T Special Course in Information Systems Integration

Koko: px
Aloita esitys sivulta:

Download "T-86.5161 Special Course in Information Systems Integration"

Transkriptio

1 HELSINKI UNIVERISITY OF TECHNOLOGY Department of Computer Science and Engineering Software Business and Engineering Institute T Special Course in Information Systems Integration The messaging choreographies for B2B integration Yritystenvälisten sanomanvälitysstandardien vertailua Project Report January 16th, 2007 Mommo, Esa Pihlaja, Markus Vesterinen, Pauli

2 Tiivistelmä Yritysten väliseen integraatioon on kehitetty useita standardeja. Nämä standardit määrittelevät erilaisia asioita hyvin eri tavoilla. Yleisesti ottaen standardit määrittelevät kuljetuskerroksen, kuljetettavien viestien rakenteen ( kirjekuoren ) sekä mahdollisesti kokoelman yritystenvälisiä prosesseja, jotka käyttävät välitettäviä viestejä. Jotta tietoa kuitenkin voidaan välittää yritysten välillä, täytyy yritysten sopia keskenään mitä standardeja käytetään ja millä tavalla. Tämän työn tarkoituksena on esitellä ja verrata erilaisia ratkaisuja, jotta suomalaiset pienet ja keskisuuret yritykset saavat tietoa eroista ja voivat valita itselleen parhaiten sopivan. Tutkimuksessa verrattiin kolmea yleistä vaihtoehtoa HTTP-pohjaiseen viestinvälitykseen: ebxml-perheeseen liittyvää ebms-standardia (electronic business Messaging System), RosettaNetin RNIF-standardia (RosettaNet Implementation Framework) ja lähinnä EDIsanomien välittämiseen käytettyä AS2-standardia (Applicability Statement 2). Vertailussa keskityttiin standardien tekniseen toteutukseen, välitettyihin otsikkotietoihin, tarjottuun toiminnallisuuteen sekä signalointitapoihin. Lisäksi tehtiin nopea katsaus standardien ohjelmistotukeen. Vertailussa huomattiin selkeästi se että jokainen standardi on tehty eri lähtökohdista käsin. AS2 on suunniteltu EDI-viestien siirtämiseen HTTP-yhteyden yli, mutta myös muuta dataa voidaan kuljettaa. RNIF kytkeytyy tiukasti muuhun RosettaNet -standardiin ja muiden kuin RosettaNet-viestien kuljettamiseen on hankalaa. EbMS on luonteeltaan yleisempi vaikka sekin on suunniteltu käytettäväksi ebxml -viestien kanssa. Käytettävän standardin valinta on monitahoinen, strateginen päätös johon vaikuttavat yrityksen toimiala, yhteistyökumppanit sekä olemassa olevat tietojärjestelmät. ii

3 Abstract Many standards have been developed for business-to-business integration. Different standards define various aspects in very different ways. In general, the standards define a transport layer, structure of transported messages (envelope) and possibly a collection of inter-company processes that use the transported messages. To be able to transport information between companies they must agree between themselves what standards are to used and in what ways. The purpose of this work is to introduce and compare different solutions so that Finnish small and medium sized companies could compare them and choose the best one for them. Three common alternative standards for HTTP-based integration were compared : ebms (eb Messaging System) that is part of the ebxml-family, RNIF (RosettaNet Implementation Framework) of RosettaNet suite, and AS2-standard (Applicability Statement 2) that is mainly used to transport EDI-messages. The comparison concentrated on the technical choices of the standards, message headers delivered, supported functionality and signalling methods supported. In addition, a short overview of the software support for each standards was made. The basis of each standard is different. AS2 has been designed to transport EDI-messages over HTTP connection, but other data can be transported as well. RNIF is tightly integrated with the rest of the RosettaNet and transporting other than RosettaNet messages is cumbersome. ebms is a more general standard in nature, even though it is designed to be used with ebxml-messages. The choice of which standard to use is a complicated one, with strategic implications. The main factors to consider are the line of business, collaboration partners and the existing data systems in use. iii

4 Sisällysluettelo Tiivistelmä... ii Abstract... iii Kuvaluettelo... vii Taulukkoluettelo... viii 1 Johdanto Taustaa Tavoitteet Tutkimuskysymykset Tutkimuksen laajuus Tutkimusmenetelmät Sanasto Raportin rakenne Aikataulu Yleisesittely RosettaNet Implementation Framework ebms (ebxml Messaging Service) AS Tekninen vertailu RNIF EbMS AS Yhteenveto iv

5 4 Tietosisältöjen vertailu RNIF EbMS AS Yhteenveto Toiminnallisuus RNIF EbMS AS Yhteenveto Signalointi RNIF EbMS AS Yhteenveto Ohjelmistotuki RNIF EBMS AS Yhteenveto Johtopäätökset ja pohdinnat Yleistä Yhteensopivuudesta Operaattorimalli v

6 8.4 Lopuksi Yhteenveto Lähdeluettelo vi

7 Kuvaluettelo Kuva 2.1 Esimerkki - tyypillinen B2B -tapahtuma... 8 Kuva 4.1 RNIF-viestin rakenne (RosettaNet 2002) Kuva 4.2 RNIF-viestin allekirjoitus (RosettaNet 2002) Kuva 4.3 EbMS-viestin rakenne (OASIS 2002) Kuva 4.4 EbXML otsikko (OASIS 2002) Kuva 4.5 MIME-otsikko (OASIS 2002) Kuva 4.6 Lähetettävän sanoman MIME-otsikko (OASIS 2002) Kuva 5.1 RNIF viestin allekirjoitus (RosettaNet 2002) Kuva 5.2 RNIF viestin salaus, luodaan Encrypted Payload Container (RosettaNet 2002) Kuva 5.3 RNIF-viestin salaus, salaamattomat otsikkotiedot paketoidaan salatun osion kanssa (RosettaNet 2002) Kuva 5.4 AS2 koreografia ja orkestrointi (Seeburger 2005) Kuva 6.1 Yksitapahtumainen asynkroninen prosessi jossa lähetetään yksi liiketoimintaviesti ja sen kuittaus (RosettaNet 2002) Kuva 6.2 Kaksitapahtumainen asynkroninen prosessi jossa ensimmäinen liiketoimintaviesti kuitataan ja lähetetään vastausviesti joka myös kuitataan (RosettaNet 2002) vii

8 Taulukkoluettelo Taulukko 3.1 B2B sanomanvälitysstandardien tekninen vertailu Taulukko 4.1 Yhteenveto tietosisällöistä Taulukko 5.1 Yhteenveto eri standardien tukemista toiminnallisuuksista Taulukko 6.1 Yhteenveto signalointiominaisuuksista Taulukko 7.1 EbMS-ohjelmistojen tarjoajia (EbXML Forum 2004) Taulukko 7.2 Standardeja tukevien ohjelmistojen lukumääriä viii

9 1 Johdanto 1.1 Taustaa B2B (yritysten välinen kaupankäynti) -integrointi perustuu tiedon toimittamiseen yritykseltä toiselle. Ennen kuin voidaan edes ajatella sanomien semantiikkaa tai prosessikoreografioita täytyy olla olemassa tapa lähettää sanomia yhdeltä osapuolelta toiselle sovitussa formaatissa. Useimmat B2B-integrointistandardit määrittävät omat kuljetusmekanisminsa ja sanomaformaattinsa. Nämä mekanismit voivat olla mitä tahansa perinteisen puhelinlankaa pitkin välitettävän datasiirron ja vaikka JMS:n (Java Message Service) päällä olevan SOAP-kirjekuoren (Simple Object Access Protocol) välillä. Saatavilla on monia erilaisia B2B-integrointistandardeja ja tällä hetkellä yksikään niistä ei ole saavuttanut niin merkittävää asemaa ja markkinaosuutta, että sitä voitaisiin sanoa johtavaksi standardiksi. Monillakaan pienillä tai keskisuurilla yrityksillä ei ole yksinkertaisesti resursseja ottaa käyttöön useampia kuin korkeintaan yksi näistä standardeista. Tämän takia monet pienet ja keskisuuret yritykset odottavat kuinka markkinat kehittyvät ennen kuin tekevät päätöksiä standardien valinnan suhteen. Tämän työn tarkoituksena on vertailla useita erilaisia standardeja keskenään pyrkimyksenä selvittää miten ne eroavat toisistaan ja mitä yhteistä niillä on. Lisäksi on tarkoitus selvittää mitä piirteitä eri standardit pitävät sisällään ja minkälaisia mahdollisuuksia on olemassa eri standardien yhteensopivuuden kannalta. 1.2 Tavoitteet Tämän työn tavoitteena on auttaa suomalaisia pieniä ja keskisuuria yrityksiä valitsemaan B2B -integrointi standardinsa niin että se sopii mahdollisimman hyvin heidän tarpeisiinsa tällä hetkellä ja että valinta ei myöskään tulevaisuudessa rajoita toimintaa. 1

10 Tavoite pyritään saavuttamaan vertailemalla useita tunnettuja sanoma -viestintäkehyksiä, kuten RNIF (RosettaNet Implementation Framework), ebms (Electronic Business Messaging service) ja AS2 (Applicability Statement 2), useista eri näkökulmista. Tässä työssä vertailuun käytettyjä näkökulmia ovat tekninen, tietosisältö, toiminnallisuus, signalointi ja ohjelmistotuki. 1.3 Tutkimuskysymykset Työn onnistumisen kannalta on tärkeää olla selkeä ja ymmärrettävä ongelman asettelu ja hyvin rajatut kysymykset joihin pyritään vastaamaan. Epämääräinen aihe voi johtaa huonoihin tuloksiin, joista ei ole hyötyä kenellekään. Tutkimuksen apuna ovat tutkimuskysymykset, joihin työssä pyritään vastaamaan. Näiden kysymysten avulla tutkimustyön tavoitteiden saavuttaminen on helpompaa. Tämän tutkimuksen apuna ovat seuraavat tutkimuskysymykset: Mitkä ovat tarkasteltujen standardien tekniset, toiminnalliset sekä sisällölliset eroavaisuudet? Jos yritys harkitsee ottavansa käyttöön jonkin näistä standardeista, millaisia asioita kannattaa ottaa huomioon valintaa tehdessä? Millaisia standardeja toteuttavia tuotteita on markkinoilla? 1.4 Tutkimuksen laajuus Tämä tutkimus keskittyy tarkastelemaan B2B-standardeja RNIF, ebms sekä AS2 asiakkaan, TIEKE:n (Tietoyhteiskunnan kehittämiskeskus ry.), toiveiden mukaisesti, kuitenkin rajoittuen HTTP-protokollaan. Nämä kolme standardia on valittu vertailuun asiakkaan toivomuksesta. Muita siirtoprotokollia, kuten SMTP tai FTP, ei tarkastella standardien yhteydessä. Tutkimus esittelee näistä standardeista lyhyen yleisesittelyn, toiminnallisuusvertailun, teknisten ominaisuuksien vertailun ja tietosisältöjen sekä signalointien vertailun. Myös tuotteita, jotka toteuttavat näitä standardeja, esitellään lyhyesti. 2

11 1.5 Tutkimusmenetelmät Tutkimus toteutetaan kirjallisuuskatsauksena Kirjallisuuskatsaus pyrkii vastaamaan esitettyihin tutkimuskysymyksiin sekä esittelemään standardit eri näkökulmista katsottuna. Kirjallisuuskatsauksen luonne on väkisinkin jossain määrin pinnallinen ja kevyt, koska tutkimuksen laajuus on niin suuri asiakkaan toivomusten mukaisesti. Tutkimuksen lähtökohdista johtuen lähteinä kirjallisuuskatsaukseen ovat ensisijaisesti standardien spesifikaatiot ja näiden määrittelijätahojen dokumentit. Näiden lisäksi on pyritty käymään läpi erilaisia akateemisia julkaisuja. 1.6 Sanasto Jotta ymmärtäisi B2B liiketoimintaa ja tätä raporttia, on tärkeää että keskeisimmät termit ylipäätään ymmärretään ja ymmärretään samalla tavalla. Tällöin estetään mahdolliset väärinkäsitykset tai epäselvyydet aihepiiriä tarkasteltaessa. Tähän kappaleeseen on kerätty eräitä tärkeimpiä raportissa esiintyviä termejä ja lyhenteitä. AS2 Applicability Statement 2, spesifikaatio datan siirtämiseen turvallisesti ja luotettavasti Internetin kautta. (RFC 4130) B2B Business to business, yritysten tai organisaatioiden välinen kaupankäynti. (Wikipedia 2006b) CMS Cryptographic Message Syntax. (Wikipedia 2006c) De Facto Kyseisellä toimialalla käytetty, vakiintunut menettelytapa tai standardi. (Wikipedia 2006d) DTD Document Type Definition, määrittelee XML -dokumentin rakenteen ja sallitut elementit dokumentissa. (W3Schools 2006). EbMS EbXML Messaging Service, sähköisen kaupankäynnin standardi, joka määrittelee XML-viestejä käyttävän sanomanvälityspalvelun (OASIS 2002) EbXML Electronic Business Extensible Markup Language. (OASIS 2002) EDI Electronic Data Interchange, sähköinen tiedonsiirtotapa. (Tieke 2006) EDIINT EDI over the Internet, EDI käyttäen Internetiä. (Wikipedia 2006e) HTTP Hypertext Transfer Protocol. Hypertekstin siirtoprotokolla, jota selaimet ja WWW-palvelimet käyttävät tiedonsiirtoon (Wikipedia 2006f) HTTPS suojattu versio. (Wikipedia 2006g) JMS Java Message Service, Java-pohjainen sanomanvälitys standardi. (Wikipedia 2006h) Koreografia Organisaatioiden välisten liiketoimintaprosessin 3

