Energia w dobrych rękach.

Transkrypt

1 Energia w dobrych rękach

2 Zmiany w Systemach Komunikacyjnych SOWE/WIRE Departament Usług Operatorskich Warszawa, 9 sierpnia 2007 r. 2

3 Agenda I. Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w dokumentach / schematach walidacji WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ - Nowe Wymagania bezpieczeństwa dla systemów transmisji danych SOWE/EL, WIRE/UR - Aplikacja CCO (Centrum Certyfikacji OSP) Harmonogram wdroŝenia zmian w systemach komunikacyjnych II. Uwarunkowania budowy wielu systemów WIRE/UR w jednym węźle sieci WIRE/SOWE III. Aktualizacja systemu bezpiecznego dostępu AppGate do wersji 8.0 IV. Uruchomienie zmodernizowanego systemu SIRE systemy komunikacji WIRE/SOWE 3

4 Zagadnienia Harmonogram działań Aktualizacja pakietu bezpieczeństwa AppGate Publikacja nowych standardów technicznych systemów WIRE i SOWE Publikacja Procedur wdraŝania zmian w standardach technicznych systemów WIRE i SOWE WdraŜanie zmian w dokumentach XML Przejście na SSL Zakończenie wdraŝania zmian w systemach WIRE i SOWE 4

5 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Cel: Dostosowanie szablonów walidacji dokumentów do aktualnie obowiązującej rekomendacji W3C Bezpośrednie odwoływanie się do plików publikowanych przez ETSO w schematach walidacji wymiany międzysystemowej Wprowadzenie wersjonowania schematów XSD i dokumentów biznesowych Wprowadzenie identyfikacji dokumentów powiązanych biznesowo w wątki wymiany informacji Poprawa wydajności transformacji dokumentów do bazy danych 5

6 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w schematach walidacji Wspólna przestrzeń nazw - Dziedziny, które powtarzały się w wielu dokumentach, jak np. kod obiektu zostały wyodrębnione do zewnętrznego pliku - Identyfikacja dziedzin dla poszczególnych tagów w schematach walidacji następuje poprzez odwołania do pliku zewnętrznego z definicjami dziedzin Wersjonowanie schematów walidacji - UmoŜliwiono obsługę dokumentów XML przesyłanych w jednym czasie w róŝnych wersjach standardów technicznych SOWE lub WIRE poprzez wprowadzenie wersjonowania schematów XSD - KaŜdy schemat walidacji składa się z: nagłówka, części dokumentacyjnej z numerem wersji, deklaracji importów schematów zewnętrznych, opisu struktury dokumentu w podziale na definicje typów i elementów biznesowych 6

7 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w schematach walidacji nazwa przestrzeni targetnamespace, deklaracja typów zewnętrznych część dokumentacyjna z numerem wersji klucz zgodności kodu obiektu pomiędzy nagłówkiem XML dokumentu a treścią odwołanie do definicji typów zewnętrznych 7

8 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w schematach walidacji Typy złoŝone Typy proste Typy wyliczeniowe 8

9 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w schematach walidacji Schematy wymiany międzysystemowej: ZGWM, OGWM, UGWM, PGWM będą bazować na schematach publikowanych przez ETSO: schedule-xml.xsd, confirmation-xml.xsd, anomaly-xml.xsd oraz związanych z nimi plikach wspólnych etso-core-cmpts.xsd i etso-codelists.xsd. PoniewaŜ schematy ETSO nie definiują Ŝadnej przestrzeni typu targetnamespace (z wyjątkiem schematów wspólnych), to chcąc wykorzystać te schematy do dokumentów WIRE konieczne jest zdefiniowanie przestrzeni nazw dla dokumentów ETSO. 9

10 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w schematach walidacji NaleŜy dodać kaŝdemu głównemu dokumentowi ETSO: schedulexml.xsd, confirmation-xml.xsd, anomaly-xml.xsd przestrzeń domyślną i przestrzeń targetnamespace o nazwie odpowiadającej nazwie pliku XSD w którym ten schemat jest przechowywany. 10

