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

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

2015/03

IBM Bluemix をはじめ、多くの便利な REST API が公開されています。REST API は HTTP プロトコルベースなので、特定のプラットフォームやプログラミング言語環境に縛られることなく、HTTP クライアント機能を持っている多くのプラットフォームやプログラミング言語から利用できるようになっています。

その一方で、IBM ノーツを使っている技術者の立場として、こういった外部の REST API をノーツからどうやって使うか、という情報があまり公開されておらず、「ノーツからは使えないんじゃないか?」と思われてしまっているように感じています。実際、ハードル高いと思う。

1点補足すると、これは「ドミノサーバー」からの話ではなく「ノーツクライアント」からの話です。ドミノサーバーであれば、Java サーブレットも使えるし、もちろんそのサーブレットからノーツデータベースにアクセスすることもできるので、連携もあまり問題ないと思うのですが、問題は「ノーツクライアント上」から「外部の」 REST API を使う、というケースです。 特に「外部の」という部分がミソで、JavaScript の AJAX などから使おうとしてもクロスサイトスクリプティング制約があったりするので、結構難しい問題だと思っています。


で、今回紹介するのは、ノーツクライアントから外部の REST API を使う方法です。"REST API" といっても、要は
 ・特定の URL に対して GET や POST でデータを送信してリクエストすると、
 ・結果が XML や JSON で返ってくるもの
という緩い定義で考えるものにします。これをノーツクライアントから実行して結果を受け取る、というものです。

今回は REST API のサンプルとして、マンホールマップの公開 API を使います。具体的には以下の URL に(GET で)アクセスすると、マンホールマップサービスに投稿されたデータから、最新20件のデータを取り出して JSON フォーマットで返す、というごく一般的(?)なものです:
http://manholemap.juge.me/searchcreated?limit=20&format=json

試しにウェブブラウザでこの URL にアクセスすると、取得結果の JSON がそのまま表示されて、こんな感じの結果になります。ちなみにこの JSON の中身の意味は・・・興味ある人はコメントなどで連絡ください、個人的に教えます(苦笑):
2015033001


この REST API にノーツクライアントからアクセスして JSON データを取得し、中身を解析してノーツで活用しよう、というのが今回の目的です。

まず最初に、これを実現するには「REST API を実行して、結果を取得する」という、ウェブ API ではごく当たり前のことを行う必要があるのですが、ノーツクライアントからこれを実行するには Java エージェントを使う必要があります。LotusScript や式関数などのマクロではノーツに関するカスタマイズ処理を記述することはできますが、TCP/IP 通信や HTTP プロトコルのレベルで処理をカスタマイズする方法は用意されていません。LSX(LotusScript eXtension) や WinSock の DLL を使って TCP/IP のソケット通信を行って・・・という手段がないわけではないと思いますが、そこまで自前で用意した上で更に HTTP プロトコルを実装、となるとさすがに非現実的です。その点、Java を使えば TCP/IP 通信は標準で持っているし、外部の便利なライブラリを使って比較的簡単に HTTP 通信を実現することもできます(更に言うと今回の例では JSON の解析も行う必要がありますが、それもライブラリに任せることができます)。 という背景もあって、今回は Java エージェントを使って REST API を実行します。

実際に Java エージェントを作る前の準備として、HTTP 通信用の Java ライブラリを用意しておきます。選択肢としてはいくつかあると思いますが、サンプルの多さなどから自分が個人的に使っているのが Jakarta Commons(Apache Commons)HTTP Client 3.1 です。この本体と、更に依存関係で必要な Logging ライブラリ、そして Codec ライブラリを全てダウンロードします。 更に実行結果の JSON テキストを取得した後の解析用に JSON ライブラリが必要になるので、これも JSON simple ライブラリをダウンロードしておきます。これらは同様の機能を持っているものであれば別のライブラリを使ってもいいのですが、以下のサンプルではこれらを使っている前提で紹介します。

以上をまとめて、以下の表のダウンロードサイトからライブラリ(のバイナリ)をダウンロードして、ダウンロードしたモジュールを展開するなどして表内右端列の4つの JAR ファイルをあらかじめ取得しておいてください。図のように同じフォルダに格納しておくと後で便利です(いずれも 2015年3月30日時点の最新バージョンです):
2015033002

