マニュアル キャンセル

Webhook の概要

 

Adobe Acrobat Sign ガイド

新機能

  1. プレリリースノート
  2. リリースノート
  3. 重要な通知

入門

  1. 管理者向けクイックスタートガイド
  2. ユーザー向けクイックスタートガイド
  3. 開発者向け
  4. ビデオチュートリアルライブラリ
  5. FAQ

管理者

  1. Admin Console の概要
  2. ユーザー管理
    1. ユーザーを追加
    2. ユーザーを一括で追加
    3. ディレクトリからユーザーを追加
    4. MS Azure Active Directory からのユーザーの追加
    5. 機能重視のユーザーの作成
      1. テクニカルアカウント – API ドリブン
      2. サービスアカウント – 手動
    6. プロビジョニングエラーが発生しているユーザーの確認
    7. 名前/メールアドレスの変更
    8. ユーザーのグループメンバーシップの編集
    9. グループインターフェイスを使用したユーザーのグループメンバーシップの編集
    10. ユーザーの管理者役割への昇格
    11. ユーザー ID タイプと SSO
    12. ユーザー ID の切り替え
    13. MS Azure を使用したユーザー認証
    14. Google フェデレーションを使用したユーザー認証
    15. 製品プロファイル
    16. ログインエクスペリエンス
  3. アカウント/グループ設定
    1. 設定の概要
    2. グローバル設定
      1. アカウントレベルと ID
      2. 自己署名ワークフロー
      3. 一括送信
      4. Web フォーム
      5. カスタム送信ワークフロー
      6. Power Automate ワークフロー
      7. ライブラリ文書
      8. 契約書からフォームデータを収集する
      9. 文書の表示制限
      10. 署名済み契約書の PDF コピーの添付
      11. 電子メールへのリンクの追加
      12. 電子メールへの画像の添付
      13. メールに添付されるファイルの名前
      14. 文書への監査レポートの添付
      15. 複数の文書を 1 つに結合
      16. 署名済み文書をアップロード
      17. アカウント内のユーザーの委任
      18. 外部受信者による委任の許可
      19. 署名の権限
      20. 送信の権限
      21. e シールを追加する権限
      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. ID プロバイダーのメタデータを含める
      5. 制限付きクラウド署名プロバイダー
    6. e シール
    7. デジタル ID
      1. デジタル ID ゲートウェイ
      2. ID チェックポリシー
    8. レポート設定
      1. 新しいレポートエクスペリエンス
      2. 従来のレポート設定
    9. セキュリティ設定
      1. シングルサインオン設定
      2. アカウント記憶設定
      3. ログインパスワードポリシー
      4. ログインパスワードの強さ
      5. Web セッション期間
      6. PDF 暗号化のタイプ
      7. API
      8. ユーザーおよびグループ情報へのアクセス
      9. 許可する IP 範囲
      10. アカウント共有
      11. アカウント共有権限
      12. 契約書の共有制御
      13. 署名者の ID 確認
      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. 署名者 ID オプション
        1. 概要
        2. 署名パスワード
        3. 電子メールによるワンタイムパスワード
        4. Acrobat Sign 認証
        5. 電話認証
        6. クラウドベースのデジタル署名
        7. ナレッジベース認証
        8. Government ID
        9. 署名者の ID レポート
      17. コンテンツ保護
      18. Notarize トランザクションを有効にする
      19. 文書の有効期限
      20. プレビュー、署名の位置指定、フィールドの追加
      21. 署名順序
      22. Liquid Mode
      23. カスタムのワークフロー制御
      24. 電子サインページのアップロードオプション
      25. 署名後の確認 URL リダイレクト
    11. メッセージテンプレート
    12. バイオ医薬業界標準対応
      1. 概要
      2. ID 認証を強制
      3. 署名の理由
    13. ワークフロー統合
    14. 公証設定
    15. 支払いの統合
    16. 署名者へのメッセージ
    17. SAML 設定
      1. SAML 設定
      2. Microsoft Active Directoryフェデレーションサービスのインストール
      3. Okta のインストール
      4. OneLogin のインストール
      5. Oracle ID フェデレーションのインストール
    18. データガバナンス
    19. タイムスタンプ設定
    20. 外部アーカイブ
    21. アカウントの言語
    22. 電子メール設定
      1. 電子メールのヘッダー/フッター画像
      2. 個々のユーザーの電子メールフッターの許可
      3. 署名依頼電子メールのカスタマイズ
      4. 宛先と CC のフィールドのカスタマイズ
      5. カスタム電子メールテンプレート
      6. リンクなし通知を有効にする
    23. echosign.com から adobesign.com への移行
    24. 受信者のオプションの設定
  4. 規制要件に関するガイダンス
    1. アクセシビリティ
      1. アクセシビリティの準拠
      2. Acrobat デスクトップ版を使用したアクセシブルなフォームの作成
      3. アクセシブルな AcroForm の作成
    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. EU/英国に関する考慮事項
      1. EU/英国の国境を超えたトランザクションおよび eIDAS
      2. 電子サインされた証書の HMLR 要件
      3. 英国の電子サイン法に対する Brexit の影響
  5. 契約書の一括ダウンロード
  6. ドメインの要求

