Handboek Annuleren

Webhooks configureren

  1. Adobe Acrobat Sign-integraties
  2. Nieuwe functies
  3. Productversies en levenscyclus
  4. Acrobat Sign voor Salesforce
    1. Het pakket installeren
    2. Het pakket configureren
    3. Handboek
    4. Digitale verificatie inschakelen
    5. Handleiding voor ontwikkelaars
    6. Geavanceerde aanpassingshandleiding
    7. Veldtoewijzing en sjablonenhandleiding
    8. Gebruikershandleiding voor gebruikers van mobiele apps
    9. Handleiding voor flowautomatisering
    10. Handleiding voor Document Builder
    11. Grote documenten configureren
    12. Upgradehandleiding
    13. Aanvullende informatie
    14. Veelgestelde vragen
    15. Handleiding voor het oplossen van problemen
    16. Aanvullende artikelen
  5. Acrobat Sign voor Microsoft
    1. Acrobat Sign voor Microsoft 365
      1. Installatiehandleiding
    2. Acrobat Sign voor Outlook
      1. Handboek
    3. Acrobat Sign voor Word/PowerPoint
      1. Handboek
    4. Acrobat Sign voor teams
      1. Handboek
      2. Handboek voor Live Sign
      3. Gebruikershandleiding voor mobiele apparaten
      4. Aanvullende informatie
      5. Microsoft Teams-goedkeuringen
    5. Acrobat Sign voor Microsoft PowerApps en Power Automate
      1. Handboek
      2. Aanvullende informatie
    6. Acrobat Sign Connector voor Microsoft Search
      1. Handboek
      2. Aanvullende informatie
    7. Acrobat Sign voor Microsoft Dynamics 
      1. Overzicht
      2. Dynamics Online: Installatiehandleiding 
      3. Dynamics Online: Handboek 
      4. Dynamics On-Prem: Installatiehandleiding 
      5. Dynamics On-Prem: Handboek
      6. Dynamics Workflowhandleiding
      7. Dynamics 365 voor Talent
      8. Upgradehandleiding
      9. Aanvullende informatie
    8. Acrobat Sign voor Microsoft SharePoint 
      1. Overzicht
      2. SharePoint On-Prem: Installatiehandleiding
      3. SharePoint On-Prem: Handleiding voor het toewijzen van sjablonen
      4. SharePoint On-Prem: Handboek
      5. SharePoint On-Prem: Aanvullende informatie
      6. SharePoint Online Installatiehandleiding
      7. SharePoint Online: Handleiding voor het toewijzen van sjablonen
      8. SharePoint Online: Handboek
      9. SharePoint Online: Handleiding voor het toewijzen van webformulieren
      10. SharePoint Online: Aanvullende informatie
  6. Acrobat Sign voor ServiceNow
    1. Overzicht
    2. Installatiehandleiding
    3. Handboek
    4. Aanvullende informatie
  7. Acrobat Sign voor HR ServiceNow
    1. Installatiegids (verouderd)
  8. Acrobat Sign voor SAP SuccessFactors
    1. Installatiegids voor Cockpit (verouderd)
    2. Installatiegids voor rekrutering (verouderd)
    3. Handboek voor rekrutering
    4. Installatiehandleiding voor Cloud Foundry
    5. Aanvullende informatie
  9. Acrobat Sign voor Workday
    1. Installatiehandleiding
    2. Handleiding om snel aan de slag te gaan
    3. Tutorial voor configuratie
  10. Acrobat Sign voor NetSuite
    1. Installatiehandleiding
    2. Aanvullende informatie
  11. Acrobat Sign voor SugarCRM
  12. Acrobat Sign voor VeevaVault
    1. Installatiehandleiding
    2. Handboek
    3. Upgradehandleiding
    4. Aanvullende informatie
  13. Acrobat Sign voor Coupa BSM Suite
    1. Installatiehandleiding
  14. Acrobat Sign voor Zapier
    1. Overzicht van Acrobat Sign voor Zapier
    2. Ondersteunde workflows voor elektronische ondertekening
    3. Ondersteunde acties
    4. Geautomatiseerde workflows voor elektronische ondertekening maken
  15. Documentatie voor Acrobat Sign Developer
    1. Overzicht
    2. Webhooks
    3. Tekstlabels

Overzicht

Een webhook is een door de gebruiker gedefinieerd HTTPS-verzoek dat wordt geactiveerd wanneer een subscribed gebeurtenis plaatsvindt op de bronsite (in dit geval Adobe Acrobat Sign).

Een webhook is dus gewoon een REST-service die gegevens of een gegevensstroom accepteert.

Webhooks zijn bedoeld voor service-tot-service communicatie in een PUSH-model.

Wanneer zich een subscribed gebeurtenis voordoet, construeert Acrobat Sign een HTTPS-POST met een JSON-hoofdtekst en levert deze aan de opgegeven URL.

 

Webhooks bieden meerdere voordelen ten opzichte van de vorige callbackmethode, bijvoorbeeld:

  • Beheerders kunnen hun eigen webhooks inschakelen zonder Acrobat Sign-ondersteuning voor het weergeven van de callback-URL
  • Webhooks zijn beter betreffende "versheid" van gegevens, de efficiëntie van communicatie en beveiliging. Geen polling vereist
  • Met webhooks wordt het gebruik van verschillende bereiken eenvoudiger (Account/Groep/Gebruiker/Bron). 
  • Webhooks bieden een modernere API-oplossing, waardoor moderne applicaties eenvoudiger kunnen worden geconfigureerd
  • U kunt meerdere webhooks per bereik configureren (Account/Groep/Gebruiker/Bron), terwijl callbacks uniek moesten zijn
  • Bij webhooks kunt u specifiek aangeven welke gegevens worden geretourneerd. Bij callbacks is dit een "alles of niets"-optie
  • De metagegevens die zijn opgenomen in een webhook, kunnen worden geconfigureerd (standaard of gedetailleerd)
  • Webhooks kunnen veel eenvoudiger worden gemaakt, bewerkt of, indien nodig, uitgeschakeld, omdat de gebruikersinterface volledig binnen de controle van de beheerder valt.
Opmerking:

Dit document is voornamelijk gericht op de webhooks-UI in de Acrobat Sign-internettoepassing (voorheen Adobe Sign).

Ontwikkelaars die meer willen weten over API kunnen hier de gewenste informatie vinden:

Het gebruik

Beheerders moeten eerst een webhookservice hebben waarmee binnenkomende pushmeldingen van Acrobat Sign worden geaccepteerd. Er zijn in dit opzicht veel opties en zolang de service POST- en GET-verzoeken kan accepteren, zal de webhook succesvol zijn.