12 tapahtumien keskinäinen järjestys ja kuvaus. (O Reilly 2006) MD5 Hash-algoritmi. Viestitiivistealgoritmi (Wikipedia 2006i) MDN Message Disposition Notification, vahvistus lähettäjälle. (RFC 4130) MIME Multi-Purpose Mail Extension, sähköpostin liitetiedostomäärittely. (Wikipedia 2006j) MSH Message Service Handler, toteutetun ebms:n viestikäsittelijä, vastaanottaa viestejä. (OASIS 2002) Orkestrointi Organisaation sisäisten liiketoimintaprosessien tapahtumien keskinäinen järjestys ja kuvaus. (O Reilly 2006) PIP Partner Interface Process. (RosettaNet 2002) PKCS Public-Key Cryptography Standards, salausmenetelmiä julkiseen avaimeen perustuen. (Wikipedia 2006k) RFC Request For Comments, asiakirjoja, jotka kuvaavat Internetin erilaisia teknisiä käytäntöjä. (Wikipedia 2006l) RNIF Rosettanet Implementation Framework, B2B -integrointi standardi. (RosettaNet 2002) S/MIME Secure MIME, määrittelee suojatun MIME:n.(Wikipedia 2006m) SHA-1 Tiivistealgoritmi. (Wikipedia 2006n) SMTP Simple Mail Transfer Protocol, sähköpostiprotokolla. (Wikipedia 2006o) SOAP Simple Object Access Protocol, protokolla tiedonsiirtoon, käyttää XML:ää. (Wikipedia 2006p) UN/EDIFACT United Nations/Electronic Data Interchange For Administration, Commerce, and Transport, YK:n määrittelemä EDI standardi. (Wikipedia 2006e) X.509 Standardi määrittelemään digitaalinen sertifikaatti. (Wikipedia 2006q) XML Extensible Markup Language. XML-kieli on metakieli, eli kieli jolla voidaan kuvata toisia kieliä. (Wikipedia 2006r) XML Signature XML dokumentin allekirjoitusmenetelmä. (Wikipedia 2006s) 1.7 Raportin rakenne Tämä tutkimusraportti jakautuu seuraavasti eri kappaleisiin: 1. Johdanto. Tämä kappale sisältää taustatietoa tutkimuksesta, tavoitteet, tutkimusta ohjaavat tutkimuskysymykset, laajuuden, käytetyt menetelmät, sanaston, raportin rakenteen kuvauksen sekä tutkimuksen aikataulun. 2. Yleisesittely. RNIF, ebms sekä AS2 standardien yleisesittelyt. 3. Tekninen vertailu. Teknisten ominaisuuksien vertailu sekä erilaisten 4

13 standardien, kuten SOAP tai XML, käyttö tarkasteltavissa standardeissa. 4. Tietosisältöjen vertailu. Standardien kuljetuskehyksessä olevien tietojen, kuten otsikkosisältöjen sekä viestien perusrakenteiden vertailu. 5. Toiminnallisuus. Standardien toiminnallisuus, kuten virheraportointi ja turvallisuus sekä standardin soveltuvuus koreografian vai orkestroinnin määrittelyyn. 6. Signalointi. Standardien signalointimenettelyjä, kuten kuittausviestikäytännöt. 7. Ohjelmistotuki. Standardeja tukevia ohjelmistoja on listattu tässä kappaleessa. 8. Johtopäätökset ja pohdinnat. Tutkimuksen johtopäätösten esittely. 9. Yhteenveto. 1.8 Aikataulu Tutkimus tehtiin TKK:n Ohjelmistotuotannon ja -liiketoiminnan laboratorion kurssilla T Tietojärjestelmien integroinnin erikoiskurssi syksyllä Tutkimuksen tekemisessä noudatettiin kurssin asettamia aikarajoja. Nämä kurssin asettamat aikarajat on alla lihavoitu. TIEKE:n (Tietoyhteiskunnan kehittämiskeskus ry.) edustajan kanssa yhteisiä tapaamisia on pidetty noin kerran viikossa Projektisuunnitelma valmis Taustatutkimusta ja kirjallisuuskatsaus Yleiskatsaukset standardeihin Tekniset katsaukset 6.11 Toiminnalliset katsaukset 8.11 Teknisen vertailun koonti ja kappaleen kirjoitus 8.11 Signalointikatsaukset Yleiskatsausten koonti ja kappaleen kirjoitus 5

14 10.11 Toiminnallisen vertailun koonti ja kappaleen kirjoitus Ohjelmistotukikatsaukset Signalointivertailun koonti ja kappaleen kirjoitus Ohjelmistotukivertailun koonti ja kappaleen kirjoitus Raportin kokoaminen ja asettelu Ensimmäinen versio valmis Ensimmäisen version katselmointi 7.12 Raportti 95 % valmis Raportin katselmointi Tutkimuksen esittely seminaarissa 6

15 2 Yleisesittely Jotta pystyisi tekemään valintoja eri standardien välillä, on myös ymmärrettävä ainakin yleisellä tasolla mistä missäkin standardissa on kyse. On hyvä tietää kenen julkaisijan toimesta ko. standardi on tehty ja mitä se pääpiirteissään tarkoittaa. Esimerkkinä tyypillisestä B2B-integrointitapahtumasta voidaan nähdä tilaus, joka on esitetty kuvassa 2.1. Ensin taustajärjestelmä lähettää sanoman BPM-ohjelmistolle (Business Process Management), joka muodostaa siitä standardin toteuttavan sanoman (salaus, allekirjoitus, yms.). Seuraavaksi sanoma lähetetään vastaanottajalle internetin (HTTP(S)) yli. Vastaanottajan BPM-ohjelmisto varmentaa sanoman ja muodostaa vastaanottajan taustajärjestelmän ymmärtämän sanoman, joka lähetetään vastaanottajan taustajärjestelmälle. Seuraavaksi muodostetaan kuittaussanoma ja se lähetetään alkuperäiselle lähettäjälle internetiä käyttäen. Lopuksi alkuperäinen lähettäjä varmentaa sanoman perillemenon kuittaussanomasta. Vertaillut standardit toteuttavat kuvassa esiintyvistä toiminnoista viestin lähetyksen ja tarkistuksen sekä kuittauksen muodostamisen, lähetyksen ja vastaanoton. 7

16 Kuva 2.1 Esimerkki - tyypillinen B2B -tapahtuma 2.1 RosettaNet Implementation Framework RosettaNet on voittoa tuottamaton järjestö, jonka tehtävänä on ohjata liiketoimintaprosessien standardointia. RosettaNet-standardi käsittää yritystenväliset standardiprosessit (Partner Interface Process, PIP), näihin liittyvät viestit, sana- ja koodikirjat yhteisen termistön ja koodiston luomiseksi sekä RNIF (RosettaNet Implementation Framework) sanomavälityspalvelustandardin (RosettaNet, 2006). Standardin osista vain RNIF käsitellään tässä vertailussa. 8

17 RNIF määrittelee sekä prosesseihin liittyvien liiketoimintaviestien että signalointiviestien lähettämiseen. Eri liiketoimintaviestit on määritelty omassa standardissaan. Signalointiviestejä on kahta päätyyppiä, positiivisia ja negatiivisia. Nämä vastaavat sitä että vastaanottaja ymmärsi tai ei ymmärtänyt vastaanotettua sanomaa. RNIF tukee sekä viestinvälitystä suoraan osapuolelta toiselle tai keskitettyä mallia jossa kaikki viestit lähetetään operaattorille joka reitittää viestin sen lopulliseen määränpäähän. (RosettaNet, 2002, s. 11 ja 58) Viestien luottamuksellisuus voidaan varmistaa salakirjoittamalla ne. Myös osapuolten välinen autentikointi ja kiistämättömyys ovat tuettuja. 2.2 ebms (ebxml Messaging Service) OASIS -organisaation määrittelemä ebms, (Electronic Business extensible Markup Language (XML) Messaging service), on sähköisen kaupankäynnin standardi, joka määrittelee XML-viestejä käyttävän sanomanvälityspalvelun. EbMS on yksi OASISorganisaation spesifikaatioista, jotka yhdessä pyrkivät luomaan yhtenäisen, keskitetyn ja sähköisen kauppapaikan yrityksille, käyttäen XML -viestejä. Yksi ebms:n eduista on, että se on lähes riippumaton kommunikointiin käytettävästä siirtoprotokollasta, jolloin ebms- viestit voidaan lähettää esimerkiksi käyttäen. Ainoana rajoituksena on, että siirtoprotokolla tukee SOAP-viestien lähetystä. EbMS spesifikaatio määrittelee viestien kuljetuksessa käytetyn "kirjekuoren", joka sisältää lähetettävän viestin. EbMS:n käyttämän kirjekuori on tarkoitettu toimimaan käyttäen SOAP:ia (Simple Object Access Protocol), josta johtuen myös liitynnät alempiin kuljetuskerroksiin on toteutettu käyttäen SOAP-liityntöjä. Lisäksi ebms-määritelmään kuuluvat käytetyt toiminnot sanomanvälitykseen sekä itse protokolla. Turvallisuus sanomanvälityksessä on määritelty viestien salauksella, tunnistamisella sekä viestien yhtenäisyydellä. Tunnistamiseen käytetään apuna digitaalisia sertifikaatteja, 9

18 salaus hoidetaan julkisten ja yksityisten avainten avulla. Viestien välityksessä käytetään saanti-ilmoituksia, joilla varmistetaan että viestit menevät perille. Yksi tärkeimmistä eduista ebms sanomanvälitysmenetelmää käytettäessä on älykkäiden ebxml -otsakkeiden tuki, mistä on suuri hyöty yrityksille jotka käyttävät jo ebxml:ää. Myös yritykset, jotka eivät käytä ebxml:ää, voivat käyttää ebms:ää, sillä ebms luo tarvittavat otsakkeet viesteihin. Eduiksi voidaan myös mainita useiden liitteiden lähettäminen yhdellä kertaa, sillä liitteet pakataan hyötykuormaksi viesteihin. 2.3 AS2 "Applicability Statement 2", lyhennettynä AS2, on spesifikaatio datan siirtämiseen turvallisesti ja luotettavasti Internetin kautta. Se on kuvattu yksityiskohtaisesti RFC:ssä (The Requests for Comments) AS2:een viitataan usein EDIINT:nä ("EDI over the Internet") tai AS2 EDIINT. Pääideana AS2:ssa on laittaa EDI tiedosto AS2 kirjekuoreen ja sitten lähettää se Internetin yli käyttäen HTTP POST pyyntöä. Turvallisuus saavutetaan käyttämällä digitaalisia sertifikaatteja ja kryptausta. AS2 määrittää miten otetaan yhteys, toimitetaan ja kuitataan data. Yleensä lähetetään EDI-sanomia (Electronic Data Interchange), mutta sanomat voivat olla myös esimerkiksi XML:ää. AS2 siis yleensä tarkoittaa EDItiedostojen lukemista ja kirjoittamista AS2 sanomista, mutta myös AS2 sanomien validitointa ja kuittaamista. AS2 toteutus on siis asiakas-palvelin ratkaisu ja asiakas ja palvelin keskustelevat toistensa kanssa Internetin välityksellä. Käyttöjärjestelmätasolla AS2 asiakas voi olla palvelin jollekin sovellus ohjelmistolle. Asiakas lähettää dataa palvelimelle, esimerkiksi jollekin kauppakumppanille. Kuittauksena sanomasta vastaanottava sovellus lähettää vahvistuksen, MDN:n (Message Disposition Notification), takaisin lähettäjälle. AS2 kehitettiin vuonna 1999 EDI standardi -yhteisön jäsenien toimesta tarkoituksena 10

19 käyttää internetiä toimitusväylänä (EDIINT). AS2 standardi perustuu voimakkaasti aikaisempiin EDI toimintatapoihin ja EDI-tyyppisten sanomien toimittamiseen. Useat toimittajat ovat tehneet yhteensopivia tuotteita, jotka käyttävä AS2:sta sanomanvälitykseen ja ne ovat tarkoitettuja käytettäväksi EDI -järjestelmien kanssa. USA:ssa AS2 on yleisesti käytetty standardi e-bisneksessä, erityisesti vähittäismyyjien toimesta ja niiden yhtiöiden jotka tarvitsevat turvallisia standardeja. Suuri vähittäismyyntiketju Wal-Mart's on aloittanut AS2:n käytön vuonna 2002 (Computerworld 2002), myös monet muut suuret USA:laiset yhtiöt käyttävät AS2:sta. 11

