ServiceFlows

The dsTest ServiceFlow feature simplifies a SmartFlow configuration by concealing the state machine and making interaction between SmartFlow and SmartEvents easier.

Two radio buttons - Use SmartFlow State Machine and Use ServiceFlow - appear in the SmartFlow State Machine wrapper. If the ServiceFlow button is disabled, the feature is not available. 

 A workspace will be prevented from opening if it contains a ServiceFlow and that selection is disabled (since required information is not available). It is possible to convert from ServiceFlow to a state machine, but the ServiceFlow information will be lost. It is not possible to convert a state machine to a ServiceFlow, and if attempted, the user will have to confirm that the state machine configuration will be discarded.

Defining a ServiceFlow

The ServiceFlow screen has two tabs - ServiceFlow Transactions and Message Definitions - which initially contain structures cloned from the workspace. The entire flow including message definitions can be defined using this screen, but message definitions may still be defined in the workspace. Changing the name of a message or deleting a message that is referenced in a ServiceFlow will raise a validation error.

Three types of transactions are supported and can be added to the flow using the buttons in the transaction tool bar:

Initiator Transaction - sends the selected message when the configured event is received and waits up to the configured timer value for the selected response message

Responder Transaction - receipt of the selected message sends the selected response message

Single-Message Transaction - sends the selected message when the configured event is received

The transactions are shown in a canvas-like panel that displays the transaction name, event handled, and the message templates involved. A transaction is selected by clicking anywhere within its bounds and the current selection is highlighted with a blue border. Alternate shading is used to clearly define and separate transactions. When a transaction is selected its properties may be modified in the panel on the right side of the screen. Every transaction must be uniquely named and all of its properties configured. Transactions with validation errors are printed in red. The diagram portion of the canvas is captured when the ServiceFlow is committed and is displayed in the workspace. Double-clicking the image opens the ServiceFlow.

The only events that can be handled are Event Received (the transaction's user event) and Unsupported Message Received Event. ServiceFlows are not started - they handle events fired by SmartEvents or node actions. Every transaction is associated with a user event and in the GUI user events are linked to transaction names. The properties panel of the transaction displays which user event is associated with that transaction. The GUI stores and produces the state and event handler XML for the SmartFlow state machine based on the transactions defined. In general, every transaction produces one new state and two event handlers and, if successful, returns the subscriber to idle with a transaction complete action. State names reflect the name of the first message plus a suffix of _sent or _received depending on the transaction type. Unique state names are created by appending _n as needed (incremented until a unique name is achieved).

An initiator transaction creates up to three event handlers:

one that begins in the idle state, handles the event received, sends the first message, transitions to a new state, and sets a timer

one that begins in the new state, handles the receipt of the second message, sends the transaction's user event towards SmartEvents (trigger_smart_event), and then returns to idle with a transaction complete

one that begins in the ANY state, handles the timeout event, and returns to idle with transaction failed (only one of these is created for a flow)

A responder transaction creates two event handlers:

one that begins in the idle state, handles receipt of the first message, sends the transaction's user event towards SmartEvents, sends the second message, and transitions to a new state

one that begins in the new state, handles the send_ok event, and then returns to idle with a transaction complete

A single-message transaction also creates two event handlers:

one that begins in the idle state, handles the event received, sends the transaction's user event towards SmartEvents, sends the message, and transitions to a new state

one that begins in the new state, handles the send_ok event, and then returns to idle with a transaction complete

The maximum number of transactions allowed in a ServiceFlow is the number of user_event values in the schema. If more complex event handling is required, a ServiceFlow can be converted to a state machine. Simply change the radio button selection and the states and event handlers created for the SerivceFlow will be available when the state machine is opened. It is not required that all user events sent towards SmartEvents be handled in SmartEvents.

Interacting with SmartEvents and node actions

An event may be sent to a ServiceFlow from a SmartEvents event handler action or from a node command action. In both cases the actual event that is sent is the user event associated with the transaction. In the case of a node command action, the user will have to select the appropriate user event. When working in SmartEvents, however, the event list displays the ServiceFlow transaction names, the only events available. Likewise, the event list in the event handler's event received options displays the SerivceFlow transaction names rather than user events.

Example of SmartFlow Usage

In a simple example of how ServiceFlow can be used, an event handler listening for an S6 attach could fire a "post transaction" event towards the SOAP ServiceFlow, another event handler that listened for a SOAP "post transaction" event would fire a "final transaction" event towards the SOAP ServiceFlow, and finally an event handler that listened for "final transaction" which would fire a transaction complete and then return to idle. An ANY event handler listens for a soap error event, and would fire a transaction failed and return to the subscriber to the idle state.