About Event Publishing in Red Apps
SRWRuntime allows any Red App to "publish" events in response to an occurrence that has important business functionality inside the Red App. SRWRuntime differentiates between event publishing and service processing. The execution of a service is synchronous; event publishing always works asynchronously.
To notify registered listeners about events, you publish an Event ID. This processing does not block for the event listener in order to complete its work. Each Sabre component or Red App that generates a set of events is responsible for defining a list of events and assigning an Event ID to each event. The Event ID identifies the event type. A Red App can send multiple events of the same type.
When an event is posted by an event source to SRWRuntime, SRWRuntime calls listeners that are registered for the Event ID and event state. If an event object is posted to SRWRuntime with a null state, the
POST state is assumed. However, the SRWRuntime EventListener class is always initialized to the
PRE state during instantiation, therefore, if you use this class, the state is always initialized to
PRE unless you explicitly set it to
When an end-user executes a command in Sabre emulator, SRWRuntime provides the events for Red Apps. By registering event listeners for the events, Red Apps can access end-user commands in an asynchronous manner. If the Red App needs to block an end-user command for business reasons, such as to provide a markup service, the Red App uses synchronous processing by providing registered service functionality.
Publishing Events by Providing IEvent Information
Events may be published at any time, provided that the Red App registers the event in
Red Apps that generate a set of events define their list of events and assign an Event ID to each event, along with all other attributes. The Event ID uniquely identifies the event, including the source. The Bus uses the event to notify listeners that are registered for the event.
To publish events using SRWRuntime, a Red App needs to use the postEvent() method by providing IEvent information. The default implementation of IEvent (Event) is available in the com.sabre.edge.cf.model.element package.
IEvent holds and clones the following information before sharing it with registered event listeners:
Event ID. A unique ID that provides event information. The Event ID will match
event_filterthat is declared for the listener. Your Event ID must conform to standards for Event ID naming conventions.
Event State. The state of event publishing.
PREpublishes the event before executing the business logic.
POSTpublishes the event after executing the business logic.
ServiceContext. This is the context that holds detailed information about an event. Request and response objects inside a service context provide this additional information.
A Red App also does the following to publish its events:
Obtain an authentication token with SRWRuntime in the Java code
Register the Event IDs in the
redapp.xmlfile. This provides SRWRuntime with the IDs of the events that a specific Red App is publishing.
For more details, see Sample Process for Publishing Events.