Wprowadzenie

Swego czasu opisywałem wzorce projektowe i API (Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy). Kluczowym wzorcem jest wzorzec SAGA, czyli sterowanie sekwencją wymiany danych z jednego miejsca. Wzorzec ten to typowy system klient-serwer (usługobiorca-usługodawca) i sprawdza się doskonale, gdy sterowanie z jednego miejsca rozwiązuje wszystkie problemy integracji. Pewnym problem jest tu jednak to, że serwer musi zostać odpytany by klient poznał jego stan, a nie zawsze jest to wystarczające.

Opis problemu

Wyobraźmy sobie, że mamy system WMS (ang. Warehouse Managements System, zarządzanie magazynami) oraz zintegrowany system ERP, rozliczający operacje magazynowe. Jak to opisałem w tym artykule (Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy) integracja na zasadzie “każdy z każdym” szybko prowadzi do dramatu zwanego “gwiazda śmierci” (death star), dlatego zalecana architektura to:

Typowy scenariusz integracji wygląda tak:

Jak widać Koordynator musi sprawdzać czy w WMS są nowe dokumenty. Jeżeli operacje magazynowe są intensywne (np. wiele na godzinę) to np. sprawdzanie co godzinę, a nawet co kwadrans nie prowadzi do “pustego przebiegu” i nie jest to zbyt dużym wyzwaniem dla wydajności tych serwerów.

Jednak pamiętajmy, że nadal większość ERP i WMS to rozbudowane systemy zbudowane na skomplikowanym relacyjnym modelu danych, więc każde takie odpytanie to jednak wykonanie bardzo skomplikowanego zapytania SQL (setki linii) do bazy mającej setki tablic (duży ERP to nawet ponad 5 tys. powiązanych tabel).

Jeżeli dane o stanach magazynowych w ERP z dokładnością do doby są wystarczające, to praktycznie nie mamy problemu. Jednak w sytuacji gdy te dane powinny być “na bieżąco” pojawia się problem: im krótszy interwał odpytywania ustalimy, tym więcej będzie odpowiedzi: “brak nowych dokumentów”. Innymi słowy im bardziej “w czasie rzeczywistym” chcemy pracować tym bardziej system (procesor) będzie “przetwarzał powietrze”.

Z tego powodu wielu integratorów nadal stosuje architekturę:

Problem w tym, że przeciętna organizacja ma kilka aplikacji i ten styl integracji bardzo szybko prowadzi do opisanej już “gwiazdy śmierci” (death star) oraz wymaga kastomizacji tych aplikacji:

Zwrotne wywołanie

Do dyspozycji mamy funkcję zwrotnego wywołania zwaną webhook:

Webhook to funkcja wywołania zwrotnego oparta na protokole HTTP, która umożliwia lekką, sterowaną zdarzeniami komunikację między 2 interfejsami API. Webhook jest używany do odbierania niewielkich ilości danych z innych aplikacji, ale także do wyzwalania przepływów pracy automatyzacji. Ponieważ webhook może łączyć źródła zdarzeń, jest także jednym ze sposobów uruchamiania działań przez serwer po stronie klienta.

(na podstawie: What is a webhook?)

Wyobraźmy się, że WMS sam informuje nas, że powstał nowy dokument, co wtedy? Wtedy z powyższej sekwencji znika polecenie sprawdzające czy są nowe dokumenty w WMS, zostaje tylko sekwencja pobierająca ten dokument z WMS i umieszczająca go w ERP.

Nie ma żadnych “pustych przebiegów” a system ERP działa praktycznie w czasie rzeczywistym. Czy mamy jakiś problem? Tak, przy dużej licznie operacji magazynowych: koordynator będzie bombardowany wywołaniami.

Podsumowanie

Każdy projekt wymaga analizy, zrozumienia tego co jest problemem a co nim nie jest. Wybór metody zawsze powinien być konsekwencją realnie stwierdzonych potrzeb i problemów. Problemem jest także to, że starsze systemy często nie mają funkcji webhook, ale osobiście wolę “wymusić” na dostawcy by ją zaimplementował, niż tworzyć potworki integracyjne, które szybko mszczą się wysokimi kosztami utrzymania i rozwoju całego systemu w organizacji. Czy to znaczy, że lepiej wdrażać jeden ERP od wszystkiego? Nie, bo nikomu sie to jeszcze nie udało :).

Przy okazji, jednym z większych błędów integracji jest używanie webhook jako narzędzia odsyłania odpowiedzi w dialogach.