Sovellusintegraatio-ohjelmisto verkkoliiketoiminnan arkkitehtuurina

Veli-Pekka Kihniä

SOVELLUSINTEGRAATIO-OHJELMISTO VERKKOLIIKETOIMINNAN ARKKITEHTUURINA

Työn valvoja Jorma Tarhio

Työn ohjaaja Sami TähtinenSami Tähtinen

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ Tekijä: Veli-Pekka Kihniä

Työn nimi: Sovellusintegraatio-ohjelmisto verkkoliiketoiminnan arkkitehtuurina Päivämäärä: 4.9.2003

Sivumäärä: 82

Osasto: Tietotekniikka Professuuri: T-106

Pääaine: Ohjelmistojärjestelmät Työn valvoja: Jorma Tarhio Työn ohjaaja: Sami Tähtinen

Diplomityössä on tutkittu uusien verkkoliiketoimintaprotokollien ominaisuuksia ja sovellusintegraatio-ohjelmisto FRENDSrin soveltuvuutta verkkoliiketoiminnan alustaksi.

Työn ongelman- ja vaatimusmäärittelyosissa on tutkittu verkkoliiketoimintaa yleensä sekä eri verkkoliiketoimintaprotokollien ominaisuuksia, nykyistä käyttöä ja niiden toteutuksille asettamia vaatimuksia. Työssä kartoitetaan myös jo olemassaolevia verkkoliiketoimintaohjelmistoja ja niiden tarjoamia ominaisuuksia.

Työn toteutusosassa suunnitellaan ja osin myös toteutetaan ebXML- ja RosettaNet- protokollia tukeva verkkoliiketoiminta-alusta. Toteutuksessa käytetään FRENDS EAI Platformin valmiita ominaisuuksia ja komponentteja luomaan joukko uusia korkeamman tason komponentteja verkkoliiketoimintaprosessien toteutukseen.

Toteutuksesta käytetään nimeä ebFRENDS. EbFRENDS on PRENDS, joka aiempien ominaisuuksien lisäksi tarjoaa valmiin tuen verkkoliiketoimintaprotokollille ja työkalut niitä käyttävien liiketoiminta-prosessien toteuttamiselle.

Tavoitteena on luoda ohjelmisto, joka tukee uusia verkkoliiketoimintaprotokollia ja tarjoaa prosessien toteuttajille mahdollisimman yksinkertaisen rajapinnan näiden protokollien käyttöön. Toisena tavoitteena on myös mahdollistaa valmiiden prosessien tai niiden osien monistamisen ja siirtämisen muihin FRENDS-järjestelmiin sellaisenaan. PRENDS tarjoaa visuaalisen prosessimäärittelykielen ja suuren joukon rajapintoja eri tietoliikenneproto-kolliin ja ulkoisiin ohjelmistoihin. Lisäksi PRENDS mahdollistaa määriteltyjen prosessien monipuolisen ajastamisen ja parametroinnin sekä tarjoaa valmiit työkalut niiden valvontaan.

Avainsanat: Yritysten välinen sovellusintegraatio (B2Bi), verkkoliiketoiminta, ebXML, RosettaNet.

Esipuhe

Tämä diplomityö sai alkunsa PRENDS Technology Oy:n silloisen tuotekehitysjohtajan Seppo Vehmaksen ajatuksesta laajentaa FRENDS-ohjelmiston käyttöaluetta yritysten väliseen integraatioon. Haluankin kiittää Seppo Vehmasta sekä hänen seuraajaansa ja ohjaajaani Sami Tähtistä mielenkiintoisesta aiheesta ja mahdollisuudesta tehdä tämä työ PRENDS Technologyn palveluksessa. Ohjaajaani haluan kiittää myös työhöni kohdistuneesta kiinnostuksesta ja palautteesta.

Kiitokset myös muille työkavereilleni tuesta ja kiinnostuksesta. Erityiskiitokset Antti Toivaselle ja Ari Haapaniemelle, joiden kanssa vaihdoin paljon mielipiteitä ja kommentteja työtä tehdessäni. Heidän kommenttinsa olivat erittäin tärkeitä varsinkin työn toteutusosan suunnittelussa.

Työni valvojaa Jorma Tarhiota haluan kiittää positiivisesta suhtautumisesta työhöni sekä kiinnostuksesta sen etenemistä kohtaan. Kiitokset myös arvokkaista neuvoista ja kommenteista, joita hän on minulle työni aikana antanut.

Kiitokset myös kaikille ystävilleni, joiden kanssa olen työstäni keskustellut ja jotka ovat minua työni aikana tukeneet.

Lopuksi tahdon vielä kiittää vanhempiani kaikesta siitä tuesta, jonka olen heiltä opiskeluni aikana saanut.

Espoossa, 4.9. 2003

Veli-Pekka Kihniä

Esipuhe...3

Lyhenneluettelo...7

1. Johdanto...9

2. Ongelman määrittely... 11

2.1. Yleistä... 11

2.1.1. Verkkoliiketoiminta ja sovellusintegraatio... 11

2.1.2. Datatason integrointi... 12

2.1.3. Ohje 1 mistorajapintatason integraatio... 12

2.1.4. Portaal i -i n tegraati o... 13

2.1.5. Prosessi-integraatio... 13

2.2. Verkkoliiketoiminnan standardit...15

2.2.1. Yleistä... 15

2.2.2. EDI/OVT... 15

2.2.3. XMLZEDI... 17

2.2.4. RosettaNet... 18

2.2.5. EbXML...20

2.2.6. Yhteenveto...22

2.3. FRENDS EAI Platform...23

2.3.1. Taustaa...23

2.3.2. Nykyinen käyttö...23

2.3.3. Arkkitehtuuri...23

2.4. Työn tavoite...28

2.4.1. Tavoite...28

2.4.2. Rajauksia...28

3. Vaatimukset...29

3.1. Yleiset vaatimukset...29

3.1.1. Yleistä...29

3.1.2. Kerrosmalli...29

3.1.3. Yhteistoimintasopimukset...31

3.1.4. Suorituskykyvaatimukset...32

3.1.5. Virhetilanteiden käsittely...32

3.2. EbXML:n asettamat vaatimukset... 34

3.2.1. Yleistä...34

3.2.2. Viestinsiirtokerros...35

3.2.3. Liiketoimintakerros...37

3.3. RosettaNetin asettamat vaatimukst... 38

3.3.1. Yleistä...38

3.3.2. Viestinsiirtokerros...38

3.3.3. Liiketoimintakerros...42

3.3.4. Virheenkäsittely...43

3.3.5. Yhteenveto...43

4. Geneerinen malli...45

5. Toteutus...47

5.1. Aiempia toteutuksia...47

5.1.1. Yleistä...47

5.1.2. EbXML...47

5.1.3. RosettaNet...48

5.1.4. Muut protokollat...49

5.2. EbFRENDS...50

5.2.1. Kerrosjako...50

5.2.2. Yhteistoimintasopimukset...50

5.2.3. Viestirajapinta...51

5.2.4. Viestinsiirtokerros...51

5.2.5. Liiketoimintakerros...58

5.2.6. Järjestelmän ylläpitorutiinit...61

6. Analyysi... 62

6.1. Vaatimusten toteutuminen...62

6.1.1. Viestinsiirtokerros...62

6.1.2. Liiketoimintakerros...66

6.2. Komponenttikirjastopohjainen ohjelmistoalusta...68

6.3. Verkkoliiketoiminta-alustan edut ja haitat...69

6.4. Komponentti kirj astopohj ai sen toteutuksen edut ja haitat... 71

6.5. Esimerkki ratkaisu...72

6.5.1. Järjestelmän määrittely...72

6.5.2. Toteutus ebFRENDS:illä...73

6.5.3. Toteutus ilman ohjelmistoalustaa...76

7. Johtopäätökset...78

7.1. Työn tarkoitus...78

7.2. Ohjelmistoalustan hyödyt...78

7.3. PRENDS:in soveltuvuus verkkoliiketoiminnan alustaksi...79

7.4. Jatkokehitys ja-tutkimus...79

8. Lähdeluettelo 81

Lyhenneluettelo

ANSI American National Standards Institute, Yhdysvaltojen standardointi­

järjestö.

BPS Business Process Specification, liiketoimintaprosessin määrittely.

CPA Collaboration Protocol Agreement, verkkoliiketoiminnan osapuolten välinen yhteistoimintasopimus.

DOM Domain Object Model, XML-dokumenttien jäsennysmenetelmä.

DTD Document Type Definition, dokumentin muodon kuvauskieli.

EAI Enterprise Application Integration, sovellusintegraatio, organisaation ohjelmistojen yhdistäminen.

ebBuE ebFRENDS Business Engine, ebFRENDS:in liiketoimintakerroksen toteuttava osa.

ebMSH ebFRENDS Message Service Handler, ebFRENDS:in viestinsiirto- kerroksen toteuttava osa.

ebXML Electronic Business using XML. XML-pohjainen verkkoliiketoimintastandardi.

EDI Electronic Data Interchange, protokolla yritysten väliseen

tiedonsiirtoon. Suomeksi O VT, Ohjelmistojen Välinen Tiedonsiirto.

FTS PRENDS Transaction Server.

HTTP HyperText Transfer Protocol.

IETF Internet Engineering Task Force, Internetin standardointiorganisaatio.

IMAP Internet Message Access Protocol, sähköpostin siirtoprotokolla.

JDBC Java DataBase Connectivity, Java-pohjainen tietokantarajapinta.

MIME Multipurpose Internet Mail Extensions, tekstipohjainen dokumenttiformaatti.

MSH Message Service Handler, viestinkäsittelijä. Verkkoliiketoiminta- toteutuksen alin kerros.

MSI Message Service Interface, viestinkäsittelijän rajapinta sitä käyttäville komponenteille.

NoF Notification of Failure, RosettaNetin virheenkäsittelyprosessi.

ODBC Open DataBase Connectivity, tietokantarajapinta.

O VT Ohjelmistojen Välinen Tiedonsiirto, protokolla yritysten väliseen tiedon-siirtoon.

PIP Partner Interface Process, RosettaNetin määrittelemä yritysten välisen liiketoimintaprosessin kuvaus.

POP Post Office Protocol, sähköpostin siirtoprotokolla.

