Mistä Drupal-integraatioissa on kysymys?
Olemme integroineet vuosien varrella Drupalin melkoiseen määrään erilaisia järjestelmiä. Saimme aikaiseksi omalle sivustollemme jopa infopaketin Drupal-integraatioista. Joskus integraatioiden tehtävänä on tuottaa lisäarvoa asiakkaillemme ja heidän sivustojensa käyttäjille jollain pienellä ja selkeästi rajatulla osa-alueella. Joissakin tapauksissa taas integraatiot pureutuvat asiakkaidemme bisneksen ytimeen ja ohjaavat suurta osaa heidän liiketoiminnastaan.
Mistä integraatioissa on kysymys?
Integraatioiden tarkoituksena on siirtää tietoa kahden järjestelmän välillä. Tiedonsiirto voi olla täysin yksisuuntaista tai sitä voi tapahtua molempiin suuntiin. Useimmiten integraatioissa tiedonsiirto tapahtuu HTTP-protokollan välityksellä, mutta mitään estettä ei ole käyttää tiedonsiirtoon esim. SSH:ta tai mitä tahansa muuta protokollaa. Toisinaan kevyen integraation ja toisesta palvelusta upotetun sisällön raja on sumea, mutta pääsääntöisesti webbisivuilla integroiduksi sisällöksi voidaan luonnehtia sellaista, joka kulkee sivustolle toteutetun esitysputken läpi. Sillä ei ole merkitystä, tapahtuuko varsinainen tiedonsiirto asiakaspäässä vai palvelimella.
Integraatioista puhuttaessa päärooliin nousevat seuraavat asiat:
- Siirrettävän tiedon luonne ja päivitystiheys
- Tiedonsiirtoprotokolla
- Autentikaatio ja verkkoinfrastruktuuri
- Tiedonsiirtoformaatti
Usein integraatiotarpeet ovat yksilöllisiä, joten suuri osa etenkin syvemmistä integraatioista rakennetaan räätälöityinä. Drupal tarjoaa kuitenkin erittäin hyvät lähtökohdat juuri tällaisten toteutusten rakentamiseen, sillä suuri osa tarvittavista palikoista on jo olemassa – kehitysvaiheessa palikat pitää vain saada liimattua oikealla tavalla kasaan.
Tietotekniikka on sikäli hieno ala, että lähes mikä tahansa on mahdollista.
Mitä tietoa tarvitaan ja kuinka usein?
Yksi integraatioiden peruskysymyksiä on se, mitä tietoa järjestelmästä toiseen pitää saada välitettyä ja kuinka usein. Tämä määrittelee sen, miltä pohjalta integraatiota lähdetään suunnittelemaan. Jos toisesta järjestelmästä tulevaa tietoa on tarve näyttää lähes reaaliaikaisesti, tulee järjestelmän tarjota integraatiokäyttöön jokin ohjelmointirajapinta, jonka kautta tietoa voidaan kysellä tarpeen mukaan. Jos taas data päivittyy harvemmin, voidaan tiedot siirtää ajoittain automaattisesti ajettavina massapäivityksinä.
Integroitavan palvelun ohjelmointirajapinnan käyttäminen on lähes aina järkevämpi lähestymistapa, sillä se tarjoaa useita etuja verrattuna massapäivitysmetodiin:
- Tieto päivittyy vain vähän kerrallaan, joten useita välimuistikerroksia voidaan hyödyntää tehokkaasti 100% ajasta. Massapäivityksessä joudutaan usein invalidoimaan suuri osa välimuistissa olevista tiedoista kerralla, jolloin päivityksen jälkeen välimuistit ovat hetken aikaa ”kylmänä”.
- Epäonnistuneet päivitykset eivät aiheuta ongelmia datan eheyden tai käsittelyn suhteen, koska vanhaa dataa voidaan käyttää siihen asti, kunnes päivitys taas onnistuu. Päivitystahti on yleensä sen verran nopea, että tästä ei normaalisti aiheudu ongelmia. Massapäivityksessä epäonnistuneet päivitykset johtavat vanhan datan palauttamiseen ja pitemmän päivitysvälin vuoksi vanhaa dataa joudutaan pahimmassa tapauksessa käyttämään hyvinkin pitkään.
- Tietoa voidaan synkronoida järjestelmien välillä todella paljon nopeammalla tahdilla, joten esimerkiksi virheellisen lähdedatan aiheuttamat ongelmat korjaantuvat nopeasti ilman erityisiä toimenpiteitä.
Massapäivitykselläkin on kuitenkin omat hyvät puolensa ja se saattaa olla myös ainoa tapa siirtää tietoa järjestelmien välillä. Tiedot voidaan siirtää turvallisesti esim. SSH-yhteyden yli ja tietolähteenä toimiva järjestelmä voidaan pitää yksinkertaisempana. Massapäivitys tarjoaa myös oikean datan helposti testikäyttöön, mikä on etenkin kehitysvaiheessa ja ongelmanselvitystilanteissa valtava apu.
Miten tieto liikkuu?
Ohjelmointirajapintoja käytettäessä tieto siirtyy lähes aina jossakin muodossa HTTP-protokollan yli. Nykyään ohjelmointirajapinnat toteutetaan lähes aina joko SOAP– tai REST-rajapintoina. Näistä jälkimmäinen on suunniteltu juurikin HTTP-protokollaa ajatellen, kun taas SOAPissa tietoa voidaan siirtää muidenkin protokollien päällä.
SOAP on ns. RPC-rajapinta, eli sen tarkoituksena on mahdollistaa aliohjelmien kutsuminen ulkopuolelta. Jotta tämä olisi mahdollista, pitää rajapinnan tarjoavan järjestelmän pystyä kuvailemaan kutsuttavat aliohjelmat rajapintaa käyttäville asiakassovelluksille. SOAPissa tämä toteutetaan WSDL-tiedoston avulla. WSDL on XML-muotoinen tiedosto, joka kuvaa aliohjelmat parametreineen sekä paluuarvoineen ja määrittelee myös sen, mitä protokollaa tiedonsiirtoon käytetään ja missä osoitteessa palvelin kuuntelee. Tiedonsiirtoformaattina SOAPissa toimii aina määrämuotoinen XML.
REST on rajapintana huomattavasti vapaamuotoisempi, mutta toisaalta hyvin tiukasti sidottu HTTP-protokollaan. RESTissä kantavana ajatuksena on, että osoitteet viittaavat resursseihin ja käytetyt HTTP-metodit (REST-sanastossa ”verbit”) suoritettavaan toimenpiteeseen. Toisin kuin SOAPissa, REST-rajapinnat voivat itse määritellä tiedonsiirtoformaattinsa, vaikkakin toistaiseksi lähes kaikki REST-rajapinnat käyttävät JSON-formaattia.
Massapäivitystoiminnot tehdään lähes aina räätälöityinä, joten niin protokollat kuin formaatitkin voivat vaihdella laajalti. Protokollana hyvin varma valinta olisi kuitenkin käyttää SFTP:tä ja formaattina esim. CSV:tä tai JSONia. SFTP toimii hyvin luotettavan ja tietoturvallisen SSH-protokollan päällä, joten tiedot saadaan turvallisesti siirrettyä. CSV on muodoltaan taulukkomaista, joten se on luonnollinen valinta päivitettäessä tietoja suoraan tietokannan tauluun. CSV:ssä on myös kohtuullisen vähän ylimääräisiä tavuja, joten se on oiva valinta isojen tietomäärien siirtämiseen. JSON puolestaan sopii erittäin hyvin rakenteisen tiedon esittämiseen ja se on helposti luettavissa niin koneellisesti kuin ihmissilminkin.
Mitä haasteita integraatioiden kanssa on odotettavissa?
Ohjelmointirajapintoja käyttävissä integraatioprojekteissa nousee yllättävän usein ongelmaksi käyttäjäautentikointi. Monissa palveluissa on omat autentikointikommervenkkinsä, jotka vaativat toisinaan hämmästyttävän paljon työtä asiakaspuolella. Yleiset ja hyväksi todetut autentikointimenetelmät ovat:
Oman autentikointiongelmansa luovat lisäksi sellaiset palvelut, joissa esimerkiksi salasanat vanhenevat pakotetusti tietyin väliajoin. Tällöin jonkun pitää käydä vaihtamassa integraatiossa käytetty salasana uuteen aina sopivin väliajoin. Tämä saattaa vaikuttaa palvelun tietoturvaan jopa haitallisesti, mikäli salasanan käsittelyyn ei suhtauduta riittävällä vakavuudella.
Integroitaessa kokonaan ulkopuolisiin järjestelmiin (esim. sosiaalisen median palvelut), saattaa haasteita aiheutua tälle alalle ominaisesta jatkuvasta muutoksesta. Useiden kolmansien osapuolten palveluiden rajapintoihin tulee pieniä muutoksia koko ajan. Osa näistä muutoksista saattaa rikkoa integraatioita täysin arvaamattomasti, mikä aiheuttaa harmaita hiuksia ylläpitovaiheessa. Toisinaan myös jotkin integraatioissa käytetyt ominaisuudet saattavat poistua kokonaan käytöstä, jolloin toteutettu integraatio lakkaa toimimasta lopullisesti. Tällaiset tilanteet ovat todella harmillisia, koska integraatioiden toteuttamiseen on jo ehditty käyttää mahdollisesti huomattavastikin resursseja.
Etenkin massapäivityksissä sekä esim. käyttäjätietokantaintegraatioissa päänvaivaa saattaa aiheutua myös verkkoinfrastruktuurista. On yleensä varsin perusteltua pitää palvelut mahdollisimman hyvin palomuurattuna, mutta tiukat palomuurisäännöt usein hankaloittavat integraatioiden kehitystä sekä ylläpitoa. Tämä ei kuitenkaan koskaan ole syy käyttää löyhempiä palomuurisääntöjä, vaan kehitystyö ja ylläpito pitää suunnitella toimimaan verkkoinfrastruktuurin vaatimusten mukaan.
Toisinaan miettimistä saattaa tulla myös siitä, että integroitavan palvelun tietomalli ei tue integraation tavoitteita. Tällaisissa tapauksissa usein kyllä lopulta pystytään toteuttamaan haluttu toiminnallisuus, mutta sen rakentaminen vaatii oletettua enemmän työtä. Tällöin toteutuksesta tulee monimutkaisempi, mikä tekee siitä myös raskaamman sekä kalliimman ylläpitää ja jatkokehittää.
Kaikki onnistuu
Tietotekniikka on sikäli hieno ala, että lähes mikä tahansa on mahdollista. Drupal 8:n kanssa tämä on erityisen totta, sillä valtavat määrät Symfony 2 -komponentteja tekevät integroinnista helppoa ja luotettavaa. Jos olet kiinnostunut Drupalin integroinnista johonkin palveluun, ole meihin yhteydessä!
