Switchノードを使う(その3)

前回に引き続きSwitchノードを使ってみます。Switchノード最終回。

メッセージシーケンスの再構築

最初のサンプルは「flows > node-red > function > switch > 07 - Recreate message sequence」です。流れは以下の通りです。
  1. injectノードでmsg.payloadに数値の配列を指定
  2. splitノードで配列をmsgオブジェクトに分解
  3. switchノードでmsg.payloadの値に応じて出力ポートを振り分け
  4. joinノードでmsgオブジェクトの値を配列に結合
  5. ログ出力

splitノードとjoinノードの挙動確認は別の機会に譲ることにして、今回はswitchノードに着目します。msg.payloadの値を文字列の"0"と比較して出力ポートを振り分けています。数値と文字列と比較するのはサンプルとしてはあまり良くない気はしますが、結果的に期待通り動作します(もしかして意図したものかもしれませんが)。「>」の挙動は、恐らくJavaScriptの「>」演算子と同じだと思うので、厳密な挙動は仕様を確認しておいた方が良さそうです。素直にやるなら同じ型どうしで比較した方が良いと思います。


プロパティによる出力ポートの振り分け

次のサンプルは「flows > node-red > function > switch > 08 - Route message based on properties」です。


順番にプロパティを確認していきます。まずはinjectノードから。msg.payloadに数値27を、msg.topicに文字列"temperature"を指定しています。


続いてswitchノード。msg.topicの値で条件分岐しています。上のinjectノードから発行されたmsgオブジェクトはmsg.topicが"templerature"なので出力ポート1に振り分けられます。そのmsg.payloadには数値27が格納されています。


最後にdebugノード。msg.payloadを出力しています。上のフローの場合、数値27を出力します。


このサンプルからわかるのは、途中で色々なノードを経由しても、msgオブジェクトのプロパティを書き換えない限り、その値は基本的に次のノードに流れていくことです。

コンテキストの値による出力ポートの振り分け

最後のサンプルは「flows > node-red > function > switch > 08 - Route message based on context value」です。このサンプルではコンテキストの値をSwitchノードの条件分岐に利用しています。パッと見複雑なので順番に見ていきます。


まずは無印のinjectノード(一番左上のやつ)から。msg.payloadに現在時刻を指定しています。


続いてswitchノード。コンテキスト「flow.state」の値で条件分岐しています。対象となる値は1, 2, 3いずれか。


下半分のフローでflow.stateに値を指定しています。縦に4つ並んだinjectノードの一つを確認すると、msg.payloadに数値(以下のノードでは0)を指定しています。injectノードではflow.stateの値を変更していません。


続いてchangeノード。ここでmsg.payloadの値をflow.stateに代入して更新しています。


これでflow.stateを更新すると、一番最初に確認したinjectノードから発行されたフローがswitchノードで条件分岐することになります。

まとめ

Switchノードはシンプルだと思っていましたが、意外とサンプルが多くて骨が折れました。おかげで、なんとなく挙動はわかった気がします。ここまでで見てきたサンプルでは以下のようなことがわかりました。
  • msgプロパティの値に応じた条件分岐
  • 最初にヒットした条件で分岐
  • 全条件のチェック
  • 入力値の型に応じた条件分岐
  • JSONata式の結果に応じた条件分岐
  • コンテキストの値に応じた条件分岐
さて、次はchangeノードですかね。

コメント

このブログの人気の投稿

Execノードを使う

Joinノードを使う(その4)

SendGridのX-SMTPAPIヘッダの使い方(Section Tags、Substitution Tags編)