Integracja danych w praktyce. Jak działa IPaaS

Ostatnie lata to prawdziwy boom na technologie big data związane z przetwarzaniem i analizą rosnących zbiorów danych. Większość aktualnych aplikacji na telefon zbiera gigantyczne wręcz pokłady informacji na temat swoich użytkowników. Dane te są gromadzone w systemach IT, a brak zautomatyzowanego procesu ich przetwarzania utrudnia, a nawet uniemożliwia efektywne zarządzanie ich zbiorami. Wraz ze wzrostem znaczenia danych rośnie więc zapotrzebowanie na ich automatyczne przetwarzanie, w tym integrację. O tym dzisiaj.

Mateusz Skawiński. Lead System Engineer w SoftServe. Od kilku lat na co dzień zajmuje się integracją systemów HCM z wykorzystaniem platform IPaaS, wcześniej także wytwarzaniem systemów informatycznych. Z tematyką IT związany od ponad 10 lat.

Potrzeba integracji danych

We współczesnych firmach coraz częściej pojawia się potrzeba integracji danych pomiędzy różnymi systemami HCM (Human Capital Management). Rosnąca oferta tych systemów sprawia, że jedna organizacja może wykorzystywać cały wachlarz różnych narzędzi HCM służących do zarządzania innymi rodzajami danych pracowników (dane płacowe, osobowe, informacje o historii zatrudnienia, dni wolne, szkolenia, ścieżki kariery itp.). Często zdarza się również, że przy przejęciu firmy lub jej części, nowo pozyskany dział będzie używał innych systemów niż organiczna część firmy. Zarówno przeniesienie obsługi całej organizacji do jednego systemu, jak i współdziałanie dotychczasowych narzędzi będzie wymagało integracji danych.

Wszystko to sprawia, że zapotrzebowanie na rozwiązania służące integracji danych szybko rośnie. Narzędzia te powinny być łatwo konfigurowalne do potrzeb konkretnego użytkownika, co w praktyce oznacza niski próg wejścia czy wiedzy eksperckiej przy jednoczesnej wysokiej efektywności i niezawodności systemu.

Jeszcze kilkanaście lat temu nie był to tak popularny kierunek, a liczba specjalistów w branży integracji nie była i wciąż nie jest na tyle duża, by pokryć szybko rosnące zapotrzebowanie na rynku pracy. Jak zapełnić tę lukę? Na szczęście systemy integracyjne są tworzone tak, by mogły na nich (przynajmniej w pewnym ograniczonym stopniu) pracować osoby, które dopiero rozwijają swoją wiedzę w tym zakresie.

Co daje IPaaS?

Odpowiedzią na rosnące zapotrzebowanie w obszarze integracji danych są platformy integracyjne IPaaS (Integration Platform as a Service). Klient operuje na nich według i w zakresie własnych potrzeb. Jest to szczególnie ważne dla mniejszych organizacji, dla których koszt wcześniejszych rozwiązań typu enterprise w pełnym wymiarze (zakup licencji, konieczność instalacji we własnym środowisku, przygotowanie infrastruktury) byłby nieakceptowalny. IPaaS pozwala wiązać koszty z faktycznym zużyciem.

To jednak nie jedyna zaleta tych platform. IPaaS dostarczają gotowe, łatwo konfigurowalne elementy będące implementacją popularnych i sprawdzonych wzorców integracyjnych. W ten sposób pomagają oszczędzać czas, a w konsekwencji ograniczyć budżet projektu. Użycie platform integracyjnych ułatwia też współdziałanie z systemami w chmurze, zdejmuje z użytkownika konieczność rozbudowy własnej infrastruktury (może być ona umieszczona na platformie IPaaS i zarządzana za jej pomocą) oraz wnosi łatwą skalowalność rozwiązania w razie potrzeby. Owa łatwa skalowalność staje się kluczowa przy obecnym wzroście ilości danych, gdy konieczne jest zachowanie dobrej wydajności procesu integracji.

