Benutzerhandbuch Abbrechen

Webhooks – Übersicht

 

Adobe Acrobat Sign-Handbuch

Neue Funktionen

  1. Vorabversionshinweise
  2. Versionshinweise
  3. Wichtige Benachrichtigungen

Erste Schritte

  1. Kurzanleitung für Administrierende
  2. Kurzanleitung für Benutzende
  3. Für Entwicklerinnen und Entwickler
  4. Video-Tutorial-Bibliothek
  5. Häufig gestellte Fragen

Verwaltung

  1. Übersicht über die Admin Console
  2. Benutzendenverwaltung
    1. Benutzende hinzufügen
    2. Hinzufügen von mehreren Benutzenden
    3. Hinzufügen von Benutzenden aus deinem Verzeichnis
    4. Hinzufügen von Benutzenden aus MS Azure Active Directory
    5. Erstellen von funktionsorientierten Benutzenden
      1. Technikkonten – API-gesteuert
      2. Dienstkonten – Manuell gesteuert
    6. Suche nach Nutzenden mit Bereitstellungsfehlern
    7. Ändern des Namens/der E-Mail-Adresse
    8. Gruppenmitgliedschaft von Benutzenden bearbeiten
    9. Bearbeiten der Gruppenmitgliedschaft von Benutzenden über die Gruppenoberfläche
    10. Hochstufen von Benutzenden zu einer Administrationsrolle
    11. Benutzeridentitätstypen und SSO
    12. Wechseln der Benutzeridentität
    13. Authentifizieren von Benutzenden mit MS Azure
    14. Authentifizieren von Benutzenden mit Google Federation
    15. Produktprofile
    16. Anmeldung 
  3. Konto-/Gruppeneinstellungen
    1. Einstellungsübersicht
    2. Globale Einstellungen
      1. Kontoebene und ID
      2. Workflows zum Selbstsignieren
      3. Massenversand
      4. Webformulare
      5. Benutzerdefinierte Sende-Workflows
      6. Power Automate-Workflows
      7. Bibliotheksdokumente
      8. Formulardaten mit Vereinbarungen erfassen
      9. Eingeschränkte Dokumentsichtbarkeit
      10. Anhängen einer PDF-Kopie der signierten Vereinbarung 
      11. Einfügen eines Links in eine E-Mail
      12. Einfügen eines Bilds in eine E-Mail
      13. An E-Mails angehängte Dateien werden folgendermaßen benannt:
      14. Anhängen von Audit-Berichten an Dokumente
      15. Zusammenführen mehrerer Dokumente zu einem Dokument
      16. Signiertes Dokument hochladen
      17. Delegation für Benutzende in meinem Konto
      18. Externen Empfangenden das Delegieren erlauben
      19. Signaturberechtigung
      20. Sendeberechtigung
      21. Berechtigung zum Hinzufügen elektronischer Siegel
      22. Festlegen einer Standardzeitzone
      23. Festlegen eines Standarddatumsformats
      24. Benutzende in mehreren Gruppen (UMG)
        1. Upgrade zur Verwendung von UMG
      25. Berechtigungen für Gruppenadministrierende
      26. Empfangende ersetzen
      27. Audit-Bericht
        1. Übersicht
        2. Nicht authentifizierten Zugriff auf der Transaktionsbestätigungsseite zulassen
        3. Aufnehmen von Erinnerungen
        4. Aufnehmen von Anzeigeereignissen
        5. Aufnehmen der Seiten-/Anhangsanzahl der Vereinbarung
      28. In Produktbotschaften und Anleitungen
      29. Barrierefreie PDF-Dateien
      30. Neues Authoring-Erlebnis
      31. Kundinnen und Kunden im Gesundheitswesen
    3. Kontoeinrichtung
      1. Logo hinzufügen
      2. Anpassen des Hostnamens/der URL des Unternehmens
      3. Firmenname hinzufügen
    4. Signaturvorgaben
      1. Korrekt formatierte Signaturen
      2. Empfangenden das Signieren erlauben durch
      3. Unterzeichnende können ihren Namen ändern
      4. Empfangenden erlauben, ihre gespeicherte Signatur zu verwenden
      5. Selbstdefinierte Nutzungsbedingungen und Hinweis für Kundinnen und Kunden
      6. Empfangende durch Formularfelder leiten
      7. Signieren ablehnen
      8. Stempel-Workflows erlauben
      9. Unterzeichnende auffordern, ihre Stellenbezeichnung oder ihr Unternehmen anzugeben
      10. Unterzeichnenden das Drucken und Einfügen von handschriftlichen Signaturen erlauben
      11. Anzeigen von Nachrichten beim elektronischen Signieren
      12. Unterzeichnende müssen ein Mobilgerät verwenden, um ihre Signatur zu erstellen
      13. IP-Adresse von Unterzeichnenden anfordern
      14. Firmenname und Stellenbezeichnung sollen nicht aus dem Teilnahmestempel ersichtlich sein
    5. Digitale Signaturen
      1. Übersicht
      2. Herunterladen und Signieren mit Acrobat
      3. Signieren mit Cloud-Signaturen
      4. Metadaten für Identitätsanbieter einschließen
      5. Anbieter eingeschränkter Cloud-Signaturen
    6. Elektronische Siegel
    7. Digital Identity
      1. Digital Identity Gateway
      2. Richtlinie zu Identitätsprüfung
    8. Berichteinstellungen
      1. Neues Berichtserlebnis
      2. Einstellungen für den klassischen Bericht
    9. Sicherheitseinstellungen
      1. Einstellungen für Single Sign-on
      2. Einstellungen zum Merken der Anmeldedaten
      3. Richtlinien für Anmeldekennwort
      4. Stärke für Anmeldekennwort
      5. Dauer der Internet-Sitzung
      6. Art der PDF-Verschlüsselung
      7. API
      8. Zugriff auf Benutzenden- und Gruppeninformationen
      9. Erlaubte IP-Bereiche
      10. Kontofreigabe
      11. Berechtigungen zur Kontofreigabe
      12. Steuerelemente für das Freigeben von Vereinbarungen
      13. Bestätigung der Unterzeichnendenidentität
      14. Kennwort für das Signieren einer Vereinbarung
      15. Dokumentkennwortstärke
      16. Unterzeichnende anhand des geografischen Standorts sperren
      17. Telefonauthentifizierung
      18. Wissensbasierte Authentifizierung (KBA)
      19. Zulassen der Seitenextraktion
      20. Ablauf des Dokumentlinks
      21. Hochladen eines Clientzertifikats für Webhooks/Rückrufe
      22. Zeitstempel
    10. Sendeeinstellungen
      1. Anzeigen der Seite „Senden“ nach der Anmeldung
      2. Name der Empfangspartei beim Senden erforderlich
      3. Sperren der Namenswerte für bekannte Benutzende
      4. Zulässige Empfangsrollen
      5. Gruppen empfangender Personen
      6. Erforderliche Felder
      7. Anhängen von Dokumenten
      8. Feldreduzierung
      9. Vereinbarungen bearbeiten
      10. Vereinbarungsname
      11. Sprachen
      12. Private Nachrichten
      13. Erlaubte Signaturarten
      14. Erinnerungen
      15. Kennwortschutz für signierte Dokumente
      16. Identifikationsoptionen für Unterzeichnende
        1. Übersicht
        2. Signierkennwort
        3. Einmalpasswort per E-Mail
        4. Acrobat Sign-Authentifizierung
        5. Telefonauthentifizierung
        6. Cloud-basierte digitale Signatur
        7. Wissensbasierte Authentifizierung
        8. Amtl. Lichtbildausweis
        9. Identitätsberichte der Unterzeichnenden
      17. Inhaltsschutz
      18. Aktivieren von Beglaubigungs-Transaktionen
      19. Dokumentablauf
      20. Anzeigen der Vorschau, Positionieren von Signaturen und Hinzufügen von Formularfeldern
      21. Signierreihenfolge
      22. Liquid Mode
      23. Optionen für selbstdefinierte Workflows
      24. Upload-Optionen auf der E-Sign-Seite
      25. Bestätigungs-URL-Umleitung nach der Signatur
    11. Nachrichtenvorlagen
    12. Bio-Pharma-Einstellungen
      1. Übersicht
      2. Authentifizierung der Identität verlangen
      3. Gründe für das Unterzeichnen
    13. Workflow-Integration
    14. Beglaubigungs-Einstellungen
    15. Zahlungsintegration
    16. Nachrichten für Unterzeichnende
    17. SAML-Einstellungen
      1. SAML-Konfiguration
      2. Installieren des Active Directory Federation Service
      3. Installieren von Okta
      4. Installieren von OneLogin
      5. Installieren von Oracle Identity Federation
    18. Datennutzungsrechte
    19. Zeitstempel-Einstellungen
    20. Externes Archiv
    21. Kontosprachen
    22. E-Mail-Einstellungen
      1. Bilder für E-Mail-Kopf- oder Fußzeile
      2. Zulassen von E-Mail-Fußzeilen für einzelne Benutzende
      3. Anpassen der „Signatur angefordert“-E-Mail
      4. Anpassen der Felder „An“ und „CC“
      5. Benutzerdefinierte E-Mail-Vorlagen
      6. Benachrichtigungen ohne Links aktivieren
    23. Migration von echosign.com zu adobesign.com
    24. Konfigurieren von Optionen für Empfangende
  4. Leitfaden für regulatorische Anforderungen
    1. Barrierefreiheit
      1. Einhaltung der Barrierefreiheitsrichtlinien
      2. Erstellen barrierefreier Formulare mit Acrobat für den Desktop
      3. Erstellen barrierefreier AcroForms
    2. HIPAA
    3. DSGVO
      1. Überblick über die DSGVO
      2. Benutzende schwärzen
      3. Vereinbarungen Benutzender schwärzen
    4. 21 CFR Part 11 und EudraLex Annex 11
      1. 21 CRF Part 11 Validierungspaket
      2. Handbuch für 21 CFR und EudraLex Annex 11
      3. Analyse der gemeinsamen Verantwortung
    5. Kundinnen und Kunden im Gesundheitswesen
    6. IVES-Unterstützung
    7. eOriginal-Archivierung für Sicherungsscheine
    8. Überlegungen der EU/des Vereinigten Königreichs
      1. Grenzüberschreitende Transaktionen zwischen der EU und dem Vereinigten Königreich und eIDAS
      2. HMLR-Anforderungen für elektronisch signierte Urkunden
      3. Die Auswirkungen des Brexit auf die Gesetze zu elektronischen Signaturen im Vereinigten Königreich
  5. Gleichzeitiges Herunterladen von mehreren Vereinbarungen
  6. Anfordern deiner Domäne 