Zodra de service is ingesteld, kan een Acrobat Sign-beheerder een nieuwe webhook maken via de Webhook-interface in het menu Account van de Acrobat Sign-site.

Beheerders kunnen de webhook zodanig configureren dat deze wordt geactiveerd voor Overeenkomst-, Webformulier (Widget)- of 'In bulk verzenden' (MegaSign)-gebeurtenissen. Bibliotheeksjabloonbron (Bibliotheekdocument) kan ook worden geconfigureerd via de API.

Het bereik van de webhook kan een heel account of afzonderlijke groepen omvatten. Dit gebeurt via de beheerinterface. De API maakt meer granulariteit mogelijk door de selectie van de bereiken GEBRUIKER of BRON.

Het type gegevens dat naar de URL wordt gepusht, is configureerbaar en kan zaken omvatten zoals informatie over de overeenkomst, de deelnemer, het document, enzovoort.

Zodra de webhook is geconfigureerd en opgeslagen, pusht Acrobat Sign een nieuw JSON-object naar de gedefinieerde URL telkens wanneer de subscribed gebeurtenis wordt geactiveerd. U hoeft de webhook niet voortdurend te bewerken of te controleren, tenzij u de criteria voor triggergebeurtenissen of de JSON-payload wilt wijzigen.

Verificatie van de bedoeling van de webhook -URL

Voordat een webhook succesvol wordt geregistreerd, verifieert Acrobat Sign of de webhook-URL die in het registratieverzoek is opgegeven, bedoeld is om meldingen te ontvangen of niet. Daarom dient Acrobat Sign, wanneer het een nieuw webhook-registratieverzoek ontvangt, eerst een verificatieverzoek in bij de webhook-URL. Dit verificatieverzoek is een HTTPS GET-aanvraag die naar de webhook-URL is verzonden. Deze aanvraag heeft een aangepaste HTTP-header X-AdobeSign-ClientId. De waarde in deze header is ingesteld op de client-ID (applicatie-ID) van de API-applicatie die de aanvraag voor het maken/registreren van de webhook indient. Voordat een webhook succesvol kan worden geregistreerd, moet de webhook-URL aan dit verificatieverzoek voldoen met een 2XX-antwoordcode EN daarnaast MOET dezelfde client-ID-waarde worden teruggestuurd op een van de volgende twee manieren:

  • In een X-AdobeSign-ClientId-responsheader. Dit is dezelfde koptekst die is doorgegeven in de oorspronkelijke aanvraag en die in de respons moet worden 'teruggekaatst'.
  • In de JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde die gelijk is aan de client-ID die in de koptekst van de aanvraag is verzonden.

De webhook wordt alleen geregistreerd bij een succesvolle respons (2XX-responscode) en validatie van de client-ID in de kop- of hoofdtekst van de respons.Het doel van dit verificatieverzoek is om aan te tonen dat uw webhook-URL ook daadwerkelijk meldingen wil ontvangen op de desbetreffende URL. Als u per ongeluk een verkeerde URL hebt ingevoerd, reageert de URL niet correct op de verificatieaanvraag en stuurt Acrobat Sign geen meldingen meer naar die URL. Daarnaast kan de webhook-URL ook valideren dat de URL alleen meldingen ontvangt via de webhooks die zijn geregistreerd bij een specifieke applicatie. Hiervoor moet u de client-ID van de toepassing valideren die wordt doorgegeven in de X-AdobeSign-ClientId-header. Als deze client-ID niet wordt herkend door de webhook-URL, moet deze NIET reageren met de antwoordcode voor succes. Acrobat Sign zal er in dat geval voor zorgen dat de URL niet als webhook wordt geregistreerd.

Verificatie van de webhook-URL-aanroep wordt in de volgende gevallen uitgevoerd:

  • Bij registratie van de webhook: als de verificatie van de webhook-URL-aanroep mislukt, wordt de webhook niet gemaakt.
  • Bij het bijwerken van de webhook van NIET-ACTIEF naar ACTIEF: als de verificatie van de webhook-URL-aanroep mislukt, wordt de status van de webhook niet gewijzigd naar ACTIEF.

Reageren op een webhookmelding

Acrobat Sign voert een impliciete verificatie van de intentie uit in elk webhookmeldingsverzoek dat naar de webhook-URL wordt verzonden. Zo bevat elk webhookmeldings-HTTPS-verzoek ook de aangepaste HTTP header genaamd X-AdobeSign-ClientId. De waarde van deze header is de client-ID (Application ID) van de toepassing waarmee de webhook is gemaakt De levering van de webhookmelding geldt alleen als succesvol wanneer een succesreactie (2XX antwoordcode) wordt geretourneerd en de client-ID wordt verzonden in de HTTP-header (X-AdobeSign-ClientId) of in een JSON-antwoordtekst met sleutel als xAdobeSignClientId en waarde als dezelfde client-ID, anders proberen we de melding opnieuw naar de webhook-URL te sturen totdat de nieuwe pogingen zijn opgebruikt.

Zoals hierboven vermeld, moet de waarde van de client-ID in de koptekst 'X-AdobeSign-ClientId' die is opgenomen in elke meldingsaanvraag van Sign, op een van de volgende twee manieren worden 'teruggekaatst':

1. HTTP-koptekst X-AdobeSign-ClientId en de waarde van deze client-ID

Voorbeeld van Javascript-code voor het ophalen, valideren en retourneren van de client-ID naar de koptekst van het antwoord

//Client-ID ophalen

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

 

//Valideren

