Supply chain workflow

Let’s take a look at organizations in the PLN business scenario, as shown in the Figure 2-17.1. For demonstration purposes, we simplified the pharma ledger process, as it can be much more complex in a real-world use case:

Figure 2-1. Organizations under PLN

Our PLN process is divided by the following three steps:

1. A manufacturer makes an equipment and ships to wholesaler

2. A wholesaler distributes the equipment to pharmacy

3. The pharmacy, as a consumer, receives the equipment, and the supply chain workflow is completed.

Defining a Consortium

As we can see from the process workflow, our PLN involves three organizations: manufacturer, wholesaler and pharmacy. These three entities will join together to build a consortium network to carry out the supply chain business. The consortium members can create users, invoke smart contracts and query blockchain data. Table 7-1 depicts the organizations and users in PLN consortium

Table 7-1: Organizations and users in the PLN consortium.

In our PLN consortium, each of the three organizations has a user, an MSP, and peer.. For manufacturer organization, we have user Bob as application user, Org1MSP is an MSP id to load the MSPdefinition. We define AnchorPeers with hostname peer0.org1.example.com to gossip communication across. Similarly, wholesaler is the second organization, Alice is its application user, and its MSP id is Org2MSP. Eve is the pharmacy organization user with Org3MSP.

With the organizations identified, we can define our Hyperledger Fabric network topology as shown in figure 7.2.

Figure 2-2. Hyperledger Fabric network topology

Since installing and deploying PLN in multiple physical nodes may not be within the scope of this chapter, we define one peer with four orgs, representing manufacturer, wholesaler, pharmacy and orderer node.

The channel plnchannel provides a private communications mechanism that will be used by orderer and the other three orgs to validate and execute the transaction.

PLN lifecycle

A piece of equipment with equipment id 2000.001 was made by a manufacturer on Jan 1, with equipment and other attributes and values as shown in Figure 2-17.3.

Transactions

In the PLN workflow section, we learned there are three steps in the entire lifecycle. Originated from the manufacturer, the equipment moves from wholesaler to pharmacy. As such, as a result of making an equipment, the wholesaler distributes and the pharmacy receives the transaction.

With all above design and analysis, we can now start to write our PLN smart contract.

Project Structure

To start our PLN smart contract development, first we need to create our smart contract project. Since we have three organizations, all peers must agree and approve of the new version of the smart contract which will be installed and deployed to the network. For our PLN, we will assume they are all the same.

We define a smart contract called pharmaledgercontract.js. The project structure shown in the figure 7.6:

Figure 2-6. Placeholder caption

package.json define two most important fabric libraries:

    "dependencies": {
        "fabric-contract-api": "^2.1.2",
        "fabric-shim": "^2.1.2"
    },

The fabric-contract-api provides the contract interface. It has two critical classes that every smart contract needs to use -Contract and Context.

const { Contract, Context } = require('fabric-contract-api');

The Contract has beforeTransaction, afterTransaction, unknownTransaction and createContext methods which are all optional and overridable in subclass. The JavaScript explicit contract class name can be specified by using its superclass to initialize itself.

The Context class provides the transactional context for every transactional invocation. It can be overridden for additional application behavior to support smart contract execution.

Contract class

Our pharma ledger contract implementation will extend from default built-in contract class from fabric-contract-api lib. Let’s first define PharmaLedgerContract with a constructor. org.pln.PharmaLedgerContract gives a very descriptive name with a unique name space for our contract. The unique contract name space is important to avoid conflict when there are many contracts from different users and operations in a shared system.

const { Contract, Context } = require('fabric-contract-api');
class PharmaLedgerContract extends Contract {

    constructor() {
        super('org.pln.PharmaLedgerContract');
    }
}

Transaction logic

As we discussed, PharmaLedgerContract will need three business functions to move the equipment owner from manufacturer, to wholesaler and finally pharmacy.

async makeEquipment(ctx, manufacturer, equipmentNumber, equipmentName, ownerName) {
// makeEquipment logic
}
async wholesalerDistribute(ctx, equipmentNumber, ownerName) {
// wholesalerDistribute logic
}
async pharmacyReceived(ctx, equipmentNumber, ownerName) {
// pharmacyReceived logic
}

The manufacturer will be initialized and an equipment entry is created. As you will notice, these functions accept a context as default first parameter with equipment related arguments ( manufacturer, equipmentNumber, equipmentName, ownerName) from client input. When makeEquipment is called, the function expects four equipment attributes from the client and assigns it to new equipment.