契約書の送信、署名、および管理

  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(AcroForm)を使用したフォームの作成
      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. その他のアクション...
      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. Web フォーム
    1. Web フォームを作成
    2. Web フォームを編集
    3. Web フォームを無効/有効にする
    4. Web フォームの非表示/再表示を切り替える
    5. URL またはスクリプトコードの検索
    6. URL パラメーターを使用した web フォームフィールドの事前入力
    7. Web フォームを保存して後で完了
    8. Web フォームのサイズ変更
  2. 再利用可能なテンプレート(ライブラリテンプレート)
    1. Acrobat Sign ライブラリの米国政府のフォーム
    2. ライブラリテンプレートの作成
    3. ライブラリテンプレートの名前変更
    4. ライブラリテンプレートのタイプの変更
    5. ライブラリテンプレートの権限レベルの変更
    6. 共有テンプレートのコピー、編集、保存
    7. ライブラリテンプレートの集計フィールドデータのダウンロード
  3. Web フォームおよびライブラリテンプレートの所有権の譲渡
  4. Power Automate ワークフロー
    1. Power Automate 統合の概要と含まれる使用権限
    2. Power Automate 統合を有効にする
    3. Power Automate の使用状況を追跡
    4. 新しいフローの作成(例)
    5. フローに使用するトリガー
    6. Acrobat Sign 外部からのフローの読み込み
    7. フローの管理
    8. フローの編集
    9. フローの共有
    10. フローを無効または有効にする
    11. フローの削除
    12. 便利なテンプレート
      1. 管理者のみ
        1. 完了したすべての文書の SharePoint への保存
        2. すべての完了した文書の OneDrive for Business への保存
        3. 完了したすべての文書の Google ドライブへの保存
        4. 完了したすべての文書の DropBox への保存
        5. 完了したすべての文書の Box への保存
      2. 契約書のアーカイブ
        1. 完了した文書の SharePoint への保存
        2. 完了した文書の One Drive for Business への保存
        3. 完了した文書の Google ドライブへの保存
        4. 完了した文書の DropBox への保存
        5. 完了した文書の Box への保存
      3. Web フォーム契約書のアーカイブ
        1. 完了した web フォーム文書の SharePoint ライブラリへの保存
        2. 完了した web フォーム文書の OneDrive for Business への保存
        3. 完了した文書の Google ドライブへの保存
        4. 完了した web フォーム文書の 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. Acrobat Sign Connector for Microsoft Search
    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. Acrobat Sign for Workday
    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. Webhooks
    1. Webhook の概要
    2. 新しい webhook の設定
    3. Webhook の表示または編集
    4. Webhook のアクティベート解除または再アクティベート
    5. Webhook の削除
    6. 双方向 SSL 証明書
    7. API の Webhook

サポートとトラブルシューティング

  1. カスタマーサポートリソース
  2. 大規模法人のカスタマーサクセスリソース

概要

Webhook は、ソースサイト(この場合は Adobe Acrobat Sign)で購入済みイベントが発生したときにトリガーされる、ユーザー定義の HTTPS リクエストです。

事実上、webhook はデータまたはデータストリームを受け入れる REST サービスです。

Webhook は、プッシュモデルでのサービス間通信を目的としています。

