Configuring the System for XAI Messages
The following provides links so that you can easily navigate the information related to configuring the system for XAI messages:
• Designing Your Real Time Messages
• Designing the Real Time Message XSL
• Designing the Real Time Message Route Types
• Designing the Real Time Message NDS Types and Download Profile
• Designing the Real Time Message NDS Types and Download Profile
• Designing the Near Real Time Response
Designing Your Real Time Messages
Consider the following integration scenario. A page in your product is configured to send information to an external system real time. If the connection is down, the user is warned and may authorize that the message is sent in near real time. The following sections describe how to design the control tables needed for both scenarios.
Top of Page
Designing the Real Time Message XSL
During implementation, you will determine the information required to send to the external system. The real time message engine is passed all the data available in the page model as an XML document. The request XSL must be designed to map this data into a format expected by the target.
In addition, you should create two response XSLs to transform the message received from the target system.
• One XSL is used for real time responses. The XSL transforms the message into a format understood by the page service user exit. Note that any updates to a system business object as a result of the response is the responsibility of the user exit that called the real time message engine.
• One XSL is used for non-real time responses. In this case, if the response should update a system object, the response must trigger an XUS to update the system object. Therefore, the XSL must map the response into an XML request that reference the appropriate service to update the system object.
Top of Page
Designing the Real Time Message Route Types
For this scenario, you must create two route types.
• Create an XAI Route Type for the real time message. Indicate the sender, the request XSL and the response XSL used for real time responses.
Note: 
The sender referenced on the route type should be one that supports synchronous communication (such as an HTTP sender).
• Create an XAI route type for the near real time message. Indicate the sender, the request XSL and the response XSL used for near real time responses. Mark the route type to check the flags Receive Acknowledge and Post Response. These flags indicate to XAI that a response should be received and that additional processing is required.
Top of Page
Designing the Real Time Message NDS Types and Download Profile
For this scenario you must create two NDS types
• One NDS type is used for the real time message. Indicate an appropriate notification download condition. This allows the mechanism that creates the NDS to refer to this condition rather than hard-coding the NDS type.
• One NDS type is used for the near real time message. This NDS type must reference a special XAI inbound service used to indicate to the download staging sender that the XDS does not need to be created.
Note: 
Download Condition. The real time message engine receives the NDS type as input. It is the user exit's responsibility to determine the appropriate NDS type based on a notification download condition.
You'll need to create an entry in the service provider's notification download profile for each NDS type. Set the processing method to XAI and indicate the appropriate route type (real time or near real time) created above.
Top of Page
Designing the Near Real Time Response
To process a response to the near real time message, you must also design the XAI inbound service to be used to process the response.
• The XSL transformation scripts that are referenced by the inbound service should populate the appropriate XML elements to allow XAI to recognize that the inbound message is a response.
• Otherwise, the inbound service should be designed to process this message as appropriate. For example, if the response should update the status of the record that initiated the outgoing request, the inbound service should reference the appropriate schema to update the appropriate record.
Top of Page