Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem rozwiązań.

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu informatycznego. 

Wyjątkowo na począt­ku (poni­żej) umiesz­czam cały ten cie­ka­wy refe­rat, moż­na bo pomi­nąć i czy­tać dalej, jed­nak jeże­li ktoś chce poznać prze­wi­dy­wa­nia z roku 2016 i ma czas, pole­cam (teraz lub później):

Pogodzenie się z tym, że świat sys­te­mó ERP już nigdy nie będzie tak pro­sty jak w cza­sach main­fra­me­’ów, czy­li jed­nej cen­tral­nej apli­ka­cji, jest nieuniknione. 

Czym jest obec­nie inte­gra­cja? To wymia­na danych a nie ich współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych w cza­sach obec­nych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czy­li Planowanie Zasobów Przedsiębiorstwa. To sys­tem wyko­rzy­sty­wa­ny przez fir­my do zarzą­dza­nia i inte­gro­wa­nia waż­nych ele­men­tów ich dzia­łal­no­ści. Ale kto powie­dział, że to ma być mono­lit od jed­ne­go producenta? 

Nadal spo­ty­kam pejo­ra­tyw­ne okre­śle­nia ​„sys­tem poin­te­gro­wa­ny” jako kry­ty­kę budo­wy sys­te­mu ERP z kom­po­nen­tów i inte­gra­cji jako wymia­ny danych. Autor tego okre­śle­nia naj­praw­do­po­dob­niej nadal żyje w świe­cie mainframe. 

Chociaż dostaw­cy sys­te­mów ERP ofe­ru­ją apli­ka­cje dla przed­się­biorstw i twier­dzą, że ich zin­te­gro­wa­ny sys­tem jest naj­lep­szym roz­wią­za­niem, wszyst­kie modu­ły w jed­nym sys­te­mie ERP rzad­ko kie­dy są naj­lep­sze z najlepszych.

https://​www​.gart​ner​.com/​e​n​/​i​n​f​o​r​m​a​t​i​o​n​-​t​e​c​h​n​o​l​o​g​y​/​g​l​o​s​s​a​r​y​/​b​e​s​t​-​o​f​-​b​r​eed

Integracja tak, ale czy to ma być jedna wspólna baza danych? 

Po pierw­sze dane mają róż­ne kon­tek­sty, a ich zna­cze­nie zale­ży od kon­kret­ne­go kon­tek­stu i miej­sca użycia: 

Powyżej zobra­zo­wa­no dane i ich kon­tekst. Data może być datą uro­dzin lub datą śmier­ci i nadal jest to data. Osoba może być oby­wa­te­lem w pań­stwo­wym reje­strze, ale może być pra­cow­ni­kiem, klien­tem itp.. Opis oso­by (struk­tu­ra danych) nie zmie­nia się mimo zmia­ny jej roli. W reje­strze oby­wa­te­li data, jako pole (powy­żej), nawet taka sama, może tu wystę­po­wać wie­lo­krot­nie (tego same­go dnia może się wyda­rzyć nie­za­leż­nie wie­le róż­nych rze­czy). Jednak ta sama data, jako war­tość w reje­strze będą­cym kalen­da­rzem, musi być uni­kal­na: tu wystę­pu­je tyl­ko jeden raz. Czyli kalen­darz i rejestr np. aktów uro­dze­nia nie może być ​„jed­na bazą”. 

Jak widać powyż­szej, to doku­ment i struk­tu­ra doku­men­tu, nada­je kon­tekst danym prze­cho­wy­wa­nym w polach (doku­ment, jego sek­cja). Takiej struk­tu­ry, natu­ral­nej z per­spek­ty­wy języ­ko­wej i biz­ne­so­wej, nie da się mapo­wać na, pozba­wio­ny redun­dan­cji, model rela­cyj­nej bazy danych. Zapisanie tego doku­men­tu w mode­lu rela­cyj­nym typo­we­go ERP wyma­ga stwo­rze­nia dodat­ko­wych tablic, a odtwo­rze­nie z nich doku­men­tu wyma­ga skom­pli­ko­wa­ne­go zapy­ta­nia SQL do tej bazy (nie w niej doku­men­tów a jedy­nie dane). W bazach rela­cyj­nych NIE MA żad­nych doku­men­tów, są wycią­gnię­te z nich, i pozba­wio­ne kon­tek­stu, dane. Ich zapis i pobra­nie wyma­ga skom­pli­ko­wa­nych (czy­taj kosz­tow­nych w utwo­rze­niu i kon­ser­wa­cji) zapy­tań SQL. 

Powyższy doku­ment, bez żad­ne­go pro­ble­mu: bez utra­ty kon­tek­stu i bez mno­że­nia typów dat, zapi­sze­my jako kom­plet­ny for­mu­larz, np. w for­ma­cie XML w doku­men­to­wej bazie danych .

Wspólna baza danych jest z zasa­dy jed­no­kon­tek­sto­wa, więc pew­nych infor­ma­cji, jako nie­za­leż­nych infor­ma­cji, po pro­stu nie da się tak prze­twa­rzać. To dla­te­go prak­tycz­nie nie jest moż­li­we zbu­do­wa­nie jed­ne­go uni­wer­sal­ne­go sys­te­mu ERP z jed­ną cen­tral­ną rela­cyj­ną bazą danych, ale moż­li­we jest łatwe zbu­do­wa­nie dowol­ne­go sys­te­mu w posta­ci kil­ku zin­te­gro­wa­nych, dzie­dzi­no­wych kom­po­nen­tów. Problem ten opi­sał i wyja­śnił w 2014 roku M.Fowler:

„Sales Context” oraz ​„Support Context” to dwa róż­ne kon­tek­sty prze­twa­rza­nia tych samych danych: Customer i Product w kon­tek­ście sys­te­mu sprze­da­ży (np. CRM) to uni­kal­ne, czę­sto aktu­ali­zo­wa­ne, zapi­sy w bazie tego kom­po­nen­tu. Jednak w kon­tek­ście zgło­szeń ser­wi­so­wych są to wyłącz­nie atry­bu­ty Zgłoszeń ser­wi­so­wych, jako fak­ty histo­rycz­ne, są nie­zmie­nial­ne w przy­szło­ści. Zbudowanie takie­go sys­te­mu w posta­ci dwóch odręb­nych i zin­te­gro­wa­nych kom­po­nen­tów będzie pro­ste. Zbudowanie go w opar­ciu o jed­ną współ­dzie­lo­ną, rela­cyj­ną bazę danych, będzie bar­dzo kosz­tow­nym wyzwa­niem, a w przy­szło­ści nie będzie­my mogli tych obsza­rów oddzie­lić od sie­bie, np. gdy fir­ma podzie­li sie na dwie spe­cja­li­zo­wa­ne spół­ki (co jest dość czę­sto obecnie).

Bardzo duża wadą sys­te­mów trans­ak­cyj­nych, budo­wa­nych na jed­nej cen­tral­nej bazie rela­cyj­nej, jest ich male­ją­ca wydaj­ność ze wzro­stem licz­by użyt­kow­ni­ków i ilo­ści zapi­sa­nych danych. Wady tej nie mają sys­te­my kom­po­nen­to­we i sys­te­mu budo­wa­ne na doku­men­to­wych bazach danych typu NoSQL (patrz dla­cze­go).

Referencyjny model procesów biznesowych

Czasy mono­li­tów się skoń­czy­ły, i nawet jeże­li pla­no­wa­ne jest wdro­że­nie ​„jed­ne­go ERP”, już nigdy nie będzie to jedy­na apli­ka­cja w fir­mie. Coraz czę­ściej zakres wdro­że­nia mono­li­tycz­ne­go sys­te­mu ERP ogra­ni­cza się do obsza­ru nazy­wa­ne­go ​„back-offi­ce” czy­li do księ­go­wo­ści i admi­ni­stra­cji (pro­ce­sów wspie­ra­ją­cych). W 1985 roku M.E.Porter (rok 1985 to pierw­sze wyda­nie Strategii Konkurencji ) opi­sał tak zwa­ny wewnętrz­ny łań­cuch war­to­ści fir­my. Graficznie zobra­zo­wał go tak:

Powyższy dia­gram nadal sta­no­wi kla­sy­kę pro­ce­so­we­go podej­ścia do zarzą­dza­nia i struk­tu­ry gru­po­wa­nia pro­ce­sów biz­ne­so­wych (patrz Cambridge). Jest to stan­dar­do­wy, bazo­wy szkie­let mode­lo­wa­nia pro­ce­sów biz­ne­so­wych wewnątrz orga­ni­za­cji (star­ting point). Procesy biz­ne­so­we (czy­li tak­że aktyw­no­ści jako ich wewnętrz­na część) zosta­ły tu podzie­lo­ne na dwie pod­sta­wo­we gru­py: wspie­ra­ją­ce (suport acti­vi­ties) i ope­ra­cyj­ne (pri­ma­ry acti­vi­ties, core). 

Pomiędzy gru­pą pro­ce­sów wspie­ra­ją­cych i ope­ra­cyj­nych jest zasad­ni­cza róż­ni­ca: zmien­ność i zależ­ność od pra­wa i stan­dar­dów. Procesy wspie­ra­ją­ce są w znacz­nej mie­rze regu­lo­wa­ne pra­wem, sta­no­wią stan­dar­dy zarzą­dza­nia, nor­my pro­ce­du­ral­ne (nor­my ISO itp.). Ten obszar nie budu­je prze­wa­gi ryn­ko­wej, tu mar­ża powsta­je jako wewnętrz­na spraw­ność (obni­ża­nie kosztów). 

Procesy ope­ra­cyj­ne (core) to klu­czo­wy łań­cuch budo­wy mar­ży. To tu powsta­je prze­wa­ga ryn­ko­wa: jakość pro­duk­tów i usług. To tu są wdra­ża­ne stan­dar­dy bran­żo­we. Tu jest wła­śnie dzi­siej­sza gra­ni­ca mię­dzy ERP (pro­ce­sy wspie­ra­ją­ce, zaso­by), a apli­ka­cja­mi dzie­dzi­no­wy­mi (WMS, MES, APS, WorkFlow, e‑Commerce i wie­le innych). Próba uczy­nie­nia z nich wszyst­kich modu­łów jed­ne­go sys­te­mu, współ­dzie­lą­ce­go dane w jed­nej bazie danych, jest prak­tycz­nie awy­ko­nal­na (patrz powyż­sze M.Fowler). Tym bar­dziej, że czę­sto­tli­wość zmian w każ­dym obsza­rze jest inna, a dzie­dzi­no­we sys­te­my np. wspo­ma­ga­nia pro­duk­cji to zupeł­nie inny obszar spe­cja­li­za­cji niż np. księ­go­wość czy kadry (to dla­te­go zupeł­nie inne fir­my spe­cja­li­zu­jąc się w dostar­cza­niu opro­gra­mo­wa­nia dla tych dziedzin). 

