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

ePV 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 www.e-pv.nl Versie 1.0 Opdrachtgever Stuurgroep BBO

ePV Inhoudsopgave 1

Algemene inleiding _______________________________________________ 3

1.1

Opbouw en inhoud document ________________________________________ 3

2

Standaarden gebruikt voor het modelleren van de interactieprocessen ___ 4

2.1 2.2

Inleiding ________________________________________________________ 4 Vastlegging interactieprocessen ten behoeve van communicatie met deskundigen 5 2.2.1 OMP _________________________________________________________ 5 2.2.2 Oorsprong van OMP ____________________________________________ 6 2.2.3 Waarom OMP? _________________________________________________ 6 2.2.4 Voorbeelden ___________________________________________________ 6 2.2.5 Toepassing van OMP ____________________________________________ 8 Vastlegging interactieprocessen ten behoeve van implementatie van het proces 8 2.3.1 Inleiding ______________________________________________________ 8 2.3.2 UML _________________________________________________________ 8 2.3.3 ebXML________________________________________________________ 9 2.3.4 BPSS ________________________________________________________ 10 2.3.5 Voorbeelden __________________________________________________ 12

2.3

3

Standaarden voor het beschrijven van uitgewisselde bedrijfsdocumenten 14

3.1 3.2

Inleiding _______________________________________________________ 14 XML __________________________________________________________ 14 3.2.1 Wat is XML? __________________________________________________ 14 3.2.2 Oorsprong van XML ____________________________________________ 14 3.2.3 Waarom XML? ________________________________________________ 14 3.2.4 Toepassing van XML____________________________________________ 15 ebXML Core Components _________________________________________ 15 UBL___________________________________________________________ 16 UBL XML Schema generatie _______________________________________ 16 UBL en CC binnen ePV ___________________________________________ 17 Voorbeelden ____________________________________________________ 17

3.3 3.4 3.5 3.6 3.7

Datum: November 2006

Pagina 2 van 18

Beheerder: G-J van Lochem

Document: Handboek ePV deel 2

Project: BBO

Versie: 0.9

ePV 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.


Pagina 3 van 18



Project: BBO

Versie: 0.9

ePV 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.


Pagina 4 van 18



Project: BBO

Versie: 0.9

ePV 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 2.2.1

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


Pagina 5 van 18



Project: BBO

Versie: 0.9

ePV van een organisatie te maken. 2.2.2