Platformy integracyjne umożliwiają łatwą konfigurację połączenia i komunikacji z integrowanymi systemami za pomocą użycia Web API. Rozbudowany system wsparcia dla tworzenia rozwiązań opartych na REST czy SOAP wpisuje się w obecne trendy tworzenia aplikacji, które umożliwiają wymianę poleceń poprzez serwisy webowe oparte na HTTP. Pomaga to w budowaniu integracji nie tylko synchronizujących dane na żądanie (on demand) czy w jakimś określonym przedziale czasowym, ale także integracji działających w czasie rzeczywistym, kiedy to zaistnienie zmiany w jednym systemie jest propagowane do innego systemu.

Co może pójść nie tak?

W ogólnym zarysie koncept integracji danych można opisać prosto. Należy pobrać dane z systemu źródłowego, dokonać transformacji danych do postaci obowiązującej w systemie docelowym i tak zmodyfikowane dane w tym systemie zapisać.

Choć przedstawia się to nieskomplikowanie, podczas integracji danych napotykamy wiele trudności. Są to między innymi:

Bezpieczeństwo danych

Świadomość znaczenia bezpieczeństwa danych staje się coraz większa. Nikomu chyba nie trzeba już tłumaczyć, jak ważne jest pilnowanie przed nieuprawnionym rozpowszechnieniem danych wrażliwych, takich jak numer karty kredytowej, numer PESEL w Polsce czy SSID w Stanach Zjednoczonych. Przy budowaniu integracji należy wziąć pod uwagę, czy wrażliwe dane nie zostaną umieszczone w miejscu, do którego dostęp mogłaby mieć osoba nieupoważniona. Może to mieć miejsce zarówno bezpośrednio, tj. w systemie, do którego dane zostały wyeksportowane, lub pośrednio, np. w postaci zapisania do logów procesu integracyjnego, raportu czy powiadomienia w przypadku wystąpienia błędu.

Wydajność

Pełne wyeksportowanie danych z systemu (np. w przypadku tworzenia kopii zapasowej), zwłaszcza w przypadku systemów używanych przez duże przedsiębiorstwa, będzie operować na dużej ilości danych. Przetworzenie tych danych z pewnością będzie wymagać czasu. Ważna jest efektywna implementacja procesu, żeby ten czas mieścił się w akceptowalnych granicach. Podobnie może być w sytuacji z drugiego bieguna, gdy dokonujemy integracji małych pojedynczych zmian danych. Tutaj mogą istnieć wymogi biznesowe, by synchronizacja ta odbywała się bez opóźnień dłuższych niż kilkanaście czy kilkadziesiąt sekund (Near-Real Time Integration). W tym wypadku również konieczne jest odpowiednie dostosowanie projektu integracji do maksymalnego skrócenia czasu wykonania (np. poprzez ograniczenie logowania i audytowania tego typu integracji do minimum).

Obsługa i śledzenie błędów

Odnalezienie przyczyny błędu w przypadku nieudanej integracji może być trudne, zwłaszcza gdy przetwarzamy dużą ilość danych. Przeglądanie wygenerowanych logów może być ciągnącym się, żmudnym zajęciem. Na szczęście duże wsparcie oferują tutaj platformy integracyjne w postaci gotowych elementów wspierających obsługę i raportowanie błędów, a także łatwy dostęp i filtrowanie wyników na pośrednich etapach działania integracji, które są również automatycznie zachowywane przez platformę.

Złożone wymagania biznesowe

Określenie, które elementy danych powinny zostać wyeksportowane ze źródłowego systemu oraz w jaki sposób mają być zmapowane do systemu docelowego bywa trudne. Wiele transformacji danych nie polega na bezpośrednim mapowaniu wartości 1:1, a często wymaga pobierania i łączenia wielu rekordów z obu systemów oraz wykonywania na nich dodatkowych operacji. Opracowanie mapowania wymaga również głębokiego zrozumienia zarówno treści tych danych, jak i obu systemów.

Podstawowe założenia kluczem do sukcesu

