Hyperledger Fabric Components

Synchronous posting sends the transaction proposal to the peers, evaluates the response, and then sends the proposal responses to the Orderer. Synchronous posting requires a response from the Orderer in order for the process flow to proceed. The subsequent portion of the flow will be aware of the resultant success or rejection of the posted transaction.

The following is an outline of the synchronous posting process:

• Runs in the process flow (pflow) as part of its logic.
• iSM standard pflow services and transformers form the payload (transaction).
• The posting service (under the covers) handles the two-way communication within the network peers.
  • Posts the transaction to multiple peers.
  • Peer chaincode validates the transaction against the smart contract.
  • Chaincode sends results back to the posting service.
  • iSM internal logic can perform first level validation of results (allows performance improvements).
  • Upon validation by iSM, the peer results are sent to the Orderer.
• Fabric's Orderer
  • Ensures the network is consistent and has ultimate control of the network.
• Posting Service (the last step)
  • Makes results available to the flow and lets the flow continue.

Asynchronous posting to the blockchain enables the posting flow to proceed without waiting for the response from the Orderer, which provides an advantage. This enables the application to proceed and handle results of the post at a later time.

The asynchronous post service, like the synchronous post service, uses the Fabric provider to reach the Hyperledger system.

The Orderer sends the new block to the peer, the peer writes the new block, and then sends an event to all the parties that have registered with its event hub. Standard iSM Internal Queue operation presents these response messages to a process flow configured on the queue; that process flow handles both success and failure responses from the Orderer. If, however, you elect to shortcut error handling by configuring the posting service to perform basic validation of peer responses, these early rejections will not be sent to the internal queue as they have not yet reached the Orderer.

The following is an outline of the asynchronous posting process:

• Runs in the process flow (pflow) as part of its logic.
• iSM standard pflow services and transformers form the payload (transaction).
• The posting service (under the covers) handles the two-way communication within the network peers.
  • Posts the transaction to multiple peers.
  • Peer chaincode validates the transaction against the smart contract.
  • Chaincode sends results back to the posting service.
  • iSM internal logic can perform first level validation of results (allows performance improvements).
  • Upon validation by iSM, the peer results are sent to the Orderer.

Later in time...

• Fabric's Orderer
  • Ensures the transaction across the networked peers is consistent.
  • Has ultimate control of the network.
  • Emits an event to be trapped by iSM.
• iSM Fabric Asynchronous Response Handler
  • The Hyperledger Fabric listener receives the event from the event hub, formats it in XML or JSON, and sends it to an iSM Internal Queue for handling.

The following diagram illustrates how iSM posts a unique iSM TID (Transaction ID) along with application data for that transaction within a block.

The result of the selected query is returned to iSM from the blockchain for transaction analysis.

Understanding the Internal Queue

Standard configuration of the Internal Queue is described in the iWay Cross-Channel Services Guide. The only caveat is that you must not enable inhibit mode for the Internal Queue. Instead, iWay recommends configuring the Internal Queue to send a passivation throttle message to the posting channel should a high water mark be reached.

See the iWay Cross-Channel Services Guide for more information on configuring an Internal Queue, including the use of persistence to prevent loss of messages in the event that the server is shut down before all response messages have been handled.

The service offers specific asynchronous component configuration, including the name of the Internal Queue to receive the response. The Internal Queue listener can use configured routing services to select the proper flow for the specific message, or can use a single flow that differentiates the messages within the flow.

The message that reaches the Internal Queue for processing includes the time of posting, the parameters of the posting service, the name of the posting service, and so on. The response flow runs under the same iSM Transaction ID (TID) as that of the posting flow.