async makeEquipment(ctx, manufacturer, equipmentNumber, equipmentName, ownerName){
        let dt = new Date().toString();
        const equipment = {
            equipmentNumber,
            manufacturer,
            equipmentName,
            ownerName,
            previousOwnerType: 'MANUFACTURER',
            currentOwnerType: 'MANUFACTURER',
            createDateTime: dt,
            lastUpdated: dt
        };
await ctx.stub.putState(equipmentNumber, Buffer.from(JSON.stringify(equipment)));
}

At the end of makeEquipment , ctx.stub.putState will store the equipment initial state value with the equipment number key on the ledger. The equipment JSON data will be stringified using JSON.stringify, then converted to a buffer. The buffer conversion is required by the shim API to communicate with the peer.

The function uses JavaScript new Date() to get current date time and assigned to lastUpdated date time. When transaction data is submitted, each peer will validate and commit a transaction.

After the equipment record was created by the manufacturer, the wholesaler and pharmacy will just need to update ownership to track the current owner. Both functions are very similar.

async wholesalerDistribute(ctx, equipmentNumber, ownerName) {
        const equipmentAsBytes = await ctx.stub.getState(equipmentNumber);
        if (!equipmentAsBytes || equipmentAsBytes.length === 0) {
            throw new Error(`${equipmentNumber} does not exist`);
        }
        let dt = new Date().toString();
        const strValue = Buffer.from(equipmentAsBytes).toString('utf8');
        let record;
        try {
            record = JSON.parse(strValue);
            if(record.currentOwnerType!=='MANUAFACTURER') {
  throw new Error(` equipment - ${equipmentNumber} owner must be MANUAFACTURER`);
            }
            record.previousOwnerType= record.currentOwnerType;
            record.currentOwnerType = 'WHOLESALER';
            record.ownerName = ownerName;
            record.lastUpdated = dt;
       } catch (err) {
          throw new Error(`equipmet ${equipmentNumber} data can't be processed`);
       }
   await ctx.stub.putState(equipmentNumber, Buffer.from(JSON.stringify(record)));
   }

In the wholesalerDistribute function, we query current equipment ledger data by calling ctx.stub.getState(equipmentNumber). Once data returns, we need to make sure equipmentAsBytes is not empty and equipmentNumber is a valid number. Since ledger data is JSON string byte format, it needs to convert encoded data to a readable JSON format by using Buffer.from().toString('utf8'). We then verify if the current equipment owner type is the manufacturer using the returned data. Once all these conditions are met, ctx.stub.putState is called again. The equipment owner state would be updated to the wholesaler with the current timestamp. But as an immutable transaction log, all historical changes of the world state will permanently store in the ledger. We will define the queryHistoryByKey function to query all these data in the next step.

The pharmacyReceived function is very similar to wholesalerDistribute, so it needs to validate if the current owner is wholesaler and then transfer ownership to pharmacy before updating the equipment record.

         if(record.currentOwnerType!=='WHOLESALER') {
               throw new Error(` equipment - ${equipmentNumber} owner must be WHOLESALER`);
            }
            record.previousOwnerType= record.currentOwnerType;
            record.currentOwnerType = 'PHARMACY';

Query the ledger

After we implement all three equipment business functions, the ledger still needs a query function to search current equipment data and a query history function to get all of historical records.

ChaincodeStub is implemented by the fabric-shim library and provides GetState, GetHistoryForKey functions. In our case, the query definition is straightforward: we just need to call ctx.stub.getState to get the corresponding result.

GetHistoryForKey returns all historical transaction key values across time, we can iterate through these records and convert it to JSON byte and send the data back as a response. The timestamp tells us when the equipment state was updated. Each record contains a related transaction ID and a timestamp.

async queryHistoryByKey(ctx, key) {
      let iterator = await ctx.stub.getHistoryForKey(key);
      let result = [];
      let res = await iterator.next();
      while (!res.done) {
        if (res.value) {
          const obj = JSON.parse(res.value.value.toString('utf8'));
          result.push(obj);
        }
        res = await iterator.next();
      }
      await iterator.close();
      console.info(result);
      return JSON.stringify(result);
  }  

That is all for the smart contract function we will implement for our PLN. Next, we will see how to compile and deploy fabric chaincode.

Prerequisites

Before advancing any further we need to install the following third-party tools:

• Linux (Ubuntu)

