Automatyczne testy regresji – rozwiązanie „szyte na miarę” – cz. 3 – prezentacja przyjętego rozwiązania

18.07.2024 |  Paweł Krakowczyk

Z artykułu dowiesz się

• Jakie były założenia biznesowe i techniczne dla projektu
• Jak przebiega proces krok po kroku.

Rozwiązanie wybrane do projektu Bazylea IV

Zgodnie z decyzją biznesu, do projektu Bazylea IV w banku wybraliśmy taki wariant, w którym zmiany zarówno po stronie Hurtowni danych i przygotowywania ekstraktów z danymi źródłowymi do raportów, jak również po stronie samej aplikacji od dostawcy są wprowadzane bezpośrednio w wersji produkcyjnej. To rozwiązanie ryzykowne ze względu na liczbę wprowadzanych modyfikacji zarówno po stronie mapowania danych w Hurtowni danych jak również aplikacji – gdzie każda zmiana praktycznie może mieć negatywny wpływ na inne raporty generowane tym samym rozwiązaniem. Trudnością są też liczne zmiany związane z projektem Bazylea IV, rozwijane równolegle w tych samych źródłach, a światło dzienne zobaczą dopiero za kilka miesięcy. W tym czasie ważne jest, aby nie miało to negatywnego wpływu na przygotowywane wersje produkcyjne raportów. Zgodnie z decyzją biznesu wybór wariantu jest warunkowy i uzależniony od poprawnej implementacji proponowanych przez zespół IT w banku oraz dostawcę rozwiązań:

1. Teleportacja w przyszłość – ekstrakty z danymi z roku 2020 będą poddane automatycznemu mechanizmowi przesunięcia w czasie do roku 2048, który cechuje podobny układ dni tygodnia oraz liczbę dni w roku – ma to wpływ na datę obowiązywania nowych szablonów raportów, które po raz pierwszy zostaną zaraportowane za okres 2021-06 – mechanizm dostarczany po stronie aplikacji dostawcy
2. Testy regresji raportów w aplikacji – dostawca dostarczy rozwiązanie testujące zmiany w raportach pole po polu, raport po raporcie względem wyników referencyjnych. Umożliwi to weryfikację wprowadzanych zmian w konkretnych raportach w konkretnych polach oraz brak zmian w pozostałych raportach
3. Testy regresji ekstraktów na Hurtowni danych – zapewnimy automatyczne testowanie zmian wprowadzanych w projekcie Bazylea IV pod kątem niechcianych zmian w pozostałych raportach produkcyjnych. Przykładowo: wprowadzane zmiany mają dotyczyć tylko NSFR3 i dla nich raport różnicowy powinien zwracać wyniki, natomiast w przypadku generacji pozostałych typów ekstraktów raport różnicowy powinien być pusty – tzn. nie zawierać żadnych różnic względem wygenerowanych danych ekstraktów referencyjnych przed wprowadzeniem zmiany (LCR3, LCR, NSFR).

Wszystkie zmiany po wykonaniu testów powinny być możliwe do wdrożenia produkcyjnego.

Założenia wdrażanego wariantu

Aby móc opisać założenia biznesowe automatycznych testów regresji (zebrane podczas spotkań z dostawcą nad nowym projektem NSFR3), przedstawimy w kilku zdaniach sposób implementacji nowego rozwiązania generacji ekstraktów. To na podstawie tego rozwiązania zrodziła się potrzeba weryfikacji obowiązujących obecnie raportów biznesowych, które nie powinny ulec zmianie. Przyjęliśmy rozwiązanie, które:

• minimalizuje prace na etapie implementacji
• jest łatwe w utrzymywaniu kodu i ewentualnych zmian w przyszłości
• bazuje na tym samym pakiecie bazodanowym, tabelach sterujących zadaniami oraz zależnościami między nimi
• zawiera niezależne widoki oraz tabele w obszarach, w których NSFR3 się będzie różnił od dotychczasowego NSFR. Widoki oraz pomocnicze tabele będą zawierały dopisek ‘_NSFR3’, np. jeżeli wcześniej zadanie miało postać:

INSERT INTO TABELA_1 SELECT FROM WIDOK_1; COMMIT;

