Composer v0.20.7

At this point in time, there will be no further releases for Composer, here are some experimental features that were put into composer during it's development. They are experimental because they may not have full automated testing, samples, are undocumented and could still have bugs, but we just wanted to ensure the community knew about them.

Experimental Features

🔬 Ability to disable the Historian. It is possible to disable the use of the Historian when using business networks. The Historian is enabled by default, in order to disable it a flag is required in the business network package.json. The required flag is "disableHistorian": true. Whilst the registry for the Historian will still be created, no Historian records will be added to it during the execution of transaction processor functions. 🔬 Ability to run readonly transactions. The new model decorator, @readonly, on transaction processor functions enables the ability to shortcut the return of a readonly transaction. This would be the case if you are executing a native API chaincode query, and want to return the unmodified Assets returned by this query. Note that if you retrieve Assets and subsequently modify them within the transaction, the original format will be returned. 🔬 Ability to provide your own query handlers for client applications. the inbuilt query handler would only ever query the same peer in your organisation unless that peer was unavailable then it would look for another peer. This capability allows you to provide your own handler, for example one that performs round robin around multiple peers in your organisation to spread the load. Due to no documentation you would need to look at the source code to work out how to write and supply your own handler. See https://github.com/hyperledger/composer/blob/master/packages/composer-connector-hlfv1/lib/hlfconnection.js and https://github.com/hyperledger/composer/blob/master/packages/composer-connector-hlfv1/lib/hlfqueryhandler.js. 🔬 Ability to change the chaincode version at business network install time. A Peer will route all requests to a business network with the same name and version to a single chaincode container for all channels. If you have lots of channels with the same business network at the same version this could cause a bottleneck in the chaincode container. If you install the same business network but with a slightly different version number for each channel then the peers will have their own chaincode containers allowing the load to be spread. This is available via the -o option of the install command. An example of it’s use is

composer network install -c PeerAdmin@hlfv1 -a ~/bn-dev/trade-network.bna -o chaincodeVersion=1.45.5-channel1

🔬 A Composer Runtime simulator. Wouldn't it be great if you could have an environment that looked like a fabric network and responded like a fabric network but was really fast ? For example you could use the CLI to install a business network, start and business network and upgrade a business network really quickly and also run the rest server ? This capability exists. If you run playground locally then the simulator is already running. If you don't run playground locally then to run the simulator server you would npm install -g composer-connector-server then run it by typing composer-connector-server. Once you have the simulator running, you just need an appropriate connection profile

{
    "name": "simulator",
    "x-type": "embedded@proxy",
    "version": "1.0.0"
}

Notes

⚠️ If using the Composer tooling to create a Hyperledger Fabric development server, this will now be creating a v1.2.1 server by default. If you are using a different level of Composer v0.16.x, you will need to set the relevant environment variable via export FABRIC_VERSION=hlfvXX when using the Hyperledger Fabric development servers provided by Composer:

hlfv1 for Fabric v1.0
hlfv11 for Fabric v1.1
hlfv12 for Fabric v1.2

The fabric-dev-servers package provided is meant only as a simple hyperledger fabric setup to help you get started with developing with composer using a real fabric. It is not meant to be extended or as a basis for a custom fabric. If you are wondering where versions for hyperledger fabric v1.3 or v1.4 are, these are explicitly not included because you can develop your application using the development fabric 1.2 and still be able to deploy and run it on a fabric 1.3 or 1.4 system.

⚠️ There are multiple support splits across differing Fabric levels, so please be careful with what versions are being used:

• 0.20.0 and above are compatible with the Fabric 1.2.0, 1.2.1, 1.3.0 and 1.4.x driver only
• v0.18.2, v0.19.0 and above are compatible with the Fabric 1.1.0 driver only
• v0.18.0 -> v0.18.1 are compatible with the Fabric RC1 driver only
• v0.17.3 -> v0.17.6 are compatible with Fabric alpha driver only
• v0.17.0 -> v0.17.2 are compatible with Fabric preview driver only

⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0