Koleżanki i Koledzy,
Robię integracje w swojej firmie intuicyjnie tworzę nowy projekt w Spring Boot, mapuje pola, zachowania, w przypadku starszych systemów zakładam triggery, które wpychają informacje do tabeli integracyjnej, co jakiś czas to odczytuje i wymieniam dane.
Czy można to robić lepiej?
Czy narzędzie Apache Camel będzie pod tym kątem lepsze?
Jak robicie integracje? Mam wrażenie, że robię to niepoprawnie. Ostatnio kupiłem dosyć ciekawą książkę odnośnie wzorców integracji (Enterprise Integration Patterns Gregor Hohpe - https://www.amazon.pl/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683 ) i zaczynam ją przerabiać. Proszę o radę, wymianę doświadczeń itp.
0
6
Zacznij może od napisania w jaki sposób system z którym się chcesz integrować działa. Jeżeli ma np. jakieś api resetowe, to bez sensu robić integrację przez bazę danych.
0
@.andy: Z systemem który jest COREM (ERP), bez API REST-owego. Walczę w firmie o to, żeby Zarząd w końcu znalazł czas na tworzenie takiego API, bo to jest ciągle klepanie w kółko jednego i tego samego. Pozostałe systemy mają REST / SOAP API, więc problemu nie ma. Najczęściej też mają rozwiązania w oparciu o ENDPOINT z logami.
5
Poza technicznymi aspektami integracji ważne też jest ta logiczna: czyli czy dane mogą być przesyłane wsadowo (np co jakiś czas) czy raczej real time Ile masz tych danych? Czy jest to zwykłe uwspólnienie np słownika klientów czy po stronie systemy docelowego jest jakaś logika, która może zająć dużo czasu? Czy potrzebujesz potwierdzenia odebrania i przetworzenia danych, czy obsługa błędów będzie się odbywać po stronie odbiorcy.
Pracuje w projektach gdzie jest Apache Camel i wyje mi się, że sensowność jego użycia jest przy dużej ilości metod integracyjnych, systemów do zintegrowania. Przy dwóch systemach raczej to będzie jak użycie kombajny dla jednego kłosa.
5
Masz genearlnie dwa podejścia:
- data integration (przez triggery, replikacja danych, rozwiązania typu ETL)
- application integration (via interfejsy między systemami)
np.
data integration -> encjaA.atrybutB w systemieX zmienia się z 2 na 3. Propagujesz dane do systemuY i tam encjaB.atrybutC = Zakończone (propagacja może być bezpośrednia, np. trigger + update po db linku w ramach transakcji bazodanowej, albo pośrednie, trigger coś loguje do jakieś tabelki, a później coś z niej czyta i coś robi dalej, np. narzędzie ETL typu Pentahoo, czy jakiś własny moduł/skrypt)
application integration -> aplikacja generuje zdarzenie i przekazuje je do innego systemu (bezpośrednio - wywołanie API tego innego systemu) lub pośrednio (np. szyna integracyjna).
Przy application integration masz o tyle lepiej, że wiesz co się wydarzyło, przy integracji wia dane nie wiesz co się wydarzyło. np. Saldo zmienia się o 15. Co to było zakup? Rabat? Kara umowna?
Obydwa podejścia mają swoje wady i zalety w kontekście konkretnego problemu i środowiska w którym wdrażasz taką integrację. Co innego jak masz 2-3 systemy, a co innego jak masz ich kilkaset.
0
@yarel: To można powiedzieć, że u mnie są dwa podejścia.
Trigger w ERP-ie dodaje logi do tabeli. w innym systemie również najczęściej jest endpoint, który zawiera logi i są sczytywane od ostatniego ID.
Usługa pośrednicząca napisana w Spring Boot sprawdza logi w obu systemach i wykonuje konkretne akcje, w przypadku systemu ERP na procedurach SQL, a w innym, zewnętrznym systemie wywołuje konkretne endpointy API.
@UglyMan: Czyli w sumie używam dobrego podejścia? Szczerze mówiąc najczęściej jest maksymalnie 20 endpointów do obsłużenia na każdą integrację jak na razie (SALDEO, BASELINKER, zewnętrzne sklepy, integracje wymiany zamówień, platformy B2B, zewnętrzne WMS-y).
2
@RSom: W sumie trochę tego już jest. Można by już pomyśleć ja jakimś rozwiązaniu bardziej elastycznym jak np https://www.mulesoft.com/ albo coś takiego https://help.hitachivantara.com/Documentation/Pentaho/9.0/Products/Pentaho_Data_Integration . Jak napiszesz apkę to zmiany w API któregokolwiek systemu będą wymagały ingerencji w kod. Rozwiązania dedykowane dają również wsparcie w takich rzeczach jak obsługa błedów - powtarzanie wysyłania pakietów jak docelowe api jest niedostępne, obsługa błędów itp itd. Integracja jest prosta jak wszystko działa - gorzej jak jeden pakiet wysyłasz do 3 systemów i dwa zaakceptują a 3 nie.
Przy integracji ważne jest też, żeby ustalić system nadrzędny dla danych (czyli jak się coś rozjedzie to, który system jest jako ten poprawny) : dla magazynu będzie to pewnie WMS ( a nie ERP) itp.
1
@UglyMan: Dziękuję za konkretną dawkę wiedzy. Zdoktoryzuję się z tych rozwiązań i coś wybiorę. Spróbuję zrobić też większy nacisk na zarząd, żeby w końcu wyraził zgodę i wyznaczył ramę czasową na utworzenie API systemu ERP, bo jest wykonywana ta sama robota praktycznie za każdym razem.
0
RSom napisał(a):
Robię integracje w swojej firmie intuicyjnie tworzę nowy projekt w Spring Boot, mapuje pola, zachowania, w przypadku starszych systemów zakładam triggery, które wpychają informacje do tabeli integracyjnej, co jakiś czas to odczytuje i wymieniam dane.
Czy można to robić lepiej?
Można. Na początek proponuję przestać kompulsywnie tworzyć projekty w Springu.
Zwykle lepiej zamiast tabeli w bazie danych użyć jakiejś kolejki:
- prościej
- pewniej
- nie trzeba pisać podróby kolejki na bazie danych
- wypychasz zdarzenia (i związane z nimi dane), a nie cyklicznie się na nie zapinasz
- masz prostą transakcyjność peek&delete
Nie wiem co robisz w tej integracji, ale są od tego narzędzia, pierwsze z brzegu to https://help.hitachivantara.com/Documentation/Pentaho/7.1/0D0/Pentaho_Data_Integration czyli jeden system ma swoje api, drugi system ma swoje api a ty stawiasz po środku middleware i klepiesz te mapowania. Da się podłączyć do kolejek, da się podłączyć do baz danych, wywołać API po rest, soap, a jak potrzebujesz to wyeksportować do excela (jak to w korpo).