ライブラリダウンロードサイト必要なファイル
HTTP Client 3.xCommons HttpClient Archivescommons-httpclient-3.1.jar
LoggingDownload Apache Commons Loggingcommons-logging-1.2.jar
CodecDownload Apache Commons Codeccommons-codec-1.10.jar
JSON simpleDownloads - JSON simplejson-simple-1.1.1.jar


では改めてノーツ上で Java エージェントを作ります。目的のデータベース(なければ新規に作って)をドミノデザイナーで開き、コード - エージェントをダブルクリックして選択後に「新規エージェント」ボタンをクリックして、エージェントを追加します:
2015033000


新規エージェント作成画面でエージェント名(図では "REST API Sample")を入力し、エージェントタイプに "Java" を選択して OK ボタンをクリックし、Java エージェントを作成します:
2015033003


新規に Java エージェントが追加されました。この中身を記述する前に、先ほど用意した4つのライブラリファイルを、このエージェント内にインポートして使えるようにしておきます。エージェント画面内の インポート - アーカイブ を選択します:
2015033004


ソースディレクトリに JAR ファイルが格納されているフォルダを指定し、インポートしたい JAR ファイルをまとめて指定して「終了」ボタンをクリックします。JAR ファイルが別々のフォルダに格納されている場合は、この手順を繰り返して全ての JAR ファイルをインポートします:
2015033005


Java エージェントのアーカイブに指定した JAR ファイルが追加されていることを確認してください。これで Java エージェント内でこれらのライブラリを使った処理を記述することができるようになりました。改めて javaAgent.java をダブルクリックして、エージェント処理の実装にとりかかります:
2015033006


ドミノデザイナー内でコードエディタが開き、javaAgent.java の編集状態になります。ここで記述された内容がこのエージェントの実行内容になります。コメントで "(Your code goes here)" と書かれた箇所の後に(というか、その前の部分を触らないように)実行内容を Java で記述します:
2015033007


今回の場合は、目的の REST API を実行して、その結果を取得する、という実装を行います。取得結果を最終的にどう扱うか(例えばノーツのデータとして格納するのか?別のデータベースに格納するのか?単に表示するだけか?など)は別に検討する必要があると思いますが、今回は結果を Java コンソールに出力する、という内容にします。なので、実装コードはこんな感じです。ここはもうノーツの世界ではなく、普通に Jakarta HTTP Client を使っているだけです:
  :
  :
  // (Your code goes here)
  HttpClient client = new HttpClient();
  GetMethod get = new GetMethod( "http://manholemap.juge.me/searchcreated?limit=20&format=json" );
  int sc = client.executeMethod( get );
  if( sc == 200 ){
    String json = get.getResponseBodyAsString();
    JSONParser parser = new JSONParser();
    JSONArray objs = ( JSONArray )parser.parse( json );
    int n = objs.size();
    for( int i = 0; i < n; i ++ ){
      JSONObject obj = ( JSONObject )objs.get( i );
      Long id = ( Long )obj.get( "id" );
      String username = ( String )obj.get( "username" );
      String text = ( String )obj.get( "text" );

      //. とりあえず整形してコンソールに出力
      String line = i + ": [" + id  + "] " + text + "(" + username + ")";
      System.out.println( line );
    }
  }
  :
  :

これで javaAgent.java およびこの(今回の例だと "REST API Sample")エージェントを保存します。


では試しにこのエージェントをノーツクライアント上で実行してみます。ノーツでこのエージェントを作ったデータベースを開きます。今回の例では最終結果を Java コンソールに出力しているので、その確認のためメニューから ツール - Java デバッグコンソールの表示 を選択します:
2015033001


こんな感じの Java コンソールウィンドウが開きます。実行結果はこの中に表示されるので、ウィンドウを閉じずにこのまま続けます:
2015033002


