Proces dla e-deklaracji – czyli pytanie z odpowiedzią

Rozliczyłaś/eś już pit? Rozliczasz się razem czy osobno? Czy są jakieś ulgi? Czy będzie zwrot czy kwota do zapłaty? Do kiedy dokładnie jest termin? Gdzie jest mój urząd? Czy rozliczasz się elektronicznie? Te i wiele pytań pojawia się obecnie w naszych rozmowach. Przyczyna jest prosta. Już niedługo kończy się termin, kiedy można składać roczne deklaracje podatkowe.

Wielu podatników zdecyduje się po raz pierwszy lub kolejny złożyć swoją deklarację elektronicznie. W tym celu skorzysta z aplikacji w przeglądarce lub pobranej na komputer, wypełni dane, a następnie wybierze “Złóż deklarację”. Na koniec będzie czekać na otrzymanie tzw. UPO, czyli potwierdzenia złożenia deklaracji. W zależności od podsumowania na deklaracji, będzie musiał zapłacić brakującą kwotę podatku lub czekać na zwrot nadpłaty. Wariant takiego procesu opisany jest na poniższym diagramie.

pit450px

Na diagramie, jak widać, proces został przedstawiony od strony aplikacji. Dodany został na nim również krok dot. komunikacji z serwisem ministerstwa, obsługującym elektroniczne składanie deklaracji. Jest też krok weryfikacyjny, który w takich aplikacjach występuje – dotyczący dochodu za rok poprzedzający rok, którego dotyczy składana deklaracja. Aplikacja przygotowuje komunikat z deklaracją (prawdopodobnie w xml) i wysyła żądanie (ang. request) jej przetworzenia przez serwis. Następnie czeka na odpowiedź (ang. response). Odpowiedź może wskazywać na przyjęcie deklaracji, poprawne jej przetworzenie czy błąd. Można powiedzieć, że jest to przykład zastosowania wzorca Pytanie-Odpowiedź (ang. request-response).

Aplikacja może prowadzić użytkownika przez wypełnienie deklaracji, sugerując ekranami lub pytaniami konkretne czynności lub też umożliwiać całkowicie samodzielne wypełnienie formularzy, podobnie jak w przypadku papierowej deklaracji. W trakcie wypełniania, może jedynie sprawdzać powiązania oraz zależności pól, a sprawdzanie konkretnych wartości jest dość ograniczone. Wypełnienie takiej deklaracji, mając pod ręką materiały źródłowe, trwa kilkanaście minut. Oczekiwanie na odpowiedź z serwisu to kilka minut. Można to zrobić w dowolnym, odpowiednim dla podatnika momencie. Nie musi także udawać się do urzędu, aby przekazać deklarację papierową.

Rezydent nie jedno ma „imię”

Dzisiaj będzie wpis nadal w tematyce wakacyjnej. W czasie wykupionych wyjazdów za granicę, funkcjonuje w miejscu docelowym „instytucja” tzw. rezydenta. Rezydent opiekuje się grupą gości z danego biura podróży zakwaterowanych w określonym hotelu. Przybliża miejsce wypoczynku, hotel, informuje o ubezpieczeniu, postępowaniu w nagłych wypadkach. Przedstawia także wycieczki fakultatywne, z cenami, zasadami itp.

Chciałbym jednak zwrócić na jedną istotną funkcję Rezydenta, która przypomina w pewnych sytuacjach działanie wzorca Pełnomocnika a w innych sytuacjach – „Request- Response” lub „Fire and Forget”. Poniżej zostały przytoczone 3 przykładowe sytuacje, które w uproszczony sposób prezentują zależności w poszczególnych wzorcach.

BL_BLProcess_2015-06-01 1006

Powyższy diagram prezentuje potencjalny sposób postępowania pośrednika w tych różnych sytuacjach. Ma charakter poglądowy obrazujący ideę danego wzorca.