20 3 Tekninen vertailu Tekninen vertailu on erityisen tärkeää siksi että yritykset voisivat tehdä järkeviä päätöksiä perustuen siihen mitä standardeja tietyt B2B -integrointi standardit tukevat. Koska ensinnäkin luonnollisesti on tärkeää se mikä on ko. liiketoiminta-alan yleisimmin käytetty (de facto) standardi B2B-integroinnissa, mutta myös se mitä standardeja jo kulloisenkin yrityksen taustajärjestelmät käyttävät. Esimerkkinä voisi ajatella, että jos jonkun yrityksen sisäiset järjestelmät käyttävät keskinäiseen tiedonsiirtoon XML -sanomia niin olisi hyvä jos B2B -integroinnissa käytettävä standardikin tukisi XML -formaattia. Tässä kappaleessa käydään läpi RNIF, ebms ja AS2 standardien käyttämät standardit. Ensin esitellään lyhyesti jokaisen standardin käyttämät standardit ja lopuksi tehdään yhteenveto käytetyistä standardeista vertailun helpottamiseksi. 3.1 RNIF RNIF:ssä lähetettävä viesti kääritään MIME-kuoreen, jonka sisällä viestin eri otsikkokentät ovat omia XML-dokumenttejaan. Myös viestin varsinainen liiketoimintasisältö on yleensä XML-dokumentti, tosin se voi joissain tapauksissa olla myös muussa muodossa mikäli näin prosessikuvauksessa (PIP) määritellään. Viestin mukana lähetettävät liitteet voivat sisältää mitä tahansa dataa missä tahansa muodossa. XML-muotoisten viestien määrittelyt ovat yleensä DTD-muodossa, mutta myös XML Schema -muotoisia kuvauksia voidaan käyttää. Viesteissä käytettävän merkistön tulee olla UTF-8 tai UTF-16. (RosettaNet, 2002, s. 15) Siirtomuotoina RNIF käyttää tai SMTP:tä. Mikäli viesti halutaan salata tai allekirjoittaa se voidaan tehdä S/MIME ja PKCS protokollia käyttäen. Viesti voidaan salata myös siirron aikana käyttäen HTTPS-siirtomuotoa ja X.509 sertifikaatteja. Sertifikaattien avulla voidaan myös toteuttaa lähettäjän ja vastaanottajan 12

21 välinen autentikointi. (RosettaNet, 2002,s ) 3.2 EbMS EbMS on suunniteltu olemaan siirtoprotokollasta riippumaton ja kuljettamaan minkä tyyppisiä viestejä tahansa. Lähetettävät sanomat voivat olla mitä tahansa digitaalisessa muodossa, kuten esimerkiksi XML tiedostoja, tietokannan tauluja tai EDI viestejä. Lähetettävät sanomat pakataan ebxml objektiksi, joka sitten lähetetään. (OASIS 2002) EbMS on rakennettu SOAP-protokollan päälle kerroksittaiseksi. Koska ebms spesifioitiin neutraaliksi siirtoprotokollan suhteen, voidaan käyttää mitä tahansa siirtoprotokollaa. Koska ebms käyttää SOAP:ia ja SOAP Attachments (Liitteet) pohjanaan, tukee ebms kaikkia siirtoprotokollia, joita SOAP tukee. (OASIS 2002) EbXML viesti rakentuu siten, että ulommaisena kirjekuorena on SOAP Attachments, joka käyttää Multipurpose Internet Mail Extensions (MIME):a. Tämän kirjekuoren sisällä on vähintään kaksi MIME osaa, joista toinen on SOAP (version 1.1) yhteensopiva viesti. Seuraavat MIME osat sisältävät varsinaisen lähetettävän sanoman. Ensimmäinen MIME osa, SOAP -viesti, on XML-dokumentti, jossa on SOAP-viestin kirjekuori-osa. (OASIS 2002) EbMS sanomanvälitys käyttää edellä kuvatun mukaisesti siis alustanaan SOAP:ia. Tämän lisäksi XML-dokumenteja käytetään kaikissa viesteissä, kuten myös MIME:a. Siirtoprotokollana voidaan käyttää esimerkiksi HTTP-protokollaa tai SMTP-protokollaa sekä mitä tahansa, jota käyttäen SOAP toimii. Luotettavaan viestien välitykseen voidaan käyttää XML Signature -menetelmää, jolloin ebxml-viesti allekirjoitetaan digitaalisesti. Viestien eheys voidaan varmistaa käyttämällä jotain salausmenetelmää, kuten XML Encryption tai S/MIME. (OASIS 2002) 13

22 3.3 AS2 AS2:ssa data pakataan käyttämällä normaaleja MIME-rakenteita. AS2:sta käytetään rakenteellisen bisnes-datan siirtämiseen Internetin välityksellä eri kauppakumppanien välillä. Rakenteellinen liiketoiminta -data voi olla XML:ää, EDI:ä ANSI EDI-X12 formaatissa tai UN/EDIFACT formaatissa tai melkeinpä missä tahansa muussa rakenteellisessa formaatissa. (RFC 4130) Dataa siirretään käyttämällä HTTP-protokollaa tai HTTPS-protokollaa, AS2:n edeltäjässä Applicability Statement 1 (AS1) käytetään taas SMTP-protokollaa. AS2-viesti voi olla tyyppiä MIME Security Multiparts, se voi olla moniosa/kryptattu ja moniosa/allekirjoitettu. AS2:ssa MDN (Message Disposition Notification) on pohja, jonka päälle kuittaukset ja allekirjoitetut kuittaukset määritetään. (RFC 4130) AS2 mahdollistaa turvallisen MIME:n (S/MIME) käytön, eli formaatin ja protokollan kryptatun allekirjoituksen ja/tai kryptaus palvelujen lisäämisen Internetin MIMEsanomiin. CMS (Cryptographic Message Syntax) kapselointi syntaksia käytetään mielivaltaisen sanoman digitaaliseen allekirjoitukseen, tiivistelmään, autentikointiin tai kryptaukseen. (RFC 4130) Digitaalisen allekirjoituksen yhteydessä käytettävä hash-algoritmi SHA-1, jota myös suositellaan käytettävän AS2:n yhteydessä. Tosin myös MD5 hash-algoritmi on sallittu AS2:ssa käytettäväksi digitaalisen allekirjoituksen yhteydessä. (RFC 4130) 3.4 Yhteenveto Kaikki standardit tukevat lähetettävän sanoman tyyppinä XML:ää, mutta myös EDI on hyvin tuettu. Yhteenvetona lähetettävien sanomien tyyppien osalta voisi todeta, että tuettujen sanomaformaattien skaala on hyvin laaja. Siirtoprotokollana tuetuin standardi on luonnollisesti HTTP, johon tämä työkin keskittyy, mutta myös HTTPS- ja SMTP - protokollille löytyy tukea. Salauksessa käytetään tyypillisesti S/MIME:ä ja 14

23 kirjekuoressa on käytetty kaikissa standardeissa MIME:ä. Vertailu tärkeimpien ominaisuuksien osalta löytyy seuraavasta taulukosta: Taulukko 3.1 B2B sanomanvälitysstandardien tekninen vertailu Lähetettävän sanoman tyyppi Siirtoprotokolla Salaus Allekirjoitus Kirjekuori AS2 ebms 2.0 RNIF 2.0 XML, EDI, ANSI XML, EDI tai XML, voi EDI-X12, mikä tahansa myös olla UN/EDIFACT tai digitaalinen muun muu rakenteellinen formaatti tyyppinen formaatti mikäli määritelty PIP:ssä Mikä tahansa HTTP tai HTTPS, aiempi AS1 käyttää SMTP:tä MIME Security Multiparts, S/MIME, CMS MIME Security Multiparts, S/MIME, CMS sekä allekirjoituspohja MDN. Allekirjoituksissa hash SHA-1 tai MD5 MIME standardit siirtoprotokolla, joka on yhteensopiva SOAP:n kanssa XML Encryption, S/MIME XML Signature, S/MIME MIME yhdessä SOAP:n kanssa HTTP, HTTPS SMTP S/MIME, PKCS, HTTPS yhdessä X.509:n kanssa tai S/MIME, PKCS MIME, jonka sisällä otsikot XMLdokumentteja 15

24 4 Tietosisältöjen vertailu Eri standardit määrittelevät erilaiset sisällöt ja rakenteet sanomien otsikkoihin sekä itse viesteihin. Näitä tietoja tarvitaan, jotta voidaan tarkemmin ja yksityiskohtaisesti tarkastella eri standardeja, kuten millaisia tietoja sanomien otsikoissa liikkuu. Näitä tietoja hyödyntämällä voidaan arvioida myös kyseisen standardin käyttöönottoon liittyvää työmäärää perustuen tarvittaviin tietoihin sanomissa. Tässä kappaleessa esitellään RNIF, EbMS ja AS2 standardien tietosisällöt, kuten millaisia tietoja otsikoissa ja sanomissa käytetään kyseisissä standardeissa. Kunkin standardin kohdalla on esimerkkejä otsikoista, joita kyseinen standardi käyttää. Kappaleen lopussa on yhteenveto sekä taulukko sanomien otsikkosisällöistä. 4.1 RNIF RNIF-viesti on rakenteellisesti MIME multipart/related -kuori jonka sisällä ovat XMLmuotoiset otsikkokenttätiedostot ja varsinainen viestitiedosto sekä mahdolliset liitetiedostot jotka voivat olla missä tahansa muodossa. Viestitiedosto ja liitteet muodostavat viestin varsinaisen hyötykuorman. Viestin rakenne on esitetty kuvassa

25 Kuva 4.1 RNIF-viestin rakenne (RosettaNet 2002) Mikäli viesti halutaan salata tai allekirjoittaa voi osa tiedostoista olla S/MIME -kuoren sisällä tai koko kuori voidaan ympäröidä Multipart/signed kuorella, kuten kuvassa 4.2. Kuva 4.2 RNIF-viestin allekirjoitus (RosettaNet 2002) 17

26 Otsikot on ryhmitelty kolmeen eri ryhmään: Preamble Delivery Service Header Service Content Jokainen otsikkoryhmä on omassa XML-dokumentissaan. Preamble otsikko sisältää tiedot siitä mikä standardi ja standardin versio on kyseessä. Preamble otsikkoja ei voi salata. Delivery otsikko sisältää viestin yksilöllisen tunnisteen sekä tiedot lähettäjästä, vastaanottajasta ja siitä pitääkö viestiä kuljettaa salattuna. Delivery otsikkoja ei voi salata. Service otsikon alla välitetään tieto viestin prosessiympäristöstä eli siitä minkä prosessin osana viesti on lähetetty ja mikä sen funktio on, missä roolissa organisaatio on viestin lähettänyt (esim. myyjä, ostaja). Lisäksi se sisältää muita tietoja viestistä esimerkiksi onko kyseessä testiviesti ja kuinka monta liitettä viestissä on. Service otsikot on mahdollista salata. Minkä aktiviteetin osana viesti on lähetty (esim. Create Purchase Order) Lähettäjärooli ja -palvelu Vastaanottajarooli ja -palvelu Mihin viestiin tämä viesti on vastaus Viestin liitteet ja niiden tunnisteet Mihin prosessiin (PIP) viesti liittyy Mihin prosessi-instanssiin viesti liittyy Kuka prosessin aloitti 4.2 EbMS Ebms -sanomanvälityspalvelussa lähetetään EbXML tyyppisiä viestejä, jotka rakenteeltaan pohjautuvat MIME/moniosa viesteihin. Ulommaisena kerroksena ebxml viestissä on varsinaisen siirtoprotokollan kirjekuori, esimerkiksi HTTP tai SMTP 18

27 kirjekuori otsikkoineen (kuvassa 4.3 keltaisella värillä). Kuva 4.3 EbMS-viestin rakenne (OASIS 2002) Sen sisäpuolella on SOAP With Attachments (SOAP ja liitteet) kirjekuori (kuvassa 4.3 vaalean sinisellä). Tämän kuoren sisällä on peräkkäin kaksi tai useampia MIME osaa (kuvassa 4.3 vihreällä), joista ensimmäinen on aina pakollinen. Tämä ensimmäinen MIME osa on versio 1.1 mukainen SOAP viesti (kuvassa vaalean ruskealla), jonka kirjekuoren sisällä on SOAP kirjekuoren otsikko sekä SOAP runko-osa (kuvassa 4.3 harmaalla). Ensimmäisestä MIME osaa seuraavat MIME-osat sisältävät varsinaisen hyötykuorman, eli välitettävän sanoman. Näitä hyötykuormaa sisältävia MIME-osia voi olla useita peräkkäin ebxml-viestissä, kuitenkin aina ensimmäisessä MIME-osassa on pakollisena edellä kuvattu SOAP viesti. Ulommainen ebxml otsikko eli SOAP with Attachments otsikko (kuvassa 4.3 vaalean sinisellä, Message Package ) näyttää esimerkiksi kuten kuvassa 4.4: 19