改めてノーツクライアントの画面に戻り、メニューから アクション - (作ったエージェント名(今回の例だと "REST API Sample")) を選択して、上記で作成した Java エージェントを実行します。実行方法はこれ以外にトリガを用意しても構いませんが、動作確認目的であれば、この方法が簡単でオススメです:
2015033003


作成した Java コードが正しく実行されると、REST API が呼び出され、結果の JSON テキストがパース&解析されて、取得したデータが1行ずつ Java コンソールに表示されるはずです:
2015033004


この例だと取得結果を Java コンソールに表示するだけでしたが、この結果を DB に格納するなり、これを元に HTML を作ってブラウザで表示する(参考記事)なり、色々な応用があると思います。ともあれノーツクライアントからであっても一般的な REST API を実行することができました。

後はこれを IBM Bluemix 上の各種 Watson API など、様々な外部 REST API を使う形で応用できると思っています。ノーツのデータを元に人工知能 API を使った解析を行うなど、いろんな使い方の可能性が広がると思っています。

 

Java のコードからブラウザを起動できることを知りました。
環境依存とかで面倒そう、、と思っていたのですが、AWT の Desktop クラスを使うことで比較的簡単に実現できちゃいました:
import java.awt.Desktop;
import java.net.URI;

  :
  :

String uriString = "http://manholemap.juge.me/"; // 開くURL
Desktop desktop = Desktop.getDesktop();
try{
  URI uri = new URI( uriString );
  desktop.browse( uri );
}catch( Exception e ){
  e.printStackTrace();
}

  :
  :

これだけで指定した URL のページ(この例だとマンホールマップ)がデフォルトブラウザで開きます。

これがどんな時に便利かというと、一般的な Web アプリケーションの中で(サーブレットや JSP で)Java を使う時は HttpServletRequest/HttpServletResponse クラスなどから UI 部分との連携ができるのですが、スタンドアロン Java プログラムや、IBM Notes などのスタンドアロンアプリケーションから Java を使おうとすると、コードは実行できても UI 部分との連携がしにくくて、「実行結果をどうやって見せるか」の問題があるのでした。Java コンソールに出力するくらいはできても、それを見てもらうのも至難の技だし、そもそも見栄えも悪い。

その点、ブラウザを起動できてしまえば、パラメータに実行結果を含めちゃったりすることで実行結果を渡す方法もあるし、見栄えも HTML/CSS で自由度高く作れるしで、重宝します。

なお、java.awt.Desktop クラスはこれ以外でもファイルを関連付けられたアプリで開く open メソッドや、印刷する print メソッドなど、デスクトップ関連の便利なメソッドが用意されています。ノーツ系の皆さんは覚えておくと便利かも(とっくに知ってたらごめんなさい):
Desktop(Java Platform 7)






 

CentOS などの Linux/UNIX 環境で top コマンドを使ってプロセスの様子を確認することは珍しくないと思いますが、その機能拡張版である htop コマンドを使ってみました。普通の(?)top コマンドではわからない情報も表示してくれて便利です。Mac 環境でも使えます。


RedHat/CentOS 系 OS であれば、導入は yum コマンドで一発ですが、EPEL リポジトリを有効にする必要があります。未導入の場合は最初に EPEL を導入しておきます。以下は CentOS 6 の場合のコマンド例です:
# rpm -ivh http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm (64bit 環境の場合)
# rpm -ivh http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/6/i386/epel-release-6-8.noarch.rpm (32bit 環境の場合)

リポジトリの導入ができていれば、次のコマンドで htop のインストールもできます:
# yum install htop

シェルから "htop" で実行します:
# htop

こんな感じで起動します。テキストモードですが、画面は色分けされ、top と比べて見やすく表示されています。画面上部に CPU やメモリの様子がテキストグラフィックで表示されていて、これはこれでわかりやすくなっています:
2015032701



実はこの画面内ではカーソルキーが有効になっていて、カーソルキーの上下で特定のプロセスに移動し、F7/F8 でプロセスの優先度を変えたり、F9 で Kill したり、、といった操作もできます:
2015032702

 

F1 キーを押すとショートカットキーコマンドの一覧が表示されます:
2015032703