Senden, Signieren und Verwalten von Vereinbarungen

  1. Vereinbarungen senden  
    1. Übersicht der Seite „Senden“
    2. Senden einer Vereinbarung nur an sich selbst
    3. Senden einer Vereinbarung an andere
    4. Handschriftliche Signaturen
    5. Signierreihenfolge der Empfangenden
    6. Massenversand
      1. Überblick über die Massenversand-Funktion
      2. Massenversand – Manuell eingegebene Empfangende
      3. Massenversand – CSV-Upload
      4. Massenversand-Transaktion abbrechen
      5. Erinnerungen zum Massenversand hinzufügen
      6. Berichterstattung für den Massenversand
  2. Erstellen von Feldern in Dokumenten
    1. In-App-Authoring-Umgebung
      1. Automatische Felderkennung
      2. Ziehen und Ablegen von Feldern in der Authoring-Umgebung
      3. Formularfelder zu Empfangenden zuweisen
      4. Die Rolle „Vorausfüllen“
      5. Anwenden von Feldern mit einer wiederverwendbaren Feldvorlage
      6. Felder in eine neue Bibliotheksvorlage übertragen
      7. Aktualisierte Authoring-Umgebung beim Senden von Vereinbarungen
    2. Erstellen von Formularen mit Text-Tags
    3. Erstellen von Formularen mit Acrobat (AcroForms)
      1. AcroForm-Erstellung
      2. Barrierefreie PDF-Dokumente erstellen
    4. Felder
      1. Feldtypen
        1. Häufige Feldtypen
        2. Inline-Bilder
        3. Stempelbilder
      2. Erscheinungsbild des Feldinhalts
      3. Feldüberprüfungen
      4. Werte für maskierte Felder
      5. Festlegen von Bedingungen für das Ein-/Ausblenden
      6. Berechnete Felder
  1. Authoring-FAQ
  2. Signieren von Vereinbarungen
    1. Signieren von an sich selbst gesendeten Vereinbarungen
    2. Ausfüllen & Signieren
    3. Selbstsignieren
  3. Verwalten von Vereinbarungen
    1. Übersicht über die Seite „Verwalten“
    2. Delegieren von Vereinbarungen
    3. Ersetzen von Empfangenden
    4. Eingeschränkte Dokumentsichtbarkeit 
    5. Abbrechen einer Vereinbarung
    6. Erstellen von neuen Erinnerungen
    7. Überprüfen von Erinnerungen
    8. Stornieren von Erinnerungen
    9. Weitere Aktionen...
      1. Funktionsweise der Suche
      2. Anzeigen einer Vereinbarung
      3. Vorlage aus einer Vereinbarung erstellen
      4. Aus-/Einblenden von Vereinbarungen
      5. Hochladen einer signierten Vereinbarung
      6. Ändern von Dateien und Feldern einer gesendeten Vereinbarung
      7. Bearbeiten der Authentifizierungsmethode einer Empfangspartei
      8. Hinzufügen oder Ändern eines Ablaufdatums
      9. Hinzufügen einer Notiz zu einer Vereinbarung
      10. Freigabe einer einzelnen Vereinbarung
      11. Aufheben der Freigabe einer Vereinbarung
      12. Herunterladen einer einzelnen Vereinbarung
      13. Herunterladen einzelner Dateien einer Vereinbarung
      14. Herunterladen des Audit-Berichts einer Vereinbarung
      15. Herunterladen des Feldinhalts einer Vereinbarung
  4. Audit-Bericht
  5. Berichte und Datenexporte
    1. Übersicht
    2. Zugriffserteilung auf Berichte für Benutzende
    3. Berichtsdiagramme
      1. Erstellen eines neuen Berichts
      2. Vereinbarungsberichte
      3. Transaktionsberichte
      4. Einstellungsaktivitätsbericht
      5. Bearbeiten eines Berichts
    4. Datenexporte 
      1. Erstellen eines neuen Datenexports
      2. Bearbeiten eines Datenexports
      3. Aktualisieren des Datenexportinhalts
      4. Herunterladen des Datenexports
    5. Umbenennen eines Berichts/Exports
    6. Duplizieren eines Berichts/Exports
    7. Planen eines Berichts/Exports
    8. Löschen eines Berichts/Exports
    9. Überprüfen des Transaktionsverbrauchs

