使用手冊 取消

Acrobat Sign Webhook 概觀

 

Adobe Acrobat Sign 指南

新功能

  1. 發行前說明
  2. 發行說明
  3. 重要通知

開始使用

  1. 管理員快速入門指南
  2. 使用者快速入門指南
  3. 適用於開發人員
  4. 影片教學課程資料庫
  5. 常見問題集

管理

  1. Admin Console 概觀
  2. 使用者管理
    1. 新增使用者
    2. 大量新增使用者
    3. 從目錄新增使用者
    4. 從 MS Azure Active Directory 新增使用者
    5. 建立以功能為導向的使用者
      1. 技術帳戶 - API 導向
      2. 服務帳戶 - 手動導向
    6. 檢查有佈建錯誤的使用者
    7. 變更姓名/電子郵件地址
    8. 編輯使用者的群組成員資格
    9. 透過群組介面編輯使用者的群組成員資格
    10. 將使用者升級為管理員角色
    11. 使用者身分類型與 SSO
    12. 切換使用者身分
    13. 使用 MS Azure 驗證使用者
    14. 使用 Google Federation 驗證使用者
    15. 產品設定檔
    16. 登入體驗
  3. 帳戶/群組設定
    1. 設定概觀
    2. 全域設定
      1. 帳戶層級與 ID
      2. 自我簽署工作流程
      3. 大量傳送
      4. 網頁表單
      5. 自訂傳送工作流程
      6. Power Automate 工作流程
      7. 資料庫文件
      8. 透過合約收集表單資料
      9. 限制文件可見性
      10. 附加已簽署合約的 PDF 副本
      11. 在電子郵件中加入連結
      12. 在電子郵件中加入影像
      13. 附加至電子郵件的檔案將命名為
      14. 將稽核報告附加至文件
      15. 將多個文件合併為一個
      16. 上傳已簽署的文件
      17. 我的帳戶中的使用者委派
      18. 允許外部收件者委派
      19. 授權簽署
      20. 授權傳送
      21. 有權新增電子印章
      22. 設定預設時區
      23. 設定預設日期格式
      24. 使用者加入多個群組 (UMG)
        1. 升級以使用 UMG
      25. 群組管理員權限
      26. 更換收件者
      27. 稽核報告
        1. 概觀
        2. 在交易驗證頁面上允許未驗證的存取
        3. 包含提醒
        4. 包括檢視事件
        5. 包含合約頁面/附件計數
      28. 產品內傳送訊息和指示
      29. 無障礙 PDF
      30. 全新撰寫體驗
      31. 醫療保健客戶
    3. 帳戶設定
      1. 新增標誌
      2. 自訂公司主機名稱/URL
      3. 新增公司名稱
      4. 合約後 URL 重新導向
    4. 簽名偏好設定
      1. 格式固定的簽名
      2. 允許收件者簽署
      3. 簽署者可變更其姓名
      4. 允許收件者使用已儲存的簽名
      5. 自訂使用條款和消費者資訊披露
      6. 透過表單欄位導覽收件者
      7. 拒絕簽署
      8. 允許戳記工作流程
      9. 要求簽署者提供其職稱或公司
      10. 允許簽署者列印並置入書面簽名
      11. 在電子簽名時顯示訊息
      12. 需要簽署者使用行動裝置來建立自己的簽名
      13. 要求取得簽署者的 IP 位址
      14. 將公司名稱和職稱排除在參與戳記之外
    5. 數位簽名
      1. 概觀
      2. 使用 Acrobat 下載並簽署
      3. 以雲端簽名簽署
      4. 包括身分識別提供者的中繼資料
      5. 受限制的雲端簽名提供者
    6. 電子印章
    7. 數位身分
      1. 數位身分識別閘道
      2. 身分識別檢查原則
    8. 報告設定
      1. 全新報告體驗
      2. 傳統報告設定
    9. 安全性設定
      1. 單一登入設定
      2. 記住我設定
      3. 登入密碼原則
      4. 登入密碼強度
      5. 網頁工作階段期間
      6. PDF 加密類型
      7. API
      8. 使用者和群組資訊存取
      9. 允許的 IP 範圍
      10. 帳戶共用
      11. 帳戶共用權限
      12. 合約共用控制項
      13. 簽署者身分驗證
      14. 合約簽署密碼
      15. 文件密碼強度
      16. 依地理位置封鎖簽署者
      17. 電話驗證
      18. 知識式驗證 (KBA)
      19. 允許頁面擷取
      20. 文件連結過期
      21. 上傳 Webhook/回呼的用戶端憑證
      22. 時間戳記
    10. 傳送設定
      1. 登入後顯示「傳送」頁面
      2. 傳送時需有收件者名稱
      3. 鎖定已知使用者的名稱值
      4. 允許的收件者角色
      5. 收件者群組
      6. 必填欄位
      7. 附加文件
      8. 欄位扁平化
      9. 修改合約
      10. 合約名稱
      11. 語言
      12. 私人訊息
      13. 允許的簽名類型
      14. 提醒
      15. 已簽署文件的密碼保護
      16. 傳送合約通知途徑
      17. 簽署者身分識別選項
        1. 概觀
        2. 簽署密碼
        3. 透過電子郵件傳送的一次性密碼
        4. Acrobat Sign 驗證
        5. 電話驗證
        6. 雲端型數位簽名
        7. 知識式驗證
        8. 政府核發證件
        9. 簽署者身分報告
      18. 內容保護
      19. 啟用公證交易
      20. 文件過期
      21. 預覽、定位簽名及新增欄位
      22. 簽署順序
      23. Liquid mode
      24. 自訂工作流程控制項
      25. 電子簽名頁面的上傳選項
      26. 「簽署後」確認重新導向 URL
    11. 訊息範本
    12. 生技製藥設定
      1. 概觀
      2. 強制執行身分識別驗證
      3. 簽署原因
    13. 工作流程整合
    14. 公證設定
    15. 付款整合
    16. 簽署者傳訊
    17. SAML 設定
      1. SAML 設定
      2. 安裝 Microsoft Active Directory Federation Service
      3. 安裝 Okta
      4. 安裝 OneLogin
      5. 安裝 Oracle Identity Federation
    18. 資料控管
    19. 時間戳記設定
    20. 外部封存
    21. 帳戶語言
    22. 電子郵件設定
      1. 電子郵件標題/頁尾影像
      2. 允許個別使用者電子郵件頁尾
      3. 自訂「請求簽名」電子郵件
      4. 自訂「收件者」和「副本收件者」欄位
      5. 啟用無連結通知
      6. 自訂電子郵件範本
    23. 從 echosign.com 移轉至 adobesign.com
    24. 為收件者設定選項
  4. 法規要求指引
    1. 協助工具
      1. 協助工具合規性
      2. 使用 Acrobat 桌面應用程式建立可存取的表單
      3. 建立可存取的 AcroForms
    2. HIPAA
    3. GDPR
      1. GDPR 概觀
      2. 將使用者標記密文
      3. 將使用者的合約標記密文
    4. 21 CFR part 11 和 EudraLex Annex 11
      1. 21 CRF part 11 驗證套件
      2. 21 CFR 和 EudraLex Annex 11 手冊
      3. 共同責任分析
    5. 醫療保健客戶
    6. IVES 支援
    7. 「保存」合約
    8. 歐盟/英國考量事項
      1. 歐盟/英國跨境交易與 eIDAS
      2. 以電子方式簽署之契約的 HMLR 要求
      3. 英國脫歐對英國電子簽名法的影響
  5. 大量下載合約
  6. 宣告您的網域
  7. 「回報不當使用」連結