F5(t) でツリービューにして、+/- で展開/格納したり、といった表示も可能になるようです。試してみるとこんな感じ。カーソルがある行の情報だけが格納されています:
2015032704


F3 キーでプロセスの検索もできます。この図では "/sbin/rsys" まで検索して、カーソル行が rsyslogd のプロセスに移動している様子です:
2015032705


特定のユーザーのプロセスだけを表示する、といった操作も可能です。まず u キーを押して、ユーザーの一覧から目的のユーザーを選んで Enter 、です:
2015032706


インストールも簡単だし、シェル環境では入れておいて損のない、便利なツールだと思ってます。


 

IBM Bluemix でアプリケーションサーバーを作った場合、そのサーバーインスタンスの数やメモリ量については管理コンソール画面から(自分が持っているリソースの上限まで)動的に変更できます:
2015032615


サーバーのワークロードがある程度安定しているのであれば、これらの数値を手動で設定すればいいのですが、実際には変化するワークロードに対応するため、何らかの運用ルールを決めた上で自動的にスケールイン/アウトするように設定できると便利です。

IBM Bluemix 環境の場合、このオートスケール機能もサービスの1つとして提供されています。このオートスケールサービス自体は無料でお使いいただけます。


「無料」という意味では1点注意していただきたいのですが、IBM Bluemix はサインアップ後の30日間は無料、有料アカウント移行後もこのオートスケールサービス自体は無料でお使いいただけます。有料アカウント移行後の無料枠があり、その範囲内でご利用いただくぶんには料金は発生しません。 ただし、有料アカウント移行後にこのオートスケールサービス機能でサーバーインスタンスがスケールアウトした結果、いつの間にか無料枠を超えた状態で運用されてしまっている、という可能性がありえます。オートスケールを利用する場合の設定内容と利用料金についてはご注意ください。


では、Bluemix でのオートスケールサービスの使い方について紹介します。まずはオートスケールの対象となるアプリケーションランタイムを用意します。ここでは IBM Bluemix 上に WordPress 環境を構築して、この環境をオートスケールさせてみます(WordPress 環境である必要はありません。何か Bluemix 上で動くランタイム環境があれば、それをお使いいただいても構いません)。Bluemix 上に WordPress 環境を構築する場合の手順は以下を参照ください:
IBM Bluemix 上で WordPress 環境を構築する (少し古い記事)
IBM Bluemix で無料の WordPress 環境を構築する (比較的新しい記事、こちらがオススメ)

オートスケールの設定をするにあたり、まずは CPU やメモリの利用状況を確認します。作成した WordPress ランタイムアプリケーション(下図では dotnsf-wp)を Bluemix ダッシュボードから開き、そのプログラミング言語環境が書かれた部分(下図では PHP)をクリックします:
2015032601


このランタイムアプリケーションの現在の状態が表示されます。下図ではメモリ 128MB の1サーバーインスタンスが稼働していて、CPU 利用率は 0.1%、メモリは 128MB のうち 68.4MB が利用中、そしてディスクは 1GB のうちの 234.8MB を使っている、ということがわかります:
2015032602


この状態を元にオートスケールの条件を決めます。今はテスト的な目的もあるので、わざとスケールアウトを発生させたいため、
  メモリ利用率が 50% を超えたらスケールアウト
  メモリ利用率が 30% を下回ったらスケールイン

という(このままでもスケールアウトが発生するような)条件で運用してみます。この条件は CPU かメモリに対して設定することができますので、実際の環境を確認した上で、簡単に発生させられそうな条件を決めてください。


ではこのランタイムにオートスケールサービスを追加します。ダッシュボードに戻ってこのランタイムを選択した上で、「サービスまたは API の追加」をクリックします:
2015032603


追加できるサービスの一覧が表示されます。DevOps カテゴリーの "Auto-Scaling" サービスを選択してクリックします:
2015032604



Auto-Scaling サービスの説明と利用条件が表示され、無料サービスであることが分かります。右上のアプリ選択欄では、このサービスを追加したいランタイム(この例では dotnsf-wp)が選択されていることを確認して「作成」ボタンをクリックします:
2015032605