Jak nie utonąć w powyższych problemach? Ważne jest odpowiednie zaprojektowanie integracji. W tym celu powinniśmy zacząć od zebrania podstawowych informacji dotyczących wymagań tego procesu. Dopiero na ich bazie jesteśmy w stanie określić podstawowe założenia techniczne.

Możemy wyróżnić różne rodzaje integracji i sposoby ich modelowania, ze względu na ich:

• Punkty końcowe – może być to bowiem integracja między dwoma aplikacjami lub eksport/import danych dla pojedynczej aplikacji (np. eksportowanie danych do pliku celem raportowania lub stworzenia kopii zapasowej).
• Kierunek integracji – integracja może odbywać się tylko w jednym kierunku – z systemu A do B lub w obu kierunkach (czyli dodatkowo również z B do A). Drugi przypadek jest znacznie bardziej skomplikowany (jeśli operuje na tych samych danych). Musimy nie tylko odpowiednio wersjonować zmiany, by wiedzieć, który system jest w danej chwili aktualny i powinien być źródłem w procesie integracji, ale także potrafić rozwiązać problem, gdy zmiany zostaną dokonane na obu systemach w tym samym czasie. Trzeba wówczas albo określić jeden z systemów jako główny (master), który nadpisze zmiany w systemie podrzędnym, albo zdecydować się na ręczne rozwiązywanie tego typu konfliktów.
• Sposób synchronizacji – może to być okresowe uruchamianie integracji i przetwarzanie pewnego zbioru danych (batch) lub synchronizacja na bieżąco, przetwarzająca pojedyncze dane, które właśnie zostały zmodyfikowane (near real time – nrt). Te pierwsze będą zazwyczaj uruchamiane ręcznie (on demand) lub według zaplanowanego rozkładu (scheduled). Wiedząc, że na systemie źródłowym są dane, które powinny zaktualizować system docelowy, można zdecydować o uruchomieniu takiej integracji ręcznie. Automatyczne uruchamianie integracji może być zaplanowane np. raz w tygodniu, raz na dzień, w odstępie godzinowym itp. Integracja typu NRT, będzie uruchamiana bezzwłocznie, w momencie zaistnienia zmiany. Najczęściej będzie się to opierać na zdarzeniach (events) przypisanych do określonych operacji w systemie źródłowym, które będą wysyłać powiadomienia do usługi odpowiedzialnej za rozpoczęcie integracji (będzie ona zarejestrowana jako subskrybent, zgodnie z wzorcem publisher/subscriber).
• Zakres przetwarzanych danych – poza wyróżnionym wcześniej NRT operującym na pojedynczych danych, synchronizacje zbioru danych (batch) można podzielić na pełną (full) i ograniczoną do ostatnich zmian (delta). Ta druga nie będzie pobierać pełnego zakresu danych, lecz tylko te rekordy, które uległy modyfikacji od czasu poprzedniej synchronizacji. Można tego dokonać w oparciu o datę ostatniej modyfikacji rekordu zawartej w systemie źródłowym – tylko jeśli rekordy przechowują taką wartość (obecnie większość systemów HCM posiada tę funkcjonalność). W przeciwnym wypadku może być konieczne przechowywanie dodatkowych informacji na temat zsynchronizowanych rekordów w miejscu pośrednim (np. bazie danych – staging tables) oraz dodatkowa logika porównująca i filtrująca zmiany.

Implementacja procesu

Wiemy już, że platformy IPaaS umożliwiają szybkie rozpoczęcie pracy w prosty sposób. Przejdźmy więc do praktyki. W jaki sposób możemy rozpocząć pracę nad integracją w Dell Boomi, będącym jednym z wiodących rozwiązań IPaaS?
Jest to jedynie ogólne przedstawienie sposobu tworzenia integracji. Bardziej szczegółowe przykłady z dokładnym omówieniem można znaleźć na oficjalnej stronie Boomi (podobny scenariusz do przedstawionego poniżej przedstawia wideo).