11 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w dokumentach biznesowych dodanie definicji przestrzeni nazw targetnamespace <Komunikat xmlns=" rozszerzenie nagłówka WIRE o dodatkowe pola: wersja, id, ref_id usunięcie pola kod_sys rozszerzenie nagłówka SOWE do postaci spójnej z nagłówkiem WIRE (nowe pola powinny być takŝe kopiowane do nagłówka JMS) Dokument XML <?xml version="1.0" encoding="iso "?> <Komunikat xmlns=" Nagłówek dokumentu XML <Naglowek> <kod_kom> Kod komunikatu biznesowego</kod_kom> <kod_obiektu>kod obiektu</kod_obiektu> <data>data, której dokument dotyczy, w formacie:"rrrr-mm-dd"</data> <data_utworzenia>data utworzenia dokumentu w formacie:"rrrr-mm-dd gg:mm:ss"</data_utworzenia> <wersja> Wersja standardów, z którymi dokument jest zgodny </wersja> <id>unikalny identyfikator dokumentu</id> <ref_id>referencja do identyfikatora dokumentu, którego dany dokument dotyczy</ref_id> </Naglowek> odwołanie do przestrzeni targetnamespace nowe pola nagłówka XML Treść dokumentu XML <Tresc> <Zawartosc> <P1>Treść pola 1</P1> <P2>Treść pola 2</P2> <P3>Treść pola 3</P3> </Zawartosc> </Tresc> </Komunikat> 11

12 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w dokumentach biznesowych Dokumenty XML dotyczące Wymiany Międzysystemowej: - W części, gdzie pojawia się treść zgodna ze schedule-xml.xsd jest konieczność podania przestrzeni nazw w tym przypadku jest to przestrzeń definiowana przez ETSO xmlns= schedule-xml.xsd : Jedynym dopuszczalnym kodem dla Scheduling Coordinator w liście RoleTypeList będzie kod A28 zakończona zostanie obsługa tymczasowego kodu Z

13 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Format identyfikatorów ID i REF_ID Identyfikator ID jest generowany poprzez węzeł centralny oraz węzły lokalne w sposób gwarantujący jednoznaczną identyfikację dokumentu. Identyfikatory ID i REF_ID przyjmują następujący format WĘZEŁ_KOMUNIKAT_NUMER (np. WWABC_ZUSE_ ) gdzie: WĘZEŁ kod węzła pisany duŝymi literami KOMUNIKAT kod typu komunikatu pisany duŝymi literami NUMER kolejny numer (unikalny w ramach węzła) o stałej długości 10. Węzeł centralny kontroluje poprawność identyfikatora ID i w przypadku jego niezgodności z powyŝszymi zasadami dokument jest odrzucany poprzez wysłanie potwierdzenia IOD z kodem NP_MSGID lub DU_MSGID. 13

14 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Format identyfikatorów ID i REF_ID Pole REF_ID nagłówka XML komunikatu zawiera identyfikator referencyjny, czyli identyfikator dokumentu, którego dany dokument dotyczy Identyfikator REF_ID jest generowany tylko w dokumentach stanowiących odpowiedź lub kontynuacje wątku wymiany informacji dla innego dokumentu Generowanie dokumentów zwrotnych zawierających identyfikator referencyjny do dokumentu, na który dany komunikat stanowi odpowiedź /kontynuuje wątek wymiany informacji jest równieŝ wymaganą funkcjonalnością węzłów lokalnych 14

15 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Identyfikatory ID i REF_ID dla WIRE 15

16 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Identyfikatory ID i REF_ID dla SOWE 16

17 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Wersjonowanie dokumentów XML Istnieje moŝliwość obsługi dokumentów nadsyłanych w wielu wersjach standardów technicznych SOWE lub WIRE Informacja o wersji dokumentu XML jest prezentowana w polu wersja nagłówka XML 17