サービスを1つ追加したので、ランタイムを再ステージングするか聞かれます。ここで「再ステージ」をクリックしてランタイムサーバーを再ステージングします:
2015032606


しばらく待つと、先ほどのランタイムアプリケーションに Auto-Scaling サービスが追加されていることが確認できるようになります。次はオートスケールの条件を設定したいので、この Auto-Scaling サービスのアイコンをクリックします:
2015032607


オートスケールサービスのパネルが開きます。最初はまだ何のルール(ポリシー)も定義していないので作成する必要があります。「ポリシー構成」タブ内の「自動スケーリングポリシーの作成」ボタンをクリックします:
2015032608


最初のポリシールールを編集する画面になります。名称などは適当に付けるとして、設定すべきは具体的なルールの部分です。まずスケールイン時の最小インスタンス数はデフォルトの1のままとして、スケールアウト時の最大インスタンスは念のため4にしてみます。現在は1インスタンスのメモリが128MBなので、4インスタンスまで稼働させても無料枠内、という安心設定です(笑)。 またメトリックタイプを「メモリー」に、スケールアウトの条件を(メモリ使用率)50% 超えと設定します。これで何もしなくても今のままでスケールアウトしてくれます。 更に細かい条件を設定するため「拡張構成」をクリックします:
2015032609


拡張構成では、どれだけの期間測定してスケールイン/アウトを判断するか?を指定できます。デフォルトでは600秒(10分)になっていますが、今回はなるべくすぐに確認したいので最小値の120秒(2分)に設定し、最後に「保存」ボタンをクリックします:
2015032610


確認メッセージが表示されればポリシーの定義ができました:
2015032611


そのままダッシュボードの言語タブ(下図では "PHP")に移ってしばらく様子を見ていると、スケールアウトの様子が見えてくるはずです。これは1インスタンス増えて2インスタンスになった様子:
2015032612


条件を厳し目に設定したので(苦笑)、2分おきにインスタンスがどんどん増えていきます。設定最大値である4インスタンスまで順調に(?)増えていきました:
2015032613


この状態でダッシュボードの "Auto-Scaling" サービスを選択して、スケーリング履歴タブを開くと、この時のスケールアウトの様子が記録されており、一覧で参照することもできます:
2015032614


IBM Bluemix はアプリケーションサーバーであるランタイムと、データベースなど各種サービスを組み合わせて環境を構築するのが特徴ですが、オートスケーリングに関してもサービスの1つとして提供されており、簡単に使えることも分かっていただけるのではないかと思っています。メモリだけでなく CPU 状態でも設定できるので、用途・目的に合わせて使ってみてください。


前回の、この記事の続きです:
Bluemix の Node-RED サービスで IoT アプリを作る(1/2)


前回は IBM Bluemix 上の Node-RED サービスの初歩的な使い方を中心に説明し、IoT センサーシミュレータと接続し、送られてくるセンサーの値を取得して表示する、というシンプルなワークフローを作りました。 今回は Node-RED の他のブロック機能を組み合わせて、もう少し実用に近いワークフローを記述してみます。

具体的には、以下の様な分岐処理を含むワークフローを Node-RED エディタで記述します:
- IoT センサーから、機器温度の値を取得して、
- 機器温度が40度以下であれば、(安全な状態とみなして)その値を画面に出力して終了
- 機器温度が40度を超えている場合、警告メッセージを画面に出力し、
- 同時にその時の状態をデータベースに記録する


最初に Node-RED エディタでの、上記ワークフローの完成形を示しておきます。前回のシンプルなものと比べると、スタートは IoT デバイスになっていて変わりませんが、プロセスが長くなり、途中に条件分岐が含まれていたり、見たことのない記号のブロックがあったりと、それなりに複雑なフローになっていることがわかると思います:
2015032301


では実際に Node-RED エディタ上でこのワークフローを作っていきます。まずは前回の内容を参照して、Node-RED Starter ボイラープレートを使ってプロジェクトを作ります。この図ではアプリケーションの名称は dotnsf-nodered としましたが、実際には個別の名前を付けることになります。なお、このボイラープレートに含まれる Cloudant データベースサービスの名称が dotnsf-nodedred-cloudantNoSQLDB となっていることを確認しておきます(この名称を後で使います):
2015032401