28 Kuva 4.4 EbXML otsikko (OASIS 2002) Tämä otsikko pitää sisällään seuraavia tietoja: Content-Type (sisällön tyyppi) type (tyyppi) boundary (rajan signaali) start (viestin alun signaali) Edellisen sisällä oleva ensimmäisen MIME osan otsikko, kuvassa 4.3 vihreällä ( Header Container ) on esimerkiksi kuten kuvassa 4.5: Kuva 4.5 MIME-otsikko (OASIS 2002) Otsikon sisältämät tiedot ovat: Content-Type (sisällön tyyppi) Content-ID (sisällön tunniste) charset (merkistö) Sanomaosan, eli toinen ja siitä eteenpäin ebxml viestissä olevan MIME osan, otsikko 20

29 voisi olla esimerkiksi kuten kuvassa 4.6 (kuvassa 4.3 esitetty Payload Container(s)): Kuva 4.6 Lähetettävän sanoman MIME-otsikko (OASIS 2002) Tähän otsikkoon kuuluvat tiedot: Content-ID (sisällön tunniste) Content-Type (sisällön tyyppi) Edellisten lisäksi SOAP-kirjekuori sekä SOAP-runko sisältävät attribuutteja: xmlns (XML Namespace) xmlns:xsi (XML Namespace Schema Instance) xsi:schemalocation (XML Schema Instance Schema location) Kaikissa ebxml viesteissä on oltava mukana MessageHeader elementti, joka on SOAPotsikon yhteydessä. Tässä elementissä määritellään seuraavia tietoja: id version SOAP mustunderstand (vastaanottajan tulee ymmärtää SOAP viesti tai hylätä se) From o PartyId o Role To o PartyId o Role CPAId ConversationId Service Action MessageData o MessageId o Timestamp 21

30 o RefToMessageId o TimeToLive DuplicateElimination Description Esimerkki MessageHeader -elementistä on seuraavanlainen: <eb:messageheader eb:id=" " eb:version="2.0" SOAP:mustUnderstand="1"> <eb:from> <eb:partyid>uri:example.com</eb:partyid> <eb:role>http://rosettanet.org/roles/buyer</eb:role> </eb:from> <eb:to> <eb:partyid eb:type="sometype">qrs543</eb:partyid> <eb:role>http://rosettanet.org/roles/seller</eb:role> </eb:to> <eb:cpaid>http://www.oasis-open.org/cpa/123456</eb:cpaid> <eb:conversationid> </eb:conversationid> <eb:service eb:type="myservicetypes">quotetocollect</eb:service> <eb:action>newpurchaseorder</eb:action> <eb:messagedata> <eb:messageid>uuid-2</eb:messageid> <eb:timestamp> t12:19:05</eb:timestamp> <eb:reftomessageid>uuid-1</eb:reftomessageid> </eb:messagedata> <eb:duplicateelimination/> </eb:messageheader> Kuten esimerkeistä nähdään, viestien otsikot ovat XML muotoisia ja siten myös ihmissilmälle helppoa luettavaa. Näiden otsikoiden lisäksi ebxml viestissä voi olla mukana useita erilaisia elementtejä, kuten esimerkiksi XML Signature, jos käytetään allekirjoitusta. SOAP With Attachments -otsikko MIME -otsikko SOAP -kuori SOAP -otsikko SOAP -viestin runko /SOAP -viestin runko SOAP -otsikko /SOAP -kuori Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen 22

31 /MIME -otsikko MIME -otsikko Lähetettävä sanoma /Lähetettävä sanoma /MIME -otsikko /SOAP With Attachments -otsikko Pakollinen Vain, jos sanoma Vain, jos sanoma Vain, jos sanoma Vain, jos sanoma Pakollinen 4.3 AS2 AS2 sanoma koostuu MIME-formaatista HTTP sanoman sisällä sekä lisäksi muutamasta erityisestä AS2-otsikosta. Sanoman yksityiskohtainen sisältö riippuu siitä käytetäänkö allekirjoitusta, kryptausta, MDN-kuittausta ja/tai niiden eri kombinaatioita. HTTPprotokollan osalta voidaan huomioida, että pyyntörivi on muotoa "POST Request-URI HTTP/1.1" AS2 spesifisiä (header) otsikkokenttiä ovat AS2-versio, joka voi olla joko 1.0 tai 1.1, ja AS2 järjestelmä tunnisteet, joiden avulla vastaanottava osapuoli voi tunnistaa lähettävän osapuolen. AS2 järjestelmä tunnisteita ovat keneltä sanoma on tullut ja kenelle se lähetetty (AS2-From ja AS2-To). Periaatteessa sanoman sisällön kannalta voidaan katsoa, että on olemassa kahdenlaisia AS2-sanomia. Ensinnäkin on varsinaisen datan sisältäviä sanomia ja toiseksi on kuittaus eli MDN sanomia. Alla olevassa esimerkkisanomassa on kyseessä allekirjoitettu sanoma, johon odotetaan allekirjoitettua synkronoitua kuittausta (RFC 4130): POST /receive HTTP/1.0 Host: :80 User-Agent: AS2 Company Server Date: Wed, 31 Jul :34:50 GMT From: AS2-Version: 1.1 AS2-From: "\" as2name \"" AS2-To: Subject: Test Case 23

32 Message-Id: Disposition-Notification-To: Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional,sha1 Content-Type: multipart/signed; boundary="as2boundary1as2"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Length: as2boundary1as2 Content-Type: application/edi-x12 Content-Disposition: Attachment; filename=rfc1767.dat [ISA...EDI transaction data...iea...] --as2boundary1as2 Content-Type: application/pkcs7-signature [omitted binary pkcs7 signature data] --as2boundary1as2 Koska AS2 on suuniteltu välittämään EDIFACT-sanomia, niin on hyvä käsitellä myös EDIFACT-sanoman sisältöä, koska ne pitävät sisällään datan lisäksi toiminnallisuutta. EDIFACT sanoman segmentit ovat kehystettyjä "header-trailer" -segmenteillä, joita kutsutaan palvelu-segmenteiksi. EDIFACT sanoma koostuu siis seuraavista osista: Service String Advice UNA Ehdollinen Interchange Header UNB Pakollinen Functional Group Header UNG Ehdollinen Message Header UNH Pakollinen User Data Segments Sanoman mukaan Message Trailer UNT Pakollinen Functional Group Trailer UNE Ehdollinen Interchange Trailer UNZ Pakollinen Sanomanvälityksen kannalta olennaisin on UNB -segmentti, joka taas koostuu seuraavista osista: Syntaksitunniste (Syntax identifier) Sanomavaihdon lähettäjä (Interchange sender) Sanomavaihdon vastaanottaja (Interchange recipient) Päiväys (Date/Time of preparation) Sanomavaihdon valvonta referenssi (Interchange control referance) 24

33 Vastaanottajan viite, salasana (Recipients reference, password) Sovellus viite (Application reference) Prosessointi prioriteetti (Processing priority code) Kuittauspyyntö (Acknowledgement request) Kommunikaatio-sopimustunniste (Communication agreement id) Testi-indikaattori (Test indicator) 4.4 Yhteenveto Tämän osion kappaleissa on esitelty RNIF, ebms sekä AS2 standardien sanomissa olevia tietoja. Näistä yhteenvetona on taulukko 4.1, josta selviää hyvin että esimerkiksi lähettävän ja vastaanottavan organisaation tiedot on kaikissa standardeissa melko samanlaiset. Selkeänä eroavaisuutena on sen sijaan prosessitiedot, joita ei ebms standardissa suoraan määritellä. 25

34 Taulukko 4.1 Yhteenveto tietosisällöistä RNIF ebms AS2 Yleiset tiedot Noudatettava standardi X X UNB Standardin versio X X X Lähettäjän ja vastaanottajan tiedot Lähetäjäorganisaatio X X UNB Lähettäjän rooli X X Vastaanottajaorganisaatio X X UNB Vastaanottajan rooli X X Prosessi- ja kontekstitiedot Sovellettava prosessi X UNB Prosessi-instanssin tunniste X UNB Vastauksena viestiin X Sovellus UNB Muut Viestin uniikki tunniste X X UNB Prioriteetti UNB Kuittauspyyntö X X Testiviesti X X UNB Salasana UNB HUOM! AS2:n kohdalla UNB segmentit ovat luonnollisesti mukana vain EDIFACTsanomissa. 26

35 5 Toiminnallisuus Keskeinen osa eri standardeja on se miten ne määrittelevät tiettyjen toimintojen toteutuksen. Näitä toimintoja ovat mm. virheraportointi sekä viestinnän koreografiat ja orkestroinnit sekä tietoturvaominaisuuksiin kuuluvat viestin eheyden, luottamuksellisuuden ja kiistämättömyyden vaatimukset. Lisäksi eräs hyvin tärkeä ominaisuus yritystenvälisten integraatioiden yleistyessä on se mahdollistaako standardi niin sanotun viestinnän operaattorimallin, jossa eri osapuolet eivät lähetä viestejä toisilleen vaan operaattorille joka viestin otsikkotietojen perusteella välittää viestin joko seuraavalle operaattorille tai vastaanottajalle. Mikäli tämä ei ole mahdollista joudutaan jokaisen integraation tekniset yksityiskohdat sopimaan erikseen osapuolten välillä mikä integraatioiden lukumäärän kasvaessa lisää työmäärää ja vaikeuttaa ympäristön ylläpitämistä. Operaattorimalli saattaa vaarantaa viestin tietoturvan, mikäli operaattorille joudutaan antamaan avaimet salatun viestin purkua varten. Tämä on tarpeen, mikäli viestin vastaanottaja on määritelty viestin salatussa osassa. Tosin asiakas ja operaattori tekevät aina sopimuksen salassapidosta, joten tietoturvaongelmat ovat sopimusrikkomuksia ja niitä käsitellään sen mukaisesti. 5.1 RNIF Virheraportointi RNIF määrittelee kaksi mekanismia virhetilanteiden raportointiin. Signaaliviestejä käytetään kommunikoimaan sanoman vastaanotosta ja havaituista virheistä prosessi-instanssin sisällä. Signaaleita siis käytetään paitsi virhetilanteiden 27

36 raportointiin myös kuittaamaan viesti vastaanotetuksi. Prosessiohjausprosesseja (Process Control PIP) käytetään kommunikoimaan prosessin tilaan liittyviä virheitä prosessi-instanssin ulkopuolella. Esimerkkinä voidaan käyttää tilannetta jossa prosessi on poikkeustilanteen takia tilassa "Valmis" toisessa järjestelmässä ja toisessa järjestelmässä tila on "Ajossa" koska vastaanotettua viestiä ei pystytty käsittelemään. Signaalit lähetetään normaaleina RNIF-viesteinä joissa sisältönä (Service Content) on signaalidokumentti. Prosessiohjaus-PIPien viestit ja koreografiat on määritelty omissa määrittelyissään. Koreografia ja orkestrointi RosettaNet-standardi käsittelee pelkästään yritystenvälisiä prosesseja ja siten koreografioita. Sisäiset prosessit ja niiden orkestrointi eivät suoranaisesti kuulu RosettaNetin alueeseen. Yritystenväliset prosessit (RosettaNet-terminologiassa PIP, Partner Interface Process) on määritelty omissa standardeissaan jotka on jaettu alueittain ja aiheittain klustereihin ja segmentteihin. RNIF-standardi on suunniteltu tarkkaan PIPviestien lähetykseen, eikä muiden viestien välittäminen onnistu suoraan standardia laajentamatta. Turvallisuus RNIF-standardissa viestin eheys varmistetaan lähettäjän allekirjoituksella käyttäen S/MIME (RFC 2311) standardia. Vastaanottaja varmentaa allekirjoituksen käyttäen S/MIMEn ja PKCS:n vakiomekanismeja. Samalla varmennetaan myös lähettäjän identiteetti. Se, pitääkö viesti allekirjoittaa, on määritelty erikseen prosessimäärittelyissä. Allekirjoittamattomien viestien eheyden osalta luotetaan TCP/IP-protokollien virheenkorjausmekanismeihin. RNIF-viestin allekirjoitus on esitetty kuvassa 5.1. Viestien kiistämättömyys toteutetaan samalla sähköisellä allekirjoituksella kuin 28

37 eheydenkin osalla, siten että mukana on MD5 tai SHA-1 muotoinen tiiviste viestistä. Vastaanottajan velvollisuutena on säilyttää vastaanotettu allekirjoitettu viesti yhteisesti sovitun ajan, tyypillisesti 3-7 vuotta. Myös kuittausviestit voidaan allekirjoittaa ja näin varmistaa se ettei vastaanottaja voi kiistää vastaanottaneensa kuitattua viestiä. Kuva 5.1 RNIF viestin allekirjoitus (RosettaNet 2002) Luottamuksellisuus saadaan aikaan käyttämällä asymmetristä salakirjoitusta ja salaamalla lähetettävä viesti. Tällöin vain viestin lopullinen vastaanottaja voi lukea viestin. Viestistä voidaan salata joko pelkästään viesti ilman otsakkeita tai viesti ja Service-otsikkotiedosto, jolloin salaamatta jäävät pelkästään viestin vastaanottaja- ja lähettäjätiedot sekä standardin versiotiedot. Kuvat 5.2 ja 5.3 esittävät tilanteen, jossa salakirjoitetaan sekä viesti että Service-otsikot. 29

