Flow persistence

Assemble flow provides the simple and extensible persistence mechanism to store the flow instances. In current Assemble flow, the developer can chose to store the flow context in GlobalContext or the relational database.

Registering the FlowContextManager

Assemble flow engine delegates the persistence features such as loading and storing flow context to the implementation of FlowContextManager. There are two implementations of FlowContextManager included with Assemble flow: AppZone (default) and database, etc.

  • DefaultFlowContextManager store the flow context into "app" zone of GlobalContext
    • It is simple to use. There is no additional configuration
    • It is suitable for the testing environment.
  • JDBCFlowContextManager will persist the flow instance into database
    • It is more suitable for the real environment
    • Its implementation is based on zero.data. You can get more information for zero.data from the documentation.
The default FlowContextManager is registered in zero.config as follows: 
# By default, the flow context manager will use the App zone to store the flow context
/config/assemble/flow/flowContextManager= "zero.assemble.flow.manager.impl.DefaultFlowContextManager"

The developer can select the JDBCFlowContextManager with following configuration. 

# Use the database to store the flow context
/config/assemble/flow/flowContextManager = "zero.assemble.flow.manager.impl.JDBCFlowContextManager"

In the future release, we will support the custom FlowContextManager implementation for advanced requirement.

Database access configuration

Before using the JDBCFlowContextManager, the developer MUST add the configuration for database access into zero.config of the application, and create corresponding database and table by Command Line Interface (CLI) tools.

For convenience, we list some sample configuration for different database vendors. You can modify it according to your environment.

  1. Embedded Derby database 
    /config/db/assemble_flow_db = {
    "class" : "org.apache.derby.jdbc.EmbeddedDataSource",
    "databaseName" : "db/assemble_flow",
    "connectionAttributes" : "create=true"
}
  2. Derby database in network-server model
    /config/db/assemble_flow_db = {
    "class" : "org.apache.derby.jdbc.ClientDataSource",
    "databaseName" : "assemble_flow",    
    "serverName": "localhost",
    "portNumber": 1527,
    "user": "user",
    "password": "pwd"
}
  3. MySQL® database (tested with MySQL 5.0.x) 
    /config/db/assemble_flow_db = {
    "class" : "com.mysql.jdbc.jdbc2.optional.MysqlDataSource",
    "serverName" : "localhost",
    "portNumber" : 3306,
    "databaseName" : "assemble_flow",
    "user" : "user",
    "password": "pwd"
}
  4. DB2® database
    /config/db/assemble_flow_db = {
    "class" : "com.ibm.db2.jcc.DB2SimpleDataSource",
    "driverType" : 4,
    "serverName" : "localhost",
    "portNumber" : 50000,
    "databaseName" : "FLOW",
    "user" : "user",
    "password" : "pwd"
}

If you want to get more details or meet any problems for database access in Zero application, you can find the answer in the "Troubleshooting database access" section.

After configuration, you need to create the database with CLI command. Under the application directory, you can use the following commands to create/drop the tables in the configured databases.

  • Create the table
    zero runsql assemble_flow_db config\sql\{db_vender}\assemble_flow_create.sql
  • Drop the table
    zero runsql assemble_flow_db config\sql\{db_vender}\assemble_flow_drop.sql

In current release, the valid value of "db_vender" could be "derby", "db2" or "mysql". In case you need to use other databases, you can create your script by refer the SQL scripts under config directory of zero.assemble.flow

Persistence Policy

Different flows may have the different requirements of persistence. In some scenarios, the flow execution is transient, e.g. the feed flow for feed aggregation, the flow status doesn't required persistence for conversational interactions, and it could be execution in memory. The developer may disable the flow persistence to improve the performance.

The developer can specify the persistence policy by setting the "persistPolicy" attribute in "process" element of flow definition. Currently, Assemble flow engine support the following persistence policies

on
Default value. All flow instances are saved normally.
failed
Only failed instances will be saved. The flow instance complete successfully will be removed.
off
No instances will be saved.

For example, we can disable the persistence of the feed flow as following

<process name="mynews" persistPolicy="off">
  <receiveGET name="rssRcv"/>
  <feed name="YahooFeed" url="http://rss.news.yahoo.com/rss/topstories"/>
  <feed name="CNNFeed" url="http://rss.cnn.com/rss/cnn_topstories.rss"/>
  <aggregateFeeds name="aggregate">
   <input value="${YahooFeed}"/>
   <input value="${CNNFeed}"/>
  </aggregateFeeds>  
  <replyGET name="rssRply">
    <input value="${aggregate}"/>
  </replyGET>
</process>

Limitations of flow persistence

Assemble flow is target for the situational application, to balance the simplicity and capability of persistence; There are some known limitations.
  1. In current release, the flow engine will create the flow instance on flow startup, uses that context during the execution, and save flow context to store at the end of request. If zero server is terminated, the suspended flow instances could be recovered after the restart. But the changes of executing flow instances before termination will be lost potentially. There is no roll-back or compensation support in current implementation.
  2. To save the flow context into durable store, the variable data used in the flow must be serializable. Otherwise, the serialization will be failed, the flow status could be lost and unable to restore in the subsequent conversation.
    In case you need to use the unserializable data. You can only use it in transient flow by setting the "persistPolicy" with "off" to disable the serialization.

Version 1.1.31300