まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

2017/08

先日書いたこの件の続きです:
ユー・アー・ネクスト

↑自分の高齢の家族が某携帯キャリアでガラケー1回線をスマホに替えたら、使いもしない高額オプションを(本人は「付属品だと思った」という程度の認識で)ゴテゴテ付けられて計4回線契約をさせられていた、ということが発覚したのでした。 で、問題が起こった店舗に突撃訪問してきました。

・・・一言でいうと、完全に「腫れ物に触るような扱い」でした。絵に描いたような平身低頭というか、店長さんに今回の経緯を説明していただいた上で、こちらの言いぶんを全て認めていただきました。実は契約手続き上で渡さなければならない書類数枚が渡されていなかったこともわかりました。 その事による影響がどのくらいあったのかはわかりませんが、結論として新たに契約した3回線(代替スマホ、タブレット、無線LAN端末)はすべて「契約しなかった」ことになりました。契約してないので解約金/違約金はかかりませんし、該当機の初月の利用料も「請求に含めない」ことを約束していただきました。該当3機は全て返却しました。
pose_win_girl



実を言うと今日一日で完全に決着が付いたわけではありません。該当機3機は全て返却したのですが、先方が返却を主張する、ある「包装箱」1つが家族の家に存在していないのです(本人は「もらっていない」と主張)。これについては改めて探した上で結果を伝えるつもりです。これが話をややこしくするとは思ってないのですが、まだ気は抜けません。

加えて、今回は自分独りだけでなく独立行政法人国民生活センターに相談した上で進めていました。子供や高齢者といった社会弱者に対する高額請求は色々な所で問題が表面化しており、誤解を恐れずにいえば「タイムリーな相談内容だった」ことも影響したかもしれません。相談に乗っていただくだけでなく、進め方のアドバイスをいただいたり、この携帯キャリア本社に対する仲介になっていただくなど、とても親身に対応していただきました。


ともあれ、契約は「本来あるべき姿」に戻すことができたと思います。このあるべき姿にするまでにわざわざ契約と解約を経由するのは時間の無駄以外の何物でもないとも思うし、何よりも「家族がナメられた」と感じたら大炎上することは容易に想像できるはずなので、再発防止を徹底してほしいです。


根がケチなせいか、お金に関する理不尽な請求には泣き寝入りしないようにしています。4年ほど前に Google Wallet 経由で見に覚えのないスマホゲームのアプリ内課金が請求された時は(そもそも日本に窓口がなかったことも問題だと思ってましたが)英語でやりあいました。その時の経緯はこのブログでも紹介していました:
Google Wallet の不正利用?
Google Wallet の不正利用?(続き)
Google Wallet の不正利用?(続き2)
Google Wallet の不正利用?(続き3)
Google Wallet の不正利用?(続き4)
Google Wallet の不正利用?(解決編)

一応 Google の名誉のために言っておくと、この時の Google の対応はとても真摯で協力的でした。むしろその先のクレジット会社の対応がまったく非真摯的というか人の話を聞いていないかのような対応で解決が長引いてしまったという印象でした。


さて、先日お盆に実家に帰った時に団欒が凍り付くような事件がありました。自分が当事者ではないことと、現時点で相手の言いぶんをちゃんと聞いているわけではないので詳しく書くことは避けますが、高齢者である自分の家族の1人が大手携帯キャリアのスマホを契約した際に、明らかに不要な高額オプションを付帯契約させられていた、というものでした。

もともといわゆるガラケーを使っていたその家族がスマホに機種変更しました。ここまでは本人の意志でもあり問題ありません。ところが実際には以下の3回線を追加で(計4回線)契約させられていたのでした:
 ・(メインスマホとは別の、壊れた時の代替機として)スマホ1回線
 ・タブレット1回線
 ・「家に置くだけで家の中で無線LANが使える」ようにする******エアー1回線

ちなみにその家族は新しい回線を契約した認識はなく、「ぜんぶ付属品だと思った」とのこと。その結果の4回線契約です。本体の割賦支払いもあるので毎月の支払額はウン万円、という感じ。24回払いと36回払いが混在していて、全部キレイに解約するのがとても面倒、というあくどいやり方です。

