SmartFlow Event Handler  <event_handler> 

Defines an action for a given event in a SmartFlow transaction.

A fully defined event handler includes the current state of the transaction, the event to be trapped while the transaction is in the current state, the action to be executed, an optional transition to the next state, and the amount of time the transaction can remain in the next state before a timeout is triggered. Multiple event handlers can be defined for one state and a handler should be defined for every possible event.

Assume, for example, that the authenticating state requires a positive response in reply to an authentication request. There are at least five events that should be trapped and handled while authenticating: request could not be sent, positive response received, negative response received, timeout waiting for a response, and maximum number of retransmissions exceeded. Each of these events can be trapped with the send_failed, msg_received, timeout, and max_retran_exceeded event handlers. The msg_received handler references a message template that is compared to the received message and if the message matches the template the associated action is executed. This comparison makes it possible to differentiate between a positive and a negative response. In this example two msg_received handlers would be required - one to handle a positive response and one to handle a negative response.

Continuing with the same example, the action defined for a positive response could be to send an update message and move to the updating state, while a negative response would record a transaction failure and move to the idle state. Handlers for failure to send and timeout events could execute retransmission actions for a specified number of attempts until either a response is received (and the message received handlers take over) or until the number of attempts has been exceeded, in which case that handler executes the transaction failed action and the flow moves into the idle state.

Each state machine configuration should begin with an event handler that starts in an idle state and uses the transaction_start event to trigger an action that moves the flow to a non-idle state. A state machine should also include a path to at least one event handler that triggers a transaction complete or transaction failed action and then moves the flow back into an idle state.


start_point string
end_point string
height string






Current State <current_state> 1 .. 1 string
Transaction Start Event <transaction_start> 0 .. 1 emptyType
Send OK Event <send_ok> 0 .. 1 emptyType
Send Failed Event <send_failed> 0 .. 1 emptyType
Message Received Event <msg_received> 0 .. 1 string
Unsupported Message Received Event <received_unsupported> 0 .. 1 emptyType
Timeout Event <timeout> 0 .. 1 emptyType
Event Received <event_received> 0 .. 1 ServiceFlowEventsType *
User Event 1 <user_event1> 0 .. 1 emptyType
User Event 2 <user_event2> 0 .. 1 emptyType
User Event 3 <user_event3> 0 .. 1 emptyType
User Event 4 <user_event4> 0 .. 1 emptyType
User Event 5 <user_event5> 0 .. 1 emptyType
Increment User Counter <increment> 0 .. 1 customUserCounter
Decrement User Counter <decrement> 0 .. 1 customUserCounter
Trigger SmartEvent <trigger_smart_event> 0 .. 1 SmartFlowEventTypes
Send Message Action <send_msg> 0 .. 1 string
Transaction Complete Action <transaction_complete> 0 .. 1 emptyType
Transaction Failed Action <transaction_failed> 0 .. 1 emptyType
Next State <next_state> 0 .. 1 string
Next State Timeout <next_state_timeout> 0 .. 1 integer



SmartFlow Event Handlers <event_handlers> FlowEventHandlersType