Oorsprong van OMP

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 http://www.idef.com/idef0.html). 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 (http://www.sqeme.nl) 2.2.3

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 (http://www.in-pact.nl/). 2.2.4

Voorbeelden Ketenprocesmodel art. 8 WVW Versie: 0.1

Aanvraag bloed-/urinetest Transactievoorstel (politie) Dagvaarding

Opsporen Uitslag bloed-/ urinetest

PV invordering Proces-dossier

Transactievoorstel (OM) Uitslag bloed-/ urinetest????

Vervolgen

Dagvaardin g

Berechten Vonnis

Legenda:

Proces

Tenuitvoer leggen straf/maatregel Informatieproduct Sturend informatieproduct

Figuur 1 Voorbeeld OMP Proces: Art. 8 WvW


Pagina 6 van 18



Project: BBO

Versie: 0.9

ePV 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

Landelijk Overdrachtsformulier (LOF) “Politie” Voorgeleidings PV

Rapportage

1.Vroeghulp

Archiveren CJD

Rapportage

Geregistreerd procesdossier

RWOV Intake

Landelijk Overdrachtsformulier (LOF)

“Politie”

Advies rapportage

“Reclassering” “RC” (verdediging)

Verzoek uitbrengen rapportage

Inhoud Huidig persoonsdossier Archiveren CJD Bestaande rapportage uit persoonsdossier

2. Bepalen Noodzaak/vraagstelling Rapportage

Advies indicatiestelling

“FPD”

Opvragen inhoud persoonsdossier Opvragen bestaande rapportage persoonsdossier

3. Benoemingsadvies

Legenda:

Archiveren CJD

Opdracht rapportage Aanvraag benoemingsadvies

Benoemingsadvies

Proces

4. Benoemen rapporteur

InformatieProduct (binnen scope)

Opdracht rapportage

Opdracht rapportage

Benoeming rapporteur

InformatieProduct (buiten scope) Intrekken opdracht rapportage Sturend informatieproduct

“Aanvragende instantie”

Rappel

5. Inplannen / Uitvoeren onderzoek

Verzoek aanvulling Acceptatie Opdracht Rapportage Melding uitloop planning Planningsinformatie Reden niet rapporteren

“Aanvragende instantie”

Aanvullende informatie Proces Verbaal Bijlagen Rapportage

Archiveren CJD

Extern Proces

6. Verwerken rapportage Afloopbericht

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


Pagina 7 van 18



Project: BBO

Versie: 0.9

“Rapporterende instantie”

ePV o o o

2.2.5

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 2.3.1

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. 2.3.2

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 http://www.uml.org/). 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.


Pagina 8 van 18



Project: BBO

Versie: 0.9

ePV Voor de grafische weergave van de BPSS interactieprocessen wordt binnen ePV gebruik gemaakt van UML activity diagrammen. 2.3.3

ebXML

ebXML staat voor ’electronic business using eXtensible Markup Language’ (zie ook http://www.ebxml.org/). 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


Pagina 9 van 18



Project: BBO

Versie: 0.9

ePV 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 http://www.e-pv.nl/archief/Inhoudelijke%20producten/Voorzieningen/JAB), en gebruikt (delen) van de Core Components en BPSS (zie volgende paragraaf). 2.3.4

BPSS

Zoals gezegd sluit ePV voor de vastlegging van de interactieprocessen aan bij BPSS1 (zie ook http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp). 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 UMM is een op UML gebaseerde modelleringsmethode om de business services die iedere ketenpartner moet bieden om samen te werken te ontwerpen. Zie www.unece.org/cefact/umm/umm_index.htm 2


Pagina 10 van 18



Project: BBO

Versie: 0.9

ePV • •

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 http://www.ebpml.org/ebpml.doc). 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.


Pagina 11 van 18



Project: BBO

Versie: 0.9

ePV 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.


Pagina 12 van 18



Project: BBO

Versie: 0.9

ePV 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

Einde

Invordering rijbewijs

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.


Pagina 13 van 18



Project: BBO

Versie: 0.9

ePV 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: • •

•

3.2 3.2.1

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.

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. 3.2.2

Oorsprong van XML

XML is een standaard van het World Wide Web Consortium (W3C www.w3c.org), een onafhankelijke organisatie die deze en andere Open Standaarden beheert. Er is gebruik gemaakt van de XML 1.0 specificatie. 3.2.3

Waarom XML?

XML heeft de volgende eigenschappen:


Pagina 14 van 18



Project: BBO

Versie: 0.9

ePV •

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. 3.2.4

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 111793. 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 11179 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 www.iso.org


Pagina 15 van 18



Project: BBO

Versie: 0.9

ePV • • •

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-Schema5.

4 5

Zie www.oasis-open.org/committees/ubl/ Zie www.oasis-open.org/committees/ubl/ndrsc/


Pagina 16 van 18



Project: BBO

Versie: 0.9

ePV 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: Herkomst definitie: Formaat: Layout: Toegestane waarden: Commentaar:

Netnummer (Nederland) Netnummer Nederlands Communicatiegegevens Tekst Het deel van het telefoon- of faxnummer dat het locale of specifieke net binnen Nederland aanduidt. NEN 5825:2002 an..5 n.v.t. n.v.t. 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 11179. 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"> …..


Pagina 17 van 18



Project: BBO

Versie: 0.9

ePV <xsd:element name="NetnummerNederland" type="rtnl:TekstType" /> Het eindresultaat in een bericht zal dan kunnen zijn: 030


Pagina 18 van 18



Project: BBO

Versie: 0.9

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

Recommend Documents