• Git (https://git-scm.com)

• cURL (https://curl.haxx.se/)

• Docker and Docker Compose: Docker version 17.06.2-ce or greater is required.

• Go Language: Go version 1.14.x

• Node.js Runtime and NPM: Node.js version 8 is supported (from 8.9.4 and higher). Node.js version 10 is supported (from 10.15.3 and higher).

To set up a network, we will create an organization using the Fabric cryptogen tool, then create a consortium, and bring up PLN docker-compose. Let’s first set up our project.

Project structure

We have defined all set up scripts and configuration files for our PLN project, the source code can be found in the book Github page. The project structure is organized as shown in the figure 7.7.

Let’s take a look at important configurations:

Organizations:
    - &OrdererOrg
        Name: OrdererOrg
        ID: OrdererMSP
        MSPDir: ../organizations/ordererOrganizations/example.com/msp
        Policies:
           ....
        OrdererEndpoints:
            - orderer.example.com:7050
    - &Org1
        Name: Org1MSP
        ID: Org1MSP
        MSPDir: ../organizations/peerOrganizations/org1.example.com/msp
        Policies:
...
        AnchorPeers:
            - Host: peer0.org1.example.com
              Port: 7051
- &Org2
        AnchorPeers:
            - Host: peer0.org2.example.com
              Port: 9051
- &Org3
        AnchorPeers:
            - Host: peer0.org3.example.com
              Port: 11051

Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org2MSP.peer')"     

Profiles:
    PharmaLedgerOrdererGenesis:
        <<: *ChannelDefaults
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Consortiums:
            PharmaLedgerConsortium:
                Organizations:
                    - *Org1
                    - *Org2
                    - *Org3
    PharmaLedgerChannel:
        Consortium: PharmaLedgerConsortium
        <<: *ChannelDefaults
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
                - *Org3
            Capabilities:
                <<: *ApplicationCapabilities

services:
  orderer.example.com:
    container_name: orderer.example.com
    image: hyperledger/fabric-orderer:$IMAGE_TAG
    environment:..
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric
    command: orderer
    volumes:..
    ports:
      - 7050:7050
    networks:
      - pln

  peer0.org1.example.com:
    container_name: peer0.org1.example.com
    image: hyperledger/fabric-peer:$IMAGE_TAG
    environment:
      - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_pln
..
      - CORE_PEER_ADDRESS=peer0.org1.example.com:7051
      - CORE_PEER_LISTENADDRESS=0.0.0.0:7051
      - CORE_PEER_CHAINCODEADDRESS=peer0.org1.example.com:7052
      - CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052
      - CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
      - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051
      - CORE_PEER_LOCALMSPID=Org1MSP
    volumes:
...
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
    command: peer node start
    ports:
      - 7051:7051
    networks:
      - pln

OrdererOrgs:
  - Name: Orderer
    Domain: example.com
    EnableNodeOUs: true
    Specs:
      - Hostname: orderer
        SANS:
          - localhost

PeerOrgs:
  - Name: Org1
    Domain: org1.example.com
    EnableNodeOUs: true
    Template:
      Count: 1
      SANS:
        - localhost
    Users:
      Count: 1

Install Binaries, and Docker Images

We have reviewed important configurations in order to run the PLN network. net-pln.sh is a script to bring up the PLN network. We first need to download and install Fabric binaries to your system. Under the root project folder, there is a file called loadFabric.sh. Run the below command to load Fabric binaries and configs:

./loadFabric.sh

It will install the Hyperledger Fabric platform-specific binaries and config files into the /bin and /config directories under the project. The version we use for this project is the current latest production releases - Fabric v2.1.0 and Fabric CA v1.4.7. Run ‘docker images -a’ to check installed Fabric images.

It is now time to start our PLN network.

Start the PLN network

As we mentioned before, to start the PLN network, we need:

Generate Orderer Org Identities and peer certificates by cryptogen tool.

Here is command for org1:

cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output="organizations"

The generated output will be stored under the organizations folder.

Create Orderer Org Identities by cryptogen tool.

cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output="organizations"

Generate Common Connection Profile (CCP) for Org1, Org2 and Org3

./organizations/ccp-generate.sh

ccp-generate.sh is under the organizations folder. It uses ccp-template.json and ccp-template.yaml files as template, passing org name, peer port, CA port and CA PEM certificates to generate orgs connection files. And ccp-generate.sh copy generated connection files to peer orgs folder:

echo "$(json_ccp $ORG $P0PORT $CAPORT $PEERPEM $CAPEM)" > organizations/peerOrganizations/org1.example.com/connection-org1.json
echo "$(yaml_ccp $ORG $P0PORT $CAPORT $PEERPEM $CAPEM)" > organizations/peerOrganizations/org1.example.com/connection-org1.yaml

These connection files will be used by each peer web client to connect to the Fabric network.

Create consortium and generate an orderer system channel genesis block.

configtxgen -profile PharmaLedgerOrdererGenesis -channelID system-channel -outputBlock ./system-genesis-block/genesis.block

configtxgen reads configtx.yaml profile and generates the genesis.block file under the system-genesis-block folder.

Bring up the peer and orderer nodes

The docker composer file is defined under docker/docker-compose-pln-net.yaml. The command will pull the latest Fabric oderer and peer images, builds the orderer and peers images, and starts the services we defined in the yaml file. Run the below docker compose command to bring up the peer and orderer nodes:

IMAGE_TAG=$IMAGETAG docker-compose ${COMPOSE_FILES} up -d 2>&1

Now, let’s bring up the PLN network. Open a terminal window and run net-pln.sh under the pharma-ledger-network folder:

cd pharma-ledger-network 
./net-pln.sh up

You should see below success log (shown in figure 7.8):

We have 4 organizations including three peers and one orderer that are running in net_pln network. In the next step, we will use the script to create a PLN channel for all orgs.

Monitor the PLN network

The Fabric images in the PLN network are Docker based. During project development or production lifecycle, you may encounter many errors. For troubleshooting the code, log monitoring is definitely one of the most important things to do from a DevOps standpoint. It will help troubleshoot and find the root cause much easier and faster. Logspout is an open source container log tool for monitoring Docker logs. It collects Docker’s logs from all nodes in your cluster to be aggregated into one place. In our PLN project, we will use Logspout to monitor channel creation, smart contracts installation and others actions. Navigate to the pharma-ledger-network folder, open a new terminate window.

cd pharma-ledger-network

run the following command from the net-pln.sh script and start the logspout tool for the containers running on the PLN network net_pln:

./net-pln.sh monitor-up

...
Starting docker log monitoring on network 'net_pln'
Starting monitoring on all containers on the network net_pln
Unable to find image 'gliderlabs/logspout:latest' locally
latest: Pulling from gliderlabs/logspout
cbdbe7a5bc2a: Pull complete
956fa3cf18b6: Pull complete
94f24e0675e0: Pull complete
Digest: sha256:872555b51b73d7f50726baeae8d8c138b6b48b550fc71d733df7ffcadc9072e1
Status: Downloaded newer image for gliderlabs/logspout:latest
e8a8ad1787b69cfb7387264ee6ff63fd5a805aabe50ca6af6356d4cd8b27e052

here is script logic to bring logsprout tool up, it pulls gliderlabs/logspout images by passing theLN network name.

docker run -d --name="logspout" 
   --volume=/var/run/docker.sock:/var/run/docker.sock 
   --publish=127.0.0.1:${PORT}:80 
   --network  ${DOCKER_NETWORK} gliderlabs/logspout

This terminal window will now show the PLN network containers output for the remainder of the project development.

Creating PLN channel

In the process of creating the channel, we will use the configtxgen CLI tool to generate a genesis block and then we use per channel commands to join a channel with other peers. There are several steps for creating a PLN channel. All these script logic can be found in scripts/createChannel.sh.

First, Generate a channel configuration transaction file

In the createChannel.sh script, we define the createChannelTxn function. The critical command in this function is below:

configtxgen -profile PharmaLedgerChannel -outputCreateChannelTx ./channel-artifacts/${CHANNEL_NAME}.tx -channelID $CHANNEL_NAME

configtxgen tool reads the profile PharmaLedgerChannel section from configtx.yaml, which defines channel related configuration to generate the transaction and genesis block. And then generates plnchannel.tx file.

Second, Create an AncorPeer configuration transaction file.

we define the createAncorPeerTxn function. Similar to the previous step, we have defined the different organizational identities in configtx.yaml. configtxgen reads PharmaLedgerChannel organizational configuration and generates peer configuration transaction files.

configtxgen -profile PharmaLedgerChannel -outputAnchorPeersUpdate ./channel-artifacts/${orgmsp}anchors.tx -channelID $CHANNEL_NAME -asOrg ${orgmsp}

After createAncorPeerTxn runs, we should see Org1MSPanchors.tx, Org2MSPanchors.tx and Org3MSPanchors.tx transaction files generated.

Third, Create channel using peer channel command. The createChannel function uses ‘peer channel create’ command to create our PLN channel. When the command is issued, it will submit the channel creation transaction to the ordering service. Ordering service will check channel creation policy permissions defined in configtx.yaml. Only admin users can create a channel. setGlobalVars() in scripts/utils.sh will allow us to set peer organization as the admin user. We use org1 as an admin to create our channel.

The create a channel commands are as follow:

setGlobalVars 1
peer channel create -o localhost:7050 -c $CHANNEL_NAME --ordererTLSHostnameOverride orderer.example.com -f ./channel-artifacts/${CHANNEL_NAME}.tx --outputBlock ./channel-

setGlobalVars() in scripts/utils.sh has the following logic for setting org1 as an admin user. We can also use this function to set other peer orgs as admin users.

setGlobalVars() {
..
  if [ $USING_ORG -eq 1 ]; then
    export CORE_PEER_LOCALMSPID="Org1MSP"
    export CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA
    export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=localhost:7051
..
}

Once the channel is created, we will join peers to the channel.

Fourth, Join all the peers to the channel. After our PLN channel has been created, we can join all peers into this channel. joinMultiPeersToChannel in createChannel.sh script will join all three peer orgs into our PLN channel by running ‘peer channel join’ command:

for org in $(seq 1 $TOTAL_ORGS); do
  setGlobalVars $ORG 
  peer channel join -b ./channel-artifacts/$CHANNEL_NAME.block >&log.txt
done

When peer orgs join a channel, they need to be assigned as admin users by calling the setGlobalVars  function by passing $ORG parameter. Peer channel join command will use genesis.block to join peer orgs to the channel. Once the peer is joined to the channel, it can attend channel ledger block creation when receiving ordering service transaction submission.

Fifth, update AncorPeer for peers.As the last step in the channel creation process, we need to select at least one peer as an anchor peer. An anchor peer’s main role is private data and service discovery. The endpoints of the anchor peer are fixed, other peer nodes belonging to different members can communicate with the anchor peers to discover all existing peers on a channel. To update an anchor peer, we set a selected peer as an admin user and issue peer channel update’ command.

setGlobalVars $ORG
peer channel update -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com -c $CHANNEL_NAME -f ./channel-artifacts/${CORE_PEER_LOCALMSPID}anchors.tx --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA >&log.txt

You can use net-pln.sh script to create the PLN channel by run below command:

./net-pln.sh createChannel

Once channel creation completed, you should see below log:

...

***** [Step: 5]: start call updateAnchorPeers 3 on peer: peer0.org3, channelID: plnchannel, smartcontract: , version , sequence  *****
Using organization 3
2020-06-06 03:24:36.333 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2020-06-06 03:24:36.392 UTC [channelCmd] update -> INFO 002 Successfully submitted channel update
***** completed call updateAnchorPeers, updated peer0.org3 on anchorPeers on channelID: plnchannel, smartcontract: , version , sequence  *****

***** completed call updateOrgsOnAnchorPeers, anchorPeers updated on channelID: plnchannel, smartcontract: , version , sequence  *****

========= Pharma Ledger Network (PLN) Channel plnchannel successfully joined ===========

To see the related container information, you can check the log sprout terminal window which we opened earlier.

Testing smart contract

We have created invokeContract.sh for this project. It defines an invocation method for makeEquipment, wholesalerDistribute, pharmacyReceived and query function.

We first call makeEquipment chaincode method:

./net-pln.sh invoke equipment GlobalEquipmentCorp 2000.001 e360-Ventilator GlobalEquipmentCorp 

We pass manufacturer, equipmentNumber, equipmentName and ownerName as arguments. The script basically calls peer chaincode invoke commands by passing related function arguments.

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n ${CHINCODE_NAME} $PEER_CONN_PARMS  -c '{"function":"makeEquipment","Args":["'$manufacturer'","'$equipmentNumber'", "'$equipmentName'", "'$ownerName'"]}' >&log.txt

You will see the logs like the below:

invokeMakeEquipment--> manufacturer:GlobalEquipmentCorp, equipmentNumber:2000.001, equipmentName: e360-Ventilator,ownerName:GlobalEquipmentCorp
+ peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile /home/ubuntu/Hyperledger-Fabric-V2/chapter7-supplychain/pharma-ledger-network/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C plnchannel -n pharmaLedgerContract --peerAddresses localhost:7051 --tlsRootCertFiles /home/ubuntu/Hyperledger-Fabric-V2/chapter7-supplychain/pharma-ledger-network/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles /home/ubuntu/Hyperledger-Fabric-V2/chapter7-supplychain/pharma-ledger-network/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt --peerAddresses localhost:11051 --tlsRootCertFiles /home/ubuntu/Hyperledger-Fabric-V2/chapter7-supplychain/pharma-ledger-network/organizations/peerOrganizations/org3.example.com/peers/peer0.org3.example.com/tls/ca.crt -c '{"function":"makeEquipment","Args":["GlobalEquipmentCorp","2000.001", "e360-Ventilator", "GlobalEquipmentCorp"]}'
2020-06-06 03:43:09.186 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 001 Chaincode invoke successful. result: status:200

After invoking makeEquipment, we can run a query function to verify the ledger result. The query function uses peer chaincode query command

  peer chaincode query -C $CHANNEL_NAME -n ${CHINCODE_NAME} -c '{"function":"queryByKey","Args":["'$QUERY_KEY'"]}' >&log.txt

Then, issue the following script command to query equipment

./net-pln.sh invoke query 2000.001

The query should return current equipment state data.

{"Key":"2000.001","Record":{"equipmentNumber":"2000.001","manufacturer":"GlobalEquipmentCorp","equipmentName":"e360-Ventilator","ownerName":"GlobalEquipmentCorp","previousOwnerType":"MANUAFACTURER","currentOwnerType":"MANUAFACTURER","createDateTime":"Sat Jun 06 2020 03:43:09 GMT+0000 (Coordinated Universal Time)","lastUpdated":"Sat Jun 06 2020 03:43:09 GMT+0000 (Coordinated Universal Time)"}}

Continue to invoke remaining equipment functions for wholesaler and pharmacy.

./net-pln.sh invoke wholesaler 2000.001 GlobalWholesalerCorp
./net-pln.sh invoke pharmacy 2000.001 PharmacyCorp

Once equipment ownership is moved to pharmacy, the supply chain reaches its final state. We can issue queryHistoryByKey from the peer chaincode query command. Let’s check equipment historical data.

./net-pln.sh invoke queryHistory 2000.001

We can see the below output in the terminal:

***** start call chaincodeQueryHistory on peer: peer0.org1, channelID: plnchannel, smartcontract: pharmaLedgerContract, version 1, sequence 1 *****
+ peer chaincode query -C plnchannel -n pharmaLedgerContract -c '{"function":"queryHistoryByKey","Args":["2000.001"]}'
[{"equipmentNumber":"2000.001","manufacturer":"GlobalEquipmentCorp","equipmentName":"e360-Ventilator","ownerName":"PharmacyCorp","previousOwnerType":"WHOLESALER","currentOwnerType":"PHARMACY","createDateTime":"Sat Jun 06 2020 03:43:09 GMT+0000 (Coordinated Universal Time)","lastUpdated":"Sat Jun 06 2020 03:48:48 GMT+0000 (Coordinated Universal Time)"},{"equipmentNumber":"2000.001","manufacturer":"GlobalEquipmentCorp","equipmentName":"e360-Ventilator","ownerName":"GlobalWholesalerCorp","previousOwnerType":"MANUAFACTURER","currentOwnerType":"WHOLESALER","createDateTime":"Sat Jun 06 2020 03:43:09 GMT+0000 (Coordinated Universal Time)","lastUpdated":"Sat Jun 06 2020 03:46:41 GMT+0000 (Coordinated Universal Time)"},{"equipmentNumber":"2000.001","manufacturer":"GlobalEquipmentCorp","equipmentName":"e360-Ventilator","ownerName":"GlobalEquipmentCorp","previousOwnerType":"MANUAFACTURER","currentOwnerType":"MANUAFACTURER","createDateTime":"Sat Jun 06 2020 03:43:09 GMT+0000 (Coordinated Universal Time)","lastUpdated":"Sat Jun 06 2020 03:43:09 GMT+0000 (Coordinated Universal Time)"}]
***** completed call chaincodeQuery, Query History successful on channelID: plnchannel, smartcontract: pharmaLedgerContract, version 1, sequence 1 *****

All of the transaction history records are displayed as output. We have tested our smart contract and it works as expected.