Właśnie głów­nym powo­dem tego podzia­łu, i tego że linia tego podzia­łu jest mię­dzy admi­ni­stra­cją a dzia­łal­no­ścią ope­ra­cyj­ną, jest zmien­ność. Gdyby porów­nać mię­dzy sobą fir­my z róż­nych branż, to oka­że się, że obszar pro­ce­sów wspie­ra­ją­cych to sta­bil­ny obszar admi­ni­stra­cji, gdzie rota­cja kadr jest mała, a ewen­tu­al­na zmia­na miej­sca pra­cy nie zale­ży od bran­ży i nie wyma­ga przekwalifikowania. 

Obszar ope­ra­cyj­ny to dedy­ko­wa­ne dzie­dzi­no­we dzia­ła­nia, nace­cho­wa­ne spe­cy­fi­ką kon­kret­nej bran­ży i spe­cja­li­sta­mi ​„z dzie­dzi­ny…”. To dla­te­go na ryn­ku jest tak wie­le dzie­dzi­no­wych apli­ka­cji, któ­re powsta­ły do zarzą­dza­nia spe­cy­fi­ką okre­ślo­nych dzia­łań w okre­ślo­nej bran­ży. Nie przy­pad­kiem nazy­wa­my te apli­ka­cje ​„sys­te­ma­mi branżowymi”. 

Firma pro­duk­cyj­na to z regu­ły naj­bar­dziej skom­pli­ko­wa­ny mecha­nizm, sys­tem ERP sta­no­wi tu jedy­nie czu­bek całe­go systemu:

W efek­cie, dzi­siej­sza spraw­na fir­ma (orga­ni­za­cja) będzie mia­ła ​„stan­dar­do­wy ERP” wdro­żo­ny w obsza­rze pro­ce­sów wspie­ra­ją­cych, oraz – zin­te­gro­wa­ny z nim – zestaw dedy­ko­wa­nych, bran­żo­wych aplikacji.

Integracja jako wymaganie

Ta część jest adre­so­wa­na do każ­de­go kto mode­lu­je inte­gra­cje sys­te­mów IT (lub chce się tego nauczyć). 

W 2014 arty­kuł o inte­gra­cji koń­czy­łem słowami: 

Dedykowane dzie­dzi­no­we apli­ka­cje coraz czę­ściej są wdra­ża­ne eta­pa­mi zamiast jed­ne­go duże­go ERP. Taka inte­gra­cja nie jest wbrew pozo­rom kosz­tow­na, kosz­tow­ny jest brak sto­so­wa­nia dobrych prak­tyk i wzor­ców, któ­re war­to poznać. Zwinność dzia­ła­nia dzi­siej­szych firm na ryn­ku to wymóg a nie opcja. Zwinność taka to nie jeden duży ERP (mono­pol jed­ne­go usłu­go­daw­cy), to kil­ka zin­te­gro­wa­nych, dedy­ko­wa­nych nie­za­leż­nych apli­ka­cji , wdra­ża­nych bez kasto­mi­za­cji (wybie­ra­my naj­lep­szy pro­dukt w danym momen­cie). Ich (apli­ka­cje dzie­dzi­no­we) wymia­na na inne, przy dobrze wyko­na­nej inte­gra­cji, to jest pro­ces, któ­ry nie gene­ru­je mon­stru­al­nych kosz­tów każ­do­ra­zo­wej ana­li­zy i prze­rób­ki cało­ści IT (kolej­nej kasto­mi­za­cji jed­ne­go ERP) w firmie.

(źr.: Wymagania poza­funk­cjo­nal­ne – inte­gra­cja – Jarosław Żeliński IT-Consulting)

Modelowanie inte­gra­cji opi­sy­wa­łem nie raz (patrz wyżej cyto­wa­ny arty­kuł): nale­ży udo­ku­men­to­wać archi­tek­tu­rę (kom­po­nen­ty i ich powią­za­nia), doku­men­ty ope­ra­cyj­ne (jako agre­ga­ty danych), oraz sce­na­riu­sze opi­su­ją­ce meto­dy osią­ga­nia ocze­ki­wa­ne­go efek­tu. Scenariusze doku­men­tu­je­my dia­gra­ma­mi sekwen­cji, a zale­ca­ne para­me­try wywo­łań to wła­śnie ww. agre­ga­ty repre­zen­tu­ją­ce doku­men­ty (imple­men­to­wa­ne jako JSON lub XML). Taka postać mode­li jest dosko­na­ła do testów inte­gral­no­ści, jed­nak bar­dzo czę­sto poja­wia się potrze­ba prze­ka­za­nia w spe­cy­fi­ka­cji wyma­gań jed­ne­go określ­ne­go API, jako wydzie­lo­nej per­spek­ty­wy, i tu przy­cho­dzi z pomo­cą moż­li­wość stwo­rze­nia dedy­ko­wa­ne­go dia­gra­mu klas, któ­re­go celem jest udo­ku­men­to­wa­nie wyłącz­nie okre­ślo­ne­go API (np. wyma­ga­ne­go lub usta­lo­ne­go w toku wdrożenia). 

Trochę technologii czyli REST API

