Dotyczy wersji 2020.1.3.x; autor: Franciszek Sakławski

Wstęp

W wersji 2020 rozszerzona została obsługa podpisów cyfrowych poprzez przygotowanie dodatków (SDK) umożliwiających cyfrowe podpisanie dokumentów. Dzięki temu możemy wykonać go całkowicie zdalnie w dowolnym miejscu i porze.

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 skupię się na procesie podpisania dokumentu przy pomocy oprogramowania firmy Autenti. Pokażę jak poprawnie stworzyć obieg oraz skonfigurować akcję podpisywania.

Opis procesu

Producent na swojej stronie udostępnia następujący graf:

Rysunek 1 Autenti API Workflow

Oprogramowanie firmy Autenti udostępnia różne możliwości operowania procesowanym dokumentem.

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

Wszystkie wyżej wymienione akcje są do wykorzystania w nowym dodatku SDK (Software development kit) obsługującym oprogramowanie firmy Autenti.

Wykorzystując powyższy diagram stworzyliśmy scenariusz naszego obiegu. Prezentuje się on w następujący sposób:

 

Rysunek 2 Schemat działania obiegu

Jak widać na załączonym grafie w naszym procesie będą zdefiniowane 4 akcje:

1. Wysłanie dokumentu do Autenti
2. Wysłanie żądania o zwrot statusu dokumentu
3. Sprawdzenie statusu
4. Wysłanie żądania o podpisany dokument

Należy tu wspomnieć o sposobie weryfikacji użytkownika. W wyżej wymienionym scenariuszu to my (wysyłający umowę do podpisu) jesteśmy zarejestrowanym użytkownikiem oprogramowania firmy Autenti. Osoba podpisująca nie musi się nigdzie rejestrować. Podpis taki jest objęty certyfikatem Autenti, który zapewnia (za artykułem na stronie producenta):

1. Autentyczność pochodzenia dokumentu – dokument został utworzony i podpisany na platformie Autenti
2. Integralność dokumentu – wszyscy zainteresowani podpisali ten sam dokument

Certyfikat Autenti dodatkowo zawiera informacje o całym procesie podpisywania dokumentu – kto złożył e-podpis, kiedy i jak została zweryfikowana tożsamość podpisującego.

Jeżeli osoba podpisująca chciałaby mieć możliwość wysyłania do podpisu dokumentów musi uzyskać klucz weryfikujący, który pozwoli na korzystanie z Autenti REST API – więcej informacji można uzyskać na stronie producenta pod adresem: https://autenti.com/

Wykorzystując powyższe, zarejestrujemy umowę zlecenie, a następnie wyślemy ją do podpisu. Po wysłaniu będziemy mogli sprawdzić czy nowy pracownik podpisał umowę, poprzez przycisk na górnej belce formularza. Jeżeli tak, system pobierze podpisany dokument i zakończy obieg.

Przejdźmy więc do programu WEBCON BPS Designer Studio w celu konfiguracji obiegu.

Przypadek biznesowy

Na potrzeby prezentacji, wraz z zespołem, stworzyliśmy prosty obieg bazujący na scenariuszu opisanym w poprzednim rozdziale:

Rysunek 3 Obieg podpisu

Na formularzu zdefiniowaliśmy pola niezbędne do poprawnego działania obiegu. Należy zwrócić uwagę na grupę: „Atrybuty techniczne”, którą widać jedynie w trybie Admin. Znajdują się tam 2 pola techniczne, które stanowią integralną część naszego procesu

1. ID dokumentu zewnętrzne – jest to pole w które wpisze się ID dokumentu z bazy firmy Autenti.

W dokumentacji Autenti REST API możemy przeczytać, iż poprawne zwrócenie przez system numeru GUID oznacza poprawne zaczytanie dokumentu do wewnętrznej bazy firmy.

System więc zablokuje nas po akcji wysłania dokumentu do podpisu, jeżeli nie otrzyma zwrotnej informacji o numerze dokumentu i nie wpisze go w zdefiniowane pole.

2. ID źródłowe załącznika – pole w które wpisuje się ID załącznika – z naszej wewnętrznej bazy

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

Rysunek 4 Formularz wejściowy

Możemy więc przejść do konfiguracji akcji wysłania dokumentu do podpisu. W tym celu udajmy się do okna konfiguracji akcji na kroku „Przygotowanie umowy”. Na ścieżce przejścia ”Prześlij do podpisu” dodajmy akcję „Wyślij do podpisu”.