18 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w aplikacjach SOWE i WIRE Archiwum Dodanie zapisu informacji o ID i REF_ID dokumentu biznesowego w bazie danych archiwum SOWE i WIRE Dodanie do funkcji wyszukiwania dokumentów nowego kryterium, jakim jest ID komunikatu biznesowego 18

19 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w aplikacjach SOWE i WIRE Archiwum Dodanie funkcjonalności umoŝliwiającej wyświetlenie listy dokumentów powiązanych na podstawie ich powiązań biznesowych poprzez ID i REF_ID 19

20 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Zmiany w aplikacji WIRE/RP Wybór szablonu prezentacji w odpowiedniej wersji standardu dla danego uŝytkownika przy opcji wprowadzania nowego dokumentu - najnowsza wersja szablonu dla Uczestnika obsługującego więcej niŝ jeden standard Kontrola wersji dokumentów przy opcji importu dokumentu XML ze stacji roboczej moŝliwość importu tylko dokumentów z wersjami zgodnymi z konfiguracją węzła Operatora Rynku Mechanizm walidacji dokumentów w WIRE/RP wybiera do walidacji schemat odpowiedni do wersji standardów technicznych, z którymi jest zgodny dokument XML 20

21 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 Potwierdzenia biznesowe Dodano kontrolę uprawnień węzła do przesyłania dokumentu w określonym standardzie technicznym (IOD o kodzie ND_NAD) Dodano kontrolę formatu ID w nadsyłanych do OSP dokumentach (IOD NP_MSGID, DU_MSGID) Zmieniono kod IOD-a na DU_DANE w przypadku nadesłania przez węzeł lokalny dokumentu pomiarowego z identycznymi danymi na ten sam FPP lub MB i tę samą dobę. 21

22 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ

23 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ WYMAGANIA: Identyfikacja nadawcy komunikatu poprzez certyfikaty cyfrowe Kontrola dostępu do kolejek i kanałów WebSphere MQ Bezpieczna, szyfrowana komunikacja bez uŝycia IPSec Zapewnienie bezpiecznych certyfikatów dla Operatorów Rynku poprzez aplikację CCO Centrum Certyfikacji OSP 23

24 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ CHARAKTERYSTYKA SSL: Protokół SSL charakteryzują trzy podstawowe cechy: Uwierzytelnienie weryfikowanie toŝsamości serwera lub serwera i klienta na obu końcach połączenia przy uŝyciu certyfikatów cyfrowych Poufność - szyfrowania przesyłanych informacji w bezpiecznym kanale, tak aby tylko obie komunikujące się strony mogły uzyskać do niej dostęp Integralność - niedopuszczenie do zmiany zawartości komunikatu. Odbiorca moŝe być pewny, Ŝe otrzymuje niezmienioną informację 24

25 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ PRZEŁĄCZENIE IPSec NA SSL WebSphere MQ: Zgłoszenie przez OR gotowości do przeprowadzenia testów w zakresie protokołu szyfrującego (SSL) Utworzenie dodatkowego MenadŜera MQ SSL w ramach istniejącej u OR instancji WebSphere MQ Pozyskanie, podpisanie i zainstalowanie testowego certyfikatu z wykorzystaniem narzędzi MQ oraz aplikacji CCO Zestawienie komunikacji pomiędzy nowoutworzonym MenadŜerem MQ SSL a Środowiskiem Testowym OSP Przeprowadzenie 5 dniowych testów komunikacyjnych z wykorzystaniem testowego certyfikatu 25