to po zmianach będzie wyglądało:

IF WERSJA = 3 THEN
    INSERT INTO TABELA_1_NSFR3 SELECT FROM WIDOK_1_NSFR3; 
ELSE
    INSERT INTO TABELA_1 SELECT FROM WIDOK_1;
COMMIT;

• do funkcji generujących ekstrakty ma dodany dodatkowy parametr z informacją o wersji (dotychczas nie było wersjonowania, dlatego przyjęto jako dotychczasową wersję 0 - domyślną). Nowa wersja - 3 - zacznie obowiązywać od raportowania za czerwiec 2021 i wtedy stanie się domyślną wersją. W zadaniach bazodanowych jest parametr z wersją do przełączania zasilania konkretnych różnych obszarów tak, aby w zależności od potrzeby wygenerować albo ekstrakty w dotychczasowej formie, albo na potrzeby testowania nowego rozwiązania NSFR3 (LCR dzienny lub LCR/NSFR miesięczny). Przyjęliśmy biznesowe kody tych przetwarzań opisane w tabeli konfiguracyjnej (opiszemy ją poniżej).

Takie rozwiązanie umożliwia łatwe zarządzanie generacją ekstraktów w obecnych dwóch wersjach, a w przyszłości rozszerzanie o dowolną liczbę wersji – oraz separację widoków i tabel per wersja, w zależności od potrzeby biznesowej. Obecnie za pomocą jednej funkcji można wywoływać generację wszystkich typów ekstraktów: 

funkcja GENERUJ_EKSTRAKTY( TYP, WERSJA [default = 0] )

Dla przykładu:

• LCR → GENERUJ_EKSTRAKTY( LCR )
• LCR3 → GENERUJ_EKSTRAKTY( LCR, 3 )
• NSFR → GENERUJ_EKSTRAKTY( NSFR )
• NSFR3 → GENERUJ_EKSTRAKTY( NSFR, 3 ).

Założenia biznesowe testów regresji

1. Możliwość wchodzenia etapami na środowisko produkcyjne (PRD) - ze względu na brak pokrycia danymi zaciemnionymi na UAT wszystkich obszarów raportowych jest konieczność umożliwienia równoległego testowania niektórych obszarów w warunkach PRD, z zachowaniem jak największej izolacji dotychczasowych rozwiązań od mechanizmów generujących bieżące ekstrakty produkcyjnie (z uwzględnieniem LCR dziennego).
2. Możliwość uruchomienia ATRE na PRD - ATRE powinny być „niezauważalne” dla procesów produkcyjnych - tzn. nie powinny mieć wpływu na bieżące prace produkcyjne, nie mogą dodatkowo obciążać i wydłużać czasu generowania ekstraktów produkcyjnych.
3. Potwierdzenie braku zmian w bieżących ekstraktach podczas pracy nad NSFR3 - to główne założenie, które przyświecało powstaniu rozwiązania. Same ekstrakty to tabele płaskie. Jeżeli potwierdzimy biznesowi niezmienność tych danych w procesie generowania dotychczasowych ekstraktów po wdrożeniu zmian do NSFR3, wykluczy to konieczność generacji tych ekstraktów i testowania ich na aplikacji. Jednostki biznesowe mogą cyklicznie testować zmiany w aplikacji dostarczanej przez dostawcę na wcześniejszych ekstraktach bez konieczności każdorazowego generowania ekstraktów, które i tak się nie zmieniły (zgodnie z raportem testów).

Realizacja - referencja

Automatyczne testy regresji w pierwszym kroku wymagają utworzenia referencji, względem której będą porównywały kolejne wywołania testów. Referencja może powstać na jeden z dwóch możliwych sposobów:

1. Podczas pierwszego uruchomienia ATRE - jeżeli system nie znajdzie referencji, wtedy pierwsze uruchomienie dla danego typu ekstraktów potraktuje jako referencję
2. Control-M Self Service - jeżeli uważamy, że przetworzone ekstrakty odzwierciedlają poprawnie zaimplementowane zmiany, których oczekiwaliśmy (czyli po wprowadzonej zmianie, która przeszła pomyślnie testy i gotowa jest do wdrożenia na PRD, lub po wdrożeniu na PRD zmiany - jeżeli mówimy o środowisku produkcyjnym), wtedy możemy sami ustawić nową referencję za pomocą udostępnionych serwisów w Control-M dedykowanych do zarządzania ATRE LIREP. 