„Przenoszenie Reprezentacji Stanu” (ang. Representational sta­te trans­fer: REST) jest meto­dą komu­ni­ka­cji, któ­ra defi­niu­je zestaw wyma­gań przy two­rze­niu usług sie­cio­wych. Usługi sie­cio­we, któ­re są zgod­ne z REST, zwa­ne tak­że usłu­ga­mi sie­cio­wy­mi RESTful Web Services (RWS), zapew­nia­ją inte­ro­pe­ra­cyj­ność mię­dzy sys­te­ma­mi kom­pu­te­ro­wy­mi, tak sie­ci Internet jak i wewnątrz sie­ci jed­nej orga­ni­za­cji. Usługi RWS umoż­li­wia­ją sys­te­mom (inte­gro­wa­nym apli­ka­cjom) wza­jem­ny dostęp do danych w for­mie tek­sto­wej i mani­pu­la­cję nimi, za pomo­cą jed­no­li­te­go i pre­de­fi­nio­wa­ne­go zesta­wu bez­sta­no­wych ope­ra­cji. Całość nazy­wa­my sty­lem budo­wy archi­tek­tu­ry, jest on w peł­ni zgod­ny z obiek­to­wym i kom­po­nen­to­wym, zorien­to­wa­nym na inter­fej­sy, podej­ściem do pro­jek­to­wa­nia sys­te­mów, a klu­czo­wą zasa­dą jest tu her­me­ty­za­cja i wąska odpo­wie­dzial­ność kom­po­nen­tów. Podstawowe wzor­ce archi­tek­to­nicz­ne wyko­rzy­sty­wa­ne przy pro­jek­to­wa­niu inte­gra­cji to Saga, Łańcuch odpo­wie­dzial­no­ści i Repozytorium.

Dzięki bez­sta­no­we­mu pro­to­ko­ło­wi i stan­dar­do­wym ope­ra­cjom, sys­te­my budo­wa­ne w opar­ciu o RWS uzy­sku­ją dużą wydaj­ność, nie­za­wod­ność i moż­li­wość roz­wo­ju poprzez ponow­ne wyko­rzy­sta­nie kom­po­nen­tów (her­me­ty­za­cja), któ­re mogą być zarzą­dza­ne i aktu­ali­zo­wa­ne bez wpły­wu na sys­tem jako całość, nawet pod­czas jego działania.

Ograniczenia architektoniczne czyli wymagania wobec architektury

REST defi­niu­je 6 wyma­gań (to jego głów­ne cechy) architektonicznych.

1. Architektura usługobiorca-usługodawca

Zasadą sto­ją­cą za ogra­ni­cze­nia­mi usłu­go­bior­ca-usłu­go­daw­ca (inne spo­ty­ka­ne nazwy to: klient usłu­gi i usłu­go­daw­ca, klient-ser­wer, client – servi­ce pro­vi­der), jest sepa­ra­cja kon­tek­stów. Oddzielenie zadań zwią­za­nych z inter­fej­sem użyt­kow­ni­ka od zadań zwią­za­nych z logi­ką biz­ne­so­wą i prze­cho­wy­wa­niem danych popra­wia prze­no­śność inter­fej­sów użyt­kow­ni­ka na wie­lu plat­for­mach. Poprawia to rów­nież ska­lo­wal­ność poprzez uprosz­cze­nie kom­po­nen­tów (kil­ka pro­stych zamiast jed­ne­go zło­żo­ne­go). Być może naj­bar­dziej zna­czą­ce dla sie­ci Internet (i dla sie­ci w ogó­le) jest jed­nak to, że sepa­ra­cja ta (her­me­ty­za­cja) pozwa­la kom­po­nen­tom roz­wi­jać się nie­za­leż­nie, bez wpły­wu na pozo­sta­łe, pozwa­la­jąc w ten spo­sób na ist­nie­nie róż­no­rod­no­ści tak w sie­ci Internet, jak i w sie­ci lokal­nej orga­ni­za­cji, pozwa­la na współ­ist­nie­nie wie­lu róż­nych i nie­za­leż­nych domen i zaso­bów. Hermetyzacja to tak­że nie­za­leż­ność od typów danych: prze­ka­zy­wa­ne dane to wyłącz­nie cią­gi zna­ków (string), ich typy muszą być uzgod­nio­ne po obu stro­nach (JSON) lub zde­fi­nio­wa­ne (XSD/XML) i mogą być ina­czej zde­fi­nio­wa­ne w każ­dym z pod­sys­te­mów (np. w jed­nym sys­te­mie będzie to np. typ ​„date” w bazie rela­cyj­nej, a w innym ciąg zna­ków i maska walidacji). 

2. Bezstanowość

Komunikacja usłu­go­bior­ca-usłu­go­daw­ca jest ogra­ni­czo­na tym, że żaden kon­tekst usłu­go­bior­cy nie jest prze­cho­wy­wa­ny u usłu­go­daw­cy pomię­dzy żąda­nia­mi. Każde żąda­nie od dowol­ne­go usłu­go­bior­cy zawie­ra wszyst­kie infor­ma­cje nie­zbęd­ne do obsłu­że­nia żąda­nia. Stan sesji jest prze­cho­wy­wa­ny zawsze po stro­nie usłu­go­bior­cy (patrz wzo­rzec pro­jek­to­wy Saga). Stan sesji może być prze­ka­za­ny przez usłu­go­daw­cę do innej usłu­gi, takiej jak baza danych, aby utrzy­mać trwa­ły stan przez pewien czas i umoż­li­wić uwie­rzy­tel­nie­nie, ale wte­dy sta­no­wi on (stan jako nazwa) takie same dane jak pozo­sta­łe prze­ka­za­ne. Usługobiorca zaczy­na wysy­łać żąda­nia, gdy jest goto­wy do przej­ścia do kolej­ne­go kro­ku (nowe­go sta­nu). Reprezentacja każ­de­go sta­nu apli­ka­cji zawie­ra odno­śni­ki, któ­re mogą być uży­te następ­nym razem, gdy klient zde­cy­du­je się zaini­cjo­wać przej­ście do takie­go stanu. 

Kluczową cechą tej archi­tek­tu­ry jest tak­że to, że usłu­go­daw­ca (ser­wer) nigdy sam nie wywo­łu­je usłu­go­bior­cy (klient)!

3. Zdolność bufo­ro­wa­nia (cache)