傳送、簽署與管理合約

  1. 收件者選項
    1. 取消電子郵件提醒
    2. 電子簽名頁面上的選項
      1. 電子簽名頁面概觀
      2. 開啟以閱讀無欄位的合約
      3. 拒絕簽署合約
      4. 委派簽署權限
      5. 重新啟動合約
      6. 下載合約的 PDF
      7. 檢視合約歷史記錄
      8. 檢視合約訊息
      9. 從電子簽名轉換為書面簽名
      10. 從書面簽名轉換為電子簽名
      11. 對表單欄位進行導覽
      12. 從表單欄位中清除資料
      13. 電子簽名頁面放大倍率和導覽
      14. 變更合約工具和資訊中使用的語言
      15. 檢閱法律注意事項
      16. 調整 Acrobat Sign Cookie 偏好設定
  2. 傳送合約  
    1. 傳送頁面概述
    2. 只傳送合約給您自己
    3. 傳送合約給他人
    4. 書面簽名
    5. 收件者簽署順序
    6. 大量傳送
      1. 「大量傳送」功能的概觀
      2. 大量傳送 - 手動收件者
      3. 大量傳送 - CSV 上傳
      4. 取消「大量傳送」交易
      5. 在大量傳送中新增提醒
      6. 報告可供大量傳送
  3. 在文件中撰寫欄位
    1. 應用程式內撰寫環境
      1. 自動欄位偵測
      2. 使用撰寫環境拖放欄位
      3. 將表單欄位指派給收件者
      4. 預填角色
      5. 以可重複使用的欄位範本來套用欄位
      6. 將欄位轉送至新的資料庫範本
      7. 已在傳送合約時更新撰寫環境
    2. 以文字標籤建立表單
    3. 使用 Acrobat (AcroForms) 建立表單
      1. 建立 AcroForm
      2. 建立可存取的 PDF
    4. 欄位
      1. 欄位類型
        1. 常見欄位類型
        2. 內嵌影像
        3. 戳記影像
      2. 欄位內容外觀
      3. 欄位驗證
      4. 已遮罩的欄位值
      5. 設定顯示/隱藏條件
      6. 計算欄位 
    5. 撰寫常見問題集
  4. 簽署合約
    1. 簽署已傳送給您的合約
    2. 填寫和簽署
    3. 自我簽署
  5. 管理合約
    1. 管理頁面概述
    2. 委派合約
    3. 更換收件者
    4. 限制文件可見性
    5. 取消合約
    6. 建立新提醒
    7. 檢閱提醒
    8. 取消提醒
    9. 存取 Power Automate 流程
    10. 更多動作…
      1. 搜尋的運作方式
      2. 檢視合約
      3. 從合約建立範本
      4. 在檢視中隱藏/取消隱藏合約
      5. 上傳已簽署的合約
      6. 修改已傳送合約的檔案或欄位
      7. 編輯收件者的驗證方法
      8. 新增或修改到期日
      9. 將備註新增至合約
      10. 共用個別合約
      11. 取消共用合約
      12. 下載個別合約
      13. 下載合約的個別檔案
      14. 下載合約的「稽核報告」
      15. 下載合約的欄位內容
  6. 稽核報告
  7. 報告與資料匯出
    1. 概觀
    2. 授予使用者報告的存取權
    3. 報告圖表
      1. 建立新報告
      2. 合約報告
      3. 交易報告
      4. 設定活動報告
      5. 編輯報告
    4. 資料匯出 
      1. 建立新的資料匯出
      2. 編輯資料匯出
      3. 重新整理資料匯出內容
      4. 下載資料匯出
    5. 重新命名報告/匯出
    6. 複製報告/匯出
    7. 排程報告/匯出
    8. 刪除報告/匯出
    9. 檢查交易使用量