38 Kuva 5.2 RNIF viestin salaus, luodaan Encrypted Payload Container (RosettaNet 2002) Kuva 5.3 RNIF-viestin salaus, salaamattomat otsikkotiedot paketoidaan salatun osion kanssa (RosettaNet 2002) RNIF määrittelee että Service-otsikot voidaan sijoittaa joko viestin salattuun tai salaamattomaan osaan. Vastaanottajaotsikoiden täytyy kuitenkin aina olla salaamattomia. Siirron aikana voidaan käyttää salattua HTTPS-protokollaa selväkielisen sijaan. Tällöin satunnainen salakuuntelijakaan ei pääse lukemaan edes vastaanottajatietoja vaan ne ovat ainoastaan mahdollisen viestiä reitittävän osapuolen luettavissa. Viestitystopologiat RNIFin avulla viestejä voidaan välittää joko suoraan osapuolelta toiselle tai niin 30

39 sanottua operaattorimallia käyttäen jossa viestit lähetetään kolmannelle osapuolelle joka reitittää viestit vastaanottajalle. Tämän mahdollistaa se, etteivät vastaanottajaotsikot ole koskaan salattuja, eli myös operaattori pystyy lukemaan ne ja selvittämään kenelle viesti pitää välittää. 5.2 EbMS Virheraportointi EbMS viestikäsittelijä (Message Service Handler, MSH) sisältää erillisen moduulin, joka tarkkailee ebxml viestejä mahdollisten virheiden varalta. Huomattuaan virheen, tämä moduuli ilmoittaa yhteyden toisessa päässä olevalle viestikäsittelijälle virheestä. Mikäli vastaanottavan MSH:n SOAP -viestien käsittelijämoduli ei kykene jäsentämään jotain saamaansa viestiä, voi kyseinen SOAP -prosessori palauttaa SOAP vikaviestin, jolloin myös tällaista SOAP-vikaviestiä tulee MSH:n virhemoduulin tukea. Tällöin vikaviestit ja niissä olevat vikakoodit ovat SOAP -standardin mukaisia. EbMS määrittelee kuitenkin myös omat vikaviestinsä, jotka voivat koskea esimerkiksi turvallisuutta tai luotettavan yhteyden häiriöitä. Vikaviesti sisältää ErrorList -elementin, joka sisältää otsikon tälle elementille sekä yhden tai useampia Error -elementtejä. Nämä Error -elementit sisältävät varsinaiset vikakoodit sekä esimerkiksi id-, location- ja Description -kentät. Location -kenttä määrittelee missä kohdassa viestiä virhe on, ja Description määrittelee sanallisessa muodossa virheen. Virhekoodit on jaoteltu ebxml -viestin elementeissä oleviin sekä ei-xml virheisiin. Koreografia ja orkestrointi EbMS standardi ei määrittele orkestrointia, sillä se on tarkoitettu yritysten väliseen viestintään. Täten ebms kuvaa ainoastaan koreografian, joka toteutuu siten, että lähettäjän lähettämään viestiin vastaanottaja vastaa kuittauksella, mikäli käytetään 31

40 luotettavaa tiedonsiirtoa. Turvallisuus EbMS käyttää XML Signature -menetelmää, jolla allekirjoitetaan digitaalisesti ebxml viestin osia. Allekirjoitus tapahtuu XML Signature -standardin mukaisesti. Luottamuksellisuus ebms standardissa saavutetaan XML Encryption -menetelmällä. Sitä käyttäen voidaan salata EbXML viestin osia ja sekä SOAP -otsikko. EbXML-viestin lähetettävä sanoma voidaan salata vielä erikseen jollain muulla menetelmällä, jonka yhteyden osapuolet sopivat mahdollisesti erikseen. Kiistämättömyys varmistetaan allekirjoittamalla lähetettävä sanoma digitaalisesti ja liittämällä sanomaan kuittauspyyntö, jolloin vastaanottaja kuittaa sanoman tulleen perille sekä liittää kuittausviestiin koosteen alkuperäisestä sanomasta. Viestintätopologiat Sanomat ebms standardia käyttäen lähetetään joko suoraan vastaanottajalle tai käyttäen operaattorimallia, jossa viesti ensin lähetetään kolmannelle osapuolelle. Tämä kolmas osapuoli voi esimerkiksi olla aikaleimapalveluna vastaanottajalle sekä lähettäjälle tai ainoastaan toimia talleta ja lähetä -palveluna. Digitaalinen allekirjoitus mitätöityy, mikäli välillä oleva kolmas osapuoli muuttaa tietoja sanomassa. 5.3 AS2 Virheraportointi Palautettavat statuskoodit riippuvat myös HTTP operaatioiden statuskoodeista. Esimerkiksi statuskoodia 401 yhdessä WWW-autentikointi otsikon kanssa käytetään kertomaan että asiakkaan pitää toistaa pyyntö autentikointi otsikon kanssa. Muut 32

41 eksplisiittiset statuskoodit ovat dokumentoituja RFC 2616:ssa. Virheille pyyntö-uri:ssa, kuten 400 ( Bad Request ) tai 404 ( Not Found ) ja vastaaville, ko. status koodit ovat asianmukaisia. Nämä koodit ja niiden selitykset ovat myös dokumentoituja RFC 2616:ssa. Uudelleenlähetyksiä ei ole syytä tehdä jos virhe ei ole ohimenevä tai jos uudelleenlähetys on eksplisiittisesti ei-toivottu. Jos HTTP asiakas ei onnistu lukemaan HTTP-palvelimen vastaustietoa, niin POSTkomento voidaan toistaa identtisellä sisällöllä mukaan lukien sanomatunniste (message- ID), jos tilanne on ohimenevä. Samaa sanomatunnistetta (message-id) voidaan käyttää uudestaan vain ja ainoastaan jos kaikki sisältö, mukaan lukien alkuperäinen päiväys, ovat samoja. Servereiden pitäisi pystyä vastaanottamaan POST komentoja samalla sanomatunnisteella (message-id). MIME vastaus osa pitäisi lähettää uudelleen mukaan lukien MDN ja muut MIME osat. (RFC 4130) Koreografia ja orkestrointi Orkestrointi riippuu suuresti siitä miten yrityksen sisäiset järjestelmät ovat toteutettuja. Mutta koreografia taas on riippumatta yrityksen omasta toimintatavasta yleensä samanlainen, eli AS2:ssa se tarkoittaa, että lähetetään sanoma ja saadaan siihen kuittauksena MDN-sanoma. Seuraavassa esimerkissä, kuva 5.4, on erään toimittajan (Seeburger, 2005) esittämä kuvaus AS2 koreografiasta ja orkestroinnista. Orkestrointi tapahtuu toimittajan (supplier) ja valmistajan (manufacturer) organisaatioiden sisällä, kun taas koreografia tapahtuu heidän välillään. 33

42 Kuva 5.4 AS2 koreografia ja orkestrointi (Seeburger 2005) Turvallisuus Lähetettävien sanomien eheys, kiistämättömyys ja luottamuksellisuus varmistetaan seuraavalla tavalla. Organisaatio, joka lähettää sanoman, allekirjoittaa ja kryptaa datan käyttämällä S/MIME (RFC 2311) standardia. Lisäksi sanomaan lisätään vaatimus, että lähettäjälle täytyy lähettää vastauksena allekirjoitettu kuittaus. Tukeakseen NRR:ää (Non-repudiation of 34

43 receipt) alkuperäinen lähettäjä pitää vielä itselleen kirjaa eli lokia lähetetyistä sanomista, sanomatunnisteista (message-id) ja yhteenveto (MIC) arvoista. MIC:iä (Message Integrity Check) kutsutaan sanoman yhteenvedoksi, se on yhteenveto digitaalisen allekirjoituksen käyttämästä hash algoritmista. Käytettävät hash algoritmit ovat SHA-1 tai MD5. Vastaanottava organisaatio purkaa sanoman kryptauksen ja varmentaa allekirjoituksen saavuttaen tällä tavalla datan varmennetun eheyden ja lähettäjän autentikoinnin. Vastaanottava organisaatio sitten lähettää allekirjoitetun kuittauksen lähettävälle organisaatiolle allekirjoitetun MDN -viestin muodossa. Tämä allekirjoitettu kuittaus sisältää tiivistelmän vastaanotetusta sanomasta, antaen alkuperäiselle lähettäjälle mahdollisuuden todentaa että sanoma oli autentikoitu ja kryptaus purettu oikein vastaanottajan päässä. NRR on vahvistus sille tapahtumalle, että alkuperäinen lähettäjä on varmentanut allekirjoitetun kuittauksen saapuneeksi vastaanottajalta. Kuittaus sisältää samat tiedot, joista lähettäjän on täytynyt pitää kirjaa. Lähettäjän velvollisuus on varmentaa, että itselle talletetut tiedot ja kuittauksessa saadut tiedot täsmäävät. Lisäksi on mahdollisuus käyttää HTTPS-protokollaa HTTP-protokollan sijaan. Viestintätopologiat Sanomia voidaan lähettää suoraan kauppakumppanilta toiselle ns. point-to-point ratkaisua käyttäen, mutta on mahdollista myös käyttää operaattoreita, jotka reitittävät, mahdollisesti purkavat kryptauksia, formatoivat sanomia uudelleen jne. Kuinka paljon tietoa operaattorille pitää antaa, riippuu paljon siitä mitä kaikkia toimenpiteitä operaattorin toimenkuvaan kuuluu. Mutta joka tapauksessa jonkin tasoinen turvallinen yhteys täytyy muodostaa operaattorin ja operaattoria käyttävän organisaation väliin. 5.4 Yhteenveto Tämän osion kappaleissa on esitelty eri standardien toiminnallisia ominaisuuksia. 35

TIEKE Verkottaja Service Tools for electronic data interchange utilizers. Heikki Laaksamo

TIEKE Verkottaja Service Tools for electronic data interchange utilizers. Heikki Laaksamo TIEKE Verkottaja Service Tools for electronic data interchange utilizers Heikki Laaksamo TIEKE Finnish Information Society Development Centre (TIEKE Tietoyhteiskunnan kehittämiskeskus ry) TIEKE is a neutral,

Lisätiedot

Julkinen sanomarajapinta. 4.9. ja 11.9.2009

Julkinen sanomarajapinta. 4.9. ja 11.9.2009 4.9. ja 11.9.2009 1 Asiakkaiden nykyiset sanomaliikenneyhteydet Tulliin Nykytilassa sanomaliikenneyhteydet Tullin asiakkaiden tietojärjestelmistä Tullin sovelluksiin välillä hoidetaan operaattoreiden kautta,

Lisätiedot

Tiedonsiirto- ja rajapintastandardit

Tiedonsiirto- ja rajapintastandardit Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen

Lisätiedot

UBL sanomien käyttö sähköisessä kaupankäynnissä. Heikki Laaksamo, TIEKE ry

UBL sanomien käyttö sähköisessä kaupankäynnissä. Heikki Laaksamo, TIEKE ry UBL sanomien käyttö sähköisessä kaupankäynnissä Heikki Laaksamo, TIEKE ry Sähköisen, standardimuotoisen tiedonsiirron kehitys Suomessa Suomalainen standardi / Positiosidonnaiset tietueet KOTVA 1980-luvun

Lisätiedot

Julkinen. Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje

Julkinen. Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje Muistio 1 (7) Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje Sisällys 1 Johdanto... 1 2 Suojatun viestin vastaanottaminen... 1 3 Suojatun viestin lukeminen... 2 4 Vastaanotetun

Lisätiedot

vakuutuslaitosten ja TAMLAn välillä

vakuutuslaitosten ja TAMLAn välillä Asioiden välittämien työeläkealan toimijoiden ja TELKin sekä vakuutuslaitosten ja TAMLAn välillä Työeläkealan XML-käytäntöjen soveltaminen Taustaa, tämän dokumentin tarkoitus Asioiden välittäminen tapahtuu

Lisätiedot

Kuljetus- ja sovelluskerroksen tietoturvaratkaisut. Transport Layer Security (TLS) TLS:n suojaama sähköposti

Kuljetus- ja sovelluskerroksen tietoturvaratkaisut. Transport Layer Security (TLS) TLS:n suojaama sähköposti Kuljetus- ja sovelluskerroksen tietoturvaratkaisut Transport Layer Security (TLS) ja Secure Shell (SSH) TLS Internet 1 2 Transport Layer Security (TLS) Sopii monenlaisille sovellusprotokollille, esim HTTP

Lisätiedot

Tietoturva 811168P 5 op

Tietoturva 811168P 5 op 811168P 5 op 6. Oulun yliopisto Tietojenkäsittelytieteiden laitos Mitä se on? on viestin alkuperän luotettavaa todentamista; ja eheyden tarkastamista. Viestin eheydellä tarkoitetaan sitä, että se ei ole

Lisätiedot

Pikaviestinnän tietoturva

