Persist and Restore the Flow Session State

Intelligent Advisor Flows was only made available to select customers, and will not be made Generally Available.

The Flow Engine API provides a mechanism to serialize the current session state in a form that can be persisted and used to restore the flow session later. You can get a serialized version of the session by calling IAFlowSession.getSessionState(). Serial state can be generated with or without the value of any data action that have been set in the current flow session.

The session state only contains the information required to restore the IAFlowSession itself. If the application requires additional data in order to successfully restore the interview (for example, the screen the user is currently on), it is its responsibility to make sure that information is persisted. The format of the serialized session data is not an open format. Modification of the serialized session data is not supported and the behavior of the API where modified serial session data is loaded will be undefined.

There are two modes of operation for resuming the session:

  • sameVersion: In this mode, the flow will be started using the same version of the project that was used when the flow was serialized, even if that is not the currently active version for the deployment. If that version has been deleted, then an error will occur when attempting to start the flow.

  • latestVersion: In this mode, the flow will be started using the latest deployed version. The rules for resolving differences between the version of the flow used to serialize the session and the new flow you are mapping into are detailed below.

Map a serialized flow session onto a different flow version

The general policy is that data from a serialized flow session is done on a best efforts basis. In other words, the flow engine will try to load as much of the data as it can and discard the parts it cannot map. Having data it cannot map will not result in an error. The primary mechanism for matching values is by object and field name. For example, if the flow you have serialized from contains a object called "applicant" which has a field called "the applicant's name" and the flow you are restoring to also has an object called "applicant" which has a field called "the applicant's name" they will be considered to be the same thing.

The circumstances where data for objects and fields will get discarded are:

  • The field being set does not exist in the flow (that is, in the target flow either the field or the object to which the field belongs have been removed or renamed)

  • The field being set exists but is no longer collected as an input in the flow

  • The object has been re-parented (both the object and any references to records in that object will be removed). In other words, if the source flow has a containment chain of Global to Applicant to Income, the target flow re-organizes the entities such that you have Global to Applicant and Global to Income, all instances of "Income" in the serialized flow state, along with any references to those objects will be discarded.

  • The field being set exists but the data type has changed. For example, the type for the field has changed from a Boolean to a String. This also includes the situation where a primary record list has switched to a reference list or vice versa. (Note that reference and reference lists are two different data types.)

With respect to data actions, actions are identified by control Id and object. This means that if you delete a data action control or move it to another object, any returned data that was loaded for that data action will get discarded. Returned data will also get discarded if it can no longer be mapped according to the returned data mapping. This can happen where mapped in fields or objects change name or data type. Adding new fields or objects is ok since the flow engine does not require returned data to provide a value for every field in the returned data object (the value is implied to be null).