20160115nodered design patterns

© Hitachi, Ltd. 2016. All rights reserved.
株式会社日立製作所
2015/1/15
横井一仁
Node-REDのデザインパターン

Node-RED環境構築手順(Bluemixの場合)
1
(1) Node-REDのインスタンス作成
(1-1) ダッシュボートの「アプリの作成」をクリック (1-2) ウェブアプリケーションを選択
(1-3) ボイラーテンプレート
を選択
(2-1) インスタンスの管理画面から
「サービスまたはAPIの追加」をクリック
(1-4) Node-RED Starter
を選択
(2-2) dashDBを選択
※「Bluemix」、「dashDB」は、 International Business Machines Corporationの登録商標、製品名称です。
(2) データベース(dashDB)とバインド

Node-REDとは
2
処理ノードをGUI上でつなぐ操作で、
簡単にアプリケーションを開発できる開発環境
• コーディング未経験者でも、アプリケーション開発が容易
• 複雑な処理を行いたい場合は、JavaScriptで記述も可能
• PC、タブレットで開発できるため、どこでも開発可能
IoT端末の異常をメール通知
タブレット端末上での編集操作
処理ノード間は、
主に変数msg.payloadを用いて
JSON形式のデータが渡される
フリック入力と似た操作で
編集できる

デザインパターンとは
3
• ソフトウェア設計者が発見し、編み出した設計ノウハウを
蓄積し、名前をつけ、再利用しやすいようにカタログ化したもの。
• 一般にGoFが提唱したオブジェクト指向言語向け23パターンを指す。
ja.wikipedia.org/wiki/デザインパターン_(ソフトウェア)引用: http://
# 分類パターン
1 生成に関する
パターン
Abstract factory
2 Builder
3 Factory method
4 Prototype
5 Singleton
6 構造に関する
パターン
Adapter
7 Bridge
8 Composite
9 Decorator
10 Facade
11 Flyweight
12 Proxy
# 分類パターン
13 振る舞いに関する
パターン
Chain of responsibility
14 Command
15 Interpreter
16 Iterator
17 Mediator
18 Memento
19 Observer
20 State
21 Strategy
22 Template method
23 Visitor

4
Node-REDにおいてもデザインパターンがあると考えカタログ化を実施
• デザインパターンの観点
• Node-REDの開発でよく使われるパターン
• 従来JavaScriptのコードで実装していた処理を、処理ノードの
接続で表現することで、可読性、開発効率を向上させるパターン
• 処理ノードを繋ぎ変えるのみで修正が可能なパターン
(タブレットで開発ができるパターン)
qiita.com/zuhito/items/e9abfd6f1ba188f908ed※ URL: http://
本日は、下の記事で紹介した10個のデザインパターンを説明
「nodered デザインパターン」
でウェブ検索すると
見つかります。

5
# パターン名パターンの説明
使用頻度
高
ノード接続
を活用
タッチUIで
修正可
1 Store & Search データ格納、検索を行うパターン ◎
2 UI & API
ブラウザで受け付けた値を用いAPIを問
合せ、結果をブラウザ表示するパターン
◎
3 Timeout
処理時間が一定時間を越えた場合、
タイムアウトさせるパターン
◎ ○
4 while 繰り返し処理を行うパターン ○ ◎ ○
5 Sequence
複数の処理ノードから取得した値を
集計するパターン
○
6 Aggregator
複数の処理ノードから取得した値を
集計するパターン
○
7 Separator
1つの処理ノードから複数の異なる
値を出力するパターン
○
8 MapReduce MapReduce処理を行うパターン ○
9 Matcher
ネットワーク上を探索し、入力値が
条件に合致するか判定するパターン
◎
10 State 状態遷移を扱うパターン ○ ○
※◎: 特に該当、○: 該当

Node-REDの開発環境
6
デバッグ画面
デプロイボタン
使用可能な
処理ノード一覧
開発で使用する処理ノードを
配置する場所

デザインパターンの説明で使用する処理ノード
7
※ノードの色やアイコンが同じでも、左右の接続の有無で機能が異なる点に注意。
# 処理ノード説明
1 inject クリックを契機として処理を開始する。
2 debug 前の処理ノードから渡された値をデバッグ画面に出力する。
3 http、
http response
HTTPサーバとして機能させる。(始点httpノードと、
終点http responseノードを組み合わせて使用する)
4 DB
DBを問い合わせる。
5 http request REST APIを問い合わせる。
6 function JavaScriptでコードを記述する。
7 template 定型文を定義する。
8 switch 条件分岐を行う。
9 delay 指定時間遅延させて、後続の処理ノードを実行する。
10 change 変数の削除等を行う。
11 comment コメント文を記載する。