詳しくは自分が明日、店頭を訪ねて先方の説明を聞いてくるつもりですが、それにしてもあまりにもおかしな理論です。まず「代替機」と説明された(らしい)2台目のスマホ。代替機なら回線契約は不要のはずだし、後述の無線LAN機器を契約したなら、代替機として使うまではそちらを使えばいいので、どう考えても回線契約は不要のはず。 また「タブレット」については本人は契約した認識すらありませんでした。思い出しながら書いているだけでイライラが再発しそうだ。。

そして「なんたらエアー」とかいう無線LAN機器、これは自分が家族の部屋に無線LANを設置しているのでそもそも不要なもので、どうもこれが自宅に存在していることを店員に伝えていたにも関わらず、言いくるめて契約させられた模様。なぜこれが要ると思ったのだろう・・・


自分がこの契約のことを知ったのは機種変更の契約から8日目でした。ちょうどクーリングオフができなくなるタイミング。でもこちらからは「これはクーリングオフとかいう問題ではなく、明らかに不要なものを買わせたのだから、再度説明した上でメインの1回線以外は違約金なしで契約を取り消すべき」という主張を伝えています。

詳しくは話しませんが、全く準備せずにいきなり乗り込むわけではありません。ある程度戦う準備はした上で明日店頭に突撃訪問してきます! 言いたいことは山ほどあるのですが、解決してからにしようと思っています。訪問の結果はまたいずれ。


前回は4年くらい前に、上記のような半年以上に渡る気の長い戦いをクレジット会社とやってきて不正請求分を取り戻しました。某携帯キャリアの○○○○○○、You are next!
usflag9sm



Node.js のアプリケーションで、以下のような処理を実装してみました:
 - 認証(ログイン)用の API には誰でもアクセスできる
 - 認証 API では ID とパスワードを与えて認証し、正しいユーザーにはトークンを発行する
 - 認証以外の主な API はこの発行されたトークンを使ってアクセスした時だけ実行を許可する
 - API 呼び出し時にトークンがなかったり、正しくなかった場合は実行せずにエラー


この仕組を実現するために JSON Web Tokens (以下 "JWT")を使いました:
https://jwt.io/

2017081400


JWT はオープンかつ Node.js ではスタンダードなトークンベースの認証ライブラリです。以下で紹介するサンプルでは Web フレームワークである Express や、POST データを扱う body-parser も合わせて使うので、まとめてインストールしておきます:
$ npm install express body-parser jsonwebtoken

これらのライブラリを使って以下のようなアプリケーションを作成します:
//. app.js

var express = require( 'express' );
var app = express();
var bodyParser = require( 'body-parser' );
var jwt = require( 'jsonwebtoken' );

//. アプリケーションサーバーの稼働ポート番号
var port = process.env.PORT || 8080

//. 任意のシークレット文字列を登録
app.set( 'superSecret', 'welovenodejs' );  //. 任意の文字列

app.use( bodyParser.urlencoded( { extended: false } ) );
app.use( bodyParser.json() );

//. ユーザー情報(本来は DB などに格納された情報を使う)
var users = [
  { name: 'user0', password: 'pass0', admin: true },
  { name: 'user1', password: 'pass1', admin: false },
  { name: 'user2', password: 'pass2', admin: false },
  { name: 'user3', password: 'pass3', admin: false }
];

//. ドキュメントルートへの GET は許可
app.get( '/', function( req, res ){
  res.send( 'Hello. The API is at http://localhost:' + port + '/api' );
});

//. API ROUTES
var apiRoutes = express.Router();

//. トークンなしでアクセスを許可する API を先に定義する

//. POST(http://localhost:8080/api/authenticate)
apiRoutes.post( '/authenticate', function( req, res ){
  for( var i = 0; i < users.length; i ++ ){
    if( users[i].name == req.body.name && users[i].password == req.body.password ){
      //. 認証したユーザーの情報を使ってトークンを生成
      var token= jwt.sign( users[i], app.get( 'superSecret' ), {
        expiresIn: '24h'
      });
      res.json( { success: true, message: 'Authentication successfully finished.', token: token } );
      return;
    }
  }

  res.json( { success: false, message: 'Authentication failed.' } );
  return;
});

