Sistemų sujungimas
API ir sistemų integracijos
Integracija atrodo kaip techninis darbas, bet beveik visos problemos yra susitarimo problemos. Kai dvi sistemos turi tą patį įrašą, kažkuri turi būti teisi – ir jei tai neužrašyta, sprendimas kasdien priimamas atsitiktinai. Todėl darbas pradedamas ne nuo prisijungimo prie sąsajos, o nuo klausimo, kuri sistema yra tiesos šaltinis kiekvienam duomenų laukui ir kas nutinka, kai jos nesutampa.
Aptarti integracijos apimtįTrumpai: ką reikia susitarti
Trys dalykai nulemia, ar integracija bus patikima. Tiesos šaltinis – kuri sistema teisi dėl kiekvieno lauko, o ne apskritai. Nesutapimo taisyklė – kas nutinka, kai duomenys skiriasi: perrašoma, praleidžiama ar pažymima žmogui. Ir savininkas – kas pastebės, kad integracija nustojo veikti, ir kas turi teisę ją keisti. Be trečiojo punkto integracija veikia iki pirmo pakeitimo kitoje sistemoje.
Kada integracija yra tinkamas sprendimas
- Tie patys duomenys šiandien įvedami į dvi sistemas rankomis, todėl klaidos yra ne išimtis, o laiko klausimas.
- Reikia, kad įvykis vienoje sistemoje savaime pradėtų darbą kitoje, be žmogaus tarpininko.
- Sistemos nepakeičiamos, bet jų duomenys turi sutapti – keisti platformą būtų neproporcinga.
- Reikia žinoti, kada perdavimas nepavyko, o ne aiškintis tai iš klientų skambučių.
Kada pakanka paprastesnio sprendimo
- Duomenų nedaug ir jie keičiasi retai – periodinis eksportas ar importas gali būti pigesnis ir suprantamesnis.
- Abi sistemos jau turi paruoštą sujungimą, kuris atitinka poreikį – tada užtenka jį teisingai sukonfigūruoti.
- Procesas dar keičiasi – automatizuoti dar nenusistovėjusią eigą reiškia perrašyti integraciją kartu su ja.
Sutrikimų atvejai ir kaip jie sprendžiami
Integracijos vertė matuojama ne tuo, kaip ji veikia gerą dieną, o tuo, kas nutinka blogą. Žemiau iliustraciniai atvejai, kuriuos aprašome prieš darbą, kad jie nebūtų sprendžiami improvizuojant. Tai ne kainų lentelė ir ne pažadas dėl konkretaus rezultato.
| Sutrikimo atvejis | Ką tai reiškia praktiškai | Kaip sprendžiama |
|---|---|---|
| Įrašų dubliavimas | Tas pats klientas ar užsakymas atsiranda du kartus, dažniausiai po pakartoto perdavimo. | Kiekvienas perdavimas gauna savo tapatumo ženklą, todėl pakartojimas atpažįstamas ir nesukuria naujo įrašo. |
| Duomenų nesutapimas | Abi sistemos turi tą patį įrašą su skirtinga reikšme ir nei viena nėra akivaizdžiai teisi. | Tiesos šaltinis nustatomas kiekvienam laukui atskirai; likę atvejai pažymimi žmogui, o ne perrašomi tyliai. |
| Išorinė sistema neatsako | Sąsaja neprieinama arba atsako per ilgai, todėl darbas negali būti užbaigtas iš karto. | Perdavimas kartojamas didėjančiais intervalais ir ribotą kartų skaičių; nepavykę atvejai lieka eilėje, ne prarandami. |
| Užklausų ribos | Sistema leidžia tik tam tikrą kiekį užklausų, o esant didesniam krūviui užklausos pradedamos atmesti. | Perdavimas planuojamas paketais ir eiliškumu, kad riba nebūtų pasiekiama piko metu. |
| Pakitusi sąsaja | Kita pusė pakeičia laukus ar taisykles, o integracija apie tai nebuvo informuota. | Netikėta struktūra atmetama su suprantama klaida ir fiksuojama, todėl problema pastebima anksčiau nei duomenys sugenda. |
Kaip vyksta darbas
- 01
Sistemų ir tiesos šaltinio žemėlapis
Surašome, kurios sistemos dalyvauja, kokie įrašai keliauja tarp jų ir kuria kryptimi. Kiekvienam laukui nustatome tiesos šaltinį. Šis žingsnis dažnai atskleidžia, kad integracijos reikia mažiau, nei atrodė – arba kad pirma reikia susitarti dėl proceso.
- 02
Laukų atitikimas ir konfliktų taisyklės
Aprašome, kaip vienos sistemos laukas atitinka kitos, kas nutinka su tuščiomis reikšmėmis ir kaip sprendžiami konfliktai. Taisyklės užrašomos prieš kodą, nes vėliau jos vis tiek bus reikalingos – tik jau ginčo metu.
- 03
Sutrikimų valdymas
Įgyvendinamas pakartotinis perdavimas, pakartojimo atpažinimas ir eilė nepavykusiems atvejams. Tikslas ne išvengti klaidų, o užtikrinti, kad klaida būtų pastebima, atkuriama ir nesukurtų antro įrašo.
- 04
Stebėjimas ir atsakomybės perdavimas
Įjungiamas sutrikimų fiksavimas ir aprašoma, ką reiškia kiekvienas signalas. Kartu užrašoma, kas turi prieigas, kas gali keisti integraciją ir ką daryti, kai kita pusė paskelbia sąsajos pakeitimą.
Kas lemia kainą ir trukmę
- Sistemų skaičius ir kryptys – dvipusis perdavimas reikalauja konfliktų taisyklių, vienpusis dažniausiai ne.
- Kitos pusės sąsajos kokybė ir dokumentacija; jos nebuvimas didžiąją laiko dalį paverčia tyrimu.
- Ar reikia perkelti istorinius duomenis, ir kokia jų kokybė.
- Reikalaujamas šviežumas: kartą per dieną, kas kelias minutes ar iš karto – tai keičia visą sprendimą.
- Ar prieigas ir aplinkas galima gauti be ilgo derinimo su trečiąja puse.
Ką verta apsvarstyti prieš pokalbį
- 01Kurios sistemos turi būti sujungtos ir kuri iš jų yra teisi, kai duomenys skiriasi?
- 02Kaip greitai duomenys turi atsirasti kitoje sistemoje?
- 03Kas šiandien pastebi, kad perdavimas nepavyko?
- 04Ar reikia perkelti istorinius duomenis, ar pakanka naujų?
- 05Kas turės prieigas ir teisę keisti integraciją po perdavimo?
Aptarkime integracijos apimtį
Pakanka parašyti, kurias sistemas norite sujungti ir kokie duomenys tarp jų turi keliauti. Nesiųskite prieigos raktų ar tikrų klientų duomenų – bendras aprašymas yra tinkamas pradinis taškas.