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:

Gwiazda Śmierci: architektura integracji każdy z każdym (Death Star https://www.linkedin.com/pulse/find-your-path-death-star-microservices-architecture-van-der-schaaf/)

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.

Zasada działania funkcji webhook po stronie serwera i jej efekt (tu system WMS)

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.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.