ソースコードのインポート方法
8
[1] ソースコードをコピー [2] Node-RED開発環境の右上メニューの
Import→Clipboardから貼り付け
※ dashDB等、ソースコードをインポートしただけでは使用できない処理ノードもある。
dashDBノードはインポート後、プロパティからDBを選択する必要がある。

1. Store & Searchパターン
9
データをデータベースへ格納し、検索するパターン
• Storeパターンは、functionノードを用いてデータの選択と
格納する列名の指定を行い、後続のDBノードでデータを格納する。
• Searchパターンは、DBノードでSQL文を実行し、
検索結果を後続のdebugノードへ渡す。

10
列DATA
タイムスタンプ1
表TMP
格納
[1] injectノードのクリックを契機として、
タイムスタンプを表へ追記
• プログラム例(タイムスタンプを格納、検索)
検索
[2] injectノードのクリックを契機として、
表の内容をログ画面に出力
列DATA
表TMP
タイムスタンプ3“Tue Dec 22 2015 13:37:10”
現在の時刻

11
(2) Deploy後、表作成を実行
(デバッグ画面に[]が
出力されれば作成成功)
(1) 表を作成するCREATE TABLE文を定義
Service: dashDB-xx
Query: CREATE TABLE TMP (DATA VARCHAR(255));
• タイムスタンプ格納用の表を作成
↑左右に接続があるdashDBノード
※参考: 表を削除
(4) Deploy後、表削除を実行
(デバッグ画面に[]が
出力されれば削除成功)
(3) 表を削除するDROP TABLE文を定義
Service: dashDB-xx
Query: DROP TABLE TMP;

12
(4)SELTCT文を定義
Service: dashDB-xx
Query: SELECT * FROM TMP;
(2)格納先テーブルを登録
Service: dashDB-xx
Table: TMP
(1) タイムスタンプを列DATAに格納すると定義
Function:
(3) Deploy後、
タイムスタンプ格納を実行
(デバッグ画面の出力なし)
(5) Deploy後、検索を実行
(デバッグ画面に
検索結果が出力される)
• Storeパターンのデータ格納を複数回実行した後、Searchパターンを
実行すると、格納したタイムスタンプがデバッグ画面へ出力される。
• Storeパターンを用いて、タイムスタンプを格納
• Searchパターンを用いて、タイムスタンプを検索
msg.payload = {DATA: new Date(msg.payload).toString()};
return msg;
左のみ接続があるdashDBノード↑

2. UI & APIパターン
13
ブラウザで入力を受け付け、API問合せと結果表示を行うパターン
• 1つ目のUIパターンは、入力フォームHTMLをブラウザへ表示し、
ユーザから入力値を受け取る。
• 2つ目のUIパターンは、APIを問い合わせた結果を
格納した出力HTMLをブラウザへ表示する。
• APIパターンは、GETパラメータに指定された値を用いて、
検索等の処理を行い、その結果を返すREST API。

14
• プログラム例(指定した表の行数を表示)
入力フォーム
出力結果
[1]表名を入力
[4] 指定した表の行数を表示
[2]送信をクリック
[3] REST APIを問い合わせて、
SELECT COUNT(*) FROM TMPを実行

15
• ブラウザでhttp://
にアクセスし、表の行数が表示されれば成功
• APIパターン(引数qに指定したテーブルの行数を検索)
(1)APIのURL登録
URL: /api
(2)HTTP GETの引数qを用いてSQL文作成
Template:
(3)検索テーブルを登録
Service: dashDB-xxSELECT COUNT(*) FROM {{payload.q}};
※ dashDBノードに直接SQL文を記述する方法は、表名を変数として使用
できないため、Templateノードで作成したSQL文をdashDBノードへ渡した。
<アプリ名>.mybluemix.net/api?q=TMP
表の行数

16
• ブラウザでhttp://
にアクセスし、入力フォームが表示されれば成功
• UIパターン(入力フォーム)
(1) URLを登録
URL: /input
(2) 入力フォームのHTMLを記述
Template: <FORM action=output>
テーブル名:
<INPUT type=text name=q>
<INPUT type=submit>
</FORM>
<アプリ名>.mybluemix.net/input
※ 説明簡略化のため、HTMLの<HTML>、<BODY>タグ等の記述は省略

