Metody integracji z General Ledger

Budowane współcześnie rozwiązania i systemy IT w znakomitej większości implementują architekturę opartą o mikroserwisy. Szeroko stosowane są także rozwiązania bazujące na chmurze publicznej lub usługach w modelu SAS, będące dosyć wygodnym wyborem przy tworzeniu złożonych systemów informatycznych. Doświadczenia z projektów polegających na zintegrowaniu nowego systemu z kategorii „core banking system" dla klientów z branży finansowej pozwalają na zmapowanie zestawu dobrych praktyk, które należy uwzględnić przy realizacji podobnych projektów informatycznych. Analizuje je Adam Papros, Senior AWS Solution Architect, GFT.

Systemy bankowe są nieustannie modernizowane lub budowane od podstaw. Gama gotowych produktów z kategorii  „core banking system” jest coraz szersza i obejmuje systemy nowsze, jak i starsze. W każdym funkcjonującym systemie bankowym istnieje komponent tworzący tzw. Księgę Główną (General Ledger, GL). Jest on elementem obligatoryjnym (niezbędnym z perspektywy regulacji i raportowania) i przyjmuje różne formy, ale w dużym uproszczeniu można stwierdzić, że agreguje on informacje z wszelkich podsystemów banku, które przechowują informacje finansowe. Zapewnienie spójności stanu kont GL, obejmujących wiele podsystemów bankowych, jest zagadnieniem, które występuje zawsze w projektach informatycznych, mających na celu budowę lub rozbudowę systemu informatycznego banku.

Integracja z GL jest zatem nieodłącznym elementem wielu projektów informatycznych, które mają na celu zbudowanie systemu bankowego, rozbudowanie istniejącego, migrację do chmury lub na inny system core bankingowy. Warto także wspomnieć, że nowoczesne systemy core bankingowe mogą po prostu nie posiadać wbudowanych funkcjonalności GL – podkreśla to zatem istotę rozważanej tematyki.

Integracja z GL musi także być wykonana w odpowiedniej jakości, co wynika z charakteru przetwarzania danych. Dane dotyczące stanu finansowego aktualizuje się każdego dnia, a obecnie wszelkie problemy wynikające z braku automatyzacji w tym zakresie rozwiązywać muszą pracownicy banku. Z tego powodu warto rozważyć kilka kwestii, które mogą znacznie wpłynąć na jakość samej integracji oraz zmniejszyć ilość ręcznie wykonywanych poprawek – a w idealnym przypadku – zmniejszyć je do minimum, osiągając wysoce zautomatyzowany proces, który „po prostu działa”. Poniżej znajdują się zagadnienia, które należy wziąć pod uwagę, gdy budowana jest integracja z GL, w kontekście systemu bankowego, który istnieje  w środowisku mikroserwisów.

Integracja z GL poprzez pliki

Typowym sposobem integracji z GL jest integracja poprzez pliki. System bankowy codziennie przygotowuje transakcje, dokonując niezbędnych agregacji, mapowań, filtrowania, transformacji oraz uzupełnienia danych. Przygotowane informacje mogą być reprezentowane w formie pliku płaskiego i przesyłane do systemu GL, który w następnym kroku przetwarza cały plik.

Przygotowanie takiego pliku może być oparte o rozwiązania z kategorii Data Warehouse (hurtowni danych) lub Data Lake (miejsca do przechowywania ustrukturyzowanych i nieustrukturyzowanych danych). W obu przypadkach należy zasilić ten zasób danymi, które mogą pochodzić  z wielu systemów. Nakładając na to zasady architektury mikroserwisowej, oczywistym rozwiązaniem będzie integracja poprzez serwery kolejek np. Apache Kafka. Dane zatem spływać mogą do serwerów kolejek poprzez rozwiązania typu Change Data Capture (automatycznego śledzenia zmian w bazach danych i rozpowszechniania ich np. w innych systemach) lub inne, następnie mogą być przekierowywane do zasadniczych systemów przetwarzania wsadowego. Takie rozwiązanie oczywiście jest bardziej złożone, ma więcej komponentów i integracji, ale unika integracji bezpośrednio poprzez bazy danych, które mogą być uciążliwe ze względu na zmiany i migracje w bazach danych, towarzyszące wdrażaniu kolejnych wersji mikroserwisów. Unikanie „integracji poprzez bazy danych” wpisuje się także w dobre zasady architektury mikroserwisowej.

Pojawiające się problemy ze spójnością danych lub okoliczności wymuszające wykonanie operacji, które mają na celu poprawić stan kont GL, na pewno wydarzą się w momencie gdy system bankowy działa. Wychwycenie takich niespójności może nastąpić na drodze rekoncyliacji systemów, ale naprawa istniejącego stanu to kolejny krok, który należy wykonać, by przywrócić spójność kont GL. Integracja z GL powinna zatem umożliwić naprawę stanu kont poprzez ponowne przesłanie brakujących transakcji lub innego zestawu danych korygujących.