進階合約功能與工作流程

  1. 網頁表單 
    1. 建立網頁表單
    2. 編輯網頁表單
    3. 停用/啟用網頁表單
    4. 隱藏/取消隱藏網頁表單
    5. 尋找 URL 或指令碼
    6. 使用 URL 參數預填網頁表單欄位
    7. 儲存網頁表單以便稍後完成
    8. 調整網頁表單大小
  2. 可重複使用的範本 (資料庫範本)
    1. 在 Acrobat Sign 資料庫中的美國政府表單
    2. 建立資料庫範本
    3. 變更資料庫範本的名稱
    4. 變更資料庫範本的類型
    5. 變更資料庫範本的權限層級
    6. 複製、編輯和儲存共用範本
    7. 下載資料庫範本的彙總欄位資料
  3. 轉移網頁表單與資料庫範本的所有權
  4. Power Automate 工作流程 
    1. Power Automate 整合與包含授權的概觀
    2. 啟用 Power Automate 整合
    3. 「管理」頁面的相關動作
    4. 追蹤 Power Automate 使用狀況
    5. 建立新的流程 (範例)
    6. 用於流程的觸發器
    7. 從 Acrobat Sign 之外匯入流程
    8. 管理流程
    9. 編輯流程
    10. 共用流程
    11. 停用或啟用流程
    12. 刪除流程
    13. 實用範本
      1. 僅限管理員
        1. 將所有完成的文件儲存至 SharePoint
        2. 將所有完成的文件儲存至商務用 OneDrive
        3. 將所有完成的文件儲存至 Google 雲端硬碟
        4. 將所有完成的文件儲存至 DropBox
        5. 將所有完成的文件儲存至 Box
      2. 合約封存
        1. 將完成的文件儲存至 SharePoint
        2. 將完成的文件儲存至商務用 OneDrive
        3. 將完成的文件儲存至 Google 雲端硬碟
        4. 將完成的文件儲存至 DropBox
        5. 將完成的文件儲存至 Box
      3. 網頁表單合約封存
        1. 將完成的網頁表單文件儲存至 SharePoint 資料庫
        2. 將完成的網頁表單文件儲存至商務用 OneDrive
        3. 將完成的文件儲存至 Google 雲端硬碟
        4. 將完成的網頁表單文件儲存至 Box
      4. 合約資料擷取
        1. 從您簽署的文件擷取表單欄位資料,並更新 Excel 表
      5. 合約通知
        1. 傳送包含合約內容和已簽署合約的自訂電子郵件通知
        2. 在 Teams 頻道中取得您的 Adobe Acrobat Sign 通知
        3. 在 Slack 中取得您的 Adobe Acrobat Sign 通知
        4. 在 Webex 中取得您的 Adobe Acrobat Sign 通知
      6. 合約產生
        1. 從 Power App 表單和 Word 範本產生文件,傳送以供簽署
        2. 從 OneDrive 的 Word 範本產生合約,並取得簽名
        3. 為所選的 Excel 列產生合約,傳送以供檢閱和簽名
  5. 自訂傳送工作流程
    1. 自訂傳送工作流程概觀
    2. 建立新的傳送工作流程
    3. 編輯傳送工作流程
    4. 啟動或停用傳送工作流程
    5. 以「傳送工作流程」傳送合約
  6. 共用使用者與合約
    1. 共用使用者
    2. 共用合約

與其他產品整合

  1.  Acrobat Sign 整合概觀
  2. 適用於 Salesforce 的 Acrobat Sign
  3. 適用於 Microsoft 的 Acrobat Sign
    1. 適用於 Microsoft 365 的 Acrobat Sign
    2. 適用於 Outlook 的 Acrobat Sign
    3. 適用於 Word/PowerPoint 的 Acrobat Sign
    4. 適用於 Teams 的 Acrobat Sign
    5. 適用於 Microsoft PowerApps 和 Power Automate 的 Acrobat Sign
    6. 適用於 Microsoft Search 的 Acrobat Sign 連接器
    7. 適用於 Microsoft Dynamics 的 Acrobat Sign
    8. 適用於 Microsoft SharePoint 的 Acrobat Sign
  4. 其他整合功能
    1. 適用於 ServiceNow 的 Acrobat Sign
    2. 適用於 HR ServiceNow 的 Acrobat Sign
    3. 適用於 SAP SuccessFactors 的 Acrobat Sign
    4. 適用於 Workday 的 Acrobat Sign
    5. 適用於 NetSuite 的 Acrobat Sign
    6. 適用於 VeevaVault 的 Acrobat Sign
    7. 適用於 Coupa BSM Suite 的 Acrobat Sign
  5. 合作夥伴管理的整合功能
  6. 如何取得整合金鑰

Acrobat Sign 開發人員

  1. REST API
    1. 方法說明文件
    2. SDK/開發人員指南
    3. API 常見問答集
  2. Webhook 
    1. Webhook 概觀
    2. 設定新的 Webhook
    3. 檢視或編輯 Webhook
    4. 停用或重新啟動 Webhook
    5. 刪除 Webhook
    6. 雙向 SSL 憑證
    7. API 中的 Webhook

支援與疑難排解

  1. 客戶支援資源
  2. 企業客戶成功資源

概覽

Webhook 是一種由使用者定義的 HTTPS 請求,會在已訂閱的事件於來源網站 (以此例來說就是 Adobe Acrobat Sign) 上發生時觸發。