Erweiterte Vereinbarungsfunktionen und Workflows

  1. Webformulare 
    1. Erstellen eines Webformulars
    2. Bearbeiten eines Webformulars
    3. Deaktivieren/Aktivieren eines Webformulars
    4. Ein-/Ausblenden eines Webformulars
    5. Abrufen der URL oder des Skriptcodes 
    6. Vorausfüllen von Webformularfeldern mithilfe von URL-Parametern
    7. Speichern eines Webformulars, um es später auszufüllen
    8. Ändern der Größe eines Webformulars
  2. Wiederverwendbare Vorlagen (Bibliotheksvorlagen) 
    1. US-Behördenformulare in der Acrobat Sign-Bibliothek
    2. Erstellen einer Bibliotheksvorlage
    3. Ändern des Namens einer Bibliotheksvorlage
    4. Ändern des Typs einer Bibliotheksvorlage
    5. Ändern der Berechtigungsebene einer Bibliotheksvorlage
    6. Kopieren, Bearbeiten und Speichern einer freigegebenen Vorlage
    7. Herunterladen der aggregierten Felddaten für eine Bibliotheksvorlage
  3. Übertragen des Eigentums an Webformularen und Bibliotheksvorlagen
  4. Power Automate-Workflows
    1. Überblick über die Power Automate-Integration und die enthaltenen Berechtigungen
    2. Aktivieren der Power Automate-Integration
    3. Verfolgen der Nutzung von Power Automate
    4. Erstellen eines neuen Flows (Beispiele)
    5. Auslöser für Flows
    6. Importieren von Flows von außerhalb von Acrobat Sign
    7. Verwalten von Flows
    8. Bearbeiten von Flows
    9. Freigeben von Flows
    10. Deaktivieren oder Aktivieren von Flows
    11. Löschen von Flows
    12. Nützliche Vorlagen
      1. Nur Administration
        1. Speichern aller abgeschlossenen Dokumente in SharePoint
        2. Speichern aller abgeschlossenen Dokumente in OneDrive for Business
        3. Speichern aller abgeschlossenen Dokumente in Google Drive
        4. Speichern aller abgeschlossenen Dokumente in Dropbox
        5. Speichern aller abgeschlossenen Dokumente in Box
      2. Archivierung von Vereinbarungen
        1. Speichern deiner abgeschlossenen Dokumente in SharePoint
        2. Speichern deiner abgeschlossenen Dokumente in OneDrive for Business
        3. Speichern deiner abgeschlossenen Dokumente in Google Drive
        4. Speichern deiner abgeschlossenen Dokumente in Dropbox
        5. Speichern deiner abgeschlossenen Dokumente in Box
      3. Archivierung von Webformularvereinbarungen
        1. Speichern abgeschlossener Webformulardokumente in der SharePoint-Bibliothek
        2. Speichern abgeschlossener Dokumente in OneDrive for Business
        3. Speichern abgeschlossener Dokumente in Google Drive
        4. Speichern abgeschlossener Webformulardokumente in Box
      4. Extraktion von Vereinbarungsdaten
        1. Extrahieren von Formularfelddaten aus einem signierten Dokument und Aktualisieren eines Excel-Arbeitsblatts
      5. Vereinbarungsbenachrichtigungen
        1. Senden selbstdefinierter E-Mail-Benachrichtigungen mit dem Vereinbarungsinhalt und der signierten Vereinbarung
        2. Abrufen von Adobe Acrobat Sign-Benachrichtigungen in einem Teams-Kanal
        3. Abrufen von Adobe Acrobat Sign-Benachrichtigungen in Slack
        4. Abrufen von Adobe Acrobat Sign-Benachrichtigungen in Webex
      6. Vereinbarungsgenerierung
        1. Erstellen eines Dokuments aus einem Power Apps-Formular und einer Word-Vorlage sowie Senden zum Signieren
        2. Generieren einer Vereinbarung aus einer Word-Vorlage in OneDrive und Einholen der Signatur
        3. Generieren einer Vereinbarung für ausgewählte Excel-Zeile und Senden zur Überprüfung und Signatur
  5. Selbstdefinierte Sende-Workflows
    1. Übersicht über selbstdefinierte Sende-Workflows
    2. Erstellen eines neuen Sende-Workflows
    3. Bearbeiten eines Sende-Workflows
    4. Aktivieren oder Deaktivieren eines Sende-Workflows
    5. Senden einer Vereinbarung mit einem Sende-Workflow
  6. Freigeben von Benutzenden und Vereinbarungen
    1. Freigeben von Benutzenden
    2. Freigeben von Vereinbarungen

Integration in andere Produkte

  1.  Übersicht über Acrobat Sign-Integrationen 
  2. Acrobat Sign für Salesforce
  3. Acrobat Sign für Microsoft
    1. Acrobat Sign für Microsoft 365
    2. Acrobat Sign für Outlook
    3. Acrobat Sign für Word/PowerPoint
    4. Acrobat Sign für Teams
    5. Acrobat Sign für Microsoft PowerApps und Power Automate
    6. Acrobat Sign Connector für Microsoft Search
    7. Acrobat Sign für Microsoft Dynamics
    8. Acrobat Sign für Microsoft SharePoint 
  4. Weitere Integrationen
    1. Acrobat Sign für ServiceNow
    2. Acrobat Sign für HR ServiceNow
    3. Acrobat Sign für SAP SuccessFactors
    4. Acrobat Sign für Workday
    5. Acrobat Sign für NetSuite
    6. Acrobat Sign für VeevaVault
    7. Acrobat Sign für Coupa BSM Suite
  5. Von Partnern verwaltete Integrationen
  6. Erstellen eines Integrationsschlüssels

Acrobat Sign-Entwickler

  1. REST-APIs 
    1. Methodendokumentation
    2. SDK/Entwicklungshandbuch
    3. Häufige Fragen zu APIs
  2. Webhooks 
    1. Übersicht über Webhooks
    2. Konfigurieren eines neuen Webhooks
    3. Anzeigen oder Bearbeiten eines Webhooks
    4. Deaktivieren oder erneutes Aktivieren eines Webhooks
    5. Löschen eines Webhooks
    6. Zwei-Wege-SSL-Zertifikate
    7. Webhooks in der API

Support und Fehlerbehebung

  1. Kunden-Support-Ressourcen
  2. Ressourcen für den Erfolg von Unternehmenskundschaft 

Übersicht

Ein Webhook ist eine selbstdefinierte HTTPS-Anforderung, die ausgelöst wird, wenn ein abonniertes Ereignis auf der Quell-Website (in diesem Fall Adobe Acrobat Sign) auftritt.

Im Prinzip ist ein Webhook also nichts anderes als ein REST-Service, der Daten oder einen Datenstrom akzeptiert.

Webhooks sind für die Dienst-zu-Dienst-Kommunikation in einem PUSH-Modell konzipiert.

Wenn ein abonniertes Ereignis ausgelöst wird, erstellt Acrobat Sign eine HTTPS-POST-Anforderung mit einem JSON-Text und stellt diese für die angegebene URL bereit.

Vergewissere dich vor der Konfiguration von Webhooks, dass dein Netzwerk die für die Funktionalität erforderlichen IP-Bereiche akzeptiert.

 

