Integracja systemów

Odpowiedz Nowy wątek
2018-10-09 09:58
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.

2) 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?

Czyżby coś w stylu https://xkcd.com/927/? ;-) - Patryk27 2018-10-09 10:34
@Patryk27: Prawie, że ;-) Z tym, że te "przykrywane api" są własnościowe i nie są postrzegane jako standard. Chodzi o ich przykrycie (więc na początku będzie więcej), żeby później można było łatwiej usuwać/wymieniać istniejące klocki. - yarel 2018-10-09 11:06
@Patryk27: tak to chyba właśnie wygląda - abrakadaber 2018-10-09 11:28

Pozostało 580 znaków

2018-10-09 16:16
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?


Blocker wiszący od miesiąca? Mówisz o tym criticalu z zeszłego tygodnia? A, tak, zalogowaliśmy przedwczoraj tego minor buga. Pewnie, zajmę się ASAP tym enhancementem. Nie ma sprawy, jak tylko podomykam taski to wezmę się za ten ficzer, tylko go jeszcze wyestymujemy przed kolejnym sprintem.
edytowany 1x, ostatnio: superdurszlak, 2018-10-09 16:18
Ale to tak, jak mówię, luźny pomysł laika - superdurszlak 2018-10-09 16:16
Dzięki za odpowiedź, przetrawię co napisałeś i dam znać co o tym myślę. Póki co jestem po szkoleniu i czuję pewien przesyt nowymi pomysłami ;-) - yarel 2018-10-09 16:47

Pozostało 580 znaków

2018-10-12 03:20
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-10-14 16:02
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

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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