Beispiel-Javascript-Code zum Abrufen der Client-id, Validierung und Rückgabe im Antwortheader
Neue Funktionen
Erste Schritte
- Kurzanleitung für Administrierende
- Kurzanleitung für Benutzende
- Für Entwicklerinnen und Entwickler
- Video-Tutorial-Bibliothek
- Häufig gestellte Fragen
Verwaltung
- Übersicht über die Admin Console
- Benutzendenverwaltung
- Benutzer hinzufügen
- Erstellen von funktionsorientierten Benutzenden
- Suche nach Nutzenden mit Bereitstellungsfehlern
- Ändern des Namens/der E-Mail-Adresse
- Gruppenmitgliedschaft von Benutzenden bearbeiten
- Bearbeiten der Gruppenmitgliedschaft von Benutzenden über die Gruppenoberfläche
- Hochstufen von Benutzenden zu einer Administrationsrolle
- Benutzeridentitätstypen und SSO
- Wechseln der Benutzeridentität
- Authentifizieren von Benutzenden mit MS Azure
- Authentifizieren von Benutzenden mit Google Federation
- Produktprofile
- Anmeldung
- Konto-/Gruppeneinstellungen
- Einstellungsübersicht
- Globale Einstellungen
- Kontoebene und ID
- Neues Empfangserlebnis
- Workflows zum Selbstsignieren
- Massenversand
- Webformulare
- Benutzerdefinierte Sende-Workflows
- Power Automate-Workflows
- Bibliotheksdokumente
- Formulardaten mit Vereinbarungen erfassen
- Eingeschränkte Dokumentsichtbarkeit
- Anhängen einer PDF-Kopie der signierten Vereinbarung
- Einfügen eines Links in eine E-Mail
- Einfügen eines Bilds in eine E-Mail
- An E-Mails angehängte Dateien werden folgendermaßen benannt:
- Anhängen von Audit-Berichten an Dokumente
- Zusammenführen mehrerer Dokumente zu einem Dokument
- Einzelne Dokumente herunterladen
- Signiertes Dokument hochladen
- Delegation für Benutzende in meinem Konto
- Externen Empfangenden das Delegieren erlauben
- Signaturberechtigung
- Sendeberechtigung
- Berechtigung zum Hinzufügen elektronischer Siegel
- Festlegen einer Standardzeitzone
- Festlegen eines Standarddatumsformats
- Benutzende in mehreren Gruppen (UMG)
- Berechtigungen für Gruppenadministrierende
- Empfangende ersetzen
- Audit-Bericht
- Transaktionsfußzeile
- In Produktbotschaften und Anleitungen
- Barrierefreie PDF-Dateien
- Neues Authoring-Erlebnis
- Kundinnen und Kunden im Gesundheitswesen
- Kontoeinrichtung
- Signaturvorgaben
- Korrekt formatierte Signaturen
- Empfangenden das Signieren erlauben durch
- Unterzeichnende können ihren Namen ändern
- Empfangenden erlauben, ihre gespeicherte Signatur zu verwenden
- Selbstdefinierte Nutzungsbedingungen und Hinweis für Kundinnen und Kunden
- Empfangende durch Formularfelder leiten
- Vereinbarungs-Workflow neu starten
- Signieren ablehnen
- Stempel-Workflows erlauben
- Unterzeichnende auffordern, ihre Stellenbezeichnung oder ihr Unternehmen anzugeben
- Unterzeichnenden das Drucken und Einfügen von handschriftlichen Signaturen erlauben
- Anzeigen von Nachrichten beim elektronischen Signieren
- Unterzeichnende müssen ein Mobilgerät verwenden, um ihre Signatur zu erstellen
- IP-Adresse von Unterzeichnenden anfordern
- Firmenname und Stellenbezeichnung sollen nicht aus dem Teilnahmestempel ersichtlich sein
- Digitale Signaturen
- Elektronische Siegel
- Digital Identity
- Berichteinstellungen
- Neues Berichtserlebnis
- Einstellungen für den klassischen Bericht
- Sicherheitseinstellungen
- Einstellungen für Single Sign-on
- Einstellungen zum Merken der Anmeldedaten
- Richtlinien für Anmeldekennwort
- Stärke für Anmeldekennwort
- Dauer der Internet-Sitzung
- Art der PDF-Verschlüsselung
- API
- Zugriff auf Benutzenden- und Gruppeninformationen
- Erlaubte IP-Bereiche
- Kontofreigabe
- Berechtigungen zur Kontofreigabe
- Steuerelemente für das Freigeben von Vereinbarungen
- Bestätigung der Unterzeichnendenidentität
- Kennwort für das Signieren einer Vereinbarung
- Dokumentkennwortstärke
- Unterzeichnende anhand des geografischen Standorts sperren
- Telefonauthentifizierung
- Wissensbasierte Authentifizierung (KBA)
- Zulassen der Seitenextraktion
- Ablauf des Dokumentlinks
- Hochladen eines Clientzertifikats für Webhooks/Rückrufe
- Zeitstempel
- Sendeeinstellungen
- Anzeigen der Seite „Senden“ nach der Anmeldung
- Name der Empfangspartei beim Senden erforderlich
- Sperren der Namenswerte für bekannte Benutzende
- Zulässige Empfangsrollen
- E-Witnesses zulassen
- Gruppen empfangender Personen
- CC-Parteien
- Vereinbarungszugriff der Empfangenden
- Erforderliche Felder
- Anhängen von Dokumenten
- Feldreduzierung
- Vereinbarungen bearbeiten
- Vereinbarungsname
- Sprachen
- Private Nachrichten
- Erlaubte Signaturarten
- Erinnerungen
- Kennwortschutz für signierte Dokumente
- Vereinbarungsbenachrichtigung absenden
- Identifikationsoptionen für Unterzeichnende
- Inhaltsschutz
- Aktivieren von Beglaubigungs-Transaktionen
- Dokumentablauf
- Anzeigen der Vorschau, Positionieren von Signaturen und Hinzufügen von Formularfeldern
- Signierreihenfolge
- Liquid Mode
- Optionen für selbstdefinierte Workflows
- Upload-Optionen auf der E-Sign-Seite
- Bestätigungs-URL-Umleitung nach der Signatur
- Nachrichtenvorlagen
- Bio-Pharma-Einstellungen
- Workflow-Integration
- Beglaubigungs-Einstellungen
- Zahlungsintegration
- Nachrichten für Unterzeichnende
- SAML-Einstellungen
- SAML-Konfiguration
- Installieren des Active Directory Federation Service
- Installieren von Okta
- Installieren von OneLogin
- Installieren von Oracle Identity Federation
- SAML-Konfiguration
- Datennutzungsrechte
- Zeitstempel-Einstellungen
- Externes Archiv
- Kontosprachen
- E-Mail-Einstellungen
- Migration von echosign.com zu adobesign.com
- Konfigurieren von Optionen für Empfangende
- Leitfaden für regulatorische Anforderungen
- Barrierefreiheit
- HIPAA
- DSGVO
- 21 CFR Part 11 und EudraLex Annex 11
- Kundinnen und Kunden im Gesundheitswesen
- IVES-Unterstützung
- Archivieren von Vereinbarungen
- Überlegungen zur EU/dem Vereinigten Königreich
- Gleichzeitiges Herunterladen von mehreren Vereinbarungen
- Anfordern deiner Domäne
- Links „Missbrauch melden“
Senden, Signieren und Verwalten von Vereinbarungen
- Empfangsoptionen
- Stornieren von E-Mail-Erinnerungen
- Optionen auf der E-Signatur-Seite
- Überblick über die E-Signatur-Seite
- Öffnen der Vereinbarung, um sie ohne Felder zu lesen
- Signieren einer Vereinbarung ablehnen
- Delegieren der Signaturberechtigung
- Neustarten der Vereinbarung
- Herunterladen einer PDF-Datei der Vereinbarung
- Anzeigen des Vereinbarungsverlaufs
- Anzeigen der Vereinbarungsnachrichten
- Umwandlung von elektronischer zu handschriftlicher Signatur
- Umwandlung von handschriftlicher zu elektronischer Signatur
- Navigation der Formularfelder
- Löschen der Daten aus den Formularfeldern
- Seitenvergrößerung und Navigation der E-Signatur-Seite
- Ändern der in den Vereinbarungswerkzeugen und -informationen verwendeten Sprache
- Rechtliche Hinweise lesen
- Anpassen der Acrobat Sign-Cookie-Voreinstellungen
- Vereinbarungen senden
- Erstellen von Feldern in Dokumenten
- In-App-Authoring-Umgebung
- Automatische Felderkennung
- Ziehen und Ablegen von Feldern in der Authoring-Umgebung
- Formularfelder zu Empfangenden zuweisen
- Die Rolle „Vorausfüllen“
- Anwenden von Feldern mit einer wiederverwendbaren Feldvorlage
- Felder in eine neue Bibliotheksvorlage übertragen
- Aktualisierte Authoring-Umgebung beim Senden von Vereinbarungen
- Erstellen von Formularen mit Text-Tags
- Erstellen von Formularen mit Acrobat (AcroForms)
- Felder
- Authoring-FAQ
- In-App-Authoring-Umgebung
- Signieren von Vereinbarungen
- Vereinbarungen verwalten
- Übersicht über die Seite „Verwalten“
- Delegieren von Vereinbarungen
- Ersetzen von Empfangenden
- Eingeschränkte Dokumentsichtbarkeit
- Abbrechen einer Vereinbarung
- Erstellen von neuen Erinnerungen
- Überprüfen von Erinnerungen
- Stornieren von Erinnerungen
- Zugriff auf Power Automate-Flows
- Weitere Aktionen...
- Funktionsweise der Suche
- Anzeigen einer Vereinbarung
- Vorlage aus einer Vereinbarung erstellen
- Aus-/Einblenden von Vereinbarungen
- Hochladen einer signierten Vereinbarung
- Ändern von Dateien und Feldern einer gesendeten Vereinbarung
- Bearbeiten der Authentifizierungsmethode einer Empfangspartei
- Hinzufügen oder Ändern eines Ablaufdatums
- Hinzufügen einer Notiz zu einer Vereinbarung
- Freigabe einer einzelnen Vereinbarung
- Aufheben der Freigabe einer Vereinbarung
- Herunterladen einer einzelnen Vereinbarung
- Herunterladen einzelner Dateien einer Vereinbarung
- Herunterladen des Audit-Berichts einer Vereinbarung
- Herunterladen des Feldinhalts einer Vereinbarung
- Audit-Bericht
- Berichte und Datenexporte
- Überblick
- Zugriffserteilung auf Berichte für Benutzende
- Berichtsdiagramme
- Datenexporte
- Umbenennen eines Berichts/Exports
- Duplizieren eines Berichts/Exports
- Planen eines Berichts/Exports
- Löschen eines Berichts/Exports
- Überprüfen des Transaktionsverbrauchs
Erweiterte Vereinbarungsfunktionen und Workflows
- Webformulare
- Erstellen eines Webformulars
- Bearbeiten eines Webformulars
- Deaktivieren/Aktivieren eines Webformulars
- Ein-/Ausblenden eines Webformulars
- Abrufen der URL oder des Skriptcodes
- Vorausfüllen von Webformularfeldern mithilfe von URL-Parametern
- Speichern eines Webformulars, um es später auszufüllen
- Ändern der Größe eines Webformulars
- Wiederverwendbare Vorlagen (Bibliotheksvorlagen)
- US-Behördenformulare in der Acrobat Sign-Bibliothek
- Erstellen einer Bibliotheksvorlage
- Ändern des Namens einer Bibliotheksvorlage
- Ändern des Typs einer Bibliotheksvorlage
- Ändern der Berechtigungsebene einer Bibliotheksvorlage
- Kopieren, Bearbeiten und Speichern einer freigegebenen Vorlage
- Herunterladen der aggregierten Felddaten für eine Bibliotheksvorlage
- Übertragen des Eigentums an Webformularen und Bibliotheksvorlagen
- Power Automate-Workflows
- Überblick über die Power Automate-Integration und die enthaltenen Berechtigungen
- Aktivieren der Power Automate-Integration
- Kontextbasierte Aktionen auf der Seite „Verwalten“
- Verfolgen der Nutzung von Power Automate
- Erstellen eines neuen Flows (Beispiele)
- Auslöser für Flows
- Importieren von Flows von außerhalb von Acrobat Sign
- Verwalten von Flows
- Bearbeiten von Flows
- Freigeben von Flows
- Deaktivieren oder Aktivieren von Flows
- Löschen von Flows
- Nützliche Vorlagen
- Nur Administration
- Archivierung von Vereinbarungen
- Archivierung von Webformularvereinbarungen
- Speichern abgeschlossener Webformulardokumente in der SharePoint-Bibliothek
- Speichern abgeschlossener Dokumente in OneDrive for Business
- Speichern abgeschlossener Dokumente in Google Drive
- Speichern abgeschlossener Webformulardokumente in Box
- Extraktion von Vereinbarungsdaten
- Vereinbarungsbenachrichtigungen
- Senden selbstdefinierter E-Mail-Benachrichtigungen mit dem Vereinbarungsinhalt und der signierten Vereinbarung
- Abrufen von Adobe Acrobat Sign-Benachrichtigungen in einem Teams-Kanal
- Abrufen von Adobe Acrobat Sign-Benachrichtigungen in Slack
- Abrufen von Adobe Acrobat Sign-Benachrichtigungen in Webex
- Vereinbarungsgenerierung
- Erstellen eines Dokuments aus einem Power Apps-Formular und einer Word-Vorlage sowie Senden zum Signieren
- Generieren einer Vereinbarung aus einer Word-Vorlage in OneDrive und Einholen der Signatur
- Generieren einer Vereinbarung für ausgewählte Excel-Zeile und Senden zur Überprüfung und Signatur
- Selbstdefinierte Sende-Workflows
- Freigeben von Benutzenden und Vereinbarungen
Integration in andere Produkte
- Übersicht über Acrobat Sign-Integrationen
- Acrobat Sign für Salesforce
- Acrobat Sign für Microsoft
- Weitere Integrationen
- Von Partnern verwaltete Integrationen
- Erstellen eines Integrationsschlüssels
Acrobat Sign-Entwickler
- REST-APIs
- Webhooks
Support und Fehlerbehebung
Überblick
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.
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
|
---|
// 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:
- Ein Microsoft-Konto mit Lizenz zum Erstellen von Azure Functions Applications haben
- Eine 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
- 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.
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.
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:
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
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:
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
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
Kopiere die URL und verwende sie zum Erstellen von Webhooks in Acrobat Sign.
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.
- 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:
- Ü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.
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 von xAdobeSignClientId 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"); } } |
- 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.
- 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:
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:
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.
Ratenbegrenzung für gleichzeitig ausgeführte Anforderungen
Benachrichtigungsereignisse sowie die Erstellung von Webhooks (und Callbacks) sind auf die Anzahl der gleichzeitigen Benachrichtigungen begrenzt, die vom Acrobat Sign-System aktiv an die Kundschaft gesendet werden. Dieses Limit gilt für das Konto, sodass alle Gruppen innerhalb des Kontos eingeschlossen sind.
Durch diese Art der Ratenbegrenzung wird verhindert, dass ein schlecht konzipiertes Konto eine unverhältnismäßige Menge an Serverressourcen verbraucht, was sich negativ auf alle anderen Kundinnen und Kunden in dieser Serverumgebung auswirkt.
Die Anzahl der gleichzeitigen Ereignisse pro Konto wurde berechnet, um zu gewährleisten, dass Konten mit korrekt konfigurierten Webhooks ihre Benachrichtigungen in kürzester Zeit erhalten. Dadurch sollte nur in seltenen Fällen eine Situation eintreten, bei der Benachrichtigungen aufgrund zu vieler Anfragen verzögert werden. Die aktuellen Schwellenwerte lauten:
Aktion |
Höchstzahl |
Beschreibung |
Webhook-Erstellung |
10 |
Pro Konto sind maximal 10 gleichzeitige Anforderungen zur Webhook-Erstellung zulässig. |
Webhook-/Callback-Benachrichtigung |
30 |
Pro Konto sind maximal 30 gleichzeitige Webhook- und Callback-Benachrichtigungen zulässig. |
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 dieselben 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 Kundinnen und Kunden darüber zu informieren, dass die conditionalParameters-Informationen entfernt wurden.
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
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.