17
• UIパターン(出力HTML)
(1) URLを登録
URL: /output
(2) 問い合わせ用のURLを作成
Function:
(4) 変数msg.headersを削除
Rules: Delete msg.headers
(http request実行後は、Content-Typeが
JSONであるため)
(5) 出力HTMLを記述
Template:
• 入力フォームで表名TMPを入力し、行数が表示されれば成功
<HTML><BODY>
テーブルの行数は{{payload.1}}です。
</BODY></HTML>
msg.url = msg.req.host + "/api?q=" + encodeURI(msg.payload.q);
return msg;
(3) 問合せ結果の
形式をJSONに変更
Return:
a parsed JSON object

3. Timeoutパターン
18
処理に時間がかかる場合や、処理が停止した場合、
タイムアウト処理を行うパターン
• 処理に時間がかかった場合、タイムアウト表示処理を
先に実行するようにする。
• UIパターンにて、ノード間の処理が進まないと、ユーザは
長時間待たされるため、タイムアウト処理を入れると良い。
上の処理(青)に時間がかかった場合、
下の処理(赤)が先回りする。

19
入力フォーム(存在しない表名を指定)
出力結果(正常処理)
• 従来のUI&APIパターンの処理
(表が存在しないとユーザは長時間待たされ、エラーが返る)
API問合せ時間が5秒以上
(存在しない表名を指定)
API問合せが5秒以内
(表名TMPを指定)
出力結果(タイムアウト時)
• プログラム例
(APIが応答しない場合、タイムアウトメッセージを表示)
3分程
経過後
出力結果(エラー)
入力フォーム

20
• Timeoutパターン(httpノードと http responseノードの間に、
delayノードと templateノードを追加)
(2) タイムアウト時に表示するHTMLを記述
Template:
<HTML><BODY>タイムアウトしました。</BODY></HTML>
(1) delayノードを追加
(デフォルト待ち時間5秒)
入力フォーム
5秒
経過後
出力結果
• 存在しない表名(TMP以外)を指定し、
5秒後にタイムアウトの表示されれば成功

4. whileパターン
21
繰り返し処理を実現するパターン
• 以下の様なwhile文のコードをノードの接続関係で表現
• 定型のwhileパターンを用いることでノード接続変更の操作だけで、
既存の処理を繰り返し処理に対応させることができる。
var i = 0;
while (i < 4) {
console.log(i + "回目");
i++;
}
console.log("ループ完了");

22
• プログラム例(1回のinject実行で4回デバッグメッセージを表示)
• whileパターン (4)値iをインクリメント
Function: msg.i++;
return msg;
(3)メッセージを記述
Template: {{i}}回目
(1)初期値i=0を設定
Template: 0
Property: msg.i
(2)ループ条件を設定
Property: msg.i
条件: < 4 → 1
otherwise → 2
(5)メッセージを記述
Template: ループ終了
Injectノードを
クリック
出力結果
(4回デバッグを表示)

23
• 参考: whileパターンの応用
• 配列の長さ分、繰り返し処理をしたい場合
→ switchノードは変数を条件に指定できないため、条件文をi!=0とし定数化。
→ この変更に伴い、iの初期値を配列の長さとし、デクリメントでループさせる。
• 従来の処理を繰り返し処理に対応させたい場合
→ 配列のi番目のデータをpayloadに格納し、
後続の処理として従来処理を挿入する。
• 繰り返し処理で得た結果を、ループ後の処理で利用したい場合
→ 一時的にデータを退避するSequenceパターン(後述)を用いる。
条件文をi!=0にする
Sequenceパターンを
用いて処理結果を
別変数へ退避
Sequenceパターンを用いて退避した値を呼び出す
qiita.com/zuhito/items/ed5f505edaac2baeadd9
文字列内の各単語用いてREST APIを問い合わせる処理
http://
変数iをデクリメント
変数iの初期値を
配列の長さにする
配列のi番目のデータをpayloadに格納

5. Sequenceパターン
24
複数の処理ノードから得た値を集計するパターン
• 処理ノードを経由すると、変数payloadの値は上書きされるため、
後続の処理ノード(集計処理など)で必要となる値を、
一時的に他の変数に格納する。
• 集計を行う処理ノードで、一時的に格納した変数を呼び出す。

25
• プログラム例(451+326=777を計算)
• 1つ目のfunctionノードがmsg.payloadに451を返す。
• 集計を行うfunctionノードが2つの値の和を求める。
Injectノードを
クリック
出力結果

26
(2)値を一時変数tmpへ退避する処理を記述
Function: msg.tmp = msg.payload;
return msg;
(3)値326を返す処理を記述
Function: msg.payload = 326;
return msg;
(4)2つの値の和を計算する処理を記述
Function: msg.payload = msg.tmp + msg.payload;
return msg;
(1)値451を返す処理を記述
return msg;
• Sequenceパターン