//. ここより上で定義した API には認証フィルタはかけていない(そのまま使える) //. 認証フィルタ apiRoutes.use( function( req, res, next ){
//. ポスト本体、URLパラメータ、HTTPヘッダいずれかにトークンがセットされているか調べる var token = req.body.token || req.query.token || req.headers['x-access-token']; if( !token ){
//. トークンが設定されていなかった場合は無条件に 403 エラー return res.status(403).send( { success: false, message: 'No token provided.' } ); } //. 設定されていたトークンの値の正当性を確認 jwt.verify( token, app.get( 'superSecret' ), function( err, decoded ){ if( err ){ //. 正当な値ではなかった場合はエラーメッセージを返す return res.json( { success: false, message: 'Invalid token.' } ); } //. 正当な値が設定されていた場合は処理を続ける req.decoded = decoded; next(); }); }); //. 以下はトークンがないと使えない API //. GET(http://localhost:8080/api/) apiRoutes.get( '/', function( req, res ){ res.json( { message: 'Welcome to API routing.' } ); }); //. GET(http://localhost:8080/api/users) apiRoutes.get( '/users', function( req, res ){ res.json( users ); }); //. /api 以下に API をルーティング app.use( '/api', apiRoutes ); app.listen( port ); console.log( 'server started http://localhost:' + port + '/' );

肝になるのはルーティングに認証フィルタを定義している箇所です。ここよりも前(上)で定義した内容には認証フィルタは有効にならないので、認証なしで使える API となります(つまり GET / と POST /authenticate は認証していなくても使えます)。

この POST /api/authenticate API でポストデータ user, password を受取り、その値が変数 users の中で定義されているいずれかの組み合わせと一致していれば 24H 有効なトークンが発行されます(これを以下の API 実行時にパラメータ指定します)。

一方、ここよりも後(下)で定義する内容には認証フィルタが有効になり、GET /api と GET /api/users は上記方法で取得したトークンがパラメータに設定されていないと正しく処理されない API となります。


実際にこのアプリケーションを実行し($ node app)、curl コマンドで挙動を確認してみましょう。まずは問題なく実行できるはずの GET / を実行します:
$ curl -XGET 'http://localhost:8080/'
Hello. The API is at http://localhost:8080/api

問題なく実行できました。次は認証フィルタをかけた GET /api を実行してみます:
$ curl -XGET 'http://localhost:8080/api'
{"success":false,"message":"No token provided."}

API を実行した結果、「トークンがない」時のエラーメッセージが表示されました。ここも期待通りに動いています(試しませんが、ユーザー一覧を取得する GET /api/users も同様のエラーになります)。

では POST /api/authenticate で認証してトークンを取得してみますが最初はわざとパスワードを間違えてみます:
$ curl -XPOST -H 'Content-Type:application/json' 'http://localhost:8080/api/authenticate' -d '{"name":"user1","password":"pass0"}'
{"success":false,"message":"Authentication failed."}

先程同様にエラーになりましたが、エラーメッセージが「認証失敗」に変わりました。では改めて正しいパスワードを指定して実行してみます:
$ curl -XPOST -H 'Content-Type:application/json' 'http://localhost:8080/api/authenticate' -d '{"name":"user1","password":"pass1"}'
{"success":true,"message":"Authentication successfully finished.","token":"XXXXXX...XXXXXX"}

今度は認証が成功しました。レスポンスにも "token" が含まれています。最後にここで返ってきた token の値を指定して、先程アクセスできなかった GET /api を実行してみます:
$ curl -XGET 'http://localhost:8080/api?token=XXXXXX...XXXXXX'
{"message":"Welcome to API routing."}

