與外部系統整合

本頁介紹整合外部系統時由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秒之間。 請參閱本區段本頁面

本頁內容