Contents
SCXML Language Reference
Click here to view the organization and contents of the SCXML Language Reference.
SCXML stands for State Chart XML: State Machine Notation for Control Abstraction. Orchestration Server utilizes an internally developed SCXML engine which is based on, and supports the specifications outlined in the W3C Working Draft 7 May 2009 [4]. There are, however, certain changes and/or notable differences (see Extensions and Deviations) between the W3C specification and the implementation in Orchestration Server which are described on this page. Only the ECMAScript profile is supported (the minimal and XPath profiles are not supported).
Usage
SCXML documents are a means of defining control behaviour through the design of state machines. The SCXML engine supports a variety of control flow elements as well as methods to manipulate and send/receive data, thus enabling users to create complex mechanisms.
For example, Orchestration, which is a consumer of the SCXML engine, uses SCXML documents to execute strategies. A simple strategy may involve defining different call routing behaviours depending on the incoming caller, however, the SCXML engine facilitates a wide variety of applications beyond simple call routing.
Authoring SCXML documents can be done using any text editor or by leveraging the Genesys Composer tool.
Syntax and Semantics
The appearance of an SCXML document is very similar to that of any other markup language. The use of various SCXML-specific tags define the structure and operation of a state machine. The SCXML snippet below illustrates how an SCXML document may look like in structure:
<?xml version="1.0" encoding="UTF-8"?> <!-- Specifying the encoding is important! --> <scxml version="1.0" xmlns="http://www.w3.org/2005/07/scxml" name="SCXML DOCUMENT NAME" > <initial> <transition target="FIRST_STATE"> <log expr="'Inside the initial transition'" /> </transition> </initial> <state id="FIRST_STATE"> <onentry> <log expr="'Do things here when state is first entered'" /> <send event="LEAVE_STATE" /> </onentry> <onexit> <log expr="'Do things here when state is being exited'" /> </onexit> <transition event="LEAVE_STATE" target="exit"> <script> var message = 'Do things here during a transition'; </script> <log expr="message" /> </transition> </state> <final id="exit" /> </scxml>
Basic Elements
SCXML elements for defining states, transitions, and behaviour include (but are not limited to):
- <state>
- <transition>
- <parallel>
- <initial>
- <final>
- <onentry>
- <onexit>
In addition, it is also possible to define actions which are performed during state transitions (<onentry>, <onexit>, within <transition>) by using the following Executable Content elements (but are not limited to):
- <if>/<elseif>/<else>
- <foreach> (planned feature)
- <raise>
- <log>
It is also possible to embed script code (ECMAScript) within the state machine by using the following element:
- <script>
One may refer to the W3C Working Draft[5] for more detailed explanations of the above elements and basic usage examples.
Managing Data
SCXML applications are commonly driven by data acquisition and manipulation, where the data gathered can be processed to determine application behaviour. Users may define data models within an SCXML document by using the <datamodel> element. A <datamodel> element may have any number of <data> elements as seen below:
<datamodel> <data ID="target" expr="'Hello World!'" /> <data ID="this_is_one" expr="1" /> <data ID="m_array" expr="['a', 'b', 'c']" /> </datamodel>
Any data objects defined in this manner become accessible as a child of the _data
global object. To access a data object defined within a <datamodel>, the following syntax is used:
_data.data_ID // Where data_ID is replaced by the ID of the data element
Alternatively, one may opt to declare data objects/variables within a <script> block instead if more complex initialization routines are required. Variables defined within a <script> block, however, become children of the <script> element's parent's local scope. That is, if it was defined in the global scope (<scxml>), the variables will be globally accessible; if it was defined within a state, the variables will become children of the state's local scope.
<script> var target='Hello World!'; var this_is_one=1; var m_array = ['a', 'b', 'c']; </script> <log expr="'The value of target is: ' + target" />
Data sharing between SCXML sessions
It may be desirable in many situations to be able to share data between multiple SCXML sessions. Data may be shared between sessions using the following methods:
Session Initiated
- When one SCXML session initiates another SCXML session via the <invoke> action (or <session:start>, <session:fetch>, which are specific to Orchestration only!) the initiating session can share data via the model defined in the SCXML specification. For details, see the <invoke> implementation section.
Session runtime
- During the execution of a session, a session can shared data with another session via events and the <send> action.
Events
Event handling (both internal and external) is fully supported by the SCXML engine. The event model allows users to control SCXML sessions by sending events from external entities or by raising events internally during the execution of an SCXML document. These events can be used to drive transitions or send data to external systems.
Internal Events
These events are published and consumed by the same SCXML session. The following are the methods of managing them:
Publish
- To generate an event, either the <event> or <send> element can be used. The SCXML engine puts the event into the session's event queue. When using <send>, it is possible to place the event on either the external event queue or internal event queue, based on the value of the target attribute. (If the special value '
_internal
' is specified, the event is added to the internal event queue of the current session. If no value is specified, the event is added to the external event queue of the current session.). When using <send> to generate events, if there is an intention to cancel the event sent, it is recommended to use the attributeidlocation
instead ofid
.
Note: If multiple internal events were simultaneously published via <send> with a delay attribute value smaller than one second and, as a result, they may have to be raised within the same second, the events could be raised, but not in the same order as they were published.
Subscribe
- Receiving events is achieved by using the <transition> element. If the event contains properties, one may access the event's properties via the
_event
system variable:
_event.data
The Orchestration platform supports the use of wildcards ("*") when evaluating event names.
External Events
These events are published and consumed by the given SCXML session and the corresponding external entity. The following is a list of external entities that are supported:
- Other SCXML sessions
- External systems via Functional Modules
- External applications
The following are the methods of managing events from an SCXML-session standpoint:
- Publish
- The <send> element with the appropriate
targettype
attribute value:- scxml - for other SCXML sessions. Events may be delivered to the appropriate session within the same platform server or across platforms, and is facilitated by the message functionality of the platform. The
target
attribute has the following format:url#sessionid
- basichttp - for external applications. These events are delivered to the appropriate external application, based on the defined target URL and an HTTP POST message.
- fm - for any Functional Module-related systems. The
target
attribute is the functional module's namespace name.
- scxml - for other SCXML sessions. Events may be delivered to the appropriate session within the same platform server or across platforms, and is facilitated by the message functionality of the platform. The
- In addition to the <send> element, a given Functional Module may have an action element to send events, as well.
- The <send> element with the appropriate
- Subscribe
- The <transition> element. If the event contains properties, one may access the event's properties via the
_event
system variable:
- The <transition> element. If the event contains properties, one may access the event's properties via the
_event.data
- In general, overall external event subscription is implicit:
- Functional Modules -
- External applications and other SCXML sessions - When these events are sent, they are sent explicitly to the given session (by session ID), so no explicit subscription is needed.
- In general, overall external event subscription is implicit:
The following are the methods of managing events from an external system standpoint:
- Publish
- The method depends on the source of the event:
- Other SCXML sessions - The <send> element is used.
- External applications - The platform external interface is used (SendTransitionEvent). The platform has the appropriate functionality to receive events from external sources and deliver them to the appropriate sessions.
- Functional Modules - The Functional Module sends the events to the platform based on the defined Functional Module framework interfaces and the platform then delivers the events to the appropriate session event queue.
- The method depends on the source of the event:
- Subscribe
- For any of the potential subscribers, there is no explicit subscription method, because the SCXML session is targeting a specific destination when publishing the event, so the destination must have the appropriate interface to receive the event.
- Functional Modules - The Functional Module supports the appropriate functional module framework interface to receive the events from the session.
- External applications have the appropriate web application to process the HTTP post.
- Other SCXML sessions receive the event on their event queues via the platform.
- For any of the potential subscribers, there is no explicit subscription method, because the SCXML session is targeting a specific destination when publishing the event, so the destination must have the appropriate interface to receive the event.
Common Properties for Internal and External Events
[+] Internal and External Events
The following common properties are present in all events, whether internal or external:
- name - This is a character string giving the name of the event. It is what is matched against the 'event' attribute of <transition>. Note that transitions can carry out additional tests by using the value of this field inside boolean expressions in the 'cond' attribute.
- type - This field describes the event type. It MUST contain one of an enumerated set of string values consisting of: "platform" (for events raised by the platform itself, such as error events), "internal" (for events raised by <event>), and "external" (for all other events, including those that the state machine sends to itself via <send>).
- sendid - In the case of error events triggered by a failed attempt to send an event, this field contains the sendid or id of the triggering <send> element. Otherwise it is blank.
- invokeid - If this event is generated from an invoked child process, this field contains the invokeid of the invocation (<invoke invokeid="..." or id="...">) that triggered the child process or in the case of error events triggered by a failed attempt to invoke another process, this field contains the invokeid or id of the invoking <invoke> element. Otherwise it is blank.
The following fields are logically present in all events, but are filled in only in external events:
- origin - This a URL, equivalent to the 'target' attribute on the <send> element. The combination of this field with the 'origintype' field SHOULD allow the receiver of the event to <send> a response back to the entity that originated this event. Not currently supported.
- origintype - This is a character string, similar to the 'targettype' or 'type" attribute in <send>. The combination of this field with the 'origin' field SHOULD allow the receiver of the event to <send> a response back to the entity that originated this event. Not currently supported.
- data - This field contains whatever data the sending entity chose to include in this event. The receiving platform SHOULD reformat this data to match its data model, but MUST not otherwise modify it.
Extensions and Deviations
The Genesys SCXML implementation introduces various additions and differences from the W3C SCXML specifications. The following extensions and deviations were introduced to accommodate the needs of the SCXML engine.
ECMAScript
SpiderMonkey 1.7 is used as the ECMAScript engine. It implements a superset of ECMA-262 Edition 3. This allows for the inclusion of scripts within SCXML documents when more advanced computational logic is required beyond the standard SCXML elements.
System Variables
The SCXML specification defines the following system variables which may provide useful information to applications (all of which are available in the global scope):
_sessionid
- This represents the unique ID associated with this SCXML session. It is set by the platform.
_name
- This represents the name that the developer gives this particular SCXML document (for example, "Mortgage Process Logic". It is set by the developer when creating the document.
_event
- This represents the event being presented to the application. It is set by the platform when the event is available to the application.
_type
- This represents the type of application that the developer gives this particular SCXML document (that is, <SCXML> element
_type
attribute). It is set by the developer when creating the document.
In addition to the above variables, the SCXML engine also provides the following extension system variables:
_parentSessionid
- This represents the unique ID associated with the parent of this SCXML session. If the session has no parent, the value returned is an empty string. It is set by the platform.
_genesys
- This is the root object for accessing all Genesys-specific ECMAScript objects and functions. Note that the user is not allowed to set properties in _genesys as it is a protected system object. See Orchestration Extensions for more information.
_data (<datamodel>)
- These are the objects that are created based on the datamodels defined within the SCXML document. For example, data to be used during the processing of the logic and expected initiation and return parameters for the session. See the _data (ORS Extensions) section below for Orchestration-specific properties of the datamodel.
Protected Variables
Variables may be defined and set on any scope except within _genesys. In addition, top-level variables starting with '_' are considered system variables and should not be modified. Defining top-level variables with names starting with an underscore '_' is prohibited. However, the same restriction does not apply if the variable is defined under a top level property such as the datamodel.
_data (ORS extensions)
In addition to storing session start parameters and user-defined datamodel items, the _data object may sometimes be used by Orchestration to provide extra information about the session.
Property Name |
Description |
---|---|
_data.provision_object_name (8.1.200.48) |
Name of Enhanced Routing Script object associated with session. Provided in sessions that are started from a Script object (of type Enhanced Routing). |
Variable Scoping
An SCXML session has one Global Scope, and many Local Scopes. Note that this implementation differs from the W3C specification (as of February 16, 2012<ref name="scxml_0216">http://www.w3.org/TR/2012/WD-scxml-20120216/</ref>) as the specification dictates that all variables must be placed into a single global ECMAScript scope. Nevertheless, it is still in compliance with the W3C Working Draft 7 May 2009[1].
The SCXML engine creates a scope for each state in the document. The parent scope for each local scope is the parent state's local scope (or for <scxml>, the global scope). Each local scope shares it's name with the state name. This allows the SCXML logic to access ECMAScript objects and variables in its active ancestor's local scopes. For example, to access object x in the local scope of the grandparent of the current local scope state, one may use the following syntax:
__grand-parent-name__.x // Returns value of x from grandparent's local scope
See the following example on variable scoping:
<?xml version="1.0" encoding="UTF-8"?>
<scxml version="1.0" xmlns="http://www.w3.org/2005/07/scxml"
initial="outer">
<datamodel>
<data ID="dataval" expr="'Accessible from anywhere!'" />
</datamodel>
<script>
var globalval = 'Also accessible from anywhere!';
</script>
<state id="outer">
<onentry>
<script>
var parentval = 'Accessible from outer';
</script>
<log expr="_data.dataval" />
<log expr="globalval" />
</onentry>
<initial>
<transition target="inner" />
</initial>
<state id="inner">
<onentry>
<script>
var childval = 'Accessible from inner';
</script>
<log expr="childval" />
<log expr="__outer__.parentval" />
</onentry>
<transition target="done_inner" />
</state>
<final id="done_inner" />
<transition event="done.state.outer" target="exit" />
</state>
<final id="exit" />
</scxml>
Function Scoping and Persistence
ORS functions defined within SCXML documents (e.g., via <script> elements) may not behave as expected following an Orchestration failover and session restoration. Specifically, the scope in which a function executes may change following a session restore. Consider the following example:
<scxml initial=”my_state”> … <script> // This is a top-level script block var scope = “global”; </script> <state id=”my_state”> <onentry> <script> var scope = “my_state”; var hello = “hello world!”; var fun = function(){ __Log(scope + “: “ + hello); } <script> </onentry> <transition event=”show_message”> <script> fun(); </script> </transition> </state> …
The purpose of the function fun is simple: It will print the message "my_state: hello world!". Given the example SCXML above, every time the event show_message is processed, the function fun will be called.
Now assume that an ORS failover has occurred. On session recovery, the user may find that he/she can no longer call the function fun without receiving an error like:
14:57:28.247 METRIC <exec_error sid='T5SL1E5D9923J7OG8TM4LCLQMG000001' result='ReferenceError: hello is not defined. Line 1 - in <script> at line: 117' thread='8596' />
An uneval of the session datamodel post-recovery might indicate the variables declared within the state have all been persisted:
__my_state__:{ scope:”my_state”, hello:”hello world!”, fun:(function () {__Log(scope + “: “ + hello);}) }
The key difference between pre-recovery and post-recovery is that now, the function fun will execute in global scope instead of local scope. This means that any variables referred to within the function fun will only be resolved in the global scope. A slight modification can illustrate the difference:
<scxml initial=”my_state”> … <script> // This is a top-level script block var scope = “global”; </script> <state id=”my_state”> <onentry> <script> var scope = “my_state”; var fun = function(){ __Log(scope); } <script> </onentry> <transition event=”show_message”> <script> fun(); </script> </transition> </state> …
With the above code, fun() will now instead print: "global". The scope will be resolved to the variable declared in the top-level script block.
One possible solution would be to design the function as follows:
<scxml initial=”my_state”> … <script> // This is a top-level script block var scope = “global”; </script> <state id=”my_state”> <onentry> <script> var scope = “my_state”; var hello = “hello world!”; var fun = function(self){ __Log(self.scope + “: “ + self.hello); } <script> </onentry> <transition event=”show_message”> <script> fun(this); </script> </transition> </state> …
By passing in a reference to this, the scope of the variables are now strictly-defined and should survive persistence with no change in behaviour.
Object Ownership
Objects and its associated properties are not implicitly shared with other sessions or external applications, but there are methods to explicitly share these objects and properties with other sessions and applications. A session can only share snapshots of the current properties and objects - they are not updated dynamically when the owning session changes them. The following are the methods of how content can be shared:
- When the current session is starting another session, the current session can send these properties and objects to the new session via the <invoke> or <session:start> with the <param> elements.
- One can use the <send> action element or the Web 2.0 API equivalent of the <send> element. This allows any session or external application to get any property or object on any session.
Functions
The session has access to system functions (time, date, and so on) through the standard ECMAScript objects and functions. In addition to the core ECMAScript script functions, the SCXML engine exposes some other useful functions.
E4X (ECMAScript for XML)
SpiderMonkey supports E4X, which adds native XML support to ECMAScript. This allows the user to access XML data as primitives, rather than as objects.
See the following example for usage:
var sales = <sales vendor="John">
<item type="peas" price="4" quantity="6"/>
<item type="carrot" price="3" quantity="10"/>
<item type="chips" price="5" quantity="3"/>
</sales>;
alert( sales.item.(@type == "carrot").@quantity );
alert( sales.@vendor );
for each( var price in sales..@price ) {
alert( price );
}
delete sales.item[0];
sales.item += <item type="oranges" price="4"/>;
sales.item.(@type == "oranges").@quantity = 4;
JSON
The following functions provide a convenient method of serializing and deserializing data to and from the JavaScript Object Notation (JSON) format:
- JSON Function Set 1 - These functions are fast and should not be used on JSON-related data that is untrusted:
- uneval( object )
- Converts object to JSON string form.
- eval( string )
- Converts JSON string to object form.
- JSON Function Set 2 - These functions are more secure (for example, will not run script logic) and are defined in the ECMAScript 5th Edition standard. This function set is based on the open source version found at http://www.json.org/js. Note also that it is currently unable to handle cycles:
- JSON.stringify( object, replacer function )
- Converts object to string form.
- JSON.parse( string, replacer function )
- Converts JSON string to object form
__GetDocumentURL
Returns the URL of the currently running scxml strategy.
Usage:
__GetDocumentURL()
Parameters:
- None
Returns:
- url: STRING - e.g. "www.example.com/scxml/strategy.scxml"
__GetDocumentBaseURL
Returns the base URL of the currently running scxml strategy.
Usage:
__GetDocumentBaseURL()
Parameters:
- None
Returns:
- base_url: STRING - e.g. www.example.com/scxml/
__Log
This function is the ECMAScript equivalent to the <log> element. It allows an application to generate a logging or debug message which a developer can use to help in application development or post-execution analysis of application performance.
Usage:
__Log (expr) or __Log(expr, label, level)
Parameters:
- expr: STRING which can be a variable or a constant - This parameter returns the value to be logged.
- label: STRING which can be a variable or a constant - This parameter may be used to indicate the purpose of the log.
- level: STRING which can be a variable or a constant - This parameter specifies the log level.
Returns:
- None
__Raise
This function is the ECMAScript equivalent to the <raise> element. It allows an application to raise an event which can be used to direct the execution flow of an SCXML strategy.
Usage:
- __Raise(expr)
- __Raise(expr, data)
- __Raise(expr, delay)
- __Raise(expr, data, delay)
Parameters:
- expr: STRING which can be a variable or a constant - This parameter specifies the event name.
- data: OBJECT which can be a variable or a valid expression - This parameter specifies a data model. The data from which is included in the event (like <param> children of a <raise> element).
- delay: STRING which can be a variable or a constant - This parameter must evaluate to a valid CSS2 time designation. It specifies the time delay prior to firing the event.
Returns:
- None
__GetDocumentType
Returns the document type of the currently running scxml strategy. The value returned is equivalent to the value of the _type attribute of the <SCXML> element, as specified by the developer.
Usage:
__GetDocumentType()
Parameters:
- None
Returns:
- type: STRING
__GetCurrentStates
Returns an array of strings containing names of the currently active states.
Usage:
__GetCurrentStates()
Parameters:
- None
Returns:
- states: ARRAY[STRING1, STRING2, .. ]
__GetQueuedEvents
Returns an array of strings containing events currently placed into the event queue.
Usage:
__GetQueuedEvents()
Parameters:
- None
Returns:
- events: ARRAY[STRING1, STRING2, .. ]
In
Determines if the state specified is currently active. If so, returns true, otherwise returns false.
Usage:
In( "example_state_name" );
Parameters:
- state: STRING which can be a variable or a constant - This parameter specifies the name of the state to be compared against.
Returns:
- is_in_state: BOOLEAN
Function Scoping
A caveat resulting from the Scoping Variable Scoping deviation is that developers must now be aware of the scope in which his/her functions execute. User-defined functions will generally execute in the local scope where they were defined. This means that any variables referenced within a user-defined function must also exist within that very same scope.
It is possible to invoke a function outside of its native scope (e.g. by referencing another state directly through the object model, or by referencing a function that was defined in a parent state), but note that its variable scoping will remain in that native scope (where the function was defined). See example below:
<state id="outer" initial="inner">
<onentry>
<script>
var scope="outer";
var foo=function(){__Log("foo finds scope: " + scope);}
</script>
</onentry>
<state id="inner">
<onentry>
<script>
var scope="inner";
var bar=function(){__Log("bar finds scope: " + scope);}
</script>
<script>
foo(); // Outputs --> foo finds scope: outer
bar(); // Outputs --> bar finds scope: inner
</script>
</onentry>
</state>
</state>
Note for Orchestration users only:
Function scope will not be restored after session recovery! This is a critical difference that must be accounted for when designing an SCXML application to survive fail-over and recovery. Tests have shown that after a session has been restored from persistence, all user-defined functions (particularly those defined within states will execute in the global scope as opposed to their original native scope.
To address this issue, it is highly recommended that developers explicitly specify the scope of their variables rather than use implicit scoping. See example below:
<state id="outer" initial="inner">
<onentry>
<script>
var scope="outer";
var implicit=function(){__Log("implicit finds scope: " + scope);}
var explicit=function(self){__Log("explicit finds scope: " + self.scope);}
</script>
</onentry>
<state id="inner">
<onentry>
<script>
var scope="inner";
</script>
<script>
implicit(); // Outputs --> implicit finds scope: outer
explicit(this); // Outputs --> explicit finds scope: inner
explicit(__outer__); // Outputs --> explicit finds scope: outer
</script>
</onentry>
</state>
</state>
SCXML Elements
<anchor>
The <anchor> module is not supported by the SCXML engine. This element would otherwise be used for providing 'go back' or 'redo'-like functionality for applications.
<cancel >
For <cancel>, either one of the attributes id
and sendid
may be used. However, both cannot be defined at the same time.
When using <send> to generate events, if there is an intention to cancel the event sent, it is recommended to use the attribute idlocation
instead of id
. The sendid stored at the location specified by idlocation
may then be used in <cancel>.
When the <cancel> request has been processed, the SCXML engine will send back the "cancel.successful" event if the event was successfully removed, or "error.notallowed" if there was a problem, along with the attribute sendid
in the event.
<data>
The following are the additional Genesys attributes for <data> element. They are strictly used to help define and administer the provisioning of this data from the appropriate source.
Attribute Details
Name |
Required |
Type |
Default Value |
Valid Values |
Description |
---|---|---|---|---|---|
_type |
false |
NMTOKEN |
data |
The following is the set of valid values:
|
This allows the developer to identify the data elements that are to be parameters that the platform must obtain values for when the session is initiated. Note that this does not impact the way in which the SCXML document is executed. |
_desc |
false |
string |
none |
Any valid string |
This allows the developer to provide a description of the parameter that is to be supplied at session initiation. Note that this does not impact the way in which the SCXML document is executed. |
src Attribute
- The currently supported URI schema types for the src attribute are:
- HTTPS
- HTTP
- FILE
id Attribute
- The value of this attribute must be a valid ECMAScript variable name. This means that variable semantics that include elements like "." (for example, foo.foo) and "-" (for example, foo-foo) are not allowed. The rule is that the variable name must be able to be processed on its own in an ECMAScript snippet. If not, then a TypeError event is generated.
For example,
Valid element
<data id="foo" expr="'value1'"/>
Invalid element
<data id="foo.foo" expr="'value2'"/> <!--TypeError event generated ->
If you need to create complex objects you can always create them with the <script> element as a child of the <scxml> element with the src attribute where the src attribute value points to a valid JSON object with a mime type of application/json.
<foreach> (Since ORS 8.1.200.40, SCXML 8.1.000.77)
This element is an extension to the W3C Working Draft 7 May 2009. However, it has been formally added to the W3C SCXML specification since the W3C Working Draft 26 April 2011. <foreach> is an Executable Content element (like <if>, or <log>) and can be used to create iterators. The behaviour of <foreach> is similar to that of the C# and Perl 'foreach' construct, which traverses items in a collection. This implementation differs from the W3C specification in that the SCXML engine behaves as though a deep copy of each item in the collection is created during iteration as opposed to a shallow copy. Nevertheless, iteration behaviour will remain unaffected by changes to the collection.
Attribute Details
Name |
Required |
Type |
Default Value |
Valid Values |
Description |
---|---|---|---|---|---|
array |
true |
Value expression |
none |
A value expression that evaluates to an iterable collection. |
The <foreach> element will iterate over a deep |
item |
true |
string |
none |
Any variable name that is valid in the specified data model. |
A variable that stores a different item of the collection in each iteration of the loop. |
index |
false |
string |
none |
Any variable name that is valid in the specified data model. |
A variable that stores the current iteration index upon each iteration of the foreach loop. |
<history>
The <history> element is not supported by the SCXML engine. This element would otherwise be used for allowing 'pause and resume' control flows.
<invoke>
The child element <content> of <invoke> is not supported.
<scxml>
The following are the additional Genesys attributes for the <scxml> element:
Attribute Details
Name |
Required |
Type |
Default Value |
Valid Values |
Description |
---|---|---|---|---|---|
_type |
false |
string |
combination |
Any valid string |
This is set by the developer at the beginning of the SCXML document to define what type of SCXML logic has been defined. Composer sets this property based on the type of logic you are building. It is used for reporting purposes. |
_persist |
false |
boolean |
|
The following is the set of valid values:
|
This allows the developer to suppress all persistence capabilities. Persistence is not always desired, due to the associated performance overhead. For instance, in Orchestration, current voice-related routing strategies normally run to completion in a reasonable amount of time, and in the event of a failure, restarting the routing strategy may not be problematic. Therefore, this attribute allows sessions to suppress all use of persistence, which prevents the orchestration platform from ever persisting the session. (Note that this does *not* preclude the orchestration platform from employing other techniques, such as hot standby servers, to achieve fault tolerance for these types of session. |
_statePersistDefault |
false |
string |
"may" |
The following is the set of valid values:
|
To ensure proper session persistence during High Availability recovery, the _statePersistDefault may be used as an attribute to the top-level <scxml> element. Orchestration Server uses the value of _statePersistDefault as the default for the <state> _persist attribute, if it is not specified at the <state> level.
|
_maxtime (Since ORS 8.1.300.03, SCXML 8.1.300.00) |
false | integer | "604800" | Any valid positive integer, inside double quotes. |
Specifies the maximum age in seconds that an ORS session should exist. If this age is reached, ORS shall attempt to exit the session. If specified, this overrides the value specified in configuration for ORS under scxml/max-session-age. To disable this feature, set the _maxtime to "0". As of ORS 8.1.300.13, SCXML 8.1.300.13, an available Cassandra data store will be required for this functionality. |
_microStepLimit (Since ORS 8.1.300.11, SCXML 8.1.300.10) |
false |
integer |
1000 |
Any valid positive integer, inside double quotes. |
Specifies the maximum number of microsteps allowed to be taken following the processing of one event. Subsequent transitions may arise from the processing of one event if the following transitions are eventless. If this number is reached, ORS shall attempt to exit the session. To use ORS configured default, leave _microStepLimit undefined. To disable this feature, set _microStepLimit="0". |
_stateEntryLimit (Since ORS 8.1.300.11, SCXML 8.1.300.10) |
false |
integer |
100 |
Any valid positive integer, inside double quotes. |
Specifies the maximum number of times that a state may be entered as the target of a transition. States entered indirectly as the result of a transition element or initial attribute are not considered for this limit (e.g. ancestors of the target state that must be entered before entering the target state). If this number is reached, ORS shall attempt to exit the session. To use ORS configured default, leave _stateEntryLimit undefined. To disable this feature, set _stateEntryLimit="0". |
_maxPendingEvents (Since ORS 8.1.300.11, SCXML 8.1.300.10) |
false |
integer |
100 |
Positive integer between 30 to 100000, inclusive, inside double quotes. |
Specifies the maximum number of events allowed to be queued to a session (inclusive of internal, external, delayed and undelivered events). If this number is reached, ORS shall attempt to exit the session. This feature cannot be disabled. |
_processEventTimeout (Since ORS 8.1.300.11, SCXML 8.1.300.10) |
false |
integer |
10000 |
Any valid positive integer, inside double quotes. |
Specifies the maximum time allotted for the processing of the event queue. The processing of one event may lead to additional events being queued. Processing of the event queue does not complete until the event queue is empty. This feature sets an upper bound to the amount of time dedicated to processing these events. If the timeout is reached, ORS shall attempt to exit the session. To use ORS configured default, leave _processEventTimeout undefined. To disable this feature, set _processEventTimeout="0". |
_sendSessionRecovered (Since ORS 8.1.300.13, SCXML 8.1.300.13) _recoveryEnabled (Since ORS 8.1.300.12, SCXML 8.1.300.12) |
false |
boolean |
false |
The following is the set of valid values:
|
Specifies whether or not this strategy is eligible for proactive recovery. If set to true, the session will be explicitly restored by ORS when an ORS node performs switch-over to Primary. Proactive recovery shall never be used for sessions that process multimedia interactions. |
_debug (Since ORS 8.1.300.11, SCXML 8.1.300.10) |
false |
boolean |
false |
The following is the set of valid values:
|
Specifies whether or not debugging of SCXML strategy is required. When set to true, the session will save a copy of the fully assembled SCXML strategy to disk (working directory). |
_transitionStyle (Since ORS 8.1.300.28, SCXML 8.1.300.38) |
false |
string |
legacy |
The following is the set of valid values:
|
Specifies the order in which the <transition> executable content is to be executed in the scenario where there are two or more selected transitions (only in <parallel> regions).
|
<log>
<log> has three attributes (expr, label, level). For attribute details, please refer to State Chart XML (SCXML): State Machine Notation for Control Abstraction W3C Working Draft 7 May 2009 (www.w3.org). As of version 8.1.200.46, specifying a level of 5 with a label of 22000 to 22020 will result in behavior equivalent to that for URS/IRD.
<state>
The following are the additional Genesys attributes, children, and behavior for the <state> element:
Attribute Details
Name |
Required |
Type |
Default Value |
Valid Values |
Description |
---|---|---|---|---|---|
_es_store (as of 8.1.400.40) |
false |
string |
false |
true, false |
Introduced as part of the Elastic Connector feature described in the Orchestration Server 8.1.4 Deployment Guide. When set to true in the state description in a strategy, ORS will save information about session states into Elasticsearch, which can be used for operational/performance monitoring and analytics. Example: <state id="routing" _es_store=”true”>. |
_type |
false |
NMTOKEN |
normal |
The following is the set of valid values:
|
This allows the developer to control how the platform is to handle this state and is a place holder for future support. |
_persist |
false |
NMTOKEN |
may |
The following is the set of valid values:
|
Long-running sessions typically experience concentrated time windows in which active processing is performed, followed by a relatively long time window during which the system awaits follow-up by a customer or potentially by the agent. This attribute is used to indicate to the platform whether a session can or must be persisted:
Note: Orchestration Server uses the value of <scxml> _statePersistDefault as the default for the <state> _persist attribute, if it is not specified at the <state> level. |
_deactivate |
false |
string |
no |
The following is the set of current valid values:
|
This attribute defines whether the session that enters this state and is waiting for a transition should be immediately persisted, removed from platform memory, and marked as inactive. This attribute is valid only if the "_persist" attribute is set to "may" or "must", since only persistable sessions can be de-activated. This attribute is treated purely as a hint to the platform about how meaningful it is to persist the session. |
src | Not Supported |
Persist/Deactivate option matrix |
_persist | |||
---|---|---|---|---|
no |
may |
must | ||
_deactivate |
no |
Persistence disabled. _deactivate attribute is ignored. |
The session may be persisted in this state at the platform's discretion. |
The platform guarantees that this state will be persisted upon entry. |
now |
Persistence disabled. _deactivate attribute is ignored. |
The session may be persisted in this state at the platform's discretion and will be marked as inactive when waiting for transition. |
The session that enters this state and is waiting for transition will be immediately persisted and marked as inactive. |
<param>
The <param> element has the following restriction:
- When using the <param> element with any action element, you must specify both the
name
andexpr
attributes. Because of this, the platform does not support thename
attribute value as a data model location expression if the expr attribute is missing.
<transition>
The attribute anchor
of the <transition> is not supported.
ORS Version 8.1.200.60/8.1.300.01
The behaviour of transitions in the SCXML engine is different from that which is described in the W3C Working Draft 7 May 2009 [2]. This draft spec explains the following:
The LCA is the innermost <state>, <parallel>, or <scxml> element that is a proper ancestor of the transition's source state and its target state(s).
During a transition, all active states that are proper descendants of the LCA are exited.
The new transition behaviour of the SCXML engine shares greater similarities with that of the W3C Working Draft 16 December 2010 [3], in that in the case of a transition whose source state is a compound state and whose target(s) is a descendant of the source, the transition will not exit and re-enter its source state. In addition, the notion of the LCA is replaced by the LCCA:
The LCCA is the innermost compound <state> or <scxml> element that is a proper ancestor of the transition's source state and its target state(s).
During a transition, all active states that are proper descendants of the LCCA are exited.
<validate>
The <validate> element is not supported by the SCXML engine. This would otherwise be used to invoke a validation of the datamodel.
<xi:include>
The xinclude recommendation (http://www.w3.org/TR/xinclude/) is used for inlining of ECMAScripts (<script>) and states (<state>). An application developer may specify scripts, states, and other content separately from the main SCXML document. The included document or fragment can be text or xml. See section below on using <xi:include>.
When using xinclude, the following are important considerations to keep in mind:
- Developers should ensure that the 'resolveid' attribute value is unique within a document. This is necessary when the same included document is used multiple times within the including document since, the IDs of <state>, <parallel>, and so on, must be unique across the entire document.
- Included documents must NOT transition back to states that are defined in an including document. This does not work.
Xinclude can also be used to provide a subroutine-like capability within an SCXML application by using it like a macro facility. This replaces all <xi:include> elements with the referenced state content during the initial document fetch and load. Once the SCXML application is fully assembled, it is compiled and validated before sessions can be created based on this application.
In addition to the considerations above, the following guidelines must be followed when using xinclude as a macro style "subroutine":
- For the included document:
- The document must be a valid <state> fragment that specifies the complete behavior of the subroutine. The document can contain an <scxml> document, but if it does, the xinclude declaration must use xpointer to reference the <state> that is to be used as the subroutine.
- The referenced <state> can be a simple or a compound state. If it is a compound state, it must define <initial> as well as <final> states.
- An atomic state must use <raise>/<event> to return the appropriate output parameters. A compound state, on the other hand, can use either <raise>, <event>, or the <donedata> element of the <final> states to perform this function.
- The included <state> must be self-contained: it should not have transitions to states in the including document or outside of itself.
- The included <state> must not use datamodel elements from the included document, unless the <data> elements are defined within the <state> or one of its children. Using <data> elements defined elsewhere in the included document will likely result in an error since they are not defined in the including document.
- The included <state> should not use datamodel elements from the including document. Doing so makes subroutine information global to the application. It is recommended that data should be passed to a subroutine via an event, or through variables defined via <script>.
- The included <state> must not rely on events from the including document other than the transition to the included state.
- For the including document:
- The document must have a <transition> for the event generated by the included state or subroutine. This event will contain the results from the subroutine.
- The document must have a <transition> to the included state. The event can contain the input parameters for the subroutine. Alternately, the including state can use a <script> element in its <onentry> element to define and initialize a set of parameters that are passed to the included <state>. The included state can access these parameters through the variable scoping that ECMAScript provides.
- When using <xi:include> elements, the namespaces used in the included document need to be declared in the including document.
The following are the additional Genesys attributes for the <xi:include> element as well as existing attribute limitations.
Attribute Details
Name |
Required |
Type |
Default Value |
Valid Values |
Description |
---|---|---|---|---|---|
accept |
false |
string |
Not supported | ||
accept-language |
false |
string |
Not supported | ||
encoding |
false |
string |
Not supported | ||
href |
true |
URL |
none |
The URI of the resource to include. As of ORS 8.1.300.27, this attribute also supports substitution by session start parameters. These parameters may come from the ApplicationParms section of an Enhanced Routing Script, URL-encoded parameters of a web-started session, or the <param> elements nested within a <session:start> For example: <xi:include href="http://appsrv:80/scxml/subroutine_routing.scxml" /> It is possible to parametrize the URI as follows: <xi:include href="http://appsrv:80/scxml/$$MY_SUBROUTINE$$" /> When a special token of the form $$parameter_name$$ is provided, it will be automatically substituted with the value of the matching session start parameter (case-sensitive). If the session start parameters are as follows: MY_SUBROUTINE = subroutine_chat.scxml Resulting URI: <xi:include href="http://appsrv:80/scxml/subroutine_chat.scxml" /> | |
parse |
false |
string |
"xml" |
"xml", "text" |
See the following for details: http://www.w3.org/TR/xinclude/#include_element |
resolveid |
false |
string |
none |
Any value string |
In order to support subroutines and avoid issues with duplicate SCXML element IDs (for example, <state id=x>), this Genesys extension attribute must be used. If this attribute is specified, then ID modifications will occur. All the SCXML elements with an ID attribute (<state>, <parallel>, <final>, <history>, <send>, <invoke>, <cancel>, and <data>) in the included document are prefixed by the value of this attribute, and a separating dot. In addition, the IDREF attributes in the included document (the initial attribute in the <state> element and the target and event attributes in the <transition> element) can also be modified as long as the following wildcard substitution key is specified in the value. Otherwise they will not be changed when included. The substitution key is the string "$$_MY_PREFIX_$$". If specified, it is replaced by the value of this attribute for the included document. IMPORTANT NOTE: Developers must ensure that each use of the 'resolveid' attribute value is unique across the chain of included documents. |
xmlns |
false |
string |
none |
Any value string |
Used to provide namespaces for the included document. This is necessary for fragments. If subroutines include subroutines, this attribute must be set to the appropriate namespace for the including element. For example, |
xpointer |
false |
string |
none |
When |
When resolveid is used, two additional items can be used to handle the prefix provided by this attribute:
Name |
Valid locations |
Description |
---|---|---|
$$_MY_PREFIX_$$ |
|
During document assembly, $$_MY_PREFIX_$$ is replaced with the value of resolveid only in the defined locations. The engine does not perform global search and replace with this token. |
_my_prefix |
Any ECMAScript expression |
During document assembly, <state>, <parallel>, and <final> is given a |
Children
The child element <fallback> is not supported.
Event Extensions
In addition to the standard properties in all events (see the Events section), the following are the additional attributes that are added to the SCXML events. They are accessible via the _event.data
variable.
Event Name |
Property |
Description |
---|---|---|
error.illegalcond.errortype
error.illegalloc.errortype
error.illegalvalue.errortype
error.illegaldata.errortype
error.script.errortype
error.unsupported.element
error.receive.datamismatch
error.send.nosuchsession (ORS only, since 8.1.2)
error.send.datamismatch
error.send.ioprocessorerror
error.send.targettypeinvalid.stateid
error.send.failed
error.cancel.notallowed
error.illegalassign
error.send.noeventspecified |
document |
This is the URL of the document in which the error occurred. Note: this is important if the application uses |
element |
This is the name of the element that was being executed when the error occurred. | |
linenumber |
This is the line number of the document where the error occurred. | |
error.badfetch.protocol.response_code error.send.targetunavailable.stateid |
target |
This is the target URL which was being used in the element when the error occurred. |
document |
This is the URL of the document in which the error occurred. Note: this is important if the application uses | |
element |
This is the name of the element that was being executed when the error occurred. | |
linenumber |
This is the line number of the document where the error occurred. | |
done.state.stateid done.scxml.sessionid done.invoke.invokeid |
sessionid |
This is the session ID of the session that has ended. |
reason |
This is the reason the started session has ended. | |
params |
This is the list of parameters that is passed back based on the |
Logging and Metrics
The recorded format of a metric is typically of the form:
<metric_name data_name="value" data_name1="value" ... />
The following table describes the standard metrics:
Metric Name |
Description |
Associated Data |
---|---|---|
appl_begin |
Logged when the session is started |
Name Url (main Scxml document url) |
appl_end |
Logged when the session ends |
|
cancel |
Recorded when a request to cancel a delayed <send> event is processed. |
Sendid |
doc_request |
A document has been requested from the fetching service |
Requested URL |
doc_retrieved |
A requested document has been retrieved |
Requested URL Result (Success, Failure) Error Message Cache Hit (true/false) |
eval_cond |
A condition attribute is evaluated |
Condition Result (true/false) Line Number |
eval_expr |
An expression is evaluated |
Expression Result (true/false) Line Number |
event_processed |
A queued event has been processed |
Event name Disposition (normal, terminated, no target) |
event_queued |
An event has been queued to the session. Note that events may appear more than once, as a result of deserialization. |
Event name Queue Line Number (of the element that generated the event) Type (internal/external/platform) |
exec_error |
An error was encountered while executing the document |
Message |
fm_exec_error | An FM encountered an error. |
Function Scope Message |
extension |
A Custom Action Element has been selected for execution (but has not executed, yet). |
Name Namespace |
initial | An <initial> tag was entered. | |
invoke |
The <invoke> tag is about to be executed. |
Target Type Target |
js_diag | JS Diag data (occurs whenever max ops is reached; only available on Win32) |
JSRuntime GC Bytes JSRuntime GC MaxBytes JSRuntime GC Max Malloc Bytes JSRuntime GC Last Bytes JSRuntime ID |
log |
Summarizes the result of a <log> tag. |
Label Expression Level |
onentry |
The executable content of an <onentry > element is about to be run |
Line Number State (name of containing state) |
onexit |
The executable content of an <onexit > element is about to be run |
Line Number State (name of containing state) |
param |
The value of a param element passed to <invoke> and triggered sessions. |
Name Value |
parse_warning |
A warning generated while parsing the document that does NOT result in a failure to parse or process the document |
Message |
send |
The <send> tag has been selected for execution, but has not executed yet. |
Target Target Type Event Send ID |
state_enter |
The specified state has been entered |
Name Type (standard, parallel, final, history, initial) |
state_exit |
The specified state has exited |
Name Duration (the time in ms since the related state_enter metric was logged) |
transition |
The executable content of a <transition> is about to be run. |
State (name of containing state) Condition (the string) Line Number Event Target |
persist_store | A request to persist the session has been made. |
Type (document, session) Key (for document type) Request ID (for session type) Message (for session type) |
persist_result | A request to persist has completed. |
Message |
persist_restore | A request to restore the session has been made. | |
persist_destroy | A request to delete the session from persistence has been made. | |
persist_error | An error was encountered during persistence. |
Type (document, session) Request Key Error Code Error Message |
deactivate | Deactivation was requested for the session. |
Status (success, failed) |
restored | The session was restored. |
Supported URI Schemes
The following are the set of URI schemes that are supported:
- HTTP as defined by the RFC 2616
- HTTPS as defined by the RFC 2817
- File as defined by the RFC 1738
- gesp is a Genesys specific schema which is used to invoke an Interaction Server ESP function. (For Orchestration only)
- FORMAT -
gesp: <applname>\ [<type>\]<service>\[method>]
For example,gesp:CFGInteractionServer/Interaction/SubmitNew
- The following are the meanings of the different elements of the format:
- "applname" is the 3rd party application that is to be used to process this request.
- "service" is the name of the service with which this request is associated.
- "method" is the specific function to be performed by the 3rd party application.
- FORMAT -
- gdata is a Genesys specific schema which is used to address configuration layer objects and options in Genesys Configuration Server, as well as data in an interaction's user data. Currently only supported in <submit> and <createmessage> actions. (For Orchestration only)
- FORMAT -
gdata:[<host>:<port>/]<source> [/<objtype>.<objname>][/<p-name>]
For example,gdata:config/AG.SalesGroup/supervisor
,gdata:udata
- The following are the meanings of the different elements of the format:
- "host" is the IP host address for the targeted Configuration Server. This is optional. This element is ignored if the source element is "udata"
- "port" is the port number for the targeted Configuration Server. This is optional. This element is ignored if the source element is "udata".
- "source" is the source of the data. The following are the possible values:
- config-This is data from Configuration Server.
- udata-This is data from the associated interaction.
- "objtype" is the type of configuration layer object. This element is only valid when the source element is "config". The values are the following:
- DN-DN object
- SS-Script object
- AG-Agent Group object
- PG-Place Group
- CA-BA Category or Standard Response object
- CM-Campaign object
- CL-Calling ListTR-Transaction object
- AP-Application object
- PE-Person object.
- SK-Skill object
- PL-Place object
- ST-Statistics Table
- SC-BA Screening Rule object
- "objname" is the unique name (ID) for the configuration layer object that is being referenced. There is one exception where the name is not unique and this is with the CfgDN object. This element is only valid when the source element is "config". So the unique name will be the following combination of names:
- DN name-This is the name of the CfgDN object.
- Switch name-This is the name of the CfgSwitch object.
- The format of the objname string in this case will be dname@switchname.
- "p-name" is the name of a specific property of the object. For properties like annex data. The p-name has the following format: "annex"/section-name/option-name. In the case where the source element value is "udata", this will be the key name of the user data that you want to use. For example,
gdata:udata/CategoryID
- FORMAT -
Supported Profiles
The SCXML engine supports only the ECMAScript profile. Other profiles (such as minimal or XPath) will not be supported.
Examples
Using <xi:include>
The following example illustrates how xinclude can be used to compose several subroutine documents into the main application. The main application (complex_main.scxml) includes a subroutine (complex_sub) that is composed of two additional subroutines (compound_sub and simple_sub).
Main document/SCXML Application (complex_main.scxml)
<scxml version="1.0" xmlns="http://www.w3.org/2005/07/scxml" xmlns:queue="http://www.genesyslab.com/modules/queue" xmlns:ixn="http://www.genesyslab.com/modules/interaction" xmlns:dialog="http://www.genesyslab.com/modules/dialog" xmlns:xi="http://www.w3.org/2001/XInclude"> <initial> <transition target="start"/> </initial> <state id="start" initial="complex.complex_sub"> <onentry> <script> var args = new Object( ); args.var1 = 3; args.var2 = 'data3'; </script> </onentry> <transition event="done.state.complex.complex_sub" target="exit"> <log expr="_event.data.val1"/> <log expr="_event.data.val2"/> </transition> <xi:include parse="xml" href="complex_sub.scxml" resolveid="complex" /> </state> <final id="exit"> <onentry> <log expr="'success!'"/> </onentry> </final> <final id="error"> <onentry> <log expr="'failed!'"/> </onentry> </final> </scxml>
Primary subroutine (complex_sub.scxml)
<state id="complex_sub" initial="$$_MY_PREFIX_$$.first_step" > <onentry> <script> var usefulName1 = args.var1; var usefulName2 = args.var2; </script> </onentry> <state id="first_step" initial="$$_MY_PREFIX_$$.compound.compound_sub"> <onentry> <log expr="'Performing complex_sub.results calculation for ' + _my_prefix" /> <script> var args = new Object( ); args.var1 = 1; args.var2 = 'data1'; </script> </onentry> <xi:include parse="xml" href="compound_sub.scxml" resolveid="compound" xmlns:xi="http://www.w3.org/2001/XInclude" /> <transition event="done.state.$$_MY_PREFIX_$$.compound.compound_sub" target="$$_MY_PREFIX_$$.second_step"> <log expr="_event.data.val1"/> <log expr="_event.data.val2"/> </transition> </state> <state id="second_step" initial="$$_MY_PREFIX_$$.simple.simple_sub"> <onentry> <script> var args = new Object( ); args.var1 = 2; args.var2 = 'data2'; </script> </onentry> <xi:include parse="xml" href="simple_sub.scxml" resolveid="simple" xmlns:xi="http://www.w3.org/2001/XInclude" /> <transition event="simple_sub.results.*" target="$$_MY_PREFIX_$$.complete"> <log expr="_event.data.val1"/> <log expr="_event.data.val2"/> </transition> </state> <final id="complete"> <donedata> <param name="val1" expr="usefulName1"/> <param name="val2" expr="usefulName2"/> </donedata> </final> </state>
Nested compound subroutine (compound_sub.scxml):
<state id="compound_sub" initial="$$_MY_PREFIX_$$.calculate" > <onentry> <script> var usefulName1 = args.var1; var usefulName2 = args.var2; </script> </onentry> <state id="calculate"> <onentry> <log expr="'Performing compound_sub.results calculation for ' + _my_prefix" /> </onentry> <transition target="$$_MY_PREFIX_$$.complete"/> </state> <final id="complete"> <donedata> <param name="val1" expr="usefulName1"/> <param name="val2" expr="usefulName2"/> </donedata> </final> </state>
Nested simple subroutine (simple_sub.scxml):
<state id="simple_sub"> <onentry> <script> var usefulName1 = args.var1; var usefulName2 = args.var2; </script> <log expr="'Performing simple_sub.results calculation for ' + _my_prefix" /> <raise event="simple_sub.results.success"> <param name="val1" expr="usefulName1"/> <param name="val2" expr="usefulName2"/> </raise> </onentry> </state>
Fully assembled SCXML Application document:
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" xmlns:dialog="http://www.genesyslab.com/modules/dialog" xmlns:ixn="http://www.genesyslab.com/modules/interaction" xmlns:queue="http://www.genesyslab.com/modules/queue" xmlns:xi="http://www.w3.org/2001/XInclude"> <initial> <transition target="start"/> </initial> <state id="start" initial="complex.complex_sub"> <onentry> <script> var args = new Object( ); args.var1 = 3; args.var2 = 'data3'; </script> </onentry> <transition event="done.state.complex.complex_sub" target="exit"> <log expr="_event.data.val1"/> <log expr="_event.data.val2"/> </transition> <state _my_prefix="complex" id="complex.complex_sub" initial="complex.first_step" > <onentry> <script> var usefulName1 = args.var1; var usefulName2 = args.var2; </script> </onentry> <state _my_prefix="complex" id="complex.first_step" initial="complex.compound.compound_sub"> <onentry> <log expr="'Performing complex_sub.results calculation for ' + _my_prefix"/> <script> var args = new Object( ); args.var1 = 1; args.var2 = 'data1'; </script> </onentry> <state _my_prefix="complex.compound" id="complex.compound.compound_sub" initial="complex.compound.calculate"> <onentry> <script> var usefulName1 = args.var1; var usefulName2 = args.var2; </script> </onentry> <state _my_prefix="complex.compound" id="complex.compound.calculate"> <onentry> <log expr="'Performing compound_sub.results calculation for ' + _my_prefix"/> </onentry> <transition target="complex.compound.complete"/> </state> <final _my_prefix="complex.compound" id="complex.compound.complete"> <donedata> <param expr="usefulName1" name="val1"/> <param expr="usefulName2" name="val2"/> </donedata> </final> </state> <transition event="done.state.complex.compound.compound_sub" target="complex.second_step"> <log expr="_event.data.val1"/> <log expr="_event.data.val2"/> </transition> </state> <state _my_prefix="complex" id="complex.second_step" initial="complex.simple.simple_sub"> <onentry> <script> var args = new Object( ); args.var1 = 2; args.var2 = 'data2'; </script> </onentry> <state _my_prefix="complex.simple" id="complex.simple.simple_sub"> <onentry> <script> var usefulName1 = args.var1; var usefulName2 = args.var2; </script> <log expr="'Performing simple_sub.results calculation for ' + _my_prefix"/> <raise event="simple_sub.results.success"> <param expr="usefulName1" name="val1"/> <param expr="usefulName2" name="val2"/> </raise> </onentry> </state> <transition event="simple_sub.results.*" target="complex.complete"> <log expr="_event.data.val1"/> <log expr="_event.data.val2"/> </transition> </state> <final _my_prefix="complex" id="complex.complete"> <donedata> <param expr="usefulName1" name="val1"/> <param expr="usefulName2" name="val2"/> </donedata> </final> </state> </state> <final id="exit"> <onentry> <log expr="'success!'"/> </onentry> </final> <final id="error"> <onentry> <log expr="'failed!'"/> </onentry> </final> </scxml>
Output from application:
"Performing complex_sub.results calculation for complex" "Performing compound_sub.results calculation for complex.compound" "1" "data1" "Performing simple_sub.results calculation for complex.simple" "2" "data2" "3" "data3" "success!"