Smart Contract Developer Guide

NIMBLE Logistic Chain Code

Chain Code Structure:

The NIMBLE Logistic Contract Chain Code includes two Smart Contracts that work in parallel:

  1. Logistic Contract:- Handles the logistic process of a dispatched order from the business process service
  2. Identity Contract:- Manages identities of platform users from peer organizations (NIMBLE, EFPF).

Roles

There are set of predefined roles in NIMBLE, which are also used in the NIMBLE Logistic Contract Chain Code:

  1. PLATFORM_MANAGER :- Owners of the platform
  2. NIMBLE_USER :- NIMBLE platform user
  3. PUBLISHER :- Service or Product Provider in the NIMBLE platform
  4. PURCHASER :- Service or Product Purchaser in the NIMBLE platform.

Logistic Contract

The NIMBLE Logistic Contract defines features of a dispatched order, including the users involved in a logistic workflow.

The users with the PUBLISHER role can initiate logistic processes. The user PUBLISHER provides a list of organizations (organisation IDs) involved in the logistic process, which must be registred either in the NIMBLE or EFPF platform.

Once a logistic process is initiated, users involved in the logistic process can change the custodian of the current purchase order. These users are agreed upon at the start of the logistic process.

The data related to a blockchain persisted logistic process can be retrieved only by the egreed users or platform owners.

The logistic process can be deleted from the ledger by platform owners, only after the deletion is requested by 1 or more users.

Identity Contract

Identity contract manages the identities that are registered in both platforms, EFPF and NIMBLE.

In case of data loss, these identities are used to recreate the certificates which are required for the BlockChain client in order to connect with the Chain Code.

The Identity Contract has the user’s roles and organisation IDs which corresponds to those defined in NIMBLE and EFPF platforms.

These Identities can be deleted by the users or the platform manager that are defined in the NIMBLE Logistic Contract.

The Identity Contract is coupled with the Logistic Contract.

Testing

To test the Chain Code locally, the application should be deployed in the test-network

Test methods

Both the NIMBLE Logistic Contract and the Identity Contract include test methods for contract verification, which is helpful when working with the CLI.

1. In Logistic Contract :- InitLedger Method
How to invoke in test-network in Hyperledger Fabric
peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n logistic-contract --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"InitLedger","Args":[]}'
2. In Identity Contract :- initIdentityLedger Method
How to invoke in test-network in Hyperledger Fabric
peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n logistic-contract --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"initIdentityLedger","Args":[]}'

Extensions to other use cases.

It shlould be easy to extend the application use to other use cases, since the main functionalities required to perform transactions in the ledger are abstracted out.

Ledger API.

Smart Contracts are written using Hyperledger Fabric Contract API 2.0.0.

Single State Operations

Common Operations for supported class types used for a single instance in the ledger are defined in the State class.

Collection Operations

The following common operations in the ledger:

  1. Add State
  2. Get State
  3. Get History
  4. Delete State
  5. Update State

are defined in the StateList Class.

Context of the Chaincode.

The single Context point for the Chain Code is defined in the NimbleLogisticContext class.

It creates new collections of types for Smart Contracts. To cretae customized lists, the Contract Object Type needs to be passed as Parameter to the list initialization method.

Type Conversion

Note this project requires types in order to perform operations.

To convert objects to Contract Object Types use the pick function, which handles any type of conversion. Static methods should be defined in the Contract Object Class.

Scaffolded with

The basic skeleton is a scaffold of the Yeoman generator for Hyperledger Fabric, provided by IBM BlockChain Team. https://github.com/IBM-Blockchain/generator-fabric

Special Thanks to the IBM BlockChain Team.

Previous
Next