Olemme kuunnelleet Fiidin lukijoita ja palautteen pohjalta otimme tämänkertaiseen numeroon mukaan myös teknisempiä aiheita, kuten integraatiot. Kukapa olisikaan parempi avaamaan integraatioiden ihmeellistä maailmaa kuin yhteentoimivuudesta väitellyt ja lukuisissa eri projekteissa integraatioita suunnitellut ja toteuttanut Hannu Järvinen, joka toimii Biitillä CTO:na.
Kirjoittaja: Hannu Järvinen / CTO, Biit Oy
Tässä Fiidissä käsitellään liiketoiminnan transformaatiota, jota ei tänä päivänä oikeastaan voi toteuttaa ilman teknologiaa. Tällaisissa transformaatioprojekteissa törmätään ennen pitkää toiveisiin siitä, että käyttöön otettava tai käytössä oleva järjestelmä voisi suoraan välittää tietoja johonkin toiseen tai useampaan eri järjestelmään. Teknisesti puhutaan yhteentoimivuudesta, joka voidaan saavuttaa integraatioiden avulla.
Käytännössä vain harva yritys pärjää yhdellä järjestelmällä, jolloin uusien järjestelmien käyttöönotto on prosessi, joka suunnitellaan ja toteutetaan pala kerrallaan. Erilaisiin käyttötarkoituksiin tarvitaan omanlaisiaan, aina juuri kyseiseen toiminnallisuuteen kehitettyjä järjestelmiä. Yritysmaailmassa lyhenteet kuten ERP, CMS, CRM ja FINA ovatkin tuttuja silloin, kun kuvataan järjestelmien kokonaisarkkitehtuuria.
Integraatioiden toteuttamiseen kolme vaihtoehtoa
Käytännössä integraation toteuttamiseen on kolme yleisesti käytettyä tapaa, joiden välillä suunnitteluvaiheessa tehdäänkin puntarointia. Jokaisessa tavassa on luonnollisesti omat hyvät ja huonot puolensa.
- Ensimmäinen tapa on käyttää valmista rajapintatoteutusta eli connectoria, joka usein konfiguroidaan suoraan jomman kumman järjestelmän käyttöliittymästä. Etuna on hyvin nopea käyttöönotto, koska riviäkään ohjelmakoodia ei tarvitse kirjoittaa. Kääntöpuolena on rajoittuneisuus niihin toiminnallisuuksiin, joita kyseinen connector tarjoaa. Tällainen connector löytyy muun muassa Power BI:stä. Lisäksi täytyy mainita, että Salesforcen omistamalle Herokulle (PaaS) löytyy tietysti oma suora tietokantojen synkronointi-connector, joka mahdollistaa Salesforce toteutusten laajentamisen oman ympäristönsä ulkopuolelle, esimerkiksi portaalitoteutuksissa.
- Toinen tapa on käyttää kolmannen osapuolen integraatioalustaa, johon järjestelmät liitetään connectoreilla. Hyvänä puolena on työn määrän minimointi useamman järjestelmän ympäristöissä, koska alusta toimii solmukohtana kaikkien järjestelmien välissä ja jokainen järjestelmä pitää kytkeä siihen vain kerran. Jos ajatellaan tilannetta, jossa viisi erillistä järjestelmää pitää jokainen kytkeä toisiinsa, kaksisuuntaisuus huomioon ottaen perinteisellä point-to-point -tavalla erillisiä yhteyksiä tarvitaan n(n-1), eli 20. Connectorien tapaan huonona puolena on rajoittuneisuus tarjolla oleviin toiminnallisuuksiin, joskin integraatioalustoissa connectorien kustomointimahdollisuudet ovat usein paremmat. Esimerkkinä usein käytetystä integraatioalustasta mainittakoon MuleSoft. Aivan pakko on vielä mainita, että toteutin ensimmäisen oman verkkopohjaisen integraatioalustani diplomityönä vuonna 2007. Siitä ei tullut kuitenkaan kaupallista hittiä.
- Kolmas tapa on toteuttaa räätälöity ratkaisu, joka ohjelmoidaan joko Salesforceen, liitettävään järjestelmään tai reaaliaikaista kaksisuuntaisuutta tavoiteltaessa molempiin päihin. Parhaana puolena on toteutuksen sovittaminen juuri käsillä oleviin vaatimuksiin ja myöhempi mukautusmahdollisuus, kun asiakasintegraation päälle suunnitellaan seuraavaksi laskutus- tai mitä tahansa liiketoimintakohtaista integraatiota. Ohjelmoijan näkökulmasta katsottuna mikä tahansa on mahdollista, koska sen voi itse kirjoittaa suoraan koodiin. Vaarana räätälöidyissä toteutuksissa on esimerkiksi kovakoodaus. Biitillä olemmekin siirtyneet laajalti malliin, jossa integraatio rakennetaan niin, että sen välittämiä kenttiä voi helposti muokata selaimella suoraan Salesforcen käyttöliittymästä (Custom Metadata Types). Toinen usein käytetty tapa on eriyttää datan välitys integraation logiikasta. Tällöin koodissa kuljetetaan tarvittavat viestit, jotka toinen ratkaisu sitten erikseen käsittelee. Näin varsinainen logiikka voidaan haluttaessa rakentaa koodin sijaan Flow:lla, joka on low/no-code ratkaisu ja taas hallittavissa Salesforcen käyttöliittymästä. Toki näiden ratkaisujen sopivuus puntaroidaan aina tapauskohtaisesti.
Integraatiotapaa valittaessa ovat kustannusten näkökulmasta vertailussa usein vastakkain lisenssimaksut ja vaadittavan työn määrä – integraatioalustojen tilauspohjainen hinnoittelu ja toisaalta räätälöidyn ratkaisun toteuttamiseen tarvittava budjetti. Tietysti myös connectorit ovat vertailussa mukana niiden saatavuuden mukaan. Asiakkaan näkökulmasta investointipäätökseen vaikuttavat onneksi myös muut tekijät.
Kun lähdetään tekemään loppukäyttäjän kannalta optimaalista integraatiota, voi räätälöity ratkaisu jäädä ainoaksi vaihtoehdoksi. Se ei onneksi ole huono asia, sillä tällöin ollaan digitalisaation ytimessä. Kaiken tarkoituksena on loppupeleissä helpottaa työtä ja kasvattaa tuottavuutta sekä arvoa. Connectorien kohdalla kannattaakin nopeasti PoCata, onko tarvittavat toiminnallisuudet toteutettavissa, vai sopisiko räätälöity toteutus paremmin tarpeisiin.
Teknisempi lähestymistapa integraatioihin
Ylätasolla olevien toteuttamistapojen lisäksi voisin avata hieman teknisempää puolta, jota varsinkin räätälöidyn integraation suunnittelussa täytyy ymmärtää. Toteutuspuolella asiaan liittyvät läheisesti esimerkiksi verkkoprotokollat, tiedostomuodot ja tietoturva.
Biitilläkin on toteutettu monenlaisia integraatioita. Joskus data liikkuu binäärinä ja toisinaan vaikkapa vanhahtavassa SOAP/XML-muodossa. Nykyään onneksi selkeästi yleisin integraatiotapa on kuitenkin API-pohjainen REST/JSON, joka omalta osaltaan mahdollistaa ketterän kehittämisen.
Perusajatuksena on käyttää tiedonsiirtoon samaa HTTP-protokollaa, jota verkkoselain käyttää sivuja palvelimelta hakiessaan. Koska Web 2.0 toi aikoinaan mukanaan interaktion selaimen ja käyttäjän välille, oli tarve välittää vaikkapa kirjoitettu chat-viesti selaimelta palvelimelle ja toimittaa sieltä muiden kirjoittamat viestit takaisin selaimeen.
Tähän soveltui hyvin selaimen JavaScript koodin natiivisti käyttämä JavaScript Object Notation (JSON) -syntaksi, joka yksinkertaisuutensa vuoksi on helposti ihmisluettavassa muodossa.
Tässä yksinkertainen JSON-esimerkki:
{
”name”: ”Hannu”,
”age”: 42,
”company”: ”Biit”
}
Chat-viestin lähettämiseen palvelimelle selain voi käyttää samaa HTTP-protokollaa, jolla se alunperin haki keskustelusivun. Tällä kertaa dataa lähetettäessä HTTP-metodina on kuitenkin GET:n sijaan POST. Nyt pääsemmekin varsinaiseen asiaan. HTTP-protokolla on pyyntö-vastaus -perusteinen, eli toinen pää (selain) lähettää aina pyynnön, johon palvelin vastaa.
Palvelin ei puolestaan voi ikinä omasta aloitteestaan lähettää pyyntöä, eli tässä tapauksessa dataa selaimelle. Miten selain voi tällöin saada päivitettyä muiden lähettämät viestit näkymäänsä? Aikoinaan selain lähettikin säännöllisen pyynnön palvelimelle ja näin haki uusia viestejä jatkuvasti. Sittemmin HTML5-standardi toi mukanaan Web Socket (WS) -protokollan, jota nykypäivänä käytetään yhteyden saattamiseksi reaaliaikaiseksi ja kaksisuuntaiseksi.
Historian ymmärrys tärkeää
Entä miten tämä kaikki enää liittyy integraatioihin? Historian ymmärrys on tärkeää, jotta käsittää HTTP-protokollan luonteen ja sen asettamat ehdot integraatiolle. Kyseessä on yksisuuntainen viestintä, johon toinen pää voi vain vastata.
Käytännössä Salesforcen hakiessa tai lähettäessä dataa, se kutsuu toisen järjestelmän rajapintaa. Jos toinen järjestelmä haluaa lähettää tietoja Salesforceen, se vastaavasti kutsuu Salesforcen rajapintaa. Toisinaan toisen järjestelmän laajennusrajoitteet estävät tällaisen toteutuksen tekemisen, mikä onkin syytä havaita jo suunnittelupöydällä.
Todellinen reaaliaikaisuus voidaan siis saavuttaa vain jos molempiin päihin toteutetaan rajapinnat (API). Tällöin niitä voidaan välittömästi kutsua tietojen päivittyessä. Salesforcessa on valmiiksi sisäänrakennettuna hyvin moderni rajapinta, jota kutsumalla voi lisätä/muokata/hakea/poistaa tietueita aina samassa muodossa riippumatta siitä, onko kyse liidistä, asiakkaasta tai mistä tahansa muusta tietueesta. Usein haasteeksi tuleekin vastapään rajapinta ja toteutukset.
Yhteenvetona haluan vielä todeta, että Salesforce on helppo alusta integraatioiden toteuttamiseen. Järjestelmän omat rajapinnat ovat kunnossa, ja räätälöityjä rajapintoja on aina helppo tehdä lisää. Samoin kutsujen tekeminen ulkoisiin rajapintoihin on helppoa moderneja menetelmiä käyttämällä.