6. Aggregatorパターン
27
複数の処理ノードから得た値を集計するパターン
• 集計する値と数を管理するため、
グローバル変数context.globalを用いる。
• 集計を行うfunctionノードは、指定した数の入力を受け取った後、
後続の処理ノードに処理を渡す(return msg;を実行した時のみ
処理を引き継ぐ仕様を活用)。
• Sequenceパターンと比較すると、どの処理ノードの結果を
集計しているか、視覚的に分かりやすい。

28
• プログラム例(451+326=777を計算)
• 集計を行うfunctionノードが2つの値の和を求める。
Injectノードを
クリック
出力結果
※Sequenceパターンのプログラム例と同じ

29
• Aggregatorパターン
(4) グローバル変数に入力数定義、
データ格納先を用意する処理を参照
Function:
// グローバル変数に入力数を定義
context.global.n = 2;
// グローバル変数のデータ格納先を用意
context.global.data = new Array(2);
return msg;
(5) 2つの値の和を計算する処理を参照
Function:
//入力数を1減らす
context.global.n--;
// 値をデータ格納先に一時保存
context.global.data[context.global.n] = msg.payload;
// 定義した入力数に達した場合に、和を求めreturn
if (context.global.n === 0) {
var sum = 0;
for (var i = 0; i < context.global.data.length; i++) {
sum += context.global.data[i];
}
msg.payload = sum;
return msg;
}
(1) デザインパターンのページからAggregator
パターンのソースコードを貼り付ける。
(2)値451を返す処理を参照
return msg;
(3)値326を返す処理を参照
return msg;

7. Separatorパターン
30
1つのfunctionノードから2つの異なる値を出力するパターン
• functionノードのreturnをサイズ2の配列にし、
その配列の中に出力したい値を格納する。
• functionノードの出力数(Outputsの値)を2に設定する。

7. Separatorパターン
31
(1) 異なる2値を出力するよう記述
Outputs: 2
Function: msg.payload = 451; // 1つ目の出力を格納
var msg2 = {};
msg2.payload = 326; // 2つ目の出力を格納
return [msg, msg2]; // サイズ2の配列をretrun
• プログラム例(451と326を出力)
• 1つ目の出力のmsg.payloadに451を返す。
• 2つ目の出力のmsg.payloadに326を返す。
• Separatorパターン
Injectノードを
クリック
出力結果
(2つの値を出力)

8. MapReduceパターン
32
MapReduce処理を実現するパターン
• SeparatorパターンとAggregatorパターンを組み合わせたパターン
• MapとReduceの間のデータ転送処理をノード接続で記述
• MapReduceを理解するのに向いている(性能向上は期待できない)
• Map、Reduceの数を変更する場合は、手作業で増やす必要がある。

33
• プログラム例(ワードカウント)
• Map処理: テキストデータを入力とし、単語(Key)とその単語の
出現頻度(Value)のペアをReduce処理へ渡す。
• Shuffle処理: Map処理がデータを受け渡すReducerは、Keyの値を基に
決定する。(今回は単語の先頭文字で決定)
• Reduce処理: 同じ単語(Key)の出現頻度(Value)の和を計算する。
入力データ
Map処理
Map処理
Map処理
Reduce処理
Reduce処理
<this,1>,<pen, 1>
This is a pen.
Give me a pen.
This pen is small.
<is, 2>,<give, 1>,
<me, 1>,<a, 2>
<this, 2>,<pen, 3>,
<small, 1>
出力結果
<is,1>,<a, 1>

34
(3) Map処理を参照
Outputs: 2
Function:
var input = msg.payload.toLowerCase()
.replace( /.$/, “”).split(/ |, /);
var key_value = [];
for (var i=0; i<input.length; i++){
var key = input[i];
if (key in key_value)
{
key_value[key]++;
} else {
key_value[key] = 1;
}
}
var key1_value = [];
var key2_value = [];
for (var key in key_value){
if (‘a’<=key[0] && key[0]<=‘m’)
{
key1_value.push([key,k ey_value[key]]);
} else {
key2_value.push([key, key_value[key]]);
}
}
msg.payload = key1_value;
var msg2 = {};
msg2.payload = key2_value;
return [msg, msg2];
(2) Map数の定義を参照
Function:
var map = 3; // Map数を定義
context.global.n1 = map;
context.global.data1 = new Array(map);
return msg;
(4) Reduce処理を参照
Function:
// 入力数を減らす
context.global.n1--;
// msg.payloadのデータを格納
context.global.data1[context.global.n1] = msg.payload;
// 定義した入力数が来たら、集計処理を行い、msg.payloadを返す
if (context.global.n1 === 0){
// msg.payloadの合計値を算出
var tmp = [];
for (var i=0; i<context.global.data1.length; i++) {
var input = context.global.data1[i];
for (var j=0; j<input.length; j++) {
var key = input[j][0];
var value = input[j][1];
if (key in tmp) {
tmp[key] += value;
} else {
tmp[key] = value;
}
}
}
var output = [];
for (var key in tmp) {
output.push([key, tmp[key]]);
}
msg.payload = output;
return msg;
}
出力結果
(1) デザインパターンのページからMapReduce
パターンのソースコードを貼り付ける。
(5) ワードカウント
を実行

