Real-Time Message Configuration

Messages are routed to an external system real-time using the outbound message dispatcher or using the real-time send email business service. The system supports routing messages using HTTP and routing messages using JMS. In addition, there is a special type of message sender used for sending emails. The following sections highlights the supported real-time communication and the configuration needed for each.

Email Messages

For sending emails, the following configuration is needed:

  • Define a message sender configured for email. Senders of this type should be configured with the RTEMAILSNDR class. The sender context is used to configure the connection information for the connecting to the SMTP server.

  • This sender may be defined as the default email sender on the message option table. Alternatively, the message sender can be provided to the business service as input. Refer to Sending Email for more information.

Outbound Messages

For other outbound messages that are routed using the real-time outbound message dispatcher, a message sender must be configured to define how to route the message. The following points highlight more detail related to this configuration.

Determine the communication mechanism prior to configuring the sender.

  • When routing the message using JMS, the following configuration must be defined

    • Define an appropriate JNDI Server that indicates where the JMS resources are located.

    • Define a JMS Connection to define additional configuration needed for the connection.

    • Define the JMS Queue or JMS Topic to define the queue or topic to use.

  • When communicating using a JSON format, determine the method to use to convert the XML to JSON. The desired method is driven by how the request should be sent.

    • If choosing the Base JSON Conversion method, if XSL transformation needs to be applied prior to the conversion to JSON, then the target XML Request Schema must be defined (using a data area) so that the conversion logic knows the format of the XML it is converting. The XSL is applied to the outbound message’s XML Source, resulting in the defined XML Request Schema, which is then converted to JSON. If XSL transformation is not required, then the outbound message’s XML Source is converted to JSON.

    • If choosing the Rootless JSON Conversion method, the group element mapped to the XML source field is removed by the conversion, resulting in a rootless JSON request document.

    • If the XML source on the outbound message can be converted to JSON using an XSL, then the XSL Transformation method may be chosen.

    • You may also choose to convert the XML Source to JSON via the Standard API Conversion method (using a Jettison library). With this method, an XSL may optionally be provided. The conversion will be performed on the transformed XML.

    • For the response, if the outbound message BO defines detailed elements for the XML Response field, then the JSON should be converted to this format.
      • If your conversion method is Base JSON Conversion, then if the JSON response cannot be converted directly to the XML Response elements on the outbound message BO, then define a Response Schema (data area) that represents the results for the base JSON conversion. In addition, define an XSL that can transform the response from the converted XML to the XML format expected on the BO.

      • If your conversion method is Rootless JSON Conversion, the response document is assumed to be rootless. The group element mapped to the XML response field is added by the conversion process, resulting in a well formed XML response document.

      • If the conversion method is Standard API Conversion or XSL Transformation, the standard API is used to convert JSON to XML. An XSL may be defined to convert the response to the XML Response if needed.

    • If the outbound message BO defines a "raw" element to capture the response, then a response schema and XSL are not necessary. In this case, the system will perform a JSON to XML conversion using the Standard API Conversion method (regardless of the conversion method defined) and the result is captured in the XML response.

  • For HTTP senders including JSON senders, the system provides the following support for sending messages secured by OAuth authentication:
    • Using Oracle Web Services Manager (OWSM). The system provides a pre-configured set of policies for OAuth (F1-OAUTH) using a special extendable lookup. Note that the values of this policy set defines a specific CSF key repository that the implementation should use for capturing its CSF keys. In addition, there is a substitution value defined for the token URI: @F1_​OAUTH2_​URI@. Configure the appropriate URI for this implementation as described in URI Substitution. By default the system does not support additional policy sets to be defined. If your implementation requires a different policy set, contact support.

    • You may provide OAuth related settings as part of the message sender configuration for a REST API.

Define a message sender configured for each appropriate routing method. The invocation type should be configured as Real-time. For routing via HTTP, use the RTHTTPSNDR - HTTP sender class. For routing via HTTP with SOAP format automatically applied, use the SOAPSNDR - HTTP SOAP sender class. For routing via HTTP using JSON format, use the RTJSONSNDR - JSON sender class. For routing via JMS, use the RTJMSQSNDR - JMS queue sender class or RTJMSTSNDR - JMS topic sender class and configure the JMS Connection and JMS Queue or JMS Topic. Use the sender context to configure the required values for connecting to the appropriate destination.

Note: Refer to Support for Dynamic URLs for configuration needed to support dynamic URLs when sending an outbound message. There is specific configuration expected when defining the URL on the Sender in order to support dynamic URLs.

Configure the external system / outbound message type collection. The processing method defined for the external system / outbound message type must be Real-time.