今度は API が実行できました。同様にして GET /api/users も実行できるはずです:
$ curl -XGET 'http://localhost:8080/api/users?token=XXXXXX...XXXXXX'
[{"name":"user0","password":"pass0","admin":true},{"name":"user1","password":"pass1","admin":false},{"name":"user2","password":"pass2","admin":false},{"name":"user3","password":"pass3","admin":false}]


こんな感じで API の実行可否をトークンで制御できるようになりました。

今回の例ではソースコード内に静的に用意されたユーザー一覧を使って認証を行いましたが、実際の運用ではデータベース内に定義されたテーブル情報などを使うことになると思います。ただ JWT の基本的な考え方はこの1つのソースファイルだけで実現できているので、応用しやすいと思っています。

 

以前のブログエントリの中で Hyperledger Composer を使うことでブロックチェーンのビジネスネットワークを比較的簡単な定義で動かすことができることを紹介しました:
Hyperledger Composer フレームワークを使ってみる

↑ここで紹介したように Hyperledger Fabric v1.0 と Hyperledger Composer を使うことで、"asset" と呼ばれる取扱データ、"participant" と呼ばれるユーザー、 "transaction" と呼ばれる実行処理、そして "ACL" と呼ばれるアクセス権管理を定義してブロックチェーン環境に簡単にデプロイすることができるようになります。

この方法でデプロイしたブロックチェーンネットワークを外部のプログラムから使う方法も何通りかあるのですが、今回はその中から「Composer の内容を Web API 化」して、外部からは HTTP(S) を使った REST API として使えるように公開する方法を紹介します。以下の手順を実際に試す場合はローカル環境内に Hyperledger Fabric v1.0 および Hyperledger Composer がインストールされている必要があります。その手順は以下を参照して、ローカル環境で Hyperledger Composer が使える状態を作っておいてください:
Hyperledger Composer フレームワークをインストールする


また、実際に REST API として公開する内容のビジネスネットワークを定義した .bna ファイルが必要です。今回は以下のページで紹介されている方法に従って my-network.bna ファイルを作り、それを使うことにします(以下に日本語で解説します):
Developer Tutorial for creating a Hyperledger Composer solution


ではビジネスネットワークの定義ファイルを用意するまでの手順を紹介します。今回は github.com に公開されているサンプルをベースにクローンして用意します。

まず、上記リンク先の手順に従って Hyperledger Fabric v1.0 および Hyperledger Composer が導入された環境を用意して、両方のサービスを有効にします。

次に同環境にログインし、作業ディレクトリ(以下の例では ~/work)を作って、サンプルプロジェクトを git clone します:
$ mkdir ~/work (作業ディレクトリ)
$ cd ~/work
$ git clone https://github.com/hyperledger/composer-sample-networks.git

このサンプルプロジェクト内の basic-sample-network の内容を my-network という名前でコピーします:
$ cp -r ./composer-sample-networks/packages/basic-sample-network/  ./my-network

