Interfejs prelazi više od mrežne granice
Unutar jednog tima nedostajući kontekst može se neformalno dopuniti. Programer pita vlasnika procesa, operater prepozna izuzetak ili je konvencija baze svima poznata. Preko granica organizacija te prečice nestaju. Svaka strana ima sopstveni rečnik, ciklus izdanja, ovlašćenja, kontrole i tumačenje uspeha.
API ili specifikacija datoteke mogu biti tehnički ispravni dok poslovna interakcija ostaje dvosmislena. Odgovor „prihvaćeno“ može značiti da je poruka strukturno primljena, stavljena na pregled, poslovno odobrena ili potpuno obrađena. Ako značenje nije ugovoreno, oba sistema mogu raditi tačno kako su izgrađena, a ipak proizvesti sporan ishod.
Projektujte pet slojeva integracionog ugovora
Potpun integracioni ugovor obuhvata interakciju, semantiku, ponašanje, operativni rad i promenu. Interakcija definiše ko pokreće razmenu, kojim redosledom se odvija i gde prelazi odgovornost. Semantika definiše poslovne entitete, polja, jedinice i stanja. Ponašanje definiše validaciju, odgovore, greške, ponovne pokušaje i idempotentnost. Operativni sloj definiše vidljivost, podršku, usaglašavanje i oporavak. Promena definiše kompatibilnost, verzionisanje, najavu i povlačenje.
Nije svakom interfejsu potreban dugačak formalni dokument. Dubina treba da prati posledice i udaljenost između organizacija. Važno je da svaki sloj bude svesna odluka. OpenAPI opis, šema događaja ili raspored datoteke mogu nositi delove ugovora, ali nijedan sam ne uspostavlja odgovornost i operativno značenje.
Čuvajte identitet i korelaciju nezavisno od transporta
Transakcija može dobiti lokalne ključeve baze, identifikatore poruka i oznake paketa dok prolazi kroz sisteme. I dalje mora postojati stabilan način da se utvrdi da li se dva zapisa odnose na isti poslovni događaj. Korelacija treba da bude izričita, trajna i dostupna timovima podrške, a ne skrivena u internim zapisima integracione komponente.
Dizajn identiteta određuje i ponašanje pri duplikatima. Ako pošiljalac ponovi zahtev posle neizvesnog isteka vremena, primalac mora da prepozna predstavlja li zahtev isti nameravani efekat. Ključ idempotentnosti koristan je samo kada su njegov opseg, trajanje i poslovno značenje dogovoreni; u suprotnom samo premešta dvosmislenost u novo polje.
Status je poslovno obećanje, a ne oznaka na ekranu
Svako spolja vidljivo stanje treba da ima jedno značenje, merodavnog vlasnika, dozvoljene prelaze i očekivanu sledeću radnju. „Primljeno“, „potvrđeno“, „prihvaćeno“, „u obradi“, „završeno“ i „odbijeno“ nisu zamenljivi pojmovi. Kada je interno stanje detaljnije, mapiranje na partnerski ugovor mora biti svesno i dovoljno povratno da podrška može da ga prati.
Koristan statusni odgovor prenosi korelaciju, vreme, stanje, razlog i odgovornost. Razlikuje konačno odbijanje od privremenog uslova i pokazuje da li je ponovni pokušaj dozvoljen. Bez toga pošiljaoci stvaraju sopstvene pretpostavke, a skriveni ručni postupci podrške postaju deo integracije.
Projektujte otkaze i oporavak pre nego što završite idealan tok
Delimičan otkaz je uobičajen kada nezavisni sistemi komuniciraju. Primalac može završiti rad dok se odgovor izgubi. Nizvodni korak može otkazati posle uzvodne potvrde. Paket može sadržati ispravne i neispravne stavke. Za važne slučajeve ugovor mora objasniti nedeljivost, ponovne pokušaje, redosled, reprodukciju, kompenzaciju i usaglašavanje.
Oporavak je istovremeno tehnički i organizacioni. Neko mora biti ovlašćen da ponovo izvrši obradu ili ispravi podatke; pogođenim stranama trebaju dokazi; podrška mora znati kada je automatsko ponavljanje stalo; poslovanje mora imati put za ishode koji se ne mogu poništiti. Te odgovornosti treba proveriti u scenarijima prihvatanja.
Učinite uvođenje partnera proizvodom arhitekture
Ako svaki novi partner zahteva privatno znanje pojedinaca, organizacija još nema razvijenu integracionu sposobnost. Ponovljiv obrazac uvođenja obuhvata poslovnu interakciju, primere ugovora, testove usaglašenosti, pravila za testne podatke, postupak izdavanja pristupnih podataka, put kroz okruženja, operativne kontakte, kriterijume spremnosti i politiku verzija.
Standardizacija treba da se usredsredi na stabilne delove uz opravdane varijacije. Prisiljavanje svakog partnera u jedan fizički format može stvoriti krhka mapiranja na granici. Kanonski semantički model ili ugovoreni rečnik vredni su kada smanjuju dvosmislenost, a ne kada postanu još jedan centralni model bez vlasnika.
Upravljajte granicama kroz dokaze
Upravljanje preko organizacionih granica treba da bude vidljivo u operativnim artefaktima: imenovanim vlasnicima, zapisima verzija, očekivanjima usluge, kategorijama grešaka, dokazima prihvatanja i, gde je potrebno, zajedničkom kalendaru promena. Sastanci bez ugovornih dokaza ne mogu nadoknaditi nedefinisano ponašanje.
Počnite malim korakom: izaberite jednu važnu transakciju i pratite je od poslovne namere kroz obe organizacije, uključujući neizvestan odgovor i promenu pravila. Praznine pronađene u tom prolazu često objašnjavaju više od širokog popisa integracionih tehnologija.