Cel zmiany
Celem zmiany jest wdrożenie nowego mechanizmu propagacji danych z bazy LDS (baza danych APIHub) do systemów Santander. Mechanizm ma opierać się na komunikatach wstawianych przez APIHub na dedykowane kolejki RabbitMQ (instancja obecnie wykorzystywana przez APIHub na potrzeby wewnętrznej komunikacji jego komponentów).
Nowy mechanizm ma na celu:
Zastąpienie obecnych widoków ETL
Zastąpienie obecnego mechanizmu wysyłki danych do CBT
Rozszerzenie obecnego mechanizmu wysyłki danych o zgodach do CIS
Opis zmiany
Zasada działania nowego mechanizmu:
Na szynie RabbitMQ zostaną zdefiniowane dedykowane kolejki:
Accounts
Transactions
Consents
Payments
Na poszczególne kolejki APIHub będzie wstawiał komunikaty związane z przekazaniem danych o poszczególnych domenach:
Accounts - aktualizacja listy rachunków dla użytkownika (w tym salda), każdorazowo będzie przesyłana pełna lista. Triggerem do przekazania danych (wstawienie komunikatu do kolejki) jest odświeżenie rachunku.
Zdarzenie usunięcia rachunku: każdorazowo jest wysyłana pełna lista rachunków (aktualna zwrócona przez ASPSP). Jeżeli rachunek nie zostaje zwrócony przez ASPSP (zamknięcie rachunku, usunięcie z zakresu zgody) to nowy komunikat nie będzie zawierał rachunku przekazanego wcześniej (deduplikacja po unikalnym id rachunku nadawanym przez APIHub po stronie odbiorcy)
Transactions - aktualizacja listy transakcji per rachunek. Lista będzie aktualizowana inkrementalnie (dla transakcji typu Done, Cancelled, Rejected). Deduplikacja po unikalnym ID nadawanym przez APIHub jest po stronie systemów odbierających. Triggerem jest odświeżenie rachunku (wykonanie zapytania przyrostowego o historię rachunku). Kolejki nie będą uwzględniały usuwania transakcji zablokowanych (Hold, Scheduled, Pending). Usunięcie ich, jeśli nie zostały dodane na kolejkę, leży po stronie Banku.
Consents - aktualizacja zgody. Triggerem jest zmiana statusu zgody zgodnie z cyklem życia zgody zarządzanym przez APIHub. Pojedyncza zgoda jest identyfikowane przez unikalne id nadawane przez APIHub, a komunikat zostaje wstawiony każdorazowo, kiedy zmienia się jej status zgodnie z cyklem życia zgody:
Payments - aktualizacja listy zainicjowanych płatności per user. Lista będzie aktualizowana inkrementalnie. Deduplikacja po unikalnym ID nadawanym przez APIHub jest po stronie systemów odbierających. Triggerem jest wykonanie nowej płatności lub zmiana statusu zainicjowanej płatności.
Zarządzanie komunikatami w ramach kolejek.
Usunięcie komunikatu przez stronę odbierającą
Komunikat odebrany jest usuwany
Brak ponawiania
Przygotowanie consumer'ów leży po stronie Banku.
Zakres danych
Accounts - zakres danych wystawianych w komunikacie zgodny 1-1 z zakresem danych zwracanych w metodzie APIHub: /api/v2/bankaccount
Transactions- zakres danych wystawianych w komunikacie zgodny 1-1 z zakresem danych zwracanych w metodzie APIHub:
/api/v2/bankaccount/accountId/transaction?PageNumber=1&PageSize=100
Consents - zakres danych wystawianych w komunikacie zgodny 1-1 z zakresem danych zwracanych w metodzie APIHub: /api/v2/consent
Payments- zakres danych wystawianych w komunikacie zgodny 1-1 z zakresem danych zwracanych w metodzie APIHub: /api/v2/payment
Uwagi:
Obecnie dane wystawiane w widokach ETL są:
Filtrowane - nie są prezentowane wszystkie typy rachunków i transakcji
Agregowane - istnieją atrybuty oparte o logikę agregacji danych źródłowych
Dane przekazywane w komunikatach na kolejkach RabbitMQ nie będą filtrowane i nie będą zawierały informacji zagregowanych tak jak w obecnych widokach.
Obecne interfejsy do CBT (polegające na wywołaniu API wystawianym przez CBT) nie zawierają wszystkich parametrów rachunku i transakcji. Struktura komunikatów jakie wysyłane są obecnie do CBT (na bazie definicji usług API CBT) nie zostanie zreplikowana do nowego mechanizmu.
Obecnie funkcjonuje mechanizm ponawiania wysyłki komunikatów do CBT (w przypadku, kiedy API CBR nie odpowiada lub odpowiada błędem). W nowym mechanizmie nie będzie ponawiania.
Dane będą wysyłane w formacie odpowiednim dla framework'u MassTransit, tak więc będą zawierały wszystkie headery i metadane, które ten framework dodaje do wiadomości (tak jak to się dzieje obecnie w usłudze wysyłające informacje o zgodzie do systemu CIS)
Logowanie i diagnostyka
Podstawowe logi informujące o wstawieniu komunikatu - dostępne będą z naszej bazy logów MongoDB.
Logi odnośnie całej aktywności na kolejce - będą dostępne z logów RabbitMQ przy konfiguracji odpowiadającej verbosity i output'om wspólnie ustalonym