Ged Stenman
Castor Metrix -käyttöliittymän kehitys
Metropolia Ammattikorkeakoulu Insinööri (AMK)
Ohjelmistotuotanto Insinöörityö
4.12.2020
Otsikko Sivumäärä Aika
Castor Metrix -käyttöliittymän kehitys.
37 sivua 21.8.2017
Tutkinto ICT/Sovellustekniikan insinööri (AMK) Tutkinto-ohjelma Ohjelmistotuotanto
Ammatillinen pääaine ammatillisen pääaineen nimi
Ohjaajat Juha Kämäri (Opettaja)
Mikko Wähäsilta (Konsultti)
Projektin tarkoituksena on Castor Metrix -komponentin käyttöliittymän kehitys ja toteutus.
Castor Metrixin tuli olla SAPUI5 Fiori -pohjainen, käyttäjädataa keräävä ja visualisoiva komponentti, jonka voi asentaa mihin tahansa olemassa olevaan Fiori-pohjaiseen ohjel- mistoon. Työn toimeksiantajana toimi CastorIT, joka suomalainen SAP-järjestelmiin ja pro- sesseihin keskittynyt konsultointitalo. CastorIT tarjoaa muun muassa kustomoituja SAP Fiori -pohjaisia web-ratkaisuja.
Toimeksiantajan asettamien rajoitteiden mukaisesti Metrixin on oltava Fiori-komponentti, joten työ toteutettiin SAP Fiorilla, joka on javascript-pohjainen käyttöliittymäteknologia.
Metrixin oli kyettävä keräämään käyttäjädataa laajemmin kuin Google Analytics. Tämä rat- kaistiin luomalla identifiointifunktiot, joissa käytettiin hyödyksi SAPUI5-elementtien uniik- keja muuttujia niiden tunnistamiseen.
Metrixin toisena tavoitteena oli pystyä näyttämään kerätty data intuitiivisella tavalla käyttä- jälle. Ratkaisu oli kirjoittaa Metrix Inspector, joka asentuu Castor Metrixin mukana. Inspec- tor mahdollisti minkä tahansa yksittäisen elementin datan visualisoinnin suoraan käytössä olevasta sovelluksesta. Metrixin visualisoima data tuotiin tietokannasta GraphQL-ohjelmis- torajapinnan kautta.
Insinöörityön lopputuloksena saatiin kehitettyä asiakkaan tapeitta vastaava ohjelmisto, jonka kehittämistä tullaan jatkamaan firman sisäisesti ja joka on helposti laajennettavissa.
Työstä saatu kokemus eri teknologioiden ja tekniikoiden suhteen tulee edesauttamaan tu- levien JavaScript-pohjaisten ohjelmien kehitystä.
Avainsanat SAP Fiori, Analyttiikka, Komponentti, Käyttöliittymä
Title
Number of Pages Date
Development of Castor Metrix User Interface 37 pages
21 August 2017
Degree Bachelor of Engineering
Degree Programme Information and Communications Technology Professional Major Software Engineering
Instructors Juha Kämäri, Principal Lecturer Mikko Wähäsilta, Project Manager
The aim of the project was the development and implementation of the Castor Metrix user interface.
Castor Metrix is a SAPUI5 Fiori-based user data collecting, analyzing, and visualizing com- ponent that can be installed on any current or future Fiori-based application. This thesis was made for CastorIT which is a Finnish consulting company focusing on SAP-technolo- gies. Their main product is custom build SAP Fiori applications. The main goal is to be able to offer similar or better services to Google Analytics for all of the company’s cur-rent and future clients with Fiori-applications. The aim is to use that data to improve the us-er interfaces of said applications.
As per the client’s request, Metrix is to be a Fiori component. Thus, it will be build using SAP Fiori, which is a JavaScript based user interface technology. Since Metrix is to be su- perior to Google analytics in its data collection capabilities, a custom identification function library had to be built. The identification functions used the unique identifications of
SAPUI5 elements to accurately identify and record each element when clicked.
The second objective was to make Metrix able to visualize the collected data in an intuitive and meaningful way to the end user. The solution was to build a Metrix Inspector, which would be an additional visualization component. Inspector would visualize data from the inspected element on top of the application that the element was from in a dialog. Metrix communicates with the database through GraphQL, an application programming interface.
The finished product met all requirements set by the client. Metrix is easily expandable and will be developed further within the company. The experience gained form the present study will be of help in developing JavaScript based applications in the future.
Keywords SAP FIori, User Analytics, Component, Frontend
Sisällys
Lyhenteet
1 Johdanto 1
2 Tausta teknologiat, arkkitehtuurit ja käsitteet 2
2.1 SAP 3
2.2 ERP 3
2.3 SAP Fiori ja SAPUI5 8
2.3.1 Suunnittelun ohjeistus 8
2.3.2 Fiori Launchpad 9
2.3.3 SAPUI5 10
3 Projekti 11
3.1 Ideointi 11
3.2 Suunnittelu ja määrittely 12
3.2.1 Data Collector 12
3.2.2 Data Visualisation Application 13
3.2.3 Tietokanta 17
3.3 Toteutus 21
3.3.1 iOS Demo 22
3.3.2 Fiori Komponentti (Data Collector) 23
3.3.3 Metrix-Inspector (Datan visualisointi) 30
3.3.4 Jatkokehitys 32
4 Yhteenveto 35
Lähteet 36
Liitteet
SAP - Systems Applications and Products in Data Processing. Saksalainen Eu- roopan suurin ohjelmistoyritys..
UI5 – SAP-järjestelmissä käytetyn käyttöliittyäratkaisun versionumero.
SSO - Kertakirjautuminen (engl. single sign-on; SSO) on menetelmä, jossa pääsy useisiin palveluihin toteutetaan yhdellä käyttäjän autentikoinnilla.
API - Application Programming Interface. Ohjelmoinnissa käytettävä rajapinta JSON - JavaScript Object Notation on yksinkertainen avoimen standardin tiedos-
tomuoto.
ERP - Enterprise resource planning. Toiminnanohjausjärjestelmä on yrityksille kohdennettu tietojärjestelmä, jolla integroidaan yritykselle oleellisia toimin- toja kuten varastonhallintaa ja laskutusta.
API - Application Programming interface eli ohjelmointirajapinta on määritelmä, jonka mukaan ohjelmat voivat kommunikoida.
CSS - (Cascading Style Sheets) on mm. XHTML-dokumenttien ulkoasun määrit- tämiseen tarkoitettu tyyliohjekieli.
IOS - (aiemmin iPhone OS) on Applen kehittämä käyttöjärjestelmä, joka on käy- tössä Applen iPhone-, iPod Touch-, iPad- ja Apple TV -laitteissa.
SAP Cloud Platform - alusta jonka SAP SE on kehittänyt uusien sovellusten luomiseen, tai olemassa olevien sovellusten laajentamiseen SAP: n ylläpitämässä suojatussa pilvipalveluympäristössä.
SAP NetWeaver - Ohjelmistopino monille SAP SE: n sovelluksille.
Weaver palvelimien rakentamiseen.
HANA - tietokanta, jonka SAP julkaisi ensimmäisen kerran vuonna 2010, on raken- nettu pohjimmiltaan erilaiseen arkkitehtuuriin. Se toimii muistinvaraisesti ja tiedot tallennetaan sarakkeisiin, mikä mahdollistaa nopeamman ja reaaliai- kaisen analyysin sekä monimuotoiset laskentaominaisuudet.
1 Johdanto
Käyttäjädatan kerääminen ja analysointi on merkittävässä roolissa nykyajan nettimark- kinoinnissa. Datan avulla voidaan esimerkiksi mitata ja optimoida markkinointistrategian vaikutuksia, tarkentaa käyttäjäkunnan profiileja, identifioida ja ennaltaehkäistä ongelma- kohtia sekä ymmärtää, miten käyttäjät käyttävät verkkosovellustasi.
Verkkoanalytiikka rinnastetaan usein synonyyminä Google Analyticsin kanssa, joka on Googlen ilmainen ja helppokäyttöinen analytiikka-alusta. Syynä on se, että Google Ana- lytics toimii lähes kaikkien modernien verkkosivuratkaisujen kanssa. Mutta mitä jos sitä ei voitaisikaan käyttää?
Tätä mietittiin CastorIT:llä, joka on SAP-järjestelmiin ja prosesseihin keskittynyt konsul- tointitalo. CastorIT tarjoaa muun muassa kustomoituja SAP Fiori pohjaisia web-ratkai- suja. SAP Fiori on JavaScript-pohjainen käyttöliittymäteknologia, jonka on tarkoitus tuoda SAP ratkaisut selaimiin modernimmalla käyttäjäkokemuksella.
SAP Fiori on JavaScript -pohjainen käyttöliittymäteknologia, joka täydentää ja voi kor- vata perinteiset SAP-käyttöliittymät. Se tarjoaa roolipohjaisen, mobiilikäyttöliittymiä tuke- van, modernin käyttökokemuksen. Fiori tarjoaa perinteisen SAP-käyttöliittymien ominai- suuksien lisäksi tärkeitä ominaisuuksia kuten keskitetyn pääsyn sovelluksiin SAP Fiori - käynnistysalustan kautta. Lisäksi Fiori tukee kertakirjautumista (SSO), roolipohjaista to- dennusta ja valtuutuksien jakoa, että avointa dataprotokollaa (OData), joka helpottaa tie- toturvaa ja tietojen hallintaa. [1.]
Tämä saavutetaan käyttämällä Fiorin yritysvalmiita käyttöliittymäkehitystyökaluja, jotka perustuvat SAPUI5:een, joka taas perustuu HTML ja JavaScript teknologioihin. Tämän arkkitehtuurin seurauksena SAP Fiori ei ole sidottu tiettyyn laitteeseen, istuntoon tai käyt- täjään. Fiori-sovelluksen käyttäjät voivat aloittaa tehtävän ja tallentaa sen keskeneräi-
senä. Myöhemmin he voivat jatkaa työskentelyä toisella laitteella. Sovellus tallentaa tie- dot automaattisesti asynkronisesti. Käyttäjät voivat jopa luovuttaa osittain suoritettuja tehtäviä toisilleen. [1.]
Koska SAP Fiori ja siihen liittyvä SAPUI5 JavaScript -kirjasto ovat SAP-maailmaan eri- koistuneita teknologioita, niille ei ole olemassa mitään valmista laajaa analytiikkaratkai- sua, jolla SAPUI5-kirjastolla toteutettujen sovellusten käyttödataa pystyttäisiin lukemaan ja analysoimaan. Tästä syystä valmiit ratkaisut, kuten Google Analytics eivät toimi kun- nolla, sillä ne ovat suunniteltu normaalien websivustojen kanssa käytettäväksi.
Tarve oli luoda työkalu, jolla oli kyky kerätä ja analysoida Fiori-ohjelmien käyttödataa.
Tämä mahdollistaisi ohjelmien toimivuuden ja kokonaisvaltaisen käyttökokemuksen pa parantamisen sekä ongelmakohtien löytymisen nopeutumisen.
Alkuperäisenä ideana oli luoda vastaavanlainen tai parempi tuote kuin Google Analytics, mutta SAPUI5 Fiori pohjaisille web-sovelluksille. Projekti sai nimekseen Castor Metrix, ja tarkemman suunnittelun sekä rajauksen jälkeen ratkaisun päätavoitteiksi muodistui- vat:
• Metrixin pitää olla "Fiori Component" joka tarkoittaa, että sen voi asentaa mihin tahansa olemassa olevaan Fiori pohjaiseen ohjelmistoon.
• Metrix kerää käyttäjädataa laajemmin kuin Google Analytics.
• Metrix kykenee näyttämään kerätyn datan intuitiivisella tavalla käyttäjälle.
Tämä insinöörityö keskittyy pääosin Metrixin käyttöliittymä osioon mutta jotta voimme ymmärtää, miten ja miksi päädyimme valittuihin tietokanta- ja käyttöliittymäratkaisuihin, on avattava myös laajoja käsitettä kuten SAP, ERP ja Fiori. Kerron myös yksityiskohtai- sesti projektin aloituksesta, suunnittelusta, toteutuksesta ja siitä, miten onnistuimme pää- semään kaikkiin tavoitteisiin.
2 Taustateknologiat, arkkitehtuurit ja käsitteet
2.1 SAP
Metrixin on tarkoitus tukea nimenomaan SAP-järjestelmien päälle rakennettuja Fiori-so- velluksia. On tärkeää ymmärtää, mitä SAP:lla tarkoitetaan, jotta ymmärrämme, minkä- laisten prosessien luomaa käyttäjädataa yritämme visualisoida.
SAP on lyhenne termeistä ”Systems Applications and Products in Data Processing”, joka on karkeasti käännettynä ”Järjestelmäsovellukset ja tuotteet tietojenkäsittelyssä”, sekä on SAP-järjestelmien luoneen SAP-nimisen firman nimi. SAP Software on eurooppalai- nen monikansallinen yritys, jonka perustivat vuonna 1972 Wellenreuther, Hopp, Hector, Plattner ja Tschira. He kehittävät ohjelmistoratkaisuja liiketoiminnan johtamiseen ja asia- kassuhteiden hallitsemiseen. [3.]
SAP-järjestelmä koostuu useista täysin integroiduista moduuleista, jotka kattavat käy- tännössä kaikki liiketoiminnan johtamisen ja hallinnan osa-alueet. SAP on ERP-markki- noiden markkinajohtaja. Vuodesta 2010 lähtien SAP:llä on yli 140 000 asennusta maail- manlaajuisesti, yli 25 toimialakohtaista yritysratkaisua ja yli 75 000 asiakasta 120 maassa. Muita merkittäviä markkinoilla olevia SAP-ohjelmistojen kilpailukykyisten tuot- teiden tarjoajia ovat Oracle ja Microsoft Dynamics. [3.]
2.2 ERP
SAP on ”ERP”-ohjelmistokokonaisuus. Mitä tällä oikeastaan tarkoitetaan? ERP on ly- henne termistä “Enterprise Resource Planning”, joka suomeksi tarkoittaa “Yrityksen re- surssisuunnittelua”. [4.]
Hyvin normaali kysymys on kysyä, miksi ”Enterprise Resource Planning” eli yrityksen toiminnanohjausjärjestelmä (ERP) on ylipäätään tarpeen ja mitä hyötyä siitä on yrityk- sille? Tarkastellaan kuvan 1 mukaista normaalia liiketoimintaskenaariota:
Kuva 1. Esimerkki liiketoiminnan skenaariosta, jossa ERP ei ole käytössä.
Oletetaan esimerkissä, että asiakas lähestyy myyntitiimiä ja pyytää tiettyä tuotetta.
Myyntiryhmä ottaa yhteyttä inventaario-osastoon tarkistaakseen tuotteen saatavuuden.
Myyntitiimi huomaa, että tuotetta ei ole varastossa, ja joutuu nyt kertomaan asiakkaalle, ettei tuotetta ole saatavilla. Tämä voi johtaa tyytymättömään asiakkaaseen, ja voi pahim- millaan johtaa asiakkaan menettämiseen. Jotta seuraavalla kerralla näin ei tapahdu, hei- dän on otettava käyttöön SAP ERP -työkalu. [5.]
Ennen kuin voimme ymmärtää yksityiskohtaisesti, mikä on ERP ja miten ERP voi auttaa liiketoimintaprosessissa, täytyy ymmärtää, miten eri osastot osallistuvat liiketoimintapro- sessiin aina raaka-aineen tilaamisesta tavaroiden valmistukseen ja lopuksi tavaran toi- mittamiseen asiakkaalle. Tätä prosessia havainnollistetaan kuvassa 2.
Kuva 2. Tätä prosessia seuraa suurin osa yrityksistä.
1. Ensin asiakas ottaa yhteyttä myyntitiimiin tarkistaakseen tuotteen saatavuuden.
2. Myyntiryhmä lähestyy inventaario-osastoa tarkistaakseen tuotteen saatavuuden.
3. Jos tuotetta ei ole varastossa, myyntitiimi kääntyy tuotannon suunnitteluosastoon tuotteen valmistamiseksi.
4. Tuotannon suunnittelutiimi tarkistaa inventaario-osastolta raaka-aineen saata- vuuden.
5. Jos raaka-ainetta ei ole saatavana varaston kanssa, tuotannon suunnittelutiimi ostaa raaka-aineen toimittajilta.
6. Sitten tuotesuunnittelu välittää raaka-aineet työntekijäportaalle todellista tuotan- toa varten.
7. Kun tuotanto on valmis, työntekijäportaalta lähetetään tavarat myyntitiimille.
8. Myyntiryhmä puolestaan toimittaa sen asiakkaalle.
9. Myyntiryhmä päivittää taloustiimiä tuotteen myynnistä saaduista tuloista. Tuotan- non suunnitteluryhmä päivittää rahoitustiimiä, siitä mitä raaka-aineiden toimitta- jille pitää käytetyistä materiaaleista maksaa.
Tämä on tyypillinen liiketoimintaprosessi jokaiselle teollisuusyhtiölle. Tärkeimpiä huo- miota tässä prosessista ovat:
• Monet osastot tai liiketoimintayksiköt osallistuvat prosessiin.
• Nämä osastot tai liiketoimintayksiköt kommunikoivat ja vaihtavat tietoja jatkuvasti keskenään.
• Menestyksen avain on tehokas kommunikointi ja tiedon saanti näiden osastojen ja liiketoimintayksiköiden, sekä niihin liittyvien kolmannen osapuolten, kuten toi- mittajien, ulkoistajien ja asiakkaiden välillä.
ERP-järjestelmät mahdollistavatämän tehokkaan kommunikoinnin kaikkien osastojen ja osapuolten välillä.
Kuva 3. Prosessi ERP:llä
Verrattuna kuvaan 2 kuva 3 on huomattavasti selkeämpi. Prosessi on edelleen sama mutta kaikki kommunikaatio, pois lukien asiakkaan ja myynnin välinen, tehdään ERP:n kautta. Tässä keskitetyssä järjestelmässä on monia hyviä puolia:
• Tietoja ylläpidetään keskeisessä paikassa ja jaetaan eri osastojen välillä. Se eli- minoi tietojen päällekkäisyydet, epäjatkuvuuden ja redundanssin. Dataan voi siis aina luottaa.
• Osastoilla on pääsy muiden osastojen tietoihin reaaliajassa. Tämä poistaa tar- peen soitella eri osastojen välillä, esimerkkisi myynnin tarkastaessa tuotteen saa- tavuutta inventaariosta.
• Muita hyötyjä ovat esimerkiksi tuottavuuden lisäys, varastojen hallinnan helpot- tuminen, edistää laatua, vähentää materiaalikustannuksia, tehostaa henkilöstö- hallintoa, vähentää yleiskustannuksia, ja kaikki tämä kasvattaa voittoja.
Tästä syystä ERP-ratkaisut ovat erittäin yleisiä varsinkin suurissa liiketoimintayksiköissä.
[5.]
2.3 SAP Fiori ja SAPUI5
Kun ymmärretään paremmin käsitteet SAP ja ERP, ja miksi suuret liiketoimintayksiköt käyttävät näitä ratkaisuja, siirrymme tarkastelemaan Fioria. Kuten jo aikaisemmin mai- nittiin, Metrixin on tarkoitus toimia nimenomaan SAPUI5 Fiori -sovelluksilla. SAP Fiori on SAP:n kehittämä suunnittelukieli ja käyttökokemusratkaisu, jota SAP, sen asiakkaat ja kumppanit voivat käyttää liiketoimintasovelluksiensa tuomiseen selaimiin.
SAP Fiori -suunnittelukieltä käytetään SAP-sovelluksissa, mukaan lukien S/4HANA- ja C/4HANA-suites, SAP Data Hub ja SAP Ariba. Fiori-suunnittelukieltä käyttäviä sovelluk- sia kutsutaan usein Fiori-sovelluksiksi tai Fiori-käyttöliittymiksi (UI). SAP tarjoaa Fiori- yhteensopivia käyttöliittymäkirjastoja SAPUI5-kirjastossaan, samoin kuin SAP Cloud Platform -ohjelmistokehityspaketti (SDK) iOS:lle ja SAP Cloud Platform SDK Androidille.
[1.]
SAPUI5 on käyttöliittymäteknologia, joka perustuu JavaScriptiin, CSS: ään ja HTML5:
ään. Sovelluskehittäjät voivat käyttää sitä selaimessa toimivien sovellusten rakentami- seen. UI5:llä voi siis tehdä muitakin, kuin Fiori sovelluksia, mutta niitä kutsutaan silloin mukautetuiksi UI5 sovelluksiksi. Sovellus on varsinaisen SAP Fiori sovellus vasta kun se seuraa Fiori-suunnitteluohjeita ja on rakennettu käyttäen SAPUI5 kirjastoa. [6.]
2.3.1 Suunnittelun ohjeistus
Fiori-suunnitteluohjeet antavat ohjeet sellaisten käyttöliittymien toteuttamiseen, jotka noudattavat Fiori-suunnittelukielen prioriteetteja. Fiori-suunnitteluohjeiden tavoitteena
on ohjata suunnittelijoita ja kehittäjiä luomaan sovelluksia, jotka käyttäjien on helppo tun- nistaa Fiori-sovelluksiksi ja jotka käyttäytyvät johdonmukaisella ja ennustettavalla tavalla käyttökokemuksen parantamiseksi.
Ohjeissa määritetään jaetut palvelut (shared servises) kuten haku, Fiori Launchpad ja viestien käsittely, joita saatetaan käyttää tietyissä sovelluksissa. Ne määrittelevät myös ominaisuudet, jotka ovat yhteisiä kaikille sovelluksille, kuten teema, ulkoasu ja yleisten elementtien, kuten painikkeiden, taulukoiden ja tiilien, käyttäytymisen. [7.]
2.3.2 Fiori Launchpad
Fiori Launchpad palvelu, josta käyttäjä voi avata kaikki tarvitsemansa Fiori-ohjelmat pai- namalla kyseisen ohjelman tiiltä. Useimmat ihmiset yhdistävät juuri Launchpad-näkymän vahvimmin Fiori-käyttöliittymään ja käyttökokemukseen (User Experience).
Kuva 4. SAP Fiori Launchpad -näkymä esimerkki. [8.]
Fiori Launchpad nykyisessä Fiori 2.0 -versiossa koostuu joukosta ryhmiä ja tiiliä, joita käytetään Fiori-sovellusten käynnistämiseen ja asiaankuuluvan tiedon näyttämiseen.
Launchpad-näkymään kuuluu myös joukko tukipalveluita, jotka mahdollistavat auktori- soinnin, personoinnin, haun ja ilmoitukset. SAP tarjoaa useaa erilaista toteutusta SAP
Fiori Launchpad -ratkaisusta, joita asiakkaat voivat käyttää SAP Cloud Platformia SAP NetWeaver ABAP- ja HANA-alustoilla.
Käytännössä siis voidaan varmistaa, että jokaisella käyttäjällä on oikeus nähdä ja käyt- tää juuri niitä Fiori-sovelluksia, joita heidän kuuluu, ja että kaikki nämä sovellukset ovat yhdessä paikassa helposti löydettävissä. [8.]
2.3.3 SAPUI5
SAPUI5 on JavaScript-käyttöliittymäkirjasto, joka koostuu monipuolisista ominaisuuk- sista ja suuresta määrästä käyttöliittymäelementtejä ja SAPUI5-esimerkkejä kirjastona.
Ominaisuuksiin kuuluu tehokas moottori HTML-päivitykseen ja luontiin, joka määrittelee elementit, tietorakenteet ja tiedon sitomisen eri tietolähteille, Model-View-Controller-kon- septiin perustuen. Lisäksi kaikki tarvittavat SAPUI5:n sisäiset kirjastot ladataan auto- maattisesti tarpeen mukaan.
Elementit vaihtelevat yksinkertaisista painikkeista monimutkaisempiin elementteihin, ku- ten sap.m.SplitContainer, joka tukee näppäimistönavigointia, kosketusnavigointia ja muuta. Kehittäjällä on myös pääsy useisiin visuaalisiin teemoihin, joita voidaan mukaut- taa teeman suunnittelijan avulla tai muokata suoraan CSS:llä.
SAP käyttää tätä kirjastoa yrityssovelluksiin, jotka vaativat kriittisesti korkeita turvalli- suusstandardeja suojautuakseen sivustojenvälisiltä komentosarjoilta tai muilta hyök- käyksiltä. Se mahdollistaa myös vankan virheanalyysin / tarkastustyökalun integroinnin.
SAPUI5 perustuu jQuery ratkaisuun. [2.]
3 Projekti
3.1 Ideointi
Metrix-projekti oli alun perin nimeltään ”Fiori Usage Analytics”, ja tarkoituksena oli luoda tarkempaa käyttäjädataa keräävä komponentti, jonka voisi asentaa mihin tahansa ole- massa olevaan CastorIT:n luomaan Fiori-pohjaiseen sovellukseen. Idea syntyi silloiselta kollegalta, joka oli jo pitkään haaveillut Google Analytics -tyylisestä ratkaisusta Fiori- ja SAP-maailmaan.
Metrixin haluttiin olevan niin sanottu ”Software as a service” (SaaS), eli sen haluttiin toimivan ilman muutoksia itse sovellukseen, johon Metrix asennetaan. Tämä aiheutti monia haasteita niin suunnittelu- kuin toteutusvaiheessakin, joita käymme myöhemmin läpi.
Kuva 5. Erot Metrixin toteuttamiseen SaaS-ratkaisuna vs. kustomoituna palveluna
Projektin mahtipontisimpia tavoitteita ideatasolla oli, että Metrix kykenisi tunnistamaan käyttäjän painaman elementin, tallentamaan siitä tärkeimmät tiedot ylös, ja parhaimmil- laan kykenemään piirtämään painetun elementin uudestaan käyttödatan visualisoinnin yhteydessä.
Ideointivaiheessa teorioitiin myös, että mikäli UI-elementtiä painettaessa tallennetaan ai- kaleima, pitäisi olla mahdollista rakentaa algoritmi, joka tunnistaa niin sanottuja ”floweja”, eli toistuvia näppäily-yhdistelmiä, joita käyttäjät tekevät usein. Esimerkiksi kun käyttäjä laittaa tuotteen ostoskoriin, ja siirtyy maksamaan tuotteen, tämä voisi olla ”flow”.
3.2 Suunnittelu ja määrittely
Suunnitteluvaiheeseen siirryttäessä jaoimme Metrixin toteutuksen osiin, jotta voisimme paremmin suunnitella ja työstää jokaisen osan tarkasti:
• Data Collector – käyttödatan kerääjä.
• Data Visualisation App (myöhemmin Metrix Inspector) – kerätyn datan visuali- soimiseen tarkoitettu erillinen applikaatio.
• Database – tietokantaratkaisu.
Kuten aikaisemmin on mainittu, keskityn insinöörityössäni enimmäkseen Data Collecto- riin ja Data Visualisation Appiin, sillä ne olivat omaa vastuualuettani, mutta kerron myös lyhyesti Database-osiosta.
3.2.1 Data Collector
Data Collector on Metrixin ydin ja toiminnan kannalta tärkein osa. Olennaisinta on, että käyttäjän painaessa mitä tahansa elementtiä Fiori-sovelluksen sisällä, Metrixin Data Col- lector huomaa tapahtuman, tallentaa tarvittavat tiedot ja tekee tämän vaikuttamatta oh- jelman suorituskykyyn.
Listasimme tiedot, jotka käyttödatan kerääjän pitäisi vähintään osata jokaisesta elemen- tistä tallentaa:
• Aikaleima (sekunnin tarkkuudella) – milloin elementtiä painettiin.
• Elementin tyyppi – Metrixin pitää pystyä tunnistamaan, oliko painettu elementti esimerkiksi ”Button”, ”TabBar” tai ”ListItem”, jotka ovat yleisiä SAPUI5:ssä käy- tettyjä elementtejä.
• Elementin ID – Uniikki numero- ja kirjainyhdistelmä, jolla elementin tunnistaa tois- ten samanlaisten elementtien joukosta.
• PageTitle, eli käytössä ollut ollut Fiori-sovellus – Mihin Fiori-sovellukseen ele- mentti kuuluu.
• Muu elementin sisäinen oleellinen data – Tämä on esimerkiksi ”button” eli nap- pula elementissä napin selittävä teksti tai ikoni. “Input”-tyylisessä tekstikentässä taas tallennetaan kirjoitettu teksti tai numero.
3.2.2 Data Visualisation Application
Suunnitteluvaiheessa ideana oli, että data visualisoitaisiin erillisessä sovelluksessa, josta voisi nähdä muun muassa eniten käytetyt, vähiten käytetyt ja suhteessa eniten käytetyt elementit tyypeittäin (kuva 6). Tämä versio luotiin hyvin aikaisessa ideointivai- heessa, ja on siksi vielä hyvin karkea.
Kuva 6. Ensimmäinen UI design mock-up, miltä visualisointisovellus voisi näyttää. (Mock-up luotu InVision Studiolla)
Yleisesti ideana oli, että ohjemassa olisi kolme osiota. Vasen sivusarake näyttäisi kirjau- tuneen käyttäjän ja valitun Fiori-sovelluksen nimen, jonka dataa tarkastellaan. Keskiosa olisi varsinainen datan visualisointi osa, jossa data tuodaan luettavampaan muotoon simppeleitä top5-listoja käyttäen. Oikea sarake mahdollistaisi tarkasteltavan elementin tyypin valinnan (kuva 6).
Kuva 7. Toisen ideointisession aikana luotu Mock-up. (Mock-up on luotu InVision Studiolla)
Kuva 8. Vaihtoehtoisia datan visualisointityylejä (Mock-up luotu InVision Studiolla)
Pidettyämme toisen ideointikokouksen päätimme pitää keskiosan tiilirakenteen ja listat, mutta visualisoida datan paremmin käyttäen piirakkadiagrammeja. Lisäksi päätettiin, että keskiosaa voi kelata alaspäin myös hiirellä (tai sormella mobiilissa), eli kaikkien element- tityyppien data piirretään samaan näkymään (kuva 7). Kävimme läpi muutamia iteraati- oita mahdollisista tiilityypeistä (kuva 8).
Tässä kohtaa myös otettiin huomioon, että sovelluksen pitäisi olla toiminnallinen myös mobiili- ja tablettilaitteilla. Keskiosan tiilet sopivat tähän hyvin, ja sivusarakkeet voisi tuoda esiin pyyhkäisemällä sormella näytön reunasta.
Kuva 9. Ensimmäinen virallinen UI design -kuva. (Mock-up luotu InVision Studiolla)
Pidimme vielä monta pienempää kokousta visualisointisovelluksen toiminnallisuudesta.
Kuvassa 9 on ensimmäinen virallinen hyväksytty versio, jonka avulla lähdimme sovel- lusta rakentamaan toteutusvaiheessa.
3.2.3 Tietokanta
Tietokantapuolen ratkaisuun oli jo alusta lähtien vahva idea, jossa pysyttiin lähes täysin loppuun saakka. En itse osallistunut juurikaan tietokantapuolen toteutukseen, joten käyn sen arkkitehtuurin vain pääpiirteittäin läpi.
Tietokantaratkaisu koostui kolmesta osasta:
• MogoDB Atlas - Itsestään huolehtiva ja skaalautuva usean pilven tietokantapal- velu. [9.]
• Microsoft Azure - Microsoftin julkinen pilvipalvelu. Azurea voidaan käyttää sekä virtuaalipalvelinten alustana että kehittäjille tarkoitettuna kehitysalustana. [10.]
• GraphQL- Sovellusliittymien kyselykieli (API). Tarjoaa hyvän työkalun käyttöliit- tymä- ja tietokantakehittäjien välille. Antaa mahdollisuuden pyytää tarkasti juuri sen datan, mitä käyttöliittymä tarvitsee. [11.]
MongoDB toimi itse tietokantana. Kehityskieleksi valittiin Javascript, sillä kaikki projektiin osallistuneet kehittäjät ovat web-kehittäjiä, joille kieli on tuttu. Valintaperusteet Mon- goDB:lle yli muiden tietokanta-ratkaisujen oli sen kyky tallentaa tietoja joustaviin, JSON- tyyppisiin asiakirjoihin, eli kentät voivat vaihdella asiakirjasta toiseen ja tietorakennetta voidaan muuttaa ajan myötä. Tämän ratkaisun tuoman datan eheyden varmistaminen oli tiimille tärkeää, sillä emme vielä olleet varmoja, mitä kaikkea dataa Metrixin halutaan tulevaisuudessa kyetä tallentamaan. Lisäksi MongoDB:n tukemat Ad hoc -kyselyt, indek- sointi ja reaaliaikainen datan yhdistäminen tarjosivat tehokkaita tapoja käyttää ja analy- soida kerättyjä tietoja.
Azure valittiin toimimaan MongoDB palvelimen alustana. Syynä valintaan oli, että Azurea oli aikasemminkin käytetty CastorIT:n projekteissa onnistuneesti, ja siitä oli myös projek- tin jäsenillä kokemusta.
GraphQL valittiin API-rajapinnaksi, sillä se vaikutti lupaavalta työkalulta käyttöliittymän ja tietokannan välille. GraphQL ei ollut välttämätön Metrixin toiminnan kannalta, mutta Cas- torIT oli jo pitkään etsinyt työkalua, joka helpottaisi käyttöliittymä- ja tietokantakehittäjien kykyä kommunikoida keskenään.
GraphQL tarjoaa projektiin asennettuna GraphiQL-kehittäjätyökalun, joka tarjoaa GraphQL:ään liitetyn tietokannan skeeman helposti luettavassa muodossa sekä mah- dollisuuden testata kyselyjä lennosta (kuva 10). Tämä helpotti huomattavasti varsinkin käyttöliittymäkehitystä sekä keskustelua tietokantakehittäjien kanssa.
Kuva 10. GraphiQL-kehittäjätyökalu. Vasemmalla on kysely. Keskellä on QraphQL:n palauttama vastaus ja oikealla skeema.
Data pyyntö GraphQL:ään GraphQL vastaus
{
hero {
name
# Queries can have comments!
friends {
name }
} }
{
"data":{
"hero":{
"name":"R2-D2", "friends":[
{
"name": "Luke Skywalker"
}, {
"name": "Han Solo"
}, {
"name": "Leia Organa"
} ] } } } Taulukko 1. GraphQL Syntaksi esimerkki.
GraphQL:n kyselyiden syntaksi oli myös erittäin simppeli ja helppo oppia. Tässä esimer- kissä GraphQL:ltä pyydetään “hero” eli sankari oliota ja hänen “friends” eli ystävä listaa (taulukko 1). Käytännössä syntaksi vain vaatii datan yksinkertaistetun muodon sitä pyy- dettäessä (kuva 11).
Kuva 11. Havainnollistava kuva GraphQL-kyselystä dataa pyytävän laitteen ja tietokannan vä- lillä.
CastorIT:lle oli myös tärkeää, että Metrix toimii sujuvasti puhelimilla ja muilla päätelait- teilla. Tyypilliset REST-sovellusliittymät vaativat lataamista useista URL-osoitteista, mutta GraphQL kykenee tarjoamaan kaikki sovelluksen tarvitsemat tiedot yhteen pyyn- töön, mikä mahdollistaa Metrixin nopean toiminnan hitaissakin verkkoyhteyksissä.
3.3 Toteutus
Toteutusvaiheeseen siirryttiin suunnitteluvaiheen päätyttyä, ja suunnitteluasiakirjan hy- väksynnän jälkeen. Käsittelen tässä osiossa käyttöliittymän toteutuksen päävaiheet.
Metrixin toteutus kesti noin puolivuotta, ja se voidaan jakaa seuraaviin osiin:
• iOS Demo – idean toteuttamiskelpoisuutta esittelevä vajavainen toteutus, joka esitellään CastorIT:n isännöimässä SAP Finug-seminaarissa.
• Proof of concept (Konseptin todistus) - idean toteuttamiskelpoisuutta esittelevä vajavainen toteutus.
• Fiori Komponentti (Data collector) – Varsinaisen pääkomponentin ja datankerää- jän rakennus.
• Metrix-Inspector (Data visualisation) – Myöhemmin innovoidun datan visualisoin- tityökalun rakennus.
• Viimeistely – Tuotteen testaus ja viimeistely.
3.3.1 iOS Demo
Projektin toteutuksen alkumetreillä tuotantotiimiltä pyydettiin pientä demoa Metrixistä tu- levaan SAP Finug -seminaariin.
Alun perin ideana oli kerätä käyttäjädata itse Metrixiällä, ja sitten visualisoida ne erilli- sessä sovelluksessa. IOS-demoa rakentaessa tavoitteena oli vain esitellä datan visuali- sointia mallitietoja käyttäen.
Tähän tarvittiin iOS-sovellus, toimiva tietokanta ja GraphQL API. Isoin työ tässä vai- heessa oli tietokannan puolella. IOS sovellus luotiin Xcodea käyttäen, ja sen tarkoitus oli vain havainnollistaa, miten kerätty data voidaan näyttää loppukäyttäjälle. Tämä toteutet- tiin vain yksinkertaisilla piirakka-kaavioilla (kuvassa 10 keskellä) ja listalla, josta käyttäjä voi valita minkä sovelluksen dataa haluaa tarkastella (kuvassa 12 vasemmalla). Data pyydettiin suoraan GraphQL:ltä.
Kuva 12. Näytönkaappaus varsinaisesta toimivasta iOS-sovelluksesta.
iOS-sovellusta tehtäessä GraphQL tuli tutuksi. Syntaksi oli yksinkertainen, ja se auttoi huomattavasti kommunikaatiossa tietokantakehittäjien kanssa. GraphQL mahdollisti useassa kohtaa tietokanna ongelmanmäärittämisen käyttölittymäkehittäjältäkin.
3.3.2 Fiori-komponentti (Data Collector)
Varsinainen projekti alkoi iOS-demon jälkeen, jossa olimme kyenneet todistamaan, että tietokantamme pystyy jakamaan dataa GraphQL-rajapintaa käyttäen käyttöliittymään.
Metrix koostuu kahdesta osasta, Data Collectorista (datan kerääjä) ja Inspectorista (da- tan visualisoija). Molemmat näistä päätyivät lopulta samaan Fiori-komponenttiin. Näin tehtiin, jotta Metrix olisi jatkossa asennettavissa mihin tahansa Fiori-pohjaiseen sovel- lukseen.
Työ aloitettiin rakentamalla hyvin yksinkertainen Fiori-sovellus, joka rakentui kaikista mahdollisista eri Fiori-elementistä kuten tekstikentistä, listoista, välilehdistä, ra- dionapeista, liukusäätimistä ja monesta muusta (kuva 13). Tämä toimi kehitysympäris- tönä Metrixille. Sovelluksessa kykeni näin testaamaan Metrixin kykyä tunnistaa ja tallen- taa kaikkia mahdollisia interaktiivisia elementtejä.
Kuva 13. Metrixin testaamiseen rakennettu Fiori-sovellus. Sisältää suurimman osan Fiori-pohjai- sista interaktiivisista elementeistä.
Ensimmäisenä tehtävänä itse käyttäjädatan kerääjän luonnissa oli kyetä tallentamaan jokainen käyttäjän hiirenpainallus. Tähän ratkaisuna käytettiin tapahtumakuuntelijaa.
Koodiesimerkki 1.
Koodiesimerkissä 1 yksinkertainen koodi tallentaa hiirenpainallus tapahtuman, jonka jäl- keen se suorittaa tapahtumafunktion nimeltä “activeWordsClickIn(e)” ja antaa tälle ta- pahtuman arvona “e”. Myöhemmin tapahtumakuuntelija lisättiin myös näppäimistöpai- nalluksiin ja kohdistustapahtumiin, sillä niitä tarvittiin tiettyjen elementtien oikeaan tun- nistamiseen sekä joidenkin arvojen tallentamiseen.
Seuraava, mahdollisesti suurin haaste, oli käyttöliittymäelementtien tunnistus. Toisin sa- noen, miten tiedetään, että käyttäjän painama elementti oli esimerkiksi liukusäädin eikä esimerkiksi radionappi. Fiori generoi ohjelmaa juostessa jokaisen elementin luokkanimet (class names) uniikeiksi, joten ne eivät pysy vakioina. Tämä on suurin syy sille, miksi Google Analytics ei toimi Fiori-pohjaisissa sovelluksissa, sillä se olettaa luokkanimien pysyvän samoina joka kerta, kun sovellus avataan. Emme voineet siis myöskään matkia Google Analyticsin tapaa tunnistaa elementtejä.
Ongelma ratkaistiin tutkimalla jokaista erillistä Fiori-elmenttiä ja tunnistamalla niille uniikit identifioivat arvot, jotka kerättiin ehtolauseiksi identifiointifunktioihin. Funktio todettiin toi- mivaksi, kun testisovelluksen (kuva 13) jokaista elementtiä painettaessa Metrix tunnisti vain oikean elementin. Nämä funktiot suoritetaan listanomaisesti järjestyksessä järjes- tyksessä tapahtumafunktioiden sisällä, kuten seuraavassa esimerkissä näkyy.
Koodiesimerkki 2.
Koodiesimerkissä 2 on yksi 36:sta Metrixin identifiointifunktiosta “isSearch(e) “. Funkti- olle annetaan tutkittavaksi painettu elementti. Mikäli yksikään seuraavista ehtolauseista ei pidä paikkaansa, olemme tunnistaneet painetun elementin olevan hakukenttä.
Muussa tapauksessa elementtiä ei ole tunnistettu ja siirrytään seuraavaan identifiointi- funktioon, kunnes elementti on tunnistettu.
Kun tutkittavana oleva elementti on tunnistettu, tallennetaan siitä relevantti data talteen.
Relevantti kerättävä data oli määritelty projektin johdon puolelta.
Koodiesimerkki 3.
Koodiesimerkissä 3 aikaisemmin tunnistetusta hakukenttäelementistä tallennetaan tyy- piksi ”SearchField” eli hakukenttä, sen uniikin tunnistusnumeron, missä sovelluksessa hakukenttä on ja mitä hakukenttään oli kirjoitettu. Kun tiedämme elementin tyypin, pys- tymme myöhemmin piirtämään sen uudelleen datavisualisointi osiossa.
Koodiesimerkki 4.
Jokaisen tunnistetun elementin relevantin datan lisäksi haluttiin tietää, millä laitteella ja missä tapahtuma oli tallennettu. Laitteen tunnistus tapahtui käyttämällä selaimen UserA- gent-ominaisuutta. UserAgent palauttaa koodiesimerkissä 4 selaimen palvelimelle lähet- tämän user-agent -otsikon arvon, josta voidaan päätellä esimerkiksi, millä laitteella se- lainta käytettiin.
Koodiesimerkki 5.
Kaikki kerätty data pyritään lähettämään GraphQL:än kautta tietokantaan JSON-oliona, mikäli Metrixillä on sillä hetkellä internetyhteystila aktiivinen. Metrixin haluttiin toimivan huonoissakin verkkoyhteystilanteissa ja paikoissa. Mikäli internetyhteys ei toiminut tai oli epävakaa, Metrix muutti internetyhteystilan epäaktiiviseksi (koodiesimerkki 5), ja alkoi tallentamaan kerättyä dataa laitteen välimuistiin. “CheckHostReachable”-funktiota kut- suttiin joka minuutti, kunnes internetyhteys oli taas vakaa, jolloin internetyhteystila muu- tettiin aktiiviseksi, ja tallennettua dataa alettiin järjestyksessä lähettämään tietokantaan.
Koodiesimerkki 6.
GraphQL:lle dataa lähetettäessä lähetetään ylätunnuksena myös Metrixin käynnistämi- sen yhteydessä saatu todenne-eväste, jolla tarkastetaan, että dataa lähettävällä käyttä- jällä on oikeus lähettää dataa tietokantaan (koodiesimerkki 6). Samaa todennusta käy- tetään dataa pyydettäessä tietokannasta.
Tiivistäen Metrixin toiminnallisuus on siis:
1. Kuunnella jokaista hiirenpainallusta
2. katsoa mitä painettiin ja yrittää tunnistaa painettu elementti
3. kerätä elementille olennainen data
4. lähettää kerätyn datan joko välimuistiin tai tietokantaan GraphQL:llän kautta.
Kaikessa yksinkertaisuudessaan tässä on toimiva toteutus Metrixin datankerääjä osi- oista. Tällä tavoin Metrixiä voi laajentaa tulevaisuudessa tukemaan uusia Fiori-kom- ponentteja vain kirjoittamalla niille uuden identifiointifunktion. Näin Metrixin datankerääjä osuus on erittäin helppo ylläpitää ja huoltaa.
3.3.3 Metrix-Inspector (Datan visualisointi)
Kun datankerääjä osa Metrixistä oli saatu tyydyttävään kuntoon, siirryimme työstämään datan visualisointityökalua. Tässä kohtaa oli vielä tarkoitus luoda erillinen visualisointi sovellus, joka näyttäisi kaiken kerätyn datan käyttäjälle merkittävällä ja ymmärrettävällä tavalla.
Työn alkumetreillä havaittiin kuitenkin perustavaa laatua oleva ongelma. Vaikka pys- tymme tallentamaan tietyn elementin, esimerkiksi tietyn liukusäätimen ulkonäön, ID:n, siihen tallennetun arvon ja muuta, se ei välttämättä ollut tarpeeksi auttamaan loppukäyt- täjää ymmärtämään, mistä elementistä oli tarkalleen kyse. Lisäksi mikäli loppukäyttäjä haluaisi esimerkiksi saada tietää, montako kertaa tiettyä painiketta oli painettu, miten hän hakisi tiedon visualisointi-sovelluksesta, jos painikkeella ei ollut mitään identifioivaa tekstiä, vain vaan esimerkiksi pelkkä ikoni?
Tarkka tiedonhaku erillisessä visualisointi-sovelluksessa olisi yleisesti hyvinkin ongel- mallinen toteuttaa. Lähdin siis ratkaisemaan haastetta toisesta näkökulmasta. Jos käyt- täjä haluaa tietää jotain tietystä elementistä, eikö olisi helpompaa, että he voisivat nähdä datan suoraan itse sovelluksessa, jossa elementti on?
Näin syntyi Metrix-Inspector. Ideana oli luoda niin sanottu “Inspector-nappi” (kuva 14), jota painettuaan seuraava elementti, jota käyttäjä hiirellä painaisi, avaisi “Inspector-nä- kymän” (kuva 15), eli dialogin, joka toisi kyseisen elementin datan visuaalisesti ymmär- rettävässä muodossa suoraan käytössä olleen sovelluksen päälle.
Kuva 14. “Inspector-nappi" oikeassa alakulmassa. Sen jälkeen painetaan tutkittavaa elementtiä.
Tässä tapauksessa Radio-nappia jonka teksti arvo on “Option 1”.
Kuva 15. “Inspector-näkymä” painetusta elementistä.
Tämä mahdollisti koko Metrixin toteutuksen rakentamisen yhdelle Fiori-komponentille.
Kyseinen komponentti on asennettavissa mihin tahansa Fiori-pohjaiseen sovellukseen.
Yhden komponentin ratkaisu tekee Metrixin käyttöönotosta erittäin yksinkertaisen. [12.]
Metrixin asennuttua se tarkistaa tietokannasta, onko sovellukseen kirjautuneella käyttä- jällä lupaa käyttää Inspectoria. Mikäli on, niin Inspector-nappi tulee näkyviin leijuvana punaisena nappina oikeassa alakulmassa tutkittavan sovelluksen päällä (kuva 15). Tä- män jälkeen inspector on käytettävissä ja täysin toimintakykyinen.
Itse datan visualisoiva dialogi toteutettiin Fiori-komponentin mukana tulevalla View.frag- ment-ratkaisulla. Se on käytännössä käynnissä olevasta sovelluksesta täysin erillinen XML-näkymä, jonka voi Inspector-napilla tuoda näkyviin. Siihen tuodaan yksinkertaisella QraphQL-kyselyllä data painetusta napista, ja data visualisoidaan helposti ymmärrettä- vään muotoon. Inspector-dialogi rakentuu osista, joita voidaan asiakkaan mukaan vaih- taa. Esimerkissä (kuva 15) tutkitusta elementistä näytetään millä laitteilla, missä varas- tossa (geolokaatiota käyttäen) ja milloin sitä on painettu.
3.3.4 Jatkokehitys
Kuten jo ideointi-osiossa (3.1) mainittiin, Metrixin toivottiin pystyvä uudelleen piirtämään painetut elementit sekä luomaan ns. “flow” toistuvista datakuvioista. Nämä asiat olisi ky- ettävä todistamaan toimiviksi.
Elementtien uudelleenpiirrossa käytämme hyväksi faktaa, että kaikki Fiori-elementit seu- raavat tiukasti Fiori design -periaatteita. On perusoletus, että Fiori-elementtejä ei muu- teta omilla tyyliluokilla. Jokainen “button” eli painike on aina samannäköinen riippumatta, missä sovelluksessa se on. Ainoa ulkonäköön vaikuttava tekijä on painikkeen teksti tai ikoni, joista molemmat pystytään Metrixillä saamaan talteen. Tämä pätee kaikkiin Fiori-
pohjaisiin elementteihin, joten meillä on nyt kyky piirtää mikä tahansa elementti käyttäen vakio-Fiori-elementtejä ja lisäämällä niihin keräämämme data.
Lopuksi tarvittiin vielä kyky luoda ja visualisoida “flow”. Tähän tarvitsemme aikaleiman jokaisesta kerätystä elementistä. Tämä lisättiin perusarvoksi jokaiseen datankeruu-funk- tioon. Itse flow’n tunnistamiseen vaadittiin varsin hienostunutta algoritmia. Sen toteutus ja toimipaikka oli tietokannan puolella. Käytännössä aikaleimaa käyttäen, algoritmi pyrki tunnistamaan ketjun elementtejä, joita painettiin aina samassa järjestyksessä, muodos- tivat flow’n.
Kun algoritmi tunnistaa flow’n, se tallentaa sen muodostavan elementtiketjun ja toistojen määrän. Tätä dataa käyttäen kyettiin luomaan erittäin alustava, mutta toimiva, proto- tyyppi flow-visualisoinnista. Kuvassa 16 näkyy 2 eri flow’ta punaisina nuolikaarina, joiden päällä näkyy, montako kertaa kyseinen flow toistui. Lisäksi havainnollistamme kykyä voida piirtää alkuperäinen elementti flow’n sisälle, kuten painikkeista “Hey1-2-3-4” näkyy.
Kyseiset painikkeet luotiin Metrixin testisovellukseen, ja niitä painamalla generoitiin ku- vassa (kuva 16) näkyvät flow’t.
Kuva 16. Ensimmäinen toimiva flow-prototyyppi.
Voidaan siis todeta, että kaikki Metrixiltä toivotut toiminnot on nyt todistettu toimiviksi ja mahdollisiksi rakentaa loppuun myöhemmissä iteraatioissa.
4 Yhteenveto
Tässä insinöörityössä olemme tutustuneet CastorIT:lle rakennnetun SAPUI5 Fiori -poh- jaisten sovellusten datan keräys- ja visualisointityökalun Metrixin suunnitteluun ja toteu- tukseen.
Mielestäni Metrixin käyttöliittymän toteutuksessa päästiin kaikkiin tavoitteisiin, ja se on nyt toimiva tuote. Metrixin käytössä siirryttiin jo testivaiheeseen, jossa se asennetaan useampaan CastorIT:n sisäiseen Fiori-sovellukseen ja sen toimintaa testataan.
Javascript ja SAPUI5 olivat jo tuttuja työkaluja aikaisemmista projekteista, joten niiden käyttö ei tuonut ongelmia. SAPUI5 onneksi tukee E66:n ominaisuuksia, joten funktiot pysyivät yksinkertaisempina. Tietokannan puolella Flow-algoritmi oli suurin haaste ja au- toin myös sen suunnittelussa ja koodaamisessa. Käyttöliittymäpuolella erillinen datan visualisointisovellus tuotti projektin keskivaiheilla suuria ongelmia. Siksi olen erityisen ylpeä Metrix-Inspectorin keksimisestä, ja sen toteutuksessa onnistumisesta. Olen myös tyytyväinen, että onnistuin todistamaan tulevien toimintojen, kuten Flow-ominaisuuden visuaalisen toiminnan.
Kaiken kaikkiaan olen erittäin tyytyväinen lopputulokseen. Metrix on kykenevä paljon laajempaan ja tarkempaan datan keruuseen, identifiointiin, analysointiin sekä visuali- sointiin, kuin mihin Google Analytics olisi vastaavissa sovelluksissa pystynyt.
Lähteet
