The Hyperledger Fabric facility in iWay Service Manager (iSM) includes access to the Fabric system, posting services, and query services. For more detailed information on these components, see Hyperledger Fabric Component Reference.
Connection to the Hyperledger Fabric system is handled through a Channel provider. This provider is responsible for securing the connection and connection recovery. Separate Channel providers, each with a unique name or properties, can be defined as required. The posting and query services must be configured to refer to an available Channel provider.
For more information and an example, see Hyperledger Fabric Channel Provider.
The Transaction service invokes chaincode (embedded logic that encodes rules for specific types of network transactions) to execute a transaction on a blockchain in the Hyperledger Fabric. It starts by sending a transaction proposal request to all the configured peers. If enough proposal responses are successful (and not too many have failed), then the transaction is sent to the configured Orderers. The Transaction service can be configured in two modes:
For more information and several examples, see Hyperledger Fabric Transaction Service.
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:
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:
Later in time...
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.
This service invokes chaincode to make a read-only query in the Hyperledger Fabric. The service sends a query proposal request to all the configured peers, then it extracts the response payload from the first successful proposal response. The payload is a single ByteString value, but it can also be parsed by the service in XML or JSON, assuming the chaincode produced the result in this format.
For more information and an example, see Hyperledger Fabric Query Service.
This service queries the Hyperledger Fabric for a specific block and returns it. The search criteria can be a block number, a block hash or a Transaction ID. The result is a BlockInfo response encoded in an XML or JSON parsed tree.
For more information and an example, see Hyperledger Fabric Query Block Service.
The Hyperledger Fabric listener connects to the event hubs and listens for block events. The listener returns the BlockEvent encoded in an XML or JSON parsed tree. In the Hyperledger Fabric, a BlockEvent is an abbreviated view of a BlockInfo with the TxReadWriteSetInfo missing but the event hub origin added. If necessary, the complete BlockInfo can be retrieved by BlockNumber later in a process flow with the help of the Hyperledger Fabric Query Block Service.
This listener does not interact with the asynchronous post requests, which are fielded by the provider and handed off to the configured Internal Queue.
For more information and an example, see Hyperledger Fabric Listener.