メッセージの設計

フローを通過するメッセージは、プロパティを設定できるJavaScriptオブジェクトです。

それらメッセージは、通常 payload プロパティを持っています。これは、ほとんどのノードが使用するデフォルトのプロパティです。

Node-REDでのメッセージの詳細情報については、ユーザガイドのメッセージを利用するのセクションをお読みください。

このセクションでは、フロー内のメッセージの構造化を決定するさいに行う必要があるいくつかの方法について説明します。

フローを作成する時、メッセージが用いるプロパティは、主にフロー内のノードが必要とするかによって選択されます。

ほとんどのノードは、 msg.payload を用いることを想定しているため、これは選択の指針になります。

例えば、MQTTメッセージのpayloadにidが含まれたメッセージを受け取るフローを考えてみます。まず、そのidを用いて、一致するレコードを探すためにデータベースを問い合わせます。

MQTTからデータベースへのクエリ

このデータベースノードは、送信メッセージのペイロードに問合せ結果を格納します。つまり、ペイロードに格納されたidを上書きします。もし、後続のフローがそのid値を参照することがある場合は、上書きしないようにChangeノードを用いて他のプロパティへ値をコピーします。

Changeノードを用いて、ペイロードの値を msg.id へコピー

ここには重要な原則があります。それは、ノードはノードの機能に関係しないプロパティをメッセージから削除したり、修正したりしてはならないということです。

例えば、ほとんどの場合、functionノードは新しいメッセージオブジェクトを内部で定義するのではなく、受け取ったメッセージオブジェクトと同じオプジェクトを送信する必要があります。

デバッグサイドバーに表示された msg.topic メッセージ

多くのノードは msg.topic においても特別な意味を持って扱います。メッセージのソースを特定する目的や、または同一のフロー上で別々のメッセージの’流れ’を特定したい目的で、使用される場合があります。また、デバックサイドバーには、メッセージと合わせて出力されます。

例えば、MQTT Inノードは、受信したメッセージのトピックに msg.topic を設定します。これによって、後続のDelayノードは、メッセージの流量をトピック毎に制限できます。

フローに直接 msg.topic を用いるノードがない場合、メッセージに関する追加情報を与えるために使用できます。ただし、この値を用いる後続のフローがある場合は、注意が必要です。

再利用するためにノードやサブフローを設計する際は、処理対象のメッセージのプロパティや、値が設定されるプロパティは、全て公開するAPIの様に扱います。全てのAPIの様に、注意深く設計する必要があります。これは、フローに対しても同様に適用されます。

一つの方法は、全てのプロパティをpayloadの中に入れる方法です。例えば:

{
    "payload": {
        "temperature": 123,
        "humidity": 50,
        "pressure": 900
    }
}

この方法は、データをまとめて保持するのには便利ですが、一方で後続のノードが msg.payload の値に対して操作することを期待していると、プロパティを他に移動する操作が必要となってきます。

他の方法としては、Twitterノードに見られる様な方法があります。この方法では、最も’興味がある’情報であるツイートのテキストがpayloadに格納されます。同時に、APIから提供される完全なメタデータは、分離された msg.tweet プロパティに格納されます。

メッセージをどの様に設計するかについての正しい答えは一つではありませんが、最も一般的なケースで、ノードやフローをどの様に用いるかについて焦点を当てて検討する必要があります。

一般的なプログラミングと同様に、良いプロパティの名前を選択することも重要です。後からデバッグやフローの理解で役立つ様に、プロパティ自体を説明する名前であるべきです。例えば、 msg.t よりも msg.temperature の方がより理解しやすいです。

また、いくつかのノードにおいて reset や parts は特別な意味を持っています。この様な一般的に使われているプロパティ名も避けるべきです。