epv Handboek epv Deel 2: Interoperabiliteitsraamwerk: Toelichting gebruikte standaarden Elektronische Berichtenuitwisseling in de Strafrechtsketen

Transcriptie

1 Elektronische Berichtenuitwisseling in de Strafrechtsketen Handboek epv Deel 2: Interoperabiliteitsraamwerk: Toelichting gebruikte standaarden Datum November 2006 Auteur Project BBO: Gerald Slot Gert-Jan van Lochem Versie 1.0 Opdrachtgever Stuurgroep BBO

2 Inhoudsopgave 1 Algemene inleiding Opbouw en inhoud document 3 2 Standaarden gebruikt voor het modelleren van de interactieprocessen Inleiding Vastlegging interactieprocessen ten behoeve van communicatie met deskundigen OMP Oorsprong van OMP Waarom OMP? Voorbeelden Toepassing van OMP Vastlegging interactieprocessen ten behoeve van implementatie van het proces Inleiding UML ebxml BPSS Voorbeelden 12 3 Standaarden voor het beschrijven van uitgewisselde bedrijfsdocumenten Inleiding XML Wat is XML? Oorsprong van XML Waarom XML? Toepassing van XML ebxml Core Components UBL UBL XML Schema generatie UBL en CC binnen epv Voorbeelden 17 Datum: November 2006 Pagina 2 van 18 Beheerder: G-J van Lochem

3 1 Algemene inleiding Dit document bevat een toelichting op het zogeheten interoperabiliteitsraamwerk van epv dat wil zeggen de toegepaste standaarden die bij het analyseren en ontwerpen van het elektronische berichtenverkeer zoals beschreven in dit handboek worden gebruikt. Dit document maakt deel uit van het Handboek epv. Voor een algemene inleiding wordt verwezen naar de delen 0 en 1 van dit handboek. Deel 3 van het handboek epv gaat in op de procedures (methode) voor het beschrijven van de uitwisselprocessen en de uit te wisselen gegevens op basis van standaarden zoals die zijn beschreven in dit deel 2. Deel 4 zal beschrijven hoe het beheer van de koppelvlakobjecten geregeld is. Deel 5 bevat de begrippenlijst. 1.1 Opbouw en inhoud document In essentie is epv gericht op het realiseren van een goede interoperabiliteit. Daarbij definieert epv interoperabiliteit als: De mate waarin twee of meer gelijksoortige, autonome entiteiten (i.e. organisaties, bedrijfsprocessen, applicaties, e.d.) met elkaar kunnen samenwerken op basis van vooraf bepaalde afspraken over o.a. gegevensuitwisseling, gegevensbetekenis en overkoepelende werkprocessen. Om tot een goede interoperabiliteit te komen zijn afspraken nodig op allerlei niveaus, zoals die zijn te onderscheiden in het conceptuele lagenmodel van epv. Deze afspraken zijn deels generiek en bedoeld voor de hele strafrechtsketen. Het zijn de kaders (architectuur, standaarden, e.d.) waarbinnen nadere, specifieke afspraken (koppelvlakken) zijn te maken gericht op een concrete samenwerking tussen enkele ketenpartners. De totale set van generieke afspraken wordt aangeduid als het interoperabiliteitsraamwerk van epv. Dit document bevat een toelichting op de standaarden en methoden die het interoperabiliteitsraamwerk epv vormen. Deze standaarden en methoden zijn gebruikt bij het beschrijven en uitwerken van het elektronische berichtenverkeer zoals beschreven in dit handboek. Daarbij wordt voor iedere methode en standaard besproken met welk doel deze wordt gebruikt, hoe deze wordt ingezet (geïllustreerd aan de hand van voorbeelden), en indien relevant wordt aangegeven welke onderdelen worden gebruikt. Dit document is als volgt opgebouwd: Hoofdstuk 2 beschrijft de standaarden die gebruikt worden bij het vastleggen van de interactieprocessen binnen de keten. Hoofdstuk 3 beschrijft de standaarden die gebruikt worden bij het vastleggen van de uit te wisselen gegevens. Datum: November 2006 Pagina 3 van 18 Beheerder: G-J van Lochem

4 2 Standaarden gebruikt voor het modelleren van de interactieprocessen 2.1 Inleiding Eén van de stappen binnen de epv methode is het vastleggen en standaardiseren van het interactieproces. Het interactieproces beschrijft de verschillende gegevensuitwisselingsactiviteiten die de ketenpartners in het kader van hun ketentaak uitvoeren. Daarbij wordt meestal uitgegaan van een bepaalde context, wat we ook wel een ketenproces noemen (zie het deel 1 van dit handboek). Zo kan een interactieproces bijvoorbeeld alle uitwisselingsactiviteiten beschrijven binnen de strafrechtsketen in het kader van de Wet op de OM afdoening, in het kader van het vervoer van gedetineerden of in het kader van het identificeren en verifiëren van verdachten gebruikmakend van zowel administratieve persoonsgegevens als biometrie. Het doel van het beschrijven van de interactieprocessen is eigenlijk tweeledig. Allereerst ontbreekt vaak een totaaloverzicht van de informatie die binnen de keten (c.q. ketenproces) tussen partijen wordt uitgewisseld. Het opstellen van een interactieproces helpt om alle uitgewisselde bedrijfsdocumenten boven water te krijgen zodat deze vervolgens gestandaardiseerd en beschreven kunnen worden. Daarnaast zullen tijdens het opstellen mogelijk allerlei regionale verschillen naar boven komen waarna gezocht kan worden naar een landelijk gestandaardiseerde procesgang die gebruikt kan worden voor de elektronische uitwisseling van gegevens binnen de keten. Want het uiteindelijke doel van het beschrijven van het interactieproces is de automatisering van dit interactieproces zodat de gegevens automatisch tussen de bedrijfssystemen van de partijen binnen die participeren in de keten c.q. het ketenproces uitgewisseld kunnen worden. Het beschreven interactieproces zal de basis vormen voor deze automatisering. Tevens bestaat de mogelijkheid om het toekomstige geautomatiseerde uitwisselingsproces op basis van het beschreven interactieproces te monitoren. Belangrijk is dat een interactieproces zich slechts richt op de uitwisselmomenten (interacties) tussen partijen. De bedrijfsprocessen die binnen de ketenpartners (partijen) plaatsvinden worden niet beschreven omdat dit buiten de scope van epv valt. Om de interactieprocessen te kunnen beschrijven is een bepaalde modelleringstaal c.q. methode nodig. Daarbij wordt zoveel mogelijk aangesloten bij bestaande standaarden. Belangrijke eisen aan de modelleringstaal voor interactieprocessen zijn: De opgestelde modellen moeten eenvoudig te begrijpen zijn voor domeindeskundigen binnen de strafrechtsketen. D.w.z. dat de modellen niet te technisch en gedetailleerd mogen zijn. Anderzijds zal het model voldoende detail moeten bevatten om het interactieproces uiteindelijk te kunnen automatiseren. Dit betekent dat minimaal de volgende zaken moeten kunnen worden vastgelegd: o De partijen / actoren die gegevens uitwisselen. o De bedrijfsdocumenten die worden uitgewisseld. o De volgorde in de tijd van de uitwisselingen. Met ondersteuning voor: Sequentiële uitvoering van uitwisselingsactiveiten. Datum: November 2006 Pagina 4 van 18 Beheerder: G-J van Lochem

5 o Parallelle uitvoering en synchronisatie van parallelle stromen. Conditionele uitvoering. Het vastleggen van allerlei afspraken m.b.t. een uitwisselingsactiviteit tussen twee partijen. Binnen epv wordt een dergelijke uitwisselingsactiviteit een bedrijfstransactie genoemd. Een bedrijfstransactie beschrijft het versturen van een bepaald bedrijfsdocument van een partij naar een andere partij. Deze ander partij kan als reactie hierop eventueel een ander bedrijfsdocument terugsturen. Voor een bedrijfstransactie moeten een aantal zaken vastgelegd kunnen worden: Welke bedrijfsdocumenten worden er binnen de transactie uitgewisseld. Hoeveel tijd heeft de ontvangende partij om: De ontvangst van het bedrijfsdocument te bevestigen. Het ontvangen bedrijfsdocument te accepteren. Te antwoorden op het ontvangen bedrijfsdocument (indien van toepassing). Indien er sprake is van een beantwoordend bedrijfsdocument. Hoeveel tijd heeft de ontvangende partij dan om: De ontvangst te bevestigen. Het beantwoordende bedrijfsdocument te accepteren. Op welke manier zullen de verstuurde bedrijfsdocumenten binnen de transactie worden beveiligd (versleuteling, digitale handtekeningen, etc.) Worden er (binaire) bijlagen meegestuurd met de bedrijfsdocumenten binnen de bedrijfstransactie. Onder welke condities is een bedrijfstransactie succesvol afgerond en onder welke condities onsuccesvol? Er is dus een balans nodig tussen heldere modellen die door domeindeskundigen te begrijpen zijn en gedetailleerde modellen die uiteindelijk geïmplementeerd kunnen worden. Binnen epv is daarom voor het volgende gekozen: Tijdens de workshops waarin de processen worden geïnventariseerd en initieel worden opgesteld wordt zoveel mogelijk aangesloten bij de belevingswereld van de domeindeskundigen voor het vastleggen van de interactieprocessen. Tot nu toe is hiervoor vaak gebruik gemaakt van OMP, maar ook UML use-cases of andere modelleringstechnieken kunnen worden gebruikt. Wanneer overeenstemming is ontstaan over het proces zullen de interactieprocessen ten behoeve van de uiteindelijke implementatie en vastlegging worden omgezet naar modellen die zijn opgezet m.b.v. het Business Process Specification Schema (BPSS ook wel ebbp). 2.2 Vastlegging interactieprocessen ten behoeve van communicatie met deskundigen OMP Zoals aangegeven in de inleiding wordt tijdens de workshops en voor het communiceren met domeindeskundigen tot nu toe vaak gebruik gemaakt van OMP. OMP is de Ordeningsmethodiek Processen; een methode om een model van de bedrijfsvoering Datum: November 2006 Pagina 5 van 18 Beheerder: G-J van Lochem

6 van een organisatie te maken Oorsprong van OMP epv OMP is binnen de strafrechtsketen het eerst toegepast door ABRIO in een samenwerkingsproject tussen de Nederlandse politie en het Openbaar Ministerie. OMP is een variant van IDEF0 (zie ook De verantwoordelijkheid voor het beheer van OMP is belegd bij het Kwaliteitsbureau Nederlandse Politie van het Nederlands Politie Instituut. De uitvoering van dit beheer is belegd bij de stichting In-pact. De modelleerwijze is tevens onderdeel van de SqEME methode voor procesmanagement, OMP en SqEME komen uit dezelfde basis toepassingen voort ( Waarom OMP? De IDEF0 modelleerwijze biedt een goed hulpmiddel om stapsgewijs van grofmazig naar fijnmazig processen in kaart te brengen. Daarnaast is de OMP notatie voor veel mensen in politie en justitieland al bekend. De teken- en schematechnieken van OMP worden voornamelijk gebruikt om een globaal procesmodel op te stellen dat bijvoorbeeld tijdens een workshop kan worden ingevuld en uitgebreid. Binnen epv wordt dit vaak het opstellen van een Landkaart processchema genoemd. De OMP notatie wordt hier niet nader toegelicht. Voor nadere informatie wordt verwezen naar de reader Lezen OMP-schema s welke kan worden opgevraagd bij In-pact te Houten ( Voorbeelden Ketenprocesmodel art. 8 WVW Versie: 0.1 Uitslag bloed-/ urinetest Opsporen Aanvraag bloed-/urinetest Transactievoorstel (politie) Dagvaarding PV invordering Proces-dossier Uitslag bloed-/ urinetest???? Vervolgen Dagvaardin g Transactievoorstel (OM) Legenda: Berechten Vonnis Proces Informatieproduct Tenuitvoer leggen straf/maatregel Sturend informatieproduct Figuur 1 Voorbeeld OMP Proces: Art. 8 WvW Datum: November 2006 Pagina 6 van 18 Beheerder: G-J van Lochem

7 Het bovenstaande OMP model is gebruikt als een vereenvoudigde weergave van het interactieproces binnen de strafrechtsketen. Tijdens de workshop waarin met de domeindeskundigen het proces rondom artikel 8 van de wegenverkeerswet (over rijden onder invloed) is geïnventariseerd is het bovenstaande model verder aangevuld en gecorrigeerd. Het model toont de vier hoofdprocessen van de strafrechtsketen: opsporen, vervolgen en berechten en tenuitvoerleggen straf. Tussen deze hoofdprocessen worden zogenaamde informatieproducten uitgewisseld. Daarbij wordt een onderscheid gemaakt tussen twee soorten informatieproducten: 1. Sturende informatieproducten: deze triggeren de start van een volgend proces 2. En informatieproducten die de input of output van een proces zijn. Ketenprocesmodel Persoonsdossier CJD Versie: 0.6 Politie Landelijk Overdrachtsformulier (LOF) Voorgeleidings PV 1.Vroeghulp Rapportage Rapportage Archiveren CJD RWOV Intake Geregistreerd procesdossier Politie Landelijk Overdrachtsformulier (LOF) Reclassering Advies rapportage RC (verdediging) Verzoek uitbrengen rapportage Archiveren CJD FPD Inhoud Huidig persoonsdossier Bestaande rapportage uit persoonsdossier Advies indicatiestelling 2. Bepalen Noodzaak/vraagstelling Rapportage Aanvraag benoemingsadvies Opvragen inhoud persoonsdossier Opvragen bestaande rapportage persoonsdossier Opdracht rapportage Archiveren CJD Legenda: 3. Benoemingsadvies Benoemingsadvies Proces Informatie- Product (binnen scope) 4. Benoemen rapporteur Opdracht rapportage Opdracht rapportage Informatie- Product (buiten scope) Sturend informatieproduct Aanvragende instantie Intrekken opdracht rapportage Rappel Aanvullende informatie Benoeming rapporteur 5. Inplannen / Uitvoeren onderzoek Verzoek aanvulling Acceptatie Opdracht Rapportage Melding uitloop planning Planningsinformatie Reden niet rapporteren Aanvragende instantie Proces Verbaal Bijlagen Rapportage Archiveren CJD Extern Proces 6. Verwerken rapportage Afloopbericht Rapporterende instantie Figuur 2 Voorbeeld OMP Proces: Rapportage proces CJD Het bovenstaande OMP model is de uitkomst van een workshop waarin het interactieproces m.b.t. persoonsrapportages in kaart is gebracht. In kaart zijn gebracht: De processtappen (1-6) De partijen buiten het primaire proces (aan de linker en rechter rand van het schema) Externe processen (ovaal binnen het schema) De benoemde informatieproducten (de pijlen). Hierin kan onderscheid worden gemaakt tussen Datum: November 2006 Pagina 7 van 18 Beheerder: G-J van Lochem

8 o o o De sturende informatieproducten (stromen vertikaal een processtap in). De informatieproducten die de input of output van een proces zijn (stromen horizontaal een processtap in of uit) De eventuele informatieproducten die buiten de scope zijn geplaatst (gearceerd) Toepassing van OMP De OMP notatie kan goed gebruikt worden om het proces op hoofdlijnen en op abstract niveau in kaart te brengen (Landkaart processchema). En omdat bepaalde complexe aspecten van het proces buiten beschouwing gelaten kunnen worden is het makkelijk communiceerbaar. OMP kan niet gebruikt worden als basis voor de implementatie van het proces omdat het een aantal zaken mist: De partijen die informatie uitwisselen worden niet vastgelegd. Er wordt gesproken over processen. Het proces vervolgen kan bijvoorbeeld zowel door het OM als door politie worden uitgevoerd (indien sommige vervolgingstaken aan de politie zijn gedelegeerd). Dit zie je niet terug in het OMP proces maar dit heb je voor de implementatie wel nodig. OMP onderkent het begrip transactie niet. Het is niet mogelijk om een informatieproduct als antwoord op een ander informatieproduct weer te geven. 2.3 Vastlegging interactieprocessen ten behoeve van implementatie van het proces Inleiding De mate van detaillering die nodig is bij het beschrijven van het interactieproces ten behoeve van de automatisering van dit proces is gevonden in de Business Process Specification Schema (BPSS) notatie. Binnen epv is er daarom voor gekozen hier bij aan te sluiten. Omdat BPSS een onderdeel is van ebxml en omdat voor de grafische weergave van de processen gebruik wordt gemaakt van UML zullen deze standaarden eerst worden toegelicht UML UML staat voor Unified Modelling Language en is een veelgebruikte modelleringstaal. Het is een door de OMG (Object Management Group) opgestelde verzameling van modelleringstechnieken (zie ook UML is toepasbaar binnen de object georiënteerde wereld. Een object georiënteerd model beschrijft objecten die met elkaar interacteren door elkaar berichten te sturen. Objecten weten bepaalde dingen (vastgelegd in attributen) en kunnen bepaalde dingen doen (vastgelegd in gedrag c.q. operaties van het object). UML kent dynamische modellen die de interacties tussen de objecten beschrijven, oftewel hoe de objecten binnen je domein samenwerken. Eén van de dynamische modellen binnen UML is een zogenaamd activity diagram. Een activity diagram beschrijft de flow van activiteiten binnen een proces. M.b.v. zogenaamde zwembanen kan worden aangegeven welke objecten verantwoordelijk zijn voor de uitvoer van de activiteiten. Datum: November 2006 Pagina 8 van 18 Beheerder: G-J van Lochem

9 Voor de grafische weergave van de BPSS interactieprocessen wordt binnen epv gebruik gemaakt van UML activity diagrammen ebxml ebxml staat voor electronic business using extensible Markup Language (zie ook Het is ontstaan vanuit een aantal ontwikkelingen: Het besef dat XML als webgebaseerde technologie meer mogelijkheden kan bieden voor kleine en middelgrote ondernemingen en ontwikkelingslanden dan de traditionele EDI frameworks. De mogelijkheid om met de komst van internet technologie computersystemen van verschillende organisaties aan elkaar te koppelen. Tot midden jaren 90 werd informatietechnologie voornamelijk toegepast binnen organisaties maar door het wijdverbreide gebruik van internet wordt het ook mogelijk om het tussen verschillende organisatie toe te passen. Daarnaast is de schaduwkant van het succes van XML dat er veel verschillende specificaties ontstaat en dit leidt tot veel overlap en verwarring. Er is dus behoefte aan een gestandaardiseerde specificatie. ebxml ziet voornamelijk een uitdaging in het creëren van wat zij noemen een collaborative commerce framework. Waarbij zowel grote enterprise systemen als bedrijfssystemen van kleinere en middelgrote bedrijven kunnen samenwerken. Men moet dus zaken kunnen doen onafhankelijk van de grootte en de geografische locatie van het bedrijf. Het ebxml framework biedt een set specificaties die de basis kunnen vormen voor een dergelijke collaborative commerce. Het ebxml framework is opgeleverd in 2001 en is het resultaat van een samenwerkingsverband tussen twee organisaties: 1. Het United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT) bekend van het UN/EDIFACT framework voor Electronic Data Interchange (EDI). 2. OASIS. Non profit organisatie die industriestandaarden op het gebied van interoperabiliteit identificeert, opstelt en beheert. Wanneer je de bedrijfsprocessen van verschillende organisaties aan elkaar wilt koppelen zijn er verschillende aspecten waarover afspraken gemaakt moeten worden. EbXML wil een aantal standaarden bieden voor deze verschillende aspecten. Dit is terug te vinden in de verschillende onderdelen van het ebxml framework: Overdracht: informatie moet op een veilige en bedrijfszekere manier verstuurd kunnen worden via internet. Binnen de ebxml Messaging Service (ebms) zijn specificaties vastgelegd voor het transport de routering en packaging van bedrijfstransacties. Semantische interoperabiliteit: de betekenis van de informatie moet voor alle betrokken partijen (en hun bedrijfssystemen) hetzelfde zijn. De ebxml Core Components specificatie biedt een manier bouwsteentjes waaruit de uit te Datum: November 2006 Pagina 9 van 18 Beheerder: G-J van Lochem

10 wisselen bedrijfsdocumenten bestaan op een syntax neutrale manier vast te leggen. Register: procesdefinities, berichten en gegevensdefinities kunnen worden opgeslagen in een bibliotheek of register. ebxml definieert de structuur van dat register en de manier waarop er via het internet gebruik van kan worden gemaakt. Proces: er moet overeenstemming zijn over welke informatie wanneer en voor wie nodig is. De ebxml Business Process Specification Schema (BPSS) kan een formele beschrijving van een business proces worden vastgelegd. epv is qua transportlaag gebaseerd op ebms (zie ook JAB, de Justitiestandaard Asynchrone Berichtenuitwisseling via en gebruikt (delen) van de Core Components en BPSS (zie volgende paragraaf) BPSS Zoals gezegd sluit epv voor de vastlegging van de interactieprocessen aan bij BPSS 1 (zie ook BPSS is een notatie in XML voor het vastleggen van interactieprocessen. Het kan puur voor het vastleggen van processen worden gebruikt, maar het kan ook gebruikt worden als formele specificatie om een ebxml infrastructuur te configureren om het proces te monitoren. De binnen BPSS gebruikte concepten bouwen voort op de UN/CEFACT Modeling Methodology specification (UMM) 2. Een interactieproces bestaat in BPSS termen uit: Business documents Business transactions, deze beschrijven een transactionele uitwisseling van bedrijfsdocumenten Collaborations, een verzameling Business transactions in een bepaalde volgorde. De kern van BPSS is het concept Business transaction. Alle berichtenuitwisselingen wordt gedefinieerd als een Bedrijfstransactie, waarbij een Bedrijfstransactie atomair is. Dat wil zeggen dat deze niet verder op te splitsen is. Globaal gezien bestaat een business transaction uit het versturen van een Bedrijfsbericht door een verzendende partij naar een ontvangende partij, optioneel gevolgd door een Antwoord bericht. Een bedrijfsbericht kan één of meer zogenaamde Business documents bevatten. Voor een business transaction kunnen allerlei afspraken worden vastgelegd: Welke business documents worden er (binnen bedrijfsberichten) uitgewisseld binnen de transactie Wil je wel of geen ontvangstbevestiging (binnen welke tijd) Wel of geen acceptatiebevestiging (binnen welke tijd) 1 In de nieuwste versie van ebxml wordt ook over ebbp of ebxml-bp gesproken i.p.v. BPSS 2 UMM is een op UML gebaseerde modelleringsmethode om de business services die iedere ketenpartner moet bieden om samen te werken te ontwerpen. Zie Datum: November 2006 Pagina 10 van 18 Beheerder: G-J van Lochem

11 Moeten berichten versleuteld worden De mogelijkheid om via een authenticatie mechanisme de identiteit van de verzender te kunnen vaststellen De onderlinge samenhang en volgordelijkheid wordt binnen BPSS beschreven met een zogenaamde collaboration. Daarbij maakt BPSS onderscheid tussen twee soorten collaborations: binary en multiparty. epv sluit aan bij de binnen BPSS gehanteerde benamingen. Alleen is voor een Nederlandse vertaling gekozen: Business Document = Bedrijfsdocument Business transaction = Bedrijfstransactie Collaboration = Interactieproces In de documentatie en boeken over BPSS werd gebruik gemaakt van een op UML gebaseerde grafische notatie. Deze notatie is geen onderdeel van de BPSS specificatie en is deels gebaseerd op een UML activity diagram en een aantal extensies om bedrijfstransacties te kunnen modelleren (zie de notatie van J.J. Dubray in het boek Professional ebxml foundations, en de notatie voor multiparty collaborations van J.J. Dubray in epv maakt dus gebruik van (een Nederlandse vertaling) van de begrippen binnen BPSS en van de grafische weergave van deze begrippen m.b.v. (een extensie op) UML activity diagrams. Op dit moment wordt er geen gebruik gemaakt van de formele BPSS XML notatie om de epv interactieprocessen vast te leggen. Datum: November 2006 Pagina 11 van 18 Beheerder: G-J van Lochem

12 2.3.5 Voorbeelden Het onderstaande voorbeeld bevat een deel van het interactieproces Invordering rijbewijs. Voor het weergeven van de verschillende partijen die binnen het proces een rol spelen wordt gebruik gemaakt van UML zwembanen (de verticale banen die de communicatie van één partij weergeeft). Ook voor de weergave van de procesgang wordt gebruik gemaakt van de UML activitity diagram notatie. Voor een toelichting hierop wordt verwezen naar UML literatuur. De activiteiten weergegeven in het proces staan voor bepaalde gegevensuitwisselingsactiviteiten oftewel bedrijfstransacties tussen twee partijen. Voor een bedrijfstransactie is een specifieke grafische notatie gekozen. De dikke zwarte pijl geeft aan tussen welke partijen de uitwisseling plaatsvindt, en wie hierin initiërend is (de richting). Figuur 3: Voorbeeld BPSS interactieproces Invordering Rijbewijs In het voorbeeld zal voor de bedrijfstransactie Vermelding Invordering Rijbewijs een uitwisseling plaatsvinden tussen de politie en de RDW. Omdat de pijl start bij Politie is de politie de initiërende partij en de RDW de ontvangende / beantwoordende partij. Een andere uitbreiding t.o.v. het standaard UML activity diagram is het volgende: Een speciale transitie tussen twee bedrijfstransacties is een zogenaamde wacht op transitie. Deze geeft weer dat het afwikkelen van een bepaalde bedrijfstransactie afhankelijk is van een andere bedrijfstransactie. Zo zal het OM de bedrijfstransactie PV Invordering Rijbewijs pas kunnen afronden nadat het OM de bedrijfstransactie Vermelding Inhouding/teruggave met de RDW hebben geïnitieerd en afgerond. Datum: November 2006 Pagina 12 van 18 Beheerder: G-J van Lochem

13 Een andere extensie die gemaakt is, is dat een interactieproces kan worden opgesplitst in diverse (deel) interactieprocessen die naar elkaar verwijzen. Interactieprocessen routinezaken Versie: 0.3 Politie OM NFI Start Afdoeningsaanvraag Verzoek Bevel Aanvraag bloed-/ urine-onderzoek IVS Invordering rijbewijs Einde Rapportage Schadebemiddeling Figuur 4: Voorbeeld interactieproces met subprocessen. De in figuur 4 weergegeven rechthoek met de naam Invordering rijbewijs staat voor een interactieproces dat elders verder is uitgewerkt. Datum: November 2006 Pagina 13 van 18 Beheerder: G-J van Lochem

14 3 Standaarden voor het beschrijven van uitgewisselde bedrijfsdocumenten 3.1 Inleiding epv standaardiseert naast het proces ook de gegevens die worden uitgewisseld binnen het proces en legt deze vast. Uiteindelijk zal epv een set XML-schema s opleveren die de bedrijfsdocumenten beschrijven die binnen het interactieproces worden uitgewisseld. Belangrijk is dat voor iedere partij glashelder is wat de betekenis is van de gegevenselementen die worden uitgewisseld (semantiek). De gegevensdefinities worden binnen epv vastgelegd in het gegevenswoordenboek. Ook hier is gebruik gemaakt van een aantal standaarden die in dit hoofdstuk worden beschreven. Belangrijke uitgangspunten bij het vastleggen en standaardiseren van de uit te wisselen gegevens zijn: De semantiek moet ondubbelzinnig vastgelegd kunnen worden. Veel gegevenselementen zullen worden hergebruikt over de verschillende ketenprocessen heen (bijvoorbeeld de definitie van adresgegevens). Dit moet gefaciliteerd worden. De semantiek van gegevenselementen wordt vastgelegd in een gegevenswoordenboek en de uiteindelijke bedrijfsdocumenten die worden uitgewisseld moeten worden opgebouwd m.b.v. de gedefinieerde gegevenselementen in een XML-Schema. Er moet op een eenvoudige manier voor gezorgd kunnen worden dat het gegevenswoordenboek en de definities van de bedrijfsdocumenten synchroon blijven lopen. 3.2 XML Wat is XML? epv maakt voor uitwisseling van berichten gebruik van de XML standaard. XML is de afkorting voor extensible Markup Language. XML is een manier om documenten te voorzien van structuurcodes, die op een voorspelbare wijze aangeven wat een tekstblok betekend, waar het begint, en waar het eindigt Oorsprong van XML XML is een standaard van het World Wide Web Consortium (W3C een onafhankelijke organisatie die deze en andere Open Standaarden beheert. Er is gebruik gemaakt van de XML 1.0 specificatie Waarom XML? XML heeft de volgende eigenschappen: Datum: November 2006 Pagina 14 van 18 Beheerder: G-J van Lochem

15 Platformneutraal. Een bericht in XML kan op ieder willekeurig platform worden ingelezen (Windows, UNIX, Apple etc.) waarbij gegarandeerd is dat de informatie op ieder platform op de zelfde manier kan worden geïnterpreteerd. Mediumneutraal. Informatie in XML kan op ieder medium worden getoond (papier, beeldscherm), waarbij telkens de informatie op dezelfde manier kan worden geïnterpreteerd. Productneutraal. Uit XML berichten kunnen nieuwe samenstellingen worden gemaakt(samenvoegen, delen selecteren) die weer aan de XML standaard voldoen Door bovenstaande eigenschappen zijn andere formaten (EDIFACT, ASN.1 enzovoorts.) via geautomatiseerde procedures genereerbaar. Dus als in een deel van de ketenpartners nog geen XML kan worden verwerkt, maar wel EDIFACT, dan kunnen deze berichten eenvoudig uit het XML worden gegenereerd. In XML is het eenvoudig om entiteiten en relaties van elkaar te scheiden. Zo kan het gegevenselement Natuurlijk Persoon éénmalig worden gedefinieerd, en overal waar dit gegeven nodig is wordt naar deze zelfde definitie verwezen Toepassing van XML Berichten worden uitgewisseld in XML, en de structuur is vastgelegd in XML Schema's (XSD). Daar waar informatie niet in XML beschikbaar is of het onmogelijk in XML te coderen is (denk aan foto's) wordt gebruik gemaakt van PDF en Imageformaten (JPG). 3.3 ebxml Core Components Voor het vastleggen van het gegevenswoordenboek wordt binnen epv gebruik gemaakt van een Nederlandse vertaling van een aantal concepten uit de ebxml Core Components specificatie. Core Components neemt als basis de ISO standaard Dit is een standaard die specificeert hoe je gegevenselementen zodanig kunt definiëren dat geautomatiseerde systemen op basis van deze definitie met elkaar kunnen praten. Het kernconcept van ISO is het concept van een data-element. Van een dataelement worden definitie, representatie / toegestane waarden vastgelegd in de attributen: Object class Property Representation Een voorbeeld uit het gegevenswoordenboek epv: Een gegevenselement dat de kleur van een voertuig representeert: Object class: Voertuig Property: Kleur Representation: Tekst Volgens de ISO standaard zou de naam van het gegevenselement dan worden: Voertuig_Kleur_Tekst Een ander voorbeeld is het geslacht van een persoon 3 Zie Datum: November 2006 Pagina 15 van 18 Beheerder: G-J van Lochem

16 Object class: Geboortegegevens Property: Geslacht Representation: Code Toegestane Waarden: 0. Onbekend 1. Mannelijk 2. Vrouwelijk 9. Niet gespecificeerd De ebxml core components neemt ISO11179 als uitgangspunt en breidt dit uit tot een specificatie waarmee herbruikbare gegevenselementen kunnen worden vastleggen die als bouwstenen voor de bedrijfsdocumenten kunnen worden gebruikt. De ebxml core components specificatie specificeert verschillende lagen van objecten die hergebruikt kunnen worden: Core components (CC): Op het laagste niveau heb je de core components. Deze kunnen onafhankelijk van een bepaalde context hergebruikt worden. Bijv. straatnaam. Aggregated Core components (ACC): Dit zijn aggregaties van core components. Bijvoorbeeld een adres. Business Information Entities (BIE): Dit zijn samenstellingen van CC s en ACC s gebruikt binnen een bepaalde context. Bijvoorbeeld een BIE strafbaar feit is alleen te gebruiken binnen de context van de strafrechtsketen. Business documents. De business documents tenslotte zijn weer samengesteld uit BIE s. ebxml Core Components is puur een specificatie en staat volledig los van een syntax. De syntax kan XML zijn maar bijvoorbeeld ook EDIFACT. Door toepassing van de Core Components standaardiseert epv op datatypen van gegevenselementen, naamgeving van gegevenselementen en standaard groeperingen van gegevenselementen. 3.4 UBL ebxml Core Components is dus syntax neutraal. UBL is een specifieke XML implementatie van ebxml Core Components. UBL staat voor Universal Business Language. UBL is een open bibliotheek van XML schema s die gebruikt kunnen worden voor elektronische handel. 4 UBL biedt XML schema s voor herbruikbare BIE zoals Address, Item, Payment enzovoorts, maar ook veelgebruikte Business documents zoals Order en Invoice. Beiden worden overigens niet gebruikt binnen epv, omdat ze in een geheel andere context passen, namelijk (elektronische) handel. 3.5 UBL XML Schema generatie Daarnaast heeft de UBL werkgroep van OASIS een document opgeleverd met Naming and Design Rules (NDR) waarin is vastgelegd hoe de concepten uit de core components specificatie vertaald kunnen worden naar een XML-Schema 5. 4 Zie 5 Zie Datum: November 2006 Pagina 16 van 18 Beheerder: G-J van Lochem

17 Daarbij heeft de werkgroep ter ondersteuning van henzelf een omgeving ingericht waarin de verschillende UBL core compontents, business information entities, business documents etc. kunnen worden gespecificeerd in een Metamodel. Vervolgens is er een conversie beschikbaar die dit Metamodel vertaalt naar een XML schema op basis van de Naming and Design Rules. 3.6 UBL en CC binnen epv Hieronder is een voorbeeld weergegeven van een gegevenselement zoals deze m.b.v. de ebxml Core Components standaard is vastgelegd in het gegevenswoordenboek van epv. Aanduiding: Property: Property qualifier: Object class: Object class qualifier: Representation: Repr. tabel: Definitie: Netnummer (Nederland) Netnummer Nederlands Communicatiegegevens Tekst Het deel van het telefoon- of faxnummer dat het locale of specifieke net binnen Nederland aanduidt. Herkomst definitie: NEN 5825:2002 Formaat: an..5 Layout: n.v.t. Toegestane waarden: n.v.t. Commentaar: Conform NEN 5825:2002 Bron = Telefoondienst leverancier Voor nummerplan zie Staatscourant 1999, nr. 14 epv maakt van de volgende onderdelen van UBL en CC gebruik: Core compontents: o De manier waarop de naam van een gegevenselement wordt vastgesteld (Objectclass, property, representation) eigenlijk ISO o De reeds voorgedefinieerde representations (Tekst, Number, ID), wel vertaald naar het Nederlands. Onderdelen van UBL. o Schema modules voor de standaard representations (Text, Number, etc.) o De UBL Naming and Design Rules om een XML schema te genereren. o Mechanisme om op basis van een Metamodel business documents samen te stellen te hiervan automatisch XML schema s te genereren. 3.7 Voorbeelden Op basis van de Naming and Design Rules overgenomen van UBL zal dit gegevenselement op de volgende manier vertaald worden een XML-Schema: <xsd:complextype name="communicatiegegevenstype"> <xsd:sequence> <xsd:element ref="netnummernederland" minoccurs="0" maxoccurs="1">.. Datum: November 2006 Pagina 17 van 18 Beheerder: G-J van Lochem

18 </xsd:element> </xsd:sequence> </xsd:complextype> <xsd:element name="netnummernederland" type="rtnl:teksttype" /> Het eindresultaat in een bericht zal dan kunnen zijn: <gwb:netnummernederland>030</gwb:netnummernederland> Datum: November 2006 Pagina 18 van 18 Beheerder: G-J van Lochem