|
Genesys 8.1 SCXML Technical Reference |
||
< Parameter Elements Events > |
The actions of a functional module will be exposed by a defined XML namespace and elements which can be used in SCXML executable content. The behavior of these actions is somewhat similar to the model of the SCXML <send>
element (that is, the action follows an asynchronous request pattern):
Invoking an action (for example, initiating an interaction, starting target selection) behaves similarly to sending an event to the target system.
Invoking an action is part of the SCXML executable content.
After invoking an action, the orchestration platform immediately continues to the next statement in the executable content.
The completion of the action is signalled via an asynchronous functional module event.
Upon completion and the receiving of the event, the SCXML session may be in any state, and not necessarily in the state which initiated the action.
The SCXML session will handle the completion event using the <transition>
element.
The following is a list of restrictions with respect to functional module actions:
<ixn:disconnect>
, <ixn:start>
, and <ixn:sendmessage>
).<submit>
and <runtreatments>
. If other action elements are nested in an action element then an error will be thrown during document compilation.The functional module namespaces will be
The following is a summary of these namespaces and the element naming template for the Genesys functional modules:
Functional Module |
Namespace |
Element naming template |
Actions implemented |
---|---|---|---|
queue |
www.genesyslab.com/modules/queue |
|
|
interaction |
www.genesyslab.com/modules/interaction |
|
Interaction Action Elements, Voice Interaction Action Elements, Msgbased Interaction Action Elements, Chat Interaction Action Elements |
dialog |
www.genesyslab.com/modules/dialog |
|
|
resource |
www.genesyslab.com/modules/resource |
|
|
statistic |
www.genesyslab.com/modules/statistic |
|
|
classification |
www.genesyslab.com/modules/classification |
|
|
session |
www.genesyslab.com/modules/session |
|
|
webapi |
www.genesyslab.com/modules/ws |
|
The SCXML <invoke>
element is not to be used for action elements. As a result, this element has been limited to a target type of SCXML. This has been done for the following the reasons:
<invoke>
+ <content>
on every single invocation, as opposed to just directly using an XML element as executable content.<queue:submit queue="'targetqueue'" .../>
, it is clear that I'm referring to an ECMAScript variable. When specifying inline XML on <content>
, it is passed unmodified to the specified entity being invoked, preventing us from using anything from our datamodel as part of that XML. Note that this is already the intent of the SCXML specification — <param>
is used to pass parameters that can be evaluated (via 'expr') from the datamodel.<invoke>
. When we use <invoke>
, unless we invent a new language for defining which <param>
elements are mandatory as opposed to optional as opposed to mutually exclusive, we cannot even do syntax checking. This is made worse by the fact that with <invoke>
, you need a combination of a 'targettype', and src/<content>
to even figure out what is being "invoked", since the targettype itself does not identify the operation. With executable content, this is defined by the XSD and can be processed at document compilation time with the appropriate errors thrown. It will be checked by your XML editor when you save your SCXML document. This is very, very important, especially from a performance standpoint, since you will not always be having to validate the <invoke>
content on both sides (orchestration platform and the target system).<ccxml:createcall>
can be cancelled with <ccxml:disconnect>
. Just put <ccxml:disconnect>
in <onexit>
to accomplish this. However, the important thing is, it does not FORCE you to "cancel" the external system when leaving a state. So if you want to initiate the call and then go do something else in some other states as the call progresses, you do not have to abandon the call attempt.A functional module has three ways it can change the value of a given functional module object or property. One of these ways is through the use of an Action Element. The following is the model that should be used for providing this functionality:
The names of these actions can be whatever the function module developers feels appropriate for the object, as long as they adhere to the naming conventions for functions (see above for details).
These actions must follow the rules defined above for any action, plus the following rules:
Define the Appropriate Set of Events:
|
Genesys 8.1 SCXML Technical Reference |
||
< Parameter Elements Events > |