Przykład obejmuje stworzenie prostej integracji pobierającej dane z Salesforce i zapisujące je w bazie danych. Kolejne kroki polegają na wykonaniu etapów prostego procesu ETL (Extract, Transform, Load).

1. Ekstrakcja danych (Extract)

Pobranie danych wymaga skomunikowania się z systemem źródłowym. Do tego celu Boomi udostępnia komponenty typu Connector. Jego użycie polega na skonfigurowaniu danych połączenia (url, login, hasło, itp.) oraz typu operacji, jaką chcemy wykonać. Definiując operację, określamy również format danych, który zostanie zwrócony przez system. Możemy tutaj skorzystać z funkcjonalności connectora polegającej na automatycznym zaimportowaniu tego formatu z systemu (poprzez użycie metadata API – logika ta zaszyta jest w connectorze). Wykonanie tych czynności umożliwia już pobranie danych z systemu.

Obraz 1. Utworzenie komponentu typu connector

Obraz 2. Konfiguracja połączenia

Obraz 3. Konfiguracja operacji – pobrania danych (dla Accounts)

2. Ładowanie danych (Load)

Zanim dokonamy mapowania (transformacji danych), skonfigurujemy etap ładowania danych do systemu docelowego poprzez stworzenie connectora do bazy danych. W ten sposób możemy automatycznie zaimportować format danych systemu docelowego (na podstawie schematu tabeli bazodanowej), by następnie użyć go przy mapowaniu (bez konieczności robienia tego ręcznie). Wybierając connector typu Database, definiujemy również połączenie i operację na nim wykonywaną.

Tworzenie połączenia jest tak samo proste jak w przypadku innych typów connectora (w tym wspomnianym Salesforce). Konfigurując operację i importując format, możemy określić typ jako Dynamic Insert. Dzięki temu odpowiednia komenda SQL, która umieści dane w bazie danych, zostanie wygenerowana na podstawie zdefiniowanego formatu danych. Oczywiście jesteśmy w stanie zdefiniować komendę (również procedurę) SQL samodzielnie, jednak w wielu przypadkach automatyczne generowanie wystarczy.

Obraz 4. Zaimportowana definicja formatu danych postaci Insert Statement służąca do wprowadzania danych

3. Transformacja danych (Transform)

Do mapowania danych z formatu Salesforce (XML) do formatu zapytania do bazy danych (insert statement) – wygenerowaliśmy je w poprzednich krokach – użyjemy komponentu typu Map. Mapowanie poszczególnych elementów między wybranymi formatami możliwe jest za pomocą drag & drop. Funkcjonalność ta umożliwia zdefiniowanie mapowania w sposób prosty i przejrzysty. Oczywiście mapowanie nie zawsze będzie prostym 1:1. Na trudniejsze przypadki komponent Map dostarcza dodatkowych funkcjonalności, takich jak tabele referencyjne, podstawowe operacje na wartościach, tworzenie własnych skryptów i wiele innych.

Obraz 5. Mapowanie danych

4. Zdefiniowanie przepływu danych

Wszystkie operacje są gotowe. Zdefiniowane komponenty muszą zostać połączone definiując przepływ danych. Tego dokonujemy w głównym procesie integracji. Jeśli zadanie zostało ukończone i konfiguracja komponentów jest poprawna, możliwe będzie uruchomienie i przeprowadzenie integracji.

Obraz 6. Główny proces integracji, w którym umieszczone są komponenty

W rzeczywistości proces integracyjny będzie bardziej skomplikowany od zaprezentowanego powyżej. Należy się spodziewać konieczności zdefiniowania bardziej złożonego mapowania danych, obsługi błędów i przypadków brzegowych, łączenia danych pochodzących z różnych źródeł (np. z różnych usług API) itp. Przykład pokazuje jednak, jak łatwo bez szczegółowej wiedzy można zbudować coś działającego, co może być dalej rozbudowywane. Dostarczone komponenty platformy pozwoliły nam budować integrację wysokopoziomowo, bez konieczności zagłębiania się w techniczne szczegóły, oszczędzając tym samym mnóstwo czasu.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z