ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1
Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących w PSE Operator S.A. SPIS ZAWARTOŚCI ZAŁĄCZNIKA NR 2 DO CZĘŚCI II SIWZ: 1 ZESTAWIENIE ZASAD, STANDARDÓW I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.... 3 2 PODSTAWOWE WYTYCZNE WYNIKAJĄCE Z ZASAD, STANDARDÓW I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.... 5 2
1 ZESTAWIENIE ZASAD, STANDARDÓW I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. PSE S.A. posiada niżej opisany zestaw standardów, wytycznych i zaleceń odwzorowujący podejście do budowy platformy integracyjnej, stanowiący połączenie technologii wspierającej integrację systemów informatycznych, zbioru praktyk i procedur organizacyjnych oraz wzorców i standardów integracyjnych, zgodnie z którymi rozwiązania w obszarze integracji systemów teleinformatycznych PSE S.A. powinny być projektowane, implementowane i zarządzane. Obowiązujące standardy, wytyczne i zalecenia są zawarte w następujących opracowaniach, które zostaną udostępnione wybranemu Wykonawcy po podpisaniu umowy: 1. Referencyjna architektura logiczna Platformy Integracyjnej: 1.1. Model Strukturalny Architektury Integracyjnej. 1.2. Model Warstwowy referencyjnej Architektury Integracyjnej. 1.3. Architektura logiczna Serwisów i Procesów Integracyjnych. 1.4. Architektura logiczna Monitoringu przepływów integracyjnych. 2. Zasady architektoniczne i wzorce integracyjne: 2.1. Zasady projektowania usług i procesów integracyjnych oraz budowania dokumentów kanonicznych. 2.2. Standardy tworzenia Kanałów i Adapterów dla systemów dziedzinowych. 2.3. Standardy tworzenia Serwisów i Procesów. 2.4. Standardy nadawania nazw usługom, przepływom i kolejkom. 2.5. Standardy budowania komunikatów (w tym kanonicznych). 2.6. Standardy logowania komunikatów. 2.7. Standard nazewnictwa i tworzenia grup egzekucyjnych. 3. Reguły implementacji rozwiązań integracyjnych: 3.1. Standard organizacji przestrzeni nazw przepływów i dokumentów. 3.2. Standardy nazewnictwa obiektów IBM WebSphere Message Broker typu Broker, ExecutionGroup, QueueManager, Queue. 3
3.3. Reguły tworzenia jednolitego kodu przepływów zachowujące opracowane zasady i wzorce integracyjne. 3.4. Standard obsługi błędów, sytuacji wyjątkowych oraz logowania stanu przetwarzania. 3.5. Standard wersjonowania kodu. 3.6. Standard słownikowania atrybutów. 3.7. Standard mapowania. 3.8. Sposoby konfiguracji usług (WebService, Websphere MQ). 3.9. Zasady konfiguracji zabezpieczeń. 4. Procedura zarządzania zmianą w obszarze EAI: 4.1. Referencyjny model procesu wytwórczego przepływów w obszarze platformy integracyjnej EAI. 4.2. Referencyjny model zarządzania zmianą w Kanonicznym Modelu Danych (CDM), w tym opis ról i odpowiedzialności. 4.3. Szablon dokumentu specyfikującego wymagania dla przepływów integracyjnych. 4.4. Opis zasad monitorowania stanu realizacji usług integracyjnych. 4.5. Szablony dokumentów i modeli usług dostarczanych przez Wykonawców. 4.6. Zasady prowadzenia testów. 4
2 PODSTAWOWE WYTYCZNE WYNIKAJĄCE Z ZASAD, STANDARDÓW I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. EAI_001 Koncepcja integracji oparta jest o Strukturalny Model Architektury Integracyjnej obowiązujący w PSE S.A. (1.1. Model Strukturalny Architektury Integracyjnej). Centralną częścią architektury jest korporacyjna szyna usługowa ESB. Występuje ona jako element infrastruktury SOA, który dostarcza usługi pozwalające na przekazywanie wywołań serwisów oraz uruchomienie procesów pomiędzy Konsumentami a Dostawcami. EAI_002 Usługi i procesy integracyjne powinny być budowane zgodnie z obowiązującym w PSE S.A. warstwowym modelem architektury (1.2. Model Warstwowy referencyjnej Architektury Integracyjnej). Każdy przepływ PI (Kanał, Serwis/Proces, Adapter) powinien być przypisany do wydzielonej warstwy wyszczególnionej w hierarchicznym Modelu Warstwowym. EAI_003 Serwisy i Procesy powinny być budowane w oparciu o Logiczną Architekturę Serwisów i Procesów obowiązującą w PSE S.A. (1.3. Architektura logiczna Serwisów i Procesów Integracyjnych). Powinien zostać określony typ serwisu ( request-response, serwisy synchronizujące obiekty biznesowe pomiędzy wieloma systemami, serwisy publikujące obiekty biznesowe z jednego systemu do wielu) lub procesu (krótkotrwałe, długotrwałe), a jego realizacja dostosowana do logicznej architektury serwisów i procesów. EAI_004 Projektowanie usług i procesów realizujących usługi integracyjne powinno uwzględniać Logiczną Architekturę Monitoringu przepływów Integracyjnych (1.4. Architektura logiczna Monitoringu przepływów integracyjnych). Dla każdego przepływu powinny zostać wskazane kluczowe punkty monitoringu oraz powinno zostać określone działanie zgodne ze scenariuszami działania w przypadku wystąpienia sytuacji wyjątkowych. EAI _005 Komunikacja pomiędzy warstwami Architektury (uruchamianie przepływów) odbywa się zgodnie z określonymi przez PSE S.A. zasadami. (2.1. Zasady projektowania usług i procesów integracyjnych oraz budowania dokumentów kanonicznych). 5
Uruchamianie przepływów realizujących komunikacje pomiędzy warstwami powinno być zaprojektowane zgodnie z hierarchią w Warstwowym Modelu Architektury. EAI_006 Usługi i procesy w obszarze Platformy Integracyjnej są projektowane w oparciu o obiekty zdefiniowane w Kanonicznym Modelu Danych PSE S.A. (2.1. Zasady projektowania usług i procesów integracyjnych oraz budowania dokumentów kanonicznych). Zastosowanie KMD uniezależnia komunikację w ramach Platformy Integracyjnej od formatu komunikatów systemów dziedzinowych. EAI_007 Usługi integracyjne są tworzone zgodnie z obowiązującymi w PSE zasadami projektowania usług (2.1. Zasady projektowania usług i procesów integracyjnych oraz budowania dokumentów kanonicznych). Na przykład: Usługi powinny być niezależne od innych usług udostępnionych na PI. Usługa jest wykonywana w całości lub nie jest wykonywana w ogóle. EAI_008 Kanały i Adaptery należy tworzyć zgodnie z regułami tworzenia Kanałów i Adapterów obowiązujących w PSE S.A. (2.2. Standardy tworzenia Kanałów i Adapterów dla systemów dziedzinowych). Adapter powinien zapewnić interfejs i realizować usługi pokrywające cały zakres wymagań biznesowych stawianych PI w danej dziedzinie. EAI_009 Usługi i procesy integracyjne powinny być dostarczane wraz z dokładną dokumentacją, procedurami i scenariuszami testowymi (4.1. Referencyjny model procesu wytwórczego przepływów w obszarze platformy integracyjnej EAI). Dokumentacja powinna zawierać, co najmniej opis funkcjonalny, wymagania niefunkcjonalne, powinna wskazywać autorów oraz osoby odpowiedzialne za utrzymanie usługi/procesu. EAI_010 Usługi i procesy integracyjne powinny być projektowane zgodnie z ustalonymi QoS i umowami SLA (2.3. Standardy tworzenia Serwisów i Procesów). 6
Należy zapewnić wymaganą wydajność, dostępność i czasy odpowiedzi usług i procesów integracyjnych. EAI_011 Przepływy realizujące usługi i procesy integracyjne powinny obsługiwać wszystkie potencjalne sytuacje wyjątkowe ( 2.3. Standardy tworzenia Serwisów i Procesów). Należy wziąć pod uwagę wszystkie możliwe ścieżki w przepływie, np. komunikaty mogą ginąć, jeżeli nie są podłączone wszystkie terminale wyjściowe węzłów, lub kiedy komunikaty nie są persystentne. Należy przygotować odpowiednie scenariusze na wypadek awarii, np. czy komunikaty zalegające w bocznych kolejkach, do których trafiły po błędzie w przepływie, mają ostatecznie, po usunięciu awarii, trafić do systemu dziedzinowego, do którego były kierowane, czy mają zostać usunięte z tych kolejek. Należy się również zastanowić na nadawaniem czasu ważności komunikatom transportowanym przez Platformę Integracyjną. EAI_012 W PSE obowiązują ustalone standardy nazewnictwa usług, przepływów oraz kolejek (2.4. Standardy nadawania nazw usługom, przepływom i kolejkom). W PSE S.A. stosuje się hierarchiczny format nazewnictwa w oparciu o moduły biznesowe lub segmenty w języku angielskim. EAI_013 Komunikaty (w tym kanoniczne) przekazywane w obrębie PI posiadają określoną strukturę oraz są tworzone i utrzymywane zgodnie ze standardami obowiązującymi w PSE (2.5. Standardy budowania komunikatów). Każdy komunikat obsługiwany w ramach platformy integracyjnej posiada określoną strukturę logiczną i zawiera ustandaryzowany nagłówek. EAI_014 W PSE obowiązują ustalone standardy logowania komunikatów (2.6. Standardy logowania komunikatów). W razie konieczności logowania komunikatów transportowanych przez Platformę Integracyjną wykorzystuje się uniwersalne podprzepływy, które automatycznie wykonują archiwizację wiadomości w bazie danych. EAI_015 W PSE obowiązują ustalone reguły tworzenia i nazewnictwa grup egzekucyjnych (2.7. Standard nazewnictwa i tworzenia grup egzekucyjnych). 7
Grupy egzekucyjne powinny być tworzone z uwzględnieniem zagadnień: zrównoleglenia pracy, wydajności, bezpieczeństwa, rozmiaru komunikatu, współdzielenia funkcjonalności, zarządzania przepływami. EAI_016 W PSE obowiązują ustalone zasady organizacji przestrzeni nazw dla przepływów i dokumentów (3.1. Standard organizacji przestrzeni nazw przepływów i dokumentów). W PSE S.A. stosuje się hierarchiczny format nazewnictwa w oparciu o moduły biznesowe lub segmenty w języku angielskim EAI_017 W PSE S.A. obowiązują ustalone standardy nazewnictwa instancji brokerów, menadżerów kolejek, kanałów (3.2. Standardy nazewnictwa obiektów IBM WebSphere Message Broker typu Broker, ExecutionGroup, QueueManager, Queue). W PSE S.A. stosuje się hierarchiczny format nazewnictwa w oparciu o moduły biznesowe lub segmenty w języku angielskim EAI_018 W PSE obowiązują ustalone zasady dotyczące nazewnictwa komentowania, wersjonowania oraz formatowania kodu źródłowego ESQL. (3.3. Reguły tworzenia jednolitego kodu przepływów zachowujące opracowane zasady i wzorce integracyjne; 3.5. Standard wersjonowania kodu). Jednolite zasady tworzenia kodu źródłowego zwiększają czytelności implementacji oraz narzucają wielokrotne wykorzystanie komponentów. EAI_019 W PSE S.A. obowiązują ustalone standardy logowania błędów, sytuacji wyjątkowych oraz standardowych na Platformie Integracyjnej (3.4. Standard obsługi błędów, sytuacji wyjątkowych oraz logowania stanu przetwarzania). Do monitorowania stanu procesów i usług na Platformie Integracyjnej stosowane są pliki logów oraz baza danych. EAI_020 Podczas tworzenie słowników oraz specyfikacji reguł mapowania obiektów z natywnych modeli danych na używany w obrębie PI Kanoniczny Model należy przestrzegać standardów słownikowania i mapowania atrybutów obowiązujących w PSE S.A. (3.6. Standard słownikowania atrybutów; 3.7. Standard mapowania). 8
W przypadku złożonych usług mapowanie pól i atrybutów obiektów, również słownikowanych, odbywa się za pomocą kodu ESQL lub użycia usługi zewnętrznej względem brokera. EAI_021 Konfiguracja usług wykonywana jest na podstawie określonych parametrów podłączenia się do usługi oraz wyspecyfikowanych parametrach wejściowych i wejściowych (3.8. Sposoby konfiguracji usług (WebService, Websphere MQ). Wszystkie informacje dotyczące usługi opisuje Metryka Usługi. EAI_022 Projektowane usługi i procesy integracyjne powinny zapewniać wymagany przez PSE S.A. poziom bezpieczeństwa integracji (3.9. Zasady konfiguracji zabezpieczeń). Należy spełnić wymagany sposób uwierzytelniania oraz autoryzacji Konsumentów i Dostawców usług. Należy zapewnić wymaganą poufność i integralność danych transportowanych przez PI. EAI_023 W PSE S.A. obowiązuje ujednolicony proces prowadzenia inicjatyw projektowych dotyczących zmian na Platformie Integracyjnej obejmujący: Definicję ról. Definicję zadań. Listę dokumentacji projektowej. (4.1. Referencyjny model procesu wytwórczego przepływów w obszarze platformy integracyjnej EAI). Podczas wdrożeń na Platformie Integracyjnej należy stosować się do zdefiniowanego procesu wytwórczego. Zunifikowany proces wytwórczy pozwala na prowadzenie projektów w sposób metodyczny i wpływa pozytywnie na rezultaty prowadzonych prac. EAI_024 Dokumentacja projektowa dostarczana przez Dostawcę powinna być zgodna ze zdefiniowanymi w PSE S.A. szablonami dokumentów (4.3. Szablon dokumentu specyfikującego wymagania dla przepływów integracyjnych, 4.5. Szablony dokumentów i modeli usług dostarczanych przez Wykonawców). Zdefiniowane szablony dokumentów obejmują komplet dokumentacji dla zmian wprowadzanych na PI. Stosowanie zdefiniowanych szablonów dokumentów ma na celu zapewnienie kompletności i jakość dostarczanej dokumentacji projektowej. 9
EAI_025 Kanoniczny Model Danych PSE S.A. powinien opierać się na modelu CIM zawierającym referencyjny model danych dla przemysłu elektroenergetycznego (4.2. Referencyjny model zarządzania zmianą w Kanonicznym Modelu Danych (CDM), w tym opis ról i odpowiedzialności). Projektując Kanoniczny Model Danych PSE S.A. należy korzystać z modelu CIM. Zastosowanie referencyjnego modelu danych gwarantuje jego spójność i zgodność KDM ze standardami przemysłowymi. EAI_026 Kanoniczny Model Danych PSE S.A. jest utrzymywany centralnie w narzędziu Sparx Enterprise Architect. (4.2. Referencyjny model zarządzania zmianą w Kanonicznym Modelu Danych (CDM), w tym opis ról i odpowiedzialności) Kanoniczny Model Danych PSE S.A. musi być udokumentowany z wykorzystaniem narzędzia Sparx Enterprise Architect. EAI_027 W PSE S.A. obowiązują zasady rozwijania Kanonicznego Modelu Danych PSE S.A. (4.2. Referencyjny model zarządzania zmianą w Kanonicznym Modelu Danych (CDM), w tym opis ról i odpowiedzialności) Nowe obiekty Kanonicznego Modelu Danych i zmiany w istniejących obiektach muszą być projektowane i wprowadzane zgodnie z ustalonymi w PSE S.A. zasadami. EAI_028 W PSE S.A. obowiązują zasady monitorowania postępu prac na Platformie Integracyjnej (4.4. Opis zasad monitorowania stanu realizacji usług integracyjnych). W trakcie wprowadzania zmian na PI należy stosować zdefiniowane w PSE S.A zasady komunikacji i monitorowania postępu prac. EAI_029 Podczas prowadzenia testów na PI należy stosować przyjętą w PSE Operator S.A. organizację środowisk testowych (4.6. Zasady prowadzenia testów). Organizacja środowisk testowych PI powinna wspierać wykonanie testów wewnętrznych PI oraz testów integracyjnych z wykorzystaniem integrowanych systemów. EAI_030 Zakres testów wykonywanych na PI musi obejmować testy jednostkowe, testy integracyjne PI, w tym testy regresji, oraz opcjonalnie testy wydajnościowe. Wykonawca musi wspierać wykonanie testów procesowych (4.6. Zasady prowadzenia testów). 10
Wymagany zakres testów powinien być uzgodniony przed rozpoczęciem testów. W ramach wykonania testów na PI należy udokumentować przebieg i rezultat poszczególnych etapów. Wykonanie zdefiniowanego zakresu testów gwarantuje poprawne działanie oprogramowania uruchamianego na PI. EAI_031 Podczas testowania zmian na PI należy stosować narzędzia wspierające testy będące standardem w PSE S.A.: soapui, JMeter, JUnit (4.6. Zasady prowadzenia testów) W ramach dokumentacji testów muszą zostać przekazane do PSE S.A. skrypty testowe dla wykorzystanych narzędzi testowych. Stosowanie wspólnego zestawu narzędzi testowych zwiększa powtarzalność testów, ich automatyzację a w rezultacie wpływa pozytywnie, na jakość oprogramowania uruchamianego na Platformie Integracyjnej. EAI_032 Testy wykonywane na PI powinny w jak największym stopniu opierać się na wykorzystaniu zaślepek do systemów dziedzinowych (4.6. Zasady prowadzenia testów). Elementem przygotowania do testów jest utworzenie zaślepek i symulatorów dla interfejsów integrowanych systemów dziedzinowych. Wykorzystanie zaślepek i symulatorów uniezależnia wykonanie testów wewnętrznych PI od rozwoju i zmian wprowadzanych w systemach dziedzinowych. 11