Integracja systemów

0

Ciekaw jestem Waszych pomysłów na problem jak niżej.

  1. Mamy zbiór API RESTowych (N różnych mikroserwisów) będących pewnym standardem
  2. Mamy zbiór M systemów (w przyszłości mogą się pojawić nowe, stare zniknąć) z zupełnie innym API (inna technologia, model danych)
  3. Nie mamy możliwości modyfikacji systemów z pkt. 2

W skrócie: istniejące systemy chcemy przykryć standaryzowanym API za pomocą nowej warstwy.

Jak powinien wyglądać box, który będzie z jednej strony wystawiał N API RESTowych, a z drugiej wywoływał API przykrywanych systemów?

Jak dla mnie potrzeba co najmniej dwóch istotnych elementów:

  1. dekompozycja operacji RESTowej na operacje w systemach, które przykrywamy. Tu widziałbym jakiś silnik procesów biznesowych/workflow, który pozwoli na zamienienie np. "Utwórz klienta" na listę aktywności: "Utwórz klienta w systemie X", "Utwórz wpis w Y", "Zmień profil w Z".

Technicznie wpada REST uruchamiający proces biznesowy, którego aktywności przekładają się na wywołania API przykrywanych systemów.

  1. mapowanie produktów/usług z języka używanego w REST na obiekty znane systemom, które są przykrywane. Tu chyba jest największa trudność, bo chcemy obsłużyć potencjalnie nieograniczony (dynamiczny) zbiór usług/produktów. Przykład takiego produktu (z sufitu, ale ilustrującego ideę "produktów złożonych") - "Ubezpieczenie na życie z Canal+ dostępnym przez 30 dni za free i przeglądem auta do wykorzystania w ciągu 30 dni".

Po tym jak ktoś w systemie klasy CRM sprzeda taki produkt, to trzeba go "włączyć" i pojawia się naturalne pytanie, co to znaczy włączyć ten produkt (które zasoby wykorzystać i jak, które systemy kontrolują zasoby itd.)

Gdzie umieścilibyście informację o mapowaniu produktów/usług i dlaczego? np. adapter dla każdego z systemów, dedykowany katalog produktów/usług (odpowiadający na pytania "jestem systemem X, powiedz mi co to znaczy po mojemu produkt A", "które zasoby mam włączyć dla produktu A"), inne?

0

Jak powinien wyglądać box, który będzie z jednej strony wystawiał N API RESTowych, a z drugiej wywoływał API przykrywanych systemów

mapowanie produktów/usług z języka używanego w REST na obiekty znane systemom, które są przykrywane. Tu chyba jest największa trudność, bo chcemy obsłużyć potencjalnie nieograniczony (dynamiczny) zbiór usług/produktów.

Nie musiałem dotąd owijać istniejących systemów w nową skórę (choć w sumie to właśnie owijamy tak bazę, która delikatnie mówiąc jest z czapy, powiedzmy że to też się liczy), ale czy satysfakcjonowało by Cię potraktowanie obiektów istniejących w danym systemie jak entity w zwykłej aplikacji RESTowej i zaimplementowanie jakiegoś generycznego DAO/Repository zdolnego gadać z API wybranego systemu w roli adaptera? Wtedy to, w którym systemie grzebie DAO/Repository, żeby dołożyć pakiet NC+ do jakiegoś pakietu super duper Internetu mobilnego który właśnie dodajesz do listy zamówień byłoby chyba dość przezroczyste dla aplikacji?

0
yarel napisał(a):
  1. dekompozycja operacji RESTowej na operacje w systemach, które przykrywamy. Tu widziałbym jakiś silnik procesów biznesowych/workflow, który pozwoli na zamienienie np. "Utwórz klienta" na listę aktywności: "Utwórz klienta w systemie X", "Utwórz wpis w Y", "Zmień profil w Z".

Ale dla kogo to ma być? Bo każdy jeden programista napisze to szybciej w jakimkolwiek języku programowania, a jeśli chcesz to tworzyć dla jakichś analityków, to czas stworzenia takiego systemu umożliwiającego budowanie aplikacji z klocków może być zbyt długi jak na jedno przedsięwzięcie w IT. (Od 70 lat się nie udało zrobić kompletnego rozwiązania.)

Gdzie umieścilibyście informację o mapowaniu produktów/usług i dlaczego? np. adapter dla każdego z systemów, dedykowany katalog produktów/usług (odpowiadający na pytania "jestem systemem X, powiedz mi co to znaczy po mojemu produkt A", "które zasoby mam włączyć dla produktu A"), inne?

Każde z tych - w zależności od tego, co trzeba zrobić w ramach danego procesu. Do decyzji programistów.

0

@superdurszlak, @somekind: dzięki za odpowiedzi. Chciałem doprecyzować temat, ale w miarę pisania uświadomiłem sobie, że powoli zaczyna wyłaniać mi się rozwiązanie, które mnie satysfakcjonuje. Jak to często bywa, dopóki czegoś się nie opisze, albo ktoś nie zada pytań ciężko ruszyć z miejsca, ale później już z górki :-)

Dla porządku, rozwiązanie (szkielet/ramy) ma być dla programistów zajmujących się integracją gotowych pudełek dla różnych operatorów telekomunikacyjnych. Zarówno warstwa jak i pudełka należą do tego samego dostawcy.

Korzyścią dla operatora byłoby to, że jak już raz się przełączy na Open API, to późniejsza wymiana pudełek na pudełka innego dostawcy byłaby prosta (o ile taki dostawca wspiera Open API ;-) )
W przypadku telco takie api powoli się wykluwa: https://github.com/tmforum/TMFAPISWAGGERS

1 użytkowników online, w tym zalogowanych: 0, gości: 1