Webhooks bieten im Vergleich zur vorherigen Callback-Methode mehrere Vorteile, darunter:

  • Admins können ihre Webhooks aktivieren, ohne dass sie den Acrobat Sign-Support zur Auflistung der Rückruf-URL einbeziehen müssen.
  • Webhooks sind in Bezug auf Datenaktualität, effiziente Kommunikation und Sicherheit leistungsfähiger. Keine Auswahl erforderlich
  • Webhooks lassen unterschiedliche Umfangsbereiche (Konto/Gruppe/Benutzer/Ressource) zu. 
  • Webhooks sind eine modernere API-Lösung, die eine einfachere Konfiguration moderner Anwendungen ermöglicht.
  • Pro Geltungsbereich (Konto/Gruppe/Benutzer/Ressource) können mehrere Webhooks konfiguriert werden, wohingegen Callbacks eindeutig sein mussten.
  • Webhooks ermöglichen die Auswahl der zurückzugebenden Daten, wohingegen Callbacks eine „Alles oder nichts“-Lösung sind.
  • Es kann konfiguriert werden, welche Metadaten (einfach oder detailliert) mit einem Webhook übertragen werden
  • Webhooks sind wesentlich einfacher zu erstellen, zu bearbeiten oder nach Bedarf zu deaktivieren, da die Benutzeroberfläche vollständig der Kontrolle der Administrator*innen unterliegt.
Hinweis:

Dieses Dokument konzentriert sich hauptsächlich auf die Webhooks-Benutzeroberfläche in der Acrobat Sign-Webanwendung (früher Adobe Sign).

Entwickler*innen, die nach API-Details suchen, finden weitere Informationen hier:

Voraussetzungen

Du musst sicherstellen, dass dein Netzwerksicherheitssystem die IP-Bereiche für Webhooks akzeptiert, damit der Dienst funktioniert. 

Bei dem älteren Rückruf-URL-Dienst in REST v5 werden dieselben IP-Bereiche verwendet wie beim Webhook-Dienst.

Admins können sich bei der Adobe Admin Konsole anmelden, um Benutzende hinzuzufügen. Navigiere nach der Anmeldung zum Admin-Menü und scrolle nach unten zu Webhooks.

Und so funktioniert's

Administratoren benötigen zunächst einen Webhook-Dienst, der bereit ist, eingehende Push-Nachrichten von Acrobat Sign zu akzeptierten. Hierfür gibt es viele Optionen. Solange der Dienst POST- und GET-Anforderungen akzeptieren kann, ist der Webhook erfolgreich.

Sobald der Dienst eingerichtet ist, kann ein Acrobat Sign-Administrator einen neuen Webhook über die Webhook-Benutzeroberfläche im Kontomenü der Acrobat Sign-Website erstellen.

Admins können den Webhook so konfigurieren, dass er für Ereignisse im Zusammenhang mit Vereinbarungen, Webformularen (Widget) oder dem Massenversand (MegaSign) ausgelöst wird. Die Bibliotheksvorlagen-(Bibliotheksdokument-)ressource kann auch über die API konfiguriert werden.

Der Geltungsbereich des Webhook kann das gesamte Konto oder einzelne Gruppen über die Admin-Oberfläche umfassen. Die API ermöglicht durch die Auswahl der Geltungsbereiche USER oder RESOURCE eine größere Granularität.

Die Art der Daten, die an die URL übertragen werden, ist konfigurierbar und kann z. B. Vereinbarungsinformationen, Teilnahmeinformationen, Dokumentinformationen usw. umfassen.

Nachdem der Webhook konfiguriert und gespeichert wurde, sendet Acrobat Sign jedes Mal ein neues JSON-Objekt an die definierte URL, wenn das abonnierte Ereignis ausgelöst wird. Eine laufende Bearbeitung des Webhooks ist nicht erforderlich, es sei denn, du möchtest die Kriterien für die Ereignisauslösung oder die JSON-Payload ändern.

Überprüfung des Intents der Webhook-URL

Bevor ein Webhook erfolgreich registriert wird, überprüft Acrobat Sign, ob die Webhook-URL, die in der Registrierungsanforderung angegeben ist, Benachrichtigungen erhalten möchte oder nicht. Wenn Acrobat Sign eine neue Webhook-Registrierungsanforderung erhält, wird zunächst eine Überprüfungsanforderung an die Webhook-URL gesendet. Bei dieser Überprüfungsanforderung handelt es sich um eine HTTPS-GET-Anforderung, die an die Webhook-URL gesendet wird. Diese Anforderung hat den benutzerdefinierten HTTP-Header „X-AdobeSign-ClientId“. Der Wert in diesem Header ist auf die Client-ID (Anwendungs-ID) der API-Anwendung festgelegt, die die Erstellung/Registrierung des Webhooks anfordert. Um einen Webhook erfolgreich zu registrieren, muss die Webhook-URL mit einem 2XX-Antwortcode auf diese Überprüfungsanforderung reagieren. DARÜBER HINAUS MUSS die Webhook-URL zusätzlich denselben Client-ID-Wert auf eine der beiden folgenden Weisen zurücksenden:

  • Entweder mit „X-AdobeSign-Certified“ in der Kopfzeile der Antwort. Dies ist die gleiche Kopfzeile, die in der Anfrage übergeben wurde und in der Antwort als Echo ausgegeben wird.
  • Oder im JSON-Antworttext, wobei der Schlüssel von xAdobeSignClientId und dessen Wert dieselbe Client-ID sind, die in der Anforderung gesendet wurde.

Der Webhook wird nur bei einer erfolgreichen Antwort (2XX-Antwortcode) und Validierung der Client-ID in Kopfzeile oder Antworttext erfolgreich registriert. Ziel dieser Überprüfungsanforderung ist, anzuzeigen, dass deine Webhook-URL tatsächlich Benachrichtigungen unter dieser URL erhalten möchte. Wenn du versehentlich die falsche URL eingegeben hast, reagiert die URL nicht korrekt auf die Überprüfung der Intent-Anforderung und Acrobat Sign sendet keine Benachrichtigungen an diese URL. Darüber hinaus kann die Webhook-URL auch validieren, dass sie Benachrichtigungen nur über die Webhooks erhält, die von einer bestimmten Anwendung registriert wurden. Dies kann durch Validierung der Client-ID der Anwendung erfolgen, die in der X-AdobeSign-ClientId-Kopfzeile übergeben wurde. Wenn die Webhook-URL diese Client-ID nicht erkennt, DARF SIE NICHT mit dem Erfolgsantwortcode antworten und Acrobat Sign sorgt dafür, dass die URL nicht als Webhook registriert wird.

Die Verifizierung des Webhook-URL-Aufrufs erfolgt in den folgenden Szenarien:

  • Webhook-Registrierung: Wenn diese Überprüfung des Webhook-URL-Aufrufs fehlschlägt, wird der Webhook nicht erstellt.
  • Webhook-Aktualisierung: INAKTIV in AKTIV: Wenn diese Überprüfung des Webhook-URL-Aufrufs fehlschlägt, wird der Webhook-Status nicht in AKTIV geändert.

So reagierst du auf eine Webhook-Benachrichtigung