Sytuacja 1: Gość zwraca się do Rezydenta z prośbą o rezerwację samochodu, w ramach oferty, którą przedstawił. Rezydent wykonuje telefon, przekazuje pytania firmy, pozyskuje odpowiedzi Gościa i ostatecznie rezerwuje samochód. Potem daje potwierdzenie, z którym należy udać się do punktu, podpisać umowę i dokończyć transakcję. Jest to typowe dla wzorca projektowego „Pełnomocnik”, gdzie pośrednik przekazuje żądania po inicjatora do wykonawcy.

Sytuacja 2: Gość zwraca się do Rezydenta z prośbą o pomoc przy zmianie pokoju/hotelu, z określonej przyczyny. Kieruje się z Gościem do Recepcji, wyjaśnia i czeka na zakończenie sprawy, ponieważ mogą pojawić się kolejne kwestie wymagające udziału Rezydenta. Takie zachowanie jest typowe dla wzorca „Request-Response”, gdzie pośrednik czeka na wykonanie procesu.

Sytuacja 3: Gość zwraca się do Rezydenta z pytaniem o miejsce, gdzie można pozyskać pomoc medyczną. Rezydent wskazuje, gdzie trzeba zadzwonić i na jaki numer i zapewnia, że obsługa jest w języku ojczystym Gościa. Przekazuje dalsze wykonanie do Gościa. Jest to można powiedzieć przykład wzorca „Fire and Forget”.

Każda osoba, która miała styczność z „instytucją” tzw. Rezydenta pewnie mogłaby podać kolejne przykłady i przypadki.

Znajomy błąd pełnomocnika

Siedzisz przed monitorem, uruchamiasz przeglądarkę i wpisujesz adres strony internetowej, klikasz enter i zamiast oczekiwanej zawartości strony pojawia się błąd:

„Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.
Reason: Error reading from remote server”

Brzmi znajomo? Myślę, że tak. Patrząc na stopień wykorzystania Internetu, połączeń i komunikacji elektronicznej taki błąd może się zdarzyć zawsze. Może to być podczas przeglądania Intranetu na domowym komputerze czy podczas szukania informacji w sieci wewnętrznej, mającej połączenie z Internetem.

Przyczyny błędu mogą być różne i na różnym etapie mogą nastapić – na serwerze sieci na przykład lokalnego dostawcy internetu, na serwerze firmy, który próbuje się dostać do danych wewnątrz, na serwerze obsługującym połączenia między siecią wewnętrzną a Internetem.

Cechą wspólną tych sytuacji jest to, że do pewnego serwera wysyłane jest żądanie, które on próbuje obsłużyć. A następnie ma miejsce komunikacja w drugą stronę. Poniższy przykładowy diagram przedstawia taką sytuację.

Diagram obrazuje także ideę wzorca projektowego Pełnomocnik (ang. proxy), który opiera się na założeniu, że między klientem a rzeczywistym obiektem znajduje się pełnomocnik. Pełnomocnik ten decyduje o udostępnieniu rzeczywistego obiektu (kontroluje dostęp do niego). Może mieć też charakter zabezpieczający, co jak najbardziej można sobie wyobrazić również w powyższych przykładach.

Nazwa „proxy”, pojawiająca się w powyższym komunikacie błędu, nie jest przypadkowa. Serwer zwracający ten błąd wskazuje o braku możliwości realizacji żądania albo o niedostępności rzeczywistego obiektu. Jest pełnomocnikiem zasobów dostępnych na danym serwerze lub w połączonej sieci.

Specjalistyczny pośrednik

Ponad roku, przy okazji omawiania wzorców „Fire and Forget” oraz „Request-Response posłużyłem się przykładem procesu ETL. Jednym z etapów realizacji tego procesu, jest wyciąganie (ang. Extract) danych. Wskazałem przykład zastosowania wzorca „Request-Response” (Pytanie – Odpowiedź) oparty na odpytywaniu bazy danych (dokładnie DBMS, tj. Systemu Zarządzania Bazą Danych) o dane/informacje/status i zwracanie przez nią stosownej informacji. Były to sprawdzenie dostępności bazy (DB), pytanie o wielkość danych (WD) i pobieranie kolejnych rekordów danych (DZ – dane zapytania). Takie działania mogą się odbywać poprzez bezpośrednie zapytania w języku SQL. Fragment oznaczony jako „bez wzorca” na diagramie poniżej przedstawia takie bezpośrednie odpytania.

