Przykładowy kod JavaScript do pobrania identyfikatora klienta, sprawdzenia jego poprawności, a następnie zwrócenia go w nagłówku odpowiedzi
Ostatnia aktualizacja
18 wrz 2024
Nowości
Pierwsze kroki
- Skrócona instrukcja dla administratorów
- Skrócona instrukcja dla użytkowników
- Dla programistów
- Biblioteka samouczków wideo
- Często zadawane pytania
Administrowanie
- Przegląd Admin Console
- Zarządzanie użytkownikami
- Dodawanie użytkowników
- Tworzenie użytkowników w oparciu o funkcje
- Sprawdzanie pod kątem użytkowników z błędami obsługi
- Zmiana nazwiska/adresu e-mail
- Edytowanie członkostwa użytkownika w grupie
- Edytowanie członkostwa użytkownika w grupie za pomocą interfejsu grupy
- Awansowanie użytkownika do roli administratora
- Typy identyfikatorów użytkowników i SSO
- Przełączanie tożsamości użytkownika
- Uwierzytelnianie użytkowników z użyciem usługi MS Azure
- Uwierzytelnianie użytkowników z użyciem usługi Google Federation
- Profile produktowe
- Funkcja logowania
- Ustawienia konta/grupy
- Przegląd ustawień
- Ustawienia globalne
- Poziom i identyfikator konta
- Nowy interfejs odbiorcy
- Obiegi pracy samodzielnego podpisywania
- Wysyłka zbiorcza
- Formularze internetowe
- Niestandardowe obiegi pracy wysyłania
- Obiegi pracy Power Automate
- Dokumenty w bibliotece
- Zbieranie danych formularzy za pomocą umów
- Ograniczona widoczność dokumentu
- Załączanie kopii PDF podpisanej umowy
- Dołączanie łączy do wiadomości e-mail
- Dołączanie obrazu do wiadomości e-mail
- Pliki dołączone do wiadomości e-mail będą nazwane jako:
- Załączanie raportu kontroli do dokumentów
- Scalanie wielu dokumentów w jeden
- Pobierz pojedyncze dokumenty
- Przekaż podpisany dokument
- Delegacje dla użytkowników w moim koncie
- Zezwalanie odbiorcom zewnętrznym na delegowanie
- Upoważnienie do podpisania
- Upoważnienie do wysyłania
- Uprawnienia do dodawania pieczęci elektronicznych
- Ustawianie domyślnej strefy czasowej
- Ustawianie domyślnego formatu daty
- Użytkownicy w wielu grupach (UMG)
- Uprawnienia administratora grupy
- Zastępowanie odbiorcy
- Raport kontroli
- Stopka transakcji
- W komunikatach w produkcie i wskazówkach
- Przystępne pliki PDF
- Nowy sposób tworzenia
- Klient z sektora opieki zdrowotnej
- Konfiguracja konta
- Dodawanie logo
- Dostosowywanie nazwy hosta / adresu URL firmy
- Dodawanie nazwy firmy
- Przekierowanie adresu URL po umowie
- Preferencje dotyczące podpisu
- Dobrze sformatowane podpisy
- Zezwalanie odbiorcom na podpisywanie przez
- Sygnatariusze mogą zmieniać imiona i nazwiska
- Zezwalanie odbiorcom na korzystanie z zapisanych podpisów
- Niestandardowe warunki użytkowania i warunki ujawnienia danych klienta
- Prowadzenie odbiorców między polami formularza
- Ponowne uruchamianie obiegu pracy umowy
- Odmowa podpisania
- Zezwalanie na obiegi pracy stempli
- Wymaganie od sygnatariuszy podania stanowiska lub firmy
- Zezwalanie sygnatariuszom na wydrukowanie i złożenie podpisu pisemnego
- Pokazanie wiadomości podczas składania elektronicznego podpisu
- Wymaganie tworzenia przez sygnatariuszy podpisów za pomocą urządzenia mobilnego
- Prośba sygnatariuszy o adres IP
- Wykluczanie nazwy firmy i stanowiska w stemplach uczestnictwa
- Podpisy cyfrowe
- Pieczęcie elektroniczne
- Tożsamość cyfrowa
- Ustawienia raportu
- Nowy sposób raportowania
- Klasyczne ustawienia raportu
- Ustawienia zabezpieczeń
- Ustawienia pojedynczego logowania
- Ustawienia opcji Pamiętaj mnie
- Zasady dotyczące hasła logowania
- Siła hasła logowania
- Czas trwania sesji internetowej
- Typ szyfrowania PDF
- API
- Dostęp do informacji o użytkowniku i grupie
- Dozwolone zakresy IP
- Udostępnianie konta
- Zezwolenia na udostępnianie konta
- Ustawienia udostępniania umów
- Weryfikacja tożsamości sygnatariusza
- Hasło podpisywania umowy
- Siła hasła dokumentu
- Blokowanie sygnatariuszy według geolokalizacji
- Uwierzytelnianie telefoniczne
- Uwierzytelnianie oparte na wiedzy (KBA)
- Zezwalanie na wyodrębnianie stron
- Wygaśnięcie łącza dokumentu
- Przesłanie certyfikatu klienta dla elementów webhook / wywołań zwrotnych
- Znacznik czasowy
- Ustawienia wysyłania
- Wyświetlanie strony Wyślij po zalogowaniu
- Wymaganie nazwy odbiorcy przy wysyłaniu
- Blokowanie wartości nazw dla znanych użytkowników
- Dozwolone role odbiorcy
- Zezwól na e-osoby poświadczające
- Grupy odbiorców
- DW
- Dostęp do umowy odbiorcy
- Wymagane pola
- Załączanie dokumentów
- Spłaszczenie pola
- Modyfikowanie umowy
- Nazwa umowy
- Języki
- Wiadomości prywatne
- Dopuszczalne typy podpisu
- Przypomnienia
- Zabezpieczenie hasłem podpisanego dokumentu
- Wysyłanie powiadomień o umowie za pośrednictwem
- Opcje identyfikacji sygnatariusza
- Ochrona zawartości
- Włączanie transakcji Notarize
- Wygasanie dokumentu
- Wyświetlanie, ustawianie podpisów i dodawanie pól formularza
- Kolejność podpisywania
- Liquid Mode
- Niestandardowe elementy sterujące obiegiem pracy
- Opcje przesyłania na stronie podpisu elektronicznego
- Przekierowanie na inny adres URL potwierdzenia po podpisaniu
- Szablony wiadomości
- Ustawienia Bio-Pharma
- Integracja obiegu pracy
- Ustawienia notarializacji
- Integracja płatności
- Wiadomości sygnatariusza
- Ustawienia SAML
- Konfiguracja SAML
- Instalacja usługi federacyjnej Microsoft Active Directory
- Instalacja usługi Okta
- Instalacja usługi OneLogin
- Instalacja usługi Oracle Identity Federation
- Konfiguracja SAML
- Zarządzanie danymi
- Ustawienia znacznika czasowego
- Archiwum zewnętrzne
- Języki konta
- Ustawienia poczty e-mail
- Migracja z domeny echosign.com do adobesign.com
- Konfiguracja opcji dla odbiorców
- Wytyczne dotyczące wymogów regulacyjnych
- Dostępność
- HIPAA
- RODO
- 21 CFR część 11 i załącznik 11 EudraLex
- Klienci z sektora opieki zdrowotnej
- Obsługa IVES
- Umowy „archiwizowane”
- Kwestie do rozważenia w UE/Wielkiej Brytanii
- Zbiorcze pobieranie umów
- Przypisywanie domeny
- Łącza zgłaszania nadużycia
Wysyłanie i podpisywanie umów oraz zarządzanie nimi
- Opcje odbiorcy
- Anulowanie przypomnienia e-mail
- Opcje na stronie podpisu elektronicznego
- Przegląd strony podpisu elektronicznego
- Otwieranie w celu przeczytania umowy bez pól
- Odmowa podpisania umowy
- Delegowanie uprawnienia do podpisywania
- Ponowne uruchamianie umowy
- Pobieranie pliku PDF umowy
- Wyświetlanie historii umowy
- Wyświetlanie wiadomości umowy
- Konwertowanie z podpisu elektronicznego na pisemny
- Konwertowanie z podpisu pisemnego na podpis elektroniczny
- Nawigowanie po polach formularza
- Czyszczenie danych z pól formularza
- Powiększenie strony podpisu elektronicznego i nawigacja po niej
- Zmiana języka używanego w narzędziach i informacjach dotyczących umowy
- Przegląd informacji prawnych
- Dostosowywanie preferencji plików cookie Acrobat Sign
- Wysyłanie umów
- Tworzenie pól w dokumentach
- Środowisko tworzenia w aplikacji
- Automatyczne wykrywanie pól
- Przeciąganie i upuszczanie pól za pomocą środowiska tworzenia
- Przypisywanie pól formularza do odbiorców
- Rola Wstępne wypełnianie
- Stosowanie pól z szablonem pola wielokrotnego użytku
- Przenoszenie pól do nowego szablonu biblioteki
- Zaktualizowano środowisko tworzenia podczas wysyłania umów
- Tworzenie formularzy ze znacznikami tekstowymi
- Tworzenie formularzy przy pomocy programu Acrobat (AcroForm)
- Pola
- Tworzenie często zadawanych pytań
- Środowisko tworzenia w aplikacji
- Podpisywanie umów
- Zarządzaj umowami
- Omówienie strony Zarządzaj
- Delegowanie umowy
- Zastępowanie odbiorców
- Ograniczona widoczność dokumentu
- Anulowanie umowy
- Tworzenie nowych przypomnień
- Przeglądanie przypomnień
- Anulowanie przypomnienia
- Dostęp do obiegów Power Automate
- Więcej operacji…
- Działanie wyszukiwania
- Wyświetlanie umowy
- Tworzenie szablonu na podstawie umowy
- Ukrywanie/pokazywanie umów z widoku
- Przesyłanie podpisanej umowy
- Modyfikowanie plików i pól w wysłanych umowach
- Edytowanie sposobu uwierzytelniania odbiorcy
- Dodawanie lub modyfikacja daty wygaśnięcia
- Dodawanie uwagi do umowy
- Udostępnianie indywidualnej umowy
- Anulowanie udostępniania umowy
- Pobieranie poszczególnych umów
- Pobieranie pojedynczych plików umowy
- Pobieranie raportu kontroli dla umowy
- Pobieranie zawartości pola w umowie
- Raport kontroli
- Raportowanie i eksportowanie danych
- Omówienie
- Udzielanie użytkownikom dostępu do raportowania
- Wykresy raportu
- Eksport danych
- Zmiana nazwy raportu/eksportu
- Powielanie raportu/eksportu
- Planowanie raportu/eksportu
- Usuwanie raportu/eksportu
- Sprawdzanie użycia transakcji
Zaawansowane możliwości umów i obiegów pracy
- Formularze internetowe
- Tworzenie formularza internetowego
- Edycja formularza internetowego
- Wyłączanie/włączanie formularza internetowego
- Ukrywanie/pokazywanie formularza internetowego
- Znajdowanie adresu URL lub kodu skryptu
- Wstępne wypełnianie pól formularza internetowego przy użyciu parametrów adresu URL
- Zapisywanie formularza internetowego do późniejszego wypełnienia
- Zmiana rozmiaru formularza internetowego
- Szablony wielokrotnego użytku (Szablony biblioteki)
- Amerykańskie formularze urzędowe w bibliotece Acrobat Sign
- Tworzenie szablonu biblioteki
- Zmiana nazwy szablonu biblioteki
- Zmiana typu szablonu biblioteki
- Zmiana poziomu uprawnień szablonu biblioteki
- Kopiowanie, edytowanie i zapisywanie udostępnionego szablonu
- Pobieranie zagregowanych danych pól szablonu biblioteki
- Przenoszenie własności formularzy internetowych i szablonów bibliotek
- Obiegi pracy Power Automate
- Przegląd integracji Power Automate i dołączonych uprawnień
- Włączanie integracji usługi Power Automate
- Akcje kontekstowe na stronie Zarządzaj
- Śledzenie wykorzystania pakietu Power Automate
- Tworzenie nowego obiegu (przykłady)
- Aktywatory używane dla obiegów
- Importowanie obiegów spoza Acrobat Sign
- Zarządzanie obiegami
- Edycja obiegów
- Udostępnianie obiegów
- Wyłączanie lub włączanie obiegów
- Usuwanie obiegów
- Przydatne szablony
- Tylko administrator
- Zapisywanie wszystkich ukończonych dokumentów w usłudze SharePoint
- Zapisywanie wszystkich ukończonych dokumentów w usłudze OneDrive dla firm
- Zapisywanie wszystkich ukończonych dokumentów na Dysku Google
- Zapisywanie wszystkich ukończonych dokumentów w usłudze DropBox
- Zapisywanie wszystkich ukończonych dokumentów w usłudze Box
- Archiwizacja umowy
- Zapisywanie ukończonych dokumentów w usłudze SharePoint
- Zapisywanie ukończonych dokumentów w usłudze OneDrive dla firm
- Zapisywanie ukończonych dokumentów na Dysku Google
- Zapisywanie ukończonych dokumentów w usłudze DropBox
- Zapisywanie ukończonych dokumentów w Box
- Archiwizacja umowy formularza internetowego
- Zapisywanie ukończonych dokumentów formularzy internetowych w bibliotece SharePoint
- Zapisywanie ukończonych dokumentów formularzy internetowych w usłudze OneDrive dla firm
- Zapisywanie ukończonych dokumentów na dysku Google
- Zapisywanie ukończonych dokumentów formularzy internetowych w usłudze Box
- Wyodrębnianie danych umowy
- Powiadomienia o umowach
- Wysyłanie niestandardowych powiadomień mailowych z zawartością umowy i podpisaną umową
- Otrzymywanie powiadomień Adobe Acrobat Sign w kanale usługi Teams
- Otrzymywanie powiadomień Adobe Acrobat Sign w usłudze Slack
- Otrzymywanie powiadomień Adobe Acrobat Sign w usłudze Webex
- Generowanie umów
- Wygenerowanie dokumentu z formularza Power App i szablonu Word, wysłanie do podpisu
- Wygenerowanie umowy z szablonu programu Word w usłudze OneDrive i uzyskanie podpisu
- Wygenerowanie umowy dla wybranego wiersza programu Excel, wysłanie do recenzji i podpisu
- Tylko administrator
- Niestandardowe obiegi pracy wysyłania
- Udostępnianie użytkowników i umów
Integracja z innymi produktami
- Przegląd integracji Acrobat Sign
- Acrobat Sign dla Salesforce
- Acrobat Sign dla Microsoft
- Inne integracje
- Integracje zarządzane przez partnerów
- Jak uzyskać klucz integracji
Programista Acrobat Sign
- Interfejsy API REST
- Elementy webhook
Pomoc techniczna i rozwiązywanie problemów
Omówienie
Element webhook to zdefiniowane przez użytkownika żądanie HTTPS, które jest wyzwalane, gdy w witrynie źródłowej wystąpi subskrybowane zdarzenie (w tym przypadku Adobe Acrobat Sign).
Efektywnie zatem element webhook to tylko usługa REST, która przyjmuje dane lub strumień danych.
Elementy webhook służą do komunikacji między usługami w model PUSH.
Gdy wystąpi subskrybowane zdarzenie, program Acrobat Sign konstruuje wiadomość HTTPS POST z treścią JSON i dostarcza ją pod określony adres URL.
Przed skonfigurowaniem elementów webhook należy upewnić się, że sieć akceptuje zakresy IP wymagane dla funkcjonalności.
Elementy webhook oferują wiele korzyści w stosunku do poprzedniej metody wywołania zwrotnego, a niektóre z nich to:
- Administratorzy mogą włączać elementy webhook bez konieczności angażowania pomocy technicznej programu Acrobat Sign w celu wyszczególnienia adresu URL wywołania zwrotnego.
- Elementy webhook są lepsze pod względem „świeżości” danych, wydajności komunikacji i bezpieczeństwa. Nie jest wymagane sondowanie.
- Elementy webhook umożliwiają łatwe tworzenie różnych poziomów zakresu (Konto/Grupa/Użytkownik/Zasoby).
- Elementy webhook są nowocześniejszym rozwiązaniem API, umożliwiającym prostszą konfigurację nowoczesnych aplikacji.
- Możliwość skonfigurowania wielu elementów webhook dla każdego zakresu (konto/grupa/użytkownik/zasób), gdzie wywołania zwrotne musiały być unikalne.
- Elementy webhook pozwalają na wybór danych, które mają być zwrócone, podczas gdy wywołania zwrotne są rozwiązaniem typu „wszystko albo nic”.
- Metadane przenoszone przez elementy webhook można skonfigurować (Podstawowe lub Szczegółowe).
- Elementy webhook znacznie łatwiej jest tworzyć, edytować i wyłączać w razie potrzeby, ponieważ interfejs użytkownika znajduje się całkowicie pod kontrolą administratora.
Uwaga:
Ten dokument dotyczy przede wszystkim interfejsu użytkownika elementów webhook w aplikacji internetowej Acrobat Sign (poprzednio Adobe Sign).
Programiści, którzy poszukują szczegółowych informacji na temat interfejsu API, mogą znaleźć więcej informacji tutaj:
Wymagania wstępne
Aby usługa działała, należy zezwolić na zakresy IP dla elementów webhook za pośrednictwem zabezpieczeń sieciowych.
Starsza usługa adresu URL wywołania zwrotnego w REST v5 wykorzystuje te same zakresy adresów IP, co usługa webhook.
Administratorzy mogą zalogować się na stronie Adobe Admin Console, aby dodać użytkowników. Po zalogowaniu przejdź do menu administratora i przewiń w dół do sekcji Elementy webhook.
Korzystanie
Administratorzy będą musieli najpierw utworzyć usługę elementów webhook, gotową do przyjmowania przychodzących komunikatów od programu Acrobat Sign. Istnieje wiele opcji w tym zakresie, a jeśli tylko usługa może przyjmować żądania POST i GET, element webhook będzie działał poprawnie.
Po wprowadzeniu usługi administrator programu Acrobat Sign może utworzyć nowy element webhook za pomocą interfejsu Webhook w menu Konto na stronie programu Acrobat Sign.
Administratorzy mogą skonfigurować element webhook tak, aby wyzwalał się w przypadku zdarzeń typu Umowa, Formularz internetowy (widżet) lub Wyślij zbiorczo (MegaSign). Zasób szablonu biblioteki (dokument biblioteki) można również skonfigurować za pośrednictwem interfejsu API.
Zakres elementu webhook może obejmować całe konto lub poszczególne grupy za pośrednictwem interfejsu administratora. Interfejs API zapewnia większą szczegółowość poprzez wybór zakresów USER lub RESOURCE.
Rodzaj danych przesyłanych do adresu URL jest konfigurowalny i może obejmować takie elementy, jak informacje o umowie, informacje o uczestniku, informacje o dokumencie itd.
Po skonfigurowaniu i zapisaniu elementu webhook program Acrobat Sign będzie przesyłał nowy obiekt JSON pod zdefiniowany adres URL za każdym razem, gdy subskrybowane zdarzenie zostanie wyzwolone. Nie jest wymagana bieżąca manipulacja elementem webhook, chyba że użytkownik chce zmienić kryteria wyzwalania zdarzeń lub zawartość pliku JSON.
Weryfikacja intencji adresu URL elementu webhook
Przed pomyślnym zarejestrowaniem elementu webhook program Acrobat Sign sprawdza, czy adres URL elementu webhook podany w żądaniu rejestracji jest przeznaczony do otrzymywania powiadomień, czy też nie. W tym celu po otrzymaniu przez aplikację Acrobat Sign nowego żądania rejestracji elementu webhook, najpierw wysyła ona żądanie weryfikacji na adres URL elementu webhook. To żądanie weryfikacji jest żądaniem HTTPS GET wysyłanym do adresu URL elementu webhook. To żądanie zawiera niestandardowy nagłówek HTTP X-AdobeSign-ClientId. Wartość w tym nagłówku jest ustawiana na identyfikator klienta (identyfikator aplikacji) aplikacji API, która żąda utworzenia/zarejestrowania elementu webhook. Aby pomyślnie zarejestrować element webhook, adres URL elementu webhook musi odpowiedzieć na to żądanie weryfikacji za pomocą kodu odpowiedzi 2XX ORAZ dodatkowo MUSI zwrócić tę samą wartość identyfikatora klienta za pomocą jednego z następujących dwóch sposobów:
- Albo w nagłówku odpowiedzi X-AdobeSign-ClientId. Jest to ten sam nagłówek, który został przekazany w żądaniu i jest ponownie przywoływany w odpowiedzi.
- Albo w treści odpowiedzi JSON z kluczem xAdobeSignClientId i jego wartością jest ten sam identyfikator klienta, który został wysłany w żądaniu.
Element webhook zostanie pomyślnie zarejestrowany tylko po uzyskaniu odpowiedzi pozytywnej (kod odpowiedzi 2XX) i sprawdzeniu poprawności identyfikatora klienta w nagłówku lub treści odpowiedzi. Celem tego żądania weryfikacji jest wykazanie, że adres URL elementu webhook chce otrzymywać powiadomienia pod tym adresem. Jeśli przypadkowo wprowadzono nieprawidłowy adres URL, adres ten nie odpowie poprawnie na żądanie weryfikacji zamiarów, a program Acrobat Sign nie wyśle żadnych powiadomień na ten adres URL. Ponadto adres URL elementu webhook może również potwierdzić, że będzie otrzymywać powiadomienia tylko za pośrednictwem elementów webhook zarejestrowanych przez konkretną aplikację. Można to zrobić, sprawdzając poprawność identyfikatora klienta aplikacji przekazanego w nagłówku X-AdobeSign-ClientId. Jeśli adres URL elementu webhook nie rozpoznaje tego identyfikatora klienta, NIE MOŻE odpowiedzieć kodem odpowiedzi „powodzenie”, a program Acrobat Sign zadba o to, aby adres URL nie został zarejestrowany jako element webhook.
Weryfikacja wywołania adresu URL elementu webhook będzie przeprowadzana w następujących scenariuszach:
- Rejestracja elementu webhook: jeśli ta weryfikacja adresu URL elementu webhook nie powiedzie się, element webhook nie zostanie utworzony.
- Aktualizacja elementu webhook: NIEAKTYWNY do AKTYWNY: jeśli ta weryfikacja wywołania adresu URL elementu webhook nie powiedzie się, stan elementu webhook nie zostanie zmieniony na AKTYWNY.
Jak odpowiedzieć na powiadomienie elementu webhook
Program Acrobat Sign przeprowadza niejawną weryfikację intencji w każdym żądaniu powiadomienia elementu webhook wysyłanym do adresu URL elementu webhook. Dlatego każde żądanie HTTPS powiadomienia elementu webhook zawiera również niestandardowy nagłówek HTTP o nazwie X-AdobeSign-ClientId. Wartością tego nagłówka jest identyfikator klienta (ID aplikacji) aplikacji, która utworzyła element webhook. Powiadomienie elementu webhook zostanie uznane za pomyślnie dostarczone, jeśli, i tylko jeśli, zostanie zwrócona odpowiedź powodzenia (kod odpowiedzi 2XX) i identyfikator klienta zostanie wysłany w nagłówku HTTP (X-AdobeSign-ClientId) lub w treści odpowiedzi JSON z kluczem jako xAdobeSignClientId i wartością jako ten sam identyfikator klienta, w przeciwnym razie będziemy ponawiać próby dostarczenia powiadomienia na adres URL elementu webhook aż do wyczerpania limitu prób.
Jak wspomniano powyżej, nagłówek „X-AdobeSign-ClientId” , który jest dołączany do każdego żądania powiadomienia od Sign, wartość tego nagłówka (identyfikator klienta) powinna być powtórzona w odpowiedzi na jeden z dwóch sposobów:
1. Nagłówek HTTP X-AdobeSign-ClientId i wartość jako identyfikator tego klienta
|
|
|---|
|
// Fetch client id var clientid = request.headers['X-ADOBESIGN-CLIENTID'];
//Validate it if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created { //Return it in response header response.headers['X-AdobeSign-ClientId'] = clientid; response.status = 200; // default value } |
|
Przykładowy kod PHP do pobrania identyfikatora klienta, sprawdzenia jego poprawności, a następnie zwrócenia go w nagłówku odpowiedzi |
|---|
|
<?php // Fetch client id $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Validate it if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created { //Return it in response header header("X-AdobeSign-ClientId:$clientid"); header("HTTP/1.1 200 OK"); // default value } ?> |
2. Treść odpowiedzi JSON z kluczem jako xAdobeSignClientId i wartością jako tym samym identyfikatorem klienta
|
Przykładowy kod Javascript do pobrania identyfikatora klienta, sprawdzenia jego poprawności i zwrócenia go w treści odpowiedzi |
|---|
|
// Fetch client id var clientid = request.headers['X-ADOBESIGN-CLIENTID'];
//Validate it if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created { var responseBody = { "xAdobeSignClientId" : clientid // Return Client Id in the body }; response.headers['Content-Type'] = 'application/json'; response.body = responseBody; response.status = 200; } |
|
Przykładowy kod PHP do pobrania identyfikatora klienta, sprawdzenia jego poprawności i zwrócenia go w treści odpowiedzi |
|---|
|
<?php // Fetch client id $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Validate it if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created { //Return it in response body header("Content-Type: application/json"); $body = array('xAdobeSignClientId' => $clientid); echo json_encode($body); header("HTTP/1.1 200 OK"); // default value } ?> |
|
Przykładowa treść odpowiedzi w formacie JSON |
|---|
|
{ "xAdobeSignClientId": "BGBQIIE7H253K6" } |
Wymagania wstępne
Potrzebne będą:
- Konto Microsoft z licencją na tworzenie aplikacji Azure Functions
- Istniejąca aplikacja Azure Function, można ją utworzyć za pomocą strony https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function
- Podstawowa znajomość języka Javascript, umożliwiająca zrozumienie i napisanie kodu w dowolnie wybranym języku
Kroki tworzenia wyzwalacza Azure Functions, który posłuży jako element webhook Acrobat Sign
Aby utworzyć funkcję wyzwalacza HTTP Javascript:
1. Zaloguj się za pomocą konta Microsoft https://portal.azure.com/
2. Otwórz aplikację Azure Function wyświetlaną na karcie Function Apps.
Spowoduje to otwarcie listy aplikacji Azure Function:
3. Wybierz aplikację, w której chcesz utworzyć nową funkcję
4. Kliknij przycisk Utwórz (+), aby utworzyć nową funkcję Azure
5. Wybierz opcję Webhook + API jako scenariusz oraz JavaScript jako język
6. Kliknij przycisk Utwórz tę funkcję
Tworzona jest nowa funkcja, która może obsługiwać przychodzące żądanie API.
Dodawanie logiki, aby zarejestrować element webhook Acrobat Sign
Przed pomyślnym zarejestrowaniem elementu webhook program Acrobat Sign sprawdza, czy adres URL elementu webhook podany w żądaniu rejestracji jest rzeczywiście przeznaczony do otrzymywania powiadomień, czy też nie. W tym celu, gdy program Acrobat Sign otrzymuje nowe żądanie rejestracji elementu webhook, najpierw kieruje żądanie weryfikacji na adres URL elementu webhook. To żądanie weryfikacji jest żądaniem HTTPS GET wysyłanym do adresu URL elementu webhook z niestandardowym nagłówkiem HTTP X-AdobeSign-ClientId. Wartość w tym nagłówku jest ustawiana na identyfikator klienta aplikacji, która żąda utworzenia/zarejestrowania elementu webhook. Aby pomyślnie zarejestrować element webhook, adres URL elementu webhook musi odpowiedzieć na to żądanie weryfikacji za pomocą kodu odpowiedzi 2XX ORAZ dodatkowo musi zwrócić tę samą wartość identyfikatora klienta za pomocą jednego z następujących dwóch.
Istnieją dwie opcje, zgodnie z którymi można postąpić:
Opcja 1: Przekaż identyfikator klienta w X-AdobeSign-ClientId jako nagłówek odpowiedzi
Przekaż X-AdobeSign-ClientId w nagłówku odpowiedzi. Jest to ten sam nagłówek, który został przekazany w żądaniu i musi być ponownie przywoływany w odpowiedzi.
Zastąp plik Index.js następująca treścią:
module.exports = function (context, req) {
var clientId = req.headers['x-adobesign-clientid'];
// Validate that the incoming ClientID is genuine
if (clientId === '123XXX456') {
context.res = {
// status: 200, /* Defaults to 200 */ // any 2XX response is acceptable
body: "Notification Accepted",
headers : {
'x-adobesign-clientid' : req.headers['x-adobesign-clientid']
}
};
}
else {
context.res = {
status: 400,
body: "Opps!! Illegitimate Call identified"
};
}
context.done();
};
Przetestuj zachowanie, symulując żądanie:
1. Kliknij przycisk Test w skrajnie prawym rogu
2. Zasymuluj żądanie pozorne
Co prawda nagłówki odpowiedzi nie są pokazane powyżej, ale można je zaobserwować, symulując je za pomocą usługi Postman/DHC lub innej.
Opcja 2: Przekaż identyfikator klienta w treści odpowiedzi za pomocą klucza xAdobeSignClientId
W treści odpowiedzi JSON z kluczem xAdobeSignClientId i jego wartością jest ten sam identyfikator klienta, który został wysłany w nagłówku żądania.
Zastąp plik Index.js następująca treścią:
module.exports = function (context, req) {
var clientId = req.headers['x-adobesign-clientid'];
// Validate that the incoming ClientID is genuine
if (clientId === '123XXX456') {
context.res = {
// status: 200, /* Defaults to 200 */ // any 2XX response is acceptable
body: {
'xAdobeSignClientId' : clientId
},
headers : {
'Content-Type' : 'application/json'
}
};
}
else {
context.res = {
status: 400,
body: "Opps!! Illegitimate Call identified"
};
}
context.done();
};
Przetestuj zachowanie, symulując żądanie
1. Kliknij przycisk Test w skrajnie prawym rogu
2. Zasymuluj żądanie pozorne
Należy również pamiętać, że takie samo zachowanie dla clientID jest oczekiwane, gdy adres URL elementu webhook otrzymuje powiadomienia POST.
Gotowe do użycia
Po zweryfikowaniu zachowania adres URL elementu webhook jest funkcjonalny zgodnie ze standardami Acrobat Sign. Logikę niestandardową można dalej aktualizować zgodnie z własnymi wymaganiami.
Uzyskaj adres URL funkcji
- Kliknij przycisk Pobierz adres URL funkcji
Skopiuj adres URL i użyj go do tworzenia elementów webhook w programie Acrobat Sign.
Tworzenie funkcji AWS Lambda
Aby utworzyć funkcję AWS Lambda, zaloguj się do konsoli zarządzania AWS Management Console i wybierz usługę AWS Lambda z listy usług.
- Kliknij opcję Utwórz funkcję Lambda przy użyciu opcji „Utwórz od początku”
- Na stronie Konfiguruj funkcję wprowadź nazwę funkcji "lambdaWebhooks" i wybierz Node.js 4.3 jako środowisko wykonawcze
- W zakresie opcji Rola wybierz istniejącą rolę lub utwórz nową rolę z szablonu(ów)
- Jeśli wybrano Utwórz nową rolę z szablonu(ów) wprowadź nazwę roli (np. role-lambda) i wybierz Uprawnienia prostych mikroserwisów z listy Szablony zasad
- Kliknij przycisk Utwórz funkcję
- Na stronie nowej funkcji lamda AWS wybierz „Edytuj kod w wierszu" jako „Typ wpisu kodu", zachowaj index.handler jako element obsługi zdarzenia.
- Dodaj logikę, aby zarejestrować element webook Acrobat Sign
Przed pomyślnym zarejestrowaniem elementu webhook program Acrobat Sign sprawdza, czy adres URL elementu webhook podany w żądaniu rejestracji jest rzeczywiście przeznaczony do otrzymywania powiadomień, czy też nie. W tym celu, gdy program Acrobat Sign otrzymuje nowe żądanie rejestracji elementu webhook, najpierw kieruje żądanie weryfikacji na adres URL elementu webhook. To żądanie weryfikacji jest żądaniem HTTPS GET wysyłanym do adresu URL elementu webhook z niestandardowym nagłówkiem HTTP X-AdobeSign-ClientId. Wartość w tym nagłówku jest ustawiana na identyfikator klienta aplikacji, która żąda utworzenia/zarejestrowania elementu webhook. Aby pomyślnie zarejestrować element webhook, adres URL elementu webhook musi odpowiedzieć na to żądanie weryfikacji za pomocą kodu odpowiedzi 2XX ORAZ dodatkowo musi zwrócić tę samą wartość identyfikatora klienta za pomocą jednego z następujących dwóch. Należy również pamiętać, że takie samo zachowanie dla clientID jest oczekiwane, gdy adres URL elementu webhook otrzymuje powiadomienia POST.
Postępuj zgodnie z jednym z dwóch przypadków:
Przypadek 1: przekaż identyfikator klienta w X-AdobeSign-ClientId jako nagłówek odpowiedzi
- Przekaż X-AdobeSign-ClientId w nagłówku odpowiedzi. Jest to ten sam nagłówek, który został przekazany w żądaniu i musi być ponownie przywoływany w odpowiedzi.
Fragment kodu
W pliku index.js zastąp automatycznie wygenerowany fragment kodu następującym kodem:
- Przekaż X-AdobeSign-ClientId w nagłówku odpowiedzi. Jest to ten sam nagłówek, który został przekazany w żądaniu i musi być ponownie przywoływany w odpowiedzi.
|
Przykładowy kod JS węzła do pobrania identyfikatora klienta, sprawdzenia jego poprawności, a następnie zwrócenia go w nagłówku odpowiedzi |
|---|
|
exports.handler = function index(event, context, callback) { // Fetch client id var clientid = event.headers['X-AdobeSign-ClientId'];
//Validate it if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created { var response = { statusCode: 200, headers: { "X-AdobeSign-ClientId": clientid } }; callback(null,response); } else { callback("Oops!! illegitimate call"); } } |
Przypadek 2: Przekaż identyfikator klienta w treści odpowiedzi za pomocą klucza xAdobeSignClientId
W treści odpowiedzi JSON z kluczem xAdobeSignClientId i jego wartością jest ten sam identyfikator klienta, który został wysłany w nagłówku żądania.
Fragment kodu
Zastąp plik Index.js następującą treścią:
|
Przykładowy kod JS węzła do pobrania identyfikatora klienta, sprawdzenia jego poprawności, a następnie zwrócenia go w nagłówku odpowiedzi |
|---|
|
exports.handler = function index(event, context, callback) { // Fetch client id var clientid = event.headers['X-AdobeSign-ClientId'];
//Validate it if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created { var responseBody = { xAdobeSignClientId : clientid };
var response = { statusCode: 200, body: JSON.stringify(responseBody) };
callback(null,response); } else { callback("Opps!! illegitimate call"); } } |
- Zapisz funkcję. Funkcja lambda została utworzona i jesteśmy prawie gotowi do użycia jej w elemencie webhook działającym w czasie rzeczywistym.
Konfiguracja bramy AWS API Gateway
Aby uczynić tę funkcję lambda publicznie dostępną za pomocą metody HTTP, musimy skonfigurować bramę AWS API Gateway, używając naszej funkcji (utworzonej powyżej) jako backendu dla API.
W konsoli zarządzania AWS wybierz Brama API Gateway z usług AWS i kliknij przycisk Utwórz API
- Na stronie Utwórz nowy interfejs API wybierz Nowy interfejs API i wprowadź webhooks jako nazwę API.
- Kliknij przycisk Utwórz API
- Wybierz listę rozwijaną Działania i zaznacz opcję Utwórz zasób
- Zaznacz opcję Skonfiguruj jako zasób proxy i wpisz validate jako Nazwę zasobu oraz {proxy+} w sekcji Ścieżka zasobu
- Pozostaw niezaznaczoną opcję Włącz API Gateway CORS i kliknij przycisk Utwórz zasób
- Zachowaj wybór Proxy funkcji Lambda jako Typ integracji i wybierz region, w którym utworzono funkcję Lambda na liście rozwijanej Region Lambda (prawdopodobnie jest to ten sam region, w którym tworzysz bramę API Gateway).
- Wpisz validate jako Funkcję lambda i kliknij przycisk Zapisz
- W oknie wyskakującym Dodaj uprawnienie do funkcji Lambda wybierz OK
Jeśli wszystkie powyższe kroki zostaną wykonane pomyślnie, zobaczysz coś takiego:
Wdrażanie interfejsu API
Następnym krokiem jest wdrożenie tego interfejsu API, aby był gotowy do użycia.
- Z listy rozwijanej Działania wybierz opcję Wdrażanie interfejsu API
- Wybierz [Nowy etap] na karcie Etap wdrożenia i wpisz prod (lub cokolwiek, czym chcesz zidentyfikować ten etap) w sekcji Nazwa etapu
- Kliknij przycisk Wdrożenie.
Interfejs API jest teraz gotowy do użycia, a adres URL wywołania można znaleźć w niebieskim polu, jak pokazano poniżej:
Zapamiętaj ten adres URL, ponieważ będzie on potrzebny do wprowadzenia jako adres URL elementu webhook czasu rzeczywistego.
Gotowe do użycia
Gotowe. Użyj powyższego adresu URL z dodatkiem "/{nodeJSfunctionName}" jako adresu URL elementu webhook w żądaniu API POST /webhooks. Po zweryfikowaniu zachowania adres URL elementu webhook jest funkcjonalny zgodnie ze
standardami Acrobat Sign. Logikę niestandardową można dalej aktualizować zgodnie z własnymi wymaganiami.
Włączanie i wyłączanie
Dostęp do funkcji elementy webhook jest domyślnie włączony dla kont na poziomie przedsiębiorstwa.
Administratorzy poziomu grupy mogą tworzyć lub kontrolować elementy webhook działające tylko w obrębie ich grupy.
Dostęp do strony elementu webhook można znaleźć w lewej części menu Administrator.
Ograniczenie szybkości oparte na współbieżności
Zdarzenia tworzenia elementu webhook (i wywołania zwrotnego) i powiadomień są ograniczone w liczbie jednoczesnych powiadomień, które są aktywnie dostarczane klientowi z systemu Acrobat Sign. Ten limit dotyczy konta, aby uwzględnić wszystkie grupy na koncie.
Ten rodzaj ograniczenia szybkości zapobiega zużywaniu przez jedno źle zaprojektowane konto nieproporcjonalnej ilości zasobów serwera, co negatywnie wpływa na wszystkich innych klientów w tym środowisku serwerowym.
Obliczono liczbę jednoczesnych zdarzeń na konto w celu zapewnienia, że konta ze stabilnymi elementami webhook będą otrzymywać powiadomienia w jak najkrótszym czasie i rzadko powinny napotkać sytuację, w której powiadomienia są opóźnione z powodu zbyt dużej liczby żądań. Obecne progi to:
|
Działanie |
Maksymalna liczba |
Opis |
|
Tworzenie elementów webhook |
10 |
Na jedno konto dozwolonych jest maksymalnie 10 jednoczesnych żądań utworzenia elementów webhook. |
|
Powiadomienie elementu webhook/wywołania zwrotnego |
30 |
Na konto dozwolone jest maksymalnie 30 jednoczesnych powiadomień elementów webhook i wywołań zwrotnych. |
Sprawdzone metody
- Subskrybuj określone, potrzebne zdarzenia, aby ograniczyć liczbę żądań HTTPS do serwera — im bardziej precyzyjne elementy webhook, tym mniej objętości należy przesiać.
- Odporność na powielanie — jeśli masz więcej niż jedną aplikację korzystającą z tego samego adresu URL elementu webhook i tego samego użytkownika zmapowanego do każdej aplikacji, to to samo zdarzenie będzie wysyłane do Twojego elementu webhook wielokrotnie (raz na aplikację). W niektórych przypadkach element webhook może otrzymywać zduplikowane zdarzenia. Twoja aplikacja elementu webhook powinna być na to odporna i deduplikować według identyfikatora zdarzenia.
- Zawsze szybko reaguj na elementy webhook — Twoja aplikacja ma tylko pięć sekund na zareagowanie na żądania elementów webhook. W przypadku żądania weryfikacji rzadko stanowi to problem, ponieważ aplikacja nie musi wykonywać żadnych czynności, aby na nie odpowiedzieć. Jednak w przypadku żądań powiadomień aplikacja zwykle wykonuje coś, co wymaga czasu w odpowiedzi na żądanie. Zaleca się pracę nad oddzielnym wątkiem lub asynchroniczne używanie kolejki, aby zapewnić odpowiedź w ciągu pięciu sekund.
- Zarządzaj współbieżnością — gdy użytkownik dokonuje wielu zmian w szybkim tempie, Twoja aplikacja prawdopodobnie otrzyma wiele powiadomień dotyczących tego samego użytkownika mniej więcej w tym samym czasie. Jeśli nie zachowasz ostrożności w zarządzaniu współbieżnością, Twoja aplikacja może przetwarzać te same zmiany dla tego samego użytkownika więcej niż jeden raz. Aby skorzystać z elementów webhook programu Acrobat Sign, należy dobrze zrozumieć sposób wykorzystania tych informacji. Należy zadać następujące pytania:
- Jakie dane chcesz zwrócić w ładunku?
- Kto będzie uzyskiwał dostęp do tych informacji?
- Jakie decyzje lub raporty będą generowane?
- Zalecenia dotyczące otrzymywania podpisanego dokumentu — istnieje kilka czynników, które należy wziąć pod uwagę przy określaniu sposobu otrzymywania podpisanego pliku PDF z programu Acrobat Sign w systemie zarządzania dokumentami.
Chociaż całkowicie dopuszczalne jest wybranie opcji Dokument podpisany w ramach umowy podczas tworzenia elementu webhook, można rozważyć użycie interfejsu API Acrobat Sign do pobierania dokumentów po otrzymaniu zdarzenia wyzwalającego (takiego jak status umowy Gotowa).
Kwestie, o których należy pamiętać...
Ograniczenie rozmiaru JSON
Rozmiar ładunku JSON jest ograniczony do 10 MB.
Jeśli zdarzenie wygeneruje większy ładunek, zostanie wywołany element webhook, ale atrybuty parametrów warunkowych, jeśli występują w żądaniu, zostaną usunięte, aby zmniejszyć rozmiar ładunku.
Wartość „ConditionalParametersTrimmed” zostanie zwrócona w odpowiedzi, gdy tak się stanie, aby poinformować klienta, że informacja conditionalParameters została usunięta.
„conditionalParametersTrimmed” to obiekt typu array zawierający informacje o kluczach, które zostały przycięte.
Obcięcie zostanie wykonane w następującej kolejności:
- includeSignedDocuments
- includeParticipantsInfo
- includeDocumentsInfo
- includeDetailedInfo
Najpierw zostaną skrócone podpisane dokumenty, następnie informacje o uczestniku, informacje o dokumencie, a na końcu informacje szczegółowe.
Może się to zdarzyć na przykład w przypadku zdarzenia zakończenia umowy, jeśli zawiera ono również podpisany dokument (zakodowany w standardzie base 64) lub w przypadku umowy zawierającej wiele pól formularza
Elementy webhook Acrobat Sign dostarczają powiadomienia do nadawcy umowy i wszelkie elementy webhook skonfigurowane w grupie, z której wysłano umowę. Elementy webhook w zakresie konta odbierają wszystkie zdarzenia.
Nadawca: Użytkownik A | Sygnatariusz: Użytkownik B | Osoba, której udostępniono: Użytkownik C
Użytkownik A i Użytkownik B są na różnych kontach
Użytkownik A i Użytkownik C są na różnych kontach
Przypadek użycia |
Zawiadomienie? |
Komentarze/uwagi |
Konto Użytkownika A ma element webhook na poziomie KONTO (utworzony przez Użytkownika A lub administratora konta). |
Tak |
Element webhook na poziomie KONTO jest powiadamiany o wszystkich zdarzeniach zainicjowanych na tym koncie. |
GRUPA A ma element webhook na poziomie KONTO (utworzony przez Użytkownika A lub administratora konta/grupy). Założenie: Użytkownik A i administrator grupy są w tej samej grupie. |
Tak |
Element webhook na poziomie GRUPA jest powiadamiany o wszystkich zdarzeniach zainicjowanych w tej grupie. |
Użytkownik A ma element webhook na poziomie UŻYTKOWNIK. |
Tak |
Jako nadawca, element webhook Użytkownika A na poziomie UŻYTKOWNIK jest zainicjowany. |
Użytkownik A ma element webhook poziomu ZASÓB (dla umowy wysłanej powyżej). |
Tak |
|
Konto Użytkownika B ma element webhook na poziomie KONTO (utworzony przez Użytkownika B lub administratora konta). |
Nie |
Element webhook Użytkownika B na poziomie KONTO jest uznawany za element webhook sygnatariusza. |
GRUPA B ma element webhook na poziomie KONTO (utworzony przez Użytkownika B lub administratora konta/grupy). Założenie: Użytkownik B i administrator grupy są w tej samej grupie. |
Nie |
Element webhook Użytkownika B na poziomie GRUPA jest uznawany za element webhook sygnatariusza. |
Użytkownik A ma element webhook na poziomie UŻYTKOWNIK. |
Nie |
Element webhook Użytkownika B na poziomie UŻYTKOWNIK jest uznawany za element webhook sygnatariusza. |
Konto Użytkownika C ma element webhook na poziomie KONTO (utworzony przez Użytkownika C lub administratora konta). |
Nie |
Element webhook Użytkownika C na poziomie KONTO jest uznawany za element webhook nienależący do autora. |
GRUPA C ma element webhook na poziomie KONTO (utworzony przez Użytkownika C lub administratora konta/grupy). Założenie: Użytkownik C i administrator grupy są w tej samej grupie. |
Nie |
Element webhook Użytkownika C na poziomie GRUPY jest uznawany za element webhook nienależący do autora. |
Użytkownik C ma element webhook na poziomie UŻYTKOWNIK. |
Nie |
Element webhook Użytkownika C na poziomie UŻYTKOWNIK jest uznawany za element webhook nienależący do autora. |
Nadawca: Użytkownik A | Sygnatariusz: Użytkownik B | Osoba, której udostępniono: Użytkownik C
Użytkownik A, Użytkownik B i Użytkownik C są na tym samym koncie.
Przypadek użycia |
Zawiadomienie? |
Uwagi |
Konto Użytkownika A ma element webhook na poziomie KONTO (utworzony przez Użytkownika A lub administratora konta). |
Tak |
Elementy webhook na poziomie KONTO powiadamiają o zdarzeniach zainicjowanych przez konto. |
GRUPA A ma element webhook na poziomie KONTO (utworzony przez Użytkownika A lub administratora konta/grupy). Założenie: Użytkownik A i administrator grupy są w tej samej grupie. |
Tak |
Elementy webhook na poziomie GRUPA powiadamiają o zdarzeniach zainicjowanych przez użytkowników w grupie. |
Użytkownik A ma element webhook na poziomie UŻYTKOWNIK. |
Tak |
Jako nadawca, element webhook Użytkownika A na poziomie Użytkownik jest zainicjowany. |
Użytkownik A ma element webhook poziomu ZASÓB (dla umowy wysłanej powyżej). |
Tak |
|
Konto Użytkownika B ma element webhook na poziomie KONTO (utworzony przez Użytkownika B lub administratora konta). |
Tak |
Ponieważ Użytkownik A i Użytkownik B są na tym samym koncie, element webhook na poziomie KONTO otrzymuje powiadomienia o wszystkich zdarzeniach zainicjowanych na tym koncie. |
GRUPA B ma element webhook na poziomie KONTO (utworzony przez Użytkownika B lub administratora konta/grupy). Założenie: Użytkownik A, Użytkownik B i administrator grupy są w tej samej grupie. |
Tak |
Ponieważ Użytkownik A i Użytkownik B są w tej samej grupie, element webhook na poziomie GRUPA otrzymuje powiadomienia o wszystkich zdarzeniach zainicjowanych w tej grupie. |
GRUPA B ma element webhook na poziomie KONTO (utworzony przez Użytkownika B lub administratora konta/grupy). Założenie: Użytkownik A i Użytkownik B są w różnych grupach. |
Nie |
Element webhook Użytkownika B na poziomie GRUPA jest uznawany za element webhook sygnatariusza. Element webhook Użytkownika A (ZASÓB/UŻYTKOWNIK/GRUPA/KONTO) zostanie zainicjowany. |
Użytkownik A ma element webhook na poziomie UŻYTKOWNIK. |
Nie |
Jako odbiorca, element webhook Użytkownika B na poziomie UŻYTKOWNIK nie jest zainicjowany. |
Konto Użytkownika C ma element webhook na poziomie KONTO (utworzony przez Użytkownika C lub administratora konta). |
Tak |
Ponieważ Użytkownik A i Użytkownik C są na tym samym koncie, element webhook na poziomie KONTO otrzymuje powiadomienia o wszystkich zdarzeniach zainicjowanych na tym koncie. |
GRUPA C ma element webhook na poziomie KONTO (utworzony przez Użytkownika C lub administratora konta/grupy). Założenie: Użytkownik A, Użytkownik C i administrator grupy są w tej samej grupie. |
Tak |
Ponieważ Użytkownik A i Użytkownik C są w tej samej grupie, element webhook na poziomie GRUPA otrzymuje powiadomienia o wszystkich zdarzeniach zainicjowanych w tej grupie. |
GRUPA C ma element webhook na poziomie KONTO (utworzony przez Użytkownika C lub administratora konta/grupy). Założenie: Użytkownik A i Użytkownik C w różnych grupach. |
Nie |
Element webhook Użytkownika C na poziomie GRUPY jest uznawany za element webhook nienależący do autora. Element webhook Użytkownika A (ZASÓB/UŻYTKOWNIK/GRUPA/KONTO) zostanie zainicjowany. |
Użytkownik C ma element webhook na poziomie UŻYTKOWNIK. |
Nie |
Element webhook Użytkownika C na poziomie UŻYTKOWNIK jest uznawany za element webhook nienależący do autora. |
Ponów próbę, gdy usługa nasłuchu nie działa
Jeśli docelowy adres URL elementu webhook nie działa z jakiegokolwiek powodu, usługa Acrobat Sign doda plik JSON do kolejki i ponowi próbę wypchnięcia w cyklu progresywnym przez 72 godziny.
Niedostarczone zdarzenia zostają utrwalone w kolejce ponownych prób i w ciągu następnych 72 godzin dokłada się wszelkich starań, aby dostarczyć powiadomienia w kolejności, w jakiej wystąpiły.
Strategia ponownych prób dostarczenia powiadomień polega na podwojeniu czasu między próbami, począwszy od 1-minutowego odstępu, który wzrasta do 12 godzin, co daje 15 ponownych prób w ciągu 72 godzin.
Jeśli odbiorca elementu webhook nie odpowie w ciągu 72 godzin, a w ciągu ostatnich siedmiu dni nie było żadnych udanych powiadomień, element webhook zostanie wyłączony. Na ten adres URL nie będą wysyłane żadne powiadomienia do czasu ponownego uaktywnienia elementu webhook.
Wszystkie powiadomienia od momentu wyłączenia elementu webhook do momentu jego ponownego włączenia zostaną utracone.
