Event Framework

R24 AMR | Min(s) read

Feedback

Inflow Requests with PW

In this type of request, you define a process workflow (PW) and then use that workflow to process the request.

To configure an inflow request of this type, you need to:

Define the number of PW.ACTIVITY records. In the example below, you create two records - one to create a new customer and one for an account for that customer.
Define the PWD (Process Workflow Definition), which defines how the request is executed.
Create an inflow definition using Inflow Designer.

For all PW related configurations, see the Process Workflow user guide.

Creating the PW.ACTIVITY Records

The number of PW.ACTIVITY records you create varies according to the scenario. In our example, we need to create two activities - one to create a new customer and another to create an account for that customer.

In the create a new customer activity, we provide the function I F3. Since Inflow supports versions, we create the customer with a comma version. The Default Status Code can be any status which is not the completion status - it is the status in which the activity will be immediately after its launch.
In the account activity, we use the same function as customer. We also provide a mapping that makes sure that the account created is mapped to the new customer we created previously.

Defining the PWD (Process Workflow Definition)

In the example, PW.PROCESS.DEFINITION is created that contains two activities that were created previously.

Creating Inflow Definition using Inflow Designer

Use Inflow Designer to:

Design an inflow definition for the created process definition.
Publish the inflow definition in the t24 area, so it can be used to post the request.

For more information, see the Inflow Designer section.

Supported Scenarios for Inflow with PW

When inflow is used with PW, a set of request types is supported. This topic shows the supported types.

Single Request

An inflow request container holds a single inflow request involving a single Transact application or version. This basic request ensures that inflow covers the area currently dealt with by single requests that come in through the outbound adapter.

The expected response is:

Technical acknowledgment as soon as the request is accepted in the inflow staging.
A business (Transact) response via an integration event - for example, create new security - which can be defined at the end of the inflow process.

Bulk Request

An inflow request contains a set of identical single inflow requests involving the same Transact application or version.

The inflow request mirrors the BatchOFS or BatchOFML area covered through the outbound adapter.

The expected response involves:

Technical acknowledgment as soon as the request is accepted in the inflow staging. This response signals the successful load of the inflow container into staging. As specified above, in case of errors, the response will also set an error status per individual request. This status may be:
- Successfully loaded. Requests are committed only if the container is successful. In case of errors, the container is aborted and rolled back.
- Problem when loading.
- Not processed. The container load has been aborted before this individual request has been reached.
A business (Transact) response via an integration event, which can be defined at the end of the inflow process for each of the inflow individual requests. For example, load prices, where we have containers of 1000 prices. All requests are independent of each other and involve the same application or version.

Inflow receives multiple requests in a single inflow container, where each request is executed and committed or rolled backed individually. Bulk Inflow is a type of inflow request in which all the requests in a single inflow container are processed in one transaction rather than separate transactions.

Each bulk inflow request is indicated with a tag bulkIndicator with the value yes in the container section of the bulk inflow request.

<container:bulkIndicator>yes</container:bulkIndicator>

Each bulk inflow request has a separate message ID indicated in containerCustomCommon with the name bulkMessageId.

<container:containerCustomCommon name="bulkMessageId">MessageId</container:containerCustomCommon>

In the case of Bulk Inflow, all the individual requests contained in a single inflow container are processed as one request, i.e. one transaction.

Success or failure of the transaction depends on the success or failure of all the individual requests in that particular transaction.

The request gets processed (succeeds) only if all the individual requests within the inflow container get processed (succeed). If any of the requests within the inflow container fails, the complete request fails.

Setting the attribute BATCH.OFS in OFS.SOURCE in the case of Bulk Inflow is not allowed.
Bulk Inflow support is not provided for AA requests.

Sample Bulk Inflow Request

