使用案例:使用外部資料來源和自訂動作來限制輸送量

使用案例說明

Adobe Journey Optimizer可讓從業人員透過使用自訂動作和資料來源,將API呼叫傳送至外部系統。

這可以透過執行:

  • 資料來源:若要從外部系統收集資訊,並在歷程內容中加以使用,例如取得設定檔城市的天氣資訊,並據此建立專用的歷程流程。

  • 自訂動作:傳送資訊至外部系統,例如透過外部解決方案傳送電子郵件,此解決方案使用Journey Optimizer的協調功能以及設定檔資訊、受眾資料和歷程內容。

如果您使用外部資料來源或自訂動作,您可能想要限制歷程吞吐量,以保護外部系統:單一歷程最多5000個例項/秒,區段觸發歷程最多20000個例項/秒。 您可以在端點層級定義上限限制,以避免透過Journey Optimizer的上限API壓垮這些外部系統。 不過,系統會捨棄達到限制後的所有剩餘請求。

在本節中,您將找到可用來優化吞吐量的解決方法。 有關如何與外部系統整合的詳細資訊,請參閱 頁面.

實作

針對 區段觸發歷程,您可以定義將影響歷程吞吐量的讀取區段活動的限制率。 閱讀全文

您可以每秒將此值從500個修改為20 000個例項。 如果您需要的速度低於500/s,您也可以新增「百分比分割」條件,並搭配等待活動,將歷程分割為多個分支,並讓歷程在特定時間執行。

讓我們以 區段觸發歷程10 000個配置檔案 並向外部系統發送資料 每秒100個請求.

  1. 您可以定義讀取區段,以讀取吞吐量為500個設定檔/秒的設定檔,這表示讀取所有設定檔需要20秒。 在第2個1,你會看500個,第2個500個,等等。

  2. 接著,您可以新增「百分比分割」條件活動,其20%分割,以便在每個分支中每秒有100個設定檔。

  3. 之後,在每個分支中新增具有特定計時器的「等待」活動。 我們設定了30秒的等待。 每秒有100個設定檔會流入每個分支。

    • 在分支1,會等候30秒,這表示:

      • 在第1秒,100個設定檔將等待第31秒
      • 在第2秒,100個設定檔將等待第32秒,以此類推。
    • 在分支2中,會等候60秒,這表示:

      • 在第2個1,100個設定檔將等待第2個61(1'01")
      • 在第2個,100個設定檔將等待第62個(1'02")等候。
    • 知道我們預期最多可讀取所有設定檔20秒,每個分支之間將不會重疊,其次20會是設定檔將流入條件的最後一個分支。 在第231到第251之間,將處理分支1中的所有設定檔。 在第261(1'01")和第281(1'21")之間,將處理分支2中的所有設定檔,以此類推。

    • 作為護欄,您也可以新增第六個分支,讓每個分支的設定檔少於100個,尤其是如果您的外部系統僅支援100個請求/秒時。

重要

如同任何因應措施,請在投入生產前徹底測試該解決方案,以確定其符合您的需求。

作為其他護欄,您也可以使用上限設定功能。

注意

與以全域方式對沙箱的所有歷程保護端點的設定上限功能不同,此因應措施僅適用於歷程層級。 這表示,如果多個歷程並行執行,且目標為相同端點,則在設計歷程時需要將此納入考量。 因此,此因應措施不適用於所有使用案例。

本頁內容