購入済みイベントがトリガーされると、Acrobat Sign は JSON 本文を持つ HTTPS POST を構築し、指定された URL に配信します。

Webhook を設定する前に、ネットワークが機能に必要な IP 範囲を受け入れることを確認してください。

 

Webhook には、以前のコールバックメソッドに比べて次のような多くの利点があります。

  • 管理者は、コールバック URL を一覧するために Acrobat Sign サポートを必要とすることなく、webhook を有効にできる
  • Webhook は、データの「鮮度」、通信の効率、セキュリティの点で優れていてポーリングは不要
  • Webhook では、さまざまなレベルのスコープ(アカウント/グループ/ユーザー/リソース)を簡単に使用できる
  • Webhook はより先進的な API ソリューションであり、先進的なアプリケーションをより簡単に設定できる
  • コールバックを一意にする必要がある場合、スコープ(アカウント/グループ/ユーザー/リソース)ごとに複数の webhook を構成できる
  • Webhook では、返されるデータを選択できるが、その場合コールバックは「全部か無」ソリューションである
  • Webhook で伝送するメタデータは構成できる(基本または詳細)
  • Webhook では、管理者が UI を完全に制御できるため、必要に応じてはるかに簡単に作成、編集したり、無効にできる
注意:

この文書では、主に Acrobat Sign web アプリケーション(以前の Adobe Sign)の webhook UI について説明します。

デベロッパー向けの API の詳細については、次の URL を参照してください。

前提条件

サービスを機能させるには、ネットワークセキュリティを介して webhook の IP 範囲を許可する必要があります。

REST v5 の従来のコールバック URL サービスは、webhook サービスと同じ IP 範囲を使用します。

管理者は、Adobe Admin Console にログインしてユーザーを追加できます。ログインしたら、管理者のメニューに移動し、webhook
まで下にスクロールします。

使用方法

管理者は、まず Acrobat Sign からのインバウンドプッシュを受け入れる準備が整った webhook サービスを用意する必要があります。これに関しては多くのオプションがありますが、サービスが POST と GET のリクエストを受け入れ可能な限り、webhook は成功します。

サービスを導入したら、Acrobat Sign 管理者は、Acrobat Sign サイトの webhook インターフェイスから新しい webhook を作成できます。

管理者は、契約書、web フォーム(ウィジェット)または一括送信(MegaSign)イベントをトリガーするように webhook を設定できます。ライブラリテンプレート(ライブラリ文書)リソースは、API から設定することもできます。

Webhook のスコープには、管理インターフェイスをからアカウント全体または個々のグループを含めることができます。API を使用すると、USER または RESOURCE スコープを選択して、より詳細に設定できます。

URL にプッシュされるデータのタイプは設定可能で、契約書情報、参加者情報、文書情報などを含めることができます。

Webhook を設定して保存すると、Acrobat Sign は、購入済みイベントがトリガーされるたびに、定義された URL に新しい JSON オブジェクトをプッシュします。イベントトリガー条件や JSON ペイロードを変更する場合を除き、webhook の継続的な操作は必要ありません。

Webhook URL のインテントの確認

Acrobat Sign は、webhook の登録を完了する前に、登録リクエストで提供された webhook URL が通知を受信するかどうかを確認します。このため、Acrobat Sign は、新しい webhook 登録リクエストを受信すると、まず webhook URL に対する検証リクエストを実行します。 この確認要求は、Webhook URL に送信される HTTPSGET要求です。 このリクエストには、カスタム HTTP ヘッダー X-AdobeSign-ClientId が含まれます。このヘッダーの値は、webhook の作成/登録を要求している API アプリケーションのクライアント ID(アプリケーション ID)に設定されます。Webhook を正常に登録するために、webhook URL はこの検証リクエストに 2XX 応答コードで応答する必要があり、さらに、次の 2 つの方法のいずれかで同じクライアント ID 値を返す必要があります。

  • 応答ヘッダー X-AdobeSign-ClientId を使用。これは、リクエストで渡されたヘッダーと同じヘッダーで、応答でエコーバックされます。
  • または、xAdobeSignClientId のキーとその値(リクエストで送信されたクライアント ID と同じ値)を示す JSON 応答の本文を使用。