Podobnie jak w sie­ci WWW, usłu­go­bior­ca i pośred­ni­cy mogą bufo­ro­wać odpo­wie­dzi. Odpowiedzi muszą zatem, w spo­sób ukry­ty lub jaw­ny, okre­ślać się (być ozna­czo­ne) jako bufo­ro­wal­ne lub nie, aby zapo­biec otrzy­my­wa­niu przez usłu­go­bior­cę nie­ak­tu­al­nych lub nie­po­praw­nych danych w odpo­wie­dzi na kolej­ne żąda­nia. Dobrze zarzą­dza­ne bufo­ro­wa­nie czę­ścio­wo lub cał­ko­wi­cie eli­mi­nu­je nie­któ­re inte­rak­cje usłu­go­bior­ca-usłu­go­daw­ca, dodat­ko­wo popra­wia­jąc ska­lo­wal­ność i wydajność.

4. Warstwy pośrednie

Usługobiorca zazwy­czaj nie może stwier­dzić, czy jest połą­czo­ny bez­po­śred­nio z ser­we­rem koń­co­wym, czy z pośred­ni­kiem po dro­dze. Oznacza to, że usłu­go­bior­ca nie wie, czy roz­ma­wia z pośred­ni­kiem (sys­tem pośred­ni­czą­cy, np. pro­xy), czy z wła­ści­wym usłu­go­daw­cą (patrz wzo­rzec archi­tek­to­nicz­ny Łańcuch odpo­wie­dzial­no­ści). Jeśli więc pomię­dzy usłu­go­bior­cą a usłu­go­daw­cą zosta­nie umiesz­czo­ne pro­xy lub load balan­cer, nie będzie to mia­ło wpły­wu na komu­ni­ka­cję i nie będzie koniecz­no­ści aktu­ali­zo­wa­nia kodu usłu­go­bior­cy lub usłu­go­daw­cy. Serwery (usłu­gi) pośred­ni­czą­ce mogą popra­wić ska­lo­wal­ność sys­te­mu poprzez umoż­li­wie­nie rów­no­wa­że­nia obcią­że­nia i zapew­nie­nie współ­dzie­lo­nych pamię­ci pod­ręcz­nych. Ponadto, bez­pie­czeń­stwo może być doda­ne jako dodat­ko­wa war­stwa pośred­nia dla usług sie­cio­wych, by wyraź­nie oddzie­lić logi­kę biz­ne­so­wą od logi­ki (reguł) bez­pie­czeń­stwa. Np. wydzie­le­nie war­stwy kon­tro­li dostę­pu do danych, wymu­sza np. wdra­ża­nie poli­ty­ki bez­pie­czeń­stwa (patrz wzo­rzec archi­tek­to­nicz­ny Repozytorium). Wreszcie, ozna­cza to rów­nież, że usłu­go­daw­ca (ser­wer) tak­że może wywo­ły­wać wie­le innych ser­we­rów w celu wyge­ne­ro­wa­nia odpo­wie­dzi dla usłu­go­bior­cy (klien­ta).

5. Kod na żąda­nie (opcjo­nal­nie)

Serwery usłu­go­daw­cy mogą tym­cza­so­wo roz­sze­rzać lub dosto­so­wy­wać funk­cjo­nal­ność usłu­go­bior­cy (klien­ta), prze­sy­ła­jąc mu zwrot­nie kod wyko­ny­wal­ny: na przy­kład skom­pi­lo­wa­ne kom­po­nen­ty, takie jak aple­ty Java, lub skryp­ty po stro­nie prze­glą­dar­ki WWW, takie jak JavaScript (to doty­czy apli­ka­cji inter­ne­to­wych dzia­ła­ją­cych w prze­glą­dar­ce WWW, a nie inte­gra­cji sys­te­mów, przy­kład w dal­szej części). 

6. Jednolity interfejs

Jednolity inter­fejs defi­niu­je komu­ni­ka­cję pomię­dzy usłu­go­bior­cą i usłu­go­daw­cą. Gdy pro­gra­mi­sta zapo­zna się z jed­nym ze zde­fi­nio­wa­nych inter­fej­sów API, powi­nien być w sta­nie zasto­so­wać podob­ne podej­ście do innych inter­fej­sów API, któ­re musi wykonać.

Polecenia HTTP REST

W REST infor­ma­cje po stro­nie ser­we­ra są trak­to­wa­ne jako zasób, do któ­re­go mozna uzy­skać dostęp w jed­no­li­ty spo­sób za pomo­cą URI (Uniform Resource Identifiers) i pro­to­ko­łu HTTP. Metody GET, POST, PUT i DELETE są stan­dar­do­wo uży­wa­ne w archi­tek­tu­rze inte­gra­cji opar­tej na REST. Poniższy sche­mat zawie­ra obja­śnie­nie tych metod:

Warto wie­dzieć, że zamiast PUT moż­na użyć PATCH, jest to uprosz­cze­nie aktu­ali­zu­ją­ce wyłącz­nie zmie­nio­ne atry­bu­ty obiek­tu, wię­cej tu: REST API ? POST vs PUT vs PATCH.

Jak to działa w sieci?

REST pozwa­la tak­że na obsłu­gę żąda­nia dostę­pu do zaso­bów inter­ne­to­wych i mani­pu­lo­wa­nia nimi przy uży­ciu jed­no­li­te­go i pre­de­fi­nio­wa­ne­go zesta­wu reguł. Interakcja w sys­te­mach inter­ne­to­wych opar­tych na REST odby­wa się poprzez inter­ne­to­wy pro­to­kół HTTP (Hypertext Transfer Protocol). Na sys­tem Restful skła­da­ją się:

• Żądający zaso­bów (obsłu­gi) klient (usłu­go­bior­ca).
• Posiadający te zaso­by i udo­stęp­nia­ją­cy je ser­wer.

Np.:

Więcej:

Modelowanie REST API

Standardowa konstrukcja UML

W UML inter­fejs to na dia­gra­mie klas UML kla­sa ozna­czo­na ste­reo­ty­pem «inter­fejs», ope­ra­cje tej kla­sy to ope­ra­cje tego inter­fej­su. Na dia­gra­mie kom­po­nen­tów kla­sa inter­fej­su jest repre­zen­to­wa­na tyl­ko jako nazwa i zobra­zo­wa­na sym­bo­lem zwa­nym ​„lizak” i ​„kie­li­szek”, poka­za­no to poniżej: 

Na powyż­szym dia­gra­mie poka­za­no dwa kom­po­nen­ty: Klient (żąda usług) i Serwer (świad­czy usłu­gi). Przepływ danych może być w dwie stro­ny: pole­ce­nie get do Klienta oraz pole­ce­nia cre­ate i upda­te do ser­we­ra, jed­nak ini­cjo­wa­ne są one z zasa­dy przez kom­po­nent Klient (usłu­go­bior­ca wywo­łu­je ope­ra­cje usłu­go­daw­cy). Konstrukcja z liza­kiem jest sto­so­wa­na na Diagramie Komponentów. Na dia­gra­mie klas inter­fejs REST_API poka­że się (zosta­nie zobra­zo­wa­ny) jako kla­sa o ste­reo­ty­pie «inter­fa­ce».

W repo­zy­to­rium mode­lu ​„lizak” REST-API oraz kla­sa REST_API to ten sam ele­ment. W rze­czy­wi­sto­ści są to np. trzy diagramy:

Diagram inte­rak­cji UML poka­zu­je wywo­ła­nia ope­ra­cji inter­fej­su REST_API (przy­po­mi­nam, że linie życia na dia­gra­mie inte­rak­cji repre­zen­tu­ją obiek­ty klas a nie klasy). 

Aby opi­sać por­ty sto­su­je­my Diagram Struktur Złożonych UML (Composite Structure Diagram), komponent/klasyfikator z por­ta­mi WE i WY:

Modelowanie REST API z pomocą Visual Paradigm

Niektóre narzę­dzia CASE pozwa­la­ją na wyko­na­nie dedy­ko­wa­nej doku­men­ta­cji API, w spo­sób pozwa­la­ją­cy tak­że, w razie takiej potrze­by, na wyge­ne­ro­wa­nie szkie­le­tu kodu i jego dokumentacji. 

Producent narzę­dzia CASE Visual Paradigm dostar­cza powyż­szą kon­struk­cję jako pre­de­fi­nio­wa­ną kla­sę: dodat­ko­wy ste­reo­typ ​„zasób REST”, nada­jąc mu dedy­ko­wa­ny sym­bol (pro­fil REST). Tak to opi­su­je pro­du­cent na swo­jej stronie:

Wywołanie API jest pod­sta­wo­wym ele­men­tem usłu­gi sie­cio­wej, i powin­no być zgod­ne z REST. Jest to obiekt zawie­ra­ją­cy URI, meto­dę żąda­nia http, powią­za­ne para­me­try oraz spe­cy­fi­ka­cję żądania/odpowiedzi. Każdy z zaso­bów REST repre­zen­tu­je kon­kret­ną usłu­gę dostęp­ną na ścież­ce okre­ślo­nej przez jego wła­ści­wość URI. Dlatego, jeśli chcesz mode­lo­wać wie­le usług, nale­ży nary­so­wać wie­le zaso­bów REST. (źr.:: How to design REST API – Visual Paradigm)

Z per­spek­ty­wy mode­lo­wa­nia jest to nadal stan­dar­do­wy dia­gram klas UML, jedy­nym dodat­kiem jest spe­cja­li­zo­wa­ny sym­bol sta­no­wią­cy abs­trak­cję inter­fej­su ofe­ro­wa­ne­go. Wymienjony ​„zasób REST” to wła­śnie opi­sa­na abs­trak­cyj­na kla­sa, zobra­zo­wa­na jak na rysun­ku powy­żej. Poniżej przy­kła­do­wy efekt czy­li doku­men­ta­cja API z uży­ciem powyż­szej metody:

Np. Bardzo pro­sta komu­ni­ka­cja (inter­fejs ofe­ro­wa­ny przez ERP, lub inter­fejs wymagany):

Na powyż­szym dia­gra­mie po lewej mamy pro­sty kla­syf­ka­tor poka­zu­ją­cy, że moż­li­we jest żąda­nie Faktury lub Zamówienia na pod­sta­wie typu i nume­ru ID doku­men­tu. Po pra­wej stro­nie (uprosz­cze­nie) zwró­co­na, jako wyni­ka żąda­nia, fak­tu­ra. Jeżeli nasz pro­jekt zawie­ra deta­licz­ną spe­cy­fi­ka­cję fak­tu­ry jako agre­ga­tu, odpo­wie­dzią był­by ten wła­śnie agre­gat, np. agre­gat w posta­ci XML zna­ny z doku­men­ta­cji JPK lub fak­tu­ry ustruk­tu­ry­zo­wa­nej (patrz tak­że: Dokument jako wyma­ga­nie).

