Podpisywanie dokumentu usługą Autenti

WEBCON Redaktor Dodatki
Facebooktwitterpinterestlinkedinmail
Dotyczy wersji 2020.1.x i powyżej, autor: Piotr Dąbrowski

Wprowadzenie

W WEBCON BPS podpisy cyfrowe obsługiwane są poprzez dedykowane akcje (SDK – Software Development Kit).

Przygotowane zostały 4 dodatki pozwalające na integrację z zewnętrznymi dostawcami podpisów cyfrowych:

  1. AdobeSign
  2. Autenti
  3. DocuSign
  4. Skribble

W niniejszym artykule opisano proces podpisywania dokumentu za pośrednictwem firmy Autenti. Pokazano ponadto przykładowy obieg wraz ze skonfigurowaną akcją wysłania do podpisu oraz pobrania podpisanego dokumentu.

Opis procesu

Platforma Autenti udostępnia różne możliwości operowania procesowanym dokumentem, m.in.:

  1. tworzenie dokumentu w systemie
  2. załadowanie pliku z dokumentem do podpisu
  3. sprawdzenie statusu dokumentu
  4. wysłanie maila z linkiem do podpisu dokumentu
  5. dwuetapowa weryfikacja przy pomocy wiadomości SMS

Korzystając z powyższych metod, możliwa jest następująca komunikacja:

 

 

Rysunek 1. Schemat działania obiegu

 

W procesie będą zdefiniowane 3 akcje:

  1. wysłanie dokumentu do Autenti
  2. wysłanie żądania o zwrot dokumentu wraz ze statusem
  3. sprawdzenie statusu

Należy tu wspomnieć o sposobie weryfikacji użytkownika. W wyżej wymienionym scenariuszu wykorzystywane jest jedno konto systemowe Autenti, z którego wysyłane są dokumenty do podpisu. Osoba podpisująca nie musi posiadać konta Autenti ani licencji do platformy WEBOCN BPS.

Po wysłaniu akcja na timeout uruchomi automatyczne pobieranie dokumentu i sprawdzi jego status.

Przypadek biznesowy

Na potrzeby prezentacji zostanie wykorzystany prosty obieg:

Rysunek 2. Obieg podpisu

 

Na formularzu zdefiniowano pola niezbędne do wywołania akcji podpisu. Należy zwrócić uwagę na grupę „Atrybuty techniczne” – znajduje się tam pole techniczne, które stanowi integralną część opisywanego procesu.

  1. ID dokumentu zewnętrzne – jest to pole, w które zostanie wpisane ID dokumentu z bazy firmy Autenti

Ponadto należy przyjrzeć się typom utworzonych atrybutów, a szczególnie polu „Rola” w liście pozycji osób akceptujących. Pole to musi być polem wyboru zwracającym następujące dane (ważne są ID odpowiednich opcji):

Rysunek 3. Konfiguracja pola wyboru

 

W dokumentacji Autenti REST API można przeczytać, że poprawne zwrócenie przez system numeru GUID oznacza poprawne wczytanie dokumentu do wewnętrznej bazy firmy. System zablokuje zatem użytkownika po akcji wysłania dokumentu do podpisu, jeżeli nie otrzyma informacji zwrotnej o numerze dokumentu i nie wpisze go w zdefiniowane pole.

Formularz prezentuje się w następujący sposób:

Rysunek 4. Formularz wejściowy

 

Ścieżką „Generuj szablon” wygenerowano przykładowy dokument umowy. Dokument, który ma zostać przesłany do podpisu, powinien być w formacie PDF.

Należy zacząć od ustawienia połączenia REST z REST API Autenti.

 

Rysunek 5. Konfiguracja połączenia z API

 

Należy stworzyć połączenie typu „REST Web Service” i wybrać rodzaj autentykacji Salesforce. Następnie wprowadzić „Client ID” oraz „Client Secret”, korzystając z danych z konta Autenti. Adresy URL są aktualne na dzień 4.7.2022. Przy konfiguracji połączenia należy sprawdzić aktualną opublikowaną wersję Autenti oraz odpowiednio zmodyfikować podane w tym zrzucie ekranu adresy.

Następnie należy skonfigurować akcję wysłania dokumentu do podpisu. W przykładzie jest ona wywołana na kroku „Manager approval”. Na ścieżce przejścia „Approve” należy dodać automatyzację „Approve”, wewnątrz której znajdzie się akcja wywołania SDK.

 

Rysunek 6. Konfiguracja akcji wysłania dokumentu

 

Poniżej przedstawiono konfigurację kolejnych sekcji akcji:

 

Rysunek 7. Wybór załącznika

 

W tym polu należy stworzyć zapytanie SQL do tabeli WFDataAttachmets, które zwróci nam identyfikator załącznika przesyłanego do podpisu. W tym przypadku należy zawęzić wyszukiwanie do wyszukiwania za pomocą ID aktualnego elementu, sprawdzić, czy plik jest w kategorii „To be signed” (do podpisu) i upewnić się, czy nie został usunięty.

 

Rysunek 8. Konfiguracja autentykacji

 

W sekcji autentykacji należy wybrać utworzone wcześniej połączenie, ustawić parametr „grant_type” (typ autentykacji) na autentykację hasłem oraz określić „scope” (zakres), tzn. ustalić obszar, do którego dana aplikacja ma pełny dostęp.

 

Rysunek 9. Konfiguracja ciała zapytania

 