応答(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 応答コード)が返され、クライアント ID が HTTP ヘッダー(X-AdobeSign-ClientId)または JSON 応答本文で、キーが xAdobeSignClientId、値が同じクライアント ID として送られた場合です。それ以外の場合は、再試行の回数が終了するまで、通知が webhook URL に配信され続けます。

前述のように、Sign からのすべての通知リクエストに含まれている「X-AdobeSign-ClientId」というヘッダーの値(クライアント ID)は、次の 2 つの方法のいずれかで、応答としてエコーバックされる必要があります。

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 Functions アプリケーションを作成するためのライセンスのある Microsoft アカウント
  2. 既存の Azure Functions アプリケーションは、次の方法で作成可能 https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-create-first-azure-function
  3. 選択した任意の言語でコードを理解して記述できる、Javascript の基本的な知識

Acrobat Sign webhook として機能する Azure Functions トリガーを作成する手順

Javascript HTTP トリガー関数を作成するには:

1. Microsoft アカウントでログインします。 https://portal.azure.com/

2. 「Function App」タブに表示されている Azure Functions アプリケーションを開きます。

Azure 内の「Function Apps」に移動

Azure Functions アプリケーションのリストが開きます。

3. この新しい関数を作成するアプリケーションを選択します。

4. 「作成」(+)ボタンをクリックして、新しい Azure 関数を作成します。

Azure 関数の作成

 

5. シナリオとして「Webhook + API」、言語として「Javascript」を選択します。

6. 「この関数を作成する」をクリックします。

受信 API リクエストを処理する機能を持つ新しい関数が作成されます。

Acrobat Sign webhook を登録するロジックの追加

Acrobat Sign は、webhook の登録を完了する前に、登録リクエストで提供された webhook URL が、本当に通知を受信するかどうかを確認します。この目的のために、Acrobat Sign が新しい webhook 登録リクエストを受信すると、まず webhook URL に対して検証リクエストを作成します。この検証リクエストは、webhook URL に送信される HTTPS GET リクエストで、カスタム HTTP ヘッダー X-AdobeSign-ClientId を含みます。このヘッダーの値は、webhook の作成/登録を要求しているアプリケーションのクライアント ID に設定されます。Webhook を正常に登録するために、webhook URL はこの検証リクエストに 2XX 応答コードで応答する必要があり、さらに、次の 2 つの方法のいずれかで同じクライアント ID 値を返す必要があります。

以下の 2 つのオプションがあります。


オプション 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 を渡す

xAdobeSignClientId のキーとその値(リクエストヘッダーで送信されたクライアント ID と同じ値)を示す JSON 応答の本文内。

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 通知を受信するとき、clientID に対して同じ動作を行う必要があります。 


使用準備完了

動作の検証が終了すると、webhook URL は Acrobat Sign 標準版に従って機能します。必要に応じて、カスタムロジックをさらに更新できます。

 

関数の URL の取得

  • 関数の URL の取得」をクリック
関数の URL の取得

 

URL をコピーして、Acrobat Sign で webhook を作成するために使用します。

関数 URL のコピー

AWS Lambda 関数の作成

AWS Lambda 関数を作成するには、AWS Management Console にログインし、サービスリストから AWS Lambda サービスを選択します。

  • 『一から作成』を使用して Lambda 関数を作成」オプションをクリックします。
  • 関数の設定ページで、関数名「lambdaWebhooks」を入力し、ランタイムとして「Node.js 4.3」を選択します。
  • ロール」として、既存のロールを選択するか、テンプレートから新しいロールを作成します。
    • テンプレートから新しいロールを作成」を選択した場合は、ロール名(role-lamda など)を入力し、「シンプルなマイクロサービスのアクセス許可 」をポリシーテンプレートリストから選択します。
  • 関数の作成」ボタンをクリックします。