Wymienione scenariusze powinny być podstawowym przypadkiem użycia tych systemów, aby w przyszłości minimalizować koszt operacyjny wynikający z manualnych czynności niezbędnych do naprawy jego stanu. Pomóc mogą elementy składające się na obserwowalność systemów (observability). W szczególności można sobie wyobrazić elementy konsoli, która wskazuje, że pewne kroki przetwarzania danych wydarzyły się lub nie albo trwają dłużej, niż wskazywałoby na to doświadczenie (poprzedniego wykonania). Uwzględnić na takiej konsoli można także informacje i zakresy dotyczące przepustowości systemów (liczba żądań HTTP na sekundę, liczba obsłużonych wiadomości na sekundę). Istotnymi danymi mogą być także informacje o liczbie wiadomości, które czekają na serwerze kolejek i nie zostały jeszcze obsłużone – co wprost świadczy o problemie funkcjonalnym, niefunkcjonalnym (słaba wydajność) lub złym skalowaniu.

Aby uzyskać pełniejszy obraz można także zaprojektować i zaimplementować niestandardowe metryki, które mierzą i opisują problematyczne lub istotne kroki w trakcie przetwarzania transakcji (mapowanie, filtrowanie, uzupełnianie danych). Następnie takie metryki mogą zostać użyte w opisywanej konsoli, tak aby sytuacje odbiegające od „normy” można było łatwo uchwycić.

Integracja z GL poprzez przetwarzanie zdarzeń

Alternatywą do integracji poprzez pliki jest integracja polegająca na przetwarzaniu pojedynczych zdarzeń – w tym przypadku transakcji z wykorzystaniem API systemu GL (przykładowo HTTP API lub kolejka). W tym modelu transakcja przetwarzana jest od razu po jej zaksięgowaniu. System czeka na takie zdarzenia (nowa transakcja), przetwarza je od razu, a na końcu przesyła do systemu GL. Koncepcja wydaje się być bardzo prosta, ale może być uciążliwa, ponieważ wiele komponentów musi być dostępnych w tym samym momencie. Problem ten można ograniczyć poprzez zbudowanie dedykowanych, zoptymalizowanych baz danych, które są kopiami tylko do odczytu. Aktualizacja takich baz może następować w tle, gdyż w większości przypadków jest to akceptowalne przy uwzględnieniu charakterystyki problemu.

Kolejną cechą charakterystyczną takiej integracji jest możliwość wystąpienia naturalnych spiętrzeń w formie bardzo dużej ilości generowanych transakcji. Dotyczy to momentu, kiedy uruchamiane są procesy wsadowe pod koniec dnia. Projektowana integracja powinna uwzględniać tę sytuację – wspomniane wcześniej lokalne bazy danych, z kopiami wolno zmieniających się danych, mogą pomóc w efektywnej obsłudze takiego zdarzenia. Należy wspomnieć także, że możliwe jest przetwarzanie transakcji w grupach lub pakietach (przetwarzanie wielu zdarzeń  „na raz”) jeżeli wszystkie niezbędne systemy mają takie możliwości.

Rozwiązania oparte na kolejkach z odpowiednio dopasowanym skalowaniem horyzontalnym mogą być naturalnym wyborem bez względu na to czy system GL udostępnia API czy przykładowo integrację przez kolejkę. Oba warianty, pomimo pewnych różnic, posiadać będą te same kroki w trakcie przetwarzania oraz podobne problemy – przykładowo z wielokrotnym przetwarzaniem tych samych danych. Ta typowa kwestia dotyczy jakiejkolwiek integracji systemów, więc należy wspomnieć, że i w tym przypadku trzeba odpowiednio zadbać o poprawne przetwarzanie tych samych danych.

Kolejną ważną kwestią jest sposób radzenia sobie z błędami na poziomie pojedynczych wiadomości lub transakcji. Tymczasowa niedostępność niektórych systemów co do zasady powinna spowodować, że przetwarzanie cierpliwie czeka na to, aby wadliwy system z powrotem stał się dostępny. Sytuacja ta oczywiście powinna być odpowiednio odwzorowana w systemach monitoringu i obserwowalności. Innym przypadkiem jest błąd, który ze względu na swoją naturę powinien być zaraportowany, bo jego poprawa wymaga interwencji operatora banku. Na tę okoliczność warto zbudować dedykowany system, który potrafi zgromadzić i opisać jakiego rodzaju jest to usterka (brak wymaganego mapowania, nieobsługiwany/nieznany typ transakcji, problem z nieoczekiwaną zmianą schematu w HTTP API lub w schemacie kolejki). Ponadto taki system może oferować możliwość naprawy tego błędu oraz opcję ponownej wysyłki problematycznej transakcji.

Lepsze funkcjonowanie instytucji finansowych

Oba podejścia do integracji z GL są stosowane z powodzeniem i trudno wskazać, które jest lepsze bez kontekstu konkretnego systemu bankowego. Mają one swoje typowe cechy, nieróżniące się w istotnym stopniu od innych integracji tego typu. Należy jednak pamiętać, że integracje z GL są obligatoryjnym elementem systemów informatycznych banków i ich poprawna realizacja może korzystnie wpłynąć na funkcjonowanie i operacje instytucji finansowej. Na powyższe składa się odpowiednio skrojona architektura, jakościowa implementacja oraz uwzględnienie funkcji systemu, które pomogą rozwiązać potencjalne problemy. Te z pewnością wystąpią we współczesnych, złożonych systemach informatycznych.