We look at telemetry every day to identify issues that affect our customers, and as a result made some changes to make deploying Workbench not only more reliable, but faster as well.
Continuing from the monitoring improvements we made as part of 1.1.0, we’ve made reliability improvements to the DLT Watcher and DLT Consumer microservices (see the Blockchain Workbench architecture document for more information on those components). Practically speaking, you’ll notice fewer errors saying “It looks like something went wrong…”.
With release 1.2.0 you could deploy Workbench and connect that deployment to an existing Ethereum-based network. This past week we announced the availability of a new standalone Ethereum PoA solution, which can be deployed across members within a consortium. With these two updates, you can deploy Workbench in three different configurations:
-
**Single-Member System:** The default configuration of Workbench, where Workbench is deployed in a blockchain network with only one member.
-
**Multi-Member System Deployed in One Member’s Subscription:** You can use the new multi-member PoA consortium solution to deploy a blockchain network across several members. The, you can deploy Workbench in one member’s subscription. Everyone who wants to use Workbench will go through the one member’s Workbench deployment. This topology can be useful for PoCs and initial pilot deployments.
-
**Multi-Member System Deployed in One Shared Subscription:** This configuration is similar to the topology described above, except that Workbench is deployed in a shared subscription. Think of this shared subscription as the operator subscription for the consortium.
We are investigating other topologies, such as one where Workbench is deployed into each subscription. If that interests you, please upvote or request it on our blockchain user voice.
We know going through Workbench deployment instructions can feel like a lot of work, especially setting up AAD and registering an app for the Workbench API. To make things easier, we’ve created a new PowerShell script, which automates most of the AAD setup steps and outputs the parameters you need for Workbench deployment. You can find the instructions and the script on our GitHub.
Some of you have asked for more sample code and tools related to generating authentication bearer tokens for Workbench API. We’re excited to announce a new tool, which you can use to generate tokens for your Workbench instance. Source code is also available and can be used to create your own client authentication experience. Try it out by cloning the repo, running the Web page, and plugging in your Application Id.
