:warning: :warning: :warning: Hyperledger Composer has been deprecated :warning: :warning: :warning:
⚠️ ⚠️ ⚠️
As of the 29th August 2019, the Hyperledger Composer project is in deprecated status. None of the maintainers are actively developing new features. None of the maintainers are actively providing support via GitHub issues. However, if you wish to submit code changes via pull requests, these will be merged.
It is highly recommended that you use Hyperledger Fabric v1.4+ instead, which features significant improvements to the developer experience, including a new programming model.
More information available here: What's new in Hyperledger Fabric v1.4
⚠️ ⚠️ ⚠️
This release contains no changes, but is being used to publish warnings to the playground and documentation to inform users of the projects deprecation.
Hyperledger Fabric supports the ability to upgrade your version of fabric. However if you were running Hyperledger Fabric 1.1 and wanted to upgrade to a newer level of fabric, which requires Composer 0.20, it was not possible to upgrade to this level of Composer. You would have to find a way to start fresh and reload your data as you could not upgrade your business network to use Composer 0.20.
This release of Composer has removed the restriction to allow users to be able to upgrade their Hyperledger Fabric 1.1 version to a newer version of Hyperledger Fabric, then be able to upgrade your business network to use the Composer 0.20 runtime. To upgrade you should use version 0.20.8 of the composer-cli to perform the upgrade and you should also remove any Composer dependencies that might exist in your package.json of your BNA. You should also update your client applications to use version 0.20.8 of the Composer sdks and/or also upgrade to using 0.20.8 of the Composer Rest Server.
This capability is being added to make it easier for people to first upgrade to Hyperledger Fabric 1.4 then work on porting their composer application to the new programming models now available in Hyperledger Fabric 1.4.
⚠️Do NOT upgrade your version of Composer to 0.20 if you are running Hyperledger Fabric 1.1 and plan to remain at Hyperledger Fabric 1.1. Composer 0.20 is not compatible ⚠️Once you have upgraded, you CANNOT downgrade to Composer 0.19 even if you can downgrade Hyperledger Fabric back to 1.1. You cannot revert the Composer version change.
⚠️ 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:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
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.
🔬 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"
}
⚠️ 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:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
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.
🔬 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/v0.19.x/packages/composer-connector-hlfv1/lib/hlfconnection.js and https://github.com/hyperledger/composer/blob/v0.19.x/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"
}
⚠️ 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:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
Welcome to Hyperledger Composer v0.20.6, which comes with some bug fixes. Also we can confirm the Composer v0.20 can be used with hyperledger fabric 1.4.0. It doesn't exploit any features of this release but does tolerate it. As hyperledger fabric 1.4 is the last version of hyperledger fabric v1, this is the last version of fabric the composer will support. Composer will not support the next major release of hyperledger fabric.
🐞 #4565 Upgrade to latest fabric-shim to address identified fields not allowing non-ascii characters 🐞 #4566 Improve Resource Validator to reject numerical fields which don't contain numbers 🐞 #4480 Ensure logging files are flushed for CLI
⚠️ 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:
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:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
Welcome to Hyperledger Composer v0.20.5, which comes with some logging and bug fixes, to help keep you all Composing. Also we can confirm the Composer v0.20 can be used with hyperledger fabric 1.3.0. It doesn't exploit any features of this release but does tolerate it.
🐞 #4532 Fixes an issue where a websocket client can terminate the rest server 🐞 #4536 Fixes the logging of transaction ids for the performance (verbose) logging in chaincode 🐞 #4539 Corrects the cloud wallets documentation 🐞 #4542 Removes old information from the rest server readme as seen on npm 🐞 #4523 Minor improvements to chaincode logging 🐞 #4525 Clarify node versions in documentation (Thanks to @doowb ) 🐞 #4529 Fabric client initialize channel always uses the first peer (Thanks to @volodyad )
⚠️ 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:
⚠️ There are multiple support splits across differing Fabric levels, so please be careful with what versions are being used:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
Welcome to Hyperledger Composer v0.19.19, which comes with some logging and functional updates, to help keep you all Composing. Also we can confirm the Composer v0.20 can be used with hyperledger fabric 1.3.0. It doesn't exploit any features of this release but does tolerate it.
🐞 #4531 Fixes an issue where a websocket client can terminate the rest server 🐞 #4535 Fixes the logging of transaction ids for the performance (verbose) logging in chaincode 🐞 #4538 Corrects the cloud wallets documentation 🐞 #4522 Minor improvements to chaincode logging
⚠️ 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:
⚠️ There are multiple support splits across differing Fabric levels, so please be careful with what versions are being used:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
Welcome to Hyperledger Composer v0.20.4, which comes with some logging and bug fixes, to help keep you all Composing.
🐞 #4502 fix prereqs-ubuntu.sh script on the latest docs page 🐞 #4500 Allow txid to be passed on query transactions for logging
⚠️ 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:
⚠️ There are multiple support splits across differing Fabric levels, so please be careful with what versions are being used:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
If you are new to Conga Comics, then you can view the complete Conga Comic collection at https://congacomic.github.io/
Welcome to Hyperledger Composer v0.20.3, which comes with some logging and functional updates, to help keep your Composer experience as hyperlegendary as possible.
✨ #4477, #4492 New implementation for handling transaction events around notification of transaction commits
🐞 #4470, #4471 improve docs about TLS for CA on connection profile (thanks to @bjrnt) 🐞 #4490 fix version of loopback-datasource-juggler as new release broke composer rest server 🐞 #4487 upgrade to fabric-shim 1.2.3 to fix problems with Peer issuing GOAWAY and terminating chaincode 🐞 #4482 Update docs around business network reset usage
⚠️The new event handler capability changes how composer notifies client applications (and this includes the composer rest server, composer playground and the composer cli as they are client applications themselves) as to when the transaction has been committed/rejected. Previous releases allowed a transaction to be submitted but if it was not possible to determine whether that transaction was committed/rejected due to no event hub connections, it would just return a successful message to indicate successful submission only. The new event handler mechanism now will reject any attempt to submit a transaction if it has no connected event hubs as it will not be able to determine the final state of the transaction. It will also throw an error if during the process of submission it is not able to determine if the transaction was committed or was rejected due to loss of connection to the event hubs.
⚠️ If using the Composer tooling to create a Hyperledger Fabric development server, this will now be creating a v1.2.0 server by default. If you are using a different level of Composer, you will need to set the relevant environment variable via export FABRIC_VERSION=hlfvXX when using the Hyperledger Fabric development servers provided by Composer:
⚠️ There are multiple support splits across differing Fabric levels, so please be careful with what versions are being used:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
If you are new to Conga Comics, then you can view the complete Conga Comic collection at https://congacomic.github.io/
Welcome to Hyperledger Composer v0.19.18, which comes with some logging and functional updates, to help keep you all Composing.
🐞 #4503 fix prereqs-ubuntu.sh script on the 0.19.x docs page 🐞 #4499 Allow txid to be passed on query transactions for logging 🐞 #4497 Backport of client side performance logging from 0.20 🐞 #4483 Highlight dangers of network reset
⚠️ 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:
⚠️ There are multiple support splits across differing Fabric levels, so please be careful with what versions are being used:
⚠️ The is a change in the business network lifecycle administration, and business network card commands between v0.18.2 and v0.19.0
If you are new to Conga Comics, then you can view the complete Conga Comic collection at https://congacomic.github.io/