Transform カードを使用したマッピングの例 (Flow Designer):page-support-status: eolScheduled
チュートリアル「Flow Designer での最初の Mule アプリケーションの作成」の手順を実行したユーザーは、すでに 2 回のマッピングを行っています。この両方のマッピングをもう一度見てみましょう。
最初の例
初回は、Choice カードの出力を、NTO Order API で必要とされる入力にマップする必要がありました。
| Choice カードで出力されるデータ型 | NTO Order API で入力として必要とされるデータ型 |
|---|---|
Product Information (製品情報) データ型
[
{
"productID": string,
"category": string,
"SKU": string,
"productName": string,
"inventory": string
}
]
Salesforce Opportunity (Salesforce 商談) データ型
{
"Amount": number,
"Id": string,
"CloseDate": string,
"Name": string
}
|
Order Information (注文情報) データ型
{
"OppId": string,
"OrderAmount": number,
"orderdate": string,
"productInfo": {
"productID": string,
"category": string,
"SKU": string,
"productName": string,
"inventory": number
}
}
|
マッピングを行うため、Transform カードを使用して、[Input (入力)] 側の要素をクリックして [Output (出力)] 側の要素にドラッグしました。(Transform カードの「入力」と「出力」は Transform カード自体を基準とする相対的な用語です。Transform カードへの「入力」は Choice カードの出力であり、Transform カードの「出力」は Order API への入力です)。
Order API (POST メッセージの送信先の REST API) は Choice カードの出力に含まれる一部のデータを必要としなかったため、マッピングを行う必要がありました。また、API で必要とされるデータの一部の要素の名前が、Choice カードの出力内の対応する要素とは異っていました。
| Choice カードの要素 | マップ先の Order API の要素 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2 番目の例
チュートリアルの 2 回目のマッピングでは、Twilio カードの入力に対してデータ型を明示的に設定する必要はありませんでした。Twilio カードで必要とされるデータ構造を Transform カードで判別することができました。また、データ要素もマップしませんでした。代わりに、Transform カードの出力で DataWeave スクリプトを使用して、Transform カードの入力から、顧客に送信するメッセージにデータを取り込みました。また、To および From 項目の値を特定の電話番号に明示的に設定しました。これは、Transform カードの [Script (スクリプト)] ペインで確認できます。
To および From 項目の電話番号が示されている Transform カードの [Script (スクリプト)] ペイン[Mappings (マッピング)] ペインには次のビューが表示されました。
出力ペイロードの 3 つの項目に付けられた f(x) マーカーは、これらの項目に、文字列または DataWeave 式を介して提供された値が入力されていることを示します。入力ペイロードの OrderID、TrackingNo、および ETA が出力ペイロードの Body にすべてマップされています。これは、Body のスクリプトがこの 3 つのペイロード要素を参照するためです。