<?xml version="1.0" encoding="UTF-8"?>
  <container:inflowContainer xmlns:container="http://www.temenos.com/T24/inflow/AcctAgg/ContainerupdateAccountList" xmlns:p="http://www.temenos.com/T24/inflow/AcctAgg/updateAccountList" xmlns:p1="http://www.temenos.com/T24/inflow/Common/RequestCommon" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.temenos.com/T24/inflow/AcctAgg/ContainerupdateAccountList AcctAgg-ContainerupdateAccountList.xsd ">
  <container:containerId></container:containerId>
  <container:containerTimestamp></container:containerTimestamp>
  <container:containerDataSource></container:containerDataSource>
  <container:bulkIndicator>yes</container:bulkIndicator>
  <container:tenantId></container:tenantId>
  <container:inflowRequest>
    <p:updateAccountList>
      <p:requestCommonDetails>
        <p:requestCommon>
          <p1:requestType>process-based</p1:requestType>
          <p1:companyCode>GB0010001</p1:companyCode>
          <p1:userName>SSOUSER1</p1:userName>
          <p1:messageId>desTest1</p1:messageId>
          <p1:timestamp></p1:timestamp>
          <p1:transactionMode></p1:transactionMode>
          <p1:replace></p1:replace>
          <p1:replaceFieldIndicator></p1:replaceFieldIndicator>
          <p1:customCommon name=""></p1:customCommon>
        </p:requestCommon>
      </p:requestCommonDetails>
      <p:receiveaccountlist_ral id="200100" index="">
        <p:customerId>123121</p:customerId>
        <p:bankCode>12111</p:bankCode>
        <p:subStatus>AWAITINGUSERACTION</p:subStatus>
      </p:receiveaccountlist_ral>
    </p:updateAccountList>
    <p:updateAccountList>
      <p:requestCommonDetails>
        <p:requestCommon>
          <p1:requestType>process-based</p1:requestType>
          <p1:companyCode>GB0010001</p1:companyCode>
          <p1:userName>SSOUSER1</p1:userName>
          <p1:messageId>desTest2</p1:messageId>
          <p1:timestamp></p1:timestamp>
          <p1:transactionMode></p1:transactionMode>
          <p1:replace></p1:replace>
          <p1:replaceFieldIndicator></p1:replaceFieldIndicator>
          <p1:customCommon name=""></p1:customCommon>
        </p:requestCommon>
      </p:requestCommonDetails>
      <p:receiveaccountlist_ral id="200100" index="">
        <p:customerId>123121</p:customerId>
        <p:bankCode>12111</p:bankCode>
        <p:subStatus>AWAITINGUSERACTION</p:subStatus>
      </p:receiveaccountlist_ral>
    </p:updateAccountList>
    <p:updateAccountList>
      <p:requestCommonDetails>
        <p:requestCommon>
          <p1:requestType>process-based</p1:requestType>
          <p1:companyCode>GB0010001</p1:companyCode>
          <p1:userName>SSOUSER1</p1:userName>
          <p1:messageId>desTest3</p1:messageId>
          <p1:timestamp></p1:timestamp>
          <p1:transactionMode></p1:transactionMode>
          <p1:replace></p1:replace>
          <p1:replaceFieldIndicator></p1:replaceFieldIndicator>
          <p1:customCommon name=""></p1:customCommon>
        </p:requestCommon>
      </p:requestCommonDetails>
      <p:receiveaccountlist_ral id="200100" index="">
        <p:customerId>123121</p:customerId>
        <p:bankCode>12111</p:bankCode>
        <p:subStatus>AWAITINGUSERACTION</p:subStatus>
      </p:receiveaccountlist_ral>
    </p:updateAccountList>
  </container:inflowRequest>
  <container:containerCustomCommon name="bulkMessageId">desTest1</container:containerCustomCommon>
</container:inflowContainer>

Composite Request with Related Application Calls

An inflow is used to perform a set of Transact application or version calls.

All calls are performed in a business inflow transaction and all updates are successful or roll back occurs. Although the Transact calls are in a transaction they're not intertwined - this means they could be executed as provided. None of the calls requires the result of another call from the same inflow request.