Bardzo waż­na uwa­ga prak­tycz­na: pro­jek­to­wa­nie inte­gra­cji, jako wymia­ny danych, nale­ży reali­zo­wać w opar­ciu o kom­plet­ne doku­men­ty (zesta­wy danych): na API żąda­my ​„Faktury VAT” i po jej otrzy­ma­niu ​„u sie­bie” wycią­ga­my z niej np. ​„Wartość brut­to”. Nie two­rzy­my (nie żąda­my od ser­we­ra) API i usłu­gi ​„Podaj war­tość brut­to Faktury VAT()” bo to: dra­stycz­nie uza­leż­nia od sie­bie komu­ni­ku­ją­ce się apli­ka­cje, ogrom­nie pod­no­si kosz­ty imple­men­ta­cji i testo­wa­nia, wyma­ga powta­rza­nia całej tej pra­cy po każ­dej zmia­nie lub aktu­ali­za­cij ser­we­ra, wyma­ga dedy­ko­wa­nych ope­ra­cji dla każ­dej zin­te­gro­wa­nej apli­ka­cji u kon­tra­hen­ta .

Integracja, szcze­gól­nie apli­ka­cji pocho­dzą­cych od róż­nych pro­du­cen­tów, bar­dzo czę­sto wyma­ga mapo­wa­nia danych (tłu­ma­cze­nie). Wtedy naj­efek­tyw­niej­sze jest budo­wa­nie adap­te­rów inte­gra­cyj­nych, co chro­ni nas przez bar­dzo kosz­tow­nym mody­fi­ko­wa­niem (kasto­mi­za­cji) sys­te­mów integrowanych:

W mniej­szych wdro­że­niach budu­je­my je jako pro­ste dedy­ko­wa­ne apli­ka­cje, więk­sze wdro­że­nia mogą wyma­gać szy­ny inte­gra­cyj­nej (ang. ESB, Enterprise Service Bus)

Modelowanie interakcji

Powyższe sta­tycz­ne mode­le archi­tek­tu­ry poka­zu­je­my tak­że z per­spek­ty­wy inte­rak­cji użyt­kow­ni­ka z sys­te­mem, mię­dzy sys­te­ma­mi i mię­dzy kom­po­nen­ta­mi systemu. 

Podsumowanie

Tak więc pogo­dze­nie się z inte­gra­cją jako wyma­ga­niem jest nie­unik­nio­ne. Podobnie jak pogo­dze­nie się z tym, że cza­sy jed­nej cen­tral­nej apli­ka­cji w fir­mie i cen­tral­nej bazy danych, też ode­szły do lamu­sa. Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie on współ­pra­cu­ją, wymie­nia­ją dane. To dla­te­go inte­gra­cja sta­ła się jed­nym z obli­ga­to­ryj­nych wyma­gań każ­de­go sys­te­mu informatycznego. 

A po co ta doku­men­ta­cja? Pełni iden­tycz­ną rolę jak dobrze zapla­no­wa­na tra­sa podró­ży: wszyst­ko to co moż­na spraw­dzić na mapie przed podró­żą pozwo­li unik­nąć kosz­tow­nych nie­spo­dzia­nek w jej trak­cie. To zna­czy tak­że, że moż­na prze­ka­zać to jako wymaganie.

Poniżej pre­zen­ta­cja poka­zu­ją­ca zale­ty podej­ścia Design First, czy­li naj­pierw pro­jek­tu­je­my inte­gra­cje a potem dopie­ro pisze­my kod i implementację. 

Dwa słowa porównania: monolit vs. pakiet aplikacji dziedzinowych

Wiele razy sły­sza­łem o wadach sys­te­mów ​„poin­te­gro­wa­nych”… No to porównajmy: 

I uwa­ga: żaden mono­li­tycz­ny sys­tem ERP i tak nie obej­mie cało­ści przed­się­bior­stwa, elek­tro­nicz­na wymia­na danych z kon­tra­hen­ta­mi i insty­tu­cja­mi pań­stwo­wy­mi jest obec­nie wyma­ga­na, więc inte­gra­cja jest i tak nieunikniona.

Robot i Saga czyli jak integrować

Załóżmy, że mamy sytu­ację jak poniżej:

Szkic poka­zu­je hipo­te­tycz­ne pięć apli­ka­cji i wymia­nę danych (linie) mię­dzy nimi oraz z oto­cze­niem (wszyst­kie orga­ni­za­cje teraz wymie­nia­ją dane z oto­cze­niem, w tym z Urzędem Skarbowym). 

Standardowe apli­ka­cje ofe­ru­ją API jako Interfejs Oferowany (lista usług, któ­re moż­na wywo­łać), czy­li moż­na od nich cze­goś żądać. Problem w tym, że ktoś musi to żąda­nie wysłać. Czy żąda­nie może wysłać sama z sie­bie inna apli­ka­cja? Owszem, pod warun­kiem że ma taką moż­li­wość (a ma rzad­ko), lub że doda­my jej (kasto­mi­za­cja) taką moż­li­wość. Robi się to na pozio­mie kodu (kasto­mi­za­cja) lub na pozio­mie bazy danych (tak zwa­ne try­ge­ry). W efek­cie powsta­je, poka­za­na poni­żej, struk­tu­ra wza­jem­nych wywo­łań, któ­rych nic nie koor­dy­nu­je (każ­da apli­ka­cja sama, w sobie zna­nym momen­cie, ini­cju­je żąda­nie wobec innej). 

