フローの構造

Node-REDを初めて使う時は、おそらくエディタ内の同じタブに全てのノードを追加することから始めるでしょう。他のユーザが共有したフローの例を読み込んだり、様々なものをテストするためにプロトタイプのフローを構築したりすることもあります。

時が経つにつれて、これがノードやワイヤーの混在を引き起こし、フローの特定部分を探すことが困難になります。

開発プロジェクトを始める時に、フローをどの様に構造化するかについて検討しておくと、フローが整理されている状態を維持することを助け、保守も容易になります。

Node-REDでフローを整理する主な方法は、エディタ内で複数のタブにフローを分けることです。それを行うために用いることができるいくつかの異なる戦略があります。

もし、アプリケーションが分離された構成要素を特定できる場合は、これらを分離された各タブに配置することを検討してください。

ホームオートションのアプリケーションの場合は、物理スペースを反映するために、各部屋のフローロジックを分離されたタブに配置します。もしくは、全ての照明に関するフローを一つのタブに配置し、暖房装置に関するフローを他のもう1つのタブに配置する様に、機能に基づいてフローを分離することもできます。

もし、HTTP APIのバックエンドを構築している場合は、各タブはAPIが接続する分離されたリソースのタイプを表すこともあります。

この目標は、個別のフローの初めから最後まで「読む」ことを容易にすることです。単一のタブに配置することは、これを手助けします。

他に考慮すべきことは、同一のNode-REDアプリケーション上で、他の開発者と共同作業をしているかどうかです。この場合は、開発者がそれぞれのタブを使用すると、変更のマージが容易となります。異なる役割や専門分野がある開発者がいる場合は、それがフローの構成にどの様に影響するか検討してください。

再利用できるフローの作成

フローを作成する時に、複数の場所で再利用したいと思う共通部分を見つけることがあります。フローをメンテナンスすることが難しくなるため、これら共通部分のコピーがフロー内に複数作成させることは避ける様にしてください。修正をする時に変更箇所が複数となり、見落とす可能性があります。

Node-REDでは、再利用できるフローを作成する2つの異なる方法を提供しています。それは、リンクノードとサブフローです。

リンクノード によって、エディタのタブ間をジャンプできるフローを作成できます。フローの終了点から別のフローの開始点までの仮想的なワイヤーを追加できます。

サブフロー によって、フローとして作成した内部実装を持つ新しいノードをパレットに作成できます。作成後は、通常のノードと同じ場所にサブフローの新規インスタンスを追加できるようになります。

これら2つのアプローチの間には、いくつかの重要な違いがあります。リンクノードは、メッセージがリンクを介して渡されるフローの中では使うことができません。リンクノードは、フローの開始点と終了点のみ使うことができます。また、リンクノードは1つ以上の他のリンクノードと接続することもできます。これによって、メッセージを他の複数のフローへ渡したり、複数のフローが一つのフローにメッセージを渡したりできる様になります。それらを単一タブで用いる右から左へ向かうワイヤーが沢山存在することをなくし、ワークスペース上でフローがまとまることを助けます。

サブフローは通常のノードとして表示されるため、フロー中のどこでも利用できます。ただし、サブフローの各インスタンスは他のインスタンスから独立して存在しています。サブフロー内のフローコンテキストは、各インスタンスにスコープされます。また、サブフローが外部システムとの接続を作成する場合は、各インスタンスは独自の接続を生成します。

サブフローのカスタマイズ

サブフローを作成する時、何らかの方法で動作をカスタマイズできる様にしたい場合があります。例えば、バブリッシュするMQTTトピックを変えたい場合です。

それを行うための一つのバターンは、サブフローへ渡される各メッセージに msg.topic を設定することです。ただし、目的の値を設定するためには、各サブフローの前にChangeノードを追加する必要があります。

これを行う簡単な方法は、サブフロープロパティを用いることです。これらは、サブフローインスタンス上で設定でき、サブフロー内で環境変数として用いることができるプロパティです。

MQTTの例では、 ${MY_TOPIC} にパブリッシュする様にノードを最初に設定できます。

次に、サブフロープロパティとして MY_TOPIC を追加します。

ユーザが個々のインスタンスを編集すると、そのインスタンスのために MY_TOPIC というカスタム値が提供されます。

このやり方は、値を直接できる任意のノード設定フィールドに対して、用いることができます。ただし現在、チェックボックスや他のカスタムUI要素として提供されているフィールドに対しては機能しません。

状態情報の管理

もう一つの考慮すべきことは、フロー内の状態情報をどの様に管理するかです。例えば、フローを通過したメッセージの総数や、外部センサの状態をどのように保持するかが挙げられます。

Node-REDではランタイム内で状態管理をするためにコンテキストシステムが提供されています。このコンテキストシステムは、同一タブやサブフローのスコープとするか、グローバルに利用可能なものにするかを選択できます。

もし、状態情報が特定の一つのタブ上のノード群で必要とされる場合は、グローバルではなく、フローのスコープのコンテストを用いる必要があります。また、コンテキストの変数名は、分かりやすく簡単に識別できる様に、慎重に決める必要があります。

別の方法は、保持されたMQTTメッセージやデータベースの様なものを利用してNode-REDの外部で状態を管理する方法です。この方法は、管理を外部に依存することになり、コンテキストほど便利に統合されていないものですが、完全な代替手段ではなく、コンテキストと合わせて利用することもできます。例えば、複数のNode-REDインスタンス間で状態情報を共有したい場合、MQTTを用いることで値が変更される度にフローを実行することもできます。

別のプラットフォーム向けのフローのカスタマイズ

手動によるフローの変更なく、別のプラットフォーム向けにフローをカスタマイズするために、Node-REDでは環境変数が多くの場所で用いられています。

例えば、複数のデバイス上で同一のフローを動作させる場合、各デバイス上のフローはデバイス固有のMQTTトピックをサブスクライブする必要があります。

前述のサブフローの例の様に、 ${MY_TOPIC} にパプリッシュするようMQTTノードの設定をした後、Node-REDの起動前に環境変数としてその値を設定します。これによって、デバイス固有のカスタマイズを、全デバイス共通のフローと分離して管理できるようになります。

同様の方法は、異なるオペレーティングシステム上のフローにおいても利用できるでしょう。ただし、フローで用いられているファイルパスにおいては、OSによって異なる場合があります。

InjectノードとChangeノードでは、TypedInputにある”環境変数”オプションを用いて環境変数を参照できます。また、Functionノードにおいては、 env.get() 関数を使用できます。

エラーハンドリング

Node-REDでは、エラーに対応するフローを作成するために、CatchノードとStatusノードを提供しています。それらをどの様に使うかについてのより詳細な情報は、ユーザガイドを参照してください。

Catchノードと、それが対象とするノードの間には、直接的に視覚的な関連が見えないため、フローを読みやすさを維持するために配置をよく検討しておく必要があります。

Catchノードを、それが対象とするフローの一部分の近くに配置することは有効ですが、フローが過密になり過ぎない様に注意する必要があります。

別の方法は、全てのエラーハンドリングのフローをグループとしてメインフローの下に配置する方法です。これによって、’正常’パスとエラーパスを明確に区別できます。

Catchノードに対して分かりやすい名前をつけることも 処理対象のシナリオを容易に特定するために、 とても重要です。

以上のどのアプローチを選択する場合でも、異なるフロー間で一貫性を保つ様にしてください。