Example

For example, the two updates, update customer and update address (DE.ADDRESS), stem from a single update of the source system but address two separate tables in Transact. We want to keep them in an inflow transaction (even though each update could be performed separately from each other).

Composite Request with Related Application Calls (intertwined)

An inflow is used to perform a set of interrelated Transact application or version calls.

All calls are performed in a business inflow transaction. The Transact calls are interdependent and some part of the result of one call will be required to perform a subsequent call. We designate them as intertwined Transact calls. Some of the calls cannot be performed without using the result of prior ones to enrich the Transact request.

Example

For example, the creation of a new account for a new customer, followed by the initial deposit, involves intertwined Transact calls.

The Transact calls need to be sequenced by the inflow (defined at inflow design time). When we create the customer, the customer id is used to create the account and the new account id is used for the funds transfer.

Loop

An inflow is used to perform a set or calls to one or several Transact applications or versions. The inflow is guided by a condition, for example, do ... while or for ... do.

Example

For example, we could use a loop to spread a funds transfer across all the accounts of a particular customer.

Conditional request (branching)

An inflow is performed differently, according to the criteria from the request arguments.

Example

For example, the request may carry an instruction to create a customer, and if that customer is a US resident, to update FATCA.

Consider the following Process Workflow Definition (PWD):

The first activity is CREATE.CUSTOMER and the completion of that activity will check a certain condition defined in SWCOND (Where we check the customer residence). Based on the condition, the case activity CREATE.FATCA may or may not execute. If the condition for the CASE activity does not suffice, then the default activity will execute.

For the above PWD, a subroutine is written and attached to the application EB.API.

Sequence repair in Inflow

Sequence Repair is a functionality in Inflow in which all the arriving inflow requests are staged and then, based on information already known in Transact, it is decided whether the request can be executed immediately or delayed.

There are two types of Sequence Repair in Inflow:

Full Sequence Repair
Partial Sequence Repair

PW-based inflows alone can support sequence repair and based on the input from the inflow message PW knows how to execute the request.

Full Sequence Repair

In the case of full Sequence Repair, the incoming Inflow requests must be executed in the same order of sequencing. The requests which arrive out of order are stored (parked) and are executed only after the correct request arrives.

Sample full sequence Inflow request:

<?xml version="1.0" encoding="UTF-8"?>
<container:inflowContainer xmlns:container="http://www.temenos.com/T24/inflow/AcctAgg/ContainerupdateAccountList" 

xmlns:p="http://www.temenos.com/T24/inflow/AcctAgg/updateAccountList" xmlns:p1="http://www.temenos.com/T24/inflow/Common/RequestCommon" xmlns:xsi="http://www.w3.org/30011/XMLSchema-instance" xsi:schemaLocation="http://www.temenos.com/T24/inflow/AcctAgg/ContainerupdateAccountList AcctAgg-ContainerupdateAccountList.xsd ">
  <container:containerId></container:containerId>
  <container:containerTimestamp></container:containerTimestamp>
  <container:containerDataSource></container:containerDataSource>
  <container:bulkIndicator></container:bulkIndicator>
  <container:tenantId></container:tenantId>
  <container:inflowRequest>
    <p:updateAccountList>
      <p:requestCommonDetails>
        <p:requestCommon>
          <p1:requestType>process-based</p1:requestType>
          <p1:companyCode>GB0010001</p1:companyCode>
          <p1:userName>SSOUSER1</p1:userName>
          <p1:messageId>sequencerepair</p1:messageId>
          <p1:timestamp></p1:timestamp>
          <p1:transactionMode></p1:transactionMode>
          <p1:replace></p1:replace>
          <p1:replaceFieldIndicator></p1:replaceFieldIndicator>
          <p1:sequenceStart>5</p1:sequenceStart>
          <p1:sequencePace>5</p1:sequencePace>
          <p1:currentSequence>5</p1:currentSequence>
          <p1:sequenceCheckType>FULL</p1:sequenceCheckType>
          <p1:customCommon name=""></p1:customCommon>
        </p:requestCommon>
      </p:requestCommonDetails>
      <p:receiveaccountlist_ral id="" index="">
        <p:customerId>1</p:customerId>
        <p:bankCode>12111</p:bankCode>
        <p:subStatus>AWAITINGUSERACTION</p:subStatus>
      </p:receiveaccountlist_ral>
    </p:updateAccountList>
  </container:inflowRequest>
  <container:containerCustomCommon name=""></container:containerCustomCommon>