UWAGA: Ustawienie nowej referencji spowoduje usunięcie pozostałych przetwarzań danego typu ekstraktów.

Ustawienie referencji zostanie potwierdzone takim mailem (szczegóły powiadomień zostały opisane w dalszej części):

Maile z powiadomieniami mają w tytule celowo wspólny prefiks definiujący:

• aplikację źródłową, funkcjonalność  oraz pochodzenie [XXXXX_ATRE][DWH] 
• status/typ powiadomienia:
  • [REF] – referencja
  • [SUCCESS] – testy zakończone sukcesem (wyjaśnienie poniżej)
  • [DIFFERENCES] – znaleziono różnice względem referencji

Oraz

• typ ekstraktu [LCR/NSFR/LCR3/NSFR3]
• datę przetwarzania – gdyż istnieje możliwość zdefiniowania różnych dat dla każdego typu ekstraktów.

Warto zwrócić uwagę na stopkę maila. Podana jest w niej instancja bazy danych, z której powiadomienie zostało wysłane. Ma to o tyle znaczenie, jeżeli testy mają być przeprowadzane na więcej niż jednym środowisku, np. testowym oraz produkcyjnym.

Sukces

Oczywiście sukcesem może być poprawne zaimplementowanie zmian w mechanizmie generowania ekstraktów, który tak naprawdę wykaże w testach różnice względem ekstraktu. W ATRE przyjęliśmy, że sukcesem będzie sytuacja, w której wszystkie wygenerowane ekstrakty będą identyczne do swoich referencyjnych odpowiedników.

W powiadomieniu dodatkowo pojawia się raport w postaci HTML, który obrazuje szczegóły testów. W nazwie raportu znajduje się biznesowy identyfikator przetwarzania, aby można było łatwo go powiązać z konkretnymi ekstraktami w aplikacji.
Raport HTML skromnie przedstawia tylko najważniejsze informacje: 

• datę przetwarzania
• typ ekstraktów (ze słownika z konfiguracją)
• sposób uruchomienia
• wynik testu 
• czasy realizacji testów (poglądowo). 

Poniżej zestawienie testowego przetwarzania względem referencji. Na zrzucie zmieściły się tylko 2 z 16 ekstraktów - wszystkie z nich muszą „świecić się” na zielono. Po lewej stronie jest menu, na którym w przypadku różnic w ekstraktach pojawią się tylko te ekstrakty, w których wykryto jakiekolwiek różnice. W przypadku sukcesu jest widoczne tylko podsumowanie.

Różnice

W przypadku wykrytych różnic powiadomienie wygląda następująco:

W załącznikach pojawia się dodatkowo plik XLSX, zgodnie z założeniami technicznymi (opisanymi wyżej).

Raport HTML również prezentuje różnice - w tym przypadku testowo tylko w ekstrakcie ELA.

Po kliknięciu w ekstrakt ELA z podsumowania, lub wybranie go z menu po lewej stronie, w raporcie pojawi się odpowiednia informacja. Jeżeli różnic będzie więcej niż przyjętych 50, wtedy raport odwoła nas do stosownego miejsca (załączonego raportu XLSX lub bazy danych w przypadku jeszcze większej liczby różnic).

„Liczba różnych rekordów” to rekordy, które występują w jednym ekstrakcie, a brakuje ich w drugim. „Liczba niedopasowanych rekordów” określa te pozycje, dla których nie udało się znaleźć odpowiednika w drugim ekstrakcie (prawdopodobnie ze względu na dodanie lub usunięcie rekordu).

Szczegółowe dane różnych rekordów (w odpowiedniej ilości) są załączone w postaci XLSX. Ważne, aby odróżnić rekordy testowego przetwarzania od referencyjnego - SEQ_ID (-1 - referencja, -2 - testowe przetwarzanie). Dodatkowo w zakładce drugiej jest zapytanie, za pomocą którego te dane zostały pobrane z bazy danych.

Od kuchni… struktury tabel