26 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ PRZEŁĄCZENIE IPSec NA SSL WebSphere MQ: Pozyskanie, podpisanie i zainstalowanie produkcyjnego certyfikatu z wykorzystaniem narzędzi MQ oraz aplikacji CCO Przełączenie komunikacji z nowoutworzonego MenadŜera MQ SSL na Środowisko Produkcyjne OSP Przeprowadzenie 2 dniowych testów komunikacyjnych przy uŝyciu docelowego certyfikatu Przełączenie aplikacji WIRE/UR lub SOWE/EL na komunikację z nowym MenadŜerem MQ SSL Zatrzymanie oraz usunięcie starego MenadŜera MQ IPSec 26

27 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ ZAKRES ZMIAN W KOMUNIKACJI WIRE/SOWE PO STRONIE OSP: Konfiguracja WebSphere MQ - zmiany nazw i konfiguracji kanałów uruchomienie SSL - włączenie systemu uprawnień WebSphere MQ - uruchomienie serwera CRL uniewaŝnionych certyfikatów Udostępnienie Aplikacji CCO 27

28 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ ZAKRES ZMIAN W KOMUNIKACJI WIRE/SOWE PO STRONIE OR/EL: Konfiguracja WebSphere MQ - podpisanie certyfikatów przy uŝyciu Aplikacji CCO - zmiany nazw i konfiguracji kanałów uruchomienie SSL - włączenie systemu uprawnień WebSphere MQ 28

29 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ WYMAGANIA DLA OPERATORA RYNKU: Wersje WebSphere MQ obsługujące SSL: - WebSphere MQ 5.3 Fix Pack 12 - WebSphere MQ 6.0 Fix Pack Po stronie OR niezbędne jest aby Administrator Bezpieczeństwa OR posiadał dostęp do aplikacji CCO poprzez kanał VPN (AppGate), co wiąŝe się z koniecznością posiadania tokena RSA SecurID oraz zaktualizowaniem pakietu bezpiecznego dostępu do wersji 8.0 Login i hasło do aplikacji CCO dostępne będą na stronie www2.pse.pl po uprzednim przypisaniu ABOR owi aktywnego tokena 29

30 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ POZYSKANIE CERTYFIKATU: ABOR tworzy repozytorium certyfikatów menedŝera kolejek ABOR generuje wniosek o certyfikat przy pomocy narzędzia WebSphere MQ: gsk6cmd lub gsk7cmd Klucz prywatny przechowywany jest w repozytorium certyfikatów ABOR loguje się do aplikacji CCO 30

31 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ POZYSKANIE CERTYFIKATU: ABOR przesyła wniosek do CCO poprzez upload w aplikacji CCO 31

32 WdroŜenie autentykacji i autoryzacji z wykorzystaniem kanałów SSL WebSphere MQ POZYSKANIE CERTYFIKATU: Po podpisaniu certyfikatu przez Administratora Certyfikatów CCO, ABOR ściąga podpisany certyfikat. Szczegóły Odnów certyfikat Anuluj certyfikat Pobierz certyfikat Następnie instaluje certyfikat w repozytorium certyfikatów przy pomocy narzędzia WebSphere MQ 32

33 Nowe Standardy techniczne systemu WIRE 8.0 / SOWE 5.0 ZESTAWIENIE DOKUMENTÓW DOTYCZĄCYCH WDROśENIA: Standardy techniczne systemu WIRE wersja 8.0 Standardy techniczne systemu SOWE wersja 5.0 Wymagania bezpieczeństwa dla systemów transmisji danych SOWE/EL, WIRE/UR wersja 8.0 Instrukcja administracyjna przełączenia węzła WIRE / SOWE na protokół SSL Instrukcja uŝytkownika Aplikacji CCO Procedura wprowadzania zmian w Standardach technicznych systemu WIRE wersja 4.0 Procedura wprowadzania zmian w Standardach technicznych systemu SOWE wersja

34 Harmonogram wdroŝenia zmian w systemach komunikacyjnych WIRE/SOWE