Należy wspomnieć iż akcje te przygotowane zostały jako dodatki SDK (Software development kit) do platformy WEBCON BPS – nie są one częścią oficjalnego oprogramowania, lecz dedykowanym dodatkiem umożliwiającym, w naszym przypadku, podpisanie dokumentu.

Rysunek 5 Konfiguracja akcji "Wyślij do podpisu"

Okno konfiguracji akcji SDK posiada więcej opcji do uzupełnienia niż standardowa akcja. Pola jednak są opisane w bardzo przystępny i zrozumiały sposób, dlatego skupię się na wytłumaczeniu pól które mogą rodzić niejasności.

Rysunek 6 Klucz do autentyfikacji

Klucz integracyjny, o którym pisałem we wcześniejszej części artykułu, jest używany w każdej akcji wywołującej Autenti REST API. Z tego powodu dobrą praktyką byłoby zapisanie go w bezpiecznym, lecz dostępnym miejscu. Miejscem stworzonym do przechowywania tego typu danych są stałe procesu. Więcej o przechowywaniu danych w programie WEBCON BPS Designer Studio można przeczytać w już opublikowanym artykule pod adresem: https://kb.webcon.pl/stale-globalne-i-stale-procesowe/

W następnej sekcji konfigurujemy który załącznik ma być podpisany:

Rysunek 7 Konfiguracja akcji wysyłania dokumentu

W pierwszym polu określamy na jakiej zasadzie chcemy wybrać załącznik do podpisu. Mamy 2 opcję:

1. Na podstawie kategorii dokumentu (lub jej braku)
2. Na podstawie zapytania SQL

Jeżeli wybraliśmy opcję po kategorii dokumentu w kolejnych 2 polach możemy ustalić która kategoria ma być wybrana. Dodatkowo możemy zastosować wyrażenia Regex – do ograniczenia wyszukiwania po nazwie załącznika.

Jeżeli jednak wybraliśmy wyszukiwanie po zapytaniu SQL. Musimy stworzyć zapytanie które będzie zwracało Att_ID danego załącznika z tabeli WFDataAttachments.

Po więcej informacji na temat dodawania i zarządzania załącznikami odsyłam do naszej bazy wiedzy: https://kb.webcon.pl/

Dwa ostatnie pola tej sekcji są niezwykle ważne. To właśnie w nich będziemy wybierać nasze, wcześniej już opisane, pola techniczne. W pierwszym polu: „Copy source attachment ID” wybieramy techniczne – „ID źródłowe załącznika”. Drugim polem jest „Copy sent Document ID to field” – wybieramy pole „ID dokumentu zewnętrzne”.

Następną sekcją jest „Message content”:

W polach „Subject” oraz „Content” wybieramy nasze pola z formularza. Najważniejszym jednak polem, z konfiguracyjnego punktu widzenia, jest „Sender details”. Określa ono, czy osoba wysyłająca pismo również musi podpisać dokument. Do wyboru mamy 2 opcje:

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.

W naszym przypadku zostawiamy opcję Viewer.

Następną sekcją jest „Recipients selection”:

Rysunek 8  Konfiguracja akcji wysyłania dokumentu

W „Signers Item List” wybieramy listę pozycji, z których pól SDK ma czerpać dane:

1. Name – Imię i nazwisko osoby podpisującej
2. E-mail – adres email na który ma zostać wysłany mail z linkiem do podpisu dokumentu
3. Phone Number – na numer zdefiniowany w tym polu zostanie wysłane potwierdzenie z kodem SMS – o ile zaznaczymy opcję poniżej „Additional SMS verification”

O ile pole „Additional SMS verification” tłumaczy się samo to należy pamiętać, iż gdy zaznaczymy to pole musimy również ustawić wymagalność na kolumnie z numerem telefonu. W przeciwnym razie podczas próby wykonania akcji i niewypełnieniu pola z numerem, system poinformuje nas o błędzie.

Ostatnim polem jest „Signature Type”. Wybrać możemy spośród dwóch opcji:

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

Jest to bardzo ważne ze względu na różnicę prawną pomiędzy tymi dwoma rodzajami podpisu. Wypiszę pokrótce główne przewagi podpisu kwalifikowanego:

1. Wymaga osobistej weryfikacji tożsamości – notarialne lub urzędowe
2. Certyfikat musi być przechowywany na bezpiecznym urządzeniu i musi być chroniony PINem – Nie ma możliwości wyeksportowania go poza urządzenie
3. Jest równoważny podpisowi ręcznemu – może pełnić rolę dowodową w sądzie
4. Weryfikuje się automatycznie – w programach do odczytu PDF widać, że certyfikat jest ważny.