Następną sekcją jest „Request body”. W tym miejscu przekazywane są atrybuty określające tytuł oraz opis zapytania. W polu „Users” należy wybrać listę pozycji, z której akcja ma pobierać dane:

  1. Name – imię i nazwisko osoby podpisującej
  2. E-mail – adres e-mail, na który ma zostać wysłany mail z linkiem do podpisu dokumentu
  3. Phone Number – pole opcjonalne, które można wykorzystać do dodatkowej autentykacji za pomocą SMS. W takim przypadku na podany w tym miejscu numer zostanie wysłana wiadomość

Ostatni krok to wybór „Signature Type”, czyli rodzaju podpisu:

  1. ESIGNATURE – standardowy podpis elektroniczny
  2. QUALIFIED_ESIGNATURE – podpis kwalifikowany

Należy tutaj wspomnieć o dwóch rodzajach ról, jakie mogą być przypisane:

  1. Viewer – tylko osoby zdefiniowane na liście muszą podpisać dokument
  2. Signer – osoby zdefiniowane na liście oraz osoba wysyłająca muszą podpisać dokument

Ostatnią sekcją do skonfigurowania jest „Konfiguracja dodatku”:

 

Rysunek 10. Konfiguracja dodatku

 

W tym przypadku do pierwszego pola można przekleić konfigurację dostępną po kliknięciu w pomoc kontekstową. Natomiast w polu „Returned id of document” należy wskazać utworzone przez użytkownika pole technicznie, w którym będzie przechowywane zewnętrzne ID dokumentu.

Po poprawnym skonfigurowaniu akcji można przejść do Portalu i przetestować rozwiązanie. W tym celu należy przejść ścieżką do etapu akceptacji przełożonego.

 

Rysunek 11. Okno formularza w kroku „Prepare document”

 

Rysunek 12. Formularz w kroku „Manager approval”

 

Po zatwierdzeniu przez przełożonego dokument zostanie wysłany do podpisu przez wskazane osoby. Otrzymają one następujący e-mail:

 

Rysunek 13. Treść maila od firmy Autenti

 

Pod napisem „Zobacz Dokument” kryje się hiperłącze z dokumentem użytkownika do podpisania. Po kliknięciu następuje przekierowanie na stronę producenta, gdzie należy zaznaczyć pole potwierdzające znajomość treści dokumentu, a następnie nacisnąć przycisk „Podpisz”.

 

Rysunek 14. Dokument do podpisu

 

Po kliknięciu wyświetlana jest informacja o obiegu podpisu użytkownika:

 

Rysunek 15. Ekran podpisanego dokumentu

 

Do osób podpisujących wysłane zostanie potwierdzenie o zakończeniu podpisu dokumentu wraz z kopią podpisanej umowy:

 

Rysunek 16. Mail zwrotny

 

Jeżeli dokument podpisano poprawnie, przypięte powinny być do niego certyfikat i pieczęć zaświadczające o autentyczności podpisu:

 

Rysunek 17. Certyfikat podpisu firmy Autenti

 

Po zatwierdzeniu i złożeniu podpisu przedmiotowy dokument zostanie przekazany do kroku „Awaiting for E-Signatures”. Należy skonfigurować akcję pobierającą dokument wraz z jego statusem, aby zakończyć proces. Na ścieżce „Get documents” należy dodać automatyzację z akcją pobrania podpisanego pliku:

 

Rysunek 18. Konfiguracja akcji pobrania dokumentu

 

Większość konfiguracji odbywa się analogicznie do akcji wysyłania dokumentu. W polu „Copy Status to field” należy wskazać do jakiego atrybutu trafi pobrany przez użytkownika status – ułatwi to ustawianie warunku w dalszym kroku warunkowym. Pole „Category” to kategoria, do jakiej trafi pobrany dokument – w opisywanym przypadku będzie to „Podpisano”.

Następnie następuje konfiguracja kroku warunkowego „Signed?”, do którego prowadzi ścieżka „Get documents”:

 

Rysunek 19. Konfiguracja kroku warunkowego „Signed?”

 

Jeśli w atrybut „Document status” akcja pobrania wpisze wartość „COMPLETED”, element zostanie przekazany do kroku końcowego. W przeciwnym wypadku powróci do „Awaiting for E-Signatures”. System może zwrócić 5 różnych statusów:

  1. PROCESSING – nie podjęto jeszcze wszystkich decyzji
  2. SUCCESS – wszyscy podpisali dokument
  3. FAILED – przynajmniej jeden podpisujący odmówił podpisania
  4. WITHDRAWN – dokument został wycofany
  5. ERROR – błąd operacji

Pozostaje jeszcze skonfigurować funkcję timeout (przekroczenie czasu) w kroku „Awaiting for E-Signatures”, która co godzinę będzie sprawdzała, czy dokument został już podpisany:

 

Rysunek 20. Konfiguracja funkcji timeout

 

Tryb działania należy ustawić na „Przejście ścieżką po wywołaniu akcji”. Ponieważ nie jest definiowana żadna akcja do wykonania, opisywana funkcja timeout będzie co godzinę próbowała przejść do następnego kroku.

 

Po poprawnym wykonaniu akcji powinien być widoczny następujący ekran:

 

Rysunek 21. Ekran końcowy

 

Jak widać przedmiotowy element trafił do kroku końcowego, a do kategorii „Podpisano” dodano podpisany dokument.

Podsumowanie

Zaprezentowany powyżej obieg jest tylko przykładem zastosowania dodatku WEBCON BPS do integracji z Autenti. Dodatek ten, po drobnych modyfikacjach, może zostać dodany do dowolnego obiegu.

Kod źródłowy dodatków można znaleźć na naszym koncie Github pod adresem: https://github.com/WEBCON-BPS.

Udostępniamy je na tej licencji.