Acrobat Sign führt eine implizite Überprüfung des Intents in jeder Webhook-Benachrichtigungsanforderung durch, die an die Webhook-URL gesendet wird. Daher enthält jede Webhook-HTTPS-Benachrichtigungsanforderung auch den benutzerdefinierten HTTP-Header mit der Bezeichnung „X-AdobeSign-ClientId“. Der Wert dieses Headers ist die Client-ID (Anwendungs-ID) der Anwendung, die den Webhook erstellt hat. Die Webhook-Benachrichtigung gilt nur dann als erfolgreich zugestellt, wenn, und nur wenn, eine erfolgreiche Antwort (2XX-Antwortcode) zurückgegeben wird und die Client-ID entweder in der HTTP-Kopfzeile (X-AdobeSign-ClientId) oder in einem JSON-Antworttext mit dem Schlüssel „xAdobeSignClientId“ und dem Wert derselben Client-ID gesendet wird. Andernfalls wird erneut versucht, die Benachrichtigung an die Webhook-URL zu senden, bis die Wiederholungsversuche aufgebraucht sind.

Wie oben erwähnt, sollte der Header „X-AdobeSign-ClientId“, der in jeder Benachrichtigungsanforderung von Sign enthalten ist, in einer Antwort auf eine der beiden folgenden Weisen zurückgegeben werden:

1. HTTP-Header X-AdobeSign-ClientId und Wert der Client-ID

Beispiel-Javascript-Code zum Abrufen der Client-id, Validierung und Rückgabe im Antwortheader

// Fetch client id

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

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Ersetze „BGBQIIE7H253K6“ durch die Client-ID der Anwendung, mit der der Webhook erstellt wird

{

    //in Antwortheader zurückgeben

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

    response.status = 200;  // Standardwert

}

PHP-Beispielcode, um die Client-ID abzurufen, zu validieren und dann im Antwortheader zurückzugeben

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Ersetze „BGBQIIE7H253K6“ durch die Client-ID der Anwendung, mit der der Webhook erstellt wird

{

    //in Antwortheader zurückgeben

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

   header("HTTP/1.1 200 OK"); // Standardwert

}

?>


2. JSON-Antworttext mit dem Schlüssel „xAdobeSignClientId“ und dem Wert derselben Client-ID

Beispieljavascriptcode, um die Client-ID abzurufen, zu validieren und dann im Antworttext zurückzugeben

// Fetch client id

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

 

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Ersetze „BGBQIIE7H253K6“ durch die Client-ID der Anwendung, mit der der Webhook erstellt wird

{

    var responseBody = {

                         "xAdobeSignClientId"?: clientid // Rückkehr-Kunden-Identifikation im Haupttext

                       };

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

    response.body = responseBody;

    response.status = 200;

}

PHP-Beispielcode, um die Client-ID abzurufen, zu validieren und dann im Antworttext zurückzugeben

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Ersetze „BGBQIIE7H253K6“ durch die Client-ID der Anwendung, mit der der Webhook erstellt wird

{

   //im Antworttext zurückgeben

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

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

   echo json_encode($body);

   header("HTTP/1.1 200 OK"); // Standardwert

}

?>

Beispiel-JSON Antworttext

{

    "xAdobeSignClientId": "BGBQIIE7H253K6"

}

Voraussetzungen

Du musst:

  1. Ein Microsoft-Konto mit Lizenz zum Erstellen von Azure Functions Applications haben
  2. Ein vorhandene Azure Function Application haben. Du kannst eine mithilfe von https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function erstellen
  3. Grundkenntnisse von JavaScript haben, damit du den Code in jeder beliebigen Sprache deiner Wahl verstehen und schreiben kannst

Schritte zum Erstellen eines Azure Function-Auslösers, der als Acrobat Sign-Webhook fungiert

Um eine JavaScript HTTP-Triggerfunktion zu erstellen:

1. Melde dich über dein Microsoft-Konto an: https://portal.azure.com/

2. Öffne deine Azure Function Application, die auf der Registerkarte „Funktions-Apps“ angezeigt wird.

Zu Funktions-Apps in Azure navigieren

Dadurch wird deine Liste von Azure Function Applications geöffnet:

3. Wähle die Anwendung, in der du diese neue Funktion erstellen möchtest

4. Klicke auf Erstellen (+), um eine neue Azure-Funktion zu erstellen.

Azure-Funktion erstellen

 

5. Wähle Webhook + API als das Szenario und JavaScript als Sprache

6. Klicke auf diese Funktion erstellen

Es wird eine neue Funktion erstellt, die eine eingehende API-Anforderung verarbeiten kann.

Logik hinzufügen, um den Acrobat Sign-Webhook zu registrieren

Bevor ein Webhook erfolgreich registriert wird, überprüft Acrobat Sign, ob die Webhook-URL, die in der Registrierungsanforderung angegeben ist, wirklich Benachrichtigungen erhalten möchte oder nicht. Wenn Acrobat Sign eine neue Webhook-Registrierungsanforderung empfängt, wird deshalb zunächst eine Überprüfungsanforderung an die Webhook-URL gestellt. Diese Überprüfungsanforderung ist eine HTTPS-GET-Anforderung, die mit einem benutzerdefinierten HTTP-Header X-AdobeSign-ClientId an die Webhook-URL gesendet wird. Der Wert in diesem Header ist auf die Client-ID der Anwendung festgelegt, die das Erstellen/Registrieren des Webhooks anfordert. Um einen Webhook erfolgreich zu registrieren, muss die Webhook-URL auf diese Überprüfungsanforderung mit einem 2XX-Antwortcode reagieren. ZUSÄTZLICH MUSS die Webhook-URL denselben Client-ID-Wert auf eine der beiden folgenden Weisen zurücksenden:

Es gibt zwei Optionen, die du befolgen kannst:


Option 1: Übergib die Client-ID mit „X-AdobeSign-ClientId“ als Antwortheader

Übergib X-AdobeSign-ClientId im Antwortheader. Dies ist der gleiche Titel, der in der Anforderung übergeben wurde, und muss in der Antwort zurückgegeben kopiert werden.

Ersetze die Index.js-Datei durch Folgendes:

Datei „index.js“ ersetzen

module.exports = function (context, req) {

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

    // Validiere, dass die eingehende ClientID echt ist

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

        context.res = {

            // Status: 200/* Standardwert ist 200 * // jede Antwort im Format 2XX ist akzeptabel

            body: "Notification Accepted",

            headers : {

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

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Ups!! Illegitimer Aufruf identifiziert"

        };

    }

    context.done();

};

 

Teste das Verhalten, indem du die Anforderung simulierst:

1. Klicke auf die Schaltfläche Test ganz rechts

2. Simuliere die Anforderung

Funktion testen

Auch wenn oben keine Antwortheader angezeigt werden, kannst du sie durch die Simulation mit Postman/DHC oder einem anderen Dienst anzeigen lassen.


Option 2: Übergib die Client-ID im Antworttext mit dem Schlüssel „xAdobeSignClientId“

Im JSON-Antworttext, wobei der Schlüssel von xAdobeSignClientId und sein Wert dieselbe Client-ID sind, die im Anforderungsheader gesendet wurde.

Ersetze die Index.js-Datei durch Folgendes:

Inhalt der Datei „index.js“ aktualisieren

module.exports = function (context, req) {

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

    // Validiere, dass die eingehende ClientID echt ist

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

        context.res = {

            // Status: 200/* Standardwert ist 200 * // jede Antwort im Format 2XX ist akzeptabel

            

                'xAdobeSignClientId' : clientId

            },

            headers : {

                'Content-Type' : 'application/json'

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Ups!! Illegitimer Aufruf identifiziert"

        };

    }

    context.done();

};

 