AWS での関数の作成

  • 新しい AWS lamda 関数ページで、「コードエントリタイプ」として「コードをインラインで編集」を選択し、ハンドラーは index.handler のままにします。
  • Acrobat Sign webhook を登録するロジックの追加

    Acrobat Sign は、webhook の登録を完了する前に、登録リクエストで提供された webhook URL が、本当に通知を受信するかどうかを確認します。この目的のために、Acrobat Sign が新しい webhook 登録リクエストを受信すると、まず webhook URL に対して検証リクエストを作成します。この検証リクエストは、webhook URL に送信される HTTPS GET リクエストで、カスタム HTTP ヘッダー X-AdobeSign-ClientId を含みます。このヘッダーの値は、webhook の作成/登録を要求しているアプリケーションのクライアント ID に設定されます。Webhook を正常に登録するために、webhook URL はこの検証リクエストに 2XX 応答コードで応答する必要があり、さらに、次の 2 つの方法のいずれかで同じクライアント ID 値を返す必要があります。 また、Webhook URL がイベント通知を受信する場合も、clientID に対して同じ動作がPOSTされます。 

    次のいずれかのケースに従います。

    ケース 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 を渡す

xAdobeSignClientId のキーとその値(リクエストヘッダーで送信されたクライアント ID と同じ値)を示す JSON 応答の本文内。

 

コードスニペット

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 Gateway の設定

この Lambda 関数に HTTP メソッドからパブリックにアクセスできるようにするには、上記で作成した関数を API のバックエンドとして使用して、AWS API Gateway を設定する必要があります。

AWS Management Console で AWS サービスから「API Gateway」を選択し、「API の作成」ボタンをクリックします。

API ゲートウェイの設定

  • 新しい API の作成」ページで「新しい API」を選択し、API 名として「webhooks」と入力します。
  • API の作成」ボタンをクリックします。
  • アクション」ドロップダウンリストを選択し、「リソースの作成」オプションを選択します。
  • プロキシリソースとして設定」オプションを選択し、リソース名として「validate」と入力し、リソースパス{proxy+} と入力します。
  • API Gateway CORS を有効にする」オプションをオフのままにし、「リソースの作成」ボタンをクリックします。
  • 統合タイプとして「Lambda 関数プロキシ」を選択したままにし、「Lambda リージョン」ドロップダウンリストで Lambda 関数を作成したリージョン(おそらく API Gateway を作成するリージョンと同じ)を選択します。
  • Lambda 関数として「validate」と入力し、「保存」ボタンをクリックします。
  • Lambda 関数に権限を追加」ポップアップウィンドウで、「OK」を選択します。

上記の手順の実行がすべて完了すると、次のような画面が表示されます。

設定されたメソッド

API の導入

次の手順は、この API をデプロイして使用できるようにすることです。

  • アクション」ドロップダウンで「API をデプロイ」を選択します。
  • デプロイメントステージ」で「新しいステージ」を選択し、「ステージ名」に「prod」(またはこのステージを識別する任意の名称)を入力します。
  • デプロイ」ボタンをクリックします。

これで API を使用する準備ができました。次に示すように、青いボックスに呼び出し URL が表示されます。

API をデプロイ

リアルタイムの webhook URL として入力する必要があるので、この URL をメモしておきます。

使用準備完了

これで完了です。 上記の URL を使用し、webhook URL として/webhooks API リクエストのPOSTに"/{nodeJSfunctionName}"を追加します。  動作の検証が終了すると、webhook URL は
Acrobat Sign 標準版に従って機能します。必要に応じて、カスタムロジックをさらに更新または追加できます。

有効/無効にする方法

Webhook 機能へのアクセスは、エンタープライズ版レベルのアカウントではデフォルトで有効になっています。

グループレベルの管理者は、自分のグループ内でのみ動作する webhook を作成/制御できます。

Webhook ページへのアクセスは、管理メニューの左パネルに表示されます。

「Webhooks」タブに移動