Po poprawnym skonfigurowaniu akcji, możemy przejść do Portalu i przetestować rozwiązanie. W tym celu przejdźmy ścieżką na której zamieszczona jest akcja podpisu – „Prześlij do podpisu”

Rysunek 9 Formularz dokumentu

Po wciśnięciu, system przeniósł nas do następnego kroku. Dodatkowo dostałem maila z prośbą o akceptację dokumentu:

Rysunek 10 Treść maila od firmy Autenti

Wciskamy napis „Dokument” pod którym kryje się hiperłącze z naszym dokumentem do podpisania. System przekierował nas na stronę producenta. Teraz musimy zaznaczyć zgodę, iż wiemy co się znajduje w dokumencie a następnie wciskamy przycisk „Rozpocznij podpisywanie”.

Rysunek 11 Dokument do podpisu

Po wciśnięciu, system przeszedł do kolejnego ekranu. Jako, że zaznaczyliśmy w konfiguracji weryfikację SMSem, musimy wpisać kod który otrzymamy na podany na formularzu numer. SMS z kodem prezentuje się w taki sposób:

Rysunek 12 SMS z kodem

Kod przepisujemy a następnie wciskamy przycisk „Podpisz dokument”:

Rysunek 13 Ekran podpisu dokumentu

Po poprawnym podpisaniu dokumentu system nas o tym poinformuje:

Rysunek 14 Ekran podpisanego dokumentu

Dodatkowo na mój adres email zostało wysłane powiadomienie z załączonym podpisanym dokumentem oraz linkiem do strony dokumentu.

Rysunek 15 Mail z podpisanym dokumentem

Gdy dokument został poprawnie podpisany, powinien być do niego przypięty certyfikat i pieczęć zaświadczające o autentyczności podpisu. Otwórzmy więc dokument i sprawdźmy:

Rysunek 16 Certyfikat podpisu firmy Autenti

 

Nasz dokument zatrzymał się w kroku „Oczekiwanie na podpis”. Zdefiniowaliśmy akcję pozwalającą na sprawdzenie statusu naszego dokumentu.

Przyjrzyjmy się więc konfiguracji akcji pobrania statusu:

Rysunek 17 Konfiguracja akcji pobrania statusu dokumentu

W sekcji „Konfiguracja dodatku” wybieramy pole przechowujące numer GUID naszego dokumentu a w polu „Copy Status to field” wybieramy pole w które wpisać ma się status. System może nam zwrócić 5 różnych statusów:

1. PROCESSING – Nie wszystkie decyzje zostały podjęte
2. SUCCESS – Wszyscy podpisali dokument
3. FAILED – Przynajmniej jeden podpisujący odmówił podpisania
4. WITHDRAWN – Dokument został wycofany
5. ERROR – Błąd operacji

Jeżeli system zwróci SUCCESS kolejna akcja przeniesie nas z kroku „Oczekiwanie na podpis” ścieżką „Podpisano”.

Rysunek 18 Status dokumentu

Jak widać w pole „Status podpisu” wpisał się status „SUCCESS” co oznacza poprawne podpisanie dokumentu.

Na ścieżce „Podpisano” wykonywana jest akcja SDK „Pobierz podpisany dokument”. Przejdźmy więc do WEBCON BPS Designer Studio w celu sprawdzenia konfiguracji:

Rysunek 19 Konfiguracja akcji pobrania dokumentu

Pola z konfiguracji pokrywają się z polami z poprzednich akcji oprócz dwóch pól „Category” oraz „Suffix”.

Pole „Category” definiuje kategorię dokumentu która zostanie przypisana pobranemu, podpisanemu dokumentowi. Pole „Suffix” określa sufiks(przyrostek) który zostanie dodany do nazwy podpisanego dokumentu.

Jak widzimy, dokument został poprawnie pobrany.

Rysunek 20 Formularz z podpisanym dokumentem

Podsumowanie

Zaprezentowany powyżej obieg jest tylko przykładem zastosowania nowych dodatków (SDK) do WEBCON BPS. Jednakże dodatki te, po drobnych modyfikacjach, mogą zostać dodane do dowolnego obiegu.

Kod źródłowy dodatków można znaleźć na naszym koncie Github pod adresem: https://github.com/WEBCON-BPS. Przedstawione dodatki są tylko przykładami użycia pluginów SDK. Udostępniamy je na tej licencji.

Przypisy:
https://autenti.com/api/

https://autenti.com/category/blog/