Section I – SCXML > SCXML > Events Bottom of Page
| Genesys 8.0 SCXML Technical Reference
< Anchor Elements Expressions >

## Events

The event model will be fully supported. It will support both internal session events and external events.

Internal Events

These events are published and consumed by the same SCXML session. The following are the methods of managing them:

- Publish — Either the `<event>` or `<send>` element can be used. The SCXML engine will put the event into the session's event queue. When using `<send>`, you can put the event on either the external event queue or the 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.).
- Subscribe — `<transition>` element. If the event has properties, the `_event` system variable will contain the event's properties at the following location: "`_event.data`". The orchestration platform will support wildcards ("*") in the event names. See the SCXML specification for details.

External Events

These events are published and consumed by the given SCXML session and the corresponding external entity. The following is the list of external entities that will be 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. These events are delivered to the appropriate session by the message functionality of the platform. This includes within the same platform server and across platform servers. The target attribute value will have 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 will be the functional module's namespace name.

In addition to the `<send>` element, a given functional module may have an action element to send events, as well.

- Subscribe — The `<transition>` element. If the event has properties, the `_event` system variable will contain the event's properties at the following location: "`_event.data`". The orchestration platform will support wildcards ("*") in event names. See the SCXML specification for details. In general, overall external event subscription is implicit:

- Functional Modules — For details, see the Events section.
- External applications and other SCXML sessions — When these events are sent, they are sent explicitly to the given session (session ID), so no explicit subscription is needed.

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). For details, see the External 2.0 Interfaces section. The platform will have the appropriate functionality to receive events from external sources and deliver them to the appropriate sessions.
- Functional Modules — The functional module will send the events to the platform based on the defined functional module framework interfaces and the platform will deliver the event to the appropriate session event queue.

- 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 will support the appropriate functional module framework interface to receive the events from the session.
- External applications will have the appropriate web application to process the HTTP post.
- Other SCXML sessions will receive the event on their event queues via the platform.

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 will contain the sendid or id of the triggering `<send>` element. Otherwise it will be blank.
- invokeid — If this event is generated from an invoked child process, this field will contain 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 will contain the invokeid or id of the invoking `<invoke>` element. Otherwise it will be blank.

The following fields are logically present in all events, but will be filled in only in external events:

- origin — This a URI, 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.
- 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.
- 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.

#### Specific Events

The following is the list of events that are supported by SCXML.