35 Harmonogram wdroŝenia zmian w systemach komunikacyjnych Tabela 1. Czynności związane z wprowadzeniem zmian LP Opis czynności Odpowiedzialność Czas 1. Publikacja nowej wersji Standardów technicznych OSP Do systemu WIRE 8.0 /SOWE Publikacja Karty Aktualizacji do Instrukcji OSP Do Ruchu i Eksploatacji Sieci Przesyłowej 3. Wprowadzenie zmian do systemu OSP OSP Do Zgłoszenie przez Dostawców oprogramowania do OSP gotowości do przeprowadzenia testów WIRE/UR, SOWE/EL 5. Wyznaczenie przez OSP terminu oraz harmonogramu testów 6. Prowadzenie testów systemu wymiany informacji WIRE/UR, SOWE/EL 7. Wystawienie certyfikatu zgodności Dostawcy oprogramowania, którzy przeszli testy (posiadanie przez OR certyfikatu zgodności zwalnia OR z konieczności testów w zakresie wymiany dokumentów) 35 Dostawca Systemu Do OSP Dostawca Systemu, OSP OSP 2-3 dni od zgłoszenia Do Po zakończeniu testów

36 Harmonogram wdroŝenia zmian w systemach komunikacyjnych LP Opis czynności Odpowiedzialność Czas 8. Zgłaszanie przez OR gotowości do zmiany OR Od standardu wymiany informacji 9. Wyznaczanie daty zmiany obowiązującego OSP Od standardu dla poszczególnych OR 10. Zgłaszanie przez OR gotowości do przeprowadzenia testów w zakresie protokołu OR szyfrującego (SSL) 11. Wyznaczenie przez OSP terminu i harmonogramu OSP 2-3 dni od testów komunikacyjnych (testy będą trwały 5 dni na ST +2 dni na SP) otrzymania zgłoszenia 12. Prowadzenie testów OR, OSP Podpisanie protokołu akceptacji systemu WIRE/UR, SOWE/EL do wymiany dokumentów zgodnie ze Standardami technicznymi systemu WIRE 8.0, SOWE 5.0 z wykorzystaniem SSL. OSP Po zakończeniu testów Zgłoszenie z pkt. 8 i 10 mogą być przesłane jednocześnie 36

37 Uwarunkowania budowy wielu systemów WIRE/UR w jednym węźle dostępowym sieci WIRE/SOWE

38 Uwarunkowania budowy wielu systemów WIRE/UR w jednym węźle dostępowym sieci WIRE/SOWE Wymagania: Konieczność rozdzielenia systemów WIRE/UR dla OSD i dla systemów innych URB ZałoŜenia: MoŜliwość zbudowania systemów WIRE/UR przez dwóch lub więcej OR z wykorzystaniem istniejącej infrastruktury sprzętowej i sieciowej. 38

39 Uwarunkowania budowy wielu systemów WIRE/UR w jednym węźle dostępowym sieci WIRE/SOWE Rozdzielenie następuje za gateway em, który pozostaje wspólny dla wszystkich OR za skonfigurowanie urządzenia zgodnie z parametrami technicznymi odpowiada OR Wykorzystanie tego samego węzła sieci SOWE/WIRE przez więcej niŝ jednego OR (URB) wiąŝe się z koniecznością zapewnienia przez OR (URB) odpowiedniej przepustowości łączy do sieci SOWE/WIRE (Dla dwóch OR zaleca się posiadanie dwóch łączy i konfigurację sieci tak aby kaŝdy OR (URB) wykorzystywał po jednym łączu a drugie przejmowało jego funkcje w przypadku awarii.) 39

40 Uwarunkowania budowy wielu systemów WIRE/UR w jednym węźle dostępowym sieci WIRE/SOWE Decyzja czy nowy Manager WebSphere MQ będzie działał na tym samym serwerze pod innym adresem IP, czy teŝ na innym serwerze pozostaje w gestii OR-ów Uwaga: Przy niezastosowaniu się do zalecenia posiadania dwóch łączy lub podczas awarii jednego łącza pasmo transmisji danych będzie dzielone (aktualnie dla kaŝdego WIRE/UR wymagane 64 kbps) 40

