Wymagania funkcjonalne I niefunkcjonalne



Pobieranie 0.56 Mb.
Strona12/14
Data28.04.2016
Rozmiar0.56 Mb.
1   ...   6   7   8   9   10   11   12   13   14

1.15 Integracja

1.15.1 ePUAP





  1. System musi posiadać wbudowany interfejs komunikacyjny pozwalający na wymianę informacji (dokumentów wraz z zestawem niezbędnych metadanych) z platformą ePUAP.

  2. System musi zapewniać komunikację zarówno w trybie Urzędowego Poświadczenia Odbioru (UPO) jak i Urzędowego Poświadczenia Doręczenia (UPD).

  3. System musi umożliwiać obsługę identyfikatorów korelacyjnych ePUAP w celu identyfikacji konta użytkownika, z którego do SII został przekazany komunikat.

  4. System musi umożliwiać przekazywanie dokumentów wychodzących z poziomu SEOD na konta użytkowników i instytucji na ePUAP.

1.15.2 Exchange





  1. System musi współpracować z istniejącym u Zamawiającego systemem poczty opartym na Exchange 2010.

  2. System musi pozwalać na wykorzystanie, w witrynach bądź listach Systemu, elementów funkcjonalnych, które umożliwią dostęp do następujących folderów konta e-mail danego użytkownika:

  1. kalendarz,

  2. kontakty,

  3. zadania,

  4. skrzynka odbiorcza.

  1. System musi umożliwiać taką konfigurację, aby poczta wysłana pod adres przypisany do listy Portalu (kalendarz lub repozytorium dokumentów) została w niej zapisana.

  2. System musi zapewnić, że prezentowane informacje, będą dotyczyły tylko aktualnie zalogowanego użytkownika Systemu.



1.15.3 Broker Komunikacyjny


System musi komunikować się z Brokerem Komunikacyjnym opartym o technologię BizTalk Server w następujący sposób:

1.15.3.1Interfejsy


  1. Zamawiający dopuszcza zastosowanie do budowy interfejsów integracyjnych następujących metod:

  1. usługi (WebServices),

  2. tabele interfejsowe w bazie danych,

  3. pliki XML.

  1. Dostęp do poszczególnych interfejsów musi być ograniczony jedynie dla Brokera Komunikacyjnego, poprzez nałożenie, odpowiednich dla wykorzystywanego protokołu, zabezpieczeń.



1.15.3.2Usługi (WebServices)


  1. Interfejs musi umożliwiać komunikację w oparciu o protokół http i https. Komunikacja może być jednokierunkowa i dwu kierunkowa (żądanie – odpowiedz). Dopuszcza się dwa rodzaje kodowania: Text i MTOM.

  2. Mechanizm autentykacji klientów usługi (Client authentication mechanism) musi pozwalać na autentykację na poziomie warstwy transportowej, jak i komunikatu (Transport Security and Message Security). Może być to autentykacja Windows lub autentykacja z wykorzystaniem certyfikatu X.509.

  3. Interfejs musi być zgodny z rozszerzeniami WS-*:

      1. WS-Security, wspierając poniższe standardy:

        • Web Services Security: SOAP Message Security (WS-Security) 1.0 i 1.1,

        • Web Services Secure Conversation Language (WS-SecureConversation 1.3),

        • Web Services Trust Language (WS-Trust 1.3),

        • Web Services Security X.509 Certificate Token Profile 1.0 i 1.1,

        • Web Services Security Username Token Profile 1.0 i 1.1,

        • Web Services Security Kerberos Token Profile 1.0 i 1.1.

      2. WS-AtomicTransaction 1.1:

        • transakcyjne odbieranie komunikatów,

        • transakcyjne wysyłanie komunikatów.

      3. WS-Adressing 1.0:

        • definicja powiązania punktów końcowych i nagłówków informacyjnych wiadomości.



