|
Genesys 8.1 SCXML Technical Reference |
||
< SCXML Document Retrieval Runtime > |
There are several types of SCXML session initiation and the orchestration applications and logic must be tailored based on the type of "initiation." In other words, the orchestration application or logic must be aware of how it was initiated and be programmed to handle it. A developer could create two different orchestration logic "front end" applications and then have a common orchestration logic module to do the logic that is common to both. For example:
Trigger-Oriented SCXML Document
<scxml name="trigger initiated" initialstate="triggerState"> <state id="triggerState"> <datamodel> <data id="param1" _type="parameter"/> <data id="param2" _type="parameter"/> ... </datamodel> <onentry> <!--- Do some core initialization processing---> </onentry> <transition event="trigger.event" target="commonState"> <!--- prepare for common state processing set param data model ---> </transition> </state> <state id="commonStateT" src="commonStateURL"> ... </state> </scxml>
<invoke>
or <session:start>
–Oriented SCXML Document
<scxml name="started logic" initialstate="startState"> <state id="startState"> <datamodel> <data id="param1" _type="parameter"/> <data id="param2" _type="parameter"/> ... </datamodel> <onentry> <!--- Do some core initialization processing---> </onentry> <transition target="commonState"/> </state> <state id="commonStateS" src="commonStateURL"> ... </state> </scxml>
The following are the different types of session initiation that are supported by the orchestration platform.
<invoke>
Initiation — The use of <invoke>
to allow your orchestration logic/session to initiate a new session in relationship to the invoking session. No content from the invoking session will be shared with the invoked session, but the invoking session can pass data in the <invoke>
element using the <param>
element (invoking session side) and the <data>
element (invoked session side). This new session is a child of the invoking session and will be terminated when the invoking session's logic leaves the invoking state or when the invoking session ends. In order for the invoking session to continue running additional logic (states), it must use <parallel>
states (the invoking <state>
is a child of a <parallel>
state).
<session:start>
Initiation — The use of <session:start>
to allow your orchestration logic and session to initiate another session. The difference between using this action and the <invoke>
is that the session started using the <session:start>
is independent of the starting session and will not terminate when the starting session terminates. This action is needed to support long-standing service logic sessions that are initiated from interaction process sessions. No content from the starting session will be shared with the started session, but the starting session can pass data in the <session:start>
element. In addition, this does not block a given state of the starting session. Data from the starting session can be passed using the <param>
element as part of the <session:start>
element. This data is passed and managed in the same way as with <invoke>
initiation. <session:start>
, but allows 3rd party applications to start orchestration logic sessions without the need of using an orchestration platform trigger.For details on defining, passing, resolving, and potentially returning session parameters, see the Session Parameterization section.
|
Genesys 8.1 SCXML Technical Reference |
||
< SCXML Document Retrieval Runtime > |