Teste das Verhalten, indem du die Anforderung simulierst

1. Klicke auf die Schaltfläche Test ganz rechts

2. Simuliere die Anforderung

Funktion testen

Beachte auch, dass dasselbe Verhalten für clientID erwartet wird, wenn die Webhook-URL POST-Benachrichtigungen empfängt. 


Zur Verwendung bereit

Nachdem du das Verhalten überprüft hast, funktioniert die Webhook-URL gemäß den Acrobat Sign-Standards. Du kannst eine benutzerdefinierte Logik weiter an deine Anforderungen anpassen.

 

Erhalte die Funktions-URL

  • Klicke auf Funktions-URL abrufen
Funktions-URL abrufen

 

Kopiere die URL und verwende sie zum Erstellen von Webhooks in Acrobat Sign.

Funktions-URL kopieren

Erstellen der AWS Lambda-Funktion

Um eine AWS Lambda-Funktion zu erstellen, melde dich bei deiner AWS Management Console an und wähle den AWS Lambda-Dienst aus der Liste der Dienste aus.

  • Klicke auf die Option zum Erstellen einer Lambda-Funktion und dann auf Von Grund auf erstellen.
  • Gib auf der Seite „Funktion konfigurieren“ den Funktionsnamen „lambdaWebhooks“ ein und wähle Node.js 4,3 als Laufzeit aus
  • Wähle für die Rolle eine vorhandene Rolle aus oder erstelle eine neue Rolle aus den Vorlagen.
    • Wenn du Neue Rolle aus Vorlage(n) erstellen ausgewählt hast, gib einen Rollennamen ein (z. B. „role-lamda“) und wähle aus der Liste Richtlinienvorlagen die Option Einfache Mikroservices-Berechtigungen aus.
  • Klicke auf die Schaltfläche Funktion erstellen.
Funktion in AWS erstellen

  • Wähle auf der Seite mit der neuen AWS Lambda-Funktion unter Code-Eingabetyp die Option Code inline bearbeiten aus und behalte „index.handler“ als Handler bei.
  • Füge Logik hinzu, um den Acrobat Sign-Webhook zu registrieren.

    Bevor ein Webhook erfolgreich registriert wird, überprüft Acrobat Sign, ob die Webhook-URL, die in der Registrierungsanforderung angegeben ist, wirklich Benachrichtigungen erhalten möchte oder nicht. Wenn Acrobat Sign eine neue Webhook-Registrierungsanforderung empfängt, wird deshalb zunächst eine Überprüfungsanforderung an die Webhook-URL gestellt. Diese Überprüfungsanforderung ist eine HTTPS-GET-Anforderung, die mit einem benutzerdefinierten HTTP-Header X-AdobeSign-ClientId an die Webhook-URL gesendet wird. Der Wert in diesem Header ist auf die Client-ID der Anwendung festgelegt, die das Erstellen/Registrieren des Webhooks anfordert. Um einen Webhook erfolgreich zu registrieren, muss die Webhook-URL auf diese Überprüfungsanforderung mit einem 2XX-Antwortcode reagieren. ZUSÄTZLICH MUSS die Webhook-URL denselben Client-ID-Wert auf eine der beiden folgenden Weisen zurücksenden: Beachte auch, dass dasselbe Verhalten für clientID erwartet wird, wenn die Webhook-URL POST-Benachrichtigungen empfängt.

    Gehe wie in einem der beiden Fälle vor:

    Fall 1: Übergib die Client-ID in „X-AdobeSign-ClientId“ als Antwortheader

    •  Übergib X-AdobeSign-ClientId im Antwortheader. Dies ist der gleiche Titel, der in der Anforderung übergeben wurde, und muss in der Antwort zurückgegeben kopiert werden.

      Code-Snippet
      Ersetze in der index.js-Datei das automatisch generierte Code-Snippet durch folgenden Code:

Node.js-Beispielcode, um die Client-ID abzurufen, zu validieren und dann im Antwortheader zurückzugeben

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

  // Client-ID einholen

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

 

  //Validieren

  if (clientid ==„BGBQIIE7H253K6“) //Ersetze „BGBQIIE7H253K6“ durch die Client-ID der Anwendung, mit der der Webhook erstellt wird

  {

    var response = {

        statusCode: 200,

        headers: {

            "X-AdobeSign-ClientId": clientid

        }

     };

   callback(null,response);

  }

  else {

   callback("Oops!! illegitimate call");

  }

}

 

Fall 2: Übergib die Client-ID im Antworttext mit dem Schlüssel xAdobeSignClientId

Im JSON-Antworttext, wobei der Schlüssel vonxAdobeSignClientId und sein Wert dieselbe Client-ID sind, die im Anforderungsheader gesendet wurde.

 

Code Snippet

Ersetze die Index.js-Datei durch Folgendes:

Node.js-Beispielcode, um die Client-ID abzurufen, zu validieren und dann im Antwortheader zurückzugeben

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

 // Client-ID einholen

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

  

 //Validieren

 if (clientid ==„BGBQIIE7H253K6“) //Ersetze „BGBQIIE7H253K6“ durch die Client-ID der Anwendung, mit der der Webhook erstellt wird

 {

   var responseBody = {

        xAdobeSignClientId : clientid

   };

     

    var response = {

        statusCode: 200,

        body: JSON.stringify(responseBody)

    };

 

   callback(null,response);

 }

 else {

   callback("Opps!! illegitimate call");

  }

}

Inhalt der Datei „index.js“ aktualisieren

  • Speichere die Funktion. Die Lambda-Funktion wird erstellt und wir können sie nun bald in einem Echtzeit-Webhook verwenden.

 

Konfigurieren des AWS API Gateway

Um Lambda über eine HTTP-Methode öffentlich zugänglich zu machen, müssen wir das AWS API Gateway mit unserer (oben erstellten) Funktion als Backend für die API konfigurieren.

Wähle in der AWS Management Console das API Gateway aus den AWS-Diensten aus und klicke auf die Schaltfläche API erstellen.

API-Gateway konfigurieren

  • Wähle auf der Seite Neue API erstellen die Option Neue API aus und gib Webhooks als API-Name ein.
  • Klicke auf die Schaltfläche API erstellen.
  • Wähle die Dropdown-Liste Aktionen und dann die Option Ressource erstellen aus.
  • Aktiviere die OptionAls Proxyressource konfigurieren und gib validate als Ressourcenname und {proxy+} in den Ressourcenpfad ein.
  • Lasse die Option API Gateway CORS aktivieren deaktiviert und klicke auf die Schaltfläche Ressource erstellen.
  • Lasse die Option Lambda-Funktion-Proxy als Integrationstyp ausgewählt und wähle in der Dropdown-Liste Lambda-Region die Region aus, in der du die Lambda-Funktion erstellt hast (dies ist wahrscheinlich dieselbe Region, in der du das API Gateway erstellst).
  • Gib validate als Lambda-Funktion ein und klicke auf die Schaltfläche Speichern.
  • Klicke im Popup-Fenster Berechtigung zu Lambda-Funktion hinzufügen auf OK.

Wenn alle oben genannten Schritte erfolgreich ausgeführt werden, wird ungefähr der folgende Bildschirm angezeigt:

Konfigurierte Methode

Bereitstellen der API