35
• MapReduceパターンの編集(Map処理を4つに変更)
(2) 入力データ(templateノード)と
Map処理をコピー＆接続
(1) Map数を3から4に変更
Function:
var map = 4; // Map数を定義
return msg;
(3) Map処理の2出力を
2つのReduce処理へ接続
(前処理結果から“this”、”pen”、
”is”、”small”の値が1ずつ増加)
出力結果

9. Matcherパターン
36
処理ノードのネットワークを探索し、入力値が条件に合致するか判定するパターン
• 各functionノードは、条件に合致した場合のみ通過し、後続のノードに処理を渡す。
• 全体の条件に合致している場合は、functionノードから成るネットワーク上から
出力が得られる。
• 後から全体の条件を修正したい場合は、ノードの接続を変更するのみで修正可
(タブレット上の操作のみで修正可)

37
• プログラム例(英文の文型判定)
英文を入力とする
Injectノードを順にクリック
出力結果
(文型の判定結果)

38
• Matcherパターン
(1) デザインパターンのページから、
Matcherパターンのソースコードを貼り付ける。
(2) 各英文をクリックすると、
文型の判定結果が出力される。

39
• Matcherパターンの編集
(主語に”冠詞形容詞名詞”の並びを許可する条件に変更)
(1) 主語に“冠詞形容詞名詞”を含む文を追加
Payload: string
The tall man walked.
(2) 他の形容詞のノードをコピー&ペーストし、
冠詞と名詞の間に挿入

10. Stateパターン
40
状態遷移を表現するパターン
• 状態を表すfunctionノードと、
遷移先を決定するswitchノードから成る。
(functionノードとswitchノードの内容は、全て同じ)
• 遷移のノード接続のみで、状態遷移を記述できる。

41
• プログラム例(状態遷移表)
• 文字列を検査するための状態遷移表(状態aが開始点)
• 以下のうち、不合格(状態e)になる文字列はどれか判定する。
(ア) 0101 (イ) -1 (ウ) 12.2 (エ) 4.5.1 (オ) 451+
文字
符号数字小数点
現在の
状態
a a b e
b e b c
c e d e
d e d e

42
(2) Switchノードに変数msg.cを渡す処理を参照
Function: var input = msg.payload;
var len = input.length;
if (msg.i == null) {
msg.i = 0;
} else {
msg.i++;
}
msg.c = input.charAt(msg.i);
msg.state = msg.i + "回目: 状態=a, 文字=" + msg.c;
if (msg.i < len) {
return msg;
}
(1) デザインパターンのページから、
Stateパターンのソースコードを
貼り付ける。
(3)遷移先条件を参照
Property: msg.c
条件:
matches regex +|- → 1
matches regex d → 2
== . → 3
(4) 各入力を
クリック
(判定結果が
出力される)

参考ページ
43
• Storeパターン
• ラズパイの情報をMQTT経由で取得し、dashDBに格納する例
• UI & APIパターン
• ブラウザの入力フォームから、Watson APIを問い合わせ、
結果を表示する例
dotnsf.blog.jp/archives/1047589155.html
「Node-RED(QuickStart) のデータを dashDB に格納する」
http://
qiita.com/KenichiSekine/items/7005df36093fabf00b41
「BluemixのNode-REDで簡単Webアプリ開発」
http://

まとめ
44
• Node-REDのデザインパターン10個を紹介
• 特にStore&Search～Sequenceパターンは実開発で有用
• Node-REDはハッカソンや実証実験など短時間の開発に向いている。
• 複雑な処理がカプセル化されているため、迅速に開発できる。
• DB、UI、API、ロジックなどのチームの役割分担が明確である。
• 役割毎に開発したプログラムをマージすることも容易である。
デザインパターンは、チーム開発時の共通認識、
共通言語として重要となると考える。

株式会社日立製作所
2015/1/15
横井一仁
END
45

20160115nodered design patterns

More Related Content

What's hot

Viewers also liked

Similar to 20160115nodered design patterns

More from BMXUG

20160115nodered design patterns