Azure Blockchain Workbenchを用いることで、サプライ・チェーン・マネジメントに向けたブロックチェーンアプリケーションを迅速に構築することができます。今回は、簡単なデモアプリケーションの紹介をします。
Azure Blockchain WorkbenchによるEnterprise向けブロックチェーンアプリケーション開発の迅速化
Azure Blockchain Workbenchを用いることで、ブロックチェーンアプリケーションを作成する上で必要となる環境構築や機能連携といった作業を大幅に削減することが可能になります。
ブロックチェーンの基本環境の簡単なセットアップ
例えば、ブロックチェーンアプリケーションのベースとなる以下の環境や機能を簡単にセットアップできます。
- ブロックチェーンのノードに対応する仮想マシン
- Ethereumベースでのスマートコントラクト実装環境
- ユーザー認証機能
多様な機能を備えた”すぐに使えるアプリケーション”として実装可能
上記に加えて、以下のような実務に必要な多様な機能も事前にセットアップされているため、すぐに使えるアプリケーションとして開発を進めることができます。
- Webやモバイルに対応したクライアントアプリケーション
- オフチェーンとして利用可能なリレーショナルデータベース
- IoTデバイス連携
PoAによるコンソーシアム型ブロックチェーンの構築
また、権限者に基づく合意アルゴリズムであるPoA(Proof-of-Authority)による構築も可能であるため、エンタープライズ向けとして使用しやすいコンソーシアム/プライベート型のブロックチェーンを構築できます。
Azure Blockchain Workbench アーキテクチャの概要
Azure Blockchain Workbenchを立ち上げた際の環境の全体概要は以下のようになります。詳細は下記のリンクをご覧ください。
参考:
Azure Blockchain Workbench アーキテクチャ
サプライ・チェーン・マネジメントでの活用を想定したデモアプリケーションの紹介
Azure Blockchain Workbenchを用いることで、サプライ・チェーン・マネジメント向けのブロックチェーンアプリケーションを手軽に実装できます。
今回、サプライヤーから発注元へ商品が配送される際に、スマートコントラクトを用いて、事前の合意規則の元で配送が行われているかを検証するデモアプリケーションを紹介します。
デモアプリケーションが完成すると、下記のようなWebアプリケーションとして実際に動かすことができます。
今回のデモアプリケーションを通じて、下記の機能を実装することができます。
- Azure Active Directory(AD)を用いたユーザー認証
- Solidityで実装したスマートコントラクトによる商品トレースと規則遵守
- IoTデバイスによる測定値を用いた規則遵守の検証
デモアプリケーションのシーン説明
デモでは、サプライチェーン上の立場の異なる複数のユーザーを作成し、Web上で実際にアプリケーションを動かします。
シーンとしては、サプライヤーであるWoodgrove Distributionから、2つの配送業者 (Contoso ShippingとBlockchain Shipping) を経由して、発注者であるNorthwind Traders Supplychainへ製品が配送される流れを想定しています。
特徴的な点としては、IoTデバイスとスマートコントラクトを連携することで、製品配達時の温度・湿度を測定記録し、最後に監査機関により事前に合意した温度・湿度になっているかの検証を行うといったプロセスが含まれています。
想定シーンの詳細な手順は以下となっています。
- サプライヤーであるWoodgrove Distributionユーザーによる、コンストラクタインスタンスの生成による合意規則 (オーナー、監査担当、取扱可能な温度と湿度) の設定
- Woodgrove Distributionユーザーによる、Contoso Shippingへのrequestの登録
- Contoso Shippingユーザーによる、Woodgrove Distributionからのrequestの承認 (Contoso Shippingへの責任の移管) と、Blockchain Shippingへのrequestの登録
- シミュレートされたデバイスの測定結果 (デモでは値を手入力) の取り込み
- Blockchain Shippingユーザーによる、Contoso Shippingからのrequestの承認 (Blockchain Shippingへの責任の移管) と、Northwind Traders Supplychainへのrequestの登録
- Northwind Traders Supplychainユーザーによる、Blockchain Shippingからのrequestの承認 (Northwind Traders Supplychainへの責任の移管) と、 商品が到着したことの登録
- Government Regulatorユーザーによる、コンプライアンスのためのスマートコントラクトの監査
デモアプリケーションでの実装の流れ
デモを実行する際の大きな流れは以下のようになります。
- Azure Active Directory (AD) を作成する (Northwind Traders)
- 作成したAzure ADにアプリの登録をする (Azure Blockchain Workbench Web Client)
- 作成したAzure ADに対してサブスクリプションを登録する
- 作成したAzure ADのリソースにBlockchain Workbenchをデプロイする
- Web Client上でスマートコントラクトをデプロイする(TelemetryCompliance)
- 作成したAzure ADでデモに使用する6人のユーザーを作成し、Web Client上で作成したユーザーの割り当てを行う
- 「想定シーンの詳細な手順」に記載のある①〜⑦のプロセスを順に進める
デモアプリケーションを実際に実装するには、Blockchain Workbenchのデプロイの他に、Azure Active DirectoryやWeb Clientアプリケーションの設定なども必要になります。
詳細は下記のデモアプリケーションへのリンクの各ページをご覧ください。
デモアプリケーションへのリンク
※2019年3月現在、最新版は英語版をご参照ください。日本語版は一部現状と異なるバージョンとなっております。
デモアプリケーションのコードの解説
Azure Blockchain Workbenchでは、solidityによるスマートコントラクトコードファイル (Ethereumの場合) とjsonによる構成ファイルを用いてブロックチェーンアプリケーションを作成します (詳細はリンクを参照)
参考:
チュートリアル:Azure Blockchain Workbench でブロックチェーン アプリケーションを作成する
ここでは、デモアプリケーションで使用するTelemetryCompliance.sol (solidityコード) について説明をします。
solidityのコードの大枠は「コントラクトの定義」、コントラクト内で使用する「状態変数の定義」と「関数の定義」、加えて、コントラクトが呼び出される際に一度だけ呼ばれる「コンストラクタの定義」によって構成されます。
コード本体とコードの説明は以下のようになります。
※ コードは2019年3月末現在に実行確認したものをベースとしています。
コード本体
コードの説明 (コード内のコメント文を整理したもの)
1) コントラクトの定義
- 1-1) コントラクトを定義する
2) コントラクトで使用する状態変数の定義
- 2-1) レコードの状態を示す変数を定義する
- 2-2) ワークフローに参加する組織のアドレスを示す変数を定義する
- 2-3) 湿度と温度の許容範囲(最小値と最大値)を示す変数を定義する
- 2-4) デバイスで最後に測定された値とそのときの日時(タイムスタンプ)を示す変数を定義する
- 2-5) 許容範囲を逸脱したときに、どの測定値が逸脱しているかを示す変数を定義する
- 2-6) コンプライアンスの状態(許容範囲内で配送できているかどうか)を示す変数を定義する
3) コンストラクタの定義
- 3-1) 新しくConstractを作成する際にNew Contractとして一度呼び出されるconstructorを定義する
- 3-1-1) WebアプリのNew Contract画面で手入力した値を代入する
- 3-1-2) その他の変数について初期状態を設定する
4) コントラクトで使用する関数の定義
- 4-1) デバイスの測定情報をセンサーから受け取るときに使用する関数を定義する
- 4-1-1) エラー処理の設定 (関数を呼び出したアドレスがDeviceでないとき、StateがOutOfComplianceやCompletedのとき)
- 4-1-2) 測定された値を(今回はWebアプリ上で入力された値)を状態変数へ代入する
- 4-1-3) 湿度が許容範囲を超えた時は、そのことを各種状態変数へ記録し、ComplianceStatusをfalseにする
- 4-1-4) 温度が許容範囲を超えた時は、そのことを各種状態変数へ記録し、ComplianceStatusをfalseにする
- 4-1-5) 湿度か温度が許容範囲を超えた時は、StateをStateType.OutOfComplianceにする
- 4-2) 製品に対する責任を他の当事者に要求するときに使用する関数
- 4-2-1) エラー処理の設定 (関数を呼び出したアドレスがCounterpartyでないとき、StateがCreatedやInTransitでないとき、newCounterpartyがDeviceやSupplyChainObserverのとき)
- 4-2-2) 要求先のCounterparty(Webアプリ上で入力された値)を状態変数へ代入する
- 4-2-3) 状態変数であるStateをTransitionRequestPendingに変更する
- 4-3) 責任を要求された当事者が、製品の責任の移転を承認するときに使用する関数
- 4-3-1) エラー処理の設定 (関数を呼び出したアドレスがRequestedCounterpartyでないとき、StateがTransitionRequestPendingでないとき)
- 4-3-2) アドレス(ユーザー)の更新
- 4-3-3) 状態変数であるStateをInTransitに変更する
- 4-4) 製品の納品が完了したときに使用する関数
- 4-4-1) エラー処理の設定 (関数を呼び出したアドレスがCounterpartyでないとき、StateがInTransitでないとき)
- 4-4-2) 状態変数であるStateをFinalDeliveryに変更する
- 4-5) SupplyChainOwnerが、契約が納品状態になり完了したことを承認するときに使用する関数
- 4-5-1) エラー処理の設定 (関数を呼び出したアドレスがSupplyChainOwnerでないとき、StateがFinalDeliveryでないとき)
- 4-5-2) アドレス(ユーザー)の更新
- 4-5-3) 状態変数であるStateをCompletedに変更する