Der nächste Schritt besteht darin, diese API so bereitzustellen, dass sie verwendet werden kann.

  • Wähle in der Dropdown-Liste Aktionen die Option API bereitstellen aus.
  • Wähle unter Bereitstellungsphase die Option [Neue Phase] aus und gib unter Phasenname Produktion oder einen beliebigen anderen Wert zur Identifizierung der betreffenden Phase ein.
  • Klicke auf die Schaltfläche Bereitstellen.

Die API ist jetzt einsatzbereit und du findest die Invoke-URL im blauen Feld, wie unten dargestellt:

API bereitstellen

Notiere dir diese URL, da du sie als URL für den Echtzeit-Webhook eingeben musst.

Zur Verwendung bereit

Fertig. Verwende diese URL oben mit dem Anhang „/{nodeJSfunctionName}“ als Webhook-URL in der POST /webhooks API-Anforderung.  Nachdem du das Verhalten überprüft hast, funktioniert die Webhook-URL gemäß den
Acrobat Sign-Standards. Du kannst die benutzerdefinierte Logik deinen Anforderungen entsprechend weiter aktualisieren/hinzufügen.

Aktivierung oder Deaktivierung

Der Zugriff auf die Webhooks-Funktion ist für Konten auf Unternehmensebene standardmäßig aktiviert.

Admins auf Gruppenebene können die Webhooks steuern/erstellen, die nur innerhalb ihrer jeweiligen Gruppen arbeiten.

Der Zugriff auf die Seite Webhooks ist in der linken Leiste des Admin-Menüs zu finden.

Zur Registerkarte „Webhooks“ navigieren

Bewährte Verfahren

  • Abonniere bestimmte, benötigte Ereignisse, um die Anzahl der HTTPS-Anforderungen an den Server zu begrenzen – Je genauer du deine Webhooks gestaltest, desto weniger Volumen musst du durchsuchen.
  • Vermeide Dopplungen – Wenn mehr als eine App mit derselben Webhook-URL vorhanden ist und die selben Nutzerdaten mit jeder der Apps verknüpft sind, wird dasselbe Ereignis mehrmals an deinen Webhook gesendet (einmal pro App). In einigen Fällen kann dein Webhook doppelte Ereignisse empfangen. Deine Webhook-Anwendung sollte darauf vorbereitet sein und Dopplungen nach Ereignis-ID filtern.
  • Reagiere immer schnell auf Webhooks – deine App hat nur fünf Sekunden Zeit, um auf Webhook-Anforderungen zu reagieren. Bei der Verifizierungsanforderung ist dies selten ein Problem, da deine App keine echte Arbeit leisten muss, um zu reagieren. Bei Benachrichtigungsanfragen tut deine App jedoch in der Regel etwas, das Zeit in Anspruch nimmt, um auf die Anfrage zu reagieren. Es wird empfohlen, an einem separaten Thread oder asynchron mit einer Warteschlange zu arbeiten, um sicherzustellen, dass du innerhalb von fünf Sekunden reagieren kannst.
  • Gleichzeitigkeit verwalten – Wenn ein Benutzer mehrere Änderungen in schneller Folge vornimmt, erhält deine App wahrscheinlich mehrere Benachrichtigungen für denselben Benutzer ungefähr zur gleichen Zeit. Wenn du Gleichzeitigkeit nicht sorgfältig verwaltest, verarbeitet deine App dieselben Änderungen für denselben Benutzer unter Umständen mehr als einmal. Um die Vorteile von Acrobat Sign-Webhooks zu nutzen, musst du eine klare Vorstellung davon haben, wie die Informationen verwendet werden sollen. Denke daran, Fragen wie die folgenden zu stellen:
    • Welche Daten sollen in der Nutzlast zurückgegeben werden? 
    • Wer wird auf diese Informationen zugreifen? 
    • Welche Entscheidungen oder Berichte werden generiert?
  • Empfehlungen für den Empfang eines signierten Dokuments: Bei der Entscheidung, wie eine signierte PDF-Datei von Acrobat Sign in deinem Dokumentenverwaltungssystem empfangen werden soll, sind mehrere Faktoren zu berücksichtigen.

Auch wenn es durchaus akzeptabel ist, bei der Erstellung eines Webhooks nur die Option Signiertes Vereinbarungsdokument auszuwählen, solltest du die Acrobat Sign-API verwenden, um Dokumente abzurufen, wenn ein auslösendes Ereignis (z. B. Vereinbarungsstatus „Abgeschlossen“) eingeht.

Zu berücksichtigende Punkte...

JSON-Größenbeschränkung

Die JSON-Payload-Größe ist auf 10 MB begrenzt.

Wenn ein Ereignis ein größeres Payload generiert, wird ein Webhook ausgelöst, aber wenn bedingte Parameterattribute in der Anforderung vorhanden sind, werden sie entfernt, um die Größe des Payloads zu reduzieren. 

„ConditionalParametersTrimmed“ wird in der Antwort zurückgegeben, wenn dies geschieht, um Kund*innen darüber zu informieren, dass die conditionalParameters-Informationen wurden entfernt.

ConditionalParametersTrimmed ist ein Array-Objekt, das die Informationen über die Keys enthält, die gelöscht wurden.

Die Kürzung wird in der folgenden Reihenfolge durchgeführt:

  • includeSignedDocuments
  • includeParticipantsInfo
  • includeDocumentsInfo
  • includeDetailedInfo

Signierte Dokumente werden zuerst abgeschnitten, gefolgt von Teilnehmerdaten., Dokumentinformationen und schließlich ausführliche Information.

Das kann beispielsweise einem Vereinbarungsfertigstellungsereignis, wenn es signiertes Dokument (Base 64 -kodiert) oder für eine Vereinbarung mit mehreren Formularfeldern enthält

Webhook-Benachrichtigungen

Acrobat Sign-Webhooks senden Benachrichtigungen an die sendende Partei der Vereinbarung sowie an alle Webhooks, die innerhalb der Gruppe konfiguriert sind, von der die Vereinbarung gesendet wurde. Im Konto angelegte Webhooks empfangen alle Ereignisse.

Sendende Partei: nutzende Partei A | Signierende Partei: nutzende Partei B | Freigabekontakt: nutzende Partei C

Nutzende Partei A und nutzende Partei B befinden sich in verschiedenen Konten

Nutzende Partei A und nutzende Partei C befinden sich in verschiedenen Konten

Anwendungsfall

Benachrichtigung?

Kommentare/Hinweise

Das Konto der nutzenden Partei A verfügt über einen Webhook auf KONTO-Ebene (erstellt von der nutzenden Partei A oder der Kontoadministration).

Ja

Ein Webhook auf KONTO-Ebene wird über alle Ereignisse benachrichtigt, die in diesem Konto ausgelöst werden.

Das Konto der nutzenden Partei A verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei A oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei A und die Gruppenadministration befinden sich in derselben Gruppe.

Ja

Ein Webhook auf GRUPPEN-Ebene wird über alle Ereignisse benachrichtigt, die in dieser Gruppe ausgelöst werden.

Die nutzende Partei A verfügt über einen Webhook auf BENUTZENDEN-Ebene.

Ja

Als sendende Partei wird der Webhook der nutzenden Partei A auf BENUTZENDEN-Ebene ausgelöst

Die nutzende Partei A hat einen Webhook auf RESSOURCEN-Ebene (für die oben genannte gesendete Vereinbarung).

Ja

 
     

Das Konto der nutzenden Partei B verfügt über einen Webhook auf KONTO-Ebene (erstellt von der nutzenden Partei B oder der Kontoadministration).

