Skip to main content

Architektura

Maxime avatar
Written by Maxime
Updated over 4 months ago

Poniżej opisana została architektura rozwiązania oraz poszczególne jej komponenty. Architektura logiczna rozwiązania APIHub została przedstawiona na diagramie poniżej. Oparta została ona o zestaw współpracujących ze sobą microservice'ów. Poszczególne microservice'y realizują odrębne funkcje biznesowe i mogą być rozwijane niezależnie (pod kątem technologii i dostawców). Zapewnia to między innymi możliwość rozwijania kolejnych konektorów API przez niezależne zespoły developerskie (zarówno po stronie banqware jak i Partnerów).
Architektura składa się z następujących elementów:

  • API Gateway- warstwa odpowiedzialna za kierowanie wywołań API do poszczególnych usług oraz orkiestrację.

  • Zestaw usług Core- dedykowane serwisy są odpowiedzialne za poszczególne domeny biznesowe, w tym:

    • Transactional Data- dostęp do danych o rachunkach i transakcjach w LDS,

    • User Management- zarządzanie cyklem życia externalUser,

    • Session Provider- zarządzanie cyklem życia sesji AIS,

    • Consent Management- zarządzanie zgodami oraz cyklem życia tokenów oAuth,

    • Enriched data provider- dostarcza metryki wyliczane na danych transakcyjnych, przyjmuje zlecenia wyliczenia metryk,

    • APSPS management- zarządzanie listą i parametryzacją ASPSP.

  • Zestaw usług Connector- dedykowane pod konkretny standard lub typ API ASPSP, wysoce parametryzowalne instancje logiczne pozwalające na podłączanie kolejnych banków. Każdy podłączony ASPSP korzysta z jednej lub więcej (skalowanie) instancji danego konektora.

  • Usługi Reporting- odpowiedzialne za dostarczanie danych do raportowania wykorzystania i zachowania API APIHub, API ASPSP oraz raportowania analitycznego w kontekście użytkowników (externalUser). Obszar raportowy jest rozwijany na bieżąco, powstają nowe domeny usług w tym obszarze.

  • Batch jobs- procesy wsadowe. Na obecnym etapie są to:

    • Proces cyklicznej aktualizacji danych w LDS (4 sesje AIS dziennie)

    • Proces zarządzania retencją danych w LDS

Całość komunikacji pomiędzy usługami realizowana jest przez komunikaty wysyłane na szynę integracyjną.

99cd3671-3480-4057-aeef-b12ea83b742e.png


Baza danych- LDS
Kluczowym elementem APIHub jest baza danych nazwana LDS (Local Data Store)

  • Dane agregowane z ASPSP (poprzez różne API, w różnym formacie) są tłumaczone na jeden zunifikowany model danych (source agnostic). Informacje o rachunkach, transakcjach dostępne przez nasze API są zawsze w takim samy formacie (uwzględniając unifikację słowników) bez względu na sposób ich agregacji oraz stosowany przez ASPSP standard API.

  • Zapis danych w LDS powoduje również, iż dane są dostępne zawsze (ostatni znany stan danych) niezależnie od dostępności i czasu dostępu do źródła danych (API ASPSP). Aktualizacja danych wykonywana jest asynchronicznie (w tle). Dzięki temu:

    • usługa zapewnia PSU odpowiedni user-experience- niedostępność lub problemy wydajnościowe APSPS nie wpływają negatywnie na działania aplikacji użytkownika końcowego,

    • Pozwala to minimalizować liczbę zapytać do API ASPSP, pytamy tylko aby odświeżyć

    • Pozwala (dodatkowe funkcje APIHub) na analizę i wzbogacanie danych unifikowanych i przechowywanych w LDS

  • Dane pobrane z ASPSP są usuwane po zakończeniu sesji agregacyjnej, o ile PSU explicite nie zażąda przechowania danych w LDS na potrzeby kolejnych raportów i/lub cyklicznego odświeżania danych.

  • Jednocześnie w LDS zapisywane i dostępne są informacja źródłowe (zgodnie ze strukturą i zawartością otrzymaną od ASPSP) na potrzeby procesu rozpatrywania reklamacji Klientów.

Model danych dla kluczowych elementów, takich jak rachunek i transakcja, obsługiwany w LDS (format zunifikowany) został zbudowany w oparciu o specyfikę systemów core w bankach (liczba atrybutów rachunku i transakcji jest bardzo szeroka). Pozwala on tym samym na pełne zmapowanie atrybutów tych encji jakie są przekazywane w ramach różnych API i standardów API PSD2.

Baza diagnostyczna
W ramach APIHub funkcjonuje mechanizm logowania zdarzeń, wyjątków i danych diagnostycznych w dedykowanej bazie noSQL (MongoDB). Dostęp do logów realizowany jest poprzez:

  • aplikacji Robo3t (lub dowolnego Klienta MongoDB) instalowanej po stronie Klienta

  • eksport logów (format JSON) w ramach uzgodnionego harmonogramu

Did this answer your question?