Inflow
Inflow is the Integration Framework component that allows you to send inward messages to Transact at high volumes.
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.
Before you can configure inflow, you need to check that your system meets the inflow system requirements. You also need to configure your environment and carry out a number of pre-configuration tasks.
There are three types of inflow requests - requests with PW, requests without PW, and generic OFS requests.
Inflow Designer is used to publish Inflows to Transact.
Packaging and Deploying Inflows
The create inflow records in Transact through Inflow Packager you need to produce a package of designs and then deploy it.
Inflow Designer allows you to create inflow designs and publish them into Temenos Transact. But, if you want to modify the already existing designs, you must recreate the Inflow Designer project and its corresponding design records and then modify the inflow design according to your needs.
Inflow supports incoming messages for non-AA applications and versions. The following steps show how to support AA applications and versions for inflow with and without a PW process.
In order to use sub-flows, it is necessary to have imbricated (overlapping) inflows. The system supports up to three levels of sub-flows.
Inflow runtime is a part of Inflow that you use to post the requests that need to be executed by Transact. This section explains the runtime artefacts and shows how to deploy them. It also shows how to execute an inflow request.
Before you deploy Inflow_EE.ear, make sure that the connection factory, queue connection factory and the queues are created in the application server and the required modifications are done in the configuration files.
Inflow_EE.ear is the runtime artefact that contains the Inflow_REST.war, Inflow_Listener.war, Inflow_STREAM.war and Inflow _MDB.jar files. Inflow_EE.ear needs to be deployed in an application server to process the inflow messages posted to a queue.
You can execute an Inflow request using ESB, JMS queues and REST API. The ESB solution is supported by IIB Adapter.
Inflow is asynchronous, which means that when you post an inflow request, a success or failure response will be written to the processed Inflow table.
This section explains the Inflow Signal Event. If a failure occurred in Transact and all the retries for the corresponding failure are exhausted then a signal event is triggered and sent to IF.EVENTS.INTERFACE.TABLE stating the request has failed in Transact.
This section explains the Inflow Acknowledgement. It is the process of providing an acknowledgement to the queue whether the request provided (Process based, Application based and Generic OFS) is staged to the staging table (IF_INFLOW_MESSAGE).
Defining and Using Inward Landing Table
The IF.INWARD.DESIGN.LANDING table is used as a source table for Workbench and becomes a source for inflow events packaging without making the IF.INFLOW.CATALOG table editable.
Posting Inflow Request to Topics
This section explains how to enable Inflow to accept requests from Azure Eventhub and Kafka topics.
Representing Inflow with Grafana
This section details about the Temn monitoring tool Grafana, a graphic representation which helps in tracing and vizualizing the event for the data inflow.
You may need this reference information when using the software.
In this topic