Pikaviestinnän tietoturva Ongelmat, vaihtoehdot ja ratkaisut 4.5.2009 Kandidaatintyö, TKK, tietotekniikka, kevät 2009 Varsinainen työ löytyy osoitteesta http://olli.jarva.fi/kandidaatintyo_ pikaviestinnan_tietoturva.pdf Mitä? Mitä?

Lisätiedot

WEB SERVICES RAJAPINTA SAMLINKIN TEKNINEN RAJAPINTAKUVAUS OHJELMISTOTALOILLE

WEB SERVICES RAJAPINTA SAMLINKIN TEKNINEN RAJAPINTAKUVAUS OHJELMISTOTALOILLE WEB SERVICES RAJAPINTA 02.05.2014 Sisällysluettelo Sisällysluettelo 02.05.2014 2 (13) 1 SOAP-kehys... 4 2 Aineiston pakkaus... 4 3 Aineiston salaus... 4 4 Tuetut operaatiot... 4 5 Application Request Header...

Lisätiedot

OnniSMS Rajapintakuvaus v1.1

OnniSMS Rajapintakuvaus v1.1 OnniSMS Rajapintakuvaus v1.1 1.0 Yleistä OnniSMS on HTTPS/XML pohjainen rajapinta tekstiviestin lähettämiseen. Palvelun käyttöön tarvitaan käyttäjätunnus, salasana ja palvelimen osoite, jotka saa tekemällä

Lisätiedot

OSI ja Protokollapino

OSI ja Protokollapino TCP/IP OSI ja Protokollapino OSI: Open Systems Interconnection OSI Malli TCP/IP hierarkia Protokollat 7 Sovelluskerros 6 Esitystapakerros Sovellus 5 Istuntokerros 4 Kuljetuskerros 3 Verkkokerros Linkkikerros

Lisätiedot

Case VYVI-Turvaposti miten huolehditaan turvallisesta viestinnästä eri sidosryhmien kesken? Tommi Simula Tietoturvapäällikkö Valtori

Case VYVI-Turvaposti miten huolehditaan turvallisesta viestinnästä eri sidosryhmien kesken? Tommi Simula Tietoturvapäällikkö Valtori Case VYVI-Turvaposti miten huolehditaan turvallisesta viestinnästä eri sidosryhmien kesken? Tommi Simula Tietoturvapäällikkö Valtori Agenda Sähköpostin turvallisuus Yleiset käyttötapaukset VYVI Turvaposti

Lisätiedot

T-111.361 Hypermediadokumentin laatiminen. Sisältö. Tavoitteet. Mitä on www-ohjelmointi? Arkkitehtuuri (yleisesti) Interaktiivisuuden keinot

T-111.361 Hypermediadokumentin laatiminen. Sisältö. Tavoitteet. Mitä on www-ohjelmointi? Arkkitehtuuri (yleisesti) Interaktiivisuuden keinot T-111.361 Hypermediadokumentin laatiminen -Ohjelmointi Peruskäsitys www-ohjelmoinnin kentästä Tekniikat interaktiivisuuden toteuttamiseen tekniikat tekniikat Tietokannat Juha Laitinen TKK/TML juha.laitinen@hut.fi

Lisätiedot

Julkinen. Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje

Julkinen. Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje Ohje 1 (10) Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje Sisällys 1 Johdanto... 1 2 Suojatun viestin vastaanottaminen... 1 3 Suojatun viestin lukeminen... 2 4 Vastaanotetun

Lisätiedot

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj SUOMEN KUNTALIITTO Sosiaali- ja terveysyksikkö Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj ~ (operatiiviset-/tiedonjakelu-/si~llönhallinta~velluk~et)

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702)

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

T2V2 Turvallisuushavaintoilmoitussanomakuvaus

T2V2 Turvallisuushavaintoilmoitussanomakuvaus Versio: 0.5 Muokattu: 23.6.2008 2(10) SISÄLLYS 1 Tarkoitus...3 1.1 Rajaus...3 1.2 Dokumentaatio...3 2 Tietojen esitystavat...3 2.1 Numeerinen tieto...3 2.2 Päivämäärät ja kellonajat...3 2.3 Totuusarvot...4

Lisätiedot

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite

Lisätiedot

K U U L A L A A K E R I LUOTTAMUKSELLINEN 1(6)

K U U L A L A A K E R I LUOTTAMUKSELLINEN 1(6) K U U L A L A A K E R I LUOTTAMUKSELLINEN 1(6) Messto HTTP API Messto HTTP API on sovelluskehittäjiä varten kehitetty helppo tapa toteuttaa tekstiviesti- ja multimediaviestisovelluksia. Rajapinnan avulla

Lisätiedot

SAMLINK VARMENNEPALVELU PALVELUKUVAUS OHJELMISTOTALOILLE

SAMLINK VARMENNEPALVELU PALVELUKUVAUS OHJELMISTOTALOILLE SAMLINK VARMENNEPALVELU Sisällysluettelo 2 (7) Sisällysluettelo 1 Johdanto... 3 2 Asiakasohjelmiston varmennehaun käyttötapaukset... 3 3 getcertificate-operaatio... 3 3.1 SenderId... 4 3.2 RequestId...

Lisätiedot

Tekninen kuvaus Aineistosiirrot Interaktiiviset yhteydet iftp-yhteydet

Tekninen kuvaus Aineistosiirrot Interaktiiviset yhteydet iftp-yhteydet Tekninen kuvaus Aineistosiirrot Interaktiiviset yhteydet iftp-yhteydet 15.11.2012 Sisällysluettelo 1 Johdanto... 3 1.2 Interaktiivinen FTP-yhteystapa... 3 1.3 Linkki aineistosiirtopalveluun liittyvät dokumentit...

Lisätiedot

Tietoturvan perusteet - Syksy 2005. SSH salattu yhteys & autentikointi. Tekijät: Antti Huhtala & Asko Ikävalko (TP02S)

Tietoturvan perusteet - Syksy 2005. SSH salattu yhteys & autentikointi. Tekijät: Antti Huhtala & Asko Ikävalko (TP02S) Tietoturvan perusteet - Syksy 2005 SSH salattu yhteys & autentikointi Tekijät: Antti Huhtala & Asko Ikävalko (TP02S) Yleistä SSH-1 vuonna 1995 (by. Tatu Ylönen) Korvaa suojaamattomat yhteydentottotavat

Lisätiedot

T2V2 Vaaratilanneilmoitussanomakuvaus

T2V2 Vaaratilanneilmoitussanomakuvaus Versio: 0.3 Muokattu: 23.6.2008 2(10) SISÄLLYS 1 Tarkoitus...3 1.1 Rajaus...3 1.2 Dokumentaatio...3 2 Tietojen esitystavat...3 2.1 Numeerinen tieto...3 2.2 Päivämäärät ja kellonajat...3 2.3 Totuusarvot...4

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

Maventa Connector Käyttöohje

Maventa Connector Käyttöohje Maventa Connector Käyttöohje 17.4.2015 Sisällys 1. Esittely... 2 1.1. Käytön edellytykset... 2 1.2. Tuetut aineistomuodot... 2 2. Asennustiedosto... 3 2.1. Sisäänkirjautuminen... 7 3. Asetuksien määrittäminen...

Lisätiedot

PALVELUKUVAUS OHJELMISTOTALOILLE SAMLINK VARMENNEPALVELU

PALVELUKUVAUS OHJELMISTOTALOILLE SAMLINK VARMENNEPALVELU PALVELUKUVAUS OHJELMISTOTALOILLE SAMLINK VARMENNEPALVELU Versio 1.0 OY SAMLINK AB 2 (8) Sisällysluettelo Sisällysluettelo 1 Johdanto... 4 2 Asiakasohjelmiston varmennehaun käyttötapaukset... 4 3 getcertificate-operaatio...

Lisätiedot

Muutokset suoran sanoma-asioinnin webservicepalvelun

Muutokset suoran sanoma-asioinnin webservicepalvelun SANOMALIIKENNE Tullihallitus Suora sanoma-asiointi 16.6.2012 Muutokset suoran sanoma-asioinnin webservicepalvelun XML-schemoihin v.1.8 muutos 16.6.2012 SISÄLLYSLUETTELO 1 Johdanto... 3 2 Aikataulu ja yhteensopivuus...

Lisätiedot

Tekninen rajapinta - Soveltamisohje Kansallisen tulorekisterin perustamishanke

Tekninen rajapinta - Soveltamisohje Kansallisen tulorekisterin perustamishanke Versio 1.0 Tekninen rajapinta - Soveltamisohje Kansallisen tulorekisterin perustamishanke Tekninen rajapinta - Soveltamisohje 2 (13) Versiohistoria Versio Päivämäärä Kuvaus 1.0 12.6.2017 Dokumentti julkaistu.

Lisätiedot

Kvarkki XUA: sähköisen allekirjoituksen määritys 1 (6) V 1.0. Kvarkki XUA: sähköisen allekirjoituksen määritys

Kvarkki XUA: sähköisen allekirjoituksen määritys 1 (6) V 1.0. Kvarkki XUA: sähköisen allekirjoituksen määritys Kvarkki XUA: sähköisen allekirjoituksen määritys 1 (6) Kvarkki XUA: sähköisen allekirjoituksen määritys 9.6.2017 Kvarkki XUA: sähköisen allekirjoituksen määritys 2 (6) Sisältö 1 Johdanto... 3 1.1 Dokumentissa

Lisätiedot

papinet -sanomastandardit

papinet -sanomastandardit papinet -sanomastandardit Tapio Räsänen Puutavaralogistiikan kehittämishaasteita 14.6.2007 1 papinet on An international paper and forest products industry e-business initiative. A set of standard electronic

Lisätiedot

Internet Protocol version 6. IPv6

Internet Protocol version 6. IPv6 Internet Protocol version 6 IPv6 IPv6 Osoiteavaruus 32-bittisestä 128-bittiseksi Otsikkokentässä vähemmän kenttiä Lisäominaisuuksien määritteleminen mahdollista Pakettien salaus ja autentikointi mahdollista

Lisätiedot

NELLI-Tunnis. Käyttäjän tunnistus NELLI-tiedonhakuportaalissa yleisissä kirjastoissa. Versio 1.0. 16.5.2006 Ere Maijala Kansalliskirjasto

NELLI-Tunnis. Käyttäjän tunnistus NELLI-tiedonhakuportaalissa yleisissä kirjastoissa. Versio 1.0. 16.5.2006 Ere Maijala Kansalliskirjasto NELLI-Tunnis Käyttäjän tunnistus NELLI-tiedonhakuportaalissa yleisissä kirjastoissa Versio 1.0 16.5.2006 Ere Maijala Kansalliskirjasto Sisällysluettelo Johdanto...3 Tekniikka...3 Esimerkit...4 XML-Skeema...5

Lisätiedot

Business Opening. Arvoisa Herra Presidentti Very formal, recipient has a special title that must be used in place of their name

Business Opening. Arvoisa Herra Presidentti Very formal, recipient has a special title that must be used in place of their name - Opening Finnish Norwegian Arvoisa Herra Presidentti Very formal, recipient has a special title that must be used in place of their name Hyvä Herra, Formal, male recipient, name unknown Hyvä Rouva Formal,

Lisätiedot

Yrityksen sähköisen sanomaliikenteen automatisointi

Yrityksen sähköisen sanomaliikenteen automatisointi Yrityksen sähköisen sanomaliikenteen automatisointi Digi Roadshow 20.4.2015 OneWay Sanomanvälitys Oy Jukka Sippola OneWay Sanomanvälitys Oy / Rauhala Yhtiöt Oy OneWay Sanomanvälitys Oy Perustettu 1.1.2013

Lisätiedot

Tietojen toimittaminen Skeemat Viestit Kansallisen tulorekisterin perustamishanke

Tietojen toimittaminen Skeemat Viestit Kansallisen tulorekisterin perustamishanke Versio 1.0 Tietojen toimittaminen Skeemat Viestit Kansallisen tulorekisterin perustamishanke Tietojen toimittaminen Skeemat Viestit 2 (14) Versiohistoria Versio Päivämäärä Kuvaus 1.0 12.6.2017 Dokumentti

Lisätiedot

Kela Kanta-palvelut Terveydenhuollon todistusten välitys Toiminnalliset prosessit

Kela Kanta-palvelut Terveydenhuollon todistusten välitys Toiminnalliset prosessit Kela Kanta-palvelut 19.5.2016 Terveydenhuollon todistusten välitys Toiminnalliset prosessit Kela Kanta-palvelut 19.5.2016 Sisällys 1 Johdanto... 2 2 Todistuksen välitys vastaanottokäynnin yhteydessä (perusprosessi)3

Lisätiedot

Tietuekuva. Aineistosiirrot XML ISO 20022 XML pain.001.001.02 MT101 sanomasäännöt 15.11.2012

Tietuekuva. Aineistosiirrot XML ISO 20022 XML pain.001.001.02 MT101 sanomasäännöt 15.11.2012 Tietuekuva Aineistosiirrot XML 20022 XML pain.001.001.02 sanomasäännöt 15.11.2012 2 1. Maksusanoman rakenne ja sisältö Dokumentti on tarkoitettu käytettäväksi yhdessä C2B tietuekuvauksen kanssa pain 001.001.02

Lisätiedot

Kymenlaakson Kyläportaali

Kymenlaakson Kyläportaali Kymenlaakson Kyläportaali Klamilan vertaistukiopastus Tietoturva Tietoturvan neljä peruspilaria 1. Luottamuksellisuus 2. Eheys 3. Saatavuus 4. (Luotettavuus) Luottamuksellisuus Käsiteltävää tietoa ei paljasteta

Lisätiedot

Markkinoiden tiedonvaihto murroksessa - ajatuksia tulevasta. Pasi Aho, tasepalvelupäällikkö Sähkömarkkinapäivä 12.4.2012

Markkinoiden tiedonvaihto murroksessa - ajatuksia tulevasta. Pasi Aho, tasepalvelupäällikkö Sähkömarkkinapäivä 12.4.2012 Markkinoiden tiedonvaihto murroksessa - ajatuksia tulevasta Pasi Aho, tasepalvelupäällikkö Sähkömarkkinapäivä 12.4.2012 2 Mitä on markkinoiden tiedonvaihto? Tietosisältöjä: siirtokapasiteetteja, säätösähkötarjouksia,

Lisätiedot

Group 2 - Dentego PTH Korvake. Peer Testing Report

Group 2 - Dentego PTH Korvake. Peer Testing Report Group 2 - Dentego PTH Korvake Peer Testing Report Revisions Version Date Author Description 1.0 Henrik Klinkmann First version Table of Contents Contents Revisions... 2 Table of Contents... 2 Testing...

Lisätiedot

Sähköisen toimitusketjun tuomat edut Liikenne- ja viestintäministeriö 26.03.2013. Ilkka Tirkkonen Regional CIO

Sähköisen toimitusketjun tuomat edut Liikenne- ja viestintäministeriö 26.03.2013. Ilkka Tirkkonen Regional CIO Sähköisen toimitusketjun tuomat edut Liikenne- ja viestintäministeriö 26.03.2013 Ilkka Tirkkonen Regional CIO Sähköinen toimitusketju Myyjä luovutus Tilaus Vahvistus Toimitus Kysely Vastaus Ostaja luovutus

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

Tietojen jakelu Skeemat Viestit Kansallisen tulorekisterin perustamishanke

Tietojen jakelu Skeemat Viestit Kansallisen tulorekisterin perustamishanke Versio 1.0 Tietojen jakelu Skeemat Viestit Kansallisen tulorekisterin perustamishanke Tietojen jakelu Skeemat Viestit 2 (20) Versiohistoria Versio Päivämäärä Kuvaus 1.0 12.6.2017 Dokumentti julkaistu.

Lisätiedot

XML-saatavuuskysely. XML-tiedoston kuvaus. versio 1.3.3 04.02.2008

XML-saatavuuskysely. XML-tiedoston kuvaus. versio 1.3.3 04.02.2008 XML-saatavuuskysely XML-tiedoston kuvaus versio 1.3.3 04.02.2008 Ecom Oy 2004-2008 XML-saatavuuskysely Versio 1.3.3 2/15 Sisällysluettelo Historia...3 Rakenteen hierarkinen esitys...4 Elementtien kuvaukset...5

Lisätiedot

Yritysturvallisuuden perusteet. 11. Luento Tietotekninen turvallisuus

Yritysturvallisuuden perusteet. 11. Luento Tietotekninen turvallisuus Yritysturvallisuuden perusteet Teemupekka Virtanen Helsinki University of Technology Telecommunication Software and Multimedia Laboratory teemupekka.virtanen@hut.fi 11. Luento Tietotekninen turvallisuus

Lisätiedot

Luento 12: XML ja metatieto

Luento 12: XML ja metatieto Luento 12: XML ja metatieto AS-0.110 XML-kuvauskielten perusteet Janne Kalliola XML ja metatieto Metatieto rakenne sanasto Resource Description Framework graafikuvaus XML Semanttinen Web agentit 2 1 Metatieto

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

XML prosessori. XML prosessointi. XML:n kirjoittaminen. Validoiva jäsennin. Tapahtumaohjattu käsittely. Tapahtumaohjattu käsittely.

XML prosessori. XML prosessointi. XML:n kirjoittaminen. Validoiva jäsennin. Tapahtumaohjattu käsittely. Tapahtumaohjattu käsittely. XML prosessointi Miten XML dokumentteja luetaan ja kirjoitetaan XML prosessori lukee ja välittää XML dokumentin sovellukselle. Se sisältää entieettikäsittelijän (mahdollisesti) XML jäsentimen Sovellus

Lisätiedot

Opus SMS tekstiviestipalvelu

Opus SMS tekstiviestipalvelu Opus SMS tekstiviestipalvelu Sivu 1 / 17 1. Yleistä toiminnosta Opus SMS tekstiviestipalvelun avulla voidaan Opus Dental potilashallintaohjelmasta Lähettää muistutuksia tekstiviestillä Lähettää tiedusteluita

Lisätiedot

SOAPin nimen Object on harhaanjohtava, koska SOAPissa ei ole objektiviittauksia. Tähän ja muihin SOAPin puutteisiin palataan niin ikään myöhemmin.

SOAPin nimen Object on harhaanjohtava, koska SOAPissa ei ole objektiviittauksia. Tähän ja muihin SOAPin puutteisiin palataan niin ikään myöhemmin. 1 SOAPin uusin versio 1.2 on vuodelta 2003. Vaikka tämä versio onkin jo yleisesti käytössä ja myös W3C:n suositus, käytetään versiota 1.1 myös jonkin verran edelleen. SOAPia voidaan käyttää esim. tyypilliseen

Lisätiedot

Interfacing Product Data Management System

Interfacing Product Data Management System Interfacing Product Data Management System Tekijä: Työn valvoja: Mats Kuivalainen Timo Korhonen Esitelmän sisältö Työn suorituspaikka - Ideal Product Data Oy Käsitteitä Työn tavoitteet Työn tulokset 1/5

Lisätiedot

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Mikä on IT arkkitehtuuri? Liiketoimintamalli määrittelee IT arkkitehtuurin IT arkkitehtuuri ottaa kantaa sovelluksen laadullisiin vaatimuksiin

Lisätiedot

Suomalaisen julkishallinnon Vetuma-palvelu Vetuma-palvelun SAML-kutsurajapinnan metadata-tiedosto Versio: 3.5

Suomalaisen julkishallinnon Vetuma-palvelu Vetuma-palvelun SAML-kutsurajapinnan metadata-tiedosto Versio: 3.5 Suomalaisen julkishallinnon Vetuma-palvelu Vetuma-palvelun SAML-kutsurajapinnan metadata-tiedosto Versio: 3.5 Vetuma Verkkotunnistus ja -maksaminen Sisällysluettelo 1. Johdanto... 3 2. Metadata määrityksen

Lisätiedot

Green Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille?

Green Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille? Green Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille? 10.10.01 Tuomo Suortti Ohjelman päällikkö Riina Antikainen Ohjelman koordinaattori 10/11/01 Tilaisuuden teema Kansainvälistymiseen

Lisätiedot

DOCUMENT MANAGER FI/ NO/ SE

DOCUMENT MANAGER FI/ NO/ SE PALVELUKUVAUS 1 (6) DOCUMENT MANAGER FI/ NO/ SE PALVELUKUVAUS 2 (6) CONTENTS 1. DOCUMENT MANAGER... 3 2. DOCUMENT MANAGER - KUVAUS... 3 2.1 Tuotteet... 4 2.1.1 Data Management... 4 2.1.2 ipost Letter...

Lisätiedot

Sähköposti ja tekstiviesti tietoturvatontako? Yrjö Koivusalo tietohallintapäällikkö V-SSHP

Sähköposti ja tekstiviesti tietoturvatontako? Yrjö Koivusalo tietohallintapäällikkö V-SSHP Sähköposti ja tekstiviesti tietoturvatontako? Yrjö Koivusalo tietohallintapäällikkö V-SSHP Esityksen sisältö Esimerkkejä hyötykäytöstä Miksi tämä on ajankohtaista? Säännöksiä ja suosituksia Pohdintaa Kaiser

Lisätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajärjestelmien integrointi Liiketoimintajärjestelmien integrointi Vierailuluento 12.12.2016 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application

Lisätiedot

Ongelma 1: Miten tieto kannattaa koodata, jos sen halutaan olevan hyvin vaikeasti luettavaa?

Ongelma 1: Miten tieto kannattaa koodata, jos sen halutaan olevan hyvin vaikeasti luettavaa? Ongelma 1: Miten tieto kannattaa koodata, jos sen halutaan olevan hyvin vaikeasti luettavaa? 2012-2013 Lasse Lensu 2 Ongelma 2: Miten tietoa voidaan (uudelleen)koodata tehokkaasti? 2012-2013 Lasse Lensu

Lisätiedot

Aktivointipalvelut - vähemmän paperia, enemmän verkkolaskuja

Aktivointipalvelut - vähemmän paperia, enemmän verkkolaskuja Aktivointipalvelut - vähemmän paperia, enemmän verkkolaskuja Hannu Katila, Marketing Manager Basware Experience User Forum Collaborate. Innovate. Succeed. Australia Denmark Finland France Germany Netherlands

Lisätiedot

11.12.2006 VAATIMUSMÄÄRITTELY

11.12.2006 VAATIMUSMÄÄRITTELY VAATIMUSMÄÄRITTELY Vaatimusmäärittely 2 (18) VERSIONHALLINTA Versio Päivä Tekijä Kuvaus 0.1 4.10.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 4.10.2006 Kaarlo Lahtela kohdat 7 (tominnalliset vaatimukset)

Lisätiedot

1 (4) 28.11.08. Maksujärjestelmät. Sisällysluettelo

1 (4) 28.11.08. Maksujärjestelmät. Sisällysluettelo Finvoice. Palvelukuvaus 28..2008 (4) 28..08 Sisällysluettelo Finanssialan keskusliiton suosituksen mukaisen Fincoice-sanoman yleisperiaatteet... Taustaa... 2 Mikä on Finvoice... Kuluttajan e-lasku... 2

Lisätiedot

Myyntilasku: 100 % lähteviä laskuja verkkolaskuina Joustavat ratkaisut omien asiakkaittesi valmiuksista riippumatta

Myyntilasku: 100 % lähteviä laskuja verkkolaskuina Joustavat ratkaisut omien asiakkaittesi valmiuksista riippumatta Myyntilasku: 100 % lähteviä laskuja verkkolaskuina Joustavat ratkaisut omien asiakkaittesi valmiuksista riippumatta Basware Käyttäjäpäivät 20.-21.9.2011 Rohkeus liiketoiminnan kehittämiseen Lahti Esityksen

Lisätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajärjestelmien integrointi Liiketoimintajärjestelmien integrointi Vierailuluento 2.3.2015 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application

Lisätiedot

TEKNINEN MÄÄRITTELY. Matkahuollon osoitekorttihaun rajapinta. Ismo Koskinen

TEKNINEN MÄÄRITTELY. Matkahuollon osoitekorttihaun rajapinta. Ismo Koskinen TEKNINEN MÄÄRITTELY Matkahuollon osoitekorttihaun rajapinta Ismo Koskinen Versio 2.2 Päiväys 12.05.2014 Tekijä Ismo Koskinen MUUTOSHISTORIA Versio ja pvm Laatija Muutoksen kuvaus 1.0 / 07.07.2009 Ismo

Lisätiedot

PANKKILINJAN FTP - KUVAUS

PANKKILINJAN FTP - KUVAUS PANKKILINJAN FTP - KUVAUS 2 Sisällysluettelo SISÄLLYSLUETTELO...2 YLEISTÄ...3 YHTEYSKÄYTÄNTÖ...4 YHTEYDEN AVAAMINEN JA FTP-SISÄÄNKIRJAUS...4 ASIAKKAAN JA PANKIN TODENNUS...5 PALVELUN PYYNTÖ...5 AINEISTON

Lisätiedot

SÄHKÖISET RAHTIKIRJAT - VISMA AUTOTRANSPORT

SÄHKÖISET RAHTIKIRJAT - VISMA AUTOTRANSPORT Visma Nova SÄHKÖISET RAHTIKIRJAT - VISMA AUTOTRANSPORT Page 1 Lähtökohdat Logistiikka-alan toimijoiden tavoitteena sähköinen toimintatapa vuoteen 2013 mennessä (Logistiikkayritysten liitto ry): Pyrkimyksenä

Lisätiedot

AS2 Applicability Statement 2

AS2 Applicability Statement 2 Toteutettu yhteistyössä Elintarviketeollisuusliitto ry:n ja Päivittäistavarakauppa ry:n kanssa osana maa- ja metsätalousministeriön kansallista elintarviketalouden laatustrategiaa Tiedonsiirtosuositus

Lisätiedot

Omat Lähdöt ohjelmointirajapinta: Versio 1.01

Omat Lähdöt ohjelmointirajapinta: Versio 1.01 Sivu 1(19) Omat Lähdöt ohjelmointirajapinta: Versio 1.01 Seasam House Oy Helsingin seudun liikenne Hyväksynyt: Päivämäärä: Hyväksynyt: Päivämäärä: www.seasam.com Sivu 2(19) Versio historia Versio 0.01

Lisätiedot

Tekninen dokumentti. TEKNINEN DOKUMENTTI Versio 4.4-1 29.9.2011 1 (24) Versio ja pvm Laatinut Tarkastanut Hyväksynyt.

Tekninen dokumentti. TEKNINEN DOKUMENTTI Versio 4.4-1 29.9.2011 1 (24) Versio ja pvm Laatinut Tarkastanut Hyväksynyt. 29.9.2011 1 (24) Tekninen dokumentti Metsäkeskusten sähköisten viestien (siirtotiedostojen) lähettäminen automaattisesti metsäkeskusten tiedonsiirtopalveluun ja palvelun palauteviestit Versio ja pvm Laatinut

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

W3C-teknologiat ja yhteensopivuus

W3C-teknologiat ja yhteensopivuus W3C-teknologiat ja yhteensopivuus Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), Hypermedialaboratorio W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: W3C asettaa

Lisätiedot

BASWARE E-INVOICE KAIKKI MYYNTILASKUT VERKKOLASKUINA. Juho Värtö, Account Manager

BASWARE E-INVOICE KAIKKI MYYNTILASKUT VERKKOLASKUINA. Juho Värtö, Account Manager BASWARE E-INVOICE KAIKKI MYYNTILASKUT VERKKOLASKUINA Juho Värtö, Account Manager BASWARE E-INVOICE KAIKKI MYYNTILASKUT VERKKOLASKUINA Johdanto Palvelutarjooma Pakettiratkaisut verkkolaskujen lähettämiseen

Lisätiedot

Baswaren verkkolaskuratkaisut PK-yritykselle. Mikael Ylijoki VP, Network Services Product Management

Baswaren verkkolaskuratkaisut PK-yritykselle. Mikael Ylijoki VP, Network Services Product Management Baswaren verkkolaskuratkaisut PK-yritykselle Mikael Ylijoki VP, Network Services Product Management Mikä on verkkolasku? Verkkolasku on lasku, joka: Lähetetään ja/tai vastaanotetaan sähköisesti Sisältää

Lisätiedot

KAOS 2015: Integraatioiden standardointi suunnittelumallien avulla. Ilkka Pirttimaa, Chief ICT Architect, Stockmann ICT

KAOS 2015: Integraatioiden standardointi suunnittelumallien avulla. Ilkka Pirttimaa, Chief ICT Architect, Stockmann ICT KAOS 2015: Integraatioiden standardointi suunnittelumallien avulla Ilkka Pirttimaa, Chief ICT Architect, Stockmann ICT 1 2 Integraatioiden nykytila 2015 Standardoidut: Integraatiotyökalut Suunnittelumallit

Lisätiedot

Hostingpalvelujen. oikeudelliset kysymykset. Viestintäviraston Abuse-seminaari 2012. Jaakko Lindgren

Hostingpalvelujen. oikeudelliset kysymykset. Viestintäviraston Abuse-seminaari 2012. Jaakko Lindgren Hostingpalvelujen oikeudelliset kysymykset Viestintäviraston Abuse-seminaari 2012 Jaakko Lindgren Legal Counsel Tieto, Legal jaakko.lindgren@tieto.com Esittely Jaakko Lindgren Legal Counsel, Tieto Oyj

Lisätiedot

Veronumero.fi Tarkastaja rajapinta

Veronumero.fi Tarkastaja rajapinta Suomen Tilaajavastuu Oy Veronumero.fi Tarkastaja rajapinta Rajapintakuvaus veronumeroiden tarkastamiseen ja henkilötietojen noutamiseen Suomen Tilaajavastuu Oy Muutoshistoria Päivämäärä Tekijä Muutos 11.2.2013

Lisätiedot

Sähköpostitilin käyttöönotto

Sähköpostitilin käyttöönotto Sähköpostitilin käyttöönotto Versio 1.0 Jarno Parkkinen jarno@atflow.fi Sivu 1 / 16 1 Johdanto... 2 2 Thunderbird ohjelman lataus ja asennus... 3 3 Sähköpostitilin lisääminen ja käyttöönotto... 4 3.2 Tietojen

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA, Järjestelmäarkkitehtuuri (TK081702) SOA SOA-arkkitehtuuri perustuu xml:ään ja Web Services teknologioihin Mahdollistaa joustavan mukautumisen tuleviin muutoksiin Kustannustehokas Toteutukset perustuvat

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (7) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

Security server v6 installation requirements

Security server v6 installation requirements CSC Security server v6 installation requirements Security server version 6.4-0-201505291153 Pekka Muhonen 8/12/2015 Date Version Description 18.12.2014 0.1 Initial version 10.02.2015 0.2 Major changes

Lisätiedot

Oppilaan opas. Visuaaliviestinnän Instituutti VVI Oy. Versio 0.2 (2008-01-21)

Oppilaan opas. Visuaaliviestinnän Instituutti VVI Oy. Versio 0.2 (2008-01-21) Oppilaan opas Visuaaliviestinnän Instituutti VVI Oy Versio 0.2 (2008-01-21) Versio Päivämäärä Kuvaus 0.1 2005-01-16 Ensimmäinen versio. 0.2 2008-01-21 Korjattu kuvatiedostojen maksimiresoluutio ja muutamia

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Kuluttajaverkkolaskutus ja esilläpitopalvelu Suomessa

Kuluttajaverkkolaskutus ja esilläpitopalvelu Suomessa Kuluttajaverkkolaskutus ja esilläpitopalvelu Suomessa Palvelun kuvaus sivu 1/7 Tiedon asiakirjat: tekijänoikeudet Tämän asiakirjan sisältöä tai mitään sen osaa ei saa jäljentää yrityksenne ulkopuolella

Lisätiedot

SecGo. Sähköinen allekirjoitus ja sen käyttö. Ari-Pekka Paananen, SecGo VE Oy Director,technology ari-pekka.paananen@secgo.com

SecGo. Sähköinen allekirjoitus ja sen käyttö. Ari-Pekka Paananen, SecGo VE Oy Director,technology ari-pekka.paananen@secgo.com SecGo Sähköinen allekirjoitus ja sen käyttö Ari-Pekka Paananen, SecGo VE Oy Director,technology ari-pekka.paananen@secgo.com Turvallinen Sähköinen Tiedonkulku Tunnistetut käyttäjät tietojärjestelmiin Pääsyoikeudet

Lisätiedot

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska

Lisätiedot

SALAUSMENETELMÄT. Osa 2. Etätehtävät

SALAUSMENETELMÄT. Osa 2. Etätehtävät SALAUSMENETELMÄT Osa 2 Etätehtävät A. Kysymyksiä, jotka perustuvat luentomateriaaliin 1. Määrittele, mitä tarkoitetaan tiedon eheydellä tieoturvan yhteydessä. 2. Määrittele, mitä tarkoittaa kiistämättömyys

Lisätiedot

Salatun sähköpostipalvelun käyttöohje

Salatun sähköpostipalvelun käyttöohje Salatun sähköpostipalvelun käyttöohje Lappeenrannan teknillinen yliopisto tarjoaa henkilökunnalle käyttöön salatun sähköpostipalvelun. Salattu sähköposti on tarkoitettu käytettäväksi tilanteissa, joissa

Lisätiedot

Sisäilmaston mittaus hyödyntää langatonta anturiteknologiaa:

Sisäilmaston mittaus hyödyntää langatonta anturiteknologiaa: Ismo Grönvall/Timo/TUTA 0353064 Tehtävä 5: Sisäilmaston mittaus hyödyntää langatonta anturiteknologiaa: Ihmiset viettävät huomattavan osan (>90 %) ajasta sisätiloissa. Sisäilmaston laatu on tästä syystä

Lisätiedot

Digitalisaation hyödyt teollisuudessa

Digitalisaation hyödyt teollisuudessa TEKNOLOGIAN TUTKIMUSKESKUS VTT OY Digitalisaation hyödyt teollisuudessa Teollisuus ja digitalisaatio seminaari 3.9.2015 Technopolis Hermia, Tampere Heli Helaakoski, TkT, tutkimuspäällikkö Teollisuuden

Lisätiedot

Maksuturva- ja emaksut- palvelun integrointiohje

Maksuturva- ja emaksut- palvelun integrointiohje Maksuturva- ja emaksut- palvelun integrointiohje Versio 1.4 INTEGROINTIOHJE 2(9) Sisältö 1 INTEGROINTIMAHDOLLISUUDET... 3 2 INTEGROINTIRAJAPINNAT... 4 2.1 Yleistä... 4 2.2 MAKSUTURVA/EMAKSUT-TAPAHTUMAN

Lisätiedot

Hammastankohissin modernisointi. Heikki Laitasalmi

Hammastankohissin modernisointi. Heikki Laitasalmi Hammastankohissin modernisointi Heikki Laitasalmi Loppudemossa Mitä oltiinkaan tekemässä V-malli Modbus viestintä (PLC VFD) Esitellään laitteet Lopuksi Modbusia käytännössä Hammastankohissi Arkkitehtuuri

Lisätiedot

Sonyn suomenkielisen Web-portaalin käyttöohjeet

Sonyn suomenkielisen Web-portaalin käyttöohjeet Sonyn suomenkielisen Web-portaalin käyttöohjeet Sonyn Web-portaalin käyttöohjeet Seuraavilla sivuilla esiteltävien käyttöohjeiden yhteenveto: Sisäänkirjautuminen Uuden tai vaihtosalasanan hankkiminen.

Lisätiedot

Palvelun rekisteröinti Virtu - luottamusverkostoon / testipalveluun

Palvelun rekisteröinti Virtu - luottamusverkostoon / testipalveluun 1 Resurssirekisteri :: Käyttöohje Palvelun rekisteröinti Virtu - luottamusverkostoon / testipalveluun Tässä ohjeessa kerrotaan, miten lisäät uuden Service Provider (SP) palvelun Virtu - luottamusverkostoon

Lisätiedot

Muutokset suoran sanoma-asioinnin webservicepalvelun

Muutokset suoran sanoma-asioinnin webservicepalvelun 1(6) Sanomaliikenne Suora sanoma-asiointi Muutokset suoran sanoma-asioinnin webservicepalvelun XML-schemoihin v.1.5 muutos 4.12.2010 2(6) SISÄLLYSLUETTELO 1 Johdanto... 3 2 Aikataulu ja yhteensopivuus...

Lisätiedot

Collaborative & Co-Creative Design in the Semogen -projects

Collaborative & Co-Creative Design in the Semogen -projects 1 Collaborative & Co-Creative Design in the Semogen -projects Pekka Ranta Project Manager -research group, Intelligent Information Systems Laboratory 2 Semogen -project Supporting design of a machine system

Lisätiedot

SÄHKE- ja Moreqvaikutukset. dokumenttienhallinnan järjestelmäkehitykseen. Juha Syrjälä, Affecto Finland Oy

SÄHKE- ja Moreqvaikutukset. dokumenttienhallinnan järjestelmäkehitykseen. Juha Syrjälä, Affecto Finland Oy SÄHKE- ja Moreqvaikutukset asian- ja Ju dokumenttienhallinnan järjestelmäkehitykseen Juha Syrjälä, Affecto Finland Oy Affecto Enterprise Information Management -ratkaisujen edelläkävijä Pohjois- Euroopassa

Lisätiedot

Sisältö. 3 Yleistä 4 Toimittajaportaalin edut 5-10 Rekisteröinti 11-22 Laskun teko 23 Lasku JIP. 29/05/2015 Anna-Stina Lindblad

Sisältö. 3 Yleistä 4 Toimittajaportaalin edut 5-10 Rekisteröinti 11-22 Laskun teko 23 Lasku JIP. 29/05/2015 Anna-Stina Lindblad Toimittajaportaali Sisältö 3 Yleistä 4 Toimittajaportaalin edut 5-10 Rekisteröinti 11-22 Laskun teko 23 Lasku JIP 2 Yleistä Toimittajaportaali on Baswaren internetissä toimiva sovellus, jonka kautta voi

Lisätiedot

Tietojärjestelmien yhteensovittaminen turvallisesti älykkäisiin koneisiin

Tietojärjestelmien yhteensovittaminen turvallisesti älykkäisiin koneisiin Tietojärjestelmien yhteensovittaminen turvallisesti älykkäisiin koneisiin Tampereen teknillinen yliopisto 28.1.2010 Jouni Vuorensivu Remion Ltd. www.remion.com jouni.vuorensivu@remion.com Jouni Vuorensivu

Lisätiedot

Tikon Ostolaskujenkäsittely versio 6.1.2 SP1

Tikon Ostolaskujenkäsittely versio 6.1.2 SP1 Toukokuu 2012 1 (14) Tikon Ostolaskujenkäsittely versio 6.1.2 SP1 Asennusohje Toukokuu 2012 2 (14) Sisällysluettelo 1. Vaatimukset palvelimelle... 3 1.1..NET Framework 4.0... 3 1.2. Palvelimen Internet

Lisätiedot