在此頁面上：擷取自訂動作的API呼叫傳回的回應裝載，以便您根據外部系統的資料來協調歷程、個人化訊息及處理錯誤。
您可以在自訂動作中運用API呼叫回應，並根據這些回應協調您的歷程。
重要備註 custom-action-enhancements-notes
-
回應承載支援純量陣列：
code language-none "dummyScalarArray": [ "val1", "val2" ] -
回應承載中不支援異質陣列：
code language-none "dummyRandomArray": [ 20, "aafw", false ]
設定自訂動作 config-response
-
建立自訂動作。 請參見此頁面。
-
在回應 （成功回應）欄位內按一下。
-
貼上呼叫傳回之裝載的範例。 驗證欄位型別是否正確（字串、整數等）。 以下是呼叫期間擷取的回應裝載範例。 我們的本機端點會傳送熟客點數和設定檔的狀態。
code language-none { "customerID" : "xY12hye", "status":"gold", "points": 1290 }
每次呼叫 API 時，系統都會擷取有效負載範例中包含的所有欄位。
-
（選用）啟用錯誤回應裝載，以擷取呼叫失敗時傳回的格式，然後貼上範例裝載。 若要這麼做，請在自訂動作設定中選取定義失敗回應承載。 深入瞭解設定自訂動作中的設定裝載欄位。
code language-none { "errorResponse" : "customer not found" }錯誤回應裝載只有在您於自訂動作設定中啟用時才能使用。
-
我們也將customerID新增為查詢引數。
-
按一下儲存。
在歷程中善用回應 response-in-journey
只需將自訂動作新增至歷程即可。 然後，您可以在條件、其他動作和訊息個人化中運用回應裝載欄位。
如果您已定義錯誤回應承載，則會在內容屬性 > Journey Orchestration > 動作 > <action name> > errorResponse底下公開它。 您可以在逾時和錯誤分支中使用它來驅動遞補邏輯和錯誤處理。
例如，您可以新增條件以檢查熟客點數。 當人員進入餐廳時，您的本機端點會傳送包含設定檔忠誠度資訊的呼叫。 如果設定檔為黃金客戶，則可傳送推播。 如果在呼叫中偵測到錯誤，請傳送自訂動作以通知您的系統管理員。
-
新增您的事件和先前建立的熟客方案自訂動作。
-
在忠誠度自訂動作中，將客戶ID查詢引數對應至設定檔ID。 核取選項在逾時或錯誤的情況下新增替代路徑。
-
在第一個分支中，新增條件並使用進階編輯器在 Context 節點下運用動作回應欄位。
-
然後新增推播，並使用回應欄位個人化您的訊息。 在範例中，我們使用忠誠度點數和客戶狀態來個人化內容。 動作回應欄位位於內容屬性 > Journey Orchestration > 動作下。
note NOTE 每個輸入自訂動作的設定檔都會觸發呼叫。 即使回應一律相同，歷程仍會為每個設定檔執行一個呼叫。 -
在逾時和錯誤分支中，新增條件並利用內建的 jo_status_code 欄位。 在我們的範例中，我們使用
http_400錯誤型別。 請參閱本節。code language-none @action{ActionLoyalty.jo_status_code} == "http_400"如果已定義錯誤回應裝載，您也可定位其欄位，例如：
code language-none @action{ActionLoyalty.errorResponse.errorResponse} == "customer not found"
-
新增將傳送給您的組織的自訂動作。
測試模式記錄 test-mode-logs
您可以透過測試模式存取與自訂動作回應相關的狀態記錄。 如果您已在歷程中定義具有回應的自訂動作，您將會在這些記錄上看到 actionsHistory 區段，其中顯示外部端點傳回的裝載（作為該自訂動作的回應）。 定義錯誤回應裝載時，系統會將其納入失敗的呼叫。 這在偵錯方面可能非常有用。
錯誤狀態 error-status
jo_status_code欄位一律可用，即使未定義任何回應裝載。
以下是此欄位可能的值：
- http狀態代碼： http_
<HTTP API call returned code>，適用於執行個體http_200或http_400 - 逾時錯誤： 逾時
- 上限設定錯誤： 上限
- 內部錯誤： 內部錯誤
當傳回的http程式碼大於2xx或發生錯誤時，會將動作呼叫視為錯誤。 在這種情況下，歷程會流向專用逾時或錯誤分支。
如果已為自訂動作設定錯誤回應裝載，則失敗呼叫的 errorResponse 節點會公開其欄位。 如果未設定錯誤回應裝載，則無法使用該節點。
運算式語法 exp-syntax
語法如下：
#@action{myAction.myField}
以下是一些範例：
// action response field
@action{<action name>.<path to the field>}
@action{ActionLoyalty.status}
// action response field
@action{<action name>.<path to the field>, defaultValue: <default value expression>}
@action{ActionLoyalty.points, defaultValue: 0}
@action{ActionLoyalty.points, defaultValue: @event{myEvent.newPoints}}
在自訂動作回應中操控集合時，您可以仰賴currentActionField存取目前專案：
count(
@action{MyAction.MyCollection.all(
currentActionField.description == "abc"
)}
)
在原生管道中使用自訂動作回應 response-in-channels
自訂動作的回應裝載欄位可用於原生通道（電子郵件、推播、簡訊）以進行訊息個人化。 這包括重複處理外部API傳回的陣列和巢狀資料結構的能力。
如需在訊息中反複處理自訂動作回應資料的詳細範例和語法，請參閱使用Handlebars反複處理內容資料。
其他資源
如需詳細資訊，請參閱以下頁面：
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page explains how to capture the response payload returned by a custom action’s API call and leverage it to orchestrate journeys, personalize messages, and handle errors.
Intents:
- Configure a custom action to capture success and failure response payloads
- Leverage response payload fields in conditions, other actions, and message personalization
- Handle errors and timeouts using the jo_status_code field and the errorResponse node
- Inspect custom action responses through test mode logs
- Use the expression syntax to reference response fields, including default values and collections
Glossary:
- Response payload: The example payload pasted in the Response (success response) field whose fields are retrieved on each call (product-specific)
- Error response payload: The payload captured when a call fails, enabled by selecting Define a failure response payload, exposed under the errorResponse node (product-specific)
- jo_status_code: A built-in field, always available even when no response payload is defined, that carries the call outcome (product-specific)
- actionsHistory: A section shown in test mode logs that displays the payload returned by the external endpoint (product-specific)
- currentActionField: A reference used to access the current item when manipulating collections in a custom action response (product-specific)
- Test mode: The mode through which you access status logs related to custom action responses (product-specific)
Guardrails:
- Scalar arrays are supported in the response payload, but heterogeneous arrays are not supported.
- Only newly created custom actions include the jo_status_code field out-of-the-box; to use it with an existing custom action you need to update the action, for example by updating the description and saving.
- An action call is considered in error when the returned http code is greater than 2xx or if an error occurs, and the journey flows to the dedicated timeout or error branch.
- If an error response payload is configured, its fields are exposed under the errorResponse node for failed calls; if none is configured, that node is not available.
- Each profile entering the custom action triggers one call, even if the response is always the same.
Terminology:
- Canonical name: API call response in custom actions — Acronym: n/a — variants: custom action response, response payload
- Synonyms: “success response” = “Response field”
- Do not confuse: “Response” (success response payload) ≠ “Error Response” (failure response payload defined via Define a failure response payload)
- jo_status_code values: http_
(for example http_200 or http_400), timedout (timeout error), capped (capping error), internalError (internal error)``
`FAQ:
Q: Which array types are supported in the response payload? — Scalar arrays are supported; heterogeneous arrays are not supported. Q: Why does an existing custom action not expose the jo_status_code field? — Only newly created custom actions include it out-of-the-box; update the existing action, for example by updating the description and saving, to add it. Q: When is an action call considered in error? — When the returned http code is greater than 2xx or an error occurs, after which the journey flows to the dedicated timeout or error branch. Q: Where can the returned payload be inspected? — Through test mode logs, in the actionsHistory section that displays the payload returned by the external endpoint. Q: Can response payload fields be used in native channels? — Yes, response payload fields from custom actions can be used in native channels (email, push, SMS) for message personalization.`
``