Nein

Der Webhook auf KONTO-Ebene der nutzenden Partei B ist ein Webhook für Unterzeichnende.

Das Konto der nutzenden Partei B verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei B oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei B und die Gruppenadministration befinden sich in derselben Gruppe.

Nein

Der Webhook auf GRUPPEN-Ebene der nutzenden Partei B ist ein Webhook für Unterzeichnende.

Die nutzende Partei B verfügt über einen Webhook auf BENUTZENDEN-Ebene.

Nein

Der Webhook auf BENUTZENDEN-Ebene der nutzenden Partei B ist ein Webhook für Unterzeichnende.

     

Das Konto der nutzenden Partei C verfügt über einen Webhook auf KONTO-Ebene (erstellt von der nutzenden Partei C oder der Kontoadministration).

Nein

Der Webhook auf KONTO-Ebene der nutzenden Partei C wird als Webhook ohne Ursprungseigenschaft betrachtet.

Das Konto der nutzenden Partei C verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei C oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei C und die Gruppenadministration befinden sich in derselben Gruppe.

Nein

Der Webhook auf GRUPPEN-Ebene der nutzenden Partei C wird als Webhook ohne Ursprungseigenschaft betrachtet.

Die nutzende Partei C verfügt über einen Webhook auf BENUTZENDEN-Ebene.

Nein

Der Webhook auf BENUTZENDEN-Ebene der nutzenden Partei C wird als Webhook ohne Ursprungseigenschaft betrachtet.

Sendende Partei: nutzende Partei A | Signierende Partei: nutzende Partei B | Freigabekontakt: nutzende Partei C

Die nutzende Partei A, die nutzende Partei B und die nutzende Partei C befinden sich in demselben Konto

Anwendungsfall

Benachrichtigung?

Hinweise

Das Konto der nutzenden Partei A verfügt über einen Webhook auf KONTO-Ebene (erstellt von der nutzenden Partei A oder der Kontoadministration).

Ja

Webhooks auf KONTO-Ebene benachrichtigen über Ereignisse, die vom Konto ausgelöst wurden.

Das Konto der nutzenden Partei A verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei A oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei A und die Gruppenadministration befinden sich in derselben Gruppe.

Ja

Webhooks auf GRUPPEN-Ebene benachrichtigen über Ereignisse, die von den Benutzenden in deren Gruppe ausgelöst wurden.

Die nutzende Partei A verfügt über einen Webhook auf BENUTZENDEN-Ebene.

Ja

Der Webhook der nutzenden Partei A als sendenden Partei wird auf BENUTZENDEN-Ebene ausgelöst

Die nutzende Partei A hat einen Webhook auf RESSOURCEN-Ebene (für die oben genannte gesendete Vereinbarung).

Ja

 
     

Das Konto der nutzenden Partei B verfügt über einen Webhook auf KONTO-Ebene (erstellt von der nutzenden Partei B oder der Kontoadministration).

Ja

Da die nutzende Partei A und die nutzende Partei B sich in demselben Konto befinden, wird ein Webhook auf KONTO-Ebene über alle Ereignisse benachrichtigt, die in diesem Konto ausgelöst werden.

Das Konto der nutzenden Partei B verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei B oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei A, die nutzende Partei B und die Gruppenadministration befinden sich in derselben Gruppe.

Ja

Da die nutzende Partei A und die nutzende Partei B sich in demselben Konto befinden, wird ein Webhook auf GRUPPEN-Ebene über alle Ereignisse benachrichtigt, die in dieser Gruppe ausgelöst werden.

Das Konto der nutzenden Partei B verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei B oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei A und die nutzende Partei B befinden sich in unterschiedlichen Gruppen.

Nein

Der Webhook auf GRUPPEN-Ebene der nutzenden Partei B ist ein Webhook für Unterzeichnende.

Der Webhook der nutzenden Partei A (RESSOURCE/NUTZENDE PARTEI/GRUPPE/KONTO) wird ausgelöst.

Die nutzende Partei B verfügt über einen Webhook auf BENUTZENDEN-Ebene.

Nein

Der Webhook der nutzenden Partei B als empfangenden Partei wird auf BENUTZENDEN-Ebene ausgelöst.

     

Das Konto der nutzenden Partei C verfügt über einen Webhook auf KONTO-Ebene (erstellt von der nutzenden Partei C oder der Kontoadministration).

Ja

Da die nutzende Partei A und die nutzende Partei C sich in demselben Konto befinden, wird ein Webhook auf KONTO-Ebene über alle Ereignisse benachrichtigt, die in diesem Konto ausgelöst werden.

Das Konto der nutzenden Partei C verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei C oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei A, die nutzende Partei C und die Gruppenadministration befinden sich in derselben Gruppe.

Ja

Da die nutzende Partei A und die nutzende Partei C sich in demselben Konto befinden, wird ein Webhook auf GRUPPEN-Ebene über alle Ereignisse benachrichtigt, die in dieser Gruppe ausgelöst werden.

Das Konto der nutzenden Partei C verfügt über einen Webhook auf GRUPPEN-Ebene (erstellt von der nutzenden Partei C oder der Konto-/Gruppenadministration).

Annahme: Die nutzende Partei A und die nutzende Partei C befinden sich in unterschiedlichen Gruppen.

Nein

Der Webhook auf GRUPPEN-Ebene der nutzenden Partei C wird als Webhook ohne Ursprungseigenschaft betrachtet.

Der Webhook der nutzenden Partei A (RESSOURCE/NUTZENDE PARTEI/GRUPPE/KONTO) wird ausgelöst.

Die nutzende Partei C verfügt über einen Webhook auf BENUTZENDEN-Ebene.

Nein

Der Webhook auf Benutzendenebene der nutzenden Partei C wird als Webhook ohne Ursprungseigenschaft betrachtet.

Wiederholung des Vorgangs, wenn der Listening-Service heruntergefahren ist

Wenn die Ziel-URL für den Webhook aus irgendeinem Grund nicht funktioniert, fügt Acrobat Sign die JSON-Datei einer Warteschlange hinzu und wiederholt die Übertragung in einem progressiven Zyklus von 72 Stunden.

Nicht zugestellte Ereignisbenachrichtigungen werden in einer Wiederholungswarteschlange gespeichert. Innerhalb der folgenden 72 Stunden wird nach besten Kräften versucht, die Benachrichtigungen in der Reihenfolge zu senden, in der die Ereignisse aufgetreten sind.

Die Strategie beim erneuten Zustellen von Benachrichtigungen ist eine Verdoppelung der Zeit zwischen Versuchen. Es wird mit einem Intervall von einer Minute begonnen bis zu einem Intervall von zwölf Stunden. Daraus ergeben sich 15 Versuche innerhalb von 72 Stunden.

Wenn der Webhook-Empfänger nicht innerhalb von 72 Stunden antwortet und in den letzten sieben Tagen keine erfolgreichen Benachrichtigungszustellungen erfolgt sind, wird der Webhook deaktiviert. Es werden erst Benachrichtigungen zu dieser URL ausgelöst, sobald der Webhook wieder aktiviert wird.

Alle Benachrichtigungen zwischen der Deaktivierung des Webhooks und der anschließenden erneuten Aktivierung gehen verloren.

 Adobe

Schneller und einfacher Hilfe erhalten

Neuer Benutzer?