Applications run in the Brand Mobiliser Processing Engine (processing engine) runtime container and are managed by the processing engine. Once deployed to the runtime container, applications can be invoked by either incoming messages or events. Events can be generated by the system, a scheduled time, or a call from an external Web service.
For a newly started application, a new session is created, and the Application Start state is executed. Sessions are based on a consumer's MSISDN, which is typically the mobile telephone number from which the message is sent. The Application Start state is created automatically for new applications, and cannot be removed. This state performs initialization prior to executing the application. The Application Start state is typically followed by at least one state. For example, if an interactive application is invoked by an incoming message, the Application Start state processes the incoming message, and routes it to the appropriate follow-up state, based on the message value. The Application Start state can also filter messages, and save incoming message values in session attributes.
If you restart an application, the existing session is reactivated, and all session attributes are available to the application. The application continues from the last active state.
The processing engine executes the current application state, calling either processMessage or processState; these methods contain state-specific logic.
If a state is reactivated by a call to its processMessage method, the state processes the incoming message.
For example, State 1 —> Send SMS state —> State 3. When the flow reaches the Send SMS state, a message is sent out and the flow waits for a response. When the response arrives, the processing engine calls the Send SMS state's processMessage method to reactivate the state. The state processes the message, finds the follow-up transition that matches the incoming message, and returns the follow-up transition state. For example, if the follow-up state is State 3, the processing engine sets the current state to State 3, and begins executing it.
When a state is activated by a follow-up transition, the processing engine calls the processState method, which contains the core logic of the state. If the state needs to call an external Web service, you implement the call in the processState method.
States do not return objects from the processState method. Instead, they set flags using the helper object SmappStateProcessingAction, which is an input parameter to the method. For example, if the state-logic processing is successful, the state calls continueProcessing(followUpState), passing the name of the follow-up state as followUpState.
The processing engine sets the current state to the value of followUpState, and executes the current state.
The first two conditions terminate the application. A call to waitForMessage pauses the application until a response is received, and the session hibernates. When the response message arrives, the life cycle restarts.
For event applications, if the processing engine encounters no follow-up transition, it checks the preconfigured terminating criteria to determine whether to stop, or keep the session alive and generate a callback to repeat from the Application Start state.