</container:inflowContainer>

Partial Sequence Repair

In the case of partial sequence repair, the incoming inflow requests need not be executed in the same order of sequencing. The current sequence number of each request is checked against the sequence number of the last executed Process Workflow (PW) Inflow request.

If the sequence number of current Inflow request is higher than that of the sequence number of the last executed PW Inflow request, the request is executed. If the sequence number of current Inflow request is lower than that of the sequence number of the last executed PW Inflow request, the request is rejected. In other words, the requests arriving for processing with a lower sequence will be rejected.

Sample partial sequence Inflow request:

<?xml version="1.0" encoding="UTF-8"?>
  <container:inflowContainer xmlns:container="http://www.temenos.com/T24/inflow/AcctAgg/ContainerupdateAccountList" xmlns:p="http://www.temenos.com/T24/inflow/AcctAgg/updateAccountList" xmlns:p1="http://www.temenos.com/T24/inflow/Common/RequestCommon" xmlns:xsi="http://www.w3.org/30011/XMLSchema-instance" xsi:schemaLocation="http://www.temenos.com/T24/inflow/AcctAgg/ContainerupdateAccountList AcctAgg-ContainerupdateAccountList.xsd ">
  <container:containerId></container:containerId>
  <container:containerTimestamp></container:containerTimestamp>
  <container:containerDataSource></container:containerDataSource>
  <container:bulkIndicator></container:bulkIndicator>
  <container:tenantId></container:tenantId>
  <container:inflowRequest>
    <p:updateAccountList>
      <p:requestCommonDetails>
        <p:requestCommon>
          <p1:requestType>process-based</p1:requestType>
          <p1:companyCode>GB0010001</p1:companyCode>
          <p1:userName>SSOUSER1</p1:userName>
          <p1:messageId>sequencerepair</p1:messageId>
          <p1:timestamp></p1:timestamp>
          <p1:transactionMode></p1:transactionMode>
          <p1:replace></p1:replace>
          <p1:replaceFieldIndicator></p1:replaceFieldIndicator>
          <p1:sequenceStart>5</p1:sequenceStart>
          <p1:sequencePace>5</p1:sequencePace>
          <p1:currentSequence>5</p1:currentSequence>
          <p1:sequenceCheckType>PARTIAL</p1:sequenceCheckType>
          <p1:customCommon name=""></p1:customCommon>
        </p:requestCommon>
      </p:requestCommonDetails>
        <p:receiveaccountlist_ral id="" index="">
          <p:customerId>1</p:customerId>
          <p:bankCode>12111</p:bankCode>
          <p:subStatus>AWAITINGUSERACTION</p:subStatus>
        </p:receiveaccountlist_ral>
      </p:updateAccountList>
    </container:inflowRequest>
    <container:containerCustomCommon name=""></container:containerCustomCommon>
</container:inflowContainer>

In this topic

Products

Ecosystem

Technology

Other Product documentation

Inflow Requests with PW

Creating the PW.ACTIVITY Records

Defining the PWD (Process Workflow Definition)

Creating Inflow Definition using Inflow Designer

Supported Scenarios for Inflow with PW

Single Request

Bulk Request

Sample Bulk Inflow Request

Composite Request with Related Application Calls

Composite Request with Related Application Calls (intertwined)

Loop

Conditional request (branching)

Sequence repair in Inflow

Full Sequence Repair

Partial Sequence Repair