ベストプラクティス

  • 特定の必要なイベントをサブスクライブして、サーバーに対する HTTPS リクエストの数を制限する:webhook をより具体的なものにするほど、取捨選択する量を少なくできます。
  • 重複耐性がある:同じ webhook URL を共有する複数のアプリケーションがあり、各アプリケーションに同じユーザーがマッピングされている場合、同じイベントが webhook に複数回送信されます(アプリケーションごとに 1 回ずつ)。場合によっては、webhook が重複するイベントを受信することがあります。Webhook アプリケーションはこれを許容し、イベント ID によって重複排除を行う必要があります。
  • 常に Webhook にすばやく応答する:アプリケーションが webhook リクエストに応答できる時間は 5 秒だけです。検証リクエストでは、これはほとんど問題になりません。なぜならアプリケーションは応答するために実際の作業を実行する必要がないためです。しかし、通知リクエストの場合、アプリがリクエストへ応答するのに時間がかかる作業が発生することがよくあります。5 秒以内に応答できるように、別のスレッドで作業するか、キューを使用して非同期で作業することをお勧めします。
  • 並行処理の管理:ユーザーが次々に連続して変更を行うと、ほぼ同時に同じユーザーに対する複数の通知がアプリケーションに送信される可能性があります。並行処理の管理方法に注意しないと、同じユーザーに対して同じ変更が複数回処理されてしまうおそれがあります。Acrobat Sign webhook を活用するには、情報の使用方法を明確に理解する必要があります。次のような問いかけをしてください。
    • ペイロードにはどのようなデータを返すか
    • この情報にアクセスするのは誰か
    • どのような意思決定や報告が行われるか
  • 署名済み文書を受信するための推奨事項:文書管理システムで Acrobat Sign から署名済み PDF を受け取る方法を決定する際には、いくつかの要因を考慮する必要があります。

単に「契約署名済み文書」オプションを選択しても差し支えありませんが、webhook を作成する際に、イベント(契約書の完了ステータスなど)のトリガーを受信したときに、Acrobat Sign API を使用して文書を取得することを検討することもできます。

注意事項...

JSON のサイズ制限

JSON ペイロードのサイズは 10 MB に制限されています。

イベントがこれより大きなペイロードを生成する場合、webhook はトリガーされますが、条件パラメーター属性(リクエスト内にある場合)は、ペイロードのサイズを減じるために削除されます。

これが発生したときは、応答で「ConditionalParametersTrimmed」が返され、クライアントに conditionalParameters 情報が削除されたことを伝えます。

conditionalParametersTrimmed」は array オブジェクトで、トリミングされたキーに関する情報を含みます。

切り捨ては以下の順序で行われます。

  • includeSignedDocuments
  • includeParticipantsInfo
  • includeDocumentsInfo
  • includeDetailedInfo

署名済み文書は、最初に切り捨てられ、続いて、参加者情報、文書情報、最終的に詳細情報が切り捨てられます。

これは、例えば、契約書完了イベントに署名済み文書(base 64 でエンコード)が含まれている場合や、複数のフォームフィールドを持つ契約書などで発生します。

Webhook 通知

Acrobat Sign webhook は、通知を契約書の送信者および契約書の送信元のグループ内で設定されているすべての webhook に配信します。アカウントスコープの webhook は、すべてのイベントを受信します。

送信者:ユーザー A | 署名者:ユーザー B | 共有相手:ユーザー C

ユーザー A とユーザー B が異なるアカウント内

ユーザー A とユーザー C が異なるアカウント内

ユースケース

通知

コメント/メモ

ユーザー A のアカウントに、(ユーザー A またはアカウント管理者によって作成された)アカウントレベルの webhook がある。

はい

アカウントレベルの webhook は、そのアカウントでトリガーされたすべてのイベントの通知を受けます。