if (clientid ==="BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

{

    //Retourneren in de koptekst van de respons

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

    response.status = 200;  // standaardwaarde

}

Voorbeeld van PHP-code voor het ophalen, valideren en retourneren van de client-ID naar de koptekst van het antwoord

<?php

//Client-ID ophalen

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Valideren

if($clientid == "BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

{

    //Retourneren in de koptekst van de respons

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

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

}

?>


2. JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde van dezelfde client-ID

Voorbeeld van Javascript-code voor het ophalen, valideren en retourneren van de client-ID naar de hoofdtekst van hat antwoord

//Client-ID ophalen

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

 

 

//Valideren

if (clientid ==="BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

{

    var responseBody = {

                         "xAdobeSignClientId" : clientid // Client-ID retourneren in de hoofdtekst van de respons

                       };

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

    response.body = responseBody;

    response.status = 200;

}

Voorbeeld van PHP-code voor het ophalen, valideren en retourneren van de client-ID naar de hoofdtekst van de respons

<?php

//Client-ID ophalen

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Valideren

if($clientid == "BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

{

    //Retourneren in de hoofdtekst van de respons

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

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

   echo json_encode($body);

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

}

?>

Voorbeeld van JSON-hoofdtekst van de respons

{

    "xAdobeSignClientId": "BGBQIIE7H253K6"

}

Vereisten

U hebt het volgende nodig:

  1. Een Microsoft-account met een licentie om Azure Functions-toepassingen te maken
  2. Een bestaande Azure Function-toepassing. U kunt deze maken met behulp van https://docs.microsoft.com/nl-nl/azure/azure-functions/functions-create-first-azure-function 
  3. Standaardkennis van Javascript, zodat u de code in een taal van uw keuze kunt begrijpen en schrijven

Stappen voor het maken van een Azure Functions-trigger die fungeert als Acrobat Sign-webhook

Een Javascript HTTP-triggerfunctie maken:

1. Meld u aan via uw Microsoft-account https://portal.azure.com/

2. Open de Azure Functie-applicatie die wordt weergegeven op het tabblad Functie-apps.

Hiermee wordt uw lijst met Azure Function-toepassingen geopend:

3. Kies de toepassing waarin u deze nieuwe functie wilt maken

4. Klik op de knop Maken (+) om een nieuwe Azure-functie te maken

 

5. Selecteer Webhook + API als scenario en Javascript als taal

6. Klik op Deze functie maken

Er wordt een nieuwe functie gemaakt waarmee een binnenkomende API-aanvraag kan worden verwerkt.

Logica toevoegen voor registratie van de Acrobat Sign-webhook

Voordat een webhook kan worden geregistreerd, controleert Acrobat Sign of de webhook-URL in de registratieaanvraag daadwerkelijk is bedoeld om meldingen te ontvangen. Wanneer Acrobat Sign een nieuwe aanvraag voor webhookregistratie ontvangt, wordt dan ook eerst een verificatieaanvraag gestuurd naar de webhook-URL. Hierbij gaat het om een HTTPS GET-aanvraag die naar de webhook-URL wordt gestuurd met de aangepaste HTTP-header X-AdobeSign-ClientId. De waarde in deze header is ingesteld op de client-ID van de toepassing die de aanvraag voor het maken/registreren van de webhook indient. Voordat een webhook kan worden geregistreerd, moet de webhook-URL aan dit verzoek voldoen met een 2XX-responscode. Bovendien moet dezelfde waarde voor de client-ID worden teruggestuurd op een van de volgende twee manieren.

U hebt twee opties:


Optie 1: De client-ID in X-AdobeSign-ClientId doorgeven als koptekst van de respons

Geef de X-AdobeSign-ClientId door in de koptekst van de respons. Dit is dezelfde koptekst die was doorgegeven in de oorspronkelijke aanvraag en die in de respons moet worden 'teruggekaatst'.

Vervang het bestand Index.js door het volgende:

module.exports = function (context, req) {

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

    // Bevestigen dat de binnenkomende ClientID ook echt is

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

        context.res = {

            // status: 200, /* Defaults to 200 */ // elke 2XX-respons is acceptabel

            body: "Melding geaccepteerd",

            headers : {

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

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Oeps!! Ongeldige aanroep geïdentificeerd"

        };

    }

    context.done();

};

 

Test het gedrag door de aanvraag na te bootsen:

1. Klik op de knop Test in de rechterhoek

2. Boots de aanvraag na

Hoewel antwoordheaders hierboven niet worden weergegeven, kunt u het bekijken door nabootsing via postman/DHC of een andere dienst.


Optie 2: De client-ID doorgeven in de hoofdtekst van het antwoord met de sleutel xAdobeSignClientId

In de JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde die gelijk is aan de client-ID die in de koptekst van de aanvraag was verzonden.

Vervang het bestand Index.js door het volgende:

module.exports = function (context, req) {

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

    // Bevestigen dat de binnenkomende ClientID ook echt is

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

        context.res = {

            // status: 200, /* Defaults to 200 */ // elke 2XX-respons is acceptabel

            body: {

                'xAdobeSignClientId' : clientId

            },

            headers : {

                'Content-Type' : 'application/json'

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Oeps!! Ongeldige aanroep geïdentificeerd"

        };

    }

    context.done();

};

 

Test het gedrag door de aanvraag na te bootsen

1. Klik op de knop Test in de rechterhoek

2. Boots de aanvraag na

Merk op dat hetzelfde gedrag voor clientID wordt verwacht wanneer de webhook-URL een POST-melding ontvangt. 


Klaar voor gebruik

Nadat u het gedrag hebt geverifieerd, is de webhook-URL functioneel volgens de Acrobat Sign-normen. U kunt de aangepaste logica verder bijwerken op basis van uw vereisten.

 

De functie-URL ophalen

  • Klik op Functie-URL ophalen

 

Kopieer de URL en gebruik deze om webhooks te maken in Acrobat Sign.

De AWS Lambda-functie maken

Om een AWS Lambda-functie te maken meldt u zich aan bij uw AWS Management Console en selecteert u de AWS Lambda-service in de lijst met services.

  • Klik op Een Lambda-functie maken met de optie Nieuw ontwerpen
  • Voer op de pagina Functie configureren de functienaam lambdaWebhooks in en selecteer Node.js 4.3 als Runtime
  • Kies voor de Rol een bestaande rol of maak een nieuwe rol op basis van sjablonen
    • Als u hebt gekozen voor  Nieuwe rol maken op basis van sjablonen, voert u een rolnaam in (bijv. rol-lamda) en selecteert u Vereenvoudigde microservices-machtigingen in de lijst Beleidsjablonen
  • Klik op de knop Functie maken

  • Selecteer op de nieuwe AWS lambda-functiepagina Code inline bewerken als Type code-invoer, bewaar de index.handler als Handler.
  • Logica toevoegen om de Acrobat Sign-webhook te registreren

    Voordat een webhook kan worden geregistreerd, controleert Acrobat Sign of de webhook-URL in de registratieaanvraag daadwerkelijk is bedoeld om meldingen te ontvangen. Wanneer Acrobat Sign een nieuwe aanvraag voor webhookregistratie ontvangt, wordt dan ook eerst een verificatieaanvraag gestuurd naar de webhook-URL. Hierbij gaat het om een HTTPS GET-aanvraag die naar de webhook-URL wordt gestuurd met de aangepaste HTTP-header X-AdobeSign-ClientId. De waarde in deze header is ingesteld op de client-ID van de toepassing die de aanvraag voor het maken/registreren van de webhook indient. Voordat een webhook kan worden geregistreerd, moet de webhook-URL aan dit verzoek voldoen met een 2XX-responscode. Bovendien moet dezelfde waarde voor de client-ID worden teruggestuurd op een van de volgende twee manieren. Merk op dat hetzelfde gedrag voor clientID wordt verwacht wanneer de webhook-URL een POST-melding ontvangt. 

    Volg een van de twee gevallen:

    Geval 1: Client-ID doorgeven in X-AdobeSign-ClientId als koptekst van de respons

    •  Geef de X-AdobeSign-ClientId door in de koptekst van de respons. Dit is dezelfde koptekst die was doorgegeven in de oorspronkelijke aanvraag en die in de respons moet worden 'teruggekaatst'.

      Codefragment
      In het index.js-bestand vervangt u het automatisch gegenereerde codefragment door de volgende code:

Voorbeeld van de JS-code van de node om de client-ID op te halen, deze te valideren en vervolgens terug te sturen naar de koptekst van de respons

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

  // Client-ID ophalen

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

 

 //Valideren

  if (clientid =="BGBQIIE7H253K6") //Vervang 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

  {

    var response = {

        statusCode: 200,

        headers: {

            "X-AdobeSign-ClientId": clientid

        }

     };

   callback(null,response);

  }

  else {

   callback("Oops!! illegitimate call");

  }

}

 

Geval 2: Client-ID doorgeven in de hoofdtekst van de respons met de sleutel xAdobeSignClientId

In de JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde die gelijk is aan de client-ID die in de koptekst van de aanvraag was verzonden.

 

Codefragment

Vervang het bestand Index.js door het volgende:

Voorbeeld van de JS-code van de node om de client-ID op te halen, deze te valideren en vervolgens terug te sturen naar de koptekst van de respons

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

 // Client-ID ophalen

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

  

 //Valideren

 if (clientid =="BGBQIIE7H253K6") //Vervang 'BGBQIIE7H253K6' door de client-ID van de applicatie waarmee de webhook is gemaakt

 {

   var responseBody = {

        xAdobeSignClientId : clientid

   };

     

    var response = {

        statusCode: 200,

        body: JSON.stringify(responseBody)

    };

 

   callback(null,response);

 }

 else {

   callback("Opps!! illegitimate call");

  }

}

  • Sla de functie op. Lambda-functie is gemaakt en we zijn bijna klaar om deze te gebruiken in een realtimewebhook

 

De AWS API-gateway configureren

Om deze Lambda openbaar toegankelijk te maken via een HTTP-methode moeten we de AWS API Gateway configureren met onze functie (hierboven gemaakt) als de back-end voor de API.

Selecteer in de AWS Management Console de API-gateway van de AWS-services en klik op de knop API maken

  • Selecteer op de pagina Nieuwe API maken Nieuwe API en voer webhooks in als de API-naam.
  • Klik op de knop API maken
  • Selecteer de vervolgkeuzelijst Acties en selecteer de optie Bron maken
  • Selecteer de optie Configureren als proxybron en voer valideren in bij Bronnaam en {proxy+} in het Bronpad
  • Selecteer de optie API Gateway CORS inschakelen niet en klik op de knop Bron maken
  • Houd de Lambda-functieproxy geselecteerd als integratietype en selecteer het gebied waar u de Lambda-functie hebt gemaakt in de vervolgkeuzelijst Lambda-gebied (waarschijnlijk is dat hetzelfde gebied waar u de API-gateway maakt).
  • Voer valideren in als de Lambda-functie en klik op de knop Opslaan
  • Selecteer in het pop-upvenster Toestemming toevoegen aan Lambda-functie OK

Als alle bovenstaande stappen correct zijn uitgevoerd, ziet u zoiets als dit:

API implementeren

De volgende stap is het implementeren van deze API, zodat deze klaar is voor gebruik.

  • Selecteer in de vervolgkeuzelijst Acties API implementeren
  • Selecteer [Nieuw stadium] in de Implementatiefase en voer prod (of iets anders waarmee u dit stadium wilt identificeren) in de Stadiumnaam in
  • Klik op de knop Implementeren

API is nu klaar voor gebruik en u kunt de aanroep-URL vinden in het blauwe vak, zoals hieronder weergegeven:

Let op deze URL, want u moet deze invoeren als uw realtimewebhook-URL.

Klaar voor gebruik

Het is gereed. Gebruik deze bovenstaande URL met "/{nodeJSfunctionName}" toegevoegd als webhook-url in POST /webhooks API-verzoek.  Nadat u het gedrag hebt geverifieerd, is de webhook-URL functioneel volgens de
Acrobat Sign-normen. U kunt de aangepaste logica verder bijwerken/toevoegen volgens uw vereisten.

Configuratieopties

Bij de configuratie van de webhook moet u vijf elementen definiëren:

  • Naam : we raden een intuïtieve naam aan die andere beheerders gemakkelijk kunnen begrijpen.
  • Bereik: hoe groot is het 'vangnet' van de webhook? Account en Groep zijn beschikbaar in de interface.
    • De API biedt ondersteuning voor de bereiken Account, Groep, Gebruiker en Bron.
    • Er kan slechts één bereik per webhook worden gedefinieerd.
  • URL: de doel-URL waarnaar Acrobat Sign de JSON-payload heeft gepusht.
  • Gebeurtenissen: de trigger die ervoor zorgt dat Acrobat Sign de JSON bouwt en naar de URL pusht.
    • Elke gebeurtenis bouwt een andere lading die relevant is voor de activeringsgebeurtenis.
    • Een webhook kan meerdere gebeurtenissen bevatten.
  • Notificatieparameters: met de notificatieparameters worden de secties van de JSON-payload voor de Gebeurtenis geïdentificeerd, zodat u alleen die secties van de Gebeurtenis kunt selecteren die voor deze webhook belangrijk zijn (wat leidt tot minder onnodige gegevens die naar uw URL worden gestuurd).

Zodra de webhook volledig is gedefinieerd, klikt u op Opslaan, waarna de webhook direct kan reageren op activeringsgebeurtenissen. 

Opmerking:

Configureer uw webhook-URL om te reageren op de webhookverificatie en webhookmeldingsverzoeken volgens het verificatieprotocol dat hierboven is uitgelegd. De client-ID (toepassings-ID) die wordt verzonden naar webhooks die zijn gemaakt met de Acrobat Sign-webtoepassing, is - UB7E5BXCXY

De webhook configureren



Bereiken

  • Account: de pushmelding wordt geactiveerd door alle subscribed gebeurtenissen in de account.
    • Accountbeheerders kunnen alle webhooks bekijken die zijn gedefinieerd voor het account en alle groepen binnen dat account.
  • Groep: de pushmelding wordt geactiveerd door alle subscribed gebeurtenissen in de desbetreffende groep OPMERKING: door de groep bestreken webhooks bestaan alleen voor die ene groep.
    • Groepsbeheerders kunnen alleen die webhooks zien die aan hun groep zijn toegewezen. Ze kunnen de webhooks op accountniveau of webhooks die aan andere groepen zijn gebonden, niet zien.
    • Accounts waarvoor Gebruikers in meerdere groepen zijn ingeschakeld, zien de optie om de groep in te stellen waarop het bereik moet worden toegepast.
  • Gebruikersaccount: de pushmelding wordt geactiveerd door alle gebeurtenissen met aanmelding in een gebruikersaccount. Webhooks op gebruikersniveau kunnen alleen via een API worden gemaakt.
  • Webhook op bronniveau: dergelijke webhooks worden gemaakt voor een specifieke bron. De gebeurtenissen die specifiek zijn voor deze bron, worden via een pushmelding naar de webhook-URL gestuurd. Webhooks op bronniveau kunnen alleen via een API worden gemaakt.

URL

Een webhook-URL is een server die luistert naar binnenkomende HTTPS POST-meldingen die worden geactiveerd wanneer bepaalde gebeurtenissen plaatsvinden.

U hebt deze URL nodig om uw webhook bij gebeurtenissen aan te melden.

  • De client moet een HTTPS-URL opnemen waarnaar Acrobat Sign een POST-melding kan sturen. Deze URL moet openbaar zijn op internet.  
    • Zo zullen 127.0.0.1 en localhost-URI's bijvoorbeeld niet werken.
    • Het URL-eindpunt moet luisteren op poort 443 of 8443 (bepaald door de klant bij het definiëren van de callback-URL).
  • Controleer of de webhook ondersteuning biedt voor POST-aanvragen bij inkomende gebeurtenismeldingen en voor GET-aanvragen bij de verificatieaanvraag.
  • De URL mag niet worden geblokkeerd door een firewall.


Gebeurtenissen

Hieronder staan de gebeurtenissen die een push naar de webhook-URL kunnen activeren, gegroepeerd op object en vermeld in de volgorde die in de gebruikersinterface wordt gevonden.

De waarde aan de linkerkant is de waarde die u ziet in de gebruikersinterface van Acrobat Sign. De waarde aan de rechterkant is de naam van de webhook in de API.

Raadpleeg de handleiding voor ontwikkelaars van Acrobat Sign voor volledige informatie over de webhooks en hun payloads.

Overeenkomsten:

Gebruikersinterface-element Webhooknaam
Overeenkomst voor alle gebeurtenissen AGREEMENT_ALL
Overeenkomst gemaakt AGREEMENT_CREATED
Overeenkomst verzonden AGREEMENT_ACTION_REQUESTED
Deelnemer aan overeenkomst voltooid AGREEMENT_ACTION_COMPLETED
Overeenkomstworkflow voltooid AGREEMENT_WORKFLOW_COMPLETED
Overeenkomst verlopen AGREEMENT_EXPIRED
Overeenkomst verwijderd AGREEMENT_DOCUMENTS_DELETED
Overeenkomst geannuleerd AGREEMENT_RECALLED
Overeenkomst afgewezen AGREEMENT_REJECTED
Overeenkomst gedeeld AGREEMENT_SHARED
Overeenkomst gedelegeerd AGREEMENT_ACTION_DELEGATED
Deelnemer aan overeenkomst vervangen AGREEMENT_ACTION_REPLACED_SIGNER
Overeenkomst gewijzigd AGREEMENT_MODIFIED
Wijziging van overeenkomst bevestigd AGREEMENT_USER_ACK_AGREEMENT_MODIFIED
Overeenkomst-e-mail bekeken AGREEMENT_EMAIL_VIEWED
Overeenkomst-e-mail niet bezorgd AGREEMENT_EMAIL_BOUNCED
Overeenkomst kan niet worden gemaakt AGREEMENT_AUTO_CANCELLED_CONVERSION_PROBLEM
Overeenkomst gesynchroniseerd na offlinegebeurtenis AGREEMENT_OFFLINE_SYNC
Overeenkomst geüpload door afzender AGREEMENT_UPLOADED_BY_SENDER
Overeenkomst gearchiveerd AGREEMENT_VAULTED
Deelnemer geverifieerd via identiteit op sociale media AGREEMENT_WEB_IDENTITY_AUTHENTICATED
Identiteit van deelnemer geverifieerd via KBA AGREEMENT_KBA_AUTHENTICATED
Overeenkomstherinnering verzonden AGREEMENT_REMINDER_SENT
Naam ondertekenaar overeenkomst gewijzigd door ondertekenaar AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER
   
Overeenkomst Webhooks alleen beschikbaar via API
N.v.t. AGREEMENT_EXPIRATION_UPDATED
N.v.t.
AGREEMENT_READY_TO_NOTARIZE
N.v.t.
AGREEMENT_READY_TO_VAULT

 

In bulk verzenden:

Gebruikersinterface-element Webhooknaam
In bulk verzenden: alle gebeurtenissen MEGASIGN_ALL
In bulk verzenden gemaakt
MEGASIGN_CREATED
In bulk verzenden gedeeld
MEGASIGN_SHARED
In bulk verzenden ingetrokken
MEGASIGN_RECALLED

 

Webformulieren:

Gebruikersinterface-element Webhooknaam
Webformulier: alle gebeurtenissen WIDGET_ALL
Webformulier gemaakt
WIDGET_CREATED
Webformulier ingeschakeld
WIDGET_ENABLED
Webformulier: uitgeschakeld
WIDGET_DISABLED
Webformulier gewijzigd
WIDGET_MODIFIED
Webformulier gedeeld
WIDGET_SHARED
Webformulier maken mislukt
WIDGET_AUTO_CANCELLED_CONVERSION_PROBLEM

 

Bibliotheeksjablonen (alleen API):

Gebruikersinterface-element Webhooknaam
N.v.t. LIBRARY_DOCUMENT_ALL
N.v.t. LIBRARY_DOCUMENT_CREATED
N.v.t. LIBRARY_DOCUMENT_AUTO_CANCELLED_CONVERSION_PROBLEM
N.v.t. LIBRARY_DOCUMENT_MODIFIED

 

Meldingsparameters

Met meldingsparamters kunt u de JSON-payload aanpassen aan de specifieke elementen van de gebeurtenis.

Bij de gebeurtenis Deelnemer overeenkomst vervangen wilt u misschien alleen de elementen Informatie over overeenkomst en Informatie over deelnemer opnemen, en Informatie over documenten niet. Zo houdt u ook de totale verstuurde content van de JSON naar uw webhook-URL beperkt.

 

  • Overeenkomst
    • Agreement Info: gedetailleerde overeenkomst die de status van de overeenkomst op het moment van de activerende gebeurtenis wordt gebaseerd.
    • Informatie over overeenkomstdocument: bevat alle documenten die als gevolg van de gebeurtenis zijn gegenereerd.
    • Informatie over overeenkomstdeelnemer: bevat alle deelnemergegevens als gevolg van de gebeurtenis.
    • Document met ondertekende overeenkomst: de ondertekende PDF. 
      • Van toepassing op de gebeurtenissen Overeenkomstworkflow voltooid en Overeenkomst: alle.
  • In bulk verzenden
    • Informatie over In bulk verzenden: gedetailleerde informatie over het object In bulk verzenden dat de gebeurtenis heeft geactiveerd.
  • Webformulier
    • Widgetinfo: gedetailleerde informatie over het webformulier dat de gebeurtenis heeft geactiveerd.
    • Informatie over widgetdocument: de documentinformatie die is gekoppeld aan het webformulier.
    • Informatie over widgetdeelnemers: informatie over de gedefinieerde deelnemers in het webformulier.

Tweezijdige SSL-verificatie

Tweerichtings-SSL, vaak Client-Side SSL of wederzijdse TLS genoemd, is een SSL-modus waarbij zowel de server als de client (webbrowser) certificaten presenteren om zichzelf te identificeren.

Accountbeheerders kunnen een 'client-side'-certificaat configureren op de pagina Beveiligingsinstellingen.

Acrobat Sign verifieert de SSL-certificaten bij het leveren van payloads aan de webhook-URL. Als een webhook de SSL-certificaatverificatie niet doorstaat, wordt er geen JSON-payload geleverd. 

Gebruik tweezijdige SSL-verificatie om de client (Acrobat Sign) te verifiëren en als listening-service om er zeker van te zijn dat uw webhook-URL alleen bereikbaar is voor Acrobat Sign. 

Als de webhook is gemaakt door een partnerapplicatie, gebruikt de webhook een clientcertificaat (indien beschikbaar) van het account van de partnerapplicatie om zichzelf te identificeren bij het maken van webhooknotificaties.

Hieronder vindt u de meest voorkomende vragen voor zowel het verificatieproces van de webserver als de verificatie van de clientcertificering.

Webserververificatie

Tijdens de registratie van een webhook verifieert Acrobat Sign de URL van de webhookserver.

Klanten kunnen de webhook niet registreren als de verbinding met de terugbel-URL van de webhook niet kan worden voltooid met Acrobat Sign.

Nee.

De webhookcallback-URL kan alleen HTTPS zijn op poort 443 of 8443.

Acrobat Sign blokkeert het uitgaande HTTPS-verkeer naar alle andere poorten.

Een goede manier om het servercertificaat te verifiëren is door de DigiCert® SSL-installatiediagnosetool te gebruiken.

Voer alleen de hostnaam in, bijvoorbeeld: www.digicert.com

Veelvoorkomende problemen zijn:

  • Probleem: een niet-vertrouwd CA- of zelfondertekend certificaat gebruiken

Oplossing: gebruik een openbaar door CA uitgegeven SSL-certificaat voor de webhookcallback-server.

Niet-vertrouwde CA

  • Probleem: de server verzendt het tussenliggende certificaat niet

Oplossing: installeer de tussenliggende certificaten op de webhookcallback-server.

Zie https://www.digicert.com/kb/ssl-certificate-installation.htm voor meer informatie.

Ontbrekende tussencertificaten

Verificatie van clientcertificaten

Om een tweerichtings-SSL in te stellen voor een webhook vragen we de beheerder een p12- (of pfx)-bestand met de privésleutel te uploaden. Het bestand wordt veilig opgeslagen in het klantaccount en de beheerder heeft volledige controle om het op elk moment te verwijderen.

In een tweerichtingswebhookconfiguratie is Acrobat Sign de beller/client en heeft de privésleutel nodig om te bewijzen dat de aanroep is gedaan door Acrobat Sign namens de klantaccount.

  1. Controleren of SSL in twee richtingen is ingeschakeld

    SSL in twee richtingen moet zijn ingeschakeld op de webhookcallback-server.

    Maak via elke webbrowser verbinding met de webhookcallback-URL. U zou het volgende moeten krijgen:

    400 Bad Request
    Geen vereist SSL-certificaat verzonden

    Dit betekent dat de server verwacht dat de client clientcertificaten verzendt (d.w.z.: tweerichtings-SSL is ingeschakeld voor de server).

    Als het bovenstaande bericht niet wordt weergegeven, is tweerichtings-SSL niet ingeschakeld.

    Opmerking:

    U kunt Postman gebruiken en een POST-verzoek doen naar de webhookcallback-URL. U zou een vergelijkbaar resultaat moeten krijgen.

  2. Clientcertificaat lokaal verifiëren

    De aanmeldingsgegevens van de klant kunnen een zelfondertekend certificaat of een door CA uitgegeven certificaat zijn. Ze moeten echter minimaal voldoen aan de volgende X.509 v3-uitbreidingen:

    X.509 v3-uitbreiding

    Waarde

    ExtendedKeyUsage

    clientAuth (OID: 1.3.6.1.5.5.7.3.2)

    KeyUsage

    digitalSignature

    Het clientcertificaat moet een PKCS12-bestand zijn met de extensie .p12 of .pfx, en het moet zowel het clientcertificaat bevatten (zodat de server de identiteit van de client kan verifiëren) als de persoonlijke sleutel van de client ( zodat de client berichten digitaal kan ondertekenen voor de server om te verifiëren tijdens de SSL-handshake). 

    Gebruik de opdracht openssl om het p12- (pfx)-bestand te verifiëren:

    openssl pkcs12 -info -in outfile.p12

    De wachtwoordzin voor de privésleutel moet worden aangevraagd. De uitvoer moet zowel certificaten als een versleutelde privésleutel bevatten, zoals:

    Bag Attributes
        localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB
    subject=/C=US/ST=California/L=San Jose/O=Adobe Inc./CN=sp.adobesignpreview.com
    issuer=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
    -----BEGIN CERTIFICATE-----
    MIIGwDCCBaigAwIBAgIQAhJSKDdyQZjlbYO5MJAYOTANBgkqhkiG9w0BAQsFADBP
    MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSkwJwYDVQQDEyBE
    ...
    JAKQLQ==
    -----END CERTIFICATE-----
    Bag Attributes: <No Attributes>
    subject=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
    issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
    -----BEGIN CERTIFICATE-----
    MIIEvjCCA6agAwIBAgIQBtjZBNVYQ0b2ii+nVCJ+xDANBgkqhkiG9w0BAQsFADBh
    MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
    ...
    -----END CERTIFICATE-----
    Bag Attributes
        localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB
    Key Attributes: <No Attributes>
    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI7eNh2qlsLPkCAggA
    ...
    FHE=
    -----END ENCRYPTED PRIVATE KEY-----

    De certificaten moeten ten minste het certificaat van de eindentiteit en de tussentijdse certificaten bevatten. Idealiter bevat het ook het CA-rootcertificaat.  

    Waarschuwing:

    Zorg ervoor dat het p12- of pfx-bestand beveiligd is met een wachtwoordzin.

  3. Een zelfondertekend clientcertificaat maken (optioneel)

    Clientcertificaten kunnen door een CA worden uitgegeven of zelfondertekend zijn, afhankelijk van uw wensen.

    Gebruik de opdracht openssl om een zelfondertekend clientcertificaat te genereren:

    openssl req -newkey rsa:4096 -keyform PEM -keyout ca.key -x509 -days 3650 -outform PEM -out ca.cer

    Let op:

    Houd de resulterende bestanden geheim, aangezien dit uw zelfondertekende CA-certificaten zijn.

    Genereer vervolgens het p12-klantbestand:

    1. Een privésleutel genereren voor de SSL-klant:

      openssl genrsa -out client.key 2048

    2. Gebruik de privésleutel van de klant om een certificatieverzoek te genereren:

      openssl req -new -key client.key -out client.req

    3. Het klantcertificaat uitgeven met behulp van het certificeringsverzoek en het CA-certificaat/sleutel:

      openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key -set_serial 101 -extensions client -days 365 -outform PEM -out client.cer

    4. Converteer het klantcertificaat en de privésleutel naar pkcs#12-indeling voor gebruik door browsers:

      openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12

    5. Verwijder de persoonlijke sleutel van de klant, het klantcertificaat en de klantaanvraagbestanden, aangezien de pkcs12 alles heeft wat u nodig hebt.

      rm client.key client.cer client.req

  4. Het klantcertificaat controleren ten opzichte van de externe server

    • Gebruik Postman om het PFX-bestand van de klant te laden in Instellingen > Certificaten.
    • Selecteer Certificaat toevoegen om het klantcertificaat toe te voegen.
    Instellingen Postman

    • Configureer de HTTP-header voor x-adobesign-clientid:
    De koptekst configureren

    Eenmaal geconfigureerd stuurt u een POST-verzoek naar de webhook callback-URL.

    U zou een 200-reactie moeten krijgen.

  5. Waarom weigert Acrobat Sign mijn PFX-bestand, zelfs nadat ik het met Postman heb geverifieerd?

    Als u het bovenstaande proces voor pfx-bestandsverificatie hebt gevolgd en Acrobat Sign het pfx-bestand nog steeds weigert, dan is het bestand waarschijnlijk gegenereerd door een Microsoft-tool die een niet-standaard PKCS12-bestand kan produceren.

    Gebruik in dat geval de onderstaande openssl-opdrachten om de certificaten en de persoonlijke sleutel uit het pfx-bestand te extraheren en genereer vervolgens een PKCS12-bestand met de juiste indeling:

    // Certificaten en privésleutel extraheren uit pfx-bestand
    openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:&quot;&quot; -out clientcert.crt -nokeys
    openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:&quot;&quot; -out clientcert.key -nodes -nocerts
    
    // Nieuw PKCS12-bestand maken
    openssl pkcs12 -export -inkey clientcert.key -in clientcert.crt -out clientcert.pfx

In- of uitschakelen

Toegang tot de webhookfunctie is standaard ingeschakeld voor accounts op ondernemingsniveau.

Beheerders op groepniveau kunnen webhooks maken/controleren die alleen binnen de groep functioneren.

Als u de pagina Webhooks wilt openen, gaat u naar de linkerkant van het menu Beheer: Account > Webhooks

Een webhook activeren

Wanneer een webhook voor de eerste keer wordt gemaakt, is de status voor de webhook Actief.

Op de pagina Webhooks in Acrobat Sign worden standaard de actieve webhooks getoond.

Een niet-actieve webhook activeren:

  • Klik op het pictogram Opties (drie horizontale lijnen) rechts van de webhookkoptekstrij en selecteer Alle webhooks weergeven

 

  • Klik één keer op de inactieve webhook om deze te selecteren
    • De opties voor de webhook worden onder de koptekstrij getoond
  • Klik op Activeren

Zodra de volgende gebeurtenis wordt geactiveerd, start de actieve webhook begint met het verzenden van gegevens naar de doel-URL.

Een webhook uitschakelen

Om een webhook uit te schakelen, hoeft u alleen maar de volgende stappen uit te voeren

  • Navigeer naar de pagina Webhooks
  • Klik één keer op de webhook die u wilt deactiveren
  • Selecteer Deactiveren in de menuopties onder de koprij
    • Wanneer een webhook is uitgeschakeld, is zijn status Niet actief

Een webhook weergeven of bewerken

U kunt webhooks altijd bewerken en opslaan, en als u een nieuwe configuratie opslaat, is de wijziging direct van kracht.

Alleen Gebeurtenissen en Meldingsparameters kunnen worden bewerkt.

Als u Naam, Bereik of URL wilt wijzigen, moet u een nieuwe webhook maken.

De parameters van een webhook bewerken:

  • Navigeer naar de pagina Webhooks 
  • Klik één keer op de webhook die u wilt bewerken
  • Klik op de optie Weergeven/Bewerken onder de koptekstrij

 

  • Voer de benodigde wijzigingen door en klik op Opslaan

Een webhook verwijderen

Een webhook kan altijd worden verwijderd.

Als u een webhook verwijdert, wordt deze in het systeem vernietigd. U kunt een verwijderde webhook dus niet herstellen of terugzetten.

Webhooks hoeven niet eerst te worden gedeactiveerd.

Een webhook verwijderen:

  • Navigeer naar Webhooks
  • Klik één keer op de webhook die u wilt verwijderen
  • Klik op de optie Verwijderen onder de koptekstrij
  • U wordt gevraagd of u zeker weet dat u de webhook wilt verwijderen. Klik op OK

Best practices

  • Meld u aan voor specifieke, noodzakelijke gebeurtenissen om het aantal HTTPS-verzoeken aan de server te beperken - Hoe specifieker u uw webhooks kunt maken, hoe minder volume u hoeft door te nemen.
  • Bestand tegen duplicatie - Als u één en dezelfde webhook-URL deelt met meerdere apps, en als dezelfde gebruiker is toegewezen aan elke app, wordt dezelfde gebeurtenis meerdere keren naar uw webhook verzonden (één keer per app). In sommige gevallen kan uw webhook dubbele gebeurtenissen ontvangen. Uw webhooktoepassing moet hiermee kunnen omgaan en dedupliceren op gebeurtenis-ID.
  • Altijd snel antwoorden op webhooks - Uw app heeft slechts tien seconden om te reageren op webhookverzoeken. Voor het verificatieverzoek is dit slechts zelden een probleem, aangezien uw app hoeft geen echt werk hoeft te doen om te reageren. Bij meldingsverzoeken doet de app als reactie op het verzoek meestal iets dat tijd kost. Het wordt aanbevolen om met een wachtrij aan een aparte thread of asynchroon te werken om ervoor te zorgen dat u binnen vijf seconden kunt reageren
  • Gelijktijdigheid beheren - Wanneer een gebruiker snel achter elkaar een aantal veranderingen aanbrengt, ontvangt uw app waarschijnlijk meerdere meldingen voor dezelfde gebruiker op ongeveer hetzelfde tijdstip. Als u niet goed oplet bij het beheer van gelijktijdigheid, is het mogelijk dat de app dezelfde wijzigingen voor dezelfde gebruiker meermalen aanbrengt. Om te profiteren van Acrobat Sign-webhooks moet u een duidelijk begrip hebben van het gebruik van de informatie. Stel uzelf de volgende vragen: 
    • Welke gegevens wilt u retourneren in de payload? 
    • Wie heeft toegang tot deze informatie? 
    • Welke beslissing of rapportage wordt hierdoor gegenereerd?
  • Aanbevelingen voor het ontvangen van een ondertekend document - Er zijn verschillende factoren waarmee u rekening moet houden bij het bepalen hoe u een ondertekende PDF van Acrobat Sign in uw documentbeheersysteem ontvangt. 

Hoewel het volkomen acceptabel is om gewoon de optie Overeenkomst van ondertekend document te selecteren tijdens het maken van een webhook, kunt u overwegen de Acrobat Sign-API te gebruiken om de documenten op te halen wanneer een activerende gebeurtenis (zoals de overeenkomststatus Voltooid) is ontvangen.

Dingen om rekening mee te houden...

Beperking van JSON-grootte

De grootte van de JSON-lading is beperkt tot 10 MB.

Als een gebeurtenis een grotere payload genereert, wordt een webhook geactiveerd, maar de attributen van voorwaardelijke parameters, als die aanwezig zijn in het verzoek, worden verwijderd om de payload te verkleinen. 

Wanneer dit gebeurt, wordt 'ConditionalParametersTrimmed' in het antwoord geretourneerd om de client te informeren dat de informatie over de conditionalParameters is verwijderd.

conditionalParametersTrimmed” is een array-object met informatie over de sleutels die zijn afgekapt.

De afkapping vindt plaats in de onderstaande volgorde:

  • includeSignedDocuments
  • includeParticipantsInfo
  • includeDocumentsInfo
  • includeDetailedInfo

De ondertekende documenten worden eerst worden afgekapt, gevolgd door deelnemerinformatie op, documentgegevens en de uiteindelijke gedetailleerde informatie.

Dit kan bijvoorbeeld op een gebeurtenis ook gebeuren als het agreement ondertekend document (versleutelde grondtal 64) of voor een agreement met meerdere formuliervelden bevat

Webhook-meldingen

Acrobat Sign-webhooks leveren meldingen die van toepassing zijn op alle deelnemers aan een overeenkomst als er een webhook is geconfigureerd voor die gebruiker, hun groep of hun account.

Overeenkomstgebeurtenissen worden zo verwerkt dat als er een webhook is geconfigureerd voor de betreffende deelnemer van die gebeurtenis, er een melding naar die webhook-URL wordt verzonden. Met andere woorden, webhooks worden geactiveerd voor gebeurtenissen in alle toepasselijke overeenkomsten, zelfs die buiten de groep of account waarin de webhook is geconfigureerd.

Meldingen worden alleen geleverd voor die gebeurtenissen waarbij de deelnemer betrokken is. De afzender van een overeenkomst ontvangt bijvoorbeeld bijna elke melding, terwijl ontvangers alleen meldingen ontvangen vanaf het begin van hun betrokkenheid bij de overeenkomst, en alleen voor die evenementen waarin ze betrokken zijn.

Webhookmeldingen volgen het huidige verificatie- en zichtbaarheidsmodel van Acrobat Sign zelf, wat betekent dat gebruikers pas toegang hebben tot de overeenkomst wanneer de deelname van de gebruiker aan een overeenkomst is begonnen.

De afzender stuurt een overeenkomst ter ondertekening naar drie ondertekenaars.

  • Er is een accountniveau WebhookX geconfigureerd voor het account van de afzender.
  • Signer1 is lid van hetzelfde account als de afzender maar in een andere groep en er is een WehbhookY geconfigureerd voor die groep.
  • Signer2 is lid van een ander account en er is een accountniveau WebhookZ geconfigureerd voor het Signer2-account.
  • Signer3 is lid van hetzelfde account als een afzender.

De Afzender stuurt een overeenkomst: WebhookX activeert Overeenkomst gemaakt en Overeenkomst verzonden terwijl WebhookY Overeenkomst verzonden activeert.

Signer1 ondertekent: WebhookX activeert Overeenkomst deelnemer voltooid en Overeenkomst verzonden, WebhookY activeert Overeenkomst deelnemer voltooid en WebhookZ activeert Overeenkomst verzonden.

Signer2 ondertekent: WebhookX activeert Overeenkomst deelnemer voltooid en Overeenkomst verzonden, terwijl WebhookZ een melding verzendt voor Overeenkomst deelnemer voltooid.

Signer3 ondertekent: WebhookX activeert Overeenkomst deelnemer voltooid en Overeenkomst workflow voltooid, WebhookY activeert Overeenkomst workflow voltooid en WebhookZ activeert Overeenkomst workflow voltooid.

Probeer het opnieuw wanneer de listening-service niet beschikbaar is

Als de doel-URL voor de webhook om welke reden dan ook niet beschikbaar is, zal Acrobat Sign de JSON in de wachtrij plaatsen en de push opnieuw proberen in een progressieve cyclus van 72 uur.

De niet-afgeleverde gebeurtenissen worden bewaard in een wachtrij voor opnieuw proberen en er wordt de komende 72 uur alles aan gedaan om de meldingen af te leveren in de volgorde waarin ze zijn opgetreden.

De strategie voor het opnieuw proberen van de levering van meldingen is een verdubbeling van de tijd tussen pogingen, beginnend met een interval van 1 minuut oplopend tot elke 12 uur, wat resulteert in 15 nieuwe pogingen in een tijdsbestek van 72 uur.

Als de webhookontvanger niet binnen 72 uur reageert en er in de afgelopen zeven dagen geen succesvolle leveringen van meldingen zijn geweest, wordt de webhook uitgeschakeld. Geen meldingen worden naar dit URL opnieuw verzonden tot webhook wordt geactiveerd.

Alle meldingen webhook tussen het moment is uitgeschakeld en het later opnieuw ingeschakeld, zullen verloren gaan.

 Adobe

Krijg sneller en gemakkelijker hulp

Nieuwe gebruiker?

Adobe MAX 2024

Adobe MAX

The Creativity Conference

14-16 oktober Miami Beach en online

Adobe MAX 2024

Adobe MAX

The Creativity Conference

14-16 oktober Miami Beach en online