RNIF RosettaNet Implementation Framework, RosettaNet-standardi.

SAX Simple API for XML, XML-dokumenttien jäsennysmenetelmä.

SMTP Simple Mail Transfer Protocol, sähköpostin siirtoprotokolla.

SOAP Simple Object Access Protocol, XML -pohjainen etäkutsuprotokolla.

SSL Secure Socket Layer, TCP-yhteyksien salausmenetelmä.

ТРА W3C XML XSL XSLT

Trading Partner Agreement, verkkoliiketoiminnan osapuolten välinen yhteistoimintasopimus.

World Wide Web Consortium, Internetin standardoi nti organi saati o.

extensible Markup Language. Rakenteinen dokumenttiformaatti.

extensible Stylesheet Language. Dokumenttien muodon kuvauskieli.

XSL Transformation. Dokumenttien muuntaminen toiseen muotoon XSL-kuvausten avulla.

1. Johdanto

Yritykset ovat viime aikoina panostaneet tietojärjestelmiensä integrointiin.

Integroidussa järjestelmässä yhteen sen osaan syötetty uusi tai muokattu tieto siirtyy järjestelmän kaikkiin niihin osiin, jotka käyttävät tätä kyseistä tietoa. Toimiva integrointi mahdollistaa useasta ohjelmistosta koostuvan järjestelmän käsittelyn yhtenä isona kokonaisuutena. Seuraava askel järjestelmien integraatiossa on eri yritysten tai organisaatioden järjestelmien integroiminen. Tätä on itse asiassa jo pitkän aikaa tapahtunutkin EDI:n avulla. [1]

Organisaatioiden välisessä integraatiossa määritellään prosesseja, joita järjestelmät suorittavat keskenään. Vanha esimerkki tästä on EDI-laskutus, jossa myyjä toimittaa laskun sähköisesti ostajalle. Varsinkin, jos kauppasuhde on pysyvä, voidaan tämä prosessi automatisoida molemmissa päissä. Uudet verkkoliiketoimintaprotokollat ebXML ja RosettaNet pyrkivät standardoimaan organisaatioiden välisiä prosesseja ja helpottamaan organisaatioiden välistä integraatiota. Nämä protokollat pyrkivät laajentamaan ja monipuolistamaan organisaatioiden välisiä prosesseja monimutkaisempiin tapahtumaketjuihin. Jo nyt RosettaNetiä käytetään esimerkiksi tilausten automatisointiin ja koko toimitusketjun yhteisten tulevaisuusennusteiden laatimiseen. [8]

EbXML ja RosettaNet ovat kuitenkin monimutkaisia ja työläitä toteutettavia.

Toteutuksen avuksi on jo olemassa erilaisia ohjelmointikomponentteja, jotka hoitavat itse viestien välityksen ohjelmoijan puolesta. Tämä helpottaa toteutusta huomattavasti, mutta ratkaisee vain osan ongelmista. Jotta verkkoliiketoimintaratkaisusta olisi mitään hyötyä, on se saatava integroitua yrityksen muihin järjestelmiin. Ilman kunnollista integraatiota, ratkaisu ei pääse käsiksi tarvitsemiinsa tietoihin tai vaatii käyttäjän apua joidenkin prosessien suorittamiseen.

Jotta prosessien automatisointi maksaisi itsensä takaisin, on automatisoinnin korvattava tarpeeksi monta käsin tehtävää operaatiota. Joissain tapauksissa tämä kriteeri täyttyy yhden prosessin automatisoinnilla. Esimerkkinä tällaisesta prosessista voisi olla suurivolyyminen laskutus. Joskus taas on automatisoitava monta erilaista prosessia, jolloin toteutuksen kustannuksiin vaikuttaa suuresti yhden prosessin toteutuksen hinta.

Toinen ongelma on prosessien muokattavuus. Jos järjestelmän joku osa tai prosessikuvaus itse muuttuu, on prosessia voitava muokata nopeasti uusien vaatimusten mukaiseksi. Jos jokainen prosessi ohjelmoidaan alusta alkaen, on hinta melko suuri ja muutokset vaativat ohjelmakoodin muokkausta. Tällaisessa tapauksessa on tarve ohjelmistolle, jonka avulla prosessit on nopea toteuttaa ja jonka avulla niitä on helppo muokata.

Jo sisäisten järjestelmien integrointi on isommissa organisaatioissa monimutkainen ongelma, varsinkin ilman hyviä työkaluja. FRENDS EAI Platform on integraatio- ohjelmisto, joka tarjoaa työkalut järjestelmäintegraatioon. Sen avulla voidaan määritellä ja toteuttaa integraatioprosessit nopeasti erilaisten järjestelmien välillä. Prosessien määrittely tapahtuu graafisesti ilman ohjelmointia ja prosesseja voidaan muokata jopa järjestelmän ollessa toiminnassa. PRENDS sisältää suuren joukon erilaisia valmiita komponentteja ja rajapintoja erilaisiin ohjelmistoihin kytkeytymiseksi. Jos PRENDS

integroituu kaikkiin yrityksen järjestelmiin, on järkevää, että PRENDS on myös se piste, jonka kautta integroidutaan myös muiden organisaatioiden järjestelmiin.

Työn tarkoitus on laajentaa PRENDS EAI Platformia siten, että se tukee myös RosettaNet- ja ebXML-protokollia ja mahdollistaa myös yritysten välisten prosessien toteutuksen. Tätä varten on selvitettävä kuinka protokollien viestiliikenne voidaan toteuttaa FRENDS:illä ja kuinka yritysten väliset prosessit voidaan määritellä FRENDS:illä. Jos nämä ongelmat saadaan ratkaistua, voidaan FRENDS:in avulla toteuttaa organisaatioiden välisiä prosesseja, jotka integroituvat suoraan yrityksen muihin järjestelmiin. PRENDS:istä on siis tarkoitus luoda ohjelmistoalusta myös yritysten väliseen integraatioon. Tästä syystä tutkitaan myös tällaisen ohjelmistoalustan vaatimuksia, sen hyötyjä ja haittoja.

2. Ongelman määrittely

2.1. Yleistä

2.1.1. Verkkoliiketoiminta ja sovellusintegraatio

Verkkoliiketoiminnalla tarkoitetaan yritysten välistä liiketoimintaa, josta osa, yleensä tilaukset ja laskutus hoidetaan sähköisesti. Kauppatavaran ollessa sähköisesti siirrettävää, myös toimitus voi tapahtua sähköisesti. Sähköinen liiketoiminta ei siis tässä tapauksessa tarkoita esimerkiksi yksityishenkilöiden käyttämiä yritysten verkkopalveluita ja -kauppoja.

Sovellusintegraatiolla (EAI, Enterprise Application Integration.) tarkoitetaan eri ohjelmistojen yhdistämistä yhdeksi suuremmaksi kokonaisuudeksi. Perinteisesti sovellusintegraatiolla on tarkoitettu yrityksen tai konsernin sisäisten tietojärjestelmien yhdistämistä. Nykyisin sovellusintegraatioita on alettu rakentaa myös eri yritysten järjestelmien välille. Tästä käytetään yleensä nimitystä "B2B Application Integration", joka voidaan suomentaa yritysten väliseksi sovellusintegraatioksi.

' c= Л .2

g

§ jc

V) ro

Ф V O

