このガイドでは、APIを介して商品カタログを検索し、顧客の希望商品を照合し、在庫を確認して在庫状況に応じてフローを分岐させる再利用可能なFin手順の作り方を説明します。この手順を使って、新規注文の作成や既存注文の更新をバックエンドの注文APIで行えます。
独自のAPIエンドポイントとパラメータ名を使用してください。例示のURL、リクエストボディ、フィールド名はバックエンドが公開するものに置き換えてください。手順を初めて作成する場合は、まずFin手順の作成をお読みください。
注意：
データコネクター：以下の3つの特定のコネクターが必要です。
商品カタログを返すもの（GET）。
注文アイテムを作成するもの（POST）。
既存の注文を更新するもの（PUT）。
標準的なレスポンス形式：APIは一貫したデータ構造を返す必要があります。
エラー処理：堅牢な手順にするため、条件ステップではData Connectorsが返す
status_codeとerrorのレスポンス属性を使用してください。これにより、Finは特定のHTTPエラーコード（例：400、500）で分岐でき、単純な成功/失敗パスに頼りません。
ヒント：コミュニティエキスパートやIntercomソリューションアーキテクトとProcedures Meetup Office Hoursでつながりましょう。隔週開催のこのセッションでは、実践的なリアルタイムサポートやライブQ&Aを提供し、Fin手順とデータコネクターの設定と最適化を支援します。
データコネクターの設定
Finが正しいアクションを識別しやすいように、わかりやすい名前（例：Get Product Catalog、Create Order Item、Update Order Item）で3つのコネクターを作成してください。
コネクターが必要とする入力を収集します。Temporary Attributesは直接Data Connectorの入力として渡せます。データがすでに一時変数にある場合、Finは自動的にマッピングし顧客に尋ねません。値が保存されていない場合のみ、顧客から収集する入力として設定してください。https://api.example.comやフィールド名は独自のエンドポイントとJSONキーに置き換えてください。コネクターの設定、認証、実行に関するよくある質問はFinとデータコネクターのFAQをご覧ください。
1. 商品カタログ取得（GET）
目的：id、名前、価格、在庫を含む商品リストを返します。
メソッド：GET。
URL：https://api.example.com/items（またはカタログのエンドポイント）
ヘッダー：Content-Type: application/json（必要に応じて認証付き）
レスポンス：商品オブジェクトの配列。
Example response:
[
{ "id": "sku-100", "name": "Classic T-Shirt", "price": 19.99, "stock": 120 },
{ "id": "sku-101", "name": "Running Shoes", "price": 89.50, "stock": 45 },
{ "id": "sku-104", "name": "Nintendo Switch", "price": 119.00, "stock": 0 }
]
2. 注文アイテム作成（POST）
目的：新規注文または特定の注文アイテムを作成します。
メソッド：POST。
URL：https://api.example.com/orders（または注文作成のエンドポイント）
ヘッダー：Content-Type: application/json（認証付き）
リクエストボディ：product_idとquantityを含める必要があります。
{
"product_id": "<product id>",
"quantity": <integer>
}
Finにproduct_idとquantityを収集させたい場合は、コネクターの入力を設定してください。
3. 注文アイテム更新（PUT）
目的：既存の注文にアイテムを追加または更新します。
メソッド：PUT。
URL：https://api.example.com/orders/{{order_id}}（またはPUT /orders/{order_id}/items）
ヘッダー：Content-Type: application/json（認証付き）
リクエストボディ：product_idとquantityを含める必要があります。
{
"product_id": "<product id>",
"quantity": <integer>
}必須入力：order_id、product_id、quantity
パス変数order_idとリクエストボディを示すAPI接続。
order_id、product_id、quantityのデータ入力を収集。
手順フローの構築
会話の途中データを保存するために一時変数を使用します。推奨変数はTemporary.SelectedProductID、Temporary.StockLevel、Temporary.OrderActionです。
ステップ1：商品問い合わせと検索
顧客に促す：「どの商品がよろしいですか？」と尋ねます。
データコネクターを呼び出す：Get Product Catalogを使用します。
ロジック：返されたリストから、Temporary.SelectedProductNameに最も合致する商品名（またはSKU）を検索します。
一致した場合、以下を設定します：
Temporary.SelectedProductID = 商品ID
Temporary.SelectedProductName = カタログの正規商品名
Temporary.StockLevel = 商品の在庫数（整数に変換）
検証：一致が見つからない場合は、顧客に確認を促すか、カタログから類似上位商品を提案し、別の商品を選んだ場合はステップ1に戻ります。
実装ノート
照合ロジックは単純な部分文字列一致や高度なあいまい一致でも構いません。Finの条件ステップが確実に動作するように決定論的にしてください。
ステップ2：在庫確認と分岐
手順UIで標準のIF/ELSEロジックブロックを使用してTemporary.StockLevelを確認します。これは単純な値の比較なので、コード条件は不要です。ビジュアル条件ビルダーを使い、属性としてTemporary.StockLevelを選択してください。
IF Temporary.StockLevel > 0：ステップ3へ進む。
ELSE："在庫切れ"セクション（ステップ8）へルート。
ステップ3：新規注文か既存注文かを尋ねる
プロンプト：「この商品について新しい注文を作成しますか、それとも既存の注文に追加しますか？」
受け付ける回答：
新規 → Temporary.OrderAction = "new" → ステップ4
既存 → Temporary.OrderAction = "existing" → ステップ4
不明瞭な場合は確認の質問をして繰り返す。
ステップ4 — 数量を尋ねて検証（小さな更新）
プロンプト：「いくつご希望ですか？」→整数に解析→Temporary.Quantityに保存。
検証：
Temporary.Quantity ≤ 0 の場合は再度尋ねる。
Temporary.Quantity > Temporary.StockLevel の場合は、利用可能な在庫を顧客に知らせ、次のいずれかを行う：
最大可能数量を提示し、少ない数量の確認を求める（ステップ4内でループ）、または
バックオーダー/通知オプションを提供（ステップ8）。
数量が検証されたら、ステップ5（注文アクションの決定）へ進む。
数量のプロンプトと検証のアクションブロック。
ステップ5：注文アクションの決定（IF / ELSE IF）
注文作成と更新をインラインで処理する代わりに、それぞれのパスを専用のサブ手順にルーティングします。これによりメインフローがすっきりし、各パスを独立してテスト可能にします。IF / ELSE IF条件ブロックを追加し、各分岐で@Run sub-procedureを使用してください。複雑な日付ベースの比較についてはFin Proceduresのコード条件の書き方を参照。
IF Temporary.OrderAction == 'new'：@Run sub-procedureを使ってCreate New Orderサブ手順を呼び出す。
ELSE IF Temporary.OrderAction == 'existing'：@Run sub-procedureを使ってUpdate Existing Orderサブ手順を呼び出す。
ELSE（フォールバック）：チームにエスカレーション
ステップ6：新規注文作成（サブ手順）
このステップを専用のサブ手順（例：「Create New Order」）に移動し、メインフローを読みやすくします。そのサブ手順内でCreate Order Itemコネクタを呼び出します。Temporary.SelectedProductIDやTemporary.Quantityなどの一時属性はコネクタの入力に直接マッピング可能で、手動のプロンプトは不要です：
product_id = Temporary.SelectedProductID
quantity = Temporary.Quantity
レスポンスをTemporary.NewOrderIDにキャプチャし（返された場合）、コネクタのstatus_codeをTemporary.CreateOrderStatusに保存。
成功時の返信：
「[Temporary.Quantity] × [Temporary.SelectedProductName]で新規注文を作成しました。注文ID：[Temporary.NewOrderID]。他に何かできますか？」アクション後の選択肢を提供（アイテム追加、数量変更、チェックアウト、終了）。セッション継続時はTemporary.NewOrderIDを保持。
コネクタ呼び出し直後に条件ステップを追加し、Temporary.CreateOrderStatusで分岐します。status_codeとerror属性は属性セレクタの下部にある場合があるので、見えない場合はスクロールしてください。分岐は以下の通り：IF status_code == 200 または 201：成功確認へ進む。ELSE IF status_code == 400：顧客にリクエストが無効（例：不正なproduct IDや数量）であることを伝え、入力の修正を促し再試行を提供。ELSE IF status_code >= 500：サーバーエラーを謝罪し、error属性を内部メモに記録してE-Comm Support Teamにエスカレーション。ELSE（予期しないステータス）：Temporary.CreateOrderStatusをログに記録しE-Comm Support Teamにエスカレーション。コネクタ障害のデバッグとステータスコード解釈の詳細はFin Proceduresとデータコネクタのトラブルシューティングを参照。
マッピングされた入力とレスポンスマッピング（order_id → Temporary.NewOrderID）を使ったコネクタ呼び出し。
アクション後の確認メッセージとオプション。
ステップ7：既存注文の更新（サブ手順）
プロンプト：「この商品を追加したい既存の注文IDを教えてください。」→Temporary.ExistingOrderIDに保存。
呼び出し：Update Order Itemコネクタに以下を渡す：
order_id = Temporary.ExistingOrderID
product_id = Temporary.SelectedProductID
quantity = Temporary.Quantity
コネクタのstatus_codeをTemporary.UpdateOrderStatusに、errorフィールド（存在する場合）をTemporary.UpdateOrderErrorに保存。
成功時の返信：
「[Temporary.Quantity] × [Temporary.SelectedProductName]を注文[Temporary.ExistingOrderID]に追加しました。ほかに何か？」
アクション後の選択肢を提供（アイテム追加、数量変更、チェックアウト、終了）。コネクタ呼び出し直後に条件ステップを追加し、Temporary.UpdateOrderStatusで分岐します。ステップ6と同様にstatus_codeとerror属性は属性セレクタの下部にある場合があります。分岐は以下の通り：IF status_code == 200：成功確認へ進む。ELSE IF status_code == 400：注文IDが無効の可能性を顧客に伝え、確認と再入力を促し再試行を提供。ELSE IF status_code >= 500：サーバーエラーを謝罪し、Temporary.UpdateOrderErrorを内部メモに表示しE-Comm Support Teamにエスカレーション。ELSE（予期しないステータス）：ステータスをログに記録しE-Comm Support Teamにエスカレーション。ライブ会話でのコネクタ障害診断の完全なガイドはFin Proceduresとデータコネクタのトラブルシューティングを参照。
ヒント：Data Connectorが返すstatus_codeとerror属性は属性セレクタの下部に表示されることがあります。すぐに見えない場合はスクロールしてください。堅牢なエラーハンドリング分岐を作るために重要です。
ExistingOrderIDの収集とそれを使ったUpdateコネクタ呼び出し。
アクション後の確認メッセージとオプション。
ステップ8：在庫切れ
Temporary.StockLevel ≤ 0の場合、または要求数量が利用可能数を超え、顧客が数量減少を拒否した場合にトリガー。
アクション：
謝罪し、明確な選択肢を提示：
類似商品を表示（カタログからの上位マッチ）。
バックオーダー/入荷通知を提供 — 連絡先の希望を記録。
利用可能な場合は部分数量を提供。
顧客が通知/バックオーダーを選択した場合 → 希望を記録して確認。
顧客が代替案を選択した場合 → 新しい選択肢でステップ1（商品問い合わせと検索）に戻る。
顧客の応答に応じて終了またはループ。
次のステップ
コアの注文フローが機能したら、より複雑な結果に対応するためにこれらの高度なパターンを検討してください。
注文作成後にWorkflowへ引き渡す
新規注文が成功した後、Workflow（例：「Send Order Confirmation」）に引き渡して、メール領収書やCRM更新などの下流の自動化を処理します。Create New Orderサブ手順の最後にHandoff to workflowステップを使用してください。手順は引き渡しで終了し、Workflow終了後に再開しないため、これを最後のステップにしてください。
注文結果に基づいて手順を切り替える
注文が特定の状態（例：バックオーダーや支払い失敗）になる場合は、専用の手順（例：「Backorder Management」や「Payment Failure Recovery」）に切り替え、すべての結果を1つの手順で処理しないようにします。これにより個別の手順が集中し、管理が容易になります。
繰り返されるAPI失敗の状況でコンテキスト付きでエスカレーション
同じコネクタが再試行で失敗した場合（例：連続2回の500エラー）、人間のチームにエスカレーションし、Temporary.CreateOrderStatusまたはTemporary.UpdateOrderErrorを要約した内部メモを含めて、チームメンバーが顧客に再度尋ねることなく完全なコンテキストを把握できるようにします。
複数商品カートのためにサブ手順を連結
1回のセッションで複数の商品を注文する顧客をサポートするために、注文処理成功後にProduct Inquiryサブ手順に戻り、アイテムカウンターを増やします。顧客が終了を確認したらループを終了します。