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 (20)

Viewers also liked (10)

Similar to 20160115nodered design patterns (20)

More from BMXUG (20)

Recently uploaded (9)

20160115nodered design patterns