實際上,Webhook 只是一種會接受資料或串流資料的 REST 服務。

Webhook 是為了用於在推送模型中提供服務對服務通訊

當已訂閱的事件觸發時,Acrobat Sign 會建構具有 JSON 內文的 HTTPS POST,並將其傳遞到指定的 URL。

設定 Webhook 之前,請先確定您的網路能接受功能所需的 IP 範圍

 

與過去的回呼方法相比,Webhook 具有多種優點,其中包括:

  • 管理員可以啟用其 Webhook,無需由 Acrobat Sign 支援以列出回呼 URL
  • Webhook 在資料的「新鮮度」、通訊效率和安全性方面都比較好。不需要輪詢
  • Webhook 可輕鬆使用不同層級的範圍 (帳戶/群組/使用者/資源)。 
  • Webhook 是更現代化的 API 解決方案,能夠更簡單直覺地設定現代化的應用程式
  • 每個作用範圍 (帳戶/群組/使用者/資源) 皆可設置多個 Webhook,但回呼必須是唯一的
  • Webhook 允許選擇要傳回的資料,其中回呼是一種「全有或全無」解決方案
  • 可設置隨 Webhook 一起攜帶的中繼資料 (基本或詳細)
  • 更容易依需要建立、編輯或禁用 Webhook,因為 UI 完全在管理員的控制之下。
註解:

本文件主要聚焦於 Acrobat Sign 網路應用程式 (之前稱為 Adobe Sign) 中 Webhook 的 UI。

尋求 API 詳細資訊的開發人員,可在以下位置找到更多資訊:

必要條件

您必須允許 Webhook 的 IP 範圍通過您的網路安全性,服務才能運作。

REST v5 中的舊版回呼 URL 服務使用與 Webhook 服務相同的 IP 範圍。

管理員可登入 Adobe Admin Console 以新增使用者。登入後,瀏覽至管理員選單,並向下捲動至 Webhook

使用方式

管理員首先需要有 Webhook 服務,準備好接受來自 Acrobat Sign 的傳入推送。這部份有許多選項,只要服務能夠接受 POST 和 GET 請求,Webhook 就會成功。

服務到位後,Acrobat Sign 管理員便可從 Acrobat Sign 網站上「帳戶」選單中的 Webhook 介面建立新的 Webhook。

管理員可以設定 Webhook 以觸發合約、網頁表單 (Widget) 或大量傳送 (MegaSign) 事件。亦可透過 API 設定資料庫範本 (資料庫文件) 資源。

Webhook 的範圍可以包括整個帳戶,或是透過管理介面的各個群組。透過選擇「使用者」或「資源」範圍,API 可提供更多的精細度。

推送至 URL 的資料類型是可設定的,且可包括如合約資訊、參與者資訊、文件資訊等。

設定並儲存好 Webhook 後,每次已訂閱的事件觸發時,Acrobat Sign 就會將新的 JSON 物件推送到已定義的 URL。除非您要更改事件觸發條件或 JSON 裝載,否則不需要持續操作 Webhook。

驗證 Webhook URL 的目的

在成功註冊 Webhook 之前,Acrobat Sign 會驗證註冊請求中提供的 Webhook URL 是否有意接收通知。為此,當 Acrobat Sign 收到新的 Webhook 註冊請求時,會先向該 Webhook URL 提出驗證請求。 此驗證請求是發送到Webhook URL的HTTPSGET請求。 此請求具有自訂 HTTP 標頭 X-AdobeSign-ClientId。此標頭中的值,會設定為請求建立/註冊該 Webhook 之 API 應用程式的用戶端 ID (應用程式 ID)。為了成功註冊 Webhook,Webhook URL 必須以 2XX 回應代碼回應此驗證請求,「而且」還「必須」以下列兩種方法的其中一種,傳回相同的用戶端 ID 值:

  • 在回應標頭 X-AdobeSign-ClientId 中。這就是於請求中傳遞,並在回應中傳回的同一標頭。
  • 或是在 JSON 回應內文中,其中含有 xAdobeSignClientId 鍵,且其值與在請求中傳送的用戶端 ID 相同。

要成功回應 (2XX 回應代碼) 並驗證標頭或回應內文中的用戶端 ID,才算成功註冊 Webhook。此驗證請求的目的,是要證明您的 Webhook URL 確實希望在該 URL 上接收通知。如果意外輸入錯誤的 URL,則 URL 無法正確回應意圖請求的驗證,且 Acrobat Sign 不會向該 URL 發送任何通知。此外,Webhook URL 還可以驗證它只透過由特定應用程式註冊的 Webhook 接收通知。這可藉由驗證在 X-AdobeSign-ClientId 標頭中傳遞的應用程式用戶端 ID 來完成。如果 Webhook URL 無法識別該用戶端 ID,則它「必定不使用」成功回應代碼回應,而 Acrobat Sign 會注意該 URL 並未註冊為 Webhook。

系統將在以下的情況下驗證 Webhook URL 呼叫:

  • 註冊 Webhook:如果此 Webhook URL 呼叫驗證失敗,就不會建立 Webhook。
  • 更新 Webhook:「非作用中」到「作用中」:如果此 Webhook URL 呼叫驗證失敗,Webhook 的狀態就不會更改為「作用中」。

如何回應 Webhook 通知