41 Uwarunkowania budowy wielu systemów WIRE/UR w jednym węźle dostępowym sieci WIRE/SOWE Nowy podmiot otrzymuje nowy zestaw adresów IP i nową decyzję z parametrami technicznymi Rozdzielenie systemu wiąŝe się z koniecznością odbycia testów zgodnie z Procedurą przyłączania i akceptacji systemów informatycznych Operatora Rynku do systemów informatycznych OSP. Nowy podmiot otrzymuje nowy Protokół akceptacji systemu informatycznego Rozdzielenie systemów wiąŝe się z koniecznością aneksowania / zawarcia umowy pomiędzy OR (URB) a OSP 41

42 Aktualizacja systemu bezpiecznego dostępu AppGate do wersji

43 Aktualizacja systemu bezpiecznego dostępu AppGate do wersji 8.0 Zakończenie wsparcia przez producenta dla dotychczas uŝywanej wersji AppGate 4.0 wymusiło potrzebę aktualizacji Aktualizacja przeprowadzana jest w sposób płynny (od r. działają oba systemy bezpiecznego dostępu) System w wersji 4.0 będzie funkcjonował do r. Aplikacje: Archiwum WIRE, WIRE/RP i Archiwum SOWE dostępne będą pod nowym adresem http. Pod dotychczas uŝytkowanymi adresami pojawią się mechanizmy przekierowujące do nowych lokalizacji (wymaga aktualizacji wyjątków dla obsługi PROXY zgodnie z przesłaną instrukcją) Aplikacja CCO dostępna będzie tylko pod nowym adresem 43

44 Uruchomienie zmodernizowanego systemu SIRE systemy komunikacji WIRE/SOWE 44

45 Uruchomienie zmodernizowanego systemu SIRE systemy komunikacji WIRE/SOWE Architektura systemu (SIRE) SIRE Manager WebSphere MQ IPSec IPSec OR 1 Manager WebSphere MQ OR 2 Manager WebSphere MQ 45

46 Uruchomienie zmodernizowanego systemu SIRE systemy komunikacji WIRE/SOWE Architektura systemu zsire + SIRE Gateway SIRE Manager WebSphere MQ GATEWAY Manager WebSphere MQ zsire COA, COD IPSec IPSec OR 1 Manager WebSphere MQ OR 2 Manager WebSphere MQ Planowany termin uruchomienia r. 46

47 Uruchomienie zmodernizowanego systemu SIRE systemy komunikacji WIRE/SOWE Brak zmian w generacji potwierdzeń COA, COD Brak zmian po stronie systemów WIRE/UR, SOWE/EL Od : Archiwum WIRE i Aplikacja WIRE/RP dostępne pod nowym adresem http (wymagany AppGate 8.0) Archiwum SOWE dostępne pod nowym adresem http (wymagany AppGate 8.0) 47

48 Uruchomienie zmodernizowanego systemu SIRE systemy komunikacji WIRE/SOWE Architektura systemu zsire (uwzględniająca płynne przejście na SSL) SIRE Manager WebSphere MQ GATEWAY Manager WebSphere MQ zsire IPSec COA, COD COA, COD SSL OR 1 Manager WebSphere MQ OR 2 Manager WebSphere MQ Planowany termin rozpoczęcia przełączania na SSL r. Udostępniona zostanie aplikacja CCO (wymagany AppGate 8.0) 48

49 Uruchomienie zmodernizowanego systemu SIRE systemy komunikacji WIRE/SOWE Architektura systemu zsire (docelowo z wykorzystaniem SSL) zsire Manager WebSphere MQ SSL COA, COD SSL OR 1 Manager WebSphere MQ OR 2 Manager WebSphere MQ Planowany termin zakończenia przełączania r. 49

50 Podsumowanie 50

51 Dziękujemy za uwagę Energia w dobrych rękach