Event Name | Description | Where used
--- | --- | ---
error.illegalcond.errortype | If a conditional expression does not evaluate to a boolean value ('true' or 'false'), this event is raised. The optional errortype element indicates the ECMAScript error type, as specified in Section 15.11.6 of [ECMASCRIPT-262]. | Any element that has a "cond" attribute, such as `<if>`, `<elseif>`, and `<transaction>`
error.illegalloc.errortype | If a location expression does not evaluate to a legal location, this event is raised. The optional errortype element indicates the ECMAScript error type, as specified in Section 15.11.6 of [ECMASCRIPT-262]. This event is also raised under the following conditions: `<param>` — If the 'expr' attribute is missing and the 'name' attribute does not refer to a location in the data model. `<assign>` — If the location expression does not denote a valid location in the datamodel. | Any element that has an attribute that is a location expression, such as `<send>`, `<invoke>`, `<param>`, `<assign>`, `<validate>`, and `<anchor>`
error.illegalvalue.errortype Note: same as error.invaliddata | If a value expression does not return a legal data value, this event is raised. The optional errortype element indicates the ECMAScript error type, as specified in Section 15.11.6 of [ECMASCRIPT-262]. | Any element that has an attribute that is a value expression, such as `<log>`, `<send>`, `<cancel>`, `<invoke>`, `<param>`, `<data>`, and `<assign>`
error.illegaldata.errortype Note: same as error.invaliddata | Any errors which arise during initialization must be mapped into this event, where the optional errortype element indicates the ECMAScript error type, as specified in Section 15.11.6 of [ECMASCRIPT-262]. | Any element that is processed at load time, such as `<data>`
error.script.errortype | Any errors which arise during processing of `<script>` content must be mapped into this event, where the optional errortype indicates the ECMAScript error type, as specified in Section 15.11.6 of [ECMASCRIPT-262]. | The `<script>` element
error.unsupported.element | The platform will raise this event when an element is not supported. The element element identifies the name of the element which is not supported. | For example, we do not support the `<anchor>` element
`error.badfetch.protocol.response_code` Note: same as `error.fetch` | The platform will raise this event when it cannot fetch the data from its source. Note: If the `<scxml>` 'exmode' attribute value is strict, the platform will raise this event. If the `<scxml>` 'exmode' attribute value is lax, the platform will ignore the element. The protocol element is the type of protocol used to fetch the document. In the case of a fetch failure, the interpreter context must use a detailed event type telling which specific HTTP or other protocol-specific response code was encountered. The value of the `response_code` element for HTTP is defined in RFC 2616. This allows applications to treat a missing document differently from a prohibited document, for instance. The value of the response code for other protocols (such as HTTPS, RTSP, and so on) is dependent upon the protocol. | Any element that is fetching data from some source (source-related attributes, src, srcexpr), such as `<data>`, `<state>`, `<parallel>`, `<content>`, `<param>`
error.receive.datamismatch | If a sent event passes validation in the sending session, but the receiving session cannot handle the data format contained in the event, the receiving session should raise this event in the session for which the event was intended and should also notify the sending session of the error. This event will then be ignored. | The `<send>` element
error.send.nosuchsession | If the sending session specifies a sessionid in the target attribute that does not exist on the receiving platform, this event should be raised. | The `<send>` element
error.send.datamismatch | If the sending session specifies a data format that the receiving session does not support, this event should be raised. | The `<send>` element
error.send.ioprocessorerror | This event is raised if any platform- and connectivity-related errors are encountered. | The `<send>` element
error.send.failed | If the receiving platform returns any HTTP response code other than 204, the platform will raise this error. | The `<send>` element
`error.send.targetunavailable.stateid` Note: same as `send.failed`. typenotfound | If the `<send>` target attribute value is invalid or unreachable by the platform, this event will be raised, where the stateid element is the id of the `<state>` containing the `<send>` element. | The `<send>` element
error.send.typeinvalid.stateid Note: same as send.failed. typenotsupported | If the `<send>` target attribute value is not supported, this event will be raised, where the stateid element is the id of the `<state>` containing the `<send>` element. | The `<send>` element
error.send.noeventspecified | If neither the `<send>` event attribute nor the `<content>` element are present, this event will raised. | The `<send>` element
error.cancel.notallowed Note: same as error.notallowed | This event is raised when the `<cancel>` action is not allowed for whatever reason (for example, if the sendid is invalid or the message has already been sent) | The `<cancel>` element
error.validate.validationfailure | This event is raised at document load time if no schema is specified in this element. | The `<validate>` element
error.illegalassign | This event is raised when the application attempts to change the value of a read only–protected variable or data item. | Any element that could change a variable or data item, such as `<assign>`, `<data>`, or `<script>`
done.state.stateid | This event is raised when a state has completed its onexit processing, where the id element is the state's id. | The `<state>` element
done.invoke.invokeid | This event is raised when an invoked session has completed its processing, where the id element is the `<invoke>` invokeid attribute. | The `<invoke>` element
cancel.done | This event is raised when the cancel action has been successfully completed. | The `<cancel>` element
error.invoke.invokeid | This event indicates that there was an error trying to start the session associated with the `<invoke>` action. | The `<invoke>` element

Section I – SCXML > SCXML > Events Top of Page
| Genesys 8.0 SCXML Technical Reference
< Anchor Elements Expressions >