1.15.3.3Tabele interfejsowe w bazie danych


  1. System do komunikacji z Brokerem Komunikacyjnym może wykorzystywać tabele interfejsowe w bazie danych. Do komunikacji z Brokerem Komunikacyjnym powinny zostać utworzone tabele do wysyłania informacji do innych systemów i tabele do pobierania danych od brokera.

Wspierane wersje Oracle:

  1. Oracle 9i (9.2.0.2),

  2. Oracle 10g (10.1.0.2.0 & 10.2.0.1.0),

  3. Oracle 11g.

Wersje bazy danych SQL Server:

  1. SQL Server 2000,

  2. SQL Server 2005,

  3. SQL Server 2008.




  1. Wykonawca musi zapewnić możliwość oznaczenia statusu wymiany informacji poprzez dodanie do tabel kolumny określającej status np.: 0 – do odczytu, 1 – odczytane, 2 – potwierdzone dostarczenie.

  2. Tabele interfejsowe w bazie danych muszą zawierać kolumny o typach prostych, bez typów XML.

  3. W celu ograniczenia dostępu do tabel interfejsowych muszą być wykorzystane mechanizmy autentykacji i autoryzacji bazy danych w połączeniu z funkcjonalnością usług katalogowych.



1.15.3.4Pliki XML


  1. Wymiana informacji musi być możliwa poprzez zapis i odczyt plików XML z systemu NTFS. Pliki mogą być umieszczane lokalnie lub na udziale sieciowym. System udostępnia swoje informacje poprzez zapis ich do plików, które są odczytywane przez brokera komunikacyjnego. Broker może też tworzyć pliki z informacjami dla systemu. Pliki XML powinny być kodowane w formacie UTF-16.

  2. Do zabezpieczenia bezpieczeństwa przesyłanych danych musi być wykorzystany mechanizm uprawnień NTFS.

  3. Specyfikacja funkcji realizowanych przez interfejsy zostanie określona przez zespoły po stronie Zamawiającego i wykonawcy na etapie tworzenia specyfikacji technicznej systemu.

1.15.4 System SOFTUS


  1. System musi umożliwić automatyczne pobranie i przekazanie przez Broker Komunikacyjny oparty o technologię BizTalk Server do modułu kadrowego systemu SOFTUS (system HR) niezbędnych informacji z procesów związanych z dyscypliną pracy.

  2. Zakres przekazanych informacji zostanie opracowany na etapie projektu technicznego.



1.15.5 Unified Communication





  1. System musi umożliwić integrację z użytkowanym u Zamawiającego Microsoft Lync poprzez wyświetlanie w systemie SII statusu dostępności danego pracownika wraz z możliwością wykonania z poziomu SII:

    1. połączenia typu chat, głos czy video,

    2. zaplanowania spotkania,

    3. wysłania e-mail,

    4. dodania do kontaktów Outlook,

    5. wyświetlenia właściwości Outlook.



1.15.6 System Edukacyjny


  1. System musi umożliwić rezerwację (w tym zmianę rezerwacji i usunięcie rezerwacji) zasobów zdefiniowanych w module rezerwacji zasobów z poziomu Sytemu Edukacyjnego GUS.

  2. System musi umożliwić wykorzystanie modułu struktury organizacyjnej SII z poziomu Systemu Edukacyjnego GUS w zakresie akceptacji zapisów na szkolenia pracowników jednostek statystyki publicznej.

1.15.7 Portal informacyjny GUS


  1. System musi posiadać usługe sieciową dedykowaną dla Biuletynu Informacji Publicznej Portalu Internetowego GUS (WebService opisany z pomocą opisu usług sieciowych WSDL) służącą do przesyłania meta danych i plików z Systemu. Szczegółowa specyfikacja tej usługi zostanie określona na etapie wdrożenia.



1   ...   6   7   8   9   10   11   12   13   14


©absta.pl 2016
wyślij wiadomość

    Strona główna