Acrobat Sign 會在發送到 Webhook URL 的每個 Webhook 通知請求中,執行目的的隱含驗證。因此,每個 Webhook 通知 HTTPS 請求還包含名為 X-AdobeSign-ClientId 的自訂 HTTP 標頭。此標頭的值是建立 Webhook 的應用程式之用戶端 ID (應用程式 ID)。我們只會在以下情況下將 Webhook 通知視為已成功傳送:若,且若傳回成功回應 (2XX 回應代碼),並在 HTTP 標頭 (X-AdobeSign-ClientId) 中或在具有鍵為 xAdobeSignClientId 且值為同一用戶端 ID 的 JSON 回應內文中,傳送用戶端 ID,否則我們會重新嘗試將通知傳送到 Webhook URL,直到重試次數用盡為止。

如上所述,在 Sign 的每個通知請求中都包含標頭「X-AdobeSign-ClientId」,而此標頭的值 (用戶端 ID) 應以如下兩種方式的其中一種,於回應中傳回:

1. HTTP 標頭 X-AdobeSign-ClientId 和作為此用戶端 ID 的值

擷取用戶端 ID 的 Javascript 程式碼範例,先驗證,然後在回應標頭中將之傳回

// Fetch client id

var clientid = request.headers['X-ADOBESIGN-CLIENTID'];

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    //Return it in response header

    response.headers['X-AdobeSign-ClientId'] = clientid;

    response.status = 200;  // default value

}

擷取用戶端 ID 的 PHP 程式碼範例,先驗證,然後在回應標頭中將之傳回

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    //Return it in response header

   header("X-AdobeSign-ClientId:$clientid");

   header("HTTP/1.1 200 OK"); // default value

}

?>


2. 具有金鑰為 xAdobeSignClientId,且值為同一用戶端 ID 的 JSON 回應內文

擷取用戶端 ID 的 Javascript 程式碼範例,先驗證,然後在回應內文中將之傳回

// Fetch client id

var clientid = request.headers['X-ADOBESIGN-CLIENTID'];

 

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    var responseBody = {

                         "xAdobeSignClientId" : clientid // Return Client Id in the body

                       };

    response.headers['Content-Type'] = 'application/json';

    response.body = responseBody;

    response.status = 200;

}

擷取用戶端 ID 的 PHP 程式碼範例,先驗證,然後在回應內文中將之傳回

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

   //Return it in response body

   header("Content-Type: application/json");

   $body = array('xAdobeSignClientId' => $clientid);

   echo json_encode($body);

   header("HTTP/1.1 200 OK"); // default value

}

?>

JSON 的回應內文範例

{

    "xAdobeSignClientId": "BGBQIIE7H253K6"

}

必要條件

您需要:

  1. 獲授權可建立 Azure 函式應用程式的 Microsoft 帳戶
  2. 既有的 Azure 函式應用程式,您可以使用 https://docs.microsoft.com/zh-tw/azure/azure-functions/functions-create-first-azure-function 來建立
  3. Javascript 的基本知識,以便能以您選擇的任何語言理解並編寫程式碼

建立做為 Acrobat Sign Webhook 的 Azure 函式觸發程式的步驟

建立 Javascript HTTP 觸發函式:

1. 用您的 Microsoft 帳戶登入 https://portal.azure.com/

2. 開啟在「函式應用程式」標籤下顯示的 Azure 函式應用程式。

瀏覽至 Azure 中的函式應用程式

這會開啟 Azure 函式應用程式清單:

3. 選擇要在其中建立新函式的應用程式

4. 按一下「建立 (+)」按鈕以建立新的 Azure 函式

建立 Azure 函式

 

5. 選取 Webhook + API 作為情境,選取 Javascript 作為語言

6. 按一下「建立此函式

如此即建立有能力處理傳入 API 請求的新函式。

新增邏輯以註冊 Acrobat Sign Webhook

在成功註冊 Webhook 之前,Acrobat Sign 會驗證註冊請求中提供的 Webhook URL 是否確實有意接收通知。為此,當 Acrobat Sign 接收到新的 Webhook 註冊請求時,首先會對 Webhook URL 發出驗證請求。此驗證請求是使用自訂 HTTP 標頭 X-AdobeSign-ClientId 發送到 Webhook URL 的 HTTPS GET 請求。此標頭中的值,應設定為請求建立/註冊 Webhook 的應用程式之用戶端 ID。為了成功註冊 Webhook,Webhook URL 必須以 2XX 回應代碼回應此驗證請求,「而且」還必須以下列兩種方法的其中一種傳回相同的用戶端 ID 值:

您有兩種選項可遵循:


選項 1:在 X-AdobeSign-ClientId 中傳遞用戶端 ID 作為回應標頭

在回應標頭中傳遞 X-AdobeSign-ClientId。這就是於請求中傳遞,且必須在回應中傳回的同一個標頭。

以下列程式碼取代 Index.js 檔案:

取代 index.js 檔案

