Configuring SCE¶
SCE uses two configuration files:- An scxml file for specifying states, transitions and action
- An input mapping file that specifies event sources
Input mapping file¶
The input mapping is the main configuration file for SCE. It contains three types of statements:- An scxml path (exactly one)
- Event source specifications (may occur multiple times)
- Event specifications (applying to the previous source)
For example, the following configuration specifies a single source and two events:
statemachine scxml src/main/resources/memory.xml source xcf ShortTerm event xpath:NoCard /MemoryCards/CARDS[@countKnown = 0] event xpath:OneCard /MemoryCards/CARDS[@countKnown = 1]
To be exact, it specifies that the SCXML file to be loaded is
src/main/resources/memory.xml
and that an XCF event source with the name "ShortTerm" should be used.
Event specifications¶
At the moment, all events are determined through XPath matching. This means that only XML input is supported. In the future, further input types will be supported -- stay tuned :-)
For now, an event specification occurs in three variants:- Just XPath
- XPath with name
- XPath with name and type
The first looks as follows:
event xpath /some/path[condition]
When the xpath matches, its value will be converted to a string and the string is the name of the resulting event. This can be fairly powerful, but also slightly unpredictable.
The second specifies a fixed event name and use the XPath's value only as a payload
event xpath:name /some/path...
If the XPath matches, the event "name" will be generated and the value of the XPath will be available in the variable
_eventdata
in SCXML.
The third form also uses a fixed name and converts its input data to a FlatTree using the datamapper API.
event xpath:event_name:datatype_name /some/path
This will create the event "event_name" and convert the input data using the data type "datatype_name", with format XML. The resulting type instance will also be available in the
_eventdata
variable in SCXML.
Using tasks through SCE¶
Not surprisingly, given its status as an XTT sister project, SCE can act as a task client. To do so, one use the SCML invoke
tag, with the type "task" and a source specification giving the channel and the type of the goal specification. The parameters of the invoke are then used to create the output document using DAPI. For example
<invoke targettype="task" source="Memory:SAY:say"> <param name="utterance" expr="'Hello World'"/> <!-- note the single quotes around the string! --> <param name="timestamps.initiated" expr="System.currentTimeMillis()"/> </invoke>
will cause a SAY task with the words "Hello World" to be invoked.
Note For the invoke tag to work properly, the state must be continuously held during the task's execution. If the state is left before the task is done, a cancel will be automatically generated (this is intended and may be useful, but one should be aware of it, of course). Furthermore, if the state were to be left immediately (e.g., using an empty transition), the task won't even be invoked.
When a task is finished, the event PARENTID.invoke.done
will be generated. Here, PARENTID
is the id of the enclosing state.
Using SCE as a task-server¶
This is work in progress and not currently finished. It can be achieved using some hacks, but please ask me about it. It is definitely planned to implement this properly, and soon!