與外部系統整合

本頁介紹了Journey Orchestration在整合外部系統時提供的不同護欄以及最佳做法：如何使用封頂API優化對外部系統的保護，如何配置行程超時，以及重試如何工作。

Journey Orchestration允許您通過自定義資料源和自定義操作配置到外部系統的連接。例如，這允許您使用來自外部預訂系統的資料來豐富您的行程，或使用諸如Epsilon或Facebook等第三方系統發送消息。

在整合外部系統時，可能會遇到一些問題，系統可能速度慢，可能停止響應，或者可能無法處理較大的卷。 Journey Orchestration提供了多個護欄，以保護您的系統免受過載。

所有外部系統在效能上都不同。您需要根據使用案例調整配置。

當Journey Orchestration執行對外部API的調用時，將按以下方式執行技術護欄：

封頂

內置的封頂API提供了上游技術保護，有助於保護您的外部系統。

對於外部資料源，每秒最大調用數設定為15。如果呼叫數超過每秒15次，則放棄剩餘的呼叫。您可以增加私有外部資料源的此限制。聯繫Adobe，將端點包括在允許清單中。對於公共外部資料源，這是不可能的。

對於自定義操作，您需要評估外部API的容量。例如，如果Journey Optimizer每秒發送1000個呼叫，而您的系統每秒只能支援100個呼叫，則您需要定義一個上限設定規則，以便您的系統不會飽和。

在沙盒級別為特定終結點（調用的URL）定義上限設定規則。在運行時，Journey Orchestration驗證是否定義了封頂規則，並在調用該終結點期間應用定義的速率。如果呼叫數超過定義的速率，則丟棄剩餘的呼叫，並將其計為報告錯誤。

封頂規則特定於一個端點，但全局於沙箱的所有行程。這意味著，沙箱的所有行程之間都共用了封頂槽。

例如，假設您為外部系統定義了每秒100個調用的上限規則。您的系統在10個不同的旅程中由自定義操作調用。如果一次行程每秒接收200個呼叫，它將使用100個可用插槽，並放棄剩餘的100個插槽。由於超出最高速度，其他9次旅程將沒有任何空間。此粒度有助於保護外部系統免受過載和崩潰的影響。

要瞭解有關上限設定API以及如何配置上限設定規則的詳細資訊，請參閱此頁。

如果滿足上限規則，則應用超時規則。

在每個行程中，可以定義超時持續時間。這允許您在調用外部系統時設定最大持續時間。在行程的屬性中配置超時持續時間。請參見此頁面。

此超時對所有外部調用（自定義操作和自定義資料源中的外部API調用）是全局的。預設情況下，它設定為5秒。

在定義的超時持續時間內，Journey Orchestration嘗試調用外部系統。在第一次調用之後，最多可執行三次重試，直到達到超時持續時間結束。無法更改重試次數。

每次重試都使用一個插槽。如果每秒有100個呼叫的上限，並且每個呼叫需要兩次重試，則速率將降至每秒30個呼叫(每個呼叫使用3個插槽：第一次呼叫和兩次重試)。

超時持續時間值取決於使用案例。如果想快速發送消息，則不想設定長時間超時。此外，超時時間越長，排入隊列的項目就越多。這會大大影響效能。如果Journey Orchestration每秒執行1000次呼叫，保持5或15秒的資料可以迅速壓垮系統。

讓我們舉一個超時5秒的示例。

第一次呼叫持續時間不到5秒：呼叫成功，未執行重試。
第一次呼叫持續時間超過5秒：呼叫已取消，且無重試。在報告中，它被計為超時錯誤。
第一次調用在2秒後失敗（外部系統返回錯誤）:如果有可用的封頂插槽，則剩餘3秒重試。
- 如果在5秒結束前三次重試中的一次成功，則會執行調用，並且沒有錯誤。
- 如果在重試期間達到超時持續時間的結束，則取消調用，並將其計為報告中的超時錯誤。

如何配置封頂規則？是否有預設的上限設定規則？

預設情況下，沒有封頂規則。封閉規則在沙盒級別上使用封閉API為特定終結點（調用的URL）定義。請參閱此部分和此頁。

執行了多少次重試？是否可以更改重試次數或定義兩次重試之間的最小等待時間？

對於給定的呼叫，在第一次呼叫之後最多可執行三次重試，直到達到超時持續時間結束。無法更改重試次數和每次重試之間的時間。請參閱本節。

在哪裡可以配置超時？有最大值嗎？

在每個行程中，可以定義超時持續時間。在行程的屬性中配置超時持續時間。超時持續時間必須介於1秒和30秒之間。請參閱此部分和此頁。