Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

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 roz­wią­zań. (22.04.2022 dopi­sa­łem Dodatek).

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ę jed­nym z obli­ga­to­ryj­nych wyma­gań każ­de­go sys­te­mu informatycznego. 

Pogodzenie się z tym, że świat już nigdy nie będzie tak pro­sty jak 40 lat temu jest nie­unik­nio­ne. Podobnie jak pogo­dze­nie się z tym, że cza­sy jed­nej cen­tral­nej apli­ka­cji też ode­szły do lamu­sa. Praktyka zaś poka­zu­je, że 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 jest utopią. 

Dane i ich kontekst czyli informacje

Po pierw­sze dane mają róż­ne kon­tek­sty, ich zna­cze­nie zale­ży od 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, jed­nak ta sama data jako war­tość, w reje­strze będą­cym kalen­da­rzem musi być unikalna. 

Powyższe to struk­tu­ra doku­men­tu, jak widać zna­cze­nie danych nadaj kon­tekst ich uży­cia (doku­ment, jego sek­cja). Takiej struk­tu­ry, natu­ral­nej z per­spek­ty­wy 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 niej 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. 

Powyższy doku­ment, bez żad­ne­go pro­ble­mu: bez utra­ty kon­tak­tu i bez mno­że­nia typów dat, zapi­sze­my 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 rze­czy infor­ma­cji po pro­stu nie da się tak prze­twa­rzać. To dla­te­go nie jest moż­li­we zbu­do­wa­nie jed­ne­go uni­wer­sal­ne­go sys­te­mu ERP z cen­tral­ną rela­cyj­ną bazą danych, ale moż­li­we jest łatwe zin­te­gro­wa­nie kil­ku spe­cja­li­zo­wa­nych dzie­dzi­no­wych sys­te­mów. Problem ten opi­sał i wyja­śnił w 2014 roku M.Fowler:

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 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 (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 kosz­tó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 gra­ni­ca mię­dzy ERP (pro­ce­sy wspie­ra­ją­ce) a apli­ka­cja­mi dzie­dzi­no­wy­mi (WMS, MES, APS, WorkFlow, e‑Commerce i wie­le innych). 

Głównym powo­dem tego podzia­łu, i tego że linia podzia­łu jest wła­śnie tu gdzie jest, 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 prze­kwa­li­fi­ko­wa­nia. 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ń, spe­cy­ficz­nych dla danej bran­ży. Nie przy­pad­kiem nazy­wa­my te apli­ka­cje ​„sys­te­ma­mi branżowymi”. 

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 – poza nim – zestaw dedy­ko­wa­nych, bran­żo­wych apli­ka­cji, inte­gro­wa­nych z tym ERP.

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 apli­ka­cyj­ne i ich powią­za­nia), doku­men­ty 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 agre­ga­ty repre­zen­tu­ją­ce doku­men­ty (imple­men­to­wa­ne jako JSON lub XML). Taka postać 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­fiak­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 ustal­ne­go w toku wdrożenia). 

Co to jest REST API?

Przenoszenie Stanów Reprezentacji (ang. Representational sta­te trans­fer: REST) jest meto­dą komu­ni­ka­cji, któ­ra defi­niu­je zestaw ogra­ni­czeń (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 usłu­ga­mi sie­cio­wy­mi RESTful (RWS), zapew­nia­ją inte­ro­pe­ra­cyj­ność mię­dzy sys­te­ma­mi kom­pu­te­ro­wy­mi w Internecie. Usługi RESTful Web Services umoż­li­wia­ją sys­te­mom 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 podej­ściem do pro­jek­to­wa­nia sys­te­mów, a klu­czo­wą zasa­dą jest tu tak­że her­me­ty­za­cja i pro­jek­to­wa­nie zorien­to­wa­ne na 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­wych ope­ra­cji, sys­te­my RESTful 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 ogra­ni­czeń (to jego głów­ne cechy) archi­tek­to­nicz­nych, któ­re spra­wia­ją, że każ­da usłu­ga sie­cio­wa jest praw­dzi­wie RESTful API.

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: 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 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 ser­we­ra. 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, pozwa­la­jąc w ten spo­sób na ist­nie­nie w sie­ci Internet, lub w sie­ci lokal­nej orga­ni­za­cji, 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).

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. Usługobiorca zaczy­na wysy­łać żąda­nia, gdy jest goto­wy do przej­ścia do nowe­go sta­nu. Gdy jed­no lub wię­cej żądań jest nie­roz­strzy­gnię­tych, usłu­go­bior­ca jest uwa­ża­ny za znaj­du­ją­ce­go się w sta­nie przej­ścio­wym. 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 nowe­go stanu. 

Kluczową cechą tej archi­tek­tu­ry jest tak­że to, że usłu­go­daw­ca nigdy sam nie wywo­łu­je usługobiorcy!

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, 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. Dodanie war­stwy bez­pie­czeń­stwa jako oddziel­nej war­stwy wymu­sza­ją np. wdra­ża­ne 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 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ługobiorcy.

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 (patrz wzo­rzec archi­tek­to­nicz­ny Repozytorium). 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 Internet?

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 z użyciem UML w 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­ja­cy tak­że, w razie takiej potrze­by, na wyge­ne­ro­wa­nie szkie­le­tu kodu i jego doku­men­ta­cji. 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. Z per­spk­ty­wy UML jest to, zna­ny z Diagramu Struktur Złożonych (Composit Structure Diagram), komponent/klasyfikator z por­ta­mi WE i WY.

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:

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 .

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.

Dodatek czyli co to jest Robot i Saga?

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­ny 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 jak poka­za­no poniżej:

Szkodliwość podej­ścia poka­za­ne­go powy­żej jest podwój­na: pomi­ja­my logi­kę zarzą­dza­nia dany­mi 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).

Popatrzmy teraz na poniż­szy szkic:

Korzyści: nie musi­my kasto­mi­zo­wać apli­ka­cji bo 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 na ESB), 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 na ESB. 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 wymie­nia danych bez­po­śred­nio z inną. 

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 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 .

Źródła

Inne artykuły na podobny temat

• Wymagania poza­funk­cjo­nal­ne – integracja
• Opis Przedmiotu Zamówienia – instruk­cja nie tyl­ko dla prawników
• CHMURY – od roz­bu­do­wa­nych roz­wią­zań auto­no­micz­nych do struk­tur zło­żo­nych z róż­ne­go rodza­ju roz­pro­szo­nych usług
• RE: Duży mono­li­tycz­ny ERP czy integracja
• Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i rekomendacje