常見問題集 — 事件訂閱
以下是有關活動訂閱的常見問題集:
什麼是訂閱?
訂閱是一組資料,用來比對及傳遞Adobe Workfront事件至客戶的HTTP端點。 此資源由4個主要屬性組成:
- customer_id
- obj_code
- obj_id
- url
訂閱也可以有其他屬性(例如本身的唯一ID和建立日期),但上方列出的屬性主要用於比對事件並將它們提供給客戶。
我是否能夠根據事件裝載內的特定條件,選取要傳送至端點的事件?
事件訂閱篩選器是一種可依指定條件排序事件子項的方式。 建議您套用篩選器至事件訂閱,因為這樣可以大幅減少端點需要使用的訊息數量。 如需詳細資訊,請參閱事件訂閱篩選。
為何API會傳回409衝突回應代碼?
如果您嘗試建立事件訂閱並收到回應代碼: 409衝突,則您嘗試建立的訂閱重複。 Workfront不允許建立重複的訂閱。
如果訊息未傳遞至我的端點,怎麼辦?
尋找下列案例並使用建議的解決方案:
-
確定您的訂閱端點(由 url 欄位定義)正在傳回2XX HTTP回應代碼。 如果不是,請連絡Workfront支援,或參閱事件訂閱傳遞需求。
-
事件傳送請求可能在完成之前逾時。 請確認您的端點在5秒內持續回應。 這是HTTP要求傳送事件訂閱訊息時設定的預設逾時。 如果您的端點沒有在5秒內回應,請連絡Workfront支援或參閱事件訂閱傳遞需求。
-
這些事件可能不會產生您思考的方式。 確保您沒有對事件應該如何或何時引發做出假設。 例如,您可能會認為更新任務上的檔案會產生任務更新事件,而是會產生檔案建立或檔案更新事件。
-
您的訂閱可能無法如預期般設定。 您可以在不同的環境中建立事件訂閱,並預期他們會像其他Workfront資料一樣進行傳輸。 但是,事件訂閱資料未設定為複製或升級至其他環境。 請確定您向正確的環境發出API要求,且該環境中的訂閱已如預期般設定。
-
未收到裝載,因為必要的Workfront IP位址尚未新增至防火牆上的允許清單。 事件訂閱事件只會從少數IP位址傳送。 確保目的地網路具有從Workfront事件訂閱接收裝載所需的所有IP例外。
為什麼我的訊息需要太多時間才能到達我的端點?
可能是下列其中一種情況造成的:
-
系統中的大型作業(例如大量更新)可能會造成大量訊息同時排入佇列,這可能需要一些時間處理。
-
大型專案上長期執行的計算或時間表計算,可能導致發佈至事件訂閱的訊息發生延遲,進而耗用。
-
訂閱可能已停用。
-
在100則訊息的寬限期後,如果特定URL (可能與一或多個訂閱相關聯)超過70%的時間失敗,或該URL在2000次連續嘗試後無法傳送,則不會嘗試傳送與同一URL的訂閱相符的所有訊息。 相反地,這些訊息會立即排入重試佇列。
URL停用後,每隔10分鐘,我們都會嘗試傳送進入處理的下一個訊息。 如果訊息成功,我們會重新啟用該URL及後續的任何相符訂閱。 如果該訊息無法傳送,該10分鐘計時器會重設,我們會在訊息過期後重試。
此行為可能會被視為不一致性或延遲傳送,但只會遵循我們處理事件訂閱訊息的原則。
-
如果符合下列任一條件,事件訂閱URL將會被硬停用:
- 訂閱URL已有7天無法傳送,且在過去72小時內已嘗試傳送至少2000次失敗。
- 訂閱URL無法傳送50,000次連續嘗試。
-
如果在嘗試呼叫事件訂閱API時收到500回應狀態,怎麼辦?
請聯絡Workfront支援。 若要瞭解如何連絡支援,請參閱連絡客戶支援。
Workfront事件訂閱可使用哪些不同型別的驗證?
您可以使用任何使用持有人權杖的驗證。 訂閱的 authToken 欄位是字串,代表OAuth2持有者權杖,用於以 url 欄位中指定的URL進行驗證。 理論上,只要目的地端點知道如何處理其編碼(即 utf-8),此權杖值可以是任何值。
我應多久之後才會從Workfront事件訂閱收到事件裝載?
一般而言,您會預期在記錄資料變更後5秒內收到事件訂閱事件傳送請求。 平均而言,從進行資料變更的時間開始,不到1秒就會收到webhook通知。 不過,服務可能會收到大量訊息,而且可能需要更長的時間。
其他資源
-
API檔案: 事件訂閱API
-
最佳實務: 事件訂閱最佳實務
-
觸發事件訂閱裝載的欄位: 事件訂閱資源欄位
-
瞭解事件訂閱重試次數: 事件訂閱重試次數
-
設定Workfront的防火牆: 設定防火牆的允許清單