アプリケーションから Node-RED エディタを開き、"iotibm" ブロックをキャンバスに1つ追加します。このあたりは前回の内容と同じです:
2015032407


iotibm ブロックをダブルクリックして編集状態に移り、このデバイスの属性を入力します。デバイスID(Device Id)欄にはこのデバイスの MAC アドレスを指定しますが、これは最後に入れるので空にしておいても構いません。これが(仮想の) IoT デバイスであり、ここから送られてくるセンサーの値を使ってワークフローを記述します:
2015032402


次にワークフローを進める中でセンサーの機器温度を何度も調べるのは効率が悪いため、「センサーの機器温度だけを取り出す」という処理を最初に行っておきます。こうすることでいちいち JSON テキストを解析することなく、一度取り出した機器温度の値を多くの処理の中でそのまま使うことができるようになるからです。キャンバスの左ペイン内 function カテゴリから "function" と書かれたブロックを1つ追加し、先ほどの "iotibm" ブロックと線で結びます:
2015032408


追加した function ブロックをダブルクリックして編集状態にして、下図のように msg.payload.d.objectTemp(機器温度)に payload という名前を付けて返す、という関数処理を加えます。これによってこの次のブロックからははメッセージの payload プロパティを参照することで機器温度を取得することができるようになります:
2015032401


次のブロックを追加します。同様に function カテゴリから "switch" と書かれたブロックを1つ追加し、先ほどの "function" ブロックと線で結びます:
2015032409


追加した switch ブロックをダブルクリックして編集状態にして、下図のような分岐ルールにします(2つ目のルールは +rule と書かれたボタンをクリックして追加します)。これによって msg.payload の値(=機器温度)が 40 を超えている(=警告)場合はルート1へ、40以下(=正常)の場合はルート2へ、処理を分岐するようにしています:
2015032403


次は分岐の正常処理を用意します。正常処理の場合は単純に画面に機器温度を出力するだけとします。パレットに output カテゴリから "debug" と書かれたブロックを1つ追加し、switch ブロックの下側(ルート2)から線で結びます:
2015032410


追加した debug ブロックをダブルクリックして編集状態にして、下図のような内容(msg.payload の値を debug タブに出力する)にします。機器温度が正常範囲内と判断された場合はこれだけです:
2015032404



次に分岐の警告処理を用意します。警告処理の場合は画面への出力内容にも "Warning!" という文字列を追加して出力し、更にその温度を Cloudant にも記録するようにします。まずは出力内容の文字列を変更するために function カテゴリから "template" ブロックを1つ追加し、switch ブロックの上側(ルート1)から線で結びます。更に追加した template ブロックから、先ほど追加した debug ブロックに向けて線を結びます:
2015032411



追加した template ブロックをダブルクリックして編集状態にして、下図のような内容に書き換えます。payload の値の前に "Warning!: " という文字列を付加するような処理を施しています:
2015032405



更に、この警告時の機器温度をデータベースに追加するためのブロックを追加します。storage カテゴリ内の右側にコネクタがない "Cloudant" ブロックを1つ追加し、template ブロックから線で結びます。なお右側にコネクタがある "Cloudant" ブロックはデータを検索する処理で、検索結果を次のブロックに渡します。右側にコネクタがない "Cloudant" ブロックは単純なデータ追加処理です。今回は後者のブロックを使います:
2015032412


追加した Cloudant ブロックをダブルクリックして編集状態にして、下図のような内容に書き換えます。今回の処理では警告メッセージを、Bluemix のボイラープレートに含まれる Cloudant サービス(dotnsf-nodered-cloudantNoSQLDB)内の iotdata というデータベース内に insert します:
2015032406


この時点で Node-RED エディタのキャンバスに必要なパーツは全て揃いました。

ただ、ここで指定した Cloudant 内の iotdata というデータベースは標準で存在しているわけではないので、このままデータを挿入しようとしてもエラーとなります。そのためこのデータベースを事前に作成しておきます。

