Completeノードを使う

今回は、Completeノードを使ってみます。説明文の冒頭には以下のようなことが書いてあります。

  • ノードからランタイムに対してメッセージ処理の完了が通知されると、本ノードによって次のフローを開始できます
  • 本ノードは出力ポートを持たないノードと共に用いる場合などに有用です
  • 例えば、Email送信ノードで送信後にフローを起動する場合がこれに当たります

フローの末端で処理が完了した後に次のフローを開始できるということのようです。出力ポートを持たないノードと言えば、DebugノードやHttp reponseノードなんかも該当しそうです。なんとなく動作のイメージは理解できますが、イマイチ使いどころがピンときません。とりあえず、サンプルフローを読み込んで動かしてみます。

Completeノードのサンプルフロー

メニューから「読み込み > サンプル > flows > node-red > common > complete > 01 - Handle completion of node execution」を選択してサンプルフローを読み込みます。Injectノードのボタンを選択してフローを実行すると、「Hello World!」のログが2件出力されます。


フローの設定を確認すると、最初のDebugノードの完了イベントをCompleteノードで拾って、2つ目のDebugノードが実行されています。ラインがなくてもノード間が論理的に繋がっていることになります。


Completeノードが受け取るmsgオブジェクト

Completeノードが受け取るmsgオブジェクトの内容が気になったので、以下のようなフローを作成してみました。CompleteノードはInject, Function, Debug各ノードの完了イベントを拾うようにしてあります。Funcitonノードではmsg.prop1に値「value1」を設定しています。


msgオブジェクトの識別子_msgidの値は全部同じです。最初のログはprop1プロパティが存在しないので、Injectノードの完了イベントを受けて出力されたものと考えられます。それ以降のログの内容はすべて同じです。これを見る限り、Completeノードは各ノードで受け渡しされたmsgオブジェクトと同じものを受け取っているようです。これならDebugノードを大量に配置しなくてもログ出力を1箇所に集約できそうです。逆に、出力されるログがフロー上のどの流れで出力されたものか追いづらくなるデメリットもありそうです。


まとめ

Debugノードを置きすぎてフローがゴチャゴチャになるのを避けるのに有効そうです。一方で、本来必要な処理はラインでつなげていくことになるでしょうから、ログ出力以外にCompleteノードを使うユースケースが思いつきません。他に有効な利用用途を知りたいものです。とりあえず、今の段階ではこんな方法もあるんだぐらいで頭の片隅に入れておこうと思います。

コメント

このブログの人気の投稿

Execノードを使う

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

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