Integracje systemów i API

Objawy, po których poznasz, że potrzebujesz integracji

Pierwszy i najczęstszy: ktoś w firmie przepisuje dane z jednego ekranu na drugi. Zamówienia ze sklepu do systemu magazynowego, dane kontrahenta z formularza do CRM, pozycje z faktury do arkusza. To praca, która nie wnosi nic poza ryzykiem literówki, a zajmuje realny etat.

Drugi: te same dane w dwóch miejscach różnią się od siebie i nikt nie potrafi rozstrzygnąć, które są prawdziwe. Zwykle znaczy to, że oba systemy pozwalają edytować ten sam rekord i nie ustalono, który z nich jest źródłem prawdy. To problem projektowy, nie techniczny, i rozwiązujemy go przed napisaniem pierwszej linii kodu.

Trzeci: raport, na który trzeba czekać. Jeśli odpowiedź na pytanie o marżę albo stan zapasów wymaga eksportu z trzech systemów i wieczoru w arkuszu, to decyzje w firmie zapadają na podstawie danych sprzed tygodnia. Integracja zamienia to w widok, który jest aktualny w momencie otwarcia.

Jak podchodzimy do integracji

Zaczynamy od mapy: jakie systemy uczestniczą w procesie, które dane są w każdym z nich tworzone, a które tylko czytane, i w którą stronę mają płynąć. Ta mapa najczęściej ujawnia, że część planowanych połączeń jest niepotrzebna, a jedno brakujące jest ważniejsze niż wszystkie pozostałe razem.

Dla każdego przepływu ustalamy źródło prawdy - dokładnie jeden system, w którym dany rekord powstaje i może być zmieniany. Pozostałe otrzymują kopię i nie mogą jej edytować, albo mogą, ale wtedy z góry definiujemy zasadę rozstrzygania konfliktów. Pominięcie tego kroku jest najczęstszą przyczyną integracji, które po pół roku trzeba pisać od nowa.

Potem sprawdzamy, co druga strona faktycznie udostępnia. Dokumentacja API bywa nieaktualna, limity zapytań bywają niższe od deklarowanych, a niektóre systemy nie mają API w ogóle i pozostaje import plików lub dostęp do bazy. To rozstrzygamy testami, zanim złożymy jakąkolwiek obietnicę terminu.

• -Mapa systemów i kierunków przepływu danych
• -Wyznaczenie źródła prawdy dla każdego rekordu
• -Test realnych możliwości i limitów każdego API
• -Implementacja z monitoringiem i ponawianiem
• -Uruchomienie równoległe przed przełączeniem procesu

Z czym najczęściej się łączymy

Systemy sprzedażowe i magazynowe, platformy e-commerce, systemy CRM, programy księgowe i fakturujące, bramki płatnicze, operatorów wysyłki, systemy kadrowe oraz narzędzia komunikacji wewnętrznej. Do tego usługi chmurowe i cała warstwa raportowa, która z tych danych korzysta.

Nie ograniczamy się do listy gotowych konektorów, bo najciekawsze przypadki dotyczą zwykle systemów, dla których nikt konektora nie napisał - starszego oprogramowania branżowego albo narzędzia stworzonego kiedyś na zamówienie. Jeśli system ma jakikolwiek sposób wymiany danych, da się to obsłużyć.

• -ERP i systemy magazynowe
• -CRM i systemy obsługi klienta
• -Platformy e-commerce i marketplace
• -Programy księgowe i fakturujące
• -Bramki płatnicze i operatorzy logistyczni

API, webhooki i kolejki - kiedy co stosować

Zapytanie do API stosujemy tam, gdzie potrzebujemy danych na żądanie i możemy poczekać na odpowiedź. To najprostszy wariant, ale przy dużej liczbie zapytań szybko trafia w limity dostawcy, więc dokładamy warstwę pamięci podręcznej.

Webhook odwraca kierunek: to druga strona informuje nas, że coś się wydarzyło. Jest dużo wydajniejszy niż odpytywanie co minutę o zmiany, ale wymaga poprawnej obsługi powtórzeń - dostawcy potrafią wysłać to samo zdarzenie kilka razy, więc każda operacja musi być idempotentna, czyli bezpieczna przy ponownym wykonaniu.

Kolejka komunikatów wchodzi tam, gdzie zdarzeń jest dużo albo przetwarzanie trwa długo. Zdarzenie ląduje w kolejce, a system przetwarza je we własnym tempie. Gdy docelowa usługa jest chwilowo niedostępna, nic nie ginie - zadania czekają i wykonują się po jej powrocie.

Co się dzieje, gdy integracja przestaje działać

Przestanie. Dostawca zmieni wersję API, wygaśnie token, druga strona będzie mieć awarię albo ktoś wprowadzi rekord w formacie, którego nikt nie przewidział. Różnica między integracją dobrą a złą polega nie na tym, czy się zepsuje, tylko na tym, czy się o tym dowiesz.

Dlatego każdą integrację wyposażamy w monitoring, ponawianie z rosnącym odstępem i tak zwaną kolejkę zdarzeń nieudanych. Nieprzetworzone zdarzenia nie znikają - trafiają w jedno miejsce, z którego można je obejrzeć i uruchomić ponownie po usunięciu przyczyny. Powiadomienie o awarii przychodzi na wskazany kanał od razu, a nie wtedy, gdy zadzwoni klient.

Prowadzimy też pełny dziennik zdarzeń: co, kiedy i z jakim skutkiem zostało wysłane. Przy sporze o to, czy zamówienie na pewno trafiło do magazynu, jest to jedyny argument, który kończy dyskusję.

Migracje i wymiana systemu

Osobną częścią naszej pracy są migracje - przeniesienie danych ze starego systemu do nowego. Zaczynamy od czyszczenia i mapowania pól, potem robimy próbne przejście na kopii i porównujemy liczby: ile rekordów weszło, ile odpadło i dlaczego. Dopiero gdy różnice są wyjaśnione, planujemy przełączenie.

Prawie zawsze proponujemy okres pracy równoległej, w którym oba systemy działają jednocześnie, a dane są synchronizowane w jedną stronę. Kosztuje to trochę dodatkowej pracy i eliminuje najgorszy możliwy scenariusz - odkrycie po fakcie, że czegoś nie przeniesiono, gdy stary system jest już wyłączony.