Installation of chaincode results in the copying of source code to the peers we have selected to be endorsers, and every installation is associated with a user-defined version. The main function installChaincode is implemented in install-chaincode.js. This function in turn calls the installChaincodeInOrgPeers function for each of the 4 organizations in sequence; the latter function installs chaincode on the peers of a given organization. As in the case of a channel join, we create both client and channel handles for a given organization, enroll an administrator user for that organization, and associate that user with the client handle. This next step is to create an installation proposal and submit it to the orderer as follows:

var request = {
  targets: targets,
  chaincodePath: chaincode_path,
  chaincodeId: Constants.CHAINCODE_ID,
  chaincodeVersion: chaincode_version
};
client.installChaincode(request);

The targets refer to the configurations of the endorsing peers in the organization, and are loaded from config.json. chaincodeId and chaincodeVersion can be set by the caller (and defaults are set in constants.js as tradecc and v0, respectively), but the chaincodePath must refer to a location that contains the source code. In our scenario, the location refers to a path on the local file system: github.com/trade_workflow.

Internally in the SDK, the installation request packages the chaincode’s source code into a prescribed format called ChaincodeDeploymentSpec (CDS)(https://github.com/hyperledger/fabric/blob/release-1.1/protos/peer/chaincode.proto). This package is then signed (by the organization administrator associated with the client object) to create a SignedChaincodeDeploymentSpec(https://github.com/hyperledger/fabric/blob/release-1.1/protos/peer/signed_cc_dep_spec.proto), which is then sent to the lifecycle system chaincode (LSCC) for installation.

The above procedure describes the simple case where each instance of a Signed CDS has only the signature of the identity associated with the client that issues the installation request. A more complex scenario is supported by Fabric whereby a CDS can be passed (out-of-band) to different clients (of the various organizations) and signed by each before the installation requests are received. The reader is encouraged to try out this variation using the available API functions and Fabric data structures(http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html).

The success of an installation request is determined by checking the proposal response from each target peer as follows:

if (proposalResponses && proposalResponses[i].response && proposalResponses[i].response.status === 200) {
  one_good = true;
  logger.info('install proposal was good'),
}

Finally, to orchestrate the installation on the entire network, we call the installChaincode function defined in install-chaincode.js. For the fabric-client to know where to load the chaincode source from, we temporarily set the GOPATH in the process to point to the right location in our project, which is the chaincode folder:

process.env.GOPATH = path.join(__dirname,Constants.chaincodeLocation);

For a successful installation, the chaincode folder must contain a subfolder named src, within which the chaincode path sent in the installation proposal must point to the actual code. As you can see, this finally resolves to chaincode/src/github.com/trade_workflow in our code repository, which indeed contains the source code we developed in Chapter 4, Designing a Data and Transaction Model with Golang.

In our createTradeApp.js script, we can now simply call:

var installCC = require('./install-chaincode.js'),
installCC.installChaincode(Constants.CHAINCODE_PATH, Constants.CHAINCODE_VERSION);