Efekt jaki powsta­je to: tak zwa­ny hazard, pole­ga­ją­cy na tym, że nic nie panu­je nad kolej­no­ścią tych wywo­łań. Taki hazard powo­du­je błę­dy lub zawie­sze­nia się komu­ni­ka­cji. Próby wal­ki z nim pole­ga­ją na sztucz­nym wsta­wia­niu cza­su ocze­ki­wa­nia, lub wymu­sza­niu okre­ślo­ne­go ter­mi­nu wywo­ła­nia. Koszty inte­gra­cji to koszt tych prac kasto­mi­za­cyj­nych razy licz­ba apli­ka­cji wyma­ga­ją­cych tej kasto­mi­za­cji, całość jest czu­ła na każ­dą zmia­nę takiej sie­ci bo np. mody­fi­ka­cja lub wymia­na jed­nej z apli­ka­cji, poten­cjal­nie wyma­ga reor­ga­ni­za­cji całej komu­ni­ka­cji. To tyl­ko część pro­ble­mów, gdyż bar­dzo czę­sto inte­gra­cje nadal są reali­zo­wa­ne meto­dą bez­po­śred­nie­go dostę­pu do danych (i wte­dy fak­tycz­nie są bar­dzo kosz­tow­ne) jak poka­za­no poniżej:

Szkodliwość podej­ścia poka­za­ne­go powy­żej jest podwój­na: pomi­ja­my logi­kę biz­ne­so­wą w opro­gra­mo­wa­niu Aplikacja2, kasto­mi­zu­je­my opro­gra­mo­wa­nie Aplikacja1. Kastomizacja to duży dodat­ko­wy koszt, ryzy­ko desta­bi­li­za­cji obu apli­ka­cji (bar­dzo czę­sto się to zda­rza) i bar­dzo czę­sto powta­rza­nie tych prac jest koniecz­ne po każ­dym upgra­de (wię­cej w arty­ku­le Wymagania poza­funk­cjo­nal­ne ? inte­gra­cja). Taka inte­gra­cja i jej wady są czę­sto uży­wa­nym argu­men­tem dostaw­ców mono­li­tycz­nych sys­te­mów ERP, jed­nak teza, że inte­gra­cja pole­ga na współ­dzie­le­niu danych to wła­śnie dema­go­gia tych dostawców. 

Popatrzmy teraz na poniż­szy szkic:

Korzyści: nie musi­my kasto­mi­zo­wać apli­ka­cji bo np. ESB ma wbu­do­wa­ny mecha­nizm pro­jek­to­wa­nia wywo­łań API, ESB izo­lu­je od sie­bie ser­we­ry apli­ka­cji: są one her­me­ty­zo­wa­ne za pomo­cą adap­te­rów (budu­je­my je np. uży­wa­ją ESB lub jako samo­dziel­ne ele­men­ty apli­ka­cji), więc zmia­na kon­fi­gu­ra­cji apli­ka­cji, lub jej wymia­na na inną, wyma­ga jedy­nie inge­ren­cji w jej adap­ter. Zastępujemy cał­ko­wi­cie indy­wi­du­al­ne inte­gra­cje z apli­ka­cja­mi kon­tra­hen­tów jed­nym cen­tral­nym węzłem inte­gra­cji (to tak­że for­ma her­me­ty­za­cji lokal­nej sie­ci). W efek­cie poszcze­gól­ne apli­ka­cje nie wyma­ga­ją żad­nych prac kasto­mi­za­cyj­nych, nie docho­dzi do opi­sa­nych desta­bi­li­za­cji i hazar­du, każ­da wymia­na danych jest bez­piecz­ną trans­ak­cją kon­tro­lo­wa­ną przez ESB zgod­nie z wzor­cem Saga . Poniżej przy­kład z uży­ciem ESB i wzor­ca Saga: 

Wyżej opi­sa­ne podej­ście ma tak­że dodat­ko­wą ogrom­ną zale­tę: dostaw­cy poszcze­gól­nych apli­ka­cji nie muszą ze sobą nicze­go uzgad­niać ani nego­cjo­wać, co bywa dłu­gie i bar­dzo kosz­tow­ne. Mogą być wybie­ra­ni nie­za­leż­nie od sie­bie, w róż­nym cza­sie, i nie zakłó­ca­ją wza­jem­nie swo­imi pra­ca­mi wdro­że­nio­wy­mi zacho­wa­nia innych apli­ka­cji. To efekt sepa­ra­cji apli­ka­cji: żad­na nie współ­dzie­li danych bez­po­śred­nio z inną, ma miej­sce tyl­ko wymia­na danych na pozio­mie logi­ki tych aplikacji. 

Czy to nie­bez­piecz­ne? Co będzie gdy uszko­dzi się ser­wer ESB? Obecnie zabez­pie­cze­nie jego dostęp­no­ści jest znacz­nie tań­sze (redun­dan­cja) niż budo­wa­nie i utrzy­ma­nie wie­lu łączy inte­gra­cji ​„każ­dy z każ­dym”. Warto też zwró­cić uwa­gę na to, że może to być (ESB) usłu­ga chmu­ro­wa, więc jej wyso­ka jakość i dostęp­ność będzie czę­sto tań­sza niż wła­sny zasób. 

Jak Budujemy logi­kę inte­gra­cji? To opi­sa­łem w arty­ku­le Wzorce pro­jek­to­we… inte­gra­cje reali­zu­je­my na bazie wzor­ca SAGA , czy­li budu­je­my skryp­ty reali­zu­ją­ce wywo­ła­nia (pobra­nie i wysła­nie danych) w usta­lo­nej kolej­no­ści i w usta­lo­nym czasie. 

A Roboty? Słynne i mod­ne ostat­nio Roboty to wła­śnie te skryp­ty reali­zu­ją­ce sce­na­riu­sze inte­gra­cji na szy­nie ESB, zna­ne od kil­ku dekad .

Nieco więcej o wzorcach integracji

Polecam tak­że stro­nę auto­ra: https://​www​.enter​pri​se​in​te​gra​tion​pat​terns​.com/​i​n​d​e​x​.​h​tml

Źródła