ユーザー A のアカウントに、(ユーザー A またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー A とグループ管理者は、同じグループ内です。

はい

グループレベルの webhook は、そのグループでトリガーされたすべてのイベントの通知を受けます。

ユーザー A に、ユーザーレベルの webhook がある。

はい

送信者として、ユーザー A のユーザーレベルの webhook がトリガーされます

ユーザー A に(上記で送信された契約書用の)リソースレベルの webhook がある。

はい

 
     

ユーザー B のアカウントに(ユーザー B またはアカウント管理者によって作成された)アカウントレベルの webhook がある。

いいえ

ユーザー B のアカウントレベルの webhook は、署名者 webhook と見なされます。

ユーザー B のアカウントに(ユーザー B またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー B とグループ管理者は、同じグループ内です。

いいえ

ユーザー B のグループレベルの webhook は、署名者 webhook と見なされます。

ユーザー B にユーザーレベルの webhook がある。

いいえ

ユーザー B のユーザーレベルの webhook は、署名者 webhook と見なされます。

     

ユーザー C のアカウントに(ユーザー C またはアカウント管理者によって作成された)アカウントレベルの webhook がある。

いいえ

ユーザー C のアカウントレベルの webhook は、非作成者 webhook と見なされます。

ユーザー C のアカウントに(ユーザー C またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー C とグループ管理者は、同じグループ内です。

いいえ

ユーザー C のグループレベルの webhook は、非作成者 webhook と見なされます。

ユーザー C にユーザーレベルの webhook がある。

いいえ

ユーザー C のユーザーレベルの webhook は、非作成者 webhook と見なされます。

送信者:ユーザー A | 署名者:ユーザー B | 共有相手:ユーザー C

ユーザー A、ユーザー B、ユーザー C が同じアカウント内

ユースケース

通知

メモ

ユーザー A のアカウントに、(ユーザー A またはアカウント管理者によって作成された)アカウントレベルの webhook がある。

はい

アカウントレベルの webhook は、アカウントによってトリガーされたイベントについて通知します。

ユーザー A のアカウントに、(ユーザー A またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー A とグループ管理者は、同じグループ内です。

はい

グループレベルの webhook は、グループ内のユーザーによってトリガーされたイベントについて通知します。

ユーザー A に、ユーザーレベルの webhook がある。

はい

送信者として、ユーザー A のユーザーレベルの webhook がトリガーされます

ユーザー A に、(上記で送信された契約書用の)リソースレベルの webhook がある。

はい

 
     

ユーザー B のアカウントに(ユーザー B またはアカウント管理者によって作成された)アカウントレベルの webhook がある。

はい

ユーザー A とユーザー B は同じアカウント内のため、アカウントレベルの webhook は、そのアカウントでトリガーされたすべてのイベントの通知を受けます。

ユーザー B のアカウントに(ユーザー B またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー A、ユーザー B およびグループ管理者は、同じグループ内です。

はい

ユーザー A とユーザー B は同じグループ内のため、グループレベルの webhook は、そのグループでトリガーされたすべてのイベントの通知を受けます。

ユーザー B のアカウントに(ユーザー B またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー A とユーザー B は、異なるグループ内です。

いいえ

ユーザー B のグループレベルの webhook は、署名者 webhook と見なされます。

ユーザー A の webhook(リソースユーザー/グループ/アカウント)がトリガーされます。

ユーザー B にユーザーレベルの webhook がある。

いいえ

受信者として、ユーザー B のユーザーレベルの webhook はトリガーされません。

     

ユーザー C のアカウントに(ユーザー C またはアカウント管理者によって作成された)アカウントレベルの webhook がある。

はい

ユーザー A とユーザー C は同じアカウント内のため、アカウントレベルの webhook は、そのアカウントでトリガーされたすべてのイベントの通知を受けます。

ユーザー C のアカウントに(ユーザー C またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー A、ユーザー C およびグループ管理者は、同じグループ内です。

はい

ユーザー A とユーザー C は同じグループ内のため、グループレベルの webhook は、そのグループでトリガーされたすべてのイベントの通知を受けます。

ユーザー C のアカウントに(ユーザー C またはアカウント/グループ管理者によって作成された)グループレベルの webhook がある。

想定:ユーザー A とユーザー C は、異なるグループ内です。

いいえ

ユーザー C のグループレベルの webhook は、非作成者 webhook と見なされます。

ユーザー A の webhook(リソースユーザー/グループ/アカウント)がトリガーされます。

ユーザー C にユーザーレベルの webhook がある。

いいえ

ユーザー C のユーザーレベルの webhook は、非作成者 webhook と見なされます。

リッスンサービスがダウンしているときの再試行

Webhook のターゲット URL が何らかの理由でダウンしている場合、Acrobat Sign は JSON をキューに入れ、72 時間にわたるプログレッシブサイクルでプッシュを再試行します。

未配信のイベントは再試行キューに保持され、発生順に通知を配信するために、次の 72 時間にわたってベストエフォート型配信が実行されます。

通知配信の再試行戦略では、試行間隔を倍増し、1 分間隔から始めて 12 時間ごとまでに増やします。結果として、72 時間の間に 15 回の再試行が行われます。

Webhook 受信者が 72 時間以内に応答せず、過去 7 日間に通知の配信が成功しなかった場合、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 日 マイアミビーチおよびオンライン