Before we can do that we must make sure we have an AD user configured as a Blockchain administrator to upload our Smart Contract and Workflow Configuration file into the workbench.  When we have done that, we must populate the participants of the Smart Contract with users, and assign them roles e.g.  Coffee farmer, Importer and so on, since each participant typically has a limited set of actions they can undertake which are defined by the contract. Only Blockchain administrator can perform this task.

When the above is completed we can log into the App Service URL that provides the Smart Contact configuration interface, this can be found in the App Service section of your Azure portal it’s the URL without the “–api” suffix. Clicking the URL field on the right of your app service dashboard will invoke a login page. On entering your Workbench administrator username and password you will be taken to a page like that in Figure 10;should this not happen check that the user account you entered has been properly configured.

In Figure 10 we have already populated the Workbench with several Blockchain applications, each running on our current Blockchain Instance. One of the applications is the ProductSupplychain demo which we created in Part 3. The other three are examples from the Blockchain Workbench git store.

To load new Blockchain applications select the “+ New” button then navigate to and load the Configuration Workflow file and the Smart Contract file, Figure 11. As the files are loaded the workbench runs validation on them to ensure they are syntactically correct. We have found in a number of cases, such as that shown in Figure 10, warnings can be ignored as they refer to non-critical issues. The files are uploaded and installed on the Blockchain network when you select the “Deploy” button. The Configuration Workflow file is used to create an interface defining the Workflow, participant Roles, actions and transitions which can be undertaken on the contract (Figures 12 to 13). The Smart Contract file is uploaded to the Blockchain network instance and configured on its nodes.

When all participants have been selected and their roles assigned, the Smart Contract can then be run. In our ProductSupplyChain example only a Producer can initiate the contract by offering a Product for sale. Once a Product has been defined, offered by the Producer and written in to the Block can it then be “Imported” by the participant whose role have been defined as an “Importer”. Other participant such as the Retailer and Processor cannot, at this stage, interact with the contract as there is nothing defined from them to do. These “rules and states” are specified in the Workflow file and used by the Workbench to enable/disable the UI to reflect these states for each role in the contract. The only other action that can be taken at this stage is for the Producer to remove or  terminate the contract on the Block.

Figures 14 to 15 show the stages taken by the Producer to add a product to the Blockchain via the application UI. First, they select “New Product”, which displays a UI containing all the named variables defined in the WorkFlow file based in turn on the Smart Contract. When these have been defined and the “Create” button selected (Figures 14 to 15) the data is stored in the SQL DB and sent to the Smart Contract to create the initial transaction. The processes typically take a few minutes (Figure 16) during which time the transaction is signed, encrypted and stored on-Block and then the off chain SQL DB store synchronized with these changes. We could at this point capture that event and send an email to interested Importers notifying them of a new or updated supply, together with its details e.g. cost, location, type amount and so on.

All relevant details of the transaction are stored (Figure 19) together with the users Blockchain address and the transaction Block number. At this point two possible events can occur as defined by the contract, an Importer can make an offer or the Producer can withdraw their offer.

So now we have a product for sale on the chain. The Shipper decides to make an offer, logs in, places their offer and it is committed to the block, as shown in Figure 20-21. Subsequently they decide to withdraw their offer (Figure 22), and at this point the product become available again.

A key feature of the Workbench and one of its main attractions is the ease with which it can access other components and services of the Azure platform, one of which is the IoT Hub.  For any goods supply chain quality control is critical and the ability to provide timely state information e.g. temperature, humidity and so on, a key requirement. If critical quality values are exceeded these details must be recorded, the product removed from the supply chain and the contract invalidated.  Information on location, status, ownership and so on can then be written to the Ledger and recorded for all to see.  In our simple example we provided a function call on the Smart contract allowing input of monitoring data, these input values can then be compared with those defined by the producer for quality control, if outside this range, the contact is invalidated and marked as out of compliance.

See the function discussed in Part 3:

UpdateReadings(int humidity, int temperature, int timeofreading) public

In Figure 23 we call the “UpdateReadings” function on to simulate the activation of a supply chain sensor device connected to the Azure IoT Hub which has been routed to the Service Bus that BlockChain Workbench has subscribed to. In this case we set the humidity value to be out of range. On receipt of the message the workbench forwards it to the on-Chain Ledger and updates the contract if the input data (sensor readings) is non-compliant which in this case it is. At this point other members of the supply chain can no longer update it, they will only “see” why and when the contract was marked as non–compliant. Since the contract is non-compliant it is marked as terminated and details of time, location and ownership will be recorded. The change of state e.g. to non-compliance, could be notified to participants via a variety of channels, email, SMS, push notification to a mobile and so on.

Summary

In Part 1 we described our experience as developers building a simple Blockchain based supply chain demo on an Ethereum POW network. Whilst we found the open source tools Geth, Truffle, Remix and so on adequate for the task the lack of information, and if we are honest, experience, resulted in frustrating time.

Subsequently (Part 2 to 4) we reviewed our experience of using the Azure Blockchain Workbench; here we fared much better.  There was documentation, a known, and for us, familiar environment with relatively simple template based setup and configuration tools. This is not say there were no problems but those we encountered where tractable and there was a forum where one could ask questions and raise issues.  Microsoft have stated their commitment to continue improving the Blockchain Workbench and to be open to user enhancement requests. Currently it stands at version 1.3.0 (our report used version 1.2.0, Blockchain Workbench) which now offers additional, easier to use, setup tools and additional code samples together with the option to deploy across a single shared Azure subscription; further subscription based configurations are promised which will ease business to business interaction.

As a Pre-Production platform we found it fairly easy to setup and use. Setting up AAD (Azure Active Directory) and configuring an application to access the Workbench Web API prove to be a little tricky, particularly the latter. That process would be helped by some more detailed documentation. There are also architectural issues, you are not able to create a Workbench instance without having an existing AAD tenancy for example, since the platform is based around AAD. Further, all the contracts you develop, and install must be must uniquely named because the Workbench expects the Solidity file and the Application to have the same name. This means that you cannot update an existing application, although this is perhaps a feature of the Ethereum network, since by its nature contacts once persisted to the network are immutable. Microsoft say they are working on this, hopefully they will also address the issue of the Configuration Metadata file and it’s mapping to the Solidity file. As we have noted elsewhere, there really has to be a better way to link these two than by hand. That said, we know where we’d prefer to be developing.

Finally, as a technology Blockchain could be used in the variety of scenarios but it will not always be appropriate or efficient to do so. Is Blockchain and Smart Contracts really for you? Well, if you are a Walmart supplier you will soon have no choice. As of next year, starting with fresh fruit and veg providers, Walmart will require all suppliers to implement IBM’s Blockchain service.

If you still have time to think about it then it might help to answer the following questions:

• Do participating parties require verification of all transactions?
• Should all transactions be immutable?
• Will the data be shared across all participants?
• Do I have the know-how, team and stamina to implement and manage a system based on emerging tools and technologies?

If you answer ‘yes’ to all or most of the above it is perhaps time to look at some of the solutions available. Although we have focused on Microsoft’s Azure based Blockchain Workbench, other major players offer similar templated BaaS platforms for example e.g. Amazon and Oracle and IBM (where you can even get a free, downloadable copy of “Blockchain for Dummies”; always handy).