Overview of Inflow

Inflow allows you to carry out business transactions. You can enrich the incoming data either with elements that are already known to Transact or with elements that belong to the same inward data set.

Inflow Principles

Inflow processing implements the following principles:

• Clear separation between the messages - the data change requests - that are received and the processes that are triggered in Transact by the incoming data.
• The use of stateless workflows in Transact to manage the sequences of interdependent calls that are needed to complete the business operations that make up the transaction.
• The acceptance of inward messages - a two-phase commit - in a staging area (a queue or a table).
• The definition of the processing steps, sequence of operations, rules of enrichment are flexible and codeless, based only on configuration.
• The provision of a designer to help you build these definitions and manage the Inflow configuration.

Typical Inflow Configuration

In a typical Inflow configuration,

• The originator sends one composite message to the Transact inflow queue using 2PC.
• The Inflow workflow processes the message by calling multiple operations and enrichments in Transact.
• The originator sends a known business message to Transact, making the ESB implementation simpler.
• There's only one round trip between ESB and Transact, which improves the overall performance of the interface.

Additional Benefits

The additional benefits of our Inflow solution include:

• The possibility of building a library of common business flows in Model Bank, cutting down L3 development.
• Easier upgrades, as any migration or change in the message handling is carried out at the time of development. No extra effort is required from clients or client developers.

Inflow Design Time

You add a Transact Inflow Designer Project under the Integration Studio plugin. This project is used to fetch the schemas from Transact to construct the XML request for the Inflow runtime to process.

Inflow Runtime

In a typical message flow, the Inflow request is either sent from an ESB (IIB is currently supported) or directly inserted to the JMS queue (non-ESB).

The above diagram shows the components that are involved in the typical message flow of an inflow request. As shown in the diagram:

1. The request XML Message is either:
   • Inserted into the inflow queue (Non-ESB solution).
   • Sent to Inflow REST API from an ESB (IIB).
   The default queue which inflow MDB listens to is queue/inflow, a JMS queue configured in ejb-jar.xml.
2. In an ESB solution, the process of transforming the XML message to OFS and inserting into the database table is done by the Inflow REST API.

   In a non-ESB solution, the inflow MDB listens to the JMS queue and transforms the XML to OFS and inserts into the database table respectively (see 2a and 2b in the diagram).

3. Inflow Listener and Failure Recovery Listener (spring listeners) are two scheduler tasks that are responsible for polling the inflow database table for the inflow id.

   The former listener picks the list of record ids (inflow ids) from the staging table. Later, the listener comes into picture whenever there is a failure and is responsible for moving the failed records from Failure table to staging table.

4. The inflow id list picked from the staging table is sent to Inflow Listener Queue.
5. Dispatcher MDB listens to the inflow Listener Queue and fetches the data for the received inflow id from the Inflow staging table.
6. After receiving the data for the inflow id, the Dispatcher MDB sends the input request to the Transact API by starting the global Transaction (T1).
7. When it receives the request, the corresponding Transact API starts another transaction (T2) and sends the request to OFS Bulk Manager (OBM).
8. The OBM processes the request and sends a response back to the Transact API, where the API ends the transaction (T2).
9. The response from the OBM is returned to the Dispatcher MDB from the Transact API, which waits for the transaction (T1) to end.
10. The Dispatcher updates the data to the corresponding DB table (success or failure) based on the response received from the Transact API and ends the Transaction (T1).

    If the response is:

    • A success, the transaction is committed and the record is moved from staging table to success table.
    • A failure, the transaction is rolled back and a new transaction is initiated to move the record to the failure table. The transaction ends when the record is committed in the failure table.

• Inserted into the inflow queue (non-ESB solution).
• Sent to Inflow REST API from an ESB (IIB).
  The default queue which inflow MDB listens to is queue/inflow, a JMS queue configured in ejb-jar.xml.

Inflow_EE.ear has the following components:

Inflow uses the following tables to process inflow messages.