(

Method

■ч

_____' Z---

V

Application hier fact?

ч

r~ ~1

Points of Integration

ч

Interaction

Kuva 1. Sovellusintegraation ulottuvuudet. [1]

Data-, sovellusrajapinta- ja metoditason integraatiot ovat yrityksen sisäisten järjestelmien integraatiotapoja. Prosessi- ja portaali-integraatio ovat molemmat

yritysten välisen integraation malleja.

Jotta yritysten välisten järjestelmien integraatio onnistuisi ja tuottaisi yritykselle lisäarvoa, on jokaisen yrityksen ensin integroitava sisäiset järjestelmänsä yhdeksi isoksi kokonaisuudeksi. Tällön esimerkiksi yrityksen toiminnanohjaus-, laskutus- ja varastojärjestelmät toimivat yhtenäisten tietojen varassa. Yritysten välisessä

integraatiossa on yleensä kyse automaattisesti käsiteltävistä laskuista, tilauksista, tilausvahvistuksista jne, joiden virheellinen käsittely voi johtaa korvauksiin tai jopa oikeudellisiin seurauksiin. Näin ollen vain järjestelmä, jolla on käytössään kaikki tarvittavat ajantasaiset tiedot, voidaan integroida muiden yritysten järjestelmiin.

Kahden ohjelmiston integrointi on yleensä melko suoraviivainen operaatio. Kun ohjelmistojen määrä kasvaa, pitää kaikki ohjelmistot yleensä integroida kaikkiin muihin ohjelmistoihin. Tällaisen järjestelmän monimutkaisuus kasvaa hyvin nopeasti ohjelmistojen määrän kasvaessa. Lopulta jo pelkkä järjestelmän hallittavuus, muutoksista ja uusien osien lisäämisestä puhumattakaan, käy mahdottomaksi. Tästä johtuen onkin tärkeää jo mahdollisimman aikaisessa vaiheessa turvautua kunnolliseen integraatio-ohjelmistoon. Monipuolisen integraatio-ohjelmiston käyttöönotto voi olla selvästikin raskaampaa kuin kevyt räätälöity ratkaisu kahden ohjelmiston yhdistämiseen. Ohjelmia lisättäessä valmiiksi käyttönotettu integraatio-ohjelmisto kuitenkin helpottaa toteuttajien taakkaa suuresti.

2.1.2. Datatason integrointi

Datatason integroinnissa eri ohjelmistojen tietokantojen yhtenevät osat synkronoidaan reaaliajassa tai tasaisin väliajoin. Kahden kohtuullisen staattista dataa sisältävän ohjelmiston integrointi datatasolla on yleensä suoraviivaista ja melko yksinkertaista.

Jos ohjelmistoja on useampia tai jos ohjelmistot useinkin päivittävät esimerkiksi saman asiakkaan tietoja omissa tietokannoissaan, tarvitaan paljon sääntöjä miten eri tilanteissa toimitaan. Kaikkien sääntöjen toteuttaminen ja kunnollinen usean tietokannan synkronointi kasvaa hyvin nopeasti erittäin monimutkaiseksi järjestelmäksi. Tällainen järjestelmä voi toimia hyvinkin, mutta sen eri osien muuttaminen tai uusien osien

lisääminen vaatii suuren määrän työtä.

Ohjelmistojen tietokantoihin pystytään yleensä kytkeytymään joko ODBC- tai JDBC- rajapintojen kautta. Datatason integroinnissa on myös otettava huomioon integroitavien ohjelmistojen sisäiset vaatimukset. Ohjelmistoilla voi olla hyvinkin monimutkaisia sisäisiä esitysmalleja ja eheysvaatimuksia. Varsinkin dataa syötettäessä on tiedettävä tarkkaan mitä muutoksia on tehtävä, jotta ohjelmiston eheys säilyy. Tunnetusti esim.

SAP/R3-ohjelmiston tietokantarakenne on niin monimutkainen, ettei sen tietokantaan käytännössä voi syöttää dataa suoraan tietokantarajapinnan kautta rikkomatta eheysvaatimuksia.

2.1.3. Ohjelmistorajapintatason integraatio

Ohjelmistorajapintasolla integroitaviin ohjelmistoihin kytkeydytään niiden tarjoamien rajapintojen kautta. Nämä rajapinnat tarjoavat yleensä pääsyn ainakin osaan ohjelmiston sisältämästä datasta. Ohjelmistorajapinnat huolehtivat, että data syötetään kaikkia eheysvaatimuksia ja synkronointeja noudattaen. Toisaalta jokaisen ohjelmiston tarjoama rajapinta on yleensä ainutlaatuinen, joten jokaista ohjelmistoa varten on luotava konnektori.

Kuvassa 1 erotellaan sovellusrajapintatason ja metoditason integraatio. Yleensä molemmilla tasoilla käytetään kuitenkin samaa ohjelmointirajapintaa. Metoditason integraatiossa integroidaan liiketoimintaprosesseja pelkän datan jakamisen lisäksi.

Tällöin integroitujen ohjelmistojen muodostaman järjestelmän liiketoimintaprosessit voivat koostua useiden eri ohjelmistojen sisäisistä prosesseista. Käytännössä ohelmistorajapintojen avulla tehdyt integraatiot ovat sekoitus metodi- ja sovellusrajapintatason integraatioita.

2.1.4. Portaali-integraatio

Portaali-integraatiossa luodaan yksi rajapinta, jonka kautta eri yritykset tarjoavat tietoa ja palveluita. Portaali-integraation avulla voidaan myös integoida sisäisiä järjestelmiä.

Tällöin jokaiseen integroitavaan ohjelmistoon luodaan rajapinta, jonka kautta portaalista pääsee käyttämään ohjelmiston palveluita, yksinkertaisimmillaan portaali voi olla käyttöliittymä joka taijoaa yhtäaikaa tietoa kahdesta eri tietokannasta ja mahdollisesti yhdistelee tietoja samaan näkymäään.

Portaali voi tarjota palveluita Internetissä kaikille ihmisille tai rajatussa verkossa vain rajatulle käyttäjäjoukolle, esimerkiksi portaalissa mukana olevlle yrityksille. Eri toimijat voivat rakentaa omia prosesseja, jotka käyttävät muiden toimijoiden portaalissa tarjoamia palveluita. Tällainen integraatio on toimivaa, mutta hieman yksipuolista.

2.1.5. Prosessi-integraatio

Internet

Public processes Private

processes Public

processes

Private processes

Back-end Back-end

Kuva 2. Yritystenvälinen prosessi-integraatio. [2]

Prosessi -integraali o luo korkean tason prosesseja eri toimijoiden välille. Tällainen prosessi koostuu käytännössä järjestelmien välisistä viesteistä ja järjestelmien sisäisistä prosesseista. Eri järjestelmät kertovat tarjoavansa tietynlaisia palveluita, joita on käytettävä tietyllä tavalla. Sisäisten prosessien toteutukseen ei tällä tasolla oteta kantaa.

Niiden on vain tuotettava tiettyyn syötteeseen tietynlainen vastaus.

Yksinkertainen esimerkki prosessi-integraatiosta on automaattinen ostotapahtuma, jossa järjestelmä A lähettää B:lle tilauksen, В vastaa tilausvahvistuksella, jonka A kuittaa oikeaksi. Tässä järjestelmien välinen prosessi koostuu kolmesta viestistä, joiden sisältö ja niiden vaatimat korkean tason toimenpiteet on määritelty yhteisesti järjestelmien välille (esim. tilaukseen on vastattava tietynmuotoisella vahvistuksella). Järjestelmien sisäisiä prosesseja ei määritellä sen tarkemmin, niiden on vain tuotettava tiettyyn syötteeseen tietynlainen vastaus.

Prosessiorientoituneen integraation avulla voidaan luoda suuriakin yhteistoimintaverkostoja, joissa prosessit koskettavat useita toimijoita. Varsinkin teollisuustuotannossa, jossa prosesseja halutaan nopeuttaa ja varastojen läpimenoaikaa pienentää, voidaan hyvin suunnitellulla integraatiototeutuksella saada aikaan hyvinkin suuria säästöjä.

2.2. Verkkoliiketoiminnan standardit

2.2.1. Yleistä

Ensimmäiset yritysten väliset sovellusintegraatioratkaisut olivat, ja hyvin suurelta osin edelleen ovat, osapuolten keskenään määrittelemiä ja sopimia. Ratkaisuissa sovittiin tapauskohtaisesti käytetyt siirtoverkot ja -protokollat, viestien rakenteet ja niiden sisällöt. Tästä seurasi luonnollisesti, että eri toteutukset olivat yhteensopivia erittäin harvoilla osa-alueilla. Verkkoliiketoiminnan yleistyessä syntyikin maa- ja alakohtaisia standardeja, jotka olivat usein suurten toimijoiden omiin tarpeisiinsa kehittämiä.

Nykyisin verkkoliiketoimintaan on olemassa useampia standardeja, joista osa hyvin on alakohtaisia, osa taas jopa täysin alariippumattomia. Laajimmalle levinnyt standardi on EDI/OVT, jonka korvaajaksi on pyritty kehittämään useitakin standardeja. Tällä hetkellä pisimmälle edennyt kilpailijastandardi on RosettaNet, XML-pohjainen standardi, joka määrittelee yritysten väliset rajapinnat sekä joitain liiketoimintaprosesseja. Toinen suuri kilpailija ebXML on yhä pilottivaiheessa.

Protokollasta riippumatta jokainen verkkoliiketoimintaprosessi on pohjimmiltaan vain jonkinlaisen viestikoreografian määrittely. Viestikoreografia määrittelee, mitä viestejä kukin osapuoli voi missäkin liiketoimintaprosessin vaiheessa lähettää. Yksinkertaisen tilausprosessin koreografia koostuu tilausviestistä ja sen vastauksesta. Vastaus voi olla joko tilauksen vahvistus tai hylkäys.

2.2.2. EDI / OVT

SOVELLUKSET

. S OVE LLU S LI ! T ÄNTÄ HALLINTA .ESITYSTAPAMUUNNIN

KUUETUSLIITÄNTÄ

KULJETUSPALVELUT

Kuva 3. EDI/OVT -järjestelmämalli. [3]

Tämänhetkinen sähköisen kaupankäynnin vallitseva standardi on EDI, Electronic Data Interchange, josta Suomessa käytetään myös nimitystä OVT, Ohjelmistojen Välinen Tiedonsiirto. EDI koostuu kahdesta rinnakkaisesta standardista (X12, ANSI:n standardi ja EDIFACT, Yhdistyneiden Kansakuntien ajama standardi). Nämä standardit

määrittelevät menetelmät, joilla yritykset voivat suorittaa transaktioita sähköisesti.

EDI suunniteltiin alunperin korvaamaan transaktioihin liittyvät paperiset dokumentit.

Yleisin EDI:n käyttö lienee nykyisin sähköinen lasku. EDI:n avulla on toteutettu myös

varsinaisia integraatioratkaisuja. EDI ei kuitenkaan määrittele tällaisia ratkaisuja, joten ne ovat käytännössä toimijoiden luomia epästandardeja ratkaisuja, jotka käyttävät standardoitua viestiformaattia, EDI:ä, ja mahdollisesti EDI-viestien välityspalveluita.

EDI:n piti olla standardi, jolla yritykset voivat helposti siirtää tietoa keskenään. Se on kuitenkin osoittautunut monimutkaiseksi ja kalliiksi järjestelmäksi, jota Yhdysvaltojen luokittelussa pienillä yrityksillä (suomalaisessa luokittelussa kokoluokaksi ei ole varaa toteuttaa. EDI pyrkii määrittelemään hyvin tarkasti viestien kentät ja niiden sisällöt, jolloin yritys tarvitsee vain yhden järjestelmän, joka muuntaa viestien sisällön yrityksen sisäiseen muotoon. Tarkoitus oli, että kerran toteutettua EDI-ratkaisua voidaan helposti monistaa tai laajentaa.

Standardi vaatii, että viestin data on muokattava täyttämään standardin vaatimukset.

Määrittelyt kuitenkin osoittautuivat liian tiukoiksi, jolloin toimijat, joiden tarpeisiin EDI ei suoraan sopinut, kehittivät omia tapoja käyttää viestejä. Näistä syistä johtuen EDI-toteutusta luotaessa yritys joutui hyvin tarkasti miettimään kuinka tarvittava data muokataan viestiin sopivaksi. Tämä puolestaan johti siihen, että käytännössä kaikki itsenäisesti luodut toteutukset olivat yhteensopimattomia ja jokaisen uuden yhteistyökumppanin kohdalla oli sovittava viestien sisältö ja toteutettava muunnos tästä uudesta muodosta yrityksen sisäiseen esitysmuotoon. [3] Yhdysvaltojen oma standardimäärittely (X.12) aiheuttaa vielä lisäongelmia yrityksille, jotka toimivat sekä amerikkalaisten että muualla toimivien yritysten kanssa.

Eri maiden kansalliset järjestöt ovat standardoineet EDI:n käyttöä vaihtelevalla innolla ja menestyksellä. Suomessa on standardoitu EDI/OVT sanakirja, joka määrittelee millaista tietoa erilaiset kentät sisältävät ja miten ne pitää tulkita. Lisäksi Suomessa on standardoitu mm. OVT-verkkolasku. Suomessa yritykset ovat pitäytyneet OVT- standardissa melko hyvin, mistä johtuen yhteensopivuusongelmia on ollut kansainvälistä tasoa vähemmän. EDI:n käyttö onkin Suomessa kansainvälisesti verrattuna laajaa ja pienemmätkin yritykset ovat pystyneet hyötymään siitä. Suomessa 61 % EDI:ä käyttävistä yrityksistä on alle 250:n henkilön yrityksiä, vaikka yleinen käsitys on, ettei EDI sovellu (Yhdysvaltain skaalassa) pienille yrityksille. [4]

Ensimmäiset EDI-toteutukset olivat tähtimuotoisia verkkoja, joissa iso toimija siirsi prosessinsa sähköisiksi ja vaati pienempiä kumppaneitaan tekemään samoin. Näissä toteutuksissa tähden keskellä oleva yritys määräsi toimintatavat. Tästä johtuen tämä yritys pystyi käyttämään samaa ohjelmistoa viestien tulkintaan parhaimmillaan kaikkien kumppaneidensa kanssa. Tämä oli luonnollisesti hyvin kustannustehokasta, sillä kerran tehtyä toteutusta voitiin käyttää useiden kumppanien kanssa. Pienet yhteistyökumppanit kuitenkin joutuivat investoimaan järjestelmään, joka pystyi keskustelemaan vain yhden yhteistyökumppanin kanssa. Jos yritys halusi käyttää EDI:ä muidenkin yritysten kanssa, joutui se yleensä luomaan uuden järjestelmän tätä varten.

Tästä johtuen pienemmillä yrityksillä EDI:n käyttöönoton aiheuttamien kustannusten takaisinmaksuaika saattoi olla useita vuosia. Myöhemmin EDI:n käytön laajetessa tähdet yhdistyivät isommiksi verkoiksi. Tähtien erilaisten toimintatapojen yhdistäminen saattoi olla hyvinkin pitkä ja kallis operaatio, sillä jokainen toimija tahtoi luonnollisesti käyttää olemassaolevia toteutuksiaan.

EDI-viestiliikenne tapahtuu perinteisesti EDI-reitittäjän tarjoamassa lisäarvoverkossa (VAN, Value Added Network). Verkko on yleensä tähti muotoinen, jossa jokaisella toimijalla on yhteys ainoastaan reitittäjään. Reitittäjä huolehtii viestien toimittamisesta oikealle vastaanottajalle ja perii palvelusta maksun esim. lähetettyjen viestien määrän mukaan. Suurilla yrityksillä summat muodostuvat vuositasolla huomattaviksi. Tämä onkin yksi syy korvata jo toteutettu ja toimiva EDI-järjestelmä jollain uudempaan standardiin pohjautuvalla järjestelmällä. Uudemmat pienen mittakaavan toteutukset pyrkivätkin käyttämään Internetiä suoraan tiedonsiirton, jolloin osapuolten ei tarvitse maksaa reitittäjälle tiedonsiirrosta. Jos EDI-järjestelmä on hyvin integroitu yrityksen muihin tietojärjestelmiin, ei sitä useimmissa tapauksissa kuitenkaan kannata korvata.

Suuri osa EDI-toteutuksista vain siirtää laskuja toimijoiden välillä. Laskujen siirto on kuitenkin vain yksi liiketoimintaprosessi yritysten välillä. EDI:llä voidaan toteuttaa muitakin prosesseja, mutta uudemmat standardit tarjoavat helpomman ja halvemman tavan toteuttaa ne. Onkin todennäköistä, että uusien standardien käyttöönotto alkaa jostain muualta kuin EDI:n käyttöaloilta. Luultavaa onkin, että aluksi uudet standardit toimivat EDI:n rinnalla tarjoten palveluita, joita EDI ei pysty tarjoamaan. EDI:n korvaamista vastaan puhuu myös vanha viisaus, jonka mukaan toimivaa järjestelmää ei pidä korjata.

2.2.3. XML/EDI

XMLZEDI arkkitehtuuri pyrkii siirtämään EDI:n toiminnallisuuden "XML-maailmaan".

Se pyrkii korjaamaan EDI:ssä vuosien aikana todetut ongelmat XML:n, viestikuvausten ja komponenttivarastojen avulla.

Komponenttivarastot sisältävät mm. viestipohjia, sanakirjoja ja toimijakuvauksia.

Viestipohjat yhdessä sanakirjojen kanssa kertovat mitä viestin tulee sisältää ja miten sisältö on tulkittava missäkin tapauksessa. Nämä mahdollistavat yleiskäyttöisten XML- työkalujen käytön viestien tulkinnassa ja muokkauksessa.

Sanakirjoja voidaan luoda ja julkaista hyvinkin vapaasti, jolloin on toki vaarana, että jälleen syntyy pieniä ryhmiä, jotka kaikki käyttävät erilaisia viestejä. XML kuitenkin mahdollistaa konversion määrittelyn eri sanakirjojen välille, ainakin jos vain eri formaattien tietosisällöt vastaavat toisiaan. Konversioihin on olemassa valmiita työkaluja, joiden käyttöönotto on huomattavasti halvempaa kuin perinteisten EDI- muuntimien ja -reitittimien toteuttaminen.

XML:n käyttö viestiformaattina tarjoaa mahdollisuuden käyttää standardityökaluja viestien rakentamiseen, validointiin sekä muunnoksiin. Dokumenttityyppimäärittely (Document Type Definition, DTD), määrittelee yksiselitteisesti mitä kenttiä viestissä on ja mitä kentät voivat sisältää. DTD-määrittelyiden avulla voidaan määritellä myös automaattiset muunnokset viestityyppien välillä. Näin eri toimijat voivat määritellä sisäisesti miten viesti muutetaan sisäiseen formaattiin ja päinvastoin. DTD- määrittelyiden lisäksi määritellään viestien käsittelysäännöt, jotka määräävät mitä viestin sisältämälle datalle tulee tehdä.

XML mahdollistaa WWW-pohjaisten käyttöliittymien helpon toteutuksen. EDI:ä käytettäessä käyttöliittymien on osattava purkaa viesti ja myös tietää mitä kenttien

sisällöt tarkoittavat, jotta viestit voidaan esittää ymmärrettävässä muodossa. XML:n avulla viesti voi itse sisältää tietoa kenttien tulkinnasta. Lisäksi uusimmat WWW- selaimet pystyvät käsittelemään XML-dokumentteja sellaisenaan.

XML/EDI on huomattavasti suppeampi standardi kuin RosettaNet tai ebXML ja näyttäisikin jääneen näiden varjoon. XML/EDI voisi korvata EDI:n, mutta koska

"toimivaa järjestelmää ei pidä korjata", tätä ei luultavasti tule tapahtumaan.

Periaatteessa uudet toimijat voisivat ottaa XML/EDI:n keskenään käyttöön EDI:n sijasta. Todennäköisimmin tällaisessa toteutuksessa kuitenkin päädytään joko RosettaNetiin tai ebXML:ään, sillä kumpikin voi toteuttaa XML/EDI:n tarjoaman toiminnallisuuden. Lisäksi sekä RosettaNet että ebXML tarjoavat mahdollisuuden laajentaa toteutuksen toiminnallisuutta prosesseihin, joita XML/EDI ei tarjoa.

2.2.4. RosettaNet

RosettaNet on sekä standardin että organisaation nimi. Organisaatio on 1998 perustettu, nykyään jo yli 400 yrityksen muodostama voittoa tavoittelematon yhtymä, jonka tarkoituksena on kehittää RosettaNet standardia sekä edistää sen käyttöönottoa.

Organisaatioon kuuluu lähinnä korkean teknologian yrityksiä tuotantoketjun kaikista vaiheista.

Telephone Business Process

DIALOG Grammar

Words Alphabet

Sound

human-to-human business exchange

eCom Application eBusiness Process

PIP

Framework Dictionary

XML Internet

server-to-server eBusiness exchange

73

О

z

rort

Kuva 4. RosettaNetin ”protokollapino". [5]

RosettaNetin tiedonvälitys tapahtuu Internetissä ja perustuu avoimiin Internet-ja XML- standardeihin. Näin päästään eroon EDIn lisäarvoverkoista, joiden käyttökustannukset voivat olla huomattaviakin.

RNIF[2] (RosettaNet Implementation Framework), RosettaNet standardi, määrittelee kahden toimijan välisen rajapinnan (Partner Interface). Lisäksi on määritelty useita

toimijoiden välisiä prosesseja eli PIPiejä (Partner Interface Process). PIP on järjestelmien välinen XML-pohjainen dialogi, joka määrittelee viestien rakenteen,

sisällön ja sanaston sekä liiketoimintaprosessin ja sen viesti koreografi an.

RosettaNet pyrkii edistämään standardoitujen PIP:ien käyttöä, jotta itsenäiset toteutukset olisivat keskenään yhteensopivia. PIP määrittelee mitä viestit sisältävät, mitä sisältö tarkoittaa ja miten viesteihin tulee vastata. Se ei kuitenkaan määrittele mitä viestin sisältämälle tiedolle tulee tehdä. Tästä johtuen yksittäinen RosettaNet-toteutus koostuu paitsi RosettaNetin määrittelemien viestien siirto- ja käsittelytoiminnallisuuksien lisäksi liittymistä yrityksen taustajärjestelmiin ja liiketoimintaprosesseihin. Tästä johtuen käytännössä jokainen toteutus on erilainen ja uusien prosessien lisääminen vaatii työtä, jonka määrä riippuu integroitavien järjestelmien määrästä ja rajapinnoista. Toisaalta yhteensopivuutta korostavan arkkitehtuurin ansiosta kerran toteutettu PIP pitäisi olla mahdollista ottaa käyttöön muiden partnereiden kanssa hyvin vähällä vaivalla.

RosettaNetin käyttöönotto on lähtenyt korkean teknologian isoista laitevalmistajista, jotka ovat voineet vaatia pienemmiltä kumppaneiltaan (lähinnä alihankkijoiltaan) RosettaNet-pohjaisia prosesseja. Tästä johtuen RosettaNet on aluksi levinnyt paikallisina tähtimuotoisina yhteistyöverkostoina. Tulevaisuudessa näiden yksittäisten tähtiverkostojen odotetaan yhtyvän toisiinsa yhteisten alihankkijoiden kautta.

RosettaNetin käyttöönotto on siis ollut hyvin samantapaista kuin EDIdlä aikanaan.

Nokia on ollut yksi ensimmäisistä isoista RosettaNet-toimijoista. Nokian yhteistyöverkko on ollut käytössä vuoden 2001 lokakuusta alkaen. Verkosto mahdollistaa yhteisten tulevaisuusennusteiden tekemisen sekä tilausten automatisoinnin. Yhdessä nämä mahdollistavat hyvin tehokkaan (ainakin Nokian kannalta) Juuri Ajoissa (JIT, Just In Time) -toimituksen, jonka avulla komponentteja ei tarvitse ostaa varastoon vaan ne menevät "suoraan kontista liukuhihnalle".[8]

2.2.5. EbXML

Request Business Details

Build Local System Implementation Register Implementation Details

Register COMPANY A Profile XML г

Scenarioy^

I Business Profile!^

COMPANYÄ

eb XMI.

Resist rv

ÉÉf3 „.--J

ViV

COMPANY В ú ■

ebXML compliant system

Хг/va 5. Kahden ebXML-îoimijan välinen korkean tason interaktio. [6]

EbXML on UN/CEFACT:in (United Nations Centre for Trade Facilitation and Electronic Business) ja OASIS:in (Organization for the Advancement of Structured Information Standards) määrittelemä joukko uusia verkkoli i ke toi mi ntastandardej a.

EbXML koostuu OASIS:in määrittelemistä viestiliikenne-, rekisteri- yhteistoimintaprofiilistandardeista sekä UN/CEFACT:in liiketoimintaprosessi- ja ydinkomponenttimäärittelyistä. Standardeista on jo olemassa julkaistut versiot mutta UN/CEFACT:in määrittelyt ovat edelleen työn alla.

EbXML määrittelee:

• Viestiliikenteen,

• Standardoidun tavan kuvata liiketoimintaprosesseja (BPS, Business Process Specification),

• Toiminnallisuuskuvaukset (CPP, Collaboration Protocol Profile) ja

• Rekisterit, joihin voi tallentaa liiketoimintaprosessi- ja toiminnallisuuskuvauksia sekä etsiä ko. kuvauksia.

EbXML:n kehityksessä eri työryhmät vastaavat eri osa-alueista. Tällä on pyritty saavuttamaan esim. liiketoimintaprosessien ja niiden kuvausten riippumattomuus viestiliikennemäärittelyistä. Eri osien erottaminen omiksi kokonaisuuksikseen mahdollistaa toteutusten helpomman uudelleenkäytön ja muokkaamisen.

EbXML-toimijat julkaisevat toiminnallisuuskuvauksensa rekistereissä, joista kaikki toimijat voivat etsiä muiden toimijoiden toiminnallisuuskuvauksia. Rekisteristä voidaan etsiä muita ebXML-toimijoita esim. toimialan tai toteutettujen prosessien perusteella.

Rekisterin avulla voidaan siis etsiä uusia kumppaneita ja luoda valmis ebXML toteutus.

Yhteistoiminnan aloitus vaatii kuitenkin myös kahdenkeskisen sopimuksen, jossa vahvistetaan käytetyt prosessit ja tietoliikenneparametrit.

Retrieval of Profiles &

new/updated ebXML Models

Retrieval of Profiles &

new/updated ebXML Models

Retrieval of ebXML Models and Profiles

Payload

Collaboration Protocol Agreement (CPA) Register

Collaboration Protocol Profile

Colla boration Protocol Profile

1CPP)

Registry Service Interface

Implementors Business Service

I nterface

Business Application Business Service

Interface

Model to XML Conversion

Business Process and Information Models (Compliant to the ebXML Meta Model)

Kuva 6. EbXML:n funktionaalinen kuvaus. [6]

RosettaNetin ja ebXMLm sanotaan usein olevan kilpailevia standardeja, mutta joidenkin asiantuntijoiden mielestä niissä on hyvin vähän leikkauskohtia. EbXML

tarjoaa infrastruktuurin, jonka avulla toimijat voivat löytää toisensa ja integroida prosessinsa. RosettaNetin suurin sisältö puolestaan ovat juuri liiketoimintaprosessien määrittelyt. EbXML siis huolehtii siitä, kuinka myyjään saadaan yhteys ja RosettaNet siitä, kuinka myyjältä tilataan jotain.[7] Eräs tulevaisuuden skenaario onkin, että ebXML toteutukset tulevat aluksi soveltuvilta osin käyttämään RosettaNetin määrittelemiä PIP:ejä ja erilliset työryhmät luovat uusia PIP:ejä muillekin toimialoille.

EbXML:n viestiliikenne tapahtuu Internetissä kuten RosettaNetinkin. RosettaNet käyttää tiedonsiirtoon oletusarvoisesti HTTP-protokollaa ja määrittelee myös SMTP- protokollan käytön. EbXML käyttää SOAP (Simple Object Access Protocol) - protokollaa HTTPm tai SMTP:n päällä. Toisaalta se sallii myös muiden protokollien käytön SOAP-viestien siirtoon. Tällöin osapuolten on itse määriteltävä kuinka valittua protokollaa käytetään.

EbXML on hyvin geneerinen standardi. Se määrittelee tiukasti vain viestiliikenteen ja rekisterit. Muut määrittelyt ovat vain suosituksia. ebXML sallii esimerkiksi EDI/OVT- viestien käyttämisen datan siirrossa, kunhan vain viestit kulkevat ebXML- viestiliikenteen mukaisesti. Tällainen geneerisyys mahdollistaa toisaalta aina "ylimenon siitä, missä aita on matalin", mutta toisaalta se myös vaatii aina osapuolten välisen sopimuksen käytetyistä sanomista. Jotta saavutettaisiin todellinen prosessitason yhteensopivuus toteutusten välillä, vaaditaan kansainvälisesti hyväksyttyjä standardeja sekä prosesseista että viesteistä.

2.2.6. Yhteenveto

EDI on edelleen vallitseva standardi. Sen käyttö on niin laajaa, että yritykset kehittävät vieläkin uusia EDI toteuksia. EDI on erittäin kriittisellä paikalla monissa yrityksissä, Suomessa useiden yritysten päivittäinen toiminta on hyvin riippuvainen EDI:stä. Koska

"toimivaa järjestelmää ei pidä korjata", ei EDI tule poistumaan vielä pitkään aikaan.

RosettaNet on valmis standardi ja jo käytössä korkean teknologian alalla. RosettaNetin standardi määrittelee oikeastaan vain viestiliikenteen. Organisaation tärkein saavutus on kuitenkin hyvin suunnitellut ja standardoidut liiketoimintaprosessit. Prosesseja on suunniteltu toimialakohtaisiksi eikä kaikenkattaviksi kuten EDLssä. Tähän mennessä prosesseja on määritelty vain korkean teknologian tuotantoketjun eri vaiheisiin. Osa niistä soveltuu sellaisenaan muillekin aloille, mutta levitäkseen laajemmin eri aloille on RosettaNetin määriteltävä vastaavia prosesseja muillekin aloille.

EbXML pyrkii olemaan koko verkkoliiketoiminnan kattava standardi. Sitä kehittävät organisaatiot eivät kuitenkaan määrittele liiketoimintaprosesseja yhtä tarkasti kuin RosettaNet. Todennäköinen vaihtoehto on, että ebXML ja RosettaNet tulevat yhdistymään siten että ebXML muodostaa infrastruktuurin ja RosettaNet liiketoimintaprosessit. Suurin este yhdistymiselle lienevät poliittiset vaikuttimet ja toimintatavat. RosettaNet on korkean teknologian yritysten yhteenliittymä, joka kehittää standardia jäsenten näkökulmasta. OASIS on huomattavasti heterogeenisempi organisaatio ja UN/CEFACT on koostuu valtioiden ja yritysten edustajista. Kaikkien kolmen yhdistäminen yhden toimintakykyisen organisaation alle tulee olemaan hyvin vaikeaa.

2.3. FRENDS EAI Platform

2.3.1. Taustaa

FRENDS on sovellusintegraatio-ohjelmisto, jota on aiemmin käytetty lähinnä yritysten sisäisten jäjestelmien integrointiin. Ensimmäinen FRENDS-asennus otettiin käyttöön vuonna 1989. FRENDSin ensimmäinen versio oli suomalaisten öljy-yhtiöiden ketjunhallinnan tarpeisiin luotu parametroitava tiedonsiirto-ohjelmisto, joka tasaisin väliajoin haki jokaiselta ketjun asemalta tapahtumatietoja ja mahdollisesti päivitti esim.

hintatietoja. Alunperin ohjelmiston painopiste olikin tietoliikenteessä, mistä johtuen PRENDS tukee edelleenkin hyvin suurta määrää tiedonsiirtoprotokollia.

Jotta kerätystä tiedosta olisi hyötyä, on se siirrettävä edelleen yrityksen muihin järjestelmiin (esim. toiminnanohjaus). Tähän tarpeeseen FRENDS:iin on kehitetty joukko rajapintoja erilaisiin ohjelmistoihin. Eri rajapinnat vaativat datan eri muodoissa, joten erilaisia konversio-ominaisuuksia on myös lisätty tarpeen mukaan.

FRENDS:issä kaikki prosessit määritellään graafisesti valmiita operaatioita yhdistelemällä. Yleensä toteutusvaiheessa ei perinteistä ohjelmointia tarvita lainkaan.

Lukuisten rajapintojen, konversioiden ja tehokkaan prosessimäärittelyn ansiosta FRENDS:illä on mahdollista integroida yrityksen erilliset ohjelmistojärjestelmät nopeasti yhdeksi kokonaisuudeksi.

2.3.2. Nykyinen käyttö

FRENDSiä käytetään laajalti vähittäiskaupan alalla ketjunhallinnassa keräämään myyntitietoja ja maksukorttitapahtumia myyntipisteistä keskusjärjestelmään.

Tällaisessa käytössä PRENDS yleensä ottaa ajastetusti yhteyttä kaikkiin myyntipisteisiin ja hakee niiden tapahtumatiedot esim. tietokantaan. Lisäksi PRENDS voi käsitellä haettuja tietoja ja syöttää ne edelleen muihin järjestelmiin tai lähettää eteenpäin jollekin kolmannelle osapuolelle. PRENDS on Suomessa tällaisessa käytössä mm. Tradekan, Nesteen ja Stockmannin ketjunhallinnassa.

Toinen yleinen käyttötapa on yritysten sisäisten järjestelmien integrointi. Näissä PRENDS joko ajastetusti synkronoi eri järjestelmien tietoja tai tarjoaa eri järjestelmille rajapinnan muiden järjestelmien tietoihin. Tällaisena portaalipalvelimena PRENDS toimii mm. Secgo:n M2M-ratkaisussa, jossa valvottavat automaatit päivittävät keskuskoneella olevia tietojaan ja saavat keskuskoneelta päivityksiä FRENDSin kautta.

2.3.3. Arkkitehtuuri

FRENDS-järjestelmä koostuu tai useammasta tähtitopologiaan asettuvasta noodista (TRENDS Huh). Keskimmäinen noodi hallitsee muita noodeja ja jokainen noodi hallitsee siihen kiinnittyneitä prosesseja. Noodit muodostavat viestinvälitys- ja reititysverkon, jonka avulla eri prosessit voivat keskustella keskenään. Hubiin kiinnittyvä prosessi on yleensä samalla koneella kuin k.o. hubi, mutta se voi tarvittaessa olla myös jollain toisella koneella.

Viestinvälitys

Hubit kytkeytyvät keskushubiin ja prosessit hubeihin joko Windowsin nimetyillä putkilla tai TCP-protokollalla. Samassa järjestelmässä voi olla yhtäaikaa sekä putkia että TCP:tä käyttäviä hubeja ja/tai prosesseja. Yksittäisten viestien koko on versiossa 4.1. rajoitettu kahdeksaan kilotavuun.

Ydin

FRENDS-ydin koostuu hubiprosesseista, Suorittajasta (PRENDS Executor), Esikäynnistäjästä (FRENDS Prestarter) ja Käynnistäjästä (FRENDS Starter). Hubeja lukuunottamatta järjestelmässä on vain yksi kappale jokaista ydinprosessityyppiä.

Lisäksi ytimeen kuuluvaksi lasketaan myös sulautettu Solidin tietokanta, ns.

ohjaustietokanta.

Hubit huolehtivat viestiliikenteestä ja eri prosessien hallinnasta. Prosessien hallinta koostuu koko jäijestelmän käynnistämisestä, kaatuneiden prosessien ja noodien uudelleenkäynnistämisestä. Jokaisella prosessilla on oma tunnuksensa, jonka perusteella hubien muodostama reititysverkko välittää viestit oikeille vastaanottajille . Esikäynnistäjän ja Käynnistäjän tehtävänä on käynnistää liiketoimintaprosessit niiden käynnistysehtojen täytyttyä. Suorittaja huolehtii varsinaisesta liiketoimintaprosessien suorituksesta ja järjestelmän resurssoinnista.

Ohjaustietokanta sisältää kaikki järjestelmän liiketoimintaprosessit ja niiden komponentit. Käytännössä ohjaustietokanta sisältää tiedot koko järjestelmästä lukuunottamatta joitain tiedostoista luettavia parametrejä sekä prosessikonfiguraatiota eli määriteltyjä noodeja ja niihin kiinnittyneiden prosessien tietoja, jotka talletetaan Windowsin rekisteriin. Ydinprosesseilla on suora yhteys tietokantaan, jossa on siis mm.

tieto kaikkien liiketoimintaprosessien rakenteesta, parametreistä ja suoritusikkunasta.

Liiketoimintaprosessit voivat yksinkertaisilla viittauksilla käyttää mitä tahansa ohjaustietokannan sisältämiä tietoja. Solid on sulautettu tietokanta eikä pysty suorituskyvyllään ja ominaisuuksillaan kilpailemaan suurten transaktiomäärien käsittelyyn sunniteltujen tietokantapalvelinta kanssa. Raskaammissa ratkaisuissa käytetäänkin yleensä erillistä ns. sovellustietokantaa liiketoimintaprosessien käyttämien tietojen tallennukseen. Hyvin suurissa toteutuksissa myös ohjaustietokanta on korvattu Microsoftin SQL Server -palvelimella ytimen suorituskyvyn parantamiseksi.

Konnektorit

Ydinprosessien lisäksi FRENDS-järjestelmässä on joukko erilaisia konnektori prosesseja. Konnektorit tarjoavat liiketoimintaprosesseille erilaisia rajapintoja mm. käyttöjärjestelmään, tietoliikenneyhteyksiin, tietokantoihin ja ulkoisiin ohjelmistoihin.

Konnektorit kuuluvat resurssipooleihin, joista jokainen tarjoaa jotain tiettyä palvelua.

Kun liiketoimintaprosessi pyytää jotain palvelua poolilta, Suorittaja ohjaa pyynnön jollekin poolin vapaalle prosessille. Poolien avulla saadaan toisaalta rinnakkaisuutta esim. tietoliikenteeseen tai ODBC-yhteyksiin. Toisaalta voidaan myös muodostaa ns.

prioriteettipooleja, joita käyttävät vain "tärkeät" liiketoimintaprosessit, jotka pääsevät näin jonkun jaetun ja ruuhkaisen poolin jonon ohi.

Liiketoimintaprosessit

FRENDS-liiketoimintaprosessi (Routine, rutiini) koostuu aikaehdosta (Time window), käynnistysehdosta (Precondition), yhteyspisteestä (Connection point) ja tehtävästä (Task). Aikaehto ja käynnistysehto määräävät milloin prosessin saa suorittaa.

Varsinaisesta suoritusajankohdasta päättävät käynnistäjä ja esikäynnistäjä. Ne pyrkivät käynnistämään prosessin heti kun se on sallittua, mutta voivat järjestelmän ollessa suuren kuorman alla joutua myöhästämään sen aloitusta.

Yhteyspiste määrittelee liiketoimintaprosessin kohteen. Sen avulla voidaan määritellä esimerkiksi puhelinnumeroita siten, että sama tehtävä osaa ottaa yhteyden eri toimipisteisiin. Yhteyspistettä ei läheskään aina tarvita, eikä mikään myöskään pakota käyttämään sitä alkuperäiseen tarkoitukseensa. Yhteyspisteiden tiedot talletetaan ohjaustietokantaan ja PRENDS tarjoaa niiden ylläpitoon työkalun, jonka avulla eri yhteyspistetyyppien tietojen ylläpitoon voidaan rakentaa omat käyttöliittymänsä.

Tehtävät määritellään PRENDS:in graafisella drag-'n'-drop -työkalulla. Saman työkalun avulla voidaan myös valvoa suoritettavana olevia prosesseja sekä tutkia jo suoritettujen prosessien eri vaiheita. Tehtävää määriteltäessä pudotetaan sen alitehtävät kohdalleen ja määritellään niille tarvittaessa argumentit. Itse tehtävä suoritetaan aina yhdessä säikeessä, mutta joku sen komponentti voi käynnistää esim. jonkin ulkoisen prosessin, jota suoritetaan yhtä aikaa tehtävän kanssa.

Tehtävä koostuu alitehtävistä, vaiheista ja ehdoista. Kaikki elementit voivat saada argumentteja ylemmän tason tehtävältä. Suorittaja on FRENDSrin ohjelmointikielen tulkki, joka hallitsee koko tehtävän suoritusta. Vaihe on pyyntö jollekin resurssipoolille.

Suorittaessaan vaihetta, Suorittaja valitsee poolista vapaan jäsenen (tai odottaa jonkin vapautumista) ja lähettää pyynnön sille. Tämän jälkeen Suorittaja jää odottamaan paluuviestiä k.o. jäseneltä. Ehdot ovat DLL-kirjastokutsuja, jotka Suorittaja käsittelee sisäisesti.

Tehtävät voivat luoda ja käyttää muuttujia, joista Suorittaja huolehtii. Muuttuja on Suorittajan sisäisesti käsittelemä tekstimuuttuja, jonka arvo välitetään sitä käyttävän vaiheen tai tehtävän parametrina (Call-by-Value). Lisäksi Suorittaja määrittelee lukuisia PRENDS viittauksia ja funktioita, jotka se voi suorittaa sisäisesti. Usein käytettyjä viittauksia ovat esimerkiksi aikaleimat. Funktioita voidaan käyttää esimerkiksi jäsentämään vaiheiden paluuarvoja tai suorittamaan yksinkertaisia matemaattisia operaatioita.

* Task Open Utility [_

Name:

® ||0pen Utilitv

0

* Phase TAPI Open Utility L

Name:

ф jfTAPI Open Utility

Class:

|SCL^J

Message definition

Send to resource: Jtapi

Г~ Resource

г

Message name: ¡OPEN

Message garameters: Protocol:

Besoutce description:

Resource for a Telephone API connection

Message description:

Opens the communication channel. Parameters vary upon the communication platform.

I* Timeout definition

T. , ,, Behaviour after a timeout:

T imeout after _

____ < Re-execute this phase 12 minutes д- рац_ but continue task Fail and abort routine

J«? Critical Save return info C~ On error

Always

’• Never

Kuva 7. Esimerkki FRENDS-tehtävän rakenteesta.

Transaction Server

FRENDS Transaction Server (FTS) on TCP-palvelin, jonka logiikka ohjelmoidaan FRENDSrin ohjelmointikielellä yhtenä tehtävänä. Kun Suorittaja on FRENDSiin ohjelmointikielen tulkki, on FTS käytännössä yhdistetty kääntäjä ja tavukoodin tulkki.

Käynnistyessään FTS kääntää annetun tehtävän sisäiseen esitysmuotoon, jonka se pystyy suorittamaan hyvin tehokkaasti.

FTS:n tehtävällä on tiettyjä rajoituksia verrattuna "tavallisiin" PRENDS tehtäviin.

Tärkeimpänä erona FTS ei voi pyytää muiden prosessien palveluita vaan kaikki vaiheet ovat DLL-kirjastojen funktiokutsuja. Toisaalta joitaina ominaisuuksista on myös laajennettu. Muuttujat välitetään viittauksina (Call-by-reference), jolloin vaiheet voivat muuttaa niiden sisältöä. Lisäksi ne voivat sisältää erilaisia olioita ja oliorajapintoja.

Yleisimmin Transaction Serveriä käytetään siten, että pyynnöt tulevat TCP-yhteyksinä.

Tämän lisäksi FTS-tehtävä on mahdollista käynnistää tavallisella FRENDS-vaiheella jostain liiketoimintaprosessista. Tehtävä määrittelee mitä parametreja se vaiheelta vaatii ja vaiheen luomisen jälkeen sitä voi käyttää kuin mille tahansa "tavalliselle"

konnektorille kohdistuvaa vaihetta. Tehtävän on itse luettava parametrit vaiheen viestistä sekä talletettava paluukoodi ja -tieto niille varattuihin muuttujiin.

Transaction Serverille on toteutettu lukuisia kirjastoja, joiden avulla voidaan rakentaan monenlaisia toteutuksia ilman "oikeaa" ohjelmointia. Osa kirjastoista tarjoaa rajapintoja ulkoisiin järjestelmiin (käyttöjärjestelmä, tietokannat, jonot, yms.). Muut kirjastot tarjoavat funktioita lähinnä viestien jäsentämiseen ja käsittelyyn.

Yksinkertaisimmillaan viestien jäsentäminen voidaan toteuttaa säännöllisten lauseiden käsittelyn avulla. Sännöllisten lausekkeiden lisäksi FTS:ään on kirjoitushetkellä toteutettu kirjasto XML-viestien DOM (Domain Object Model) -jäsentämiseen ja toinen kirjasto ISO-8583 -korttivarmennussanomien jäsentämiseen.

XML-kirjaston avulla luodaan eri viestityypeille jäsennystehtävät, jotka hakevat tiettyjen noodien sisältämät tiedot annettuihin muuttujiin. Kirjasto mahdollistaa XPath- viittausten lisäksi myös dokumenttipuun selauksen. Kirjastoa voidaan käyttää myös XML-dokumenttien muodostamiseen. Usein on kuitenkin tehokkaampaa ja helpompaa käyttää Transaction Serverin muuttujien käsittelyä, jolloin luodaan viestipohja, johon jätetään muuttuvien tietojen kohdalle argumentti viittaukset. Itse dokumentin luonti

tapahtuu tällöin antamalla viestipohjan sisältävälle tehtävälle sen vaatimat argumentit.

<doc> <doc>

<A>[ARG.A]</A> A : " 1 " В : " 2 " <A>1</A>

<B>[ARG.B]</B> > <B>2</B>

</doc> </doc>

Kuva 8. Esimerkki viestipohjien käytöstä.

2.4. Työn tavoite

2.4.1. Tavoite

Työn tavoitteena on kehittää FRENDS EAI Platformin päälle verkkoliiketoimintaohjelmisto, joka mahdollistaa yritysten välisten, standardeja verkkoliiketoimintaprotokollia käyttävien, liiketoimintaprosessien nopean toteutuksen ja integroinnin yrityksen operatiivisiin järjestelmiin. Ohjelmiston avulla on kyettävä toteuttamaan liiketoimintaprosesseja eri ympäristöissä nopeammin kuin räätälintyönä tehtävällä ohjelmoinnilla on mahdollista. Lisäksi ohjelmiston olisi tuettava jo määriteltyjen prosessien uudelleenkäyttöä ja monistamista.

Totetutusmallin tulisi pohjautua mahdollisimman suurelta osin jo olemassaoleviin ohjelmakomponentteihin. Komponentteihin tulisi olla mahdollista lisätä uusia ominaisuuksia tarpeen vaatiessa ja myös uusia komponentteja voidaan tarvittaessa luoda. Ohjelmiston tulee toteuttaa verkkoliiketoimintaprotokollat mahdollisimman valmiina komponentteina, joita liiketoimintaprosessien kehittäjät voivat käyttää prosessikuvausten toteuttamiseen mahdollisimman pienellä muokkauksella.

Työ on osa laajempaa ebFRENDS -projektia, jonka tarkoitus on laajentaa PRENDS:in ominaisuuksia yritysten väliseen tiedonsiirtoon. Työssä keskitytään kahden verkkoliiketoimintaprotokollan ebXML:n ja RosettaNetin vietiliikenteen ja liiketoimintaprosessien toteuttamiseen FRENDS:in avulla. Tuloksena syntyvän ohjelmiston on tarkoitus muodostaa ebFRENDS -tuotteen ydin, jota voidaan tarvittaessa myöhemmin laajentaa tukemaan muita protokollia.

2.4.2. Rajauksia

Tuettaviksi verkkol i i ketoi mint aprotokol 1 i ksi on alustavasti rajattu ebXML ja RosettaNet. Ohjelmiston tulisi kuitenkin mahdollistaa uusien protokollien lisääminen tulevaisuudessa. EbXML:n rekisterin käyttöön ei oteta kantaa. Oletuksena on, että PRENDS pystyy sekä lukemaan että päivittämään rekisterissä olevia tietoja.

Työssä ei oteta kantaa muihin ohjelmistoihin integroitumiseen. Oletuksena on, että PRENDS tarjoaa tarpeelliset rajapinnat ja konnektorit kaikkiin integrointitarpeisiin.

Todellisuudessa näin ei aina ole vaan harvinaisempia protokollia käyttäviä ohjelmistoja varten on luotavat omat konnektorinsa toteutuksen yhteydessä.

3. Vaatimukset

3.1. Yleiset vaatimukset

3.1.1. Yleistä

Ylimmällä tasolla sekä ebXML:n että RosettaNetin määrittelyt käsittelevät liiketoimintaprosessia kahden tai useamman osapuolen välisenä viestikoreografiana.

Alempien tasojen määrittelyt puolestaan pohjautuvat tähän näkökulmaan.

Lähestymistapa on siis hyvin prosessikeskeinen kuten myös itse prosessien suunnitteluvaihe. RosettaNet tarjoaa valmiita standardiprosesseja ja todennäköisesti vastaavia syntyy myös ebXML:ään.

Suunnitteluvaiheessa osapuolet määrittelevät toteutettavat liiketoimintaprosessit, niiden viestikoreografiat ja viestien sisällöt. Suunnitteluvaiheessa prosessien kuvaus on siis tasoa "A lähettää tilausviestin B:lle, joka vastaa siihen hyväksymis- tai hylkäysviestillä kolmen tunnin sisällä."

Toteutusvaiheessa jokainen osapuoli toteuttaa vain osa määritellystä prosessista omasta näkökulmastaan. Eli ym. esimerkkiprosessia käsitelläänkin omasta näkökulmasta:

"Vastaanotetaan tilausviesti, käsitellään se ja lähetetään vastaus." Koska ebFRENDS on yhden osapuolen järjestelmä, on ebFRENDSin lähdettävä tästä näkökulmasta.

3.1.2. Kerrosmalli

Sovellusintegraatio-ohjelmisto yhdistää organisaation erilliset sovellukset yhdeksi kokonaisuudeksi, jossa liiketoimintaprosessit voivat koostua eri sovelluksien suorittamista osista. Valmiin ohjelmiston etu räätälöityyn ratkaisuun verrattuna on valmiiden konnektorien ja jopa prosessimäärittelyiden avulla nopeutettu toteutusaika ja parempi ylläpidettävyys. Sovellusintegraatio-ohjelmiston tulisi tarjota vastaavat hyödyt myös verkkoliiketoimintaprotokollien toteutuksessa. Tämän saavuttamiseksi tulisi protokollien viestinsiirtomallit toteuttaa siten, että ne voidaan ottaa käyttöön mahdollisimman vähällä parametroinnilla. Lisäksi toteutettujen julkisten liiketoimintaprosessien (RosettaNetin PIP:it ja ebXMLrn BPS:it) uudelleenkäytön tulisi olla mahdollista.

Molempien protokollien rakenne voidaan jakaa erillisiin kerroksiin. Alimmalla tasolla, heti tiedonsiirtokerroksen päällä on viestiensiirtokerros. Sen päällä on liiketoimintakerros, joka suorittaa ns. julkista liiketoimintaprosessia.

Liiketoimintakerroksen päälle sijoittuu integraatiokerros, joka käsittelee liiketoimintaprosessia yrityksen näkökulmasta (ns. yksityinen liiketoimintaprosessi) ja integroituu yrityksen muihin järjestelmiin.

z 7 Z _

Integraatiokerros Integraatiokerros

/ /

Liiketoimintakerros Liiketoimintakerros

/ Prosessikohtainen viesti ^/

Viestinsiirtokerros Viestinsiirtokerros

/ <

ebXML/RN -kehys 7

Tiedonsiirtokerros Tiedonsiirtokerros

(HTTP/SMTP/...)

z

z

Kuva 9. ebXML. n ja RosettaNetin abstrakti kerrosmalli.

Kumpikaan protokolla ei määrittelyissään tee ylläolevan kaltaista jakoa vaan jakaa toteutuksen kolmeen osaan: Viestinsiirtopalveluun, viestirajapintaan ja liiketoimintasovellukseen. Tämä malli lähtee räätälöitujen toteutusten näkökulmasta, joissa sovellus on luotu suorittamaan tiettyjä liiketoimintaprosesseja ja käyttää itse

viestinsiirtopalvelua.

Tiedonsiirtokerros

Sekä RosettaNet että ebXML käyttävät tiedonsiirtoon oletusarvoisesti HTTP- protokollaa ja määrittelevät myös SMTP-protokollan käytön. Tiedonsiirtokerrokseen on siis toteutettava ainakin sekä HTTP-palvelin että -asiakas. SMTP-tukea varten tarvitaan SMTP-asiakas viestin lähetystä varten sekä POP- ja/tai IMAP-asiakas viestin vastaanottoon.

Olisi myös mahdollista toteuttaa SMTP-palvelin, mutta siitä ei todennäköisesti olisi lisäarvoa. Oletettavasti jokaisella toimijalla on käytössään joko oma SMTP-palvelin tai jonkun operaattorin ylläpitämä palvelin. Näin ollen SMTP:n käyttö siis muuttaa tiedonsiirtokuviota siten, että toteutuksessa ei ole palvelintoteutusta lainkaan vaan myös viestien vastaanotto tapahtuu clientilla. Tämän toteutus vaatii mekanismin, jonka avulla palvelimelta haetaan saapuneet viestit tasaisin väliajoin käsittelyä varten.

Viestinsiirtokerros

Viestinsiirtokerros huolehtii saapuvien viestien vastaanottamisesta ja lähtevien viestien välittämisestä oikeille vastaanottajille. Lisäksi kerroksen tehtävänä on todeta viestien oikeellisuus, purkaa mahdollinen salaus ja mahdollisesti myös autentikoida lähettäjä.

Viestinsiirtokerros tarjoaa liiketoimintakerrokselle sen tarvitsemat viestin lähetys- ja vastaanottopalvelut. Sen tehtävä on huolehtia oikeasta viestien kehystämisetä, osoitteistuksesta, koodauksesta ja siirtoprotokollasta. Viestinsiirtokerroksen ei ainakaan ideaalitapauksessa tarvitse tietää mitään suoritettavista liiketoimintaprosesseista. Se vain ottaa vastaan viestejä ja antaa ne ylemmälle tasolle käsiteltäviksi. Pystyäkseen toimittamaan viestit muille osapuolille, kerroksen on pystyttävä selvittämään osapuolen saapuvasta viestistä liiketoimintakerroksen ymmärtämä toisen osapuolen tunnus.

Vastaavasti kerroksen on lähtevän viestin tapauksessa sisäisen tunnuksen perusteella pystyttävä selvittämään vastaanottajan osoite, tiedonsiirtoprotokolla, salausavaimet jne.

Koska viestinsiirtokerroksen toteutusten kunnollinen yhteistoimivuus on ehdoton edellytys yhteistoiminnalle, on se myös tarkimmin kuvattu ja spesifioitu kerros molemmissa protokollissa.

Liiketoimintakerros

Liiketoimintakerros suorittaa julkista liiketoimintaprosessia eli toteuttaa osapuolten välille määriteltyä viestikoreografiaa. Sen on siis pidettävä huoli, että oikea viesti lähetetään tai saapuu oikeassa vaiheessa. Lisäksi sen on pystyttävä purkamaan viesteistä niiden sisältämä tieto integraatiokerroksen ymmärtämään muotoon sekä kasaamaan integraatiokerrokselta saatu tieto oikeanmuotoisiksi viesteiksi.

Liiketoimintakerros huolehtii julkisessa liiketoimintaprosessissa määritellyistä virhe-, kuittaus- ja aikarajakäsittelyistä. Koska liiketoimintaprosessien sallittu suoritusaika voi olla jopa vuorokausia, on liiketoimintakerroksen käytännössä toteutettava myös prosessien persistiivisyysominaisuuksia. Laite- tai ohjelmistovirheen vuoksi keskeytynyttä prosessia on mahdollisuuksien mukaan kyettävä jatkamaan automaattisesti.

Integraatiokerros

Integraatiokerros purkaa liiketoimintakerroksen tasolla, julkisessa liiketoimintaprosessissa, määritellyt abstraktit operaatiot Saijaksi sisäisiä toimenpiteitä.

Esimerkiksi "käsittele tilaus" -operaatio voi koostua asiakastietojen ja varastosaldon tarkastuksista ja päivityksistä sekä tilauksen luonnista tilausjärjestelmään.

Kumpikaan protokolla ei ota mitään kantaa integraatiokerrokseen. Räätälöidyissä ratkaisuissa viestinvälityskerroksen yläpuolista osaa ei todennäköisesti edes jaettaisi useampaan osaan. Integraatioalustaa luotaessa kerrokset on kuitenkin pyrittävä erittelemään. Samaa integraatiokerroksen toteutusta voidaan pienin muutoksin käyttää saman julkisen prosessin toteuttamiseen usealle eri osapuolelle. Integraatiokerroksen prosessit puolestaan ovat täysin riippuvaisia kunkin osapuolen sisäisistä järjestelmistä, niiden käyttötavoista ja muista käytännöistä.

Integraatiokerroksen on mahdollistettava päätösten varmistaminen käyttäjältä tarpeen niin vaatiessa. Esimerkiksi automaattisessa tilaustenkäsittelyssä voi olla, että joidenkin asiakkaiden tilaukset halutaan käsitellä manuaalisesti.

3.1.3. Yhteistoimintasopimukset

EbXML määrittelee joukon vaatimuksia yhteistyösopimukselle (EbXML CPA, Collaboration Partner Agreement). RosettaNetin versio 2 ei juurikaan ota kantaa näihin sopimuksiin (TPA, Trading Partner Agreement). RNEF2 mainitsee kuitenkin niiden tarpeellisuuden ja toteaa tämän puutteeksi. Seuraavaan versioon niiden määrittely onkin suunnitteilla.

Molemmissa protokollissa yhteistyösopimus ymmärretään sopimusoikeudellisesti sitovana. Se määrittelee ainakin osapuolten väliset sallitut liiketoimintaprosessit ja niiden tulkinnan. Myös liiketoimintaprosesseissa tehtyjä operaatiota (esim. tilaukset,

tarjoukset ja tarjouspyynnöt) voidaan, yhteistyösopimuksesta riippuen, rinnastaa paperilla tehtyihin vastaaviin operaatioihin ja pitää sitovina.

Jo puhtaasti laillisista syistä on siis tärkeää, että jokainen kerros pitää kirjaa vastaanotetuista sanomista ja niiden käsittelystä sekä tehdyistä operaatioista. Lisäksi esimeriksi vastaanotetut tilaukset mahdollisine sähköisine allekirjoituksineen on pystyttävä arkistoimaan paperisia tilauksia vastaavasti.

3.1.4. Suorituskykyvaatimukset

Toteutuksen on skaalauduttava siten, että uusien yhteistyökumppaneiden lisääminen olemassaolevien rinnalle on yksinkertaista. Käytössäolevan liiketoimintaprosessin roolin käyttöönotto uuden osapuolen kanssa tulisi parhaimmillaan vaatia vain osapuolikohtaisten tietojen lisäämisen.

Toteutuksen on kyettävä suorittamaan useita liiketoimintaprosesseja rinnakkain. On oltava mahdollista suorittaa useampaa saman liiketoimintaprosessin instanssia yhtäaikaa. Myös saman osapuolen kanssa on kyettävä suorittamaan useampaa liiketoimintaprosessin instanssia rinnakkain.

Verkkoliiketoimintaprotokollien prosessien oletetaan kestävän tunteja taijopa päiviä.

Näin ollen viestinsiirrron ja viestienkäsittelyn nopeudelle ei ole kovinkaan suuria suorituskykyrajoja. Luonnollisesti toteutuksen on kuitenkin pyrittävä olemaan mahdollisimman tehokas näiltäkin osin.

3.1.5. Virhetilanteiden käsittely

Alimmalla tasolla siirtoprotokolla (esim. HTTP) hoitaa havaitsemansa siirtovirheet protokollan määrittelyjen mukaisesti. Liiketoimintaprosessi määrittelee viestien purkamisessa (tiedonsiirtokerroksessa) tapahtuvien virheiden käsittelyn. Käsittely on aina viestin hylkäys sekä mahdollisesti poikkeusviestin lähetys lähettäjälle. Viestejä lähetettäessä on tiedonsiirtokerroksen pystyttävä hoitamaan uudelleenlähetykset sekä ajastetusti että vastaanotettujen poikkeusviestien niin vaatiessa. Mikäli poikkeusviesti ilmoittaa hylkäyksen johtuvan itse viestistä eikä esim. siirtovirheestä, tulisi liiketoimintakerrosta ja käyttäjää pystyä informoimaan asiasta.

Liiketoimintaprosessi voi määritellä sovellustason virhetilanteiden käsittelyn, joka on kyettävä toteuttamaan. Tällainen käsittely on yleensä liiketoimintaprosessin keskeytys ja mahdollisesti virhekoodin palautus toiselle osapuolelle ja/tai virheen raportointi käyttäjälle. Virhetilanne voi myös vaatia jonkun toisen liiketoimintaprosessin käynnistämistä.

Integraatiokerros voi sisältää omaa virheenkäsittelyään mutta sen on myös kerrottava liiketoimintakerrokselle virheistä. Tällaisessa tilanteessa liiketoimintakerros päättää, liiketoimintaprosessista riippuen, kuinka virhe on käsiteltävä.

Yhden liiketoimintaprosessin suoritus voi kestää useita tunteja, varsinkin jos prosessi vaatii toimenpiteitä käyttäjältä. Myös yksittäisistä siirtovirheistä toipuminen voi viedä, jopa täysin automaattisissakin liiketoimintaprosesseissa, pitkiäkin aikoja sillä

esimerkiksi RosettaNetissä viestin uudelleenlähetysaika mitataan tunneissa [2]. Tästä syystä järjestelmän tulisi pystyä jatkamaan sellaisia keskeytyneitä liiketoimintaprosesseja, joiden keskeytyminen johtui itse prosessista riippumattomista syistä, kuten esimerkiksi järjestelmän uudelleenkäynnistyksestä. Tämän toteuttaminen vaatii suoritettavien liiketoimintaprosesien tilan säilyttämistä persistiivisessä tietovarastossa, josta viimeinen tallennettu tila voidaan tarvittaessa palauttaa.

3.2. EbXML: n asettamat vaatimukset

3.2.1. Yleistä

Suurin osa ebXML:n vaatimuksista koskee viestinsiirtokerrosta, joka on järjestelmän rajapinta muihin ebXML-toimijoihin. Ylempien kerrosten rakenteelle ja toiminnallisuudelle ei juurikaan määritellä vaatimuksista mutta osa viestinsiirtokerroksen vaatimuksista vaikuttavat välillisesti myös liiketoimintakerrokseen.

ebXML Applications Messaging Service Interface

Messaging Service

SMTP HOP HTTP

Encryption, Digital Signature

Message Packaging Module Header Processing Authentication, authorization and

lepudiation services

Delivery Module Send/Receive Transpon Mapping and Binding

Kuva 10. EbXML.n viestinvälityspalvelun arkkitehtuuri. [6]

EbXML:n määrittelyt kuvaavat viestinsiirtokerroksen järjestelmäksi, joka täyttää ebXML-standardien määrittelyt ja tarjoaa sovelluksille palveluita sisäisesti määriteltävän rajapinnan kautta. Lisäksi ebXML standardoi liiketoimintaprosessien määrittelytavan ja tulevaisuudessa mahdollisesti myös joitain liiketoimintaprosesseja.