Virheenhallinta integraatioissa: kurkistus matopurkkiin

Jesse Ryhänen

Virheiden käsittely integraatioalustassa nousee usein esiin keskusteluissa sekä kehittäjien että asiakkaiden kanssa. Monelle tulee yllätyksenä, kuinka monimutkainen asia on kyseessä. Tässä tekstissä pyrinkin hiukan raottamaan virheenhallinnan matopurkin kantta ja valaista miksi se on haastavaa. Vaikea aihe on kuitenkin samalla myös tärkeä aihe, johon ei pitäisi suhtautua sivuseikkana.

Tunnista virheen juurisyy

Olennainen ajatus virheenhallinnassa on se, että virhe vaatii reagointia: ei riitä, että virhe vastaanotetaan, vaan sen pitäisi johtaa korjaustoimiin. Jotta virheeseen voidaan reagoida oikein, pitää aivan aluksi tunnistaa virheen juurisyy. Virheenhallinta ylittää siis puhtaan teknisen tason.

Yksinkertaiset tekniset virheet on helppo tunnistaa: jos sanoman vastaanottava järjestelmä vastaa HTTP-kutsuun statuksella 401 Unauthorized tai 503 Service Unavailable, voidaan päätellä, että tunnuksissa on jotain vikaa tai että järjestelmä on alhaalla. Mutta entä jos vastauksena tuleekin geneerinen 500 Internal Server Error tai jokin muu yhtä epämääräinen virhe?

Sisältövirheet ovat teknisiä virheitä huomattavasti vaikeampia ja monisyisempiä käsitellä. Näiden kirjo on äärimmäisen laaja, aina vääränmuotoisesta sanomasta puuttuviin kenttiin, vääriin formaatteihin (väärä päivämäärämuoto tai desimaalierotin) ja muihin kenttävirheisiin. Klassinen esimerkki on se, että vastaanottava järjestelmä odottaa arvoa joltain listalta, esim. verokoodia, mutta lähdejärjestelmän sanomassa on jokin aivan muu arvo.

Erityisen kinkkinen selvitettävä on virhe, joka johtuu monimutkaisista loogisista tarkistuksista muissa objekteissa, esim. että kaikki viittaukset muihin objekteihin ovat valideja, tai että eri objektien voimassaolopäivämäärät eivät limity väärin – sisältö voi olla täysin oikeanmuotoista, muttei silti läpäise tarkastusta.

Eivätkä ne teknisetkään virheet aina niin suoraviivaisia ole. 401 Unauthorized voi olla vaikea selvittää, jos tunnukset ovat oikein ja luvitus vaikuttaisi olevan oikein kohdejärjestelmässä. Ja mitä jos kohdejärjestelmä tasaisin arvaamattomin väliajoin palauttaa 501 Service Unavailablea vaikka sen omissa lokeissa ei ole tietoa virheistä? Entäpä sitten järjestelmät, jotka kertovat virheestä kyllä/ei-tyyppisessä kentässä, joskus täysin ilman selitteitä? Arvaile siinä nyt sitten mitä on tapahtunut.

Ratkaisuja automatiikalla

Edellä kuvatut skenaariot ovat kaikki sellaisia, joita integraatioiden parissa kohtaa. Yhtäkään näistä ei voi käsitellä samalla tavalla, mutta joitain suuntaviivoja voi piirtää. Kaikkein tärkeintä on, että virheisiin reagoidaan, ja ettei niitä haudata alustan syövereihin.

Klassinen lähestyminen virheenhallintaan on virheen lokitus, Azuressa esim. Azure Monitoriin tai Application Insightsiin, ja mahdollisesti sähköpostin lähetys. Näistä etenkin lokien kirjoittaminen on tärkeä perustason ratkaisu, jolla varmistetaan, että virheestä jää jokin jälki. Silti perustoimet yksinään ovat lähes sama asia kuin ei virheenhallintaa ollenkaan. Lokia pitää muistaa käydä katsomassa, ja kyllähän kaikki tietävät, että meili jää aivan liian usein lukematta. Geneerinen ”lokitus ja sähköpostitus” ei siis ole riittävä ratkaisu.

