A SubFlow state is used to call another flow as part of a flow execution.
The flow processor can transition to a SubFlow state that has its own separately defined flow processor. A sub-flow has its own context, which is isolated from the context of the parent flow. You can define data mappers from the parent to the child context, thus enabling separate namespaces and the ability to reuse the sub-flows from different parent flows. When the navigation of this sub-flow is complete, the specified data mapper copies the reply data to the parent context and the control of the flow returns to the parent flow.
The events associated by default to the SubFlow state are the exit events defined in the sub-flow and cannot be deleted. The list of events can be refreshed by using the button.
The sub-flow state is represented in the statechart diagram by the following node:
A sub-flow composed by a sequence of popup states is supported, as shown in the Figure below. These types of sub-flows are an example of common flows that may be reused by different transactions.
Note The output from the subflow state in the parent workflow must match the current exit events.
▪ If the output from the subflow state does not match any of the current exit events, the following error message is displayed:
The [flowEvtname] event does not match with any of the current exit final events with the subFlow [SubFlowname].
▪ If there is any exit event with no transition defined, the following warning message is displayed:
There are some events not being used in State: [SubFlowname] -- [Evtname].
button.
