與外部系統整合

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

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

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

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

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

  1. 已應用上限規則:如果達到最大速率,則丟棄剩餘的呼叫。

  2. 超時並重試:如果滿足上限設定規則,則Journey Orchestration會嘗試執行呼叫,直到超時持續時間結束。

封頂

內置的封頂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秒之間。 請參閱 此部分此頁

本頁內容