my-network プロジェクトの package.json ファイルを変更します。変更内容は name と prepublish 内のプロジェクト名を "my-network" にすることと、description の内容を変えることです:
    :
  "name": "my-network",
  "version": "0.1.6",
  "description": "My Commodity Trading network",
  "networkImage": "https://hyperledger.github.io/composer-sample-networks/packages/basic-sample-network/networkimage.svg",
  "networkImageanimated": "https://hyperledger.github.io/composer-sample-networks/packages/basic-sample-network/networkimageanimated.svg",
  "scripts": {
    "prepublish": "mkdirp ./dist && composer archive create --sourceType dir --sourceName . -a ./dist/my-network.bna",
    "pretest": "npm run lint",
    :

そして実際のビジネスネットワークの内容を書き換えます。定義する内容は上記ブログエントリの中で紹介したものと同じ定義をこのプロジェクト内にも作成することにします。というわけでまずは models/sample.cto ファイルを開き、以下の内容に書き換えて保存します:
/**
 * My commodity trading network
 */
namespace org.acme.mynetwork
asset Commodity identified by tradingSymbol {
    o String tradingSymbol
    o String description
    o String mainExchange
    o Double quantity
    --> Trader owner
}
participant Trader identified by tradeId {
    o String tradeId
    o String firstName
    o String lastName
}
transaction Trade {
    --> Commodity commodity
    --> Trader newOwner
}

↑ Commodity という asset と、Trader という participant と、Trade という transaction を定義しています。

同様にして lib/sample.js ファイルを開き、以下の内容に書き換えます:
/*
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

/**
 * Track the trade of a commodity from one trader to another
 * @param {org.acme.mynetwork.Trade} trade - the trade to be processed
 * @transaction
 */
function tradeCommodity(trade) {
    trade.commodity.owner = trade.newOwner;
    return getAssetRegistry('org.acme.mynetwork.Commodity')
        .then(function (assetRegistry) {
            return assetRegistry.update(trade.commodity);
        });
}

↑tradeCommodity という処理を定義しています。

そして同様にして permissions.acl ファイルも以下の内容に書き換えます:
/**
 * Access control rules for mynetwork
 */
rule Default {
    description: "Allow all participants access to all resources"
    participant: "ANY"
    operation: ALL
    resource: "org.acme.mynetwork.*"
    action: ALLOW
}

rule SystemACL {
  description:  "System ACL to permit all access"
  participant: "org.hyperledger.composer.system.Participant"
  operation: ALL
  resource: "org.hyperledger.composer.system.**"
  action: ALLOW
}

↑デフォルトで全参加者にリソースへのアクセス権を与えるという内容です。


ではここまでに定義した models/sample.cto, lib/sample.js, permissions.acl の内容でビジネスネットワークをビルドします:
$ cd ~/work/my-network
$ npm install

このコマンドが成功すると、 my-network/dist フォルダ内に my-network.bna ファイルが生成されます。このファイルと Hyperledger Composer を使って Hyperledger Fabric v1.0 に同ビジネスネットワークをデプロイします:
$ cd dist
$ composer network deploy -a my-network.bna -p hlfv1 -i PeerAdmin -s randomString

デプロイが成功しているかどうかは以下の ping コマンドで確認できます:
$ composer network ping -n my-network -p hlfv1 -i admin -s adminpw

ここまでの作業でビジネスネットワークを定義し、Hyperledger Fabric v1.0 上にデプロイすることができました。最後にこのビジネスネットワークを Web API 化して HTTP クライアントから REST でアクセスできるようにします。 そのためには composer-rest-server というツールを使います。composer-rest-server は npm を使ってインストールします:
$ sudo npm install -g composer-rest-server

composer-rest-server の使い方は REST API 化したい Hyperledger Composer プロジェクト上でコマンド実行するだけです:
$ cd ~/work/my-network
$ composer-rest-server

すると Hyperledger-Composer ロゴが現れ、知る人ぞ知る Strongloop loopback のようなインターフェースでのプロパティ指定画面になります:
2017081401


質問内容に以下のように答えます:
 Fabric Connection Profile Name: hlfv1
 Business Network Identifier: my-network
 Fabric username: admin
 secret: adminpw
 namespaces: never use namespaces
 (ここから下はデフォルトのまま)
 REST API to be secured: No
 event publication over WebSockets: Yes
 TLS security: No
2017081402


すると上記画面のように http://(IPアドレス):3000/explorer と表示されます。ウェブブラウザでこの URL にアクセスすると、(これも知る人ぞ知る StrongLoop Loopback のような)定義したビジネスネットワークに REST API でアクセスするための Open API ドキュメントが表示されます:
2017081403


この画面からは定義した Commodity や Trader, Trade といった asset, perticipant, transaction を読み書き実行するための各 API を展開したり、
2017081404


実際にパラメータを指定して実行したりすることもできます:
2017081405


この方法であればブロックチェーンにあまり詳しくないデベロッパーでも REST API で利用できるので非常に便利といえます。

 

オープンソースのブロックチェーン環境である Hyperledger Fabric 用のフレームワークとして Hyperledger Composer が提供されています:
https://hyperledger.github.io/composer/

この Composer (と Hyperledger Fabric)を使うことでブロックチェーンアプリケーションおよびビジネスネットワークを比較的簡単に作れるようになる、というものです。

この Composer を実際に動かして体験できるサービス(Hyperledger Composer Playground)がオンライン上で公開されているので使ってみました。以下はオンライン版の Composer Playground でも、ローカル版の Composer でも同じように実行できます。なお、Composer をローカル環境に導入する場合の手順は以下を参考にしてください:
Hyperledger Composer フレームワークをインストールする


では実際に Composer を使ってみましょう。まずは Hyperledger Composer Playground にアクセスします。オンライン版であれば、http://composer-playground.mybluemix.net/editor に、ローカル環境にインストールした場合であれば composer.sh を実行後に http://localhost:8080/ にアクセスします:
2017080401


このサービスを以前に使ったことがある場合はローカルストレージに以前の情報が記憶されて残っています。初めから体験し直したい場合は、ブラウザのコンソールで
> localStorage.clear()
と実行してから以下を続けてください。


Composer Playground 起動画面の "Let's Blockchain!" と書かれたボタンをクリックしてダイアログを消すと、このような初期画面になります:
2017080402


Composer では Model, Script, ACL の3つを定義してブロックチェーン上のアプリケーション(というか挙動)を定義します。この Composer Playground はサンプルをベースにこれらを改良して、実際にデプロイして動かすことができるオンラインサービスです。

では実際にサンプルを改良してシンプルなトレードアプリを作ってみましょう。まずは Model を変更してみます。画面左で "Model File models/sample.cto" と書かれた箇所をクリックして選択します。するとこのファイルの内容が画面右のエディタで表示されます:
2017080403


画面右はエディタになっているので編集可能です。デフォルトの中身を全て消し、代わりに以下の内容を(コピペなどで)入力します:
/**
 * My commodity trading network
 */
namespace org.acme.mynetwork
asset Commodity identified by tradingSymbol {
    o String tradingSymbol
    o String description
    o String mainExchange
    o Double quantity
    --> Trader owner
}
participant Trader identified by tradeId {
    o String tradeId
    o String firstName
    o String lastName
}
transaction Trade {
    --> Commodity commodity
    --> Trader newOwner
}

※入力直後に画面が以下のようになり、他のファイルでエラーが発生します。これは Model が変更になって、その Model に合わない内容が Script や ACL に設定されているためのエラーです。このエラーはこの後で修正していきます:
2017080404


※またエディタ内で編集した内容は自動的に保存されるようになっていますが、うまく働かないこともあるようです。その場合は Ctrl+S を実行して強制保存してください。環境によっては画面に HTML の保存ダイアログが出てしまうこともありますが、そちらはキャンセルしてください。


namespace (org.acme.mynetwork) を定義した上で、"Commodity" という asset 1つ(id は tradingSymbol)、"Trader" という participant 1つ(id は tradeId)、そして "Trade" という transaction 1つを定義しています。Model ではこのように取り扱うオブジェクトを asset 、取り扱う人(ネットワーク参加者)を participant、実行する処理を transaction と呼び、これらをまとめて定義するのが Model です。

では次にこの Model に合うように Script を変更します。画面左の "Script File lib/sample.js" と書かれた部分をクリックし、画面右のエディタで以下の内容に書き換えます:
2017080405
/**
 * Track the trade of a commodity from one trader to another
 * @param {org.acme.mynetwork.Trade} trade - the trade to be processed
 * @transaction
 */
function tradeCommodity(trade) {
    trade.commodity.owner = trade.newOwner;
    return getAssetRegistry('org.acme.mynetwork.Commodity')
        .then(function (assetRegistry) {
            return assetRegistry.update(trade.commodity);
        });
}

このスクリプトでは tradeCommodity という関数1つだけが定義されており、パラメータ内変数の書き換えを行った後でレジストリを取り出し、内容を書き換える、という処理を行っています。

最後に ACL を変更します。同様にして画面左の "Access Control permissions.acl" と書かれた箇所をクリックし、画面右のエディタで以下の内容に編集します:
2017080406
/**
 * Access control rules for mynetwork
 */
rule Default {
    description: "Allow all participants access to all resources"
    participant: "ANY"
    operation: ALL
    resource: "org.acme.mynetwork.*"
    action: ALLOW
}

rule SystemACL {
  description:  "System ACL to permit all access"
  participant: "org.hyperledger.composer.system.Participant"
  operation: ALL
  resource: "org.hyperledger.composer.system.**"
  action: ALLOW
}

↑デフォルトで全参加者にリソースへのアクセス権を与えるというシンプルな内容です。

ではここまでの変更内容を実際のブロックチェーンに反映させてみます。画面左下の "Deploy" ボタンをクリックします:
2017080401


画面右上に "Deploy Successful" と表示されればデプロイは成功です。これだけで定義した内容が Blockchain に反映されました、簡単ですね:
2017080403


Hyperledger Composer ではブロックチェーン上での動作確認を行うことも可能です。デプロイ後に "test" と書かれたタブを選択します。まずは Perticipant を登録してみましょう。画面左で "Trader" と書かれた箇所をクリック(※)し、画面右上の "+ Create New Participant" と書かれたボタンをクリックします:
2017080402


※画面内に "Trader" という表示が出てこなくて、"SampleParticipant" という表示しか出てこない場合は変更が画面に反映されていない状態であることを意味しています。その場合は強制的に更新するため、一度 "Define" タブに戻って、定義内容を "Export" し、エクスポートした .bna ファイルを "Import" し直してください。これで強制的に更新を行うので "Trader" が表示されるようになるはずです:
2017080401



テキスト入力のダイアログが開くので、以下の内容を入力して "Create New" ボタンをクリックします:
2017080403
{
  "$class": "org.acme.mynetwork.Trader",
  "tradeId": "TRADER1",
  "firstName": "Jenny",
  "lastName": "Jones"
}

入力した Trader が登録されます:
2017080404


同じ作業を繰り返して、以下の Trader も登録し、2つの Trader が Participant として登録されている状態にします:
{
  "$class": "org.acme.mynetwork.Trader",
  "tradeId": "TRADER2",
  "firstName": "Amy",
  "lastName": "Williams"
}

2017080405


同様にして asset である Commodity を作成します。"Commodity" が選択された状態で "+ Create New Asset" ボタンをクリックします:
2017080401


以下の内容を入力して "Create New" ボタンをクリックし、TRADER1(Jenny)の asset "ABC" を登録します:
2017080402
{
  "$class": "org.acme.mynetwork.Commodity",
  "tradingSymbol": "ABC",
  "description": "Test commodity",
  "mainExchange": "Euronext",
  "quantity": 72.297,
  "owner": "resource:org.acme.mynetwork.Trader#TRADER1"
}

この状態で "Submit Transaction" ボタンをクリックして、トランザクションを1つ実行してみましょう:
2017080403


トランザクションの内容は先程登録した TRADER1(Jenny) の Commodity アセット(ABC)の持ち主を TRADER2(Amy) に変更する、というものとします("Submit" をクリックするとトランザクションが実行されます):
2017080404
{
  "$class": "org.acme.mynetwork.Trade",
  "commodity": "resource:org.acme.mynetwork.Commodity#ABC",
  "newOwner": "resource:org.acme.mynetwork.Trader#TRADER2"
}

トランザクション実行後、"All Transactions" にはブロックチェーン上で実行されたトランザクションが記録されます:
2017080405


また、Assets 一覧を見ると、先程 TRADER1 の所有物として登録された Commodity "ABC" の持ち主が TRADER2 に変更されたことが確認できます:
2017080406


このように Composer を使うと、ブロックチェーン上で定義すべき参加者の種類、アセットの種類、アクセス権が簡単に定義できるだけでなく、試験的にデプロイしてトランザクションを発生させた上で動作を確認することが(REST API を呼んだり、プログラミングしたりしなくても)簡単に行えるようになります。


なお、上記で紹介している内容は以下のページを参考に日本語訳と解説を加えたものです。詳しくはこちらも参照ください:
https://hyperledger.github.io/composer/tutorials/playground-guide.html
 

このページのトップヘ