Real Time Outgoing Messages
This section describes the capability to send real time messages from the system to another application. The functionality works in conjunction with the near real time NDS message configuration.
Real Time Message Engine
The system provides an "engine" to communicate real time messages to an external system. This engine may be invoked by a user exit on any user interface in the system. The real time message engine receives an NDS type and a service provider as input. Using this information, the engine finds the appropriate XAI route type for the service provider's notification download profile. The route type indicates the XSLT and the XAI sender.
Note: 
HTTP Sender. In the current release of the product, only senders that communicate via HTTP are supported.
Unlike near real time messages, the XAI inbound service referenced on the NDS type is not used to build the XML request. Rather, the user exit that invokes the engine is responsible for extracting the appropriate data and passing to the engine a formatted XML document. The XSLT referenced on the route type should map attributes from XML document into a format expected by the target system.
The following points describe how the real time engine works:
• Once the XML request is built, the message is sent out based on the XAI route type's sender information.
• The system waits for a response for a predefined time out limit defined as a context entry on the sender .
• When the response is received, the engine transforms the message using the response XSL defined on the route type.
• The XML response is then passed back to the user exit that called the engine. The user exit processes the response as needed.
Note: 
As described in Routing the Message, the route type includes a flag to indicate to the system if a response requires additional action. If so, an XUS is created. The real time message engine does not support this logic. It expects the user exit to process the response as needed.
Sending Real Time Messages in Near Real Time
If the connection is not available when the real time engine attempts to communicate with the target, the engine may post the message to the download staging tables to send in "near real time" when the target system is available again.
Messages should only be posted to the staging table if the user does not need to wait for a response in real time. Consider the following examples:
• A real time message is used to request information from an external system to display to a user on a page. If the connection is down, it does not make sense to store a near real time message for this case because the user is not able to wait for the response to the request.
• There is a connection problem when the user attempts to send information to an external system. In this case, perhaps it makes sense to store a near real time message so that the information is sent to the external system when the connection is restored.
Note: 
The real time message engine does not make the decision to post a message near real time when the communication is unavailable. The responsibility lives solely with the user exit that calls the java class that invokes the engine. The following diagram illustrates a possible interaction between the user exit and the message engine:
The following points describe the diagram:
• When the user exit is informed that the real time message could not be sent, it is the responsibility of the user exit to decide if the engine should be invoked again to create a near real time message.
• The NDS type used for near real time messages is different than the one used for real time messages. The reason is because the XSL transformation script is different for real time vs. near real time.
• The NDS is created and marked pending.
• The XDS record is created and marked pending. The XML message that is ready to be sent to the sender is posted as the XML request for the XDS.
Because the XML request is already built, the NDS type used for the NDS should reference a special XAI inbound service. This service basically tells the download staging sender that the XDS already exists and doesn't need to be created.