Obecnie ATRE korzystają z 21 tabel, które można podzielić na dwie grupy: 

• tabele z danymi ekstraktów (16)
• tabele techniczne (5).

Tabele ekstraktów

Tabele ekstraktów mają identyczny zestaw kolumn z ich typami, co ich odpowiedniki w systemie. Każda z nich jest jeszcze dodatkowo poprzedzona 3 identycznymi w każdym ekstrakcie kolumnami:

1. SEQ_ID -  identyfikator techniczny
2. INDX - unikalny identyfikator każdego wiersza
3. ROW_NUM - numer wiersza

Każda z tabeli ekstrakcyjnych posiada dwa indeksy unikalne po kolumnach, wykorzystywane w celu optymalizacji poszukiwania różnic.

1. SEQ_ID, INDX
2. SEQ_ID, ROW_NUM

Dodatkową właściwością, która łączy wszystkie tabele ekstraktów jest partycjonowanie po SEQ_ID.

UWAGA: w przypadku zmiany definicji tabel z ekstraktami należy pamiętać o ich odpowiednikach w ATRE.
ATR_ELA
ATR_ERI
ATR_HAR
ATR_LZA
ATR_OPE
ATR_RKZ
ATR_ZAB
ATR_EKW
ATR_IBH_ELA
ATR_IBH_ERI
ATR_IBH_HAR
ATR_IBH_LZA
ATR_IBH_OPE
ATR_IBH_RKZ
ATR_IBH_ZAB
ATR_IBH_EKW

Tabele techniczne

Pozostałe tabele techniczne to:
ATR_CONFIG
ATR_DIFF_REC
ATR_DIFF_REC_BALANCE
ATR_EXECUTION
ATR_HISTORY

ATR_CONFIG

Pierwsza tabela ATR_CONFIG to słownik typów ekstraktów, który przechowuje również ich parametry konfiguracyjne:

Dwa dodatkowe parametry określają automatyczne uruchamianie testów:

• ENABLE - w trakcie generowania ekstraktów
• ENABLE_SCHEDULE - wg harmonogramu

Obsługiwane wartości: 0 - wyłączone, 1 - włączone.

W trakcie generowania ekstraktów - oznacza, że podczas generowania danego typu ekstraktów będą w tle uruchamiane testy z raportowaniem bieżących zmian. To ma zastosowanie np. wtedy, gdy chcemy sprawdzić, czy zmiany, nad którymi obecnie pracujemy, mają swoje odzwierciedlenie w wygenerowanych w ekstraktach danych. Może to pozwolić w miarę szybko wychwycić błędy bez oczekiwania na wygenerowanie przez aplikację raportów.

Wg harmonogramu – mamy dodatkowe zadanie na bazie danych, które jest uruchamiane od poniedziałku do piątku w godzinach wieczornych. Zadanie opisane niżej dla typów ekstraktów, które w konfiguracji mają ustawioną flagę ENABLE_SCHEDULE = 1, uruchamia generowanie samych danych do ekstraktów (bez zapisywania ich do pliku i wysyłania wewnętrznym transferem bankowym na serwer aplikacyjny), aby przeprowadzić na nich testy regresji. Ważne jest, dla którego ten mechanizm został zaimplementowany. Podczas prac nad nowym NSFR3 możemy każdego dnia otrzymywać potwierdzenie, że „nie zepsuliśmy” nic w dotychczasowych ekstraktach, które powinny pozostać bez zmian. W zasadzie wszystkie ekstrakty poza NSFR3 powinny mieć flagę ustawioną na 1. Dzięki temu oszczędzamy czas podczas wdrażania równolegle wielu zmian przez kilku programistów równolegle – nie uruchamiamy testów po zaimplementowaniu każdej zmiany.

ATR_DIFF_REC, ATR_DIFF_REC_BALANCE

