Message Flow

TIBCO application messages are transformed into requests with content and forwarded to Substation ES IMS Interface through XCF to the IMS OTMA server and, finally, to the IMS application for processing.

IMS Interface supports two types of message flow: requests or replies, and triggers. See the following examples for more detailed message flow scenarios:

Requests or Replies

The following figure shows the message flow of IMS Interface for requests or replies:

Substation ES accepts TIBCO application messages from the following sources:

  • TIBCO messaging applications anywhere in the network.
  • TIBCO transactional clients. Substation ES first sends the messages from those clients to the TIBCO Transactional store-and-forward daemons, which notify TIBCO Substation ES transactional agents of the messages to be processed.
  • Transactions that run within the IMS BMP and MPP regions. These messages are called triggered messages.
  • Other installations of Substation ES through host-side processes or transactions.
Note: For an overview of message flow between messaging applications and Substation ES interfaces, see Substation ES Message Flow.

Triggers

The following figure shows the message flow for IMS triggers:

  1. In an IMS trigger, the initial request comes from a BES application in the z/OS environment. In this figure, the request can originate from a BMP (9) or 3270 (8) device, which passes it to IMS OTMA (7).
  2. IMS OTMA forwards the message to XCF (6), which sends the message to IMS Interface (5) in Substation ES.
  3. IMS Interface forwards the message to ESB Interface (4) and the daemon or EMS server (3).

  4. The daemon or EMS server (3) sends the message to either TIBCO BusinessWorks (1) or another TIBCO messaging client (2).

In trigger transactions, no result set or acknowledgment is returned, hence no dotted arrows in this figure.

  • External Request or Reply Message Flow
    Implementing a request or reply solution is usually nonintrusive. You can execute existing host-side transactions and programs without changes.
  • Triggered Message Flow from IMS Transactions
    Implementing a triggered message flow is normally intrusive. If you want to use an IMS application to write messages to IMS queues with an alternate IOPCB, you must first add code to the application logic.
  • Synchronous Callout Message Flow from IMS Applications
    Implementing a callout is normally intrusive. If you want to use IMS application to send request messages using ICAL to the awaiting Substation ES process, you must first add code to your application logic.