module.exports = function (context, req) {

    var clientId = req.headers['x-adobesign-clientid'];

    // Validate that the incoming ClientID is genuine

    if (clientId === '123XXX456') {

        context.res = {

            // status: 200, /* Defaults to 200 */ // any 2XX response is acceptable

            body: "Notification Accepted",

            headers : {

                'x-adobesign-clientid' : req.headers['x-adobesign-clientid']

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Opps!! Illegitimate Call identified"

        };

    }

    context.done();

};

 

透過模擬請求來測試行為:

1. 按一下右上角的「測試」按鈕

2. 模擬假請求

測試函式

雖然上面未顯示回應標頭,但您可透過 postman/DHC 或任何其他服務,對其進行模擬以觀察。


選項 2:使用 xAdobeSignClientId 金鑰在回應內文中傳遞用戶端 ID

在 JSON 回應內文中,其中含有 xAdobeSignClientId 金鑰,且其值與在請求標頭中傳送的用戶端 ID 相同。

以下列程式碼取代 Index.js 檔案:

更新 index.js 檔案內容

module.exports = function (context, req) {

    var clientId = req.headers['x-adobesign-clientid'];

    // Validate that the incoming ClientID is genuine

    if (clientId === '123XXX456') {

        context.res = {

            // status: 200, /* Defaults to 200 */ // any 2XX response is acceptable

            body: {

                'xAdobeSignClientId' : clientId

            },

            headers : {

                'Content-Type' : 'application/json'

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Opps!! Illegitimate Call identified"

        };

    }

    context.done();

};

 

透過模擬請求來測試行為

1. 按一下右上角的「測試」按鈕

2. 模擬假請求

測試函式

另請注意,當 Webhook URL 接收 POST 通知時,用戶端 ID 的行為應相同。 


準備使用

驗證過該行為後,Webhook URL 將按照 Acrobat Sign 標準運作。您可以根據您的需求,進一步更新自訂邏輯。

 

取得函式 URL

  • 按一下「取得函式 URL
取得函式 URL

 

複製 URL,並使用它在 Acrobat Sign 中建立 Webhook。

複製函式 URL

建立 AWS Lambda 函式

如要建立 AWS Lambda 函式,請登入 AWS 管理主控台,並從服務清單中選取 AWS Lambda 服務。

  • 按一下「使用「從頭編寫」」建立 Lambda 函式」選項
  • 在「設定函式」頁面中,輸入函式名稱「lambdaWebhook」,並選取 Node.js 4.3 作為執行階段
  • 將「角色」選為現有角色,或從範本建立新角色
    • 如果您選擇「從範本建立新角色」,請輸入角色名稱 (例如 role-lamda),並從「原則範本」清單選取「簡單微服務權限
  • 按一下「建立函式」按鈕
在 AWS 上建立函式

  • 在新的 AWS lamda 函式頁面上,選取「以內嵌方式編輯程式碼」作為「程式碼輸入類型」,將 index.handler 保留為「處理常式」。
  • 新增邏輯以註冊 Acrobat Sign Webhook

    在成功註冊 Webhook 之前,Acrobat Sign 會驗證註冊請求中提供的 Webhook URL 是否確實有意接收通知。為此,當 Acrobat Sign 接收到新的 Webhook 註冊請求時,首先會對 Webhook URL 發出驗證請求。此驗證請求是使用自訂 HTTP 標頭 X-AdobeSign-ClientId 發送到 Webhook URL 的 HTTPS GET 請求。此標頭中的值,應設定為請求建立/註冊 Webhook 的應用程式之用戶端 ID。為了成功註冊 Webhook,Webhook URL 必須以 2XX 回應代碼回應此驗證請求,「而且」還必須以下列兩種方法的其中一種傳回相同的用戶端 ID 值: 另請注意,當Webhook URL接收POST通知時,客戶端ID的行為應相同。 

    按以下兩種情況的其中一種操作:

    情況 1:在 X-AdobeSign-ClientId 中傳遞用戶端 ID 作為回應標頭

    •  在回應標頭中傳遞 X-AdobeSign-ClientId。這就是於請求中傳遞,且必須在回應中傳回的同一個標頭。

      程式碼片段
      在 index.js 檔案中,將自動生成的程式碼片段替換為以下程式碼:

擷取用戶端 ID 的節點 JS 程式碼範例,先驗證,然後在回應標頭中將之傳回

exports.handler = function index(event, context, callback) {

  // Fetch client id

  var clientid = event.headers['X-AdobeSign-ClientId'];

 

  //Validate it

  if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

  {

    var response = {

        statusCode: 200,

        headers: {

            "X-AdobeSign-ClientId": clientid

        }

     };

   callback(null,response);

  }

  else {

   callback("Oops!! illegitimate call");

  }

}

 

情況 2:使用 xAdobeSignClientId 金鑰,在回應內文中傳遞用戶端 ID

在 JSON 回應內文中,其中含有 xAdobeSignClientId 金鑰,且其值與在請求標頭中傳送的用戶端 ID 相同。

 

程式碼片段

以下列程式碼取代 Index.js 檔案:

擷取用戶端 ID 的節點 JS 程式碼範例,先驗證,然後在回應標頭中將之傳回

exports.handler = function index(event, context, callback) {

 // Fetch client id

 var clientid = event.headers['X-AdobeSign-ClientId'];

  

 //Validate it

 if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

 {

   var responseBody = {

        xAdobeSignClientId : clientid

   };

     

    var response = {

        statusCode: 200,

        body: JSON.stringify(responseBody)

    };

 

   callback(null,response);

 }

 else {

   callback("Opps!! illegitimate call");

  }

}

更新 index.js 檔案內容

  • 儲存函式。Lambda 函式已建立,我們即將準備好將其用於即時 Webhook。

 

設定 AWS API 閘道

如要讓此 Lambda 可透過 HTTP 方法公開存取,我們需要使用我們建立其上的函式設定 AWS API 閘道,作為 API 的後端。

在 AWS 管理主控台中,從「AWS 服務」選取「API 閘道」,然後按一下「建立 API」按鈕

設定 API 閘道

  • 在「建立新 API」頁面選取「新 API」,並輸入「Webhook」作為「API 名稱」。
  • 按一下「建立 API」按鈕
  • 選取「動作」下拉式清單,然後選取「建立資源」選項
  • 勾選「設定為代理資源」項目,然後輸入 validate 作為「資源名稱」,並在「資源路徑」輸入 {proxy+}
  • 讓「啟用 API 閘道 CORS」選項保持未勾選狀態,然後按一下「建立資源」按鈕
  • 保持選取「Lambda 函式代理」作為「整合類型」,並在「Lambda 區域」下拉式清單中選取您建立 Lambda 函式的區域 (可能是您建立 API 閘道的同一區域)。
  • 輸入 validate 作為 Lambda 函式,然後按一下「儲存」按鈕
  • 在「為 Lambda 函式新增權限」快顯視窗中選取「確定

如果成功執行了上述所有步驟,您將看到以下內容:

已設定的方法

部署 API

下一步驟是部署此 API,使其可以使用。

  • 在「動作」下拉式清單選取「部署 API
  • 於「部署階段」選取「[新階段]」,然後將 prod (或任何您想用來識別此階段的文字) 輸入至「階段名稱
  • 按一下「部署」按鈕

API 現在已可使用,您可在藍色方塊中找到叫用 URL,如下所示:

部署 API

請記下此 URL,因為您需要將其輸入為即時 Webhook URL。

準備使用

完成了! 將上述URL與「/{nodeJSfunctionName}」一起作為webhook API請求POST中的webhook URL附加。  驗證過該行為後,Webhook URL 將按照
Acrobat Sign 標準運作。您可以根據需求進一步更新/新增自訂邏輯。

如何啟用或停用

針對企業層級帳戶,預設啟用對 Webhook 功能的存取權。

群組層級管理員可建立/控制僅在其群組內運作的 Webhook。

如要存取「Webhook」頁面,可在「管理」選單的左側邊欄找到。

瀏覽至「webhook」標籤

最佳實務

  • 訂閱特定的必要事件,以限制對伺服器的 HTTPS 請求數量 - Webhook 設定得越明確,您需要過濾的量就愈少
  • 避免重複 - 如果您有多個應用程式共用同一個 Webhook URL,且同樣的使用者對應至各個應用程式,則同一事件將多次 (每個應用程式一次) 發送到您的 Webhook。在某些情況下,您的 Webhook 可能會收到重複事件。您的 Webhook 應用程式應要能容忍此情況,並藉由事件 ID 消除重複資料。
  • 始終快速回應 Webhook - 您的應用程式只有五秒鐘可回應 Webhook 請求。驗證請求的部分很少有問題,因為您的應用程式不需要做任何實際的工作來回應。但在通知請求的部分,您的應用程式通常會執行一些需要時間的操作來回應請求。建議您在個別的執行緒上作業,或是以非同步的方式使用佇列,以確保您能在五秒內回應
  • 管理並行 - 當使用者快速連續進行多項變更時,您的應用程式可能會在差不多的時間收到同一使用者的多個通知。如果您對於並行的管理方式不夠小心,您的應用程式便可能會多次處理同一使用者的相同變更。為了利用 Acrobat Sign 的 Webhook,您必須對資訊的使用情況有清楚的理解。請務必提出以下問題:
    • 您要在裝載中傳回哪些資料?
    • 誰將存取此資訊?
    • 將產生哪些決定或報告?
  • 接收已簽署文件的建議 - 在決定如何於文件管理系統中接收 Acrobat Sign 的已簽署 PDF 時,需要考慮幾個因素。

儘管在建立 Webhook 時,您可以選取「合約已簽署文件」選項,不過您也可以考慮在收到觸發事件 (例如合約狀態完成) 時,使用 Acrobat Sign API 擷取文件。

注意事項…

JSON 大小限制

JSON 裝載的大小限制為 10 MB。

如果事件產生較大的裝載,則雖會觸發 Webhook,但如果請求中存在條件參數屬性時,會刪除該條件參數屬性以縮減裝載的大小。 

當發生此情況時,系統將在回應中傳回「ConditionalParametersTrimmed」以通知用戶端「 conditionalParameters 」資訊已遭移除。

conditionalParametersTrimmed」是陣列物件,包含已剪除的各個金鑰的資訊。

截斷處理將按照以下順序進行:

  • includeSignedDocuments
  • includeParticipantsInfo
  • includeDocumentsInfo
  • includeDetailedInfo

首先會截斷已簽署的文件,然後是參與者資訊、文件資訊,最後則是詳細資訊。

例如,如果合約完成事件也包括已簽署的文件 (64 位元編碼),或是合約具有多個表單欄位時,便可能發生這種情況

Webhook 通知

Acrobat Sign Webhook 會傳送通知給合約的傳送者,以及設定於傳送合約的群組中的任何 Webhook。帳戶範圍的 Webhook 會接收所有事件。

傳送者:使用者 A | 簽署者:使用者 B | 受邀共用者:使用者 C

使用者 A 和使用者 B 位於不同的帳戶中

使用者 A 和使用者 C 位於不同的帳戶中

使用情況

通知?

注釋/備註

使用者 A 的帳戶有「帳戶」層級的 Webhook (由使用者 A 或帳戶管理員建立)。

帳戶」層級的 Webhook 會收到該帳戶中觸發之所有事件的通知。

使用者 A 的帳戶有「群組」層級的 Webhook (由使用者 A 或帳戶/群組管理員建立)。

假設:使用者 A 與群組管理員位於相同群組中。

群組」層級的 Webhook 會收到該群組中觸發之所有事件的通知。

使用者 A 有「使用者」層級的 Webhook。

系統會觸發做為傳送者的使用者 A 的「使用者」層級 Webhook

使用者 A 有「資源」層級的 Webhook (針對上述已傳送的合約)。

 
     

使用者 B 的帳戶有「帳戶」層級的 Webhook (由使用者 B 或帳戶管理員建立)。

系統會將使用者 B 的「帳戶」層級 Webhook 視為簽署者 Webhook。

使用者 B 的帳戶有「群組」層級的 Webhook (由使用者 B 或帳戶/群組管理員建立)。

假設:使用者 B 與群組管理員位於相同群組中。

系統會將使用者 B 的「群組」層級 Webhook 視為簽署者 Webhook。

使用者 B 有「使用者」層級的 Webhook。

系統會將使用者 B 的「使用者」層級 Webhook 視為簽署者 Webhook。

     

使用者 C 的帳戶有「帳戶」層級的 Webhook (由使用者 C 或帳戶管理員建立)。

系統會將使用者 C 的「帳戶」層級 Webhook 視為非原建立者 Webhook。

使用者 C 的帳戶有「群組」層級的 Webhook (由使用者 C 或帳戶/群組管理員建立)。

假設:使用者 C 與群組管理員位於相同群組中。

系統會將使用者 C 的「群組」層級 Webhook 視為非原建立者 Webhook。

使用者 C 有「使用者」層級的 Webhook。

系統會將使用者 C 的「使用者」層級 Webhook 視為非原建立者 Webhook。

傳送者:使用者 A | 簽署者:使用者 B | 受邀共用者:使用者 C

使用者 A、使用者 B 和使用者 C 位於相同的帳戶中

使用情況

通知?

備註

使用者 A 的帳戶有「帳戶」層級的 Webhook (由使用者 A 或帳戶管理員建立)。

帳戶」層級的 Webhook 會通知由帳戶觸發的事件。

使用者 A 的帳戶有「群組」層級的 Webhook (由使用者 A 或帳戶/群組管理員建立)。

假設:使用者 A 與群組管理員位於相同群組中。

群組」層級的 Webhook 會通知由其群組中的使用者觸發的事件。

使用者 A 有「使用者」層級的 Webhook。

系統會觸發做為傳送者的使用者 A 的「使用者」層級 Webhook

使用者 A 有「資源」層級的 Webhook (針對上述已傳送的合約)。

 
     

使用者 B 的帳戶有「帳戶」層級的 Webhook (由使用者 B 或帳戶管理員建立)。

由於使用者 A 和使用者 B 位於相同的帳戶中,因此「帳戶」層級的 Webhook 會收到該帳戶中觸發的所有事件的通知。

使用者 B 的帳戶有「群組」層級的 Webhook (由使用者 B 或帳戶/群組管理員建立)。

假設:使用者 A、使用者 B 與群組管理員位於相同群組中。

由於使用者 A 和使用者 B 位於相同的群組中,因此「群組」層級的 Webhook 會收到該群組中觸發的所有事件的通知。

使用者 B 的帳戶有「群組」層級的 Webhook (由使用者 B 或帳戶/群組管理員建立)。

假設:使用者 A 和使用者 B 位於不同的群組中。

系統會將使用者 B 的「群組」層級 Webhook 視為簽署者 Webhook。

系統將觸發使用者 A 的 Webhook (資源/使用者/群組/帳戶)。

使用者 B 有「使用者」層級的 Webhook。

系統不會觸發做為收件者的使用者 B 的「使用者」層級 Webhook。

     

使用者 C 的帳戶有「帳戶」層級的 Webhook (由使用者 C 或帳戶管理員建立)。

由於使用者 A 和使用者 C 位於相同的帳戶中,因此「帳戶」層級的 Webhook 會收到該帳戶中觸發的所有事件的通知。

使用者 C 的帳戶有「群組」層級的 Webhook (由使用者 C 或帳戶/群組管理員建立)。

假設:使用者 A、使用者 C 與群組管理員位於相同群組中。

由於使用者 A 和使用者 C 位於相同的群組中,因此「群組」層級的 Webhook 會收到該群組中觸發的所有事件的通知。

使用者 C 的帳戶有「群組」層級的 Webhook (由使用者 C 或帳戶/群組管理員建立)。

假設:使用者 A 和使用者 C 位於不同的群組中。

系統會將使用者 C 的「群組」層級 Webhook 視為非原建立者 Webhook。

系統將觸發使用者 A 的 Webhook (資源/使用者/群組/帳戶)。

使用者 C 有「使用者」層級的 Webhook。

系統會將使用者 C 的「使用者」層級 Webhook 視為非原建立者 Webhook。

當偵聽服務關閉時重試

如果 Webhook 的目標 URL 因任何原因停止,則 Adobe Sign 會將 JSON 排入佇列,然後在 72 小時內以漸進式循環重試推送。

未傳遞的事件將保留在重試佇列中,系統會在接下來的 72 小時內盡全力按照通知發生的順序傳遞通知。

重試傳送通知的策略是將嘗試的間隔時間變更兩倍,從間隔 1 分鐘開始,到每隔 12 小時,結果就是在 72 小時內重試 15 次。

如果 Webhook 接收器在 72 小時內未能回應,且在過去七天內都未曾成功發送通知,則系統便會停用 Webhook。直到 Webhook 再次啟用前,系統都不會向此 URL 發送任何通知。

在 Webhook 停用到之後再次啟用之間的所有通知,都會遺失。

 Adobe

更快、更輕鬆地獲得協助

新的使用者?

Adobe MAX 2024

Adobe MAX
創意大會

10 月 14 至 16 日邁阿密海灘和線上

Adobe MAX

創意大會

10 月 14 至 16 日邁阿密海灘和線上

Adobe MAX 2024

Adobe MAX
創意大會

10 月 14 至 16 日邁阿密海灘和線上

Adobe MAX

創意大會

10 月 14 至 16 日邁阿密海灘和線上