改めて Bluemix のダッシュボード画面に戻り、目的のアプリケーション(この例では dotnsf-nodered)を開きます。そして Cloudant サービスのアイコン部分をクリックします:
2015032402


Cloudant NoSQL データベースの説明ページが表示されたら、右上の "LAUNCH" ボタンをクリックして、このデータベースの管理機能にアクセスします:
2015032403


このサービスで利用中の Cloudant データベースの管理画面が表示されます。このボイラープレートを使った時点で "nodered" という名前のデータベースが作られているはずです。今回は新たに機器情報格納用のデータベースを作りたいので、右上の "Add New Database" ボタンをクリックします:
2015032404


追加したいデータベースの名前(今回は "iotdata")を指定して、"Create" ボタンをクリックします:
2015032405


iotdata データベースが追加されたことが確認できたら、Cloudant 側の準備は完了です。この段階ではまだ中身がないのでデータ数(# of Docs)はゼロのはずです:
2015032406


最後に機器温度データを送信する(仮想) IoT 機器の MAC アドレスを指定します。今回は仮想 IoT シミュレータを使うことにしますので、このページにアクセスして仮想 IoT 機器を表示し、右にスワイプして "Object Tempreture"(機器温度)と書かれた画面まで移動します。デフォルト値の 24 度(40度以下)になっていることを確認し、そして画面右上に書かれた MAC アドレスをメモします:
2015032401


この MAC アドレスのコロンを省略して大文字を小文字に変換したものを、Node-RED エディタに最初に追加した IoT Sensor のデバイス ID として指定します。IoT Sensor をダブルクリックし、Device Id 欄に指定して OK をクリックします:
2015032402


これで今回作成した IoT 機器アプリのワークフローは完成です。では実際に動かしてみましょう。Node-RED エディタの右ペインで debug タブを選んだ上で、右上の "Deploy" ボタンをクリックして実行します:
2015032403


画面上部に "Successfully deployed" と表示されれば実行成功です:
2015032404


すぐに画面右ペインの debug タブ内に指定した IoT 機器から送られてくるセンサー情報の機器温度(何も変えていなければ24度)が2秒おきに表示されます:
2015032405


この時点で Cloudant の管理画面を更新しても、まだ(警告になるデータが送られてきていないので) iotdata データベースにはデータが格納されていないはずです:
2015032406


では仮想 IoT 機器の機器温度が上がった状態をシミュレートしてみます。シミュレータのボタンをクリックして、機器温度を45度まで少しずつ上げてみます:
2015032407



41度以上になったタイミングから、ワークフロー内で記述した分岐処理で警告状態と判断され、表示メッセージがカスタマイズされたものに切り替わります:
2015032408


また、41度以上のデータについては Cloudant に格納する、というブロックも追加していました。この状態で iotdata データベースを更新すると、いくつかのデータが格納されていることを確認できます。 詳細を確認してみるには iotdata と書かれた箇所をクリックします:
2015032409


iotdata データベースに格納された情報が一覧表示されます。この状態のままだと個別データが表示されないので、どれか1つ選んで右上の鉛筆マークをクリックしてみます:
2015032410


選択したデータの全情報が表示されます。"payload" 値として設定した通りの "Warning: XXX" という警告メッセージが格納されていることを確認できます:
2015032411



以上、前回よりは少し複雑なワークフロー処理を Node-RED エディタを使って実現してみました。事実上、コーディング処理は1行も記述していませんが、IoT 機器からのセンサーデータを受け取って、特定の条件にもとづいてデータベース内に格納する、という処理が実現できました。


2回に分けて小出しにしたつもりでしたが、いずれもブログエントリとしては大作になってしまいました。ただコーディングを行うような手続きはほとんどなく、画面のドラッグ&ドロップと属性値の設定程度でこのくらいはできてしまったことになります。この手軽感を多くの人に体験してほしいと思っています。

また、この Node-RED エディタには今回紹介した以外にも色々な処理や格納、他サービスとの連携などがやはりコーディング処理を行うことなく実現できる便利なブロックが多く用意されています。機会があれば、もう少し違った Node-RED の使い方も今後紹介していこうと思っています。






























このページのトップヘ