知覚的フローデザイン

知覚的フローデザインは、あるデータ形式と構造から別のデータ形式と構造へのデータのマッピングを視覚化できる、Anypoint Studio の機能です。

Anypoint コネクタを含めてその前または後に Transform Message コンポーネントを配置したフローについて考えます。Mule Runtime は、リソースへの稼働中の接続を使用して、ペイロードとプロパティに関するメタデータを取得し、そのデータを DataWeave に送り込んで、予想される入力または出力を提供します。これにより、Mule イベントの構造をユーザが自分で調べる手間を回避できます。

たとえば、組織の Salesforce 取引先を Twitter に関連付けて特定の業績評価指標を公開する必要があるとします。

Salesforce と Twitter の 2 つのコネクタを Studio キャンバスにドロップし、コネクタを組織の取引先に接続するように設定することで、コネクタ間に Transform Message コンポーネントをドロップできます。次に、その [Mule Properties (Mule プロパティ)] ビューを調べると、Mule Runtime が各プロバイダからデータ型と構造の情報をインテリジェントに取得し、データマッピングの入力と出力の規範を作成していることを確認できます。

この規範が整ったら、マッピングを設定し、DataWeave コードの空白を埋めるだけです。

たとえば、Twitter コネクタから状況更新データを取得するとします。ツイートテキストを記録したいと考えていますが、このコネクタで使用されているプロパティ名に慣れていません。Twitter のドキュメントを参照し、必要なプロパティの名前を確認する必要はありません。ロガーメッセージプロセッサを Twitter コネクタの直後に配置して、それに書き込むだけです。ロガーの [Message (メッセージ)] 項目に #[payload. と書き込んで *ctrl + スペースバー*を押すと、Twitter コネクタで実行されている要求から返されたプロパティを含め、ペイロードに関連付けられたすべてのプロパティとメソッドのリストが表示されます。

payload+autocomplete

メタデータの宣言

Mule 4 では、信頼性のある再利用可能なフローアーチファクトとアプリケーションを作成するための、規範に基づく新しい方法が導入されます。たとえば、デザイン時にエラーを事前に検出することで、より信頼性の高いアプリケーションを作成できます。
ランタイムのセマンティックを変更することなくこれを実現するため、Mule 4 ではメタデータが使用されます。より信頼性の高い再利用可能なアプリケーションを作成するには、メタデータが規範的なガイダンスとして機能する必要があります。

メタデータ宣言は、 . 絶対に必要な場合 (たとえば、値のメタデータを自分で定義する場合) や、 . アノテーション付きの値への密着度が最も高い場合 (たとえば、値のメタデータがコンポーネントによって使用または予想される場合) にのみ使用することをお勧めします。

たとえば、Tansform Message コンポーネントでメタデータコントラクトを定義すべきではありません。Dataweave はデータの作成者とコンシューマ間のデータ仲介デバイスとして機能するため、その境界でコントラクトを定義する必要があります。

メタデータ宣言をより具体化する

Transform Message コンポーネントの出力メタデータを、予想されるメタデータとして使用すると、誤る可能性があります。メタデータ型を明示的に宣言することで、Transform Message コンポーネントから出力されるデータの実際のメタデータ型をマスクすることになります。DataWeave の Transform Message 実装では、この出力データ型を完全に推定することができます。
ベストプラクティスとして、このデータが使用またはコンシュームされる場所で予想されるメタデータを定義し、メタデータが自動的に推定されない (静的/動的メタデータでない) ことをお勧めします。

同時に、Transform Message コンポーネントの入力メタデータを定義することで、マッピングで使用する、Transform Message コンポーネントに入力される実際の受信メタデータもマスクされます。
データが作成される場所でメタデータを定義することをお勧めします。ここでも、メタデータが自動的に推定されない (静的/動的メタデータでない) 場合に限られます。たとえば、実際のメッセージペイロードを生成したソースまたは拡張操作内です。

この概念を念頭に置き、再利用可能なアーチファクトのスコープの外部にデータが存在する場合、そのデータもアーチファクトのコントラクトの一部として宣言する必要があることを常に覚えておく必要があります。
たとえば、フローとサブフローは、他のプロセッサと同様に、メタデータコントラクトを宣言することが予想されます。

入力と出力のメタデータを宣言し、必要なイベントと、呼び出し元に返すイベントを具体的に指定する必要があります。出力イベントの宣言は、指定されていない場合、フローが再帰的ではないときにフローのコンテンツから自動的に推定されます。

コネクタと同様に、フローメタデータの宣言が、関連するコントラクトに基づいて自動的に推定される可能性がある特別なケースがあります。それは、APIKit または SOAPKit のリソースフローのケースです。このケースでは、対応する API コントラクトを使用して、リソースフローのメタデータコントラクトが推定されます。
この直接的な結果として、フローへのフロー参照 (flow-refs) を介したイベントコンテキスト全体の暗黙的なメタデータの伝播はありません。フローまたはサブフローを再利用することが予想される場合、このフローは入力および出力イベントに関してそのデータコントラクトを宣言する必要があります。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub