Załącznik nr 1.3. Opis Przedmiotu Zamówienia (część 3) Moduł Komunikacyjny

Transkrypt

1 Załącznik nr 1.3 do SIWZ Załącznik nr 1.3 Opis Przedmiotu Zamówienia (część 3) Moduł Komunikacyjny Strona 1 z 13

2 1 Opis przedmiotu zamówienia Przedmiotem zamówienia jest dostosowanie systemów EZD u Partnerów Projektu wyszczególnionych w załączniku nr 2 do OPZ poprzez: 1.1 Stworzenie Modułu Komunikacyjnego (MK) po stronie systemu EZD, opisanego w załączniku nr 2 do OPZ, do komunikacji z Regionalną Platformą Usług Publicznych (RPUP), realizowaną w ramach Projektu Wrota Lubelszczyzny Informatyzacja Administracji. 1.2 Konfiguracja systemu EZD do współpracy z MK. 1.3 Wdrożenie skonfigurowanego systemu EZD wraz z MK w jednostkach Partnerów projektu oraz przeszkolenie pracowników tych jednostek. Lista jednostek wymieniona jest w załączniku nr 2 do OPZ. 1.4 Udzielenie gwarancji i rękojmi. 2 Słownik pojęć Nazwa Opis HSM Sprzętowy moduł bezpieczeństwa (kryptograficzne). Urządzenie przeznaczone do przechowywania i zarządzania kluczami kryptograficznymi w infrastrukturze klucza publicznego (PKI). Wykorzystywane podczas generowania Urzędowego Poświadczenia Odbioru w komponencie Elektronicznej Skrzynki Podawczej. Otago ESB Aplikacja autorstwa firmy Otago, oparta na silniku JBoss ESB, spełniająca wymagania narzucone na komponent Regionalnej Szyny Usług. Regionalna Nazwa stosowana dla całości systemu realizowanego w ramach projektu Platforma Usług Wrota Lubelszczyzny - Informatyzacja Administracji. Publicznych (RPUP) Regionalna Komponent, którego zadaniem jest przekazywanie danych między Szyna Usług komponentami i aplikacjami wchodzącymi w skład całości systemu oraz (RSU) przechowywanie i udostępnianie danych o statusach np. wpływających dokumentów. Dodatkowo, komponent pełni rolę repozytorium danych dotyczących komunikacji poszczególnych modułów systemu, a także integracji tych modułów z systemami zewnętrznymi oraz usługami uruchomionymi na platformie epuap. W skład komponentu Regionalnej Szyny Usług wchodzą moduły Centralnej Szyny Usług (moduł instalowany w Centrum Przetwarzania danych, uruchomionym u Zamawiającego) oraz moduł Lokalnej Szyny Usług (instalowany u kilkudziesięciu partnerów projektu). Konto interesanta Funkcjonalność Lubelskiego Internetowego Biura Obsługi Interesanta umożliwiająca poszczególnym interesantom na śledzenie korespondencji przez nich realizowanej w kontaktach z jednostkami będącymi partnerami projektu Wrota Lubelszczyzny Informatyzacja Administracji. Umożliwia, między innymi podgląd pism i wniosków wysłanych przez interesanta, podgląd pism wysłanych przez poszczególne jednostki samorządu terytorialnego, a także podgląd stanu płatności (w tym Skrzynka podawcza elektronicznych) dla poszczególnych spraw. Komponent realizujący funkcjonalność zgodną z założeniami Ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne Strona 2 z 13

3 Elektroniczne Zarządzanie Dokumentacją (EZD) Moduł RESP Moduł Komunikacyjny (MK) Zamawiający Wykonawca w zakresie elektronicznej skrzynki podawczej oraz zapewniający interfejs i usługi sieciowe, umożliwiające odbieranie dokumentów dostarczanych do danego partnera Projektu, a także umożliwiający przesyłanie dokumentów pomiędzy poszczególnymi partnerami Projektu. Narzędzie teleinformatyczne, służące do elektronicznego zarządzania dokumentacją oraz umożliwiające wykonywanie w nim czynności kancelaryjnych, dokumentowanie przebiegu załatwiania spraw oraz gromadzenie i tworzenie dokumentów elektronicznych zgodnie z rozporządzeniem Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U nr 14 poz. 67). Moduł Regionalna Elektroniczna Skrzynka Podawcza jest jednym z podstawowych Modułów RPUP, stanowiącym platformę realizacji usług publicznych w części dotyczącej bezpośredniej obsługi interesantów (Portal Dostępowy, komponent Lubelskie Internetowe Biuro Obsługi Interesanta) oraz w części realizującej funkcjonalność elektronicznej skrzynki podawczej, w rozumieniu Ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne. Moduł Komunikacyjny będący przedmiotem zamówienia. Województwo Lubelskie. Zwycięzca postępowania na stworzenie Modułu Komunikacyjnego, z którym zostanie podpisana umowa. 3 Wymagania funkcjonalne Moduł komunikacyjny systemu EZD i EZD wraz z Modułem Regionalnej Elektronicznej Skrzynki Podawczej (RESP) umożliwiać mają realizację następujących funkcjonalności: 3.1 Odbieranie przez Aplikację EZD powiadomień składanych przez interesantów oraz powiadomień o dokonanych płatnościach za pośrednictwem Modułu RESP (funkcjonalność automatyczna. Możliwość ręcznego obioru powiadomień). Częstość odświeżania będzie ustalone w pliku konfiguracji (domyślna częstość wskaże Zamawiający). Wymaganie do realizacji w etapie IV. 3.2 Wysyłanie z poziomu Aplikacji EZD pism do interesantów na ich indywidualne konta w ramach Modułu RESP (funkcjonalność ręczna). 3.3 Uzupełnianie dokumentów w Aplikacji EZD o poświadczenie nadania pisma generowane przez Moduł RESP (funkcjonalność automatyczna). 3.4 Uzupełnianie dokumentów w Aplikacji EZD o poświadczenie odbioru pisma generowane przez Moduł RESP, po odebraniu dokumentu przez adresata (funkcjonalność automatyczna). 3.5 Publikowanie i aktualizacja informacji o stanie sprawy w Module BIP. Ręczne określenie dla każdej sprawy, czy informacja o jej stanie będzie publikowana na BIP oraz w jakim zakresie. 3.6 Sprawdzenie stanu sprawy w systemie BIP. 3.7 Przekazywanie rejestrów prowadzonych w Aplikacjach EZD wraz z załącznikami do komponentu BIP (w tym rejestru informacji o środowisku, zgodnie z Rozporządzeniem Ministra Środowiska z dnia r w sprawie wzoru oraz zawartości i układu publicznie dostępnego wykazu danych o dokumentach zawierających informacje Strona 3 z 13

4 o środowisku i jego ochronie). Publikacja i aktualizacja rejestrów będzie odbywać się ręcznie. 3.8 Wysyłanie z poziomu Aplikacji EZD dokumentów do innych uczestników projektu, wykorzystując przy tym indywidualne skrzynki tych uczestników w ramach Modułu RESP. 3.9 Zapewnienie funkcjonalności opisanej w punktach 1-8 w przypadkach czasowo nie działającej komunikacji pomiędzy Modułem Komunikacyjnym i RESP oraz Modułem Komunikacyjnym i BIP. 4 Sposób Komunikacji Komunikacja pomiędzy systemami odbywa się za pomocą usług sieciowych (web services). System kodowania znaków to UTF8. Aplikacje (strony komunikacji) łączą się z modułem Otago ESB Regionalnej Szyny Usług, który na podstawie adresata wiadomości kieruje zapytanie do odpowiedniej usługi. Moduł Komunikacyjny będzie korzystał z interfejsów zdefiniowanych w załączniku nr 1 do OPZ 5 Ogólna definicja usługi 5.1 Standardowy komunikat WSDL usługi znajduje się w załączniku nr 1 do niniejszego dokumentu. Standardowy komunikat składa się z następujących elementów: Nazwa Typ Rodzaj Opis nadawca xsd:int Wejściowy Identyfikator nadawcy wiadomości odbiorca xsd:int Wejściowy Identyfikator odbiorcy wiadomości id xsd:long Wejściowy Identyfikator komunikatu. Unikalny dla danego nadawcy. Wszystkie komunikaty o tym samym nadawcy i id są traktowane rodzaj xsd:int Wejściowy jako duplikaty Identyfikator rodzaju komunikatu komunikat xsd:string Wejściowy Treść komunikatu, XML zgodny z XSD odpowiedniego rodzaju i zawarty w załączniku nr 1 do OPZ wraz z późniejszymi zmianami. nadawcauzytkownik DaneUzytkownika Wejściowy Pole niewymagane. Przechowuje dokładniejsze dane dotyczące konkretnego użytkownika wywołującego usługę (nazwa i system). Strona 4 z 13

5 idprocesu xsd:long Wejściowy Pole niewymagane. Powinno być wypełniane tylko przy udzielaniu odpowiedzi na wniosek dowolnego typu wartością idproces otrzymaną w pobranym z kolejki wniosku. kod xsd:int Wyjściowy Kod odpowiedzi odpowiedz xsd:string Wyjściowy Treść odpowiedzi, XML zawierająca ewentualną informację o szczegółach przetwarzania, np. błędzie, zgodny ze schematem blad.xsd lub odpowiedzi na zapytanie dotyczące komunikatów w kolejce zgodnie ze schematem obslugakomunikatow.xsd idprocesu xsd:long Wyjściowy Wartość zwracana przez RSU, może być zapamiętana przez system zewnętrzny w celu późniejszego wyszukiwania odpowiedzi na ten konkretny wniosek. 5.2 Lista kodów odpowiedzi od do - 1 poniżej -101 od 1 Błędy ogólne Błędy w przetwarzaniu poszczególnych komunikatów Kody informacyjne poszczególnych komunikatów 5.3 Lista błędów ogólnych -1 System nie obsługuje tego komunikatu -2 Komunikat tymczasowo odrzucony może zostać ponowiony później -3 Komunikat odrzucony nie powinien być ponawiany -4 Błędna struktura komunikatu -5 Błąd przy przetwarzaniu komunikatu -6 Duplikat komunikat o tym nadawcy i id został już przetworzony. -7 Brak uprawnień dla aplikacji do wysyłania komunikatu tego rodzaju -8 Błąd podpisu/certyfikatu -9 Nieznany błąd Dla każdego z komunikatów o błędach ogólnych może zostać wygenerowany i przekazany w parametrze odpowiedz komunikat opisujący błąd wg schematu w załączniku Strona 5 z 13

6 blad.xsd. Pozostałe kody odpowiedzi będą określane w ramach potrzeb. Przestrzenie nazw zdefiniowane w plikach XSD, stanowiących załącznik do OPZ, a które obecnie wskazują na lokalizacje w domenie otago.pl, zostaną w przyszłości zmodyfikowane i osadzone w domenie, w której uruchomiona zostanie platforma RPUP. 5.4 Identyfikatory uczestników komunikacji (nadawca/odbiorca) Identyfikatory wywodzą się z kodów terytorialnych gmin, pomiędzy którymi zachodzi komunikacja i zawarte są w załączniku nr 2 do OPZ. 5.5 Komunikaty wychodzące z EZD do RPUP Nazwa Opis 101 Powiadomienie Przesłanie powiadomienia tekstowego 102 Pismo Przesłanie pisma w postaci epaczki 103 ZalPismo Przesłanie dodatkowego załącznika do wcześniej wysłanego pisma 104 InteresantSkrzynka Pobranie informacji o skrzynce interesanta lub utworzenie nowej skrzynki interesanta 105 ZalWniosek Przesłanie załącznika do wniosku wysłanego wcześniej ze skrzynki podawczej 106 CertInfo Żądanie weryfikacji dokumentu elektronicznego 107 SprawaInfo Przesłanie informacji o stanie sprawy 108 WniosekInfo Przesłanie informacji o stanie wniosku 109 SprawyDane Eksport danych spraw przetwarzanych w EZD do BIP 110 RejestryDane Eksport danych dowolnego rejestru z EZD do BIP 120 DodajPlatnosc Dodanie płatności do wybranego konta 121 UsunPlatnosc Usunięcie (anulowanie) płatności z konta 122 SprawdzStan Sprawdzenie stanu płatności 123 OznaczWykonanie Oznaczenie wykonania płatności (poza systemem epłatności) 5.6 Komunikaty przychodzące z RPUP do EZD usługi konieczne do implementacji w systemie EZD Nazwa Opis 201 Powiadomienie Przesłanie powiadomienia tekstowego 202 Wniosek Przesłanie wniosku w postaci epaczki 203 ZalWniosek Przesłanie dodatkowego załącznika do wysłanego wcześniej wniosku z (np. informacje o odebranej opłacie) 204 StanWniosku Żądanie sprawdzenia stanu wniosku 205 StanSprawy Żądanie informacji o stanie sprawy 206 UpoPismo Potwierdzenie odbioru dla dokumentu wychodzącego podpisane przez HSM 207 UpoPotwPismo Zwrotne potwierdzenie odbioru dla dokumentu wychodzącego podpisane przez interesanta 208 ZalPismo Przesłanie załącznika do wysłanego wcześniej z obiegu Strona 6 z 13

7 dokumentów pisma. 209 CertRaport Raport weryfikacji dokumentu elektronicznego przez centrum weryfikacji platformy integracyjnej 210 SkrzynkaInfo Informacje o skrzynce interesanta oraz status odpowiedzi: Informacja o istniejącej skrzynce lub potwierdzenie założenia skrzynki interesanta 124 WykonanoPlatnosc Oznaczenie wykonania płatności w systemie e-płatności 5.7 Przepływ komunikatów Wykonawca MK musi zaimplementować obsługę komunikatów w systemie EZD przychodzących z RPUP oraz komunikatów wychodzących z EZD do RPUP. Strona 7 z 13

8 Strona 8 z 13

9 5.8 Zabezpieczenia komunikacji Strona 9 z 13

10 Podstawową formą zabezpieczenia komunikacji będzie zaszyfrowanie w warstwie transportowej przy użyciu protokołu SSL/TLS 3.0. Konfiguracja zabezpieczenia powinna zostać wykonana na serwerach aplikacji, na których znajdować się będą instancje usługi sieciowej (wszystkie jednostki). Próba łączenia w kanale niezabezpieczonym będzie blokowana. Dodatkowym zabezpieczeniem gwarantującym integralność wiadomości będzie zastosowanie podpisu cyfrowego, którym podpisywane powinny być wszystkie elementy wiadomości, tzn. nawiązując do załączonego WSDL komunikat Request i komunikat Response. Podpis może być składany korzystając z certyfikatu X.509 wydanego na potrzeby SSL dla każdego serwera uczestniczącego w komunikacji. Podpis musi być zgodny ze standardem XMLDsig. Zamawiający przekaże jedynie obowiązujące odpowiednie certyfikaty. 6 Warunki wdrożenia 6.1 Konfiguracja systemu EZD Wykonawca zobowiązany jest do skonfigurowania EZD z MK. Jeżeli w trakcie realizacji MK Wykonawca wykaże brak możliwości integracji MK z funkcjonującą wersją EZD zgodnie z regułami sztuki informatycznej oraz w sposób zgodny z wymaganiami OPZ, Zamawiający dopuści zamianę wersji istniejącego EZD na wersję tego EZD współpracującą z MK. W takim przypadku Wykonawca udzieli Partnerowi licencji na wymienioną wersję EZD. Na potwierdzenie konieczności zamiany EZD Zamawiający będzie żądał pisemnego oświadczenia Wykonawcy. Wymiana wersji EZD nie może powodować zmiany warunków użytkowania EZD na niekorzystne dla Partnera, w szczególności: a) zwiększenia kosztów związanych z użytkowaniem systemu, b) wprowadzania ograniczenia użytkowników uprawnionych do korzystania z systemu, a także jakichkolwiek ograniczeń dodatkowych w stosunku do dotychczasowych warunków użytkowania, c) skrócenia terminów, np. wsparcia technicznego, gwarancji, rękojmi, d) powodowania nowych kosztów wynikających z umów uprzednio zawartych przez Partnera, e) powodowania braku dostępności danych w nowej wersji systemu, f) zakłócenia ciągłości działania systemów informatycznych u Partnera. Wykonawca dokonując wymiany wersji EZD zobowiązany jest dostarczyć dokumentację użytkownika dotyczącą wymienionej wersji EZD. Dokumentację dostarcza się osobno dla każdego z Partnerów, u których dokonywano zmiany wersji EZD. 6.2 Etapy wdrożenia Etap I Szczegółowa dokumentacja interfejsów komunikacyjnych RSU zostanie przekazana Wykonawcy najpóźniej w 3 dni robocze po podpisaniu umowy. Strona 10 z 13

11 Wykonawca zobowiązany jest wystawić pod zewnętrznym adresem IP środowisko testowe systemu EZD posiadającego stworzony, na podstawie przekazanej dokumentacji Moduł Komunikacyjny, w terminie 28 dni od podpisania umowy. Środowisko testowe musi działać do końca trwania projektu i być bezzwłocznie aktualizowane w przypadku zmian w systemie. Wykonanie etapu I musi być potwierdzone protokołem odbioru w czterech jednobrzmiących egzemplarzach zgodnie z wzorem w Umowie Etap II Po przekazaniu Zamawiającemu dostępu do środowiska testowego systemu EZD, stworzony MK zostanie zweryfikowany pod kątem prawidłowości działania oraz komunikacji z RPUP przez Zamawiającego. W przypadku nieprawidłowości działania bądź komunikacji firma realizująca moduł RPUP przy współudziale Inżyniera Projektu Wrota Lubelszczyzny Informatyzacja Administracji wskaże ewentualne błędy w komunikacji pomiędzy systemami. Wykonawca w przeciągu 1 dnia roboczego ustosunkuje się do uwag, a następnie w ciągu 3 dni roboczych przedstawi Zamawiającemu dokona poprawy zgłoszonych błędów i przedstawi je Zamawiającemu do akceptacji. W uzasadnionych przypadkach, Zamawiający może podjąć decyzję o przedłużeniu terminu. Ostatecznym terminem stworzenia zweryfikowanego oraz poprawnie komunikującego się z RPUP systemu EZD jest dzień r. Wykonanie etapu II musi być potwierdzone protokołem odbioru w czterech jednobrzmiących egzemplarzach zgodnie z wzorem w Umowie Etap III Po stworzeniu zweryfikowanego oraz poprawnie komunikującego się z RPUP systemu EZD, Wykonawca zobowiązany jest w nieprzekraczalnym terminie 18 dni wdrożyć aktualizacje (obejmującą stworzony moduł komunikacyjny) systemów EZD wyszczególnionych w załączniku nr 2 lista jednostek. Zamawiający wymaga przeszkolenia użytkowników w zakresie nowych lub realizowanych w inny sposób funkcjonalności. Zakres szkoleń musi być dostosowany do roli użytkowników w systemie EZD. Liczba użytkowników do przeszkolenia jest opisana w załączniku nr 2. Przeszkolenie musi być potwierdzone protokołem odbioru w czterech jednobrzmiących egzemplarzach zgodnie z wzorem w umowie. Wraz z ukończeniem wdrożenia zrealizowany zostaje etap III umowy Etap IV Etap IV umowy rozpocznie się z dniem r. po otrzymaniu od Zamawiającego ostatecznych dokumentacji interfejsów komunikacyjnych. Uzupełniona dokumentacja będzie w szczególności zawierała interfejs integracji z modułem płatności. Interfejsy komunikacyjne poszczególnych komponentów środowiska produkcyjnego względem interfejsów przekazanych na początku realizacji umowy mogą zostać, w trakcie realizacji dalszych prac projektowych, nieznacznie zmodyfikowane. Strona 11 z 13

12 Wykonawca do dnia r. zobowiązany jest zweryfikować ewentualne zmiany w dokumentacji interfejsów komunikacyjnych, jak również nanieść niezbędne poprawki, tak by system w pełni (pkt. 1 pkt. 9) mógł komunikować się z RPUP. Wykonanie etapu IV musi być potwierdzone protokołem odbioru w czterech jednobrzmiących egzemplarzach zgodnie z wzorem w Umowie. 7 Dokumentacja Zamawiający wymaga przekazania dokumentacji opisującej MK i jego sposób konfiguracji oraz dokumentacji użytkownika i administratora systemu EZD w zakresie wprowadzonych zmian. Dokumentacja musi być przekazana w formie elektronicznej Zamawiającemu i przynajmniej jeden wydrukowany egzemplarz dla każdej jednostki Partnera Projektu. Przekazanie ww dokumentacji musi być potwierdzone protokołem odbioru w czterech jednobrzmiących egzemplarzach zgodnie z wzorem w umowie. 8 Gwarancja i rękojmia 8.1 Czas trwania gwarancji i rękojmi Wykonawca jest zobowiązany świadczyć gwarancję i rękojmię na okres 24 miesięcy od daty wykonania bezusterkowego odbioru końcowego. 8.2 Zakres W ramach gwarancji i rękojmi Wykonawca jest zobowiązany do: Zapewnienia ciągłości działania komunikacji pomiędzy EZD i RPUP; Usuwania w porozumieniu z firmą realizującą moduł RPUP błędów; Wprowadzanie zmian wynikających ze zmian prawnych; Wprowadzanie zmian dostosowujących do potencjalnych zmian w specyfikacji interfejsów komunikacji. Należy założyć, że zmiany w specyfikacji interfejsów nie będą większe niż 25% specyfikacji aktualnej na dzień odbioru końcowego; Rozwiązywania problemów technicznych związanych z funkcjonowaniem oprogramowania. 8.3 Zasady świadczenia gwarancji i rękojmi. Zgłoszenie z zakresu rękojmi i gwarancji będą przekazywane Wykonawcy przez Zamawiającego oraz Partnerów Projektu przy użyciu: Formularza zgłoszenia udostępnionego przez Wykonawcę; Adresu udostępnionego przez Wykonawcę; Zgłoszenia mogą mieć następujące kategorie: Błąd, Zmiana RPUP, Zmiana prawna. 8.4 Obowiązujące Wykonawcę czasy realizacji zgłoszeń liczone od czasu potwierdzenia Strona 12 z 13

13 zgłoszenia: dni roboczych dla błędów, dni roboczych dla zmian RPUP, dni roboczych dla zmian prawnych. 9 Załączniki do OPZ 1. Załącznik nr 1 - Zdefiniowane interfejsy dla modułu komunikacyjnego 2. Załącznik nr 2 - Lista jednostek objętych usługą dostosowania EZD Strona 13 z 13