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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit 7 Viestipohjaisten yritysjärjestelmien suunnittelumallit Hohpe G., Woolf B.: Enterprise Integration Patterns. Addison-Wesley 2004. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Viestinvälitykseen

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

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

Sähköposti ja uutisryhmät 4.5.2005

Sähköposti ja uutisryhmät 4.5.2005 Outlook Express Käyttöliittymä Outlook Express on windows käyttöön tarkoitettu sähköpostin ja uutisryhmien luku- ja kirjoitussovellus. Se käynnistyy joko omasta kuvakkeestaan työpöydältä tai Internet Explorer

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

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

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008 Meeri Nieminen Asiakkaan vaihtoehdot Asiakkaan vaihtoehdot EMCS-järjestelmän käyttöön XML-sanomarajapinta oman järjestelmän

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

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

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

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

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

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

Ilmoitus saapuneesta turvasähköpostiviestistä

Ilmoitus saapuneesta turvasähköpostiviestistä Tullin turvasähköposti Asiakkaan ohje www.tulli.fi versio 2.2 8.1.2015 Korvaa version 2.1 22.5.2014 Tullin turvasähköposti Tulli lähettää sinulle sähköpostiviestin salattuna silloin, kun viesti tai sen

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

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

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

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

Verkkopalkan palvelukuvaus

Verkkopalkan palvelukuvaus 27.1.2012 1 (6) Verkkopalkan palvelukuvaus 27.1.2012 2 (6) Sisällysluettelo 1 Johdanto... 3 2 Verkkopalkka-palvelun toiminta palkanmaksajalle... 3 3 Verkkopalkan käyttöönotto... 4 4 Verkkopalkka-palvelun

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

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

Ohjelmistoarkkitehtuurit. Kevät 2012-2013

Ohjelmistoarkkitehtuurit. Kevät 2012-2013 Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestipohjaisten yritysjärjestelmien suunnittelumallit 1 Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit:

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

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

Asiakaspalveluprosessin kehittäminen jakelun vaikutuspiiriin kuuluvien asioiden osalta

Asiakaspalveluprosessin kehittäminen jakelun vaikutuspiiriin kuuluvien asioiden osalta Asiakaspalveluprosessin kehittäminen jakelun vaikutuspiiriin kuuluvien asioiden osalta Tehtävät 1. Asiakaspalvelun ja asiakkaiden vaatimukset jakelulle => haastateltavat organisaatiot/henkilöt => lukijaraatien

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

Helppo ottaa käyttöön, helppo käyttää Basware Virtual Printer

Helppo ottaa käyttöön, helppo käyttää Basware Virtual Printer Helppo ottaa käyttöön, helppo käyttää Basware Virtual Printer Hannu Katila, Marketing Manager Basware Experience User Forum Collaborate. Innovate. Succeed. Australia Denmark Finland France Germany Netherlands

Lisätiedot

Microsoft Outlook Web Access. Pikaohje sähköpostin peruskäyttöön

Microsoft Outlook Web Access. Pikaohje sähköpostin peruskäyttöön Microsoft Outlook Web Access Pikaohje sähköpostin peruskäyttöön 1 Käyttö työpaikalla (Hallinto-verkossa) Käynnistetään sähköposti Työpöydällä olevasta Faiposti-pikakuvakkeesta (hiirellä kaksoisklikkaamalla).

Lisätiedot

Sähköpostin arkistointi

Sähköpostin arkistointi Suomen XII liikearkistopäivät 1 12.-13.9.2007 Tampere Sähköpostin arkistointi www.industrialitc.fi 2 Esityksen sisältö Sähköpostiarkistointi osana informaation hallintaa ja ECM-kokonaisuutta Lainsäädäntö

Lisätiedot

Sähköisen liiketoimintaprosessin kehittäminen. Heikki Laaksamo, TIEKE, 26.3.2013

Sähköisen liiketoimintaprosessin kehittäminen. Heikki Laaksamo, TIEKE, 26.3.2013 Sähköisen liiketoimintaprosessin kehittäminen Heikki Laaksamo, TIEKE, 26.3.2013 SÄTKY Sähköisten toimintamallien käytön lisääminen logistiikassa Hankkeessa on luotu työkaluja, jotka mahdollistavat suomalaisen

Lisätiedot

EMVHost Online SUBJECT: EMVHOST ONLINE CLIENT - AUTOMAATTISIIRROT COMPANY: EMVHost Online Client sovelluksen käyttöohje AUTHOR: DATE: 15.03.

EMVHost Online SUBJECT: EMVHOST ONLINE CLIENT - AUTOMAATTISIIRROT COMPANY: EMVHost Online Client sovelluksen käyttöohje AUTHOR: DATE: 15.03. EMVHost Online SUBJECT: COMPANY: COMMENTS: AUTHOR: EMVHOST ONLINE CLIENT - AUTOMAATTISIIRROT NETS OY EMVHost Online Client sovelluksen käyttöohje NETS OY DATE: 15.03.2011 VERSION: 1.0 1 SISÄLLYS SISÄLLYS...

Lisätiedot

83450 Internetin verkkotekniikat, kevät 2002 Tutkielma

83450 Internetin verkkotekniikat, kevät 2002 Tutkielma <Aihe> 83450 Internetin verkkotekniikat, kevät 2002 Tutkielma TTKK 83450 Internetin verkkotekniikat Tekijät: Ryhmän nro:

Lisätiedot

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja 1 Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja kommunikointi toteutetaan SOAPin avulla. Näihin kieliin

Lisätiedot

TURVAVÄYLÄSEMINAARI. Erilaiset kenttäväylät ja niiden kehitys 13.11.2002. Jukka Hiltunen

TURVAVÄYLÄSEMINAARI. Erilaiset kenttäväylät ja niiden kehitys 13.11.2002. Jukka Hiltunen TURVAVÄYLÄSEMINAARI Erilaiset kenttäväylät ja niiden kehitys 13.11.2002 Jukka Hiltunen Miksi väylätekniikkaa? 1. luonnolliset perusteet: : kehittyneiden kenttälaitteiden ja ylemmän tason laitteiden välille

Lisätiedot

Hankkeen toiminnot työsuunnitelman laatiminen

Hankkeen toiminnot työsuunnitelman laatiminen Hankkeen toiminnot työsuunnitelman laatiminen Hanketyöpaja LLP-ohjelman keskitettyjä hankkeita (Leonardo & Poikittaisohjelma) valmisteleville11.11.2011 Työsuunnitelma Vastaa kysymykseen mitä projektissa

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

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä OHJ-5201 Web-palveluiden toteutustekniikat Kurssisisällöstä Tarja Systä 1 Yleistä Esitietovaatimukset OHJ-1400 Olio-ohjelmoinnin peruskurssi (pakollinen) OHJ-5010 Hajautettujen järjestelmien perusteet

Lisätiedot

Internet ja tietoverkot 2015 Harjoitus 7: Kertaus

Internet ja tietoverkot 2015 Harjoitus 7: Kertaus Internet ja tietoverkot 2015 Harjoitus 7: Kertaus Tämän harjoituksen tarkoituksena on hieman kerrata TCP/IP-kerrosmallin sovelluskerroksen, kuljetuskerroksen, internet-kerroksen ja siirtoyhteyskerroksen

Lisätiedot

Uutiskirjetyökalun käyttöohjeet. - Campaign Monitor -

Uutiskirjetyökalun käyttöohjeet. - Campaign Monitor - Uutiskirjetyökalun käyttöohjeet - Campaign Monitor - Tervetuloa käyttämään asiakasviestinnän työkalua Campaign Monitoria Käytössäsi on edistyksellinen ja monipuolinen työkalu, jolla toteutat asiakasviestinnän

Lisätiedot

Visma Econet Pro Factoring laskutus Finvoice muodossa

Visma Econet Pro Factoring laskutus Finvoice muodossa Visma Econet Pro Factoring laskutus Finvoice muodossa Oppaan päiväys: 27.4.2012. Asiakasneuvonta: Helpdesk: kirjautuminen Visma Econet infolinen tai osoitteen www.visma.fi kautta Visma Econet Pro: 0600-39-7261

Lisätiedot

Älykkäämmät integraatiot palveluväylän avulla

Älykkäämmät integraatiot palveluväylän avulla Älykkäämmät integraatiot palveluväylän avulla John Joro 2013 IBM Corporation Arek Oy Työeläkevakuutuksen järjestelmäkehittäjä Arek on asiakkaidensa omistama yksityinen osakeyhtiö Selkeä hallintomalli Rakennettavien

Lisätiedot

Toimintaympäristön kuvaus. LTC-Otso Myyjän työkalu (POC)

Toimintaympäristön kuvaus. LTC-Otso Myyjän työkalu (POC) LTC-Otso Myyjän työkalu (POC) Toimintaympäristön kuvaus 21 toukokuu, 2015 Sisältö 1 Johdanto... 3 1.1 Dokumentin tavoite... 3 1.2 Dokumentin yleiskuvaus... 3 2 Järjestelmälle asetetut vaatimukset... 3

Lisätiedot

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia

Lisätiedot

TIEDONKULKU. PROJEKTITYÖ Tik-76.115 Wclique

TIEDONKULKU. PROJEKTITYÖ Tik-76.115 Wclique TIEDONKULKU PROJEKTITYÖ Tik-76.115 SISÄLLYSLUETTELO Sisällysluettelo... 2 Versiohistoria... 2 1. JOHDANTO... 3 1.1 Tämän dokumentin tarkoitus... 3 1.2 Projekti... 3 2. Tiedonkulku... 3 2.1 Yleistä... 3

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

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 (6) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

Internet ja tietoverkot 2015 Harjoitus 5: (ISO/OSI-malli: Verkkokerros, TCP/IP-malli: internet-kerros)

Internet ja tietoverkot 2015 Harjoitus 5: (ISO/OSI-malli: Verkkokerros, TCP/IP-malli: internet-kerros) Internet ja tietoverkot 2015 Harjoitus 5: (ISO/OSI-malli: Verkkokerros, TCP/IP-malli: internet-kerros) Tämän harjoituksen tarkoituksena on tutustua IP-protokollaan. Kertausta - Harjoitus 4: Erään sovelluksen

Lisätiedot

Käyttäjienhallintatyökalu

Käyttäjienhallintatyökalu Käyttäjienhallintatyökalu 2 Käyttäjienhallinta-ohje Sisällysluettelo 1 Yleistä Käyttäjienhallintatyökalusta... 3 1.1 Excel-taulukko csv-tiedoston luomisessa...4 2 Käyttäjien luominen... 4 2.1 Käyttäjien

Lisätiedot

SR307 Tietoturvatekniikat ISO/IEC JTC 1/SC 27 IT Security Techniques. Tietoturvallisuuden hallinta ISO/IEC 27000. Reijo Savola Johtava tutkija VTT

SR307 Tietoturvatekniikat ISO/IEC JTC 1/SC 27 IT Security Techniques. Tietoturvallisuuden hallinta ISO/IEC 27000. Reijo Savola Johtava tutkija VTT SR307 Tietoturvatekniikat ISO/IEC JTC 1/SC 27 IT Security Techniques Tietoturvallisuuden hallinta ISO/IEC 27000 Reijo Savola Johtava tutkija VTT FORUM 2013, 30.10.2013 SISÄLTÖ Työohjelma ja organisaatio

Lisätiedot

SÄHKÖISET JA LAINSÄÄDÄNTÖ

SÄHKÖISET JA LAINSÄÄDÄNTÖ LIIKEARKISTOPÄIVÄT 12.-13.9.2007 ASIAKIRJAT SÄHKÖISET JA LAINSÄÄDÄNTÖ Jukka Tuomela Tampereen yliopisto Oikeustieteiden laitos Lainsäädännön lähtökohtia Lainsäädännössä pyritään siihen, että sähköisiä

Lisätiedot

Selvitysraportti. MySQL serverin asennus Windows ympäristöön

Selvitysraportti. MySQL serverin asennus Windows ympäristöön Selvitysraportti MySQL serverin asennus Windows ympäristöön IIO30200 / Jouni Huotari Arto Sorsa / F3900 CREATIVE COMMONS LISENSOITU http://creativecommons.org/licenses/by-nc-sa/1.0/fi/ 26.4.2010 1 SISÄLTÖ

Lisätiedot