Obie tabele służą wyłącznie do parowania wierszy ekstraktu testowanego i ekstraktu referencyjnego. Istotne są tylko te wiersze w jednej i drugiej tabeli, które nie mają swojego odpowiednika w drugiej tabeli. Tabela ATR_DIFF_REC_BALANCE przechowuje wszystkie możliwe kombinacje tych wierszy (każdy z każdym). Dla każdej pary wylicza wagę, według wcześniej opisanego wzoru. Następnie na jej podstawie po sortowaniu dopisuje pary do tabeli ATR_DIFF_REC w taki sposób, aby żaden z wierszy tabeli referencyjnej ani testowanej się nie powtórzył. Pozostałe niedopasowane wiersze traktowane są jako nowo dodane. To algorytm, który może być dowolnie modyfikowany i czas zweryfikuje jego zasadność, o ile testy będą służyły analizie. Różnice są istotne dla analizy, a ich brak jest ważny pod względem biznesowym.

ATR_EXECUTION, ATR_HISTORY

Obie tabele w zasadzie są bliźniacze (mają dokładnie taki sam zestaw kolumn). Różni je to, że ATR_EXECUTION przechowuje tylko informacje o ekstraktach aktualnie przechowywanych w bazie i jest cyklicznie czyszczona wraz z nadpisywanymi ekstraktami. ATR_HISTORY przechowuję całą historię wykonanych testów.

KOLUMNA	TYP	OPIS
SEQ_ID	INTEGER	identyfikator techniczny
EXEC_ID	VARCHAR2(13)	identyfikator biznesowy
T_EXECUTION	VARCHAR2(10)	typ ekstraktów (ARES.ATR_CONFIG.T_EXECUTION)
T_TEST	VARCHAR2(1)	typ uruchomienia testu: 0 - wg harmonogramu, 1 - w trakcie generacji ekstraktów, 2 - test uruchomiony ręcznie
TEST_TIME	INTEGER	czas trwania testu (w sekundach)
DATA_PREPARE_TIME	INTEGER	czas trwania przygotowania danych do testu (w sekundach)
DATA_ANALYZE_TIME	INTEGER	czas trwania analizy danych testu (w sekundach)
DATA_DANYCH	INTEGER	data danych (YYYYMMDD)
ADD_DATE	DATE	data testu
R_SEQ_ID	INTEGER	identyfikator techniczny referencji
R_EXEC_ID	VARCHAR2(13)	identyfikator biznesowy referencji
R_ADD_DATE	DATE	data testu referencji
REPORT	CLOB	raport HTML (który jest wysyłany jako załącznik na maila)
ELA_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu ELA
ELA_COUNT	INTEGER	liczba wierszy ekstraktu ELA
ELA_TIME	INTEGER	czas testowania ekstraktu ELA
ERI_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu ERI
ERI_COUNT	INTEGER	liczba wierszy ekstraktu ERI
ERI_TIME	INTEGER	czas testowania ekstraktu ERI
HAR_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu HAR
HAR_COUNT	INTEGER	liczba wierszy ekstraktu HAR
HAR_TIME	INTEGER	czas testowania ekstraktu HAR
LZA_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu LZA
LZA_COUNT	INTEGER	liczba wierszy ekstraktu LZA
LZA_TIME	INTEGER	czas testowania ekstraktu LZA
OPE_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu OPE
OPE_COUNT	INTEGER	liczba wierszy ekstraktu OPE
OPE_TIME	INTEGER	czas testowania ekstraktu OPE
RKZ_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu RKZ
RKZ_COUNT	INTEGER	liczba wierszy ekstraktu RKZ
RKZ_TIME	INTEGER	czas testowania ekstraktu RKZ
ZAB_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu ZAB
ZAB_COUNT	INTEGER	liczba wierszy ekstraktu ZAB
ZAB_TIME	INTEGER	czas testowania ekstraktu ZAB
EKW_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu EKW
EKW_COUNT	INTEGER	liczba wierszy ekstraktu EKW
EKW_TIME	INTEGER	czas testowania ekstraktu EKW
IBH_ELA_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu ELA_IBH
IBH_ELA_COUNT	INTEGER	liczba wierszy ekstraktu ELA_IBH
IBH_ELA_TIME	INTEGER	czas testowania ekstraktu ELA_IBH
IBH_ERI_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu ERI_IBH
IBH_ERI_COUNT	INTEGER	liczba wierszy ekstraktu ERI_IBH
IBH_ERI_TIME	INTEGER	czas testowania ekstraktu ERI_IBH
IBH_HAR_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu HAR_IBH
IBH_HAR_COUNT	INTEGER	liczba wierszy ekstraktu HAR_IBH
IBH_HAR_TIME	INTEGER	czas testowania ekstraktu HAR_IBH
IBH_LZA_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu LZA_IBH
IBH_LZA_COUNT	INTEGER	liczba wierszy ekstraktu LZA_IBH
IBH_LZA_TIME	INTEGER	czas testowania ekstraktu LZA_IBH
IBH_OPE_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu OPE_IBH
IBH_OPE_COUNT	INTEGER	liczba wierszy ekstraktu OPE_IBH
IBH_OPE_TIME	INTEGER	czas testowania ekstraktu OPE_IBH
IBH_RKZ_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu RKZ_IBH
IBH_RKZ_COUNT	INTEGER	liczba wierszy ekstraktu RKZ_IBH
IBH_RKZ_TIME	INTEGER	czas testowania ekstraktu RKZ_IBH
IBH_ZAB_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu ZAB_IBH
IBH_ZAB_COUNT	INTEGER	liczba wierszy ekstraktu ZAB_IBH
IBH_ZAB_TIME	INTEGER	czas testowania ekstraktu ZAB_IBH
IBH_EKW_CHECKSUM	VARCHAR2(32)	suma kontrolna ekstraktu EKW_IBH
IBH_EKW_COUNT	INTEGER	liczba wierszy ekstraktu EKW_IBH
IBH_EKW_TIME	INTEGER	czas testowania ekstraktu EKW_IBH

