Understanding the Process Flow
|
Topics: |
The application in this example contains a channel that uses an arbitrary listener to read the MT101 message found in Original SWIFT MT101 Message (Request for Transfer). The e-Business Information Exchange (Ebix) file for SWIFT converts this message to XML as shown in Transformed SWIFT MT101 Message (XML Format), before passing the message to a process flow. For simplicity and demonstration purposes, most of the MT101 message, after it has been transformed into XML, is omitted.
The process flow performs the following steps:
- Updates a local database with the ancillary data required for the actual financial records. These additional data fields are not carried on the blockchain. No commit is done.
- Sends the transaction fields to the blockchain.
- If successful, then the process flow completes and a commit is automatically made to the database.
- If the transaction is rejected by a timeout, then the database is rolled back and the message is sent as rejected with an iSM retry. This retry causes the message to be represented to the process flow at a later time (as configured). For more information on retry processing, see the iWay Service Manager User’s Guide.
- If the transaction is rejected as an error, then the database is rolled back and an email is sent to a responsible party.
The following table lists the parameter values that are used by this example for the original (raw) Hyperledger Fabric Transaction service.
|
Parameter |
Value |
|---|---|
|
arg0 |
Post |
|
arg1 |
_xpath(/_101/A/_50H/Account__) |
|
arg2 |
_xpath(/_101/B/_59/Account__) |
|
arg3 |
_xpath(/_101/B/_32B/Amount__) |
|
arg4 |
_xpath(/_101/A/_20/Reference__) |
|
arg5 |
_sreg(tid) |
The following table lists the corresponding parameter values that are used by this example for the skinned version of the Hyperledger Fabric Transaction service. For more information, see Using the Fabric Wizard to Create a Fabric Agent Skin.
|
Parameter |
Value |
|---|---|
|
Function |
Post |
|
From Party |
_xpath(/_101/A/_50H/Account__) |
|
To Party |
_xpath(/_101/B/_59/Account__) |
|
Amount |
_xpath(/_101/B/_32B/Amount__) |
|
Message Reference |
_xpath(/_101/A/_20/Reference__) |
|
Correlation |
_sreg(tid) |
Synchronous Posting Example
The following diagram illustrates the general process flow used for synchronous posting.
Complete posting to the Hyperledger Fabric is handled by this single process flow.
Asynchronous Posting Example
Asynchronous posting divides the work between two process flows. The first process flow performs the actual post and the second process flow checks the post result. The wait time for posting to the Hyperledger Fabric is reduced by not waiting for a response from the Orderer. The following pair of diagrams illustrate the general approach used for asynchronous posting.
The first process flow posts and checks for problems (only from the peers), as shown in the following diagram.
The actual posting result from the Orderer is handled in the response process flow, as shown in the following diagram.
Application Design Consideration
iWay Correlation Manager (not shown in this example) can be used for tracking expected events in longer running process flows (for example, the delay between the post and the response). Consider a scenario where the posting side might open the correlation using the transaction ID for correlation, and the response side might close the correlation. For more information on iWay Correlation Manager, see the iWay Business Activity Monitor User’s Guide.