Joitain teknisiä virheitä on mahdollista ratkoa automatiikalla, esim. automatisoitujen uudelleenyritysten avulla, jos virhe johtuu kohdepalvelun hetkellisestä kyykkäyksestä tai ylikuormituksesta. Automaattiset uudelleenyritykset eivät kuitenkaan itsessään ole riittävä ratkaisun taso, vaikka integraatiovirhe korjaantuisikin: mikäli ”räpsymistä” sattuu usein, on se selvä merkki virheestä taustajärjestelmässä tai verkkoyhteydessä. Automatiikka voi siis liiankin tehokkaasti peittää virheen. Siksi onkin fiksua ylläpitää statistiikkaa uudelleenyrityksistä ja virheistä, ja niiden määrän ylittäessä tietyn raja-arvon, nostaa hälytys esimerkiksi tikettijärjestelmään.

Järjestelmäarkkitehtuurin kokonaisuuden kannalta tärkeää ei ole vain se, että data liikkuu, vaan että virheet tunnistetaan – ja korjataan.

Sisältövirheiden kimurantti käsittely

Sisältövirheissä ennaltaehkäisy on tietenkin kaiken A ja O: jo määrittelyvaiheessa pitää sovittaa lähde- ja kohdejärjestelmien data yhteen, ja varmistaa että integraatioalusta siinä välissä pystyy lähettämään paitsi oikeaa sanomamuotoa, myös hyväksyttävää datasisältöä. Arvot järjestelmien välillä muunnetaan mallista toiseen, ja varmistetaan että kohdejärjestelmään syötetään vain sen hyväksymiä arvoja. Näin saadaan datavirheet minimoitua. Muutostenhallintaa on kuitenkin vaikea tehdä täydellisesti, ja näennäisen pieni versiopäivitys saattaa muuttaa sanomasisältöjä. Sisältövirheiltä on siis liki mahdoton välttyä.

Validiteettitarkistusten kohdalla design nousee tärkeään asemaan. Jos tiedon luonti esim. tarkistaa, että jollekin viiteavaimelle löytyy vastaavuus toisessa entiteetissä, pitää jo integraatioiden suunnittelussa ottaa huomioon missä järjestyksessä data pitää siirtää järjestelmien välillä. Tässäkin on lähes mahdoton päästä aukottomasti toimivaan prosessiin. Mitä jos jokin tieto jää siirtymättä esim. teknisen virheen takia?

Jos virheen palauttaminen lähdejärjestelmään on mahdollista niin, että se näytetään selkeästi käyttäjälle, on se yleensä hyvä ratkaisu. Näin on monesti synkronisissa operaatioissa, joissa järjestelmä odottaa vastausta integraatioalustalta. Moni integraatio on kuitenkin asynkroninen, esim. pollaava tai ajastetusti käynnistyvä. Tällöin lähdejärjestelmässä ei ole kesken olevaa operaatiota, joka odottaisi vastausta. Sama koskee ns. eventingiä, jossa lähdejärjestelmä lähettää sanoman muutoksesta, muttei odota vastausta.

Tärkeää sisältövirheissä on tuoda ne käyttäjien tietoon. Integraatiokehittäjä ei ole oikea henkilö, vaan virhe on saatava nimenomaan järjestelmien käyttäjille, jotta he osaavat tehdä tarvittavat korjaustoimenpiteet. Toisaalta on käytännössä aina huono vaihtoehto pakottaa käyttäjät kaivelemaan integraatioiden suorituksia ja lokeja– virhe pitää saada lähelle käyttäjiä.

Taaskaan lokitus ja sähköpostitus ei ole paras lähestyminen. Ideaalitilanteessa virhe pystytään nostamaan jotain kanavaa pitkin lähdejärjestelmään, tai viedä ne esim. monitorointi- tai tikettijärjestelmään, jota käyttäjät muutenkin käyttävät. Olennaista on saada virhe oikean henkilön silmille oikeaan aikaan, ja antaa hänelle kaikki tarvittava tieto virheen selvittämiseen.

Huono virheenkäsittely pahentaa tilannetta

Sisältövirheissä uudelleenyritys on täysin turhaa: ei se data itsestään korjaannu. Siksi catch-all-tyyppinen uudelleenyrityslogiikka ei ole tarkoituksenmukaista. Se voi jopa olla vaarallista.

Kaikkein vaarallisin virheskenaario on sellainen, jossa virheestä huolimatta data on osittain syötetty järjestelmään. Tällöin tiedon uudelleenlähetys, joko automaattinen tai manuaalinen, voi luoda duplikaatteja, esim. kaksi laskua samasta syötteestä – pahimmassa tapauksessa molemmat virheellisiä! Tämänkaltaiset skenaariot voivat aiheuttaa vakavia, vaikeasti selvitettäviä ja korjattavia ongelmia. Ikävä kyllä ei voi edes sanoa, että tämä koskee vain sisältövirheitä: myös teknisten virheiden kohdalla voi osa tiedosta siirtyä.

