RPA (Robotic Process Automation) termi viittaa prosessien automatisointiin kehitettyihin ohjelmistotekniikoihin. Näiden tekniikoiden avulla voidaan mm. siirtää tiedostoja järjestelmästä toiseen ja käsiteltäviä tiedostoja voidaan lukea, tarkistaa ja muokata. RPA-teknologioista esimerkiksi Robot Framework, UiPath ja Automate Anywhere ovat käytössä monissa tunnetuissa
yrityksissä.
Ohjelmistorobotit taipuvat moneen, mutta niitä on yritetty soveltaa jopa liian moneen käyttötarkoitukseen vaihtelevin tuloksin. Varsinkaan aineistojen laadun tarkistamiseen robotit eivät yksinään ole oikea ratkaisu, ei XML:n eikä EDIFACT, Excel, CSV, yms. aineistojen osalta.
Pointti 1: ”Virheet tulee korjata siellä missä ne syntyvät”
Markkinointipuheissa datan laatua luvataan usein parantaa robotiikan avulla. Tämä saattaa olla toimiva ratkaisu, esimerkiksi eri tietorekistereissä olevien tietojen täydentämiseen ja yhdenmukaistamiseen. Robotti ei kuitenkaan sovellu yleisratkaisuksi virheellisen datan käsittelyyn.
Mennään pahasti metsään, mikäli kauppatapahtumien, kuten tilausten ja laskujen, laatuongelmia lähdetään ratkomaan vastaanottopäässä robotiikan avulla. Virheet tulee korjata siellä missä ne syntyvät ja robotti soveltuu vain viimeiseksi oljenkorreksi keventämään ongelmien selvittelyä. Joitain perustason puutteita ja päättelyjä voidaan selvittää robotin avulla, mutta edes tekoäly ei taio roskasta kultaa.
Pointti 2: ”RPA XML-testauksessa soveltuu vain perustarkistuksiin yksinkertaisille aineistoille”
Esimerkiksi Robot Framework:in XML-kirjaston avulla voidaan luoda, muokata ja tarkistaa XML-tiedostoja. Sen avulla voidaan toteuttaa tietojen pakollisuustarkistuksia (Element Should Exist), perustason sisältötarkistuksia (Element Text Should Be) ja joitain yksinkertaisia eheystarkistuksia, kuten lukumäärien laskenta (Evaluate Xpath).
Vaikka perustarkistukset olisivatkin riittäviä tiettyyn käyttötapaukseen, seuraa tästä perinteinen ongelma eli aineistotarkistusten hautautuminen osaksi ohjelmakoodia. Kun aineiston tarkistusehtoja halutaan muuttaa, tulee robottiin tehdä kooditason päivityksiä. Tavoite kuitenkin lienee, että aineistotarkistuksia voitaisiin muokata päivittämättä itse robotin koodia?
Kauppatapahtumiin liittyy yleensä suuri määrä tietoja, sisältörajoitteita ja lukuisia ehdollisia vaatimuksia. Esimerkiksi EU-verkkolaskudirektiivin mukaiset (UBL/CII) aineistotarkistukset sisältävät noin 1000 tarkistusta. Näiden tarkistusten ylläpito kooditasolla olisi painajaismaista.
Pointti 3: ”XML-virheilmoitukset soveltuvat RPA-testaajan käyttöön, ei virheiden kommunikointiin”
Robot Framework:in XML-kirjastolla avulla luoduista tarkistuksista saadaan logille tieto, mitkä testit läpäistiin ja mitkä päätyivät virheeseen. Virheilmoitukset eivät kuitenkaan sisällä tietoja varsinaisista substanssitason vaatimuksista eikä virhetekstejä ole helppo täydentää.
Aineistovirheiden yhteydessä on myös tärkeää erotella, mitkä vaatimukset ovat suosituksia/hyviä käytäntöjä ja mitkä ehdottomia vaatimuksia. Ei sovi myöskään unohtaa, kuinka tärkeää on yksilöidä virheen sijainti, mieluiten linkkinä virheelliselle aineistoriville. Kaikki
tiedot tulisi voida myös välittää selkeänä raporttina eteenpäin aineiston tuottajalle.
Robot Frameworkin XML-kirjaston tarkistukset soveltuvatkin lähtökohtaisesti vain tapauksiin, joissa XML-aineisto tuotetaan omassa järjestelmässä ja sen tuottajalla on pääsy RPA-koodiin tai XML-aineiston tuottajalla on suora yhteys RPA-testaajaan. Tavoite kuitenkin lienee, että aineistotestauksen voisi suorittaa kuka tahansa oman aikataulunsa mukaan ja niin että testistä syntyisi selkeä palaute, jonka avulla virheet olisi helppo paikantaa ja korjata. Tähän ei robotilla päästä, ainakaan ilman huomattavaa määrää räätälöityä koodia.
Pointti 4: ”Vain rajallinen XPath 1.0 tuki, ei XPath 2.0 tukea”
Robot Frameworkin XML-kirjasto tarjoaa oletuksena vain suppean XPath 1.0 tuen ja xml-tuenkin kanssa vain normaalin 1.0 tuen. Jokainen XML-aineistojen kanssa tarkemmalla tasolla paininut tietää, että XPath 1.0:n ilmaisuvoima on hyvin rajallinen. Jotta päästäisiin perustarkistuksia syvemmälle tasolle, tarvitaan pääsy erilliseen funktiokirjastoon, XPath 2.0 tuki tai mieluiten molemmat.
Miten aineistojen laatu tulee testata?
Aineistojen testaukseen tulee käyttää siihen tarkoitettuja työkaluja. XML-aineistojen tarkistukseen soveltuu hienosti esimerkiksi Schematron-kieli. Sen avulla tarkistukset voidaan ryhmitellä omiksi kokonaisuuksikseen, kukin vaatimus voidaan kuvata selkokielisesti ja eritellä esimerkiksi fatal/warning -tarkenteella pakollisuuksiin ja suosituksiin. Tarkistuksesta saadaan tuloksena XML-muotoinen testausraportti, josta voidaan tuottaa tarpeeseen sopiva palaute.
Schematronia käytetään esimerkiksi kansainvälisessä PEPPOL-verkostossa, josta on hyvää vauhtia muodostumassa de-facto -kanava globaalin hankintatoimen tarpeisiin. Schematron-tiedoston lisähyötynä on, että se voidaan jakaa aineistojen tuottajille / lähettäjille, jolloin testaus voidaan suorittaa ilman välikäsiä. Schematron-tiedoston voi ladata myös Truugoon, jolloin aineistotestaus on mahdollista tarjota kumppaneille helppona itsepalveluna.
Annetaan siis robottien keskittyä prosessien automatisointiin ja tarkistetaan aineistot asianmukaisilla työkaluilla.
Juha Ikävalko
juha.ikavalko(at)netum.fi
p. 0405904523
Lisätietoja
Artikkeli on aiemmin julkaistu sivuilla www.agentit.fi.
AgentIT Finland Oy on 1.1.2021 lähtien Netum Integrations Oy.