Załóżmy jednak, że mamy odbytać kilka baz i powiązać dane ze sobą. Chcielibyśmy równocześnie uniknąć sytuacji namierzania się na każdą bazę osobno, identyfikowania jej strukury, a chcielibyśmy przekazać żądanie: sprawdź, pobierz, zapytaj. W takiej sytuacji między procesem Extract a poszczególnymi bazami danych można umieścić narzędzie pośredniczące, które wykona określone operacje i odpowiednio rozdzieli zadania po DBMS poszczególnych baz źródłowych.

W takim celu można zastosować wzorzec projektowy Fasada (ang. Facade), który zmniejszy liczbę połączeń i zależności między systemami. Wiąże się to utworzeniem „pośrednika” przyjmującego żądania i wysyłającego je do odpowiednich wykonawców. Sytuację taką prezentuje powyższy diagram w BMPN w części „wzorzec”.

Zaletą jest to, że mamy jeden interfejs, który można wykorzystać w różnych procesach, bez konieczności ingerowania w systemy źródłowe. Modyfikując połączenie między pośrednikiem a bazą (np. przeniesienie w inne miejsce, inna konfiguracja, sposób zapytania) modyfikujemy je tylko w jednym miejscu, bez konieczności zmiany procesów wywołujących. Takie rozwiązania są stosowane w implementacji systemów opartych o usługi (SOA).

Inicjowanie – „Zapomnij” lub „Poczekaj”

Załóżmy, że w systemie cyklicznie jest uruchamiany określonego dnia i godziny proces ładowania danych z systemów dla Hurtowni Danych. W mechanizmie inicjowanym o określonej porze (tzw. Scheduler) następuje weryfikacja, czy są do wykonania procesy ładowania danych. Jeżeli taki proces istnieje, jest uruchamiany. Poniższy diagram w BPMN przedstawia sytuację, gdy następuje uruchomienie procesu ETL (ang. Extract, Transform, Load) pobierającego dane z bazy danych i po przetworzeniu umieszczającego je w Hurtowni danych. Proces ETL składa się z 3 etapów – Pobierania danych (ang. Extract), Przetwarzania (ang. Transform) oraz Ładowania (ang. Load) do Hurtowni. W każdym z tych etapów są wykonywane zaplanowane czynności. Dla przykładu przedstawiono kilka kroków z procesu Pobierania danych.

Wróćmy jednak do tytułu – „Zapomnij” lub „Poczekaj”. Tytuł sygnalizuje dwa wzorce postępowania możliwe do wykorzystania w ramach procesów i realizowanych czynności w ramach procesu. Zapomnij wskazuje na wzorzec Fire and Forget (Strzel/Uruchom i Zapomnij), który oznacza, że proces inicjujący działanie lub inny proces nie czeka na jego zakończenie, wynik działania. Z kolei Poczekaj wskazuje na inny wzorze – Request-Response (Zażądaj Odpowiedzi), który polega na oczekiwaniu na odpowiedź z wykonania procesu, czynności, czy usługi. Obydwa wzorce są wykorzystywane w systemach informatycznych. Pierwszy z nich, jest specyficzny dla długich procesów, związanych z przetwarzaniem danych, z czasami nieokreślonym czasem trwania i niemożliwym wręcz do zdefiniowania tzw. timeoutem.

Na powyższym diagramie komunikat „Uruchom proces ETL” jest odpalany bez oczekiwania na odpowiedź przez Harmonogram. Drugi ze wzorców został natomiast zasygnalizowany poprzez komunikaty „Q” i „A” przy poszczególnych krokach procesu Extract. Jest on specyficzny dla czynności, dla których musi wrócić odpowiedź do inicjatora – odpytanie o dostępność („DB”), odpytanie o wielkość („WD”) oraz odpytanie o dane („DZ”). Z czynnościami opartymi o wzorzec Request-Response jest silnie związania obsługa błędów oraz statusów.