UWAGA: skąd system wie, który SEQ_ID jest referencją, skoro nie ma takiej kolumny? 

Tam, gdzie brakuje informacji o referencji (R_SEQ_ID jest puste), dla systemu oznacza, że takie przetwarzanie jest referencją.

Mózg operacji, czyli pakiet bazodanowy PKG_ATR

Pakiet PKG_ATR to centrum sterowania testami. Tutaj zaszyta jest cała logika.

Ciekawostka: pomiędzy pakietem PKG_ATR, a pakietem PKG_GEN_ADM (generacja ekstraktów) istnieje wzajemna zależność (wzajemnie się uruchamiają – opisujemy to niżej). W przypadku pierwszej instalacji takich obiektów ważne jest, aby zastosować „myk” z wydmuszką (pustym pakietem o tej samej nazwie), żeby nie pojawiły się błędy kompilacji. Taka instalacja zakończy się błędem.

Stałe

• gc_MAX_NUMBER_EXECUTIONS_MEMORY INTEGER:=5; → liczba przechowywanych szczegółów wykonanych testów ekstraktów per typ ekstraktu (z wyłączeniem referencji)   
• gc_MAX_NUMBER_DIFF_RAPORT INTEGER:=50; → maksymalna liczba różnic w ekstrakcie, dla której sporządzany jest szczegółowy raport różnic    
• gc_MAX_NUMBER_DIFF_EXCEL INTEGER:=500; → maksymalna liczba różnic w ekstrakcie, dla której przygotowana jest lista w EXCEL dołączana do raportu    
• gc_DIFF_R_SEQ_ID INTEGER:=-1; → identyfikator techniczny, pod którym są zapisywane różnice w ekstraktach (rekordy występujące w referencji, brakujące w teście)
• gc_DIFF_SEQ_ID INTEGER:=-2; → identyfikator techniczny, pod którym są zapisywane różnice w ekstraktach (rekordy występujące w teście, brakujące w referencji)    
• gc_DIR_NAME VARCHAR2(100) := 'CBE_LOC_XLSX_TRG_LOC'; → katalog załączników - tutaj przechowywane są szablony do tworzenia raportów HTML oraz szablon raportu XLSX, tutaj również zapisywane są tymczasowo załączniki do wiadomości z powiadomieniami

„Prawdziwy” interfejs pakietu PKG_ATR

Co tak naprawdę jest konieczne i uruchamiane na zewnątrz pakietu:

pAutoRunATR

Procedura automatycznie uruchamia ATRE po zakończeniu generowania ekstraktów (wywoływana z pakietu PKG_GEN_ADM).
Parametry:

1. p_DATA_DATE NUMBER → data przetwarzania
2. p_T_EXECUTION VARCHAR2 → typ przetwarzania (ATR_CONFIG.T_EXECUTION)
3. p_EXEC_ID VARCHAR2 → unikalny identyfikator biznesowy przetwarzania

pRunATR

Procedura uruchamia ATRE (wykorzystywana np. w Control-M Self Service, tudzież w tabeli z definicjami zadań do generacji ekstraktów)

Parametry:

1. p_DATA_DATE NUMBER
2. p_T_EXECUTION VARCHAR2
3. p_EXEC_ID VARCHAR2
4. p_T_TEST INTEGER

pRunJob

Procedura uruchamia zadanie DAILY_ATRE_JOB wg harmonogramu testów.  

pSetCfg

Procedura ustawia parametry konfiguracyjne, referencję

Parametry:

1. p_T_EXECUTION VARCHAR2 → typ przetwarzania (ATR_CONFIG.T_EXECUTION, wymagany tylko w przypadku podania p_R_SEQ_ID)
2. p_DATA_DATE NUMBER → nowa data przetwarzania (parametry nie wymagany)
3. p_R_SEQ_ID NUMBER → nowy identyfikator referencji (parametry nie wymagany)
4. p_ENABLE NUMBER → czy uruchamiać po wygenerowaniu ekstraktów (parametry nie wymagany)
5. p_ENABLE_SCHEDULE NUMBER → czy uruchamiać zgodnie z harmonogramem (parametry nie wymagany).

Harmonogram testów - definicja

Za uruchamianie ATRE odpowiedzialne jest zadanie DAILY_ATRE_JOB, ustawione od poniedziałku do piątku na godz. 22. Definicja zadania jest bardzo skromna: 

BEGIN SCHEMAT.PKG_ATRE.pRunJob; END;

Uruchamianie/konfiguracja z poziomu Control-M Self Service

Zarządzanie ATRE jest możliwe albo bezpośrednio pod bazą danych (przez dyżurnych aplikacji), albo za pomocą udostępnionych serwisów w Control-M Self Service (dla biznesu oraz analityków). Serwisy zostały udostępnione zarówno na środowisku UAT jak i PRD:

• WAZIS_LIREP_ATRE_CFG_PRD
• WAZIS_LIREP_ATRE_CFG_UAT
• WAZIS_LIREP_ATRE_EXE_PRD
• WAZIS_LIREP_ATRE_EXE_UAT
• WAZIS_LIREP_ATRE_REF_PRD
• WAZIS_LIREP_ATRE_REF_UAT

Serwisy PRD są bliźniaczym odbiciem serwisów UAT, dlatego skupimy się na omówieniu jednych, tych na środowisku UAT.

WAZIS_LIREP_ATRE_CFG_UAT
Serwis odpowiedzialny za konfigurację ATRE jak również za ustawienie referencji.

Kolejne parametry:

• Typ przetwarzania → wartości z listy: LCR, NSFR, LCR3, NSFR3 - parametr nie jest wymagany. UWAGA: jeżeli go nie wybierzemy, poniższe ustawienia (przynajmniej jedno jest wymagane) zostaną zastosowane do wszystkich typów ekstraktów.
• Data danych [YYYYMMDD] → data danych, na której aktualnie mają być uruchamiane ATRE - ten parametr ma tylko zastosowanie w przypadku, gdy dany typ przetwarzania ma włączoną opcję „Czy uruchamiać wg harmonogramu”.
• Czy uruchamiać automatycznie po przetworzeniu ekstraktów? → wartości z listy: Yes, No. 
  • Yes → po każdej próbie wygenerowania ekstraktów danego typu zostaną automatycznie uruchomione również testy
  • No → ustawiamy wtedy, gdy chcemy wyłączyć testowanie.

Domyślnie wszystkie przetwarzania są ustawione na No).

• Czy uruchamiać wg harmonogramu? → wartości z listy: Yes, No
  • Yes → dany typ przetwarzania będzie zakolejkowany do uruchomienia wg harmonogramu (patrz rozdział Harmonogram testów - definicja). 
  • No → wyłączenie danego typu przetwarzania z testowania wg harmonogramu.

Domyślnie wszystkie przetwarzania są ustawione na No. 

UWAGA: ustawienie parametru na Yes wymaga, aby dany typ miał sprecyzowaną datę, na którą ma przetwarzać ekstrakty - w przeciwnym wypadku przetwarzanie zakończy się błędem.

Jest to bardzo mało elegancki sposób do zarządzania ustawieniami (nie mamy podglądu na aktualny stan). Na potrzeby prostych testów jest jednak wystarczający, a narzędzie jest ogólnodostępne i nie wymaga pisania specjalnego frontu. Nie powinno się też często zmieniać (poza datą). Po odpowiedniej konfiguracji wszyscy zainteresowani dostają e-mail z aktualnymi ustawieniami dla wszystkich typów (w dalszej części opisujemy też powiadomienia). Jeżeli nie wprowadzimy żadnego ustawienia, zostanie wysłany tylko mail z aktualnymi ustawieniami (to taka ukryta funkcjonalność, tylko dla czytelników tej dokumentacji 😉).

WAZIS_LIREP_ATRE_EXE_UAT

Serwis do uruchamiania ATRE.

Parametry:

• Typ przetwarzania → wg słownika ATR_CONFIG.T_EXECUTION (wymagany - a nie jak na zrzucie)
• Data danych [YYYYMMDD] → data przetwarzania (również wymagana)

Serwis uruchamia ATRE dla powyższych parametrów. Wcześniej musi wygenerować dane dla tych ekstraktów. Różnica pomiędzy zwykłym a tym generowaniem ekstraktów jest tylko taka, że wynikiem tego procesu nie będą pliki ekstraktów, które niepotrzebnie zaśmiecają system plików serwera aplikacyjnego po uprzednim przeniesieniu wewnętrznym transferem bankowym, a uruchomieniem samych testów.

WAZIS_LIREP_ATRE_REF_UAT

Serwis ustawia nową referencję konkretnego typu ekstraktów dla ATRE.

Jedynym parametrem tego serwisu jest identyfikator techniczny przetwarzania ekstraktów, które chcemy, żeby stały się referencją dla danego typu przetwarzań. Jeżeli znamy identyfikator techniczny, który pewnie weźmiemy z raportu HTML konkretnego przetwarzania, to znamy też typ przetwarzania tego identyfikatora. A jeśli my to wiemy, to „wiedzą to” też testy, które: 

• czyszczą wartość w polu R_SEQ_ID wybranego przetwarzania 
• usuwają pozostałe przetwarzania danego typu (wyszukanego po podanym identyfikatorze). 

Warto się też zastanowić, czy chcemy wyczyścić testy danego typu – np. poprzez pozostawienie tego pola pustego (oczywiście odblokowując taką możliwość).

Konfiguracja powiadomień mailowych

Na koniec pozostaje nam opisać grupy adresatów powiadomień mailowych, którymi zarządza opiekun aplikacji bezpośrednio na bazie danych.

Podsumowanie

Zdefiniowane w taki sposób testy dostarczały biznesowi potrzebnych dowodów na brak zmian w produkcyjnych ekstraktach podczas pracy nad projektem Bazylea IV.

Testy mogły spokojnie być uruchamiane zarówno w fazie wytwórczej oprogramowania na środowisku testowym, jak również po wdrożeniu produkcyjnym na danych produkcyjnych.

Podczas pracy nad projektem testy uruchamiane wieczorem każdego dnia roboczego po zakończeniu pewnego etapu prac weryfikowały, czy w produkcyjnych ekstraktach LCR/NSFR nie pojawiały się niespodziewane zmiany.

Dzięki prostemu narzędziu udało się:

• zmniejszyć koszty związane z dostosowaniem aplikacji po stronie dostawcy do niestandardowych rozwiązań
• uniknąć powołania i utrzymywania w czasie prac projektowych dodatkowej infrastruktury testowej po stronie banku dla samej tylko aplikacji (minimum 6 serwerów: 3 serwery aplikacyjne oraz 3 serwery bazy danych – po parze na każde środowisko DEV, UAT i PRD –zgodnie z wymaganiami biznesu)
• zaoszczędzić czas programistów, analityków i pracowników biznesu
• uniknąć problemów, które mogły się pojawić podczas procesu scalania zmian po zakończeniu prac projektowych ze środowiskiem produkcyjnym.