Etenkin automaattisissa uudelleenlähetyksissä on myös riski ylikuormittaa kohdejärjestelmää. Otettakoon esimerkkinä massa-ajo, jossa jokainen rivi käsitellään erikseen. Jos kaikissa riveissä on virhe, ja integraatiossa on uudelleenyrityslogiikkaa, saatetaan kohdejärjestelmää pommittaa jopa sadoilla tuhansilla kutsuilla lyhyessä ajassa. Lopputuloksena voi olla järjestelmän epävakaus ja kaatuminen – joka tietenkin heijastuu kaikkiin järjestelmiin, jotka kommunikoivat kaatuneen järjestelmän kanssa.

Järjestelmäintegraation kannalta olennaisen tärkeää on se, että tieto järjestelmien välillä pysyy synkronoituna. Jos tapahtuu virhe, on siitä kerrottava selkeästi tavalla, joka tavoittaa oikean käyttäjän oikeassa vaiheessa. Automatiikalla voidaan korjata joitakin virheitä, mutta on pidettävä huoli, ettei se peitä toimenpiteitä vaativia ongelmia. Erityisen tärkeää on varmistaa, ettei automatiikka vaaranna tietojen eheyttä järjestelmien välillä.

iPaaS-alusta palautumisen apuna

Virhetilanteista palautuminen on sekin monimutkainen asia. Ei riitä, että mahdollisesti kaatuneet järjestelmät saadaan takaisin pystyyn ja yhteydet pelaamaan. Myös virheellinen data pitää saada siivottua pois, ja siirtämättä jääneet tiedot ajettua uudestaan, mahdollisesti korjattuna.

Integraatioalustan lokidata nousee arvokkaaksi, kun pitää tunnistaa virheeseen menneet siirrot. Näistä ei usein jää jälkeä kohdejärjestelmään, eikä esim. asynkronisessa tiedonsiirrossa lähdejärjestelmäkään usein tallenna muuta tietoa kuin se, että tieto on lähetetty integroitavaksi. Hyvä alustatason lokitus voi siis pelastaa päivän ja kertoa suoraan mikä tieto jäi siirtymättä.

Joskus virheeseen menneet operaatiot halutaan ajaa uudestaan, kun virhe on korjattu, esim. jos syynä oli jokin konfiguraatio- tai luvitusvirhe kohdejärjestelmässä. Moni järjestelmä ei kuitenkaan tarjoa helppoja tapoja ajaa uudestaan operaatioita. Tässäkin iPaaS-alusta voi olla avuksi.

Mitään yleispätevää toteutusmallia ei ole olemassa, vaan integraatioratkaisut pitää aina räätälöidä lähde- ja kohdejärjestelmän toiminnallisuudet huomioon ottaen. Integraatiot kannattaakin pyrkiä toteuttamaan tavalla, joka sallii tiedon uudelleenlähetyksen myös lähdejärjestelmän ulkopuolelta. Tällöin alusta voi virheiden kohdalla tallentaa sanomasisällöt ja tarjota mekanismit ajaa ne uudelleen, joko sellaisenaan tai manuaalisten korjausten jälkeen.

Entäs ne integraatioalustan omat virheet?

Tyypillinen iPaaS-kerroksessa havaittava virhe tapahtuu ulkoisessa järjestelmässä. Voi turvallisesti yleistää, että yli yhdeksän kertaa kymmenestä virhe tapahtuu muualla kuin alustassa itsessään, vaikka juurisyy olisikin integraatiossa, esimerkiksi virheellisessä mappauksessa. Mutta joskus myös integraatioalusta itse voi ajautua virhetilanteisiin.

Integraatioprosessin suoritusvirheen voi yleensä saada kiinni järkevällä suunnittelulla. Toteutus voidaan tehdä siten, että orkestrointivirheet saadaan lokille ja valvontaan esim. virheenkäsittelylohkojen järkevän käytön avulla. Myös itse alusta tarjoaa usein työkaluja, joilla voidaan havaita epäonnistuneita suorituksia ja kirjata ne lokiin. Tämä sisäänrakennettu lokitus on usein kuitenkin luonteeltaan melko teknistä ja geneeristä, eikä esim. tallenna sisältövirheitä tai kohdejärjestelmän sanomasisältöjä, joten se ei korvaa räätälöityä ja sisällön ymmärtävää virhelokitusta.

iPaaS:in sisäisessä valvonnassa loki on tärkeä mutta ei riittävä työkalu. Yhtä tärkeää on rakentaa järkeviä näkymiä ja hälytyksiä lokeihin kertyvän datan päälle. Jokaisesta virheestä ei välttämättä tarvitse lähettää viestiä, mutta on varmistettava, että tieto virheistä nousee esim. hälytysten kautta integraatiokehittäjien tietoon.

Moderni integraatioarkkitehtuuri on usein kerrostettu, jolloin tieto liikkuu monen kerroksen ja komponentin kautta. Integraation virheenselvityksessä on olennaisen tärkeää, että lokiin tallennetusta datasta voi helposti seurata koko integraatioputkea. Tärkeä työkalu tähän on jonkin sortin korrelaatio-ID, joka pysyy suoritukselle samana kaikissa kerroksissa. Tämän avulla pystytään luomaan näkymiä, joissa näkyvät kaikki tiedonsiirtoputken vaiheet.

Harvinainen, muttei ennenkuulumaton skenaario on se, että koko alusta on alhaalla. Tätä iPaaS-alusta itsessään ei voi raportoida. Siihen voi kuitenkin varautua ottamalla käyttöön esim. toisessa pilvessä olevan valvontatyökalun, joka pingailee säännöllisesti alustan valikoituja yhteyspisteitä. Tämä ei toki estä kaatumista, mutta sen avulla saa tiedon tapahtuneesta nopeasti.

Virheenhallinnan miettiminen kannattaa

Vaikka virheenhallinta on haastavaa, ei sitä kannata jättää tekemättä. Mikäli virhe voidaan käsitellä automatiikalla luotettavasti, kannattaa se yleensä tehdä. Silloin kun automatiikka tarjoaa luotettavan ratkaisun, ei ihmisiä kannata turhaan kuormittaa ylimääräisellä manuaalityöllä. Automatiikka ei kuitenkaan saa häivyttää tapahtuneita virheitä.

Se, miten virheitä voi ja kannattaa käsitellä riippuu lähde- ja kohdejärjestelmistä. Eri järjestelmillä on hyvinkin eritasoisia valmiuksia käsitellä ja palautua virhetilanteista. Olennaista onkin ymmärtää miten järjestelmät kertovat virheistään, ja millaisia virheitä niissä ylipäätään syntyy. Tällöin on helpompi toteuttaa virheenhallintaa integraatioalustassa.

Virheenhallinnassa on pidettävä odotukset ja tavoitteet realistisina. Osa teknisistä virheistä voidaan käsitellä automatiikan ja uudelleenyritysten avulla, mutta etenkin sisältövirheissä ainoa ratkaisu on usein korjata data lähtöpäässä ja lähettää uudelleen. Ei siis pidä odottaa, että iPaaS-automatiikka tarjoaisi helppoja patenttiratkaisuja.

Tärkeintä integraatioiden virheenhallinnassa on varmistaa, etteivät virheet jää huomaamatta. Alustatason ratkaisuna tämä tarkoittaa usein sitä, että rakennetaan yhteys organisaation tiketöintijärjestelmään. Voidaan myös pyrkiä toimittamaan virheet suoraan lähdejärjestelmiin, joissa käyttäjät generoivat integraation yli liikkuvaa dataa. Tärkeintä on, ettei tieto huku. Virheiden edelleenvälittämisen ohella myös tilastollinen tarkastelu voi olla hyvä työkalu virheiden selvittämisessä; tässäkin laadukas loki nousee arvoonsa.

Hyvällä suunnittelulla voidaan etenkin sisältövirheitä ennaltaehkäistä. Monimutkaisessa ympäristössä virheitä silti tapahtuu. iPaaS-alustan virheenhallinnan perimmäinen tavoite on selkeästi raportoida ja informoida tapahtuneista virheistä, ja edesauttaa niiden korjaamista. Virheenhallinnan realistinen tavoite ei ole virheiden täydellinen eliminoiminen, vaan luoda tehokkaita prosesseja niiden ratkaisuun. Tässä alustatason tekninen prosessi on vain yksi työkalu, ei kokonaisvaltainen ratkaisu itsessään.

Kuvat: Devisioona & Unsplash