SuwiML berichtstandaard

Rapport

SuwiML berichtstandaard

Auteur:

Paul Vriend, Dirk Temme

Datum document:

03-11-2005

Versie:

v0201

Status: Datum afdruk:

donderdag 3 november 2005

SuwiML berichtstandaard v0201.doc - 1 van 103


Documenthistorie Datum en versienummer

Auteur

0.1, 18/09/2001, Draft

Astrid Hackenberg

v0100, 20/12/2001, Definitief

Arjan Loeffen

v0200, 21/07/2005, Definitief

Paul Vriend

Opmerking

Volledige revisie, aanpassing en uitbreiding n.a.v. toetsing in de praktijk.

V0201, 03-11-2005

Dirk Temme

Blz 35: NB verwijderd voor optionele velden met waarde ‘Onbekend’; In de voorbeelden het gebruik van ‘ElementFormDefault’ aangepast;

Goedkeuring Datum

Naam

Functie

v0100, 20/12/2001

Domeingroep Gegevens en

Vertegenwoordiging Suwi keten.

Berichten (DGB). v0201, ??/??/2005

Domeingroep Gegevens en

Vertegenwoordiging Suwi keten.

Berichten (DGB).

Auteur: Paul Vriend, Dirk Temme



Inhoudsopgave 1.

Inleiding

7

1.1.

Doel

7

1.2.

Leeswijzer

7


8

2.1.

Inleiding

8

2.2.

SuwiML berichtidentificatie

10

2.3.

Validatie

12

SuwiML basisschema

13

3.1.

Inleiding

13

3.2.

Gegevenstypen

13

3.3.

Entiteiten

16

3.4.

Hiërarchie

17

3.5.

Automatisch tabellenbeheer

19

3.6.

Versienummering

21

SuwiML berichtschema

24

4.1.

Inleiding

24

4.2.

SuwiML body

24

Structuur

24

Voorbeelden

31

Lege velden / waarden in een SuwiML bericht

35

Afleiden berichtschema uit basisschema

35

Soorten relaties

37

2.

3.

4.




Voorbeeld

41

4.3.

Warning binnen SuwiML body

44

4.4.

Clusters binnen SuwiML body

45

4.5.

Beknopte samenvatting modellering SuwiML berichtschema

47

SuwiML berichtontwikkelingsmethodiek

49

5.1.

Inleiding

49

5.2.

Internationale ontwikkelingen mbt standaardisatie en berichtontwikkeling

49

UN/CEFACT Modelling Methodology

49

W3C

50

ISO 17113

50

ISO 11179

51

ebXml

51

Aanbevelingen met betrekking tot het berichtontwikkelingsproces

51

Het berichtontwikkelingsproces

52

Analyse, ontwerp, ontwikkeling

54

Implementatie en toepassing

54

Methodische ondersteuning van het berichtontwikkelingsproces

55

Procesmodel

55

State-transition-diagram

55

Time-sequence-diagram

55

Informatiemodel en berichthiërarchie

56

Specificatie van elektronische ketenberichten

56

Gegevensmodel

56

Berichtmodel

56

Specificatie van een elektronisch ketenbericht

58

5.

5.3.

5.4.

5.5.




6.

Definities

65

7.

Referenties

68

Appendix A

71

Lijst met figuren Figuur 1: opbouw SuwiML berichtschemaset.

8

Figuur 2: opbouw SuwiML berichtschema vanuit SGR/SuwiML.

9

Figuur 3: samenhang van standaarden en schema’s binnen SGR/SuwiML.

10

Figuur 4: voorbeeld van een SuwiML bericht met namespace verwijzingen.

11

Figuur 5: opbouw en onderlinge verhouding SuwiML basisschema modulen.

13

Figuur 6: voorbeeld van een onderdeel van de gegevenstypen-module.

14

Figuur 7: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Coded.xsd.

15

Figuur 8: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Typed.xsd.

16

Figuur 9: voorbeeld van een onderdeel van de entiteiten-module.

17

Figuur 10: opbouw en onderlinge verhouding SuwiML basisschema en SuwiML berichtschemaset.

17

Figuur 11: SOAP envelopeschema van een SuwiML Action berichtschema.

26

Figuur 12: SOAP envelopestructuur van een SuwiML Action berichtschema.

26

Figuur 13: SOAP envelopeschema van een SuwiML Reaction berichtschema.

28

Figuur 14: SOAP envelopestructuur van een SuwiML Reaction berichtschema.

29

Figuur 15: voorbeeld SuwiML Action bodyschema.

31

Figuur 16: voorbeeld SuwiML Reaction bodyschema.

33

Figuur 17: voorbeeld SuwiML Reaction response bericht.

34

Figuur 18: opbouw berichthiërarchie op basis van het SGR / het SuwiML basisschema.

37

Figuur 19: berichtinstantie irt SGR.

38

Figuur 20: berichtinstantie irt SGR met getypeerde relatie.

38

Figuur 21: berichtinstantie irt SGR met overerving van abstract datatype (eenvoudig).

38




Figuur 22: berichtinstantie irt SGR met overerving van abstract datatype (complex).

39

Figuur 23: berichtinstantie irt SGR, getypeerde relatie met overerving van abstract datatype.

40

Figuur 24: berichtinstantie irt SGR met abstracte subtypes.

41

Figuur 25: voorbeeld Entiteit-Relatie diagram voor ClientSuwi.

42

Figuur 26: SuwiML Reaction bodyschema met een verbijzondering van het XML complexType voor ClientSuwi. 43 Figuur 27: voorbeeld SuwiML Reaction response bericht met een warning.

45

Figuur 28: modelleren van clusters binnen SuwiML body.

47

Figuur 29: berichtontwikkelingsproces.

49

Figuur 30: ISO 17113 development of messages.

50


53

Figuur 32: schematisch voorbeeld van een gegevensmodel.

57

Figuur 33: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32.

57


57


57


57


58

Figuur 38: berichtmodel voor ReintegratieadviesCwiUwv zoals vastgelegd in EC-Design  .

71

Lijst met tabellen Tabel 1: opbouw SuwiML namespace.

11

Tabel 2: voorbeeldscenario van een aantal wijzigingen en de consequenties daarvan irt versienummers.

22

Tabel 3: opbouw SuwiML berichtschemaset.

25

Tabel 4: mogelijke combinaties van subelementen binnen het SuwiMLBody rootelement (onvermelde combinaties zijn niet mogelijk).

31

Tabel 5: beperkingen tav het gebruik van lege velden / waarden in een SuwiML bericht.

35




1. Inleiding 1.1.

Doel

SGR/SuwiML heeft tot doel de (elektronische) gegevensuitwisseling tussen partijen in de Suwi keten te faciliteren. Dit betreft zowel het faciliteren van de ontwikkeling van de gegevensuitwisseling (het zo eenvoudig mogelijk maken van het definiëren en realiseren van de gegevensuitwisseling, in de vorm van berichten) als de ondersteuning van de operationele gegevensuitwisseling (het run-time gebruik van SGR/SuwiML). Voor de definitie van de inhoud van berichten en de codering van de uit te wisselen gegevens wordt gebruik gemaakt van SGR/SuwiML, in de vorm van het Suwi Gegevensregister en extensies hierop voor uitwisseling in XML-formaat. SGR/SuwiML faciliteert het snel en eenduidig definiëren van de berichtinhoud (middels betekenis van gegevens, te gebruiken gegevenselementen, entiteiten en relaties), de berichtstructuur en de berichtnotatie (middels XML-tags, SuwiML basisschema, SuwiML berichtschema’s). Dit document beschrijft de functionele en technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de inhoudelijke structuur van de gegevens die moeten worden verstuurd. Dit document beschrijft de opzet en het gebruik van het SuwiML basisschema voor het definiëren van de body van SuwiML berichten. Daarmee biedt dit document een beschrijving voor het samenstellen van SuwiML berichtschema’s alsook toepassingsonafhankelijke richtlijnen voor het realiseren van gegevensuitwisseling tussen de partijen in de Suwi keten. De SuwiML berichtstandaard is bedoeld voor zowel informatieanalisten als software-engineers en is zowel gericht op het ontwikkelen van berichten als op de wijze waarop applicaties operationeel met berichten moeten omgaan.

1.2. •

Leeswijzer Hoofdstuk 2 geeft een algemene introductie op SGR/SuwiML en geeft een inleidende beschrijving van de SuwiML berichtstandaard.

•

Hoofdstuk 3 geeft een detail beschrijving van de opbouw en structuur van het SuwiML basisschema.

•

Hoofdstuk 4 geeft een detail beschrijving van de opbouw en structuur van een SuwiML berichtschema.

•

Hoofdstuk 5 geeft een detail beschrijving van de SuwiML berichtontwikkelingsmethodiek.

•

Hoofdstuk 6 geeft een beknopt overzicht van de gehanteerde definities.

NB. dit document veronderstelt dat de lezer een redelijke kennis van de XML en XML Schema standaard heeft. Voor meer informatie over deze en andere XML gerelateerde standaarden wordt verwezen naar de website van de W3C: http://www.w3c.org.




2. SuwiML berichtstandaard 2.1.

Inleiding

Alle betrokken partijen binnen de Suwi keten wisselen gegevens uit op basis van het Suwi Gegevensregister (SGR). Het SGR is het gegevensmodel met alle voor gemeenschappelijk gegevensgebruik in de Suwi keten relevante attributen, entiteiten en relaties. Zie het document Suwi Gegevensregister deel 1 en 2 (http://www.bkwi.nl) voor de inrichting van het SGR. SuwiML berichten, zoals deze worden verzonden tussen de betrokken partijen in de Suwi keten, worden afgeleid van het SGR. Entiteiten en attributen in het SGR keren terug als XML elementen in een SuwiML bericht. Een SuwiML bericht is opgemaakt als een hiërarchische reeks van XML gecodeerde gegevens. Berichten die behoren tot één berichttype, zijn te verdelen in twee groepen: het initiërende bericht, de Action, en het reagerende bericht, de Reaction. De structuur en inhoud van een SuwiML bericht wordt gevalideerd aan de hand van het SuwiML berichtschema dat eraan ten grondslag ligt. In SuwiML wordt de definitie van een logisch berichttype vastgelegd in twee SuwiML berichtschema’s met elk drie afzonderlijke XML Schema’s (een envelope-, header- en bodyschema voor het Action berichtschema en een envelope-, header- en bodyschema voor het Reaction berichtschema). Het Action berichtschema en het Reaction berichtschema samen vormen de SuwiML berichtschemaset voor het betreffende berichttype. Figuur 1 geeft hier een voorbeeld van. SuwiML berichtschemaset action

reaction

UwvDossierPersoon-EnvelopeAction.xsd

import

SuwiML-Header.xsd

import

UwvDossierPersoon-EnvelopeReaction.xsd

import

import

UwvDossierPersoon-BodyAction.xsd

UwvDossierPersoon -BodyReaction.xsd

Figuur 1: opbouw SuwiML berichtschemaset. Een op deze wijze gemodelleerd berichttype is onderdeel van een generieke methode voor het uitwisselen van berichten. Deze methode omvat de technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de envelopestructuur (het transportmiddel) en de wijze van verzending (het transport). De envelopestructuur wordt verplicht gebaseerd op de SOAP standaard. Zie het document SuwiML transactiestandaard voor een beschrijving van deze generieke methode voor het uitwisselen van berichten. De SuwiML berichtstandaard beschrijft de wijze waarop de SuwiML body moet worden vormgegeven op basis van de bouwstenen vastgelegd in het SuwiML basisschema. De SuwiML berichtstandaard maakt deel uit van SGR/SuwiML. SGR/SuwiML bestaat uit de volgende onderdelen: •

Suwi Gegevensregister (aangeduid als SGR: het gegevensmodel met alle voor gemeenschappelijk gegevensgebruik in de Suwi keten relevante attributen, entiteiten en relaties);




•

SuwiML basisschema (een XML Schema via welke de datatype informatie voor alle entiteiten en gegevenstypen uit het SGR in XML Schema formaat beschikbaar wordt gesteld);

•

SuwiML transactiestandaard (technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de envelopestructuur (het transportmiddel) en de wijze van verzending (het transport));

•

SuwiML berichtstandaard (functionele en technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de inhoudelijke structuur van de gegevens die moeten worden verstuurd).

In Figuur 2 worden de relaties tussen de verschillende onderdelen van SGR/SuwiML, noodzakelijk voor de opbouw van een SuwiML bericht, schematisch weergegeven. Het SuwiML basisschema is het XML synoniem voor het Suwi Gegevensregister en is van invloed op alle onderdelen van een SuwiML bericht. De SuwiML transactiestandaard schrijft de SOAP envelopestructuur voor, alsmede de stuurgegevens binnen de SuwiML header. De SuwiML berichtstandaard schrijft de opbouw van de SuwiML body voor. SuwiML berichtschema Suwi Gegevensregister

SOAP envelope

SuwiML basisschema

SOAP header SuwiML header

SuwiML transactiestandaard

SOAP body SuwiML body


Figuur 2: opbouw SuwiML berichtschema vanuit SGR/SuwiML. Een SuwiML bericht bestaat altijd uit een envelope die een header (de stuurgegevens) en een body (de berichtgegevens) bevat. De opbouw van een bericht door envelope, header en body staat beschreven in de SuwiML transactiestandaard en is gebaseerd op de SOAP standaard. Dit document, de SuwiML berichtstandaard, beschrijft de vormgeving van de body (de feitelijke berichtinhoud) van een SuwiML bericht. In Figuur 3 wordt de samenhang van de binnen SGR/SuwiML gebruikte standaarden en schema’s ten opzichte van elkaar weergegeven. Aan de linkerkant worden de gebruikte standaarden weergegeven en benoemd. De standaarden gezamenlijk beschrijven een generiek SuwiML bericht. De rechterkant toont een voorbeeld van een SuwiML bericht. De SuwiML transactiestandaard maakt gebruik van de standaard SOAP envelopestructuur en specificeert voor een bericht het headerschema met daarin de stuurgegevens. De SuwiML berichtstandaard specificeert de wijze waarop het bodyschema moet worden vormgegeven met behulp van het SuwiML basisschema.




Een SuwiML berichtschemaset wordt ontwikkeld door de ontwikkelaars binnen een project en is geënt op de formele richtlijnen zoals vastgesteld door SGR/SuwiML. Bij het samenstellen van een SuwiML berichtschemaset wordt gebruik gemaakt van het SuwiML basisschema, welke als grondslag dient voor alle SuwiML berichtschema’s. De berichtschemaset moet voordat het in gebruik kan worden genomen, worden getoetst aan de voorgeschreven SGR/SuwiML standaard. Deze toetsing wordt uitgevoerd door de beheerder/uitvoerder van SGR/SuwiML, i.e. het BKWI.

W3C standaard

Generiek bericht

Voorbeeld berichtinstantie (request)

SOAP

<SOAP- ENV:Envelope xmlns:SOAP- ENV="http :// schemas. xmlsoap. org/soap/envelope /" xmlns: smlb=" http://www. suwi. nl /SuwiML/ BodyAction/UwvDossierPersoon- v0302" xmlns: smlh=" http://www. suwi. nl /SuwiML/ Header -v0200" xmlns: xsi=" http://www .w3. org/2001/ /2001 /XMLSchema -instance" xsi:schemaLocation ="http :// schemas. xmlsoap. org/soap/envelope / UwvDossierPersoon- v0302 -b07 -EnvelopeAction .xsd">

SOAP -ENV: Envelope

SGR / SuwiML <SOAP- ENV:Header>

SuwiML header BerichtIdentificatie • BerichtType • IndTestbericht • etc.

Header

RouteInformatie Transactie

<smlh:SuwiMLHeader> … … …

SuwiML body • Request • Response • Redirect • Fault, Warning • Acknowledgement

Gegevens uitwisse ling uitwisseling functionele inhoud

<SOAP- ENV:Body> <smlb:SuwiMLBody> <smlb:SuwiMLBody> < smlb :Request … …>

SuwiML basisschema entiteiten module

Body

gegevenstypen module

Figuur 3: samenhang van standaarden en schema’s binnen SGR/SuwiML.

2.2.

SuwiML berichtidentificatie

SuwiML berichten worden beschreven in verscheidene schema’s: een envelope-schema, een header-schema en een body-schema. De berichtschema's die de Action en Reaction beschrijven, vormen samen een SuwiML berichtschemaset, die hoort bij een bepaald berichttype. Om de verschillende schema’s te onderscheiden wordt gebruik gemaakt van namespaces. Een namespace is een unieke naam die een specifiek definitiegebied aanduidt. Door een schema te definiëren binnen een eigen namespace worden conflicten voorkomen in naamgeving en kan eenduidigheid worden gewaarborgd van XML elementen type definities. Bij het vaststellen van een namespace moet rekening worden gehouden met de BerichtNaam, VersieMajor en VersieMinor (onderdeel van BerichtType) en het interactietype (Action of Reaction). De namespaces binnen SuwiML worden als volgt opgebouwd:




Schema

Namespace

Prefix

Basisschema

http://www.suwi.nl/SuwiML/Basis-v

sml

bijv.: http://www.suwi.nl/SuwiML/Basis-v0200 Body

http://www.suwi.nl/SuwiML/Body/-

smlb

v bijv.: http://www.suwi.nl/SuwiML/BodyAction/UwvDossierPersoon-v0302 bijv.: http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302 Header

http://www.suwi.nl/SuwiML/Header-v

smlh

bijv.: http://www.suwi.nl/SuwiML/Header-v0200 Envelope

http://schemas.xmlsoap.org/soap/envelope/

SOAPENV

Tabel 1: opbouw SuwiML namespace. Ieder SuwiML bericht wordt in de vorm van een SOAP envelope verstuurd. Dit betekent dat de SuwiML header en de SuwiML body in de SOAP envelope worden geïntegreerd. De koppeling tussen namespace en URL (locatie) wordt gemaakt met behulp van een XML Schema instance constructie, getoond in het XML voorbeeld in Figuur 4. <SOAP-ENV:Envelope xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:smlh = "http://www.suwi.nl/SuwiML/Header-v0200" xmlns:smlb = "http://www.suwi.nl/SuwiML/BodyAction/UwvDossierPersoon-v0302" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://schemas.xmlsoap.org/soap/envelope/ UwvDossierPersoon-v0302-b07-EnvelopeAction.xsd"> <SOAP-ENV:Header> <smlh:SuwiMLHeader> ... ... ... ... ... <SOAP-ENV:Body> <smlb:SuwiMLBody> ...

Figuur 4: voorbeeld van een SuwiML bericht met namespace verwijzingen.




2.3.

Validatie

Een SuwiML berichtschema is een formele beschrijving van een bericht conform SGR/SuwiML. De zendende partij heeft de verplichting om een, volgens het vastgestelde SuwiML berichtschema, valide bericht te versturen. De ontvanger moet ieder binnenkomend bericht valideren tegen het bijbehorende vastgestelde SuwiML berichtschema alvorens het intern verder te verwerken. NB. binnen een bericht wordt middels het statement ‘xsi:schemaLocation’ verwezen naar de locatie van het gerelateerde SuwiML berichtschema waar automatisch tegen gevalideerd kan worden. Om nu te voorkomen dat de verzender van het bericht de vrijheid heeft te verwijzen naar een willekeurig XML Schema op een willekeurige locatie, is het verplicht om bij de implementatie van iedere afzonderlijke gegevensuitwisseling ervoor te zorgen dat tegen een vooraf vastgesteld en op een specifieke locatie geplaatst SuwiML berichtschema wordt gevalideerd. Dit ongeacht de verwijzing in het ‘xsi:SchemaLocation’ statement in het bericht. Parsers die inkomende berichten automatisch verwerken moeten de verwijzing in het ‘xsi:schemaLocation’ statement dus feitelijk negeren, en gebruik maken van het vooraf vastgestelde en op een specifieke locatie geplaatste SuwiML berichtschema.




3. SuwiML basisschema 3.1.

Inleiding

Het SuwiML basisschema wordt direct afgeleid uit het SGR en bestaat uit een verzameling 'standaard componenten' op basis waarvan SuwiML berichtschema’s worden gedefinieerd. Het SuwiML basisschema bestaat uit twee modulen: de gegevenstypen-module en de entiteiten-module (zie Figuur 5). Hierin worden alle SGR-attributen zoals ‘Sofi-nummer’ en SGR-entiteiten zoals ‘ClientSuwi’ gedefinieerd. De relaties tussen entiteiten worden niet in het SuwiML basisschema gedefinieerd, deze worden (met het SGR als uitgangspunt) voor ieder afzonderlijk berichttype vastgelegd in de Action en Reaction SuwiML berichtschema’s.

SuwiML basisschema Entiteiten-module SGRentiteiten-v0200-b01.xsd

SuwiML-v0200-b01-Include-Coded.xsd SuwiML-v0200-b01-Include-Typed.xsd include

Gegevenstypen-module SGRgegevenstypen-v0200-b01.xsd

include

CdAoKlasse-v0200-b01-Coded.xsd

include

CdAoKlasse-v0200-b01-Typed.xsd

include

include Coded or Typed per

Figuur 5: opbouw en onderlinge verhouding SuwiML basisschema modulen.

3.2.

Gegevenstypen

Het SGR is een gegevensmodel welke alle voor gemeenschappelijk gegevensgebruik in de Suwi keten relevante attributen, entiteiten en relaties bevat. Iedere entiteit in het SGR bevat een aantal attributen, ieder attribuut verwijst naar een domeindefinitie voor het waardenbereik. In de gegevenstypen-module zijn alle SGR domeindefinities als verzameling samengebracht. Ieder SGRattribuut uit de entiteiten-module verwijst naar een SGR domeindefinitie uit de gegevenstypenmodule. Dit type is simpel (een tekenreeks zoals SofiNr of een gecodeerd waardebereik zoals Geslacht) of complex (een structuur zoals StandaardBedr), al naar gelang de aard van de SGR domeindefinitie die eraan ten grondslag ligt. Simpele typen worden als XML simpleType in het basisschema opgenomen; complexe typen worden als XML complexType gedefinieerd. De entiteiten-module en de gegevenstypen-module vormen samen het SuwiML basisschema. De entiteiten-module maakt gebruik van de SGR domeindefinities vastgelegd in de gegevenstypenmodule. Zowel de entiteiten-module als de gegevenstypen-module worden beiden in één en dezelfde namespace gedefinieerd: http://www.suwi.nl/SuwiML/Basis-v. Vanuit een SuwiML berichtschema wordt het SuwiML basisschema geïntegreerd met behulp van een




SuwiML basisschema-include-bestand: -v-b<Buildnr>Include.xsd. Het SuwiML basisschema -include-bestand incorporeert de entiteiten-module en de gegevenstypen-module. Bij het opstellen van een SuwiML berichtschema mag het SuwiML basisschema (de entiteiten-module en de gegevenstypen-module) niet worden aangepast. Zie ook Figuur 5 en Figuur 10. Alle SGR domeindefinities in de gegevenstypen-module zijn direct of indirect gebaseerd op XML Schema datatypen (built-in types), zoals string, integer, decimal, date etc. De XML Schema datatypen (built-in types) zijn gedefinieerd in de XML Schema standaard. Deze worden niet apart gedefinieerd binnen de SuwiML schema’s. <schema targetNamespace = "http://www.suwi.nl/SuwiML/Basis-v0200" xmlns = "http://www.w3.org/2001/XMLSchema" xmlns:sml = "http://www.suwi.nl/SuwiML/Basis-v0200"> <simpleType name="AantalN2"> <minInclusive value="0"/> <maxInclusive value="99"/> <simpleType name="AantSvDagenArbeidsverleden"> <minInclusive value="0"/> <maxInclusive value="52"/> <simpleType name="Abonneenr"> <maxLength value="10"/> <pattern value="\d*"/> <simpleType name="Netnr"> <maxLength value="5"/> <pattern value="\d*"/>

Figuur 6: voorbeeld van een onderdeel van de gegevenstypen-module. Figuur 6 toont een onderdeel van de gegevenstypen-module, waarin een aantal SGR domeindefinities worden gedefinieerd welke geen gecodeerd waardebereik hebben. De SGR domeindefinities Abonneenr en Netnr worden vastgelegd met behulp van XML simpleType definities,




welke worden gedefinieerd als built-in datatype string met pattern ‘\d*’ en maxLength ‘10’ respectievelijk ‘5’. De SGR domeindefinities AantSvDagenArbeidsverleden en AantalN2 worden vastgelegd met behulp van XML simpleType definities, welke worden gedefinieerd als built-in datatype nonNegativeInteger met totalDigits ‘2’, minInclusive ‘0’ en maxInclusive ‘52’ respectievelijk ‘99’. <schema targetNamespace = "http://www.suwi.nl/SuwiML/Basis-v0200" xmlns = "http://www.w3.org/2001/XMLSchema" xmlns:sml = "http://www.suwi.nl/SuwiML/Basis-v0200"> <simpleType name="Geslacht"> <enumeration value="0"> <documentation>onbekend <enumeration value="1"> <documentation>mannelijk <enumeration value="2"> <documentation>vrouwelijk <enumeration value="9"> <documentation>niet gespecificeerd (het gegevenselement wordt niet gevoerd in de administratie)

Figuur 7: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Coded.xsd. Figuur 7 toont een onderdeel van de gegevenstypen-module, waarin de SGR domeindefinitie voor Geslacht wordt gedefinieerd met een gecodeerd waardebereik. Geslacht wordt vastgelegd met behulp van een XML simpleType definitie, welke wordt gedefinieerd als built-in datatype string met daarop een restriction van enumerations ‘0’, ‘1’, ‘2’ en ‘9’, inclusief bijbehorende annotations. <schema targetNamespace = "http://www.suwi.nl/SuwiML/Basis-v0200" xmlns = "http://www.w3.org/2001/XMLSchema" xmlns:sml = "http://www.suwi.nl/SuwiML/Basis-v0200"> <simpleType name="Geslacht"> <pattern value="\d*"/>




Figuur 8: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Typed.xsd. Figuur 8 toont een alternatieve SGR domeindefinitie voor Geslacht, waarbij het gecodeerde waardebereik bewust achterwege is gelaten. Ook deze SGR domeindefinitie is onderdeel van de gegevenstypen-module. Bij gebruik van het SuwiML basisschema wordt steeds precies één van de twee SGR domeindefinities (Coded of Typed) gebruikt voor validatie. De Coded validatie laat exact en alleen het vooraf gedefinieerde gecodeerde waardebereik toe voor de betreffende SGR domeindefinitie. De Typed validatie is milder van aard en laat alle mogelijke waarden toe die voldoen aan de XML simpleType definitie voor de betreffende SGR domeindefinitie; hierbij zijn dus ook waarden toegestaan die niet noodzakelijk in het gecodeerde waardebereik vallen. In het voorbeeld hierboven voor Geslacht, zou bij gebruik van de Typed definitie ook de waarde ‘6’ zijn toegestaan, hoewel deze niet voorkomt in het gecodeerde waardebereik.

3.3.

Entiteiten

In de entiteiten-module wordt iedere SGR-entiteit gedefinieerd als een complex type (XML complexType). De SGR-attributen behorend bij een SGR-entiteit worden als een XML sequence van optionele elementen binnen het desbetreffende XML complexType gedefinieerd. Zoals gezegd verwijst ieder SGR-attribuut daarbij naar een SGR domeindefinitie uit de gegevenstypen-module. In de entiteiten-module worden geen SGR-relaties vastgelegd. De entiteiten-module is dus feitelijk een opsomming van losse SGR-entiteiten. Relaties tussen entiteiten worden (met het SGR als uitgangspunt) op berichtniveau vastgelegd, i.e. relaties worden in de Action en Reaction SuwiML berichtschema’s vastgelegd. Figuur 9 toont een onderdeel van de entiteiten-module, waarin de entiteiten Vreemdelingendocument en Ziektekostenverzekering middels XML complexTypes zijn gedefinieerd. Te zien is hoe de entiteit Vreemdelingendocument feitelijk een uitbreiding (XML extension) is van de entiteit VisDocument. Verder is te zien dat het attribuut NrVreemdelingendocument gebruik maakt van de SGR domeindefinitie NummerAN30 uit de gegevenstypen-module. <schema targetNamespace = "http://www.suwi.nl/SuwiML/Basis-v0200" xmlns = "http://www.w3.org/2001/XMLSchema" xmlns:sml = "http://www.suwi.nl/SuwiML/Basis-v0200"> <sequence> <element name="CdSrtVisDocument" type="sml:CdSrtVisDocument" minOccurs="0"/> <element name="CdLandVanUitgifteVisDocument" type="sml:LandenCdIsoA2" minOccurs="0"/> <extension base="sml:VisDocument">




<sequence> <element name="CdSrtVreemdelingendocument" type="sml:CdSrtVreemdelingendocument" minOccurs="0"/> <element name="NrVreemdelingendocument" type="sml:NummerAN30" minOccurs="0"/> <element name="DatEGeldigVreemdelingendocument" type="sml:Datum" minOccurs="0"/> <element name="IndArbeidToegestaan" type="sml:StdIndJN" minOccurs="0"/> <element name="IndTewerkstelvergunningVereist" type="sml:StdIndJN" minOccurs="0"/> <element name="IndVerlengingAangevraagd" type="sml:StdIndNvt" minOccurs="0"/> <sequence> <element name="Verzekerdennr" type="sml:Verzekerdennr" minOccurs="0"/> <element name="BedrPremieZiektekostenverz" type="sml:StandaardBedr" minOccurs="0"/> <element name="IndAanvullendVerzekerd" type="sml:StdIndOnb" minOccurs="0"/> <element name="BedrPremieAanvulZiektekostenverz" type="sml:StandaardBedr" minOccurs="0"/>

Figuur 9: voorbeeld van een onderdeel van de entiteiten-module.

3.4.

Hiërarchie

De gegevenstypen-module en entiteiten-module bestaan uit een aantal XML Schema's. In Figuur 10 staat aangegeven hoe deze zich tot elkaar verhouden, en op welke wijze een berichtschema er gebruik van maakt. De entiteiten-module komt overeen met precies één XML Schema, te weten SGRentiteiten-v-b<Buildnr>.xsd. Bij de gegevenstypen-module ligt de zaak complexer. SuwiML berichtschemaset action

reaction

UwvDossierPersoon -v0302 -b07 -EnvelopeAction .xsd

import

import

SuwiML -v0200 -Header .xsd

UwvDossierPersoon -v0302 -b07-EnvelopeReaction .xsd

import

import

UwvDossierPersoon-v0302-b07-BodyAction.xsd

import UwvDossierPersoon -v0302 -b07-Include.xsd import

UwvDossierPersoon-v0302-b07-BodyReaction.xsd

SuwiML basisschema Entiteiten-module SGRentiteiten-v0200-b01.xsd

include

Gegevenstypen-module SGRgegevenstypen -v0200-b01.xsd

include

CdAoKlasse -v0200-b01-Coded.xsd

include

CdAoKlasse -v0200-b01-Typed.xsd

include

include Coded or Typed per

Figuur 10: opbouw en onderlinge verhouding SuwiML basisschema en SuwiML berichtschemaset.




Gegevens kunnen naar diverse soorten SGR domeindefinities verwijzen. Naast de ongecodeerde domeindefinities gebaseerd op string, date, etc., al dan niet voorzien van een beperkend pattern, maxLength, etc., zijn er ook de gecodeerde domeindefinities op basis van XML enumerations . Deze XML enumerations beschrijven een lijst met specifieke codes (waarden) eventueel gecombineerd met een omschrijving. Een eenvoudig voorbeeld is de enumeration voor Geslacht, bestaande uit de codes ‘0’, ‘1’, ‘2’ en ‘9’, overeenkomend met de omschrijvingen Onbekend, Mannelijk, Vrouwelijk en Niet Gespecificeerd, zie Figuur 7. In dit voorbeeld is de lijst met codes statisch, i.e. hij wijzigt niet of nauwelijks. Er zijn echter ook dynamische codelijsten die vaak wijzigen. De structuur van de gegevenstypen-module is zodanig gekozen, dat codes kunnen wijzigen zonder de bijbehorende programmatuur te moeten herprogrammeren of herconfigureren. Het eenvoudigweg uploaden van de nieuwe codelijst moet volstaan om de programmatuur weer up-to-date te brengen. Iedere SGR domeindefinitie waarvoor een codelijst beschikbaar is, wordt vastgelegd in twee verschillende XML Schema varianten, een Coded en een Typed schema. De Coded variant beschrijft de domeindefinitie als een specifieke XML enumeration van codewaarden en codeomschrijvingen, waardoor een "strenge" validatie mogelijk is; Figuur 7 geeft een voorbeeld. De Typed variant beschrijft dezelfde domeindefinitie slechts als een pattern, waardoor een “milde” validatie mogelijk is, waarbij niet bestaande codes die wel binnen de type- en patterndefinitie passen, geen foutmelding opleveren; Figuur 8 geeft een voorbeeld. De keus voor Coded of Typed is afhankelijk van de toepassing, en wordt per SuwiML berichtschema vastgelegd in een apart -v-b<Buildnr>-Include.xsd schema, welke wordt afgeleid van één van de template schema’s: SuwiML-v-b<Buildnr>-Include-Coded.xsd

of

SuwiML-v-b<Buildnr>-Include-Typed.xsd. Binnen het afgeleide berichtspecifieke include schema kan voor elke afzonderlijke domeindefinitie (waarvoor een codelijst beschikbaar is), gekozen worden of er gebruik wordt gemaakt van de Coded of Typed variant. De keuze voor het gebruik van Coded en/of Typed kan dus per berichttype verschillen. In het meest extreme geval wordt voor het ene berichttype alleen gebruik gemaakt van Coded en voor het andere berichttype alleen van Typed. Wat betreft de keuze voor Coded en/of Typed zijn twee strategieën denkbaar: 1.

Zoveel mogelijk gebruik maken van de Coded variant; het berichtschema dwingt bij de validatie van berichten door de verzendende/ontvangende adapter de specifieke codewaarden af conform het SGR. Hiermee wordt de verwerking in de verzendende/ontvangende applicatie feitelijk ontlast, omdat daar dan zonder verdere controle mag worden aangenomen dat aan het vereiste codewaardebereik is voldaan. Voordeel van deze strategie is, dat er alleen gegarandeerd goede berichten worden verzonden/ontvangen en dat deze garantie reeds op adapternivo wordt afgedwongen. Nadeel van deze strategie is, dat bij aanpassingen van de aan het berichttype gerelateerde codelijsten, het berichtschema ook moet worden aangepast en in een nieuwe versie moet worden gepubliceerd en geïmplementeerd.




2.

Zoveel mogelijk gebruik maken van de Typed variant; het berichtschema dwingt bij de validatie van berichten door de verzendende/ontvangende adapter slechts het formaat af conform het SGR. Hiermee kan dus niet worden gegarandeerd dat ieder verzonden/ontvangen bericht alleen geldige codewaarden conform het SGR bevat. Hiermee wordt de verwerking in de verzendende/ontvangende applicatie feitelijk extra belast, omdat daar dan moet worden gecontroleerd of aan het vereiste codewaardebereik is voldaan. Voordeel van deze strategie is, dat bij aanpassingen van de aan het berichttype gerelateerde codelijsten, het berichtschema niet noodzakelijk hoeft te worden aangepast. Nadeel van deze strategie is, dat de applicaties zodanig moeten worden geconfigureerd, dat ze altijd aan de meest actuele set van codewaardebereiken voldoen. Bij de samenstelling en/of verwerking van berichten door de applicatie moet het codewaardebereik worden afgedwongen.

Naar verwachting vindt in de toekomst de berichtuitwisseling plaats op basis van de Typed variant (strategie 2) en vindt de validatie tegen het codewaardebereik plaats in de diverse applicaties. Hiermee wordt de stabiliteit van de (operationele) elektronische ketenberichten bevorderd, hetgeen voordelen oplevert voor de beheerlast en implementatielast van berichtspecificaties. Het actueel houden van de codewaardebereiken binnen de applicaties vindt zoveel als mogelijk automatisch plaats door het inlezen van de nieuwste versie van het SuwiML basisschema.

3.5.

Automatisch tabellenbeheer

Omdat in de praktijk de gecodeerde waardebereiken van bepaalde SGR domeindefinities regelmatig wijzigen, moet ook het SuwiML basisschema hierop regelmatig worden aangepast. Voor het vastleggen van het SuwiML basisschema is een structuur bedacht, die het mogelijk maakt om volledig geautomatiseerd het SuwiML basisschema (of gerichte delen daarvan) te updaten. Deze structuur staat in sectie 3.4 beschreven en wordt vastgelegd in meerdere losse b estanden: •

SGRentiteiten-v-b<Buildnr>.xsd Een alfabetische opsomming van alle SGR entiteiten en gegevenselementen (attributen), vastgelegd in een XML Schema.

•

SGRgegevenstypen-v-b<Buildnr>.xsd Een alfabetische opsomming van alle SGR domeindefinities waarvoor géén gecodeerd waardebereik bestaat, vastgelegd in een XML Schema.

•

-v-b<Buildnr>-Coded.xsd Een apart XML Schema voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat. Alle geldige codes zijn als XML enumerations gespecificeerd inclusief bijbehorende omschrijving.

•

-v-b<Buildnr>-Typed.xsd Een apart XML Schema voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat. Er wordt geen gebruik gemaakt van XML enumerations voor alle geldige codes, maar slechts van een beperkte formaatdefinitie waarin de toegestane lengte en karakters worden vastgelegd.




•

-v-b<Buildnr>.xml Een aparte XML instance voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat. Alle geldige codes zijn als waarden gespecificeerd inclusief bijbehorende omschrijving. Bovendien wordt hier per code vastgelegd wat de datum begin geldigheid en datum einde geldigheid is.

Zoals gezegd worden alle onderdelen van het SuwiML basisschema vastgelegd in één en dezelfde namespace. Met behulp van het include bestand worden de afzonderlijke XML Schema onderdelen middels XML include statements ingelezen. Daarbij wordt voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat, steeds een keuze gemaakt of er gebruik wordt gemaakt van Coded.xsd (strikte validatie tegen de feitelijk toegestane codes) of van Typed.xsd (slechts beperkte/milde validatie tegen de formaatdefinitie). Bovendien kan de verzameling XML instances, voor SGR domeindefinities met een gecodeerd waardebereik, met behulp van een tabelindex (SGRtabelindex-vb<Buildnr>.xml), met verwijzingen naar de actuele bestandsnamen van deze XML instances, geautomatiseerd ingelezen worden door een applicatie. Op deze wijze is een applicatie dus altijd verzekerd van de meest actuele verzameling SGR tabellen/codelijsten. In combinatie met de hier beschreven tabelindex is ook een overzicht van SGR domeinverwijzingen (SGRdomeinverwijzingen-v-b<Buildnr>.xml) beschikbaar. Het SGR domeinverwijzingen overzicht geeft per SGR gegevenselement (attribuut) aan van welke SGR domeindefinitie, inclusief aanduiding , gebruik wordt gemaakt. In de beschreven structuur, leidt de toevoeging van een code aan het gecodeerde waardebereik van een SGR domeindefinitie dus slechts tot een nieuwe versie van het bijbehorende Coded.xsd bestand, de bijbehorende XML instance en het include bestand. De tabelindex wordt in lijn hiermee geactualiseerd en de domeinverwijzingen eventueel ook als de wijziging tot een nieuwe leidt. SuwiML berichtschema’s kunnen op een vergelijkbare manier als applicaties gebruik maken van de beschreven structuur van het SuwiML basisschema. Het idee hierbij is dat een bepaalde versie van een SuwiML berichtschema gebruik maakt van een bepaalde versie (freeze) van het SuwiML basisschema. Eventuele aanpassingen in het SuwiML basisschema worden dus pas in een volgende versie van het SuwiML berichtschema toegepast/gebruikt. De hier beschreven structuur voor het SuwiML basisschema moet er toe leiden dat de meest actuele set van bestanden waarin het SuwiML basisschema is vastgelegd, steeds on-line beschikbaar is. Alle (applicatiebeheerders van) ketenpartners kunnen nu op ieder gewenst moment het SuwiML basisschema of gerichte onderdelen daarvan, downloaden en binnen de eigen operationele omgeving implementeren. Hiermee kan het proces van het publiceren van SuwiML basisschema updates door het BKWI en het controleren, downloaden en installeren van deze updates door ketenpartners geautomatiseerd worden.




3.6.

Versienummering

Indien voor een SGR domeindefinitie een code wordt toegevoegd, of een andere wijziging wordt doorgevoerd, dan heeft dit gevolgen voor de versienummering van het SuwiML basisschema. Tabel 2 geeft een overzicht van alle mogelijke wijzigingen en de consequenties voor de versienummering van het SuwiML basisschema.



•


v0102-b01

v0102-b01

v0102-b01

v0102-b02

v0102-b01

v0102-b01

v0200-b01

v0200-b01

v0200-b01

v0200-b01

v0200-b01

Pattern [a-z0-9] in TypeY wordt [a-z]

Tabel 2: voorbeeldscenario van een aantal wijzigingen en de consequenties daarvan irt versienummers.

De regels zijn in het kort als volgt.

Als een domeindefinitie, attribuut of entiteit wordt gewijzigd, dan verandert ook het versienummer

(versie major, versie minor en/of buildnummer) van het basisschema;

SuwiML berichtstandaard v0201.doc - 22 van 103 v0102-b01

v0102-b01

v0102-b01

v0102-b01

v0102-b01

v0102-b01

v0102-b01

Er wordt een code toegevoegd aan TypeX

v0102-b01

v0101-b01

v0101-b01

v0101-b02

v0101-b01

v0101-b01

v0101-b01

v0101-b02

v0101-b01

van 2 naar 1 positie

v0200-b01

v0102-b01

Grote structurele wijziging in Entiteiten/Attributen

v0200-b01

Maximale lengte van TypeX wordt teruggebracht

v0101-b01

v0101-b01

v0101-b01

v0101-b01

v0101-b01

v0101-b01

v0101-b01

v0101-b01

v0100-b03

v0100-b04

v0100-b02

v0100-b01

v0100-b01

v0100-b01

v0100-b03

v0100-b04

v0100-b04

Pattern [a-z] in TypeY wordt [a-z0-9]

v0101-b01

v0100-b03

v0100-b01

v0100-b02

v0100-b01

v0100-b01

v0100-b01

v0100-b03

v0100-b01

v0100-b03

Er wordt een code toegevoegd aan TypeY

v0101-b02

v0100-b01

v0100-b01

v0100-b02

v0100-b01

v0100-b01

v0100-b01

v0100-b02

v0100-b01

v0100-b02


v0102-b01

v0100-b01

v0100-b01

v0100-b01

v0100-b01

v0100-b01

v0100-b01

v0100-b01

v0100-b01

v0100-b01

Initieel

v0102-b02

v0102-b02

TypeY-Coded

TypeY-Typed

TypeX-Coded

TypeX-Typed

SGRgegevenstypen

SGRentiteiten

SuwiML-Include-Coded

SuwiML-Include-Typed

SuwiML basisschema

Soort wijziging

v0200-b01


v0200-b01



•

Als het waardebereik van de domeindefinities in het nieuwe basisschema (na het doorvoeren van de wijziging) het waardebereik van de domeindefinities in het oude basisschema (voor het doorvoeren van de wijziging) volledig bevat, dan wordt het buildnummer van het basisschema met één opgehoogd en wordt het buildnummer van het subschema waarin de betreffende domeindefinitie is opgenomen gelijkgesteld aan die van het basisschema. Alle andere subschema’s blijven ongewijzigd en behouden het reeds geldende buildnummer. Voorbeelden zijn het toevoegen van een code, het beëindigen van de geldigheid van een code (waarbij de code dus niet wordt verwijderd), het uitbreiden van een pattern, het vergroten van de maxLength, het verlagen van de minOccurs en het verhogen van de maxOccurs. Ook het aanpassen van de omschrijving behorend bij een reeds bestaande code, resulteert in het ophogen van het buildnummer (mits de aangepaste omschrijving qua betekenis gelijk blijft aan de oorspronkelijke omschrijving);

•

Als het waardebereik van de domeindefinities in het nieuwe basisschema (na het doorvoeren van de wijziging) het waardebereik van de domeindefinities in het oude basisschema (voor het doorvoeren van de wijziging) niet volledig bevat, dan verandert de versie minor van alle files. Alle buildnummers worden dan op ‘01’ teruggezet. Voorbeelden zijn het verkleinen van de maxLength, het verlagen van de maxOccurs, het verhogen van de minOccurs, het beperken van een pattern, het wijzigen van de length, het verwijderen van een code of het aanpassen van de betekenis (omschrijving) van een code. Ook het veranderen van de naam van een entiteit of attribuut resulteert in het ophogen van de versie minor en het resetten van het buildnummer naar ‘01’;

•

Grote wijzigingen, zoals het qua betekenis en opbouw herdefiniëren van entiteiten en attributen, leiden tot een wijziging van de versie major. Alle versie minor en buildnummers worden dan op ‘01’ teruggezet.




4. SuwiML berichtschema 4.1.

Inleiding

Een SuwiML bericht wordt in een SOAP envelope verstuurd. Onderdeel van deze SOAP envelope zijn een header en een body. De header legt de stuurgegevens vast die van belang zijn voor de routering en de logistieke verwerking van het bericht. De body bevat de functionele inhoud die moet worden uitgewisseld. De SOAP envelope en SuwiML header worden beschreven in de SuwiML transactiestandaard. De SuwiML body wordt hier beschreven. Voor de theoretische onderbouwing van de berichtontwikkelingsmethodiek biedt hoofdstuk 5 uitkomst, in het bijzonder sectie 5.5.

4.2.

SuwiML body

Structuur Ieder SuwiML bericht dat wordt verzonden, is gerelateerd aan een SuwiML berichtschemaset. Een SuwiML berichtschemaset bestaat uit een SuwiML berichtschema voor het Action bericht en een SuwiML berichtschema voor het Reaction bericht. Een SuwiML berichtschema bestaat uit een SOAP envelopeschema dat een SuwiML headerschema en een SuwiML bodyschema importeert; zie Figuur 1, Figuur 11 en Figuur 13. Een SuwiML bodyschema beschrijft exact hoe de body van een specifiek berichttype wordt opgebouwd; zie Tabel 3, Figuur 12 en Figuur 14. Schema

Bestand, Tag en Namespace

SOAP envelope Action

-v-b<Buildnr>-Envelope.xsd bijv.: UwvDossierPersoon-v0302-b07-EnvelopeAction.xsd <SOAP-ENV:Envelope> http://schemas.xmlsoap.org/soap/envelope/

Reaction -v-b<Buildnr>-Envelope.xsd bijv.: UwvDossierPersoon-v0302-b07-EnvelopeReaction.xsd <SOAP-ENV:Envelope> http://schemas.xmlsoap.org/soap/envelope/ SuwiML header Action

SuwiML-v-Header.xsd

Reaction bijv.: SuwiML-v0200-Header.xsd <SOAP-ENV:Envelope> <SOAP-ENV:Header> <smlh:SuwiMLHeader> http://www.suwi.nl/SuwiML/Header-v bijv.: http://www.suwi.nl/SuwiML/Header-v0200




Schema

Bestand, Tag en Namespace

SuwiML body

Action

-v-b<Buildnr>-Body.xsd bijv.: UwvDossierPersoon-v0302-b07-BodyAction.xsd -v-b<Buildnr>-Include.xsd bijv.: UwvDossierPersoon-v0302-b07-Include.xsd <SOAP-ENV:Envelope> <SOAP-ENV:Body> <smlb:SuwiMLBody> http://www.suwi.nl/SuwiML/Body/- bijv.: http://www.suwi.nl/SuwiML/BodyAction/UwvDossierPersoon-v0302

Reaction -v-b<Buildnr>-Body.xsd bijv.: UwvDossierPersoon-v0302-b07-BodyReaction.xsd -v-b<Buildnr>-Include.xsd bijv.: UwvDossierPersoon-v0302-b07-Include.xsd <SOAP-ENV:Envelope> <SOAP-ENV:Body> <smlb:SuwiMLBody> http://www.suwi.nl/SuwiML/Body/- bijv.: http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302

Tabel 3: opbouw SuwiML berichtschemaset. Gedurende het ontwikkelingstraject van een berichttype wordt de VersieMajor en de VersieMinor van de betreffende berichtschemaset zoveel mogelijk ongemoeid gelaten. Dit heeft als voordeel dat de namespaces voor de betreffende berichtschemaset ook stabiel blijven. Wijzigingen in de berichtspecificatie, i.e. in de berichtschemaset, worden opgevangen met behulp van het Buildnr; deze hoogt bij iedere wijziging steeds met één op. Zodra een berichtschemaset in productie wordt genomen, wordt de VersieMajor, de VersieMinor en het Buildnr gefixeerd (‘bevroren’). Eventuele aanpassingen die daarna volgen, maken automatisch deel uit van een nieuw ontwikkelingstraject waaraan een nieuwe combinatie VersieMajor, VersieMinor wordt gerelateerd. In het algemeen geldt dus dat iedere functionele wijziging in de specificatie van een berichttype, die leidt tot een aanpassing van één of meer van de XML Schema’s waaruit de berichtschemaset is opgebouwd, ook automatisch leidt tot een nieuwe build-/versieaanduiding voor de gehele berichtschemaset. Dus zelfs als bijvoorbeeld alleen het Action deel van een berichtschemaset moet worden aangepast, dan krijgt toch de gehele berichtschemaset een nieuwe build-/versieaanduiding. <schema targetNamespace xmlns xmlns:smlb xmlns:smlh xmlns:SOAP-ENV elementFormDefault

= = = = = =

"http://schemas.xmlsoap.org/soap/envelope/" "http://www.w3.org/2001/XMLSchema" "http://www.suwi.nl/SuwiML/BodyAction/UwvDossierPersoon-v0302" "http://www.suwi.nl/SuwiML/Header-v0200" "http://schemas.xmlsoap.org/soap/envelope/" "qualified">




<element name="Envelope" type="SOAP-ENV:Envelope"/> <sequence> <element name="Header" type="SOAP-ENV:Header"/> <element name="Body" type="SOAP-ENV:Body"/> <sequence> <element ref="smlh:SuwiMLHeader"> <sequence> <element ref="smlb:SuwiMLBody">

Figuur 11: SOAP envelopeschema van een SuwiML Action berichtschema. Een XML Schema definieert een rootelement en haar subelementen. Het rootelement van het SuwiML bodyschema is altijd <SuwiMLBody>. Figuur 12, Figuur 14 en Tabel 4 tonen welke subelementen binnen het <SuwiMLBody> rootelement kunnen voorkomen. Welk subelement in een bepaalde situatie voor mag komen hangt af van en correspondeert met het interactietype (Action of Reaction) en het CommunicatieType en het CommunicatieElement in de SuwiML header.

Figuur 12: SOAP envelopestructuur van een SuwiML Action berichtschema.




<schema targetNamespace xmlns xmlns:smlb xmlns:smlh xmlns:SOAP-ENV elementFormDefault

= = = = = =

"http://schemas.xmlsoap.org/soap/envelope/" "http://www.w3.org/2001/XMLSchema" "http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302" "http://www.suwi.nl/SuwiML/Header-v0200" "http://schemas.xmlsoap.org/soap/envelope/" "qualified">

<element name="Envelope" type="SOAP-ENV:Envelope"/> <sequence> <element name="Header" type="SOAP-ENV:Header"/> <element name="Body" type="SOAP-ENV:Body"/> <sequence> <element ref="smlh:SuwiMLHeader"> <element name="Fault" type="SOAP-ENV:Fault"> <element ref="smlb:SuwiMLBody"> <sequence> <element name="faultcode" type="QName"/> <element name="faultstring" type="string"/> <element name="faultactor" type="anyURI" minOccurs="0"/> <element name="detail" type="SOAP-ENV:detail" minOccurs="0"/> <sequence>




<element ref="smlb:Fout" maxOccurs="unbounded">

Figuur 13: SOAP envelopeschema van een SuwiML Reaction berichtschema.




Figuur 14: SOAP envelopestructuur van een SuwiML Reaction berichtschema.




CommunicatieType

CommunicatieElement

SuwiMLBody

Opmerking

Inkijk

Request

Request

Een Request betreft een verzoek om gegevens

Melding

dan wel een verzoek tot verwerking van

(Action)

gegevens. In het geval van een verzoek om gegevens, bevat een Request de sleutelinformatie die benodigd is om een bepaalde vraag te kunnen beantwoorden. Bijvoorbeeld: een sofi-nummer indien er gevraagd wordt om het dossier van een client.

Inkijk

Response

Response

(Reaction)

Een Response bevat de middels een Request opgevraagde gegevens. Bijvoorbeeld: een ClientSuwi met alle daaraan gerelateerde gegevens, indien er gevraagd werd om het dossier van een client.

Warning

Wanneer zich, bij de verwerking van een Request, een bijzondere vermeldenswaardige situatie in de applicatielaag voordoet, wordt een Warning verstuurd. NB. bij een Warning gaat het niet om een foutsituatie in de applicatielaag, maar om een foutloze verwerking van een Request, waarbij de geleverde gegevens in de Response op zich juist zijn, maar vergezeld worden van een waarschuwing. Bijvoorbeeld dat de persoon in kwestie is overleden of geëmigreerd. NB. een Warning wordt altijd verstuurd in combinatie met een Response. Het opnemen van een Warning bij de Response is optioneel.

Inkijk

Fout

(Reaction)

Response

Wanneer zich, bij de verwerking van een Request,

Fault

een functionele fout in de applicatielaag voordoet, wordt een Fault verstuurd. NB. het gaat hier niet om foutmeldingen uit de berichtlaag of transportlaag, want die worden middels SOAP en/of HTTP afgehandeld (zie ook de SuwiML transactiestandaard). NB. een Fault wordt altijd verstuurd in combinatie met een lege/gedeeltelijke Response.

Warning

Het opnemen van een Warning bij de Fault en lege/gedeeltelijke Response is optioneel.




CommunicatieType

CommunicatieElement

SuwiMLBody

Opmerking

Inkijk

Redirect

Redirect

Een Redirect bevat een verwijzing naar één of

Melding

meer alternatieve diensten welke in staat zijn de

(Reaction)

oorspronkelijke Request te beantwoorden.

Melding

Acknowledgement

(Reaction)

Acknowledge

Is vooral bruikbaar indien er sprake is van

ment

gegevensuitwisseling over een asynchrone transportlaag.

Tabel 4: mogelijke combinaties van subelementen binnen het SuwiMLBody rootelement (onvermelde combinaties zijn niet mogelijk).

Voorbeelden Figuur 15 geeft een voorbeeld SuwiML bodyschema voor de Action . Het schema importeert eerst het SuwiML basisschema, middels het berichtspecifieke include schema. Vervolgens wordt het rootelement SuwiMLBody gedefinieerd, dat bestaat uit een Request. <schema targetNamespace xmlns xmlns:sml xmlns:smlb

= = = =

"http://www.suwi.nl/SuwiML/BodyAction/UwvDossierPersoon-v0302" "http://www.w3.org/2001/XMLSchema" "http://www.suwi.nl/SuwiML/Basis-v0200" "http://www.suwi.nl/SuwiML/BodyAction/UwvDossierPersoon-v0302">

<element name="SuwiMLBody" type="smlb:SuwiMLBody"/> <sequence> <element name="Request" type="smlb:Request"/> <sequence> <element name="SofiNr" type="sml:SofiNr"/>

Figuur 15: voorbeeld SuwiML Action bodyschema. Figuur 16 geeft een voorbeeld SuwiML bodyschema voor de Reaction. Het schema importeert eerst het SuwiML basisschema, middels het berichtspecifieke include schema. Vervolgens wordt het rootelement SuwiMLBody gedefinieerd, dat bestaat uit een keuze (XML choice) tussen een Redirect een Response of een Acknowledgement, waarbij een Response eventueel vergezeld kan gaan door een Fault en/of Warning. De Response bestaat uit precies één optioneel subelement ClientSuwi. Dit




element heeft (verplicht) dezelfde naam als de SGR-entiteit (XML complexType) waaraan het refereert. Het subelement ClientSuwi heeft vervolgens hiërarchische relaties met TelefoonnrClient en Ziektekostenverzekering. <schema targetNamespace xmlns xmlns:sml xmlns:smlb

= = = =

"http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302" "http://www.w3.org/2001/XMLSchema" "http://www.suwi.nl/SuwiML/Basis-v0200" "http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302">

<element name="SuwiMLBody" type="smlb:SuwiMLBody"/> <element name="Redirect" type="smlb:Redirect"/> <sequence> <element name="Response" type="smlb:Response"/> <element name="Fault" type="smlb:Fault" minOccurs="0"/> <element name="Warning" type="smlb:Warning" minOccurs="0"/> <element name="Acknowledgement" type="smlb:Acknowledgement"/> <sequence> <element name="ExpiresAfterSeconds" type="nonNegativeInteger" minOccurs="0"/> <element name="CompoundService" type="smlb:CompoundService"/> <element name="AlternativeServiceSet" type="smlb:AlternativeServiceSet"/> <element name="Service" type="smlb:Service"/> ... ... ... <sequence> <element name="ClientSuwi" minOccurs="0"> <extension base="sml:ClientSuwi"> <sequence> <element name="TelefoonnrClient" type="sml:StandaardTelefoonnr" minOccurs="0" maxOccurs="unbounded"/>




<element name="Ziektekostenverzekering" type="sml:Ziektekostenverzekering" minOccurs="0"/> <sequence> <element name="Fout" type="smlb:Fout" maxOccurs="unbounded"/> <element name="Fout" type="smlb:Fout"/> ... <sequence> <element name="Waarschuwing" type="smlb:Waarschuwing" maxOccurs="unbounded"/> ... <sequence/>

Figuur 16: voorbeeld SuwiML Reaction bodyschema. Figuur 17 geeft een uitgewerkt voorbeeld van het body gedeelte van een SuwiML bericht. Het betreft een response, waarin gegevens zijn opgenomen aangaande een enkele ClientSuwi. Dit omvat onder meer een sofinummer, geslacht, telefoonnummer en een ziektekostenverzekering. Alle data zijn fictief. <SOAP-ENV:Envelope xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:smlh = "http://www.suwi.nl/SuwiML/Header-v0200" xmlns:smlb = "http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://schemas.xmlsoap.org/soap/envelope/ UwvDossierPersoon-v0302-b07-EnvelopeReaction.xsd"> <SOAP-ENV:Header> <smlh:SuwiMLHeader> ... <SOAP-ENV:Body>




<smlb:SuwiMLBody> <SofiNr>123456789 Jan J <SignificantDeelVanDeAchternaam>Jansen 19700101 1 0001 020 9999999 Amicon 0

Figuur 17: voorbeeld SuwiML Reaction response bericht. Een SuwiML bericht voldoet altijd aan een SuwiML berichtschema, waarnaar wordt verwezen vanuit het rootelement <SOAP-ENV:Envelope>. Een SuwiML berichtschema bestaat uit entiteiten, attributen en domeindefinities zoals vastgelegd in het SuwiML basisschema, en berichtspecifieke relaties tussen entiteiten, die waar mogelijk gebaseerd worden op de relaties zoals vastgelegd in het SGR.




Lege velden / waarden in een SuwiML bericht In het geval de verzender van een SuwiML berichtinstantie voor bepaalde velden in het bericht geen waarde beschikbaar heeft, kunnen zich de volgende situaties voordoen: SuwiML

SuwiML berichtinstantie

SuwiML berichtinstantie

berichtschema

waarde beschikbaar

geen waarde beschikbaar

veld is optioneel

In het geval een veld optioneel is volgens het

In het geval een veld optioneel is volgens het

SuwiML berichtschema en er is een waarde

SuwiML berichtschema en er is geen waarde

beschikbaar, dan moet dit veld in het bericht

beschikbaar, dan moet dit veld in het bericht

opgenomen worden met een geldige waarde.

achterwege blijven. Het veld mag dan dus niet

Het veld mag dan dus niet achterwege blijven.

met een open- en close-tag worden

NB. een ongeldige waarde zal

opgenomen zonder feitelijke waarde.

vanzelfsprekend tot een foutmelding leiden bij de samenstelling en validatie van het bericht. veld is verplicht

In het geval een veld verplicht is volgens het

In het geval een veld verplicht is volgens het

SuwiML berichtschem a, dan moet dit veld

SuwiML berichtschema, dan moet dit veld

altijd in het bericht opgenomen worden met

altijd in het bericht opgenomen worden met

een geldige waarde. Het veld mag dan dus in

een geldige waarde. Het veld mag dan dus in

geen geval achterwege blijven.

geen geval achterwege blijven.

NB. een ongeldige waarde zal

NB. het ontbreken (niet beschikbaar zijn) van

vanzelfsprekend tot een foutmelding leiden bij

een geldige waarde zal vanzelfsprekend tot

de samenstelling en validatie van het bericht.

een foutmelding leiden bij de samenstelling en validatie van het bericht. NB. als voor dit veld in het SGR een waarde is gedefinieerd die aangeeft dat het veld leeg/onbekend is, dan dient bij het ontbreken (niet beschikbaar zijn) van een geldige waarde, deze indicatie "leeg/onbekend" te worden gebruikt in het bericht, bijvoorbeeld bij "Geslacht" de waarde "0" indien "onbekend".

Tabel 5: beperkingen tav het gebruik van lege velden / waarden in een SuwiML bericht. In het algemeen geldt dat wat ook in een SuwiML berichtinstantie wordt gestopt, het altijd, ook bij foutsituaties, moet voldoen aan het bijbehorende SuwiML berichtschema. De zender heeft de verplichting dit te garanderen, de ontvanger moet dit controleren.

Afleiden berichtschema uit basisschema Een SuwiML berichtschema is samengesteld uit drie gerelateerde XML Schema’s: een SOAP envelopeschema, een SuwiML headerschema en een SuwiML bodyschema. Het SuwiML bodyschema maakt via het berichtspecifieke include schema direct gebruik van de XML Schema's van het SuwiML basisschema. De SGR-entiteiten (XML complexType) in het SuwiML basisschema




vormen dus op deze wijze de basis voor het samenstellen van een SuwiML berichtschema. Zie Figuur 10. Het SuwiML basisschema vormt het uitgangspunt voor de definitie van SuwiML berichtschema’s. Dat wil niet zeggen dat wanneer in een bericht gegevens worden opgenomen over bijvoorbeeld een Partner, verplicht de complete definitie van Partner uit het SuwiML basisschema moet worden overgenomen. Alleen die gegevens die binnen het SuwiML basisschema over een Partner zijn vastgelegd én werkelijk van belang zijn voor het bericht, worden in het SuwiML berichtschema opgenomen. Dit geldt voor de entiteiten, de attributen en de relaties uit het SGR. Figuur 18 geeft aan op welke wijze de berichthiërarchie voor een SuwiML berichtschema wordt opgebouwd aan de hand van het SGR en het SuwiML basisschema. Ieder SuwiML berichtschema gebruikt het SGR en het SuwiML basisschema als uitgangspunt. Iedere relatie, entiteit of attribuut uit het SGR / het SuwiML basisschema wordt in een SuwiML berichtschema 1-op-1 overgenomen door middel van een directe referentie naar het SuwiML basisschema, of wordt verbijzonderd voor het betreffende berichttype. Verbijzonderen betekent dat: •

optionele entiteiten of attributen in het SGR / het SuwiML basisschema, in het SuwiML berichtschema verplicht mogen worden gemaakt of mogen worden weggelaten;

•

verplichte entiteiten of attributen in het SGR / het SuwiML basisschema, in het SuwiML berichtschema niet mogen worden weggelaten en niet optioneel mogen worden gemaakt;

•

herhaalbare entiteiten (1:n relaties) mogen worden beperkt in hun herhaalbaarheid, bijvoorbeeld maxOccurs=“unbounded” beperken tot maxOccurs=“10” of maxOccurs=“1”;

•

entiteiten (relaties) niet mogen worden uitgebreid in hun herhaalbaarheid, dus niet van maxOccurs=“1” naar maxOccurs=“10”;

•

het waardebereik van attributen mag worden beperkt tot een subset van het toegestane waardebereik zoals is gedefinieerd in het SGR;

•

geen nieuwe attributen, entiteiten of hiërarchische relaties mogen worden toegevoegd, dus geen uitbreidingen ten opzichte van het SGR en het SuwiML basisschema. NB. mocht er tijdens het berichtontwikkelingstraject de functionele behoefte bestaan om nieuwe entiteiten of attributen op te nemen welke nog niet gedefinieerd en vastgelegd zijn in het SGR, dan wordt dit (in bepaalde gevallen) toegestaan, onder het voorbehoud dat deze entiteiten/attributen via een CMK (Centraal Meldpunt Ketenwijzigingen) wijzigingsverzoek worden aangemeld voor definitie en vastlegging in het SGR en het SuwiML baisschema. Een dergelijk CMK wijzigingsverzoek wordt behandeld door de Werkgroep Gegevensbeheer (WGB). Het opnemen van de nieuwe entiteiten of attributen gebeurt dus onder het voorbehoud van goedkeuring door de WGB.




veralgemeniseren

Suwi Gegevensregister SuwiML basisschema

afleiden

Transactie hiërarchie afleiden

Bericht hiërarchie

verbijzonderen

Figuur 18: opbouw berichthiërarchie op basis van het SGR / het SuwiML basisschema. In principe wordt in een SuwiML berichtschema dus altijd verwezen naar de XML complexType definities uit het SuwiML basisschema. In het geval dat voor een specifiek berichttype een XML complexType definitie wordt verbijzonderd (uitbreiden mag niet!) dan wordt de betreffende XML complexType definitie uit het SuwiML basisschema gekopieerd naar de berichtspecifieke body en daar aangepast. Zie Figuur 26. Bij het vaststellen van een SuwiML berichtschema worden de entiteiten op basis van de relaties uit het SGR, in een hiërarchische structuur aan elkaar gerelateerd. Hierbij wordt iedere relatie als een XML element gedefinieerd binnen een bestaande XML complexType definitie voor een SGR-entiteit. Dit gebeurt met behulp van het XML extension statement. Een relatie in het gegevensregister tussen entiteit A en B wordt, afhankelijk van het "gezichtspunt" van de relatie, in het bericht opgenomen, door een element B op te nemen als child van element A. Er zijn een aantal varianten te onderscheiden, welke worden beschreven in de volgende sectie.

Soorten relaties Er zijn drie soorten relaties, te weten de "gewone" relatie tussen fundamentele entiteiten, de getypeerde relatie, en de afleiding (subclass) van een abstracte entiteit (superclass). Hoe deze verschillende relaties tot een bericht leiden, wordt aan de hand van een aantal voorbeelden uitgelegd. In de voorbeelden staat aan de linkerzijde een stukje entity-relation diagram, en aan de rechter zijde een voorbeeld van een berichttype dat past bij het diagram. Er wordt een berichtinstantie getoond in plaats van een XML Schema om de leesbaarheid te verbeteren.




Gegevensmodel SGR

Berichtinstantie

A attribuutA1 attribuutA2

B attribuutB1 attribuutB2

Figuur 19: berichtinstantie irt SGR. In Figuur 19 staat een eenvoudige relatie uitgewerkt. Een praktijkvoorbeeld is een ClientSuwi die een Uitkering krijgt. A komt dan overeen met ClientSuwi en B komt dan overeen met Uitkering. In de berichtinstantie wordt entiteit Uitkering als child element opgenomen binnen element ClientSuwi. De attributen van ClientSuwi zijn Achternaam, Geboortedatum, etc.; die van Uitkering zijn Bedrag, Periode, etc. Zowel A als B kunnen uiteraard meerdere relaties met andere entiteiten hebben. Gegevensmodel SGR

Berichtinstantie

A

<X>

attribuutA1 attribuutA2

X

Y


Figuur 20: berichtinstantie irt SGR met getypeerde relatie. Een bijzondere situatie ontstaat als er meer dan één relatie tussen twee entiteiten bestaat. Om deze relaties te kunnen onderscheiden, krijgen ze een naam; met andere woorden, de relaties worden getypeerd. Figuur 20 schetst een dergelijke situatie. In de praktijk gaat het bijvoorbeeld om Adres (B), die een relatie heeft met ClientSuwi (A) als DomicilieAdres (X) en als PostAdres (Y). Gegevensmodel SGR A


B

abstract

Berichtinstantie

attribuutB1 attribuutB2

of

subclass

C1

C2

attribuutC11 attribuutC12


Figuur 21: berichtinstantie irt SGR met overerving van abstract datatype (eenvoudig).




Vanuit het object georiënteerd modelleren, is in de entity-relation wereld ook het abstracte datatype doorgedrongen. Een abstracte entiteit (superclass) komt nooit zelfstandig voor, maar dient als basis, of als bouwsteen voor een andere entiteit. In Figuur 21 is een dergelijke relatie weergegeven. Een praktijkvoorbeeld is een ClientSuwi (A) met een Uitkering (B). Er zijn echter meerdere soorten uitkeringen, zoals Wwb (C1) en W w (C2). Deze uitkeringen hebben gemeenschappelijke attributen van de entiteit Uitkering (B), zoals Bedrag, Periode, etc. Deze gemeenschappelijke attributen zijn gemodelleerd in de abstracte entiteit (superclass) Uitkering (B), terwijl specifieke kenmerken zijn gemodelleerd in de subclass. Zo zou W w (C2) als attribuut NaamLaatsteWerkgever kunnen hebben, de naam van de laatste Werkgever waar de ClientSuwi werkzaam was. In het bericht zal binnen element ClientSuwi (A) nooit element Uitkering (B) voorkomen, maar altijd Wwb (C1) en/of Ww (C2). De attributen uit de abstracte entiteit (superclass) Uitkering (B) worden door de subclassen Wwb (C1) en/of Ww (C2) overerft. NB. het is niet mogelijk dat een subclass attributen overerft uit meer dan één abstracte entiteit (superclass). Deze zogenaamde ‘multiple inheritance’ wordt niet ondersteund. Gegevensmodel SGR


B

abstract

Berichtinstantie

A


of

D attribuutD1 attribuutD2

subclass

C1

C2



E attribuutD1 attribuutD2

<E>

Figuur 22: berichtinstantie irt SGR met overerving van abstract datatype (complex). In Figuur 22 is een meer complex voorbeeld gegeven, waarin wordt aangegeven dat ook de relaties van de abstracte entiteit worden overgeërfd door de subclass, en dat subclasses ook specifieke relaties kunnen hebben.




Gegevensmodel SGR

Berichtinstantie

A

<X>


X

abstract

Y

Z


C1 subclass attribuutC11 attribuutC12

C2 attribuutC21 attribuutC22

D attribuutD1 attribuutD2

Let op: voor zowel X, Y als Z zou subclass C1 of C2 gemodelleerd kunnen zijn. Er zijn dus 8 verschillende instantie vormen mogelijk. Hierboven is er slechts één uitgewerkt.

Figuur 23: berichtinstantie irt SGR, getypeerde relatie met overerving van abstract datatype. Uiteraard kan ook een afgeleide entiteit (subclass) onderdeel zijn van een getypeerde relatie. In Figuur 23 is een voorbeeld uitgewerkt. In wezen is dit niet meer dan een combinatie van de voorbeelden uit Figuur 20 en Figuur 21. Ook hier geldt dat de abstracte entiteit (B) niet in het bericht is terug te vinden, maar wel de typering van de relatie (X, Y, Z).




Gegevensmodel SGR A attribuutA1 attribuutA2

B

abstract


subclass

abstract subclass

D1 subclass attribuutD11 attribuutD12

Berichtinstantie

C1

C2



D2

E

attribuutD21 attribuutD22

attribuutE1 attribuutE2

<E>

of <E>

of

Figuur 24: berichtinstantie irt SGR met abstracte subtypes. Abstracte entiteiten kunnen uit meerdere niveaus zijn opgebouwd. Doel is minimaliseren van definities van dezelfde objecten en eigenschappen. In Figuur 24 is een voorbeeld met twee niveaus weergegeven, maar in de werkelijkheid kunnen ook meer dan twee niveaus voorkomen.

Voorbeeld Figuur 26 geeft een voorbeeld van een SuwiML bodyschema met getypeerde relaties (Domicilieadres en FeitelijkAdres) met een abstracte entiteit (Adres). Hierin is bovendien binnen de Response een verbijzondering opgenomen van de SGR-entiteit ClientSuwi, waarnaar wordt gerefereerd middels de namespace-prefix smlb in smlb:ClientSuwi. Feitelijk is in het SuwiML bodyschema een kopie opgenomen van de oorspronkelijke XML complexType definitie van ClientSuwi uit het SuwiML basisschema en is deze kopie vervolgens aangepast (verbijzonderd) voor het SuwiML berichtschema waarvan dit SuwiML bodyschema deel uitmaakt. Figuur 25 en Figuur 26 tonen de verbijzondering van ClientSuwi en laten bovendien zien hoe, middels het XML extension statement, de getypeerde SGR-relaties vanuit ClientSuwi naar FeitelijkAdres en DomicilieAdres zijn opgenomen.




ClientSuwi SofiNr

Domicilieadres

abstract

FeitelijkAdres

Adres

subclass Straatadres

Straatadres Buitenland

Figuur 25: voorbeeld Entiteit-Relatie diagram voor ClientSuwi. <schema targetNamespace = "http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302" xmlns = "http://www.w3.org/2001/XMLSchema" xmlns:sml = "http://www.suwi.nl/SuwiML/Basis-v0200" xmlns:smlb = "http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302"> <element name="SuwiMLBody" type="smlb:SuwiMLBody"/> <element name="Redirect" type="smlb:Redirect"/> <sequence> <element name="Response" type="smlb:Response"/> <element name="Fault" type="smlb:Fault" minOccurs="0"/> <element name="Warning" type="smlb:Warning" minOccurs="0"/> <element name="Acknowledgement" type="smlb:Acknowledgement"/> <sequence> <element name="ExpiresAfterSeconds" type="nonNegativeInteger" minOccurs="0"/> <element name="CompoundService" type="smlb:CompoundService"/> <element name="AlternativeServiceSet" type="smlb:AlternativeServiceSet"/> <element name="Service" type="smlb:Service"/> ... ... ...




<sequence> <element name="ClientSuwi" minOccurs="0"> <extension base="smlb:ClientSuwi"> <sequence> <element name="FeitelijkAdres" type="smlb:Adres" minOccurs="0"/> <element name="Domicilieadres" type="smlb:Adres"/> <element name="Straatadres" type="sml:Straatadres"/> <element name="StraatadresBuitenland" type="sml:StraatadresBuitenland"/> <sequence> <element name="SofiNr" type="sml:SofiNr"/> <sequence> <element name="Fout" type="smlb:Fout" maxOccurs="unbounded"/> <element name="Fout" type="smlb:Fout"/> ... <sequence> <element name="Waarschuwing" type="smlb:Waarschuwing" maxOccurs="unbounded"/> ... <sequence/>

Figuur 26: SuwiML Reaction bodyschema met een verbijzondering van het XML complexType voor ClientSuwi.




4.3.

Warning binnen SuwiML body

Aanvullend op een bericht kan er behoefte zijn aan de toevoeging van extra "achtergrondinformatie", als motivatie bij de geleverde gegevens. Bij het beantwoorden van een request bericht middels een response, bestaat de mogelijkheid voor de server om naast de opgevraagde gegevens, middels een warning, deze aanvullende informatie aan het response bericht toe te voegen. Figuur 14 toont de XML choice constructie voor de SuwiML body, waarin het warning element opgenomen is. De warning mag alleen bij uitzondering worden gebruikt. Met andere woorden, het moet een aanvulling zijn, en mag alleen informatie bevatten die niet is af te leiden uit de response. Niet alle gegevens mogen worden verwerkt in een warning, dit om te voorkomen dat onterecht gegevens worden overgedragen. Als bepaalde gegevens bijvoorbeeld om redenen van privacy niet in een bericht verzonden mogen worden, dan zullen ze niet in de schema's zijn gemodelleerd. Dan is het natuurlijk niet de bedoeling om ze alsnog als warning te versturen. Voorafgaand aan de implementatie, moeten bij de toetsing van de berichtstructuur door de SuwiML beheerorganisatie (BKWI), ook de mogelijk te versturen warnings worden getoetst. Het initiatief voor het vastleggen en toetsen van de warnings ligt bij de leverancier van de gegevens. Zo kan de leverancier de set warnings op ieder moment zelf uitbreiden (mits getoetst en ok). Binnen de SuwiML berichtstandaard is er voor gekozen geen gebruik te maken van een vooraf gedefinieerde algemene lijst met mogelijke warnings. De leverende partij is verantwoordelijk voor duidelijke en zinvolle warnings, de SuwiML beheerorganisatie toetst op zinvolheid en toepasbaarheid van de door de leverancier voorgestelde warnings. De motivatie voor deze keuze is analoog aan de motivatie voor het gebruik van foutcodes zoals beschreven in sectie ‘Foutcodes: centraal vastgelegd versus vrij invulbaar’ van de SuwiML transactiestandaard. <SOAP-ENV:Envelope xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:smlh = "http://www.suwi.nl/SuwiML/Header-v0200" xmlns:smlb = "http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://schemas.xmlsoap.org/soap/envelope/ UwvDossierPersoon-v0302-b07-EnvelopeReaction.xsd"> <SOAP-ENV:Header> <smlh:SuwiMLHeader> ... ... ... <SOAP-ENV:Body> <smlb:SuwiMLBody> ... <Warning> <Waarschuwing> <WaarschuwingCode>23 <WaarschuwingTekst>Persoon is overleden.




<WaarschuwingBron> 5 3090 3090 <ApplicatieNaam>Persoonsregistratie

Figuur 27: voorbeeld SuwiML Reaction response bericht met een warning. Figuur 27 toont een voorbeeld van een warning. Stel dat er een berichtuitwisseling is, waarbij persoonsgegevens worden opgevraagd. Deze gegevens worden gebruikt voor het versturen van post, etc. DatumOverlijden is niet in elke berichtuitwisseling gemodelleerd, en het is niet ongebruikelijk dat er geen adres bekend is van een overleden persoon. Om nu in een bericht de afwezigheid van bijvoorbeeld de adresgegevens te verklaren, kan de warning ‘Persoon is overleden’ worden toegevoegd aan het bericht. Nogmaals, dit is een voorbeeld, en geen algemene regel, de SuwiML beheerorganisatie dient hierover een uitspraak te doen.

4.4.

Clusters binnen SuwiML body

Het vormgeven van een SuwiML berichtschema kan worden vereenvoudigd door gebruik te maken van clusterdefinities binnen de SuwiML body. Een clusterdefinitie beschrijft een (verbijzonderde) hiërarchie van entiteiten die in zijn geheel op identieke wijze en op meerdere plaatsen in de berichthiërarchie voorkomt. Door een cluster apart te definiëren kan hij vervolgens door middel van referentie onbeperkt gebruikt worden in de berichthiërarchie en is hij bovendien beter onderhoudbaar doordat eventuele wijzigingen slechts op één plek in de SuwiML body hoeven te worden doorgevoerd. Een clusterdefinitie wordt altijd vastgelegd met behulp van een XML complexType definitie binnen de SuwiML body. De clusterdefinitie kan vervolgens gebruikt worden binnen de SuwiML body door een XML element te definiëren welke als type een verwijzing naar de XML complexType clusterdefinitie bevat. Op deze manier leidt het gebruik van clusterdefinities in een berichtinstantie niet tot extra XML tags, alleen de volgens het SGR noodzakelijke en toegestane tags worden gebruikt voor de opbouw van een berichtinstantie. Figuur 28 geeft een voorbeeld van een SuwiML body waarin een clusterdefinitie voor ContactpersoonInformatie is opgenomen. Deze clusterdefinitie beschrijft een XML complexType met een geneste XML sequence waarbij de gegevens behorend bij een contactpersoon altijd bestaan uit de SGR/SuwiML entiteitdefinitie van Contactpersoon, uitgebreid met getypeerde relaties naar DomicilieAdres en PostAdres. Het DomicilieAdres is een straatadres in Nederland of het buitenland, het PostAdres is een postbusadres in Nederland. De Response definitie binnen de SuwiML body,




refereert aan de SGR/SuwiML entiteitdefinitie voor ClientSuwi en voegt daar met behulp van XML extension twee getypeerde relaties aan toe voor respectievelijk: ConsulentSuwi en WoordvoerderClientSuwi. Beide getypeerde relaties worden vervolgens door referentie gelijkgesteld aan de clusterdefinitie voor ContactpersoonInformatie. <schema targetNamespace xmlns xmlns:sml xmlns:smlb

= = = =

"http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302" "http://www.w3.org/2001/XMLSchema" "http://www.suwi.nl/SuwiML/Basis-v0200" "http://www.suwi.nl/SuwiML/BodyReaction/UwvDossierPersoon-v0302">

<element name="SuwiMLBody" type="smlb:SuwiMLBody"/> <element name="Redirect" type="smlb:Redirect"/> <sequence> <element name="Response" type="smlb:Response"/> <element name="Fault" type="smlb:Fault" minOccurs="0"/> <element name="Warning" type="smlb:Warning" minOccurs="0"/> <sequence> <element name="ClientSuwi"> <extension base="sml:ClientSuwi"> <sequence> <element name="ConsulentSuwi" type="smlb:ContactpersoonInformatie"/> <element name="WoordvoerderClientSuwi" type="smlb:ContactpersoonInformatie"/> <extension base="sml:Contactpersoon"> <sequence> <element name="DomicilieAdres" minOccurs="0"> <element name="Straatadres" type="sml:Straatadres"/>




<element name="StraatadresBuitenland" type="sml:StraatadresBuitenland"/> <element name="PostAdres" type="sml:Postbusadres"/>

Figuur 28: modelleren van clusters binnen SuwiML body.

4.5.

Beknopte samenvatting modellering SuwiML berichtschema

Ieder SuwiML berichtschema moet gebruik maken van de constructies die SGR/SuwiML biedt of ondersteunt. Men moet zich dus houden aan het principe dat iedere berichtspecificatie alleen binnen de kaders van het SGR kan worden opgesteld. Er kunnen geen nieuwe gegevenselementen, entiteiten of relaties worden bijgemaakt, noch bestaande worden uitgebreid. Kortom: de speelruimte wordt volledig bepaald door het SGR. Verder gelden puntsgewijs de volgende vuistregels: •

De SuwiML body voor een specifiek bericht bestaat uit een Request (Action) of een keuze (XML choice) tussen een Redirect of Response (Reaction), waarbij een Response eventueel vergezeld kan gaan door een Fault en/of Warning.

•

Ieder SuwiML berichtschema gebruikt het SGR / het SuwiML basisschema als uitgangspunt. Iedere relatie, entiteit of attribuut uit het SGR / het SuwiML basisschema wordt in een SuwiML berichtschema 1-op-1 overgenomen door middel van een directe referentie naar het SuwiML basisschema, of wordt verbijzonderd voor het betreffende berichttype (het SuwiML berichtschema).

•

In geval een entiteit uit het SGR / het SuwiML basisschema in een SuwiML berichtschema wordt verbijzonderd, gebeurt dit door de XML complexType definitie uit het SuwiML basisschema te kopiëren naar het SuwiML bodyschema, en binnen dit bodyschema aan te passen volgens de berichtspecifieke eisen.

•

Relaties uit het SGR / het SuwiML basisschema worden middels XML extension aan (verbijzonderde) entiteitdefinities toegevoegd.

•

Binnen de SuwiML body kunnen clusterdefinities worden opgenomen waarnaar elders in de berichthiërarchie (herhaald) kan worden verwezen.

De XML Schema aanbeveling is erg complex. Niet alle constructies zijn nodig om een werkbaar XML Schema op te stellen. In de SuwiML berichtschema's zijn de volgende regels toegepast: •

SuwiML drukt SGR gegevenselementen uit met behulp van XML element, niet met behulp van XML attribute. Het SGR is dus omgezet naar een pure XML element verzameling.




•

SuwiML definieert XML complexTypes en XML simpleTypes op topniveau. XML complexTypes leggen met name SGR entiteitdefinities vast, en worden gevuld met XML element definities voor de SGR gegevenselementen van de betreffende SGR entiteit. XML simpleTypes leggen de SGR domeindefinities vast waaraan wordt gerefereerd door de SGR gegevenselementen.

•

SuwiML definieert een apart type voor iedere SGR domeindefinitie (bijvoorbeeld het type sml:SofiNr voor de SGR domeindefinitie gerelateerd aan het SGR gegevenselement SofiNr van SGR entiteit ClientSuwi). De typenaam is gelijk aan de naam van de SGR domeindefinitie.

•

Ongetypeerde relaties tussen SGR entiteiten A en B worden gedefinieerd als een XML element B onder A. Het XML element heeft dus dezelfde naam als de SGR entiteit, i.e. de XML complexType, waarnaar de relatie verwijst.

•

Getypeerde relaties R tussen SGR entiteiten A en B worden gedefinieerd als een XML element R onder A, waarbij R van het XML complexType B is.




5. SuwiML berichtontwikkelingsmethodiek 5.1.

Inleiding

Standaardisatie- en berichtontwikkelingsmethoden richten zich op de scheiding tussen functioneleen technische vraagstukken. Daarbij is niet slechts de gegevensuitwisseling, maar de integratie van applicaties de feitelijke uitdaging. Een methodiek (combinatie van methoden) die het gehele applicatie-integratie traject ondersteunt, leidt tot een consequente werkwijze/benadering van de functioneleen technische vraagstukken en een consistente oplossing daarvan. Een definitie van het standaardisatie- en berichtontwikkelingsproces is afgeleid van nationale en internationale richtlijnen en aanbevelingen, en valt uiteen in vier logische fasen: analyse, ontwerp/ontwikkeling, implementatie en toepassing. De binnen SGR/SuwiML gehanteerde methodiek volgt deze definitie van het standaardisatie- en berichtontwikkelingsproces. analyse

ontwerp/ ontwikkeling

implementatie

toepassing

feedback Figuur 29: berichtontwikkelingsproces.

5.2.

Internationale ontwikkelingen mbt standaardisatie en berichtontwikkeling

UN/CEFACT Modelling Methodology De United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Modelling Methodology (UMM) beschrijft een methode voor de modellering van bedrijfsprocessen en geeft ondersteuning bij de ontwikkeling van bestaande en nieuwe vormen van elektronische gegevensuitwisseling (Electronic Data Interchange – EDI) tussen organisaties en/of applicaties. De UMM bedrijfsproces- en informatiemodelleringstechniek is gebaseerd op de Unified Modelling Language (UML) afkomstig van de Open Management Group (OMG). De UMM methode is deels afgeleid van de Rational Unified Process methodology (RUP) afkomstig van IBM Rational Rose. De UMM methode richt zich op de specificatie van afzonderlijke bedrijfsprocessen en informatieobjecten, alsmede de interactie scenario’s die tussen de verschillende bedrijfsprocessen plaatsvinden. Belangrijk aspect van deze specificaties is het feit dat ze functioneel van aard zijn, en los staan / onafhankelijk zijn van de onderliggende technische implementatie. Het doel is te komen tot modulaire en herbruikbare functionele specificaties, welke consistent zijn qua opbouw en inhoud. De UMM methode is dus feitelijk een formele techniek om open-EDI scenario’s te beschrijven, zoals in ISO/IEC IS 14662 wordt onderkend als een formele specificatie van een verzameling bedrijfstransacties met een gemeenschappelijk doel.




De RUP methode stelt dat softwareontwikkelingsprojecten een aantal fasen doorlopen, te weten: initiatie, uitwerking, constructie en transitie. Elk van deze fasen heeft een specifieke rol binnen het UN/CEFACT ontwikkelingsproces voor standaarden. Binnen het ebXML initiatief helpt UN/CEFACT bij de vastlegging van een standaard ontwikkelingsproces voor de levensloop (lifecycle) van elektronische berichten.

W3C Het World Wide Web Consortium (W3C) ontwikkelt interoperabele technologieën (specificaties, richtlijnen, software en tools) met als doel het potentieel van het World Wide Web ten volle te benutten. Het W3C is een forum voor informatie, handel, communicatie en gezamenlijke kennisdeling en -ontwikkeling. Het W3C richt zich onder meer op de ontwikkeling van XML gerelateerde standaarden zoals XML Schema, XPointer, DOM, XSL, XSLT, etc. Mijlpalen daarbij zijn de vaststelling van XML 1.0 (10 februari 1998) en XML Schema 1.0 (2 mei 2001).

ISO 17113 ISO 17113 “Development of messages.” stelt dat alle organisaties die zich bezig houden met de ontwikkeling van standaarden voor gegevensuitwisseling, deze gegevensuitwisseling moeten baseren op een Reference Information Model (RIM). De RIM vormt het fundament voor alle specificaties van gegevensuitwisselingen binnen de specifieke bedrijfscontext/keten/branche waarvoor de RIM is vastgesteld. Vanuit de RIM wordt een Refined Message Information Model (RMIM) afgeleid, als subset van de RIM, welke de specificatie van (gerelateerde) Hierarchical Message Definitions (HMDs) ondersteunt. Een HMD is een hiërarchische specificatie van een set berichttypen gebaseerd op informatieobjecten die zijn vastgelegd in de bijbehorende R-MIM. Een specifiek berichttype is altijd gerelateerd aan precies één HMD. Volgens ISO 17113 worden alle specificaties vastgelegd in UML. veralgemeniseren

Reference Information Model (RIM)

Suwi Gegevensregister SuwiML basisschema

subset Refined Message Information Model (R-MIM)

afleiden

Transactie hiërarchie

hierarchical subset

Hierarchic Message Definition (HMD) afleiden

Bericht hiërarchie

subset

Message types

verbijzonderen

Figuur 30: ISO 17113 development of messages.




ISO 11179 ISO/IEC 11179 beschrijft de voor gegevensmodellering noodzakelijke metadata naar soort en kwaliteit, en definieert de vastlegging en het beheer van deze metadata in een metadata register (MDR). Het is van toepassing op de specificaties van gegevensrepresentaties, -concepten, betekenissen en -relaties welke gedeeld worden tussen mensen en machines, onafhankelijk van de organisatie welke de gegevens feitelijk produceert. Het is niet van toepassing op de fysieke representatie van gegevens in termen van bits en bytes.

ebXml Electronic Business using eXtensible Markup Language (ebXML) stelt zichzelf tot doel om organisaties, ongeacht omvang of geografische locatie, vrijelijk met elkaar zaken te laten doen met behulp van het World Wide Web, het Internet. ebXML is een modulaire verzameling van specificaties die organisaties in staat stelt om middels een standaard methode elektronische XML berichten uit te wisselen, (handels)relaties te onderhouden, gegevensdefinities onderling af te stemmen en bedrijfsprocessen te definiëren en te registreren. ebXML is een gezamenlijk initiatief van UN/CEFACT en OASIS. ebXML stelt dat voor het modelleren van bedrijfsprocessen en informatieobjecten gebruik gemaakt moet worden van UMM en UML. Hoewel de bedrijfsactiviteiten per organisatie sterk zullen verschillen, kunnen de meeste activiteiten ontleed worden in meer generieke bedrijfsprocessen voor de betreffende branche/keten. De modulaire opbouw die op deze wijze tot stand komt, en de generieke bedrijfsprocessen en informatieobjecten die daarmee onderkend worden, komen in aanmerking voor standaardisatie binnen de betreffende branche/keten. ebXML zoekt naar dit soort standaard herbruikbare componenten voor welke interoperabele (componenten van) applicaties gemaakt kunnen worden. In UMM worden twee specificatieniveaus onderscheiden: de ‘Business Operational View’ (BOV) en de ‘Functional Service View’ (FSV). Zie ook de Open-EDI Reference Model Standard – ISO/IEC 14662. Deze specificatieniveaus worden ook in ebXML onderkend, met de volgende betekenis: •

De BOV beschrijft de semantiek van bedrijfsgegevens in bedrijfstransacties en aanverwante gegevensuitwisselingen. Het adresseert de architectuur van bedrijfstransacties inclusief de operationele conventies, afspraken en verplichtingen. De BOV geeft een compleet beeld van alle bedrijfstransacties met betrekking tot het vastleggen van de beslissingen en afspraken omtrent deze bedrijfstransacties.

•

De FSV beschrijft de inrichting van diensten rondom en ter ondersteuning van de bedrijfstransacties. Het concentreert zich daarbij op de Informatie Technologie (IT) aspecten van open-EDI transacties, in het bijzonder: de vereiste functionaliteit van de diensten; de interfacing tussen de diensten; protocol- en berichtuitwisselingsdiensten.

Aanbevelingen met betrekking tot het berichtontwikkelingsproces Op basis van de internationale standaarden zoals hierboven beschreven, worden de volgende aanbevelingen overgenomen:




3.

De UN/CEFACT Modelling Methodology wordt toegepast voor de modellering van bedrijfsprocessen en geeft ondersteuning bij de ontwikkeling van bestaande en nieuwe vormen van elektronische gegevensuitwisseling.

4.

De modellering van bedrijfsprocessen, bedrijfstransacties, alsmede de aanverwante gegevensuitwisselingen, wordt gespecificeerd met behulp van de Unified Modelling Language. Dit is conform de formele specificatie techniek voor open-EDI scenario’s zoals vastgelegd in ISO/IEC 14662.

5.

Een Reference Information Model – Suwi Gegevensregister – zal de basis vormen voor alle te specificeren gegevensuitwisselingen. Standaardisatie van terminologie, definities, codelijsten, etc. kan op deze wijze worden gerealiseerd en afgedwongen.

6.

Een subset van het Reference Information Model, genoemd het Refined Message Information Model, ligt ten grondslag aan de specificatie van één of meer Hierarchical Message Definitions. Elke afzonderlijke Hierarchical Message Definition ondersteunt de specificatie van één of meer berichttypen. Specificaties worden opgesteld in de Unified Modelling Language.

7.

Analyse en ontwerp/ontwikkeling vinden zuiver en alleen plaats vanuit een functioneel perspectief. Ten behoeve van implementatie en toepassing wordt gekozen voor een bepaald uitwisselingsformaat; XML (SuwiML) in de Suwi keten.

5.3.

Het berichtontwikkelingsproces

Het berichtontwikkelingsproces start met de analyse van alle (mogelijke) proces- en informatiestromen die tussen verschillende organisaties kunnen plaatsvinden. Vervolgens wordt bepaald welke van deze stromen in aanmerking komen voor (elektronische) berichtuitwisseling, i.e. de berichttypen worden bepaald. Nu volgt het ontwerp / de ontwikkeling van de functionele en technische specificaties van de onderkende berichttypen, gevolgd door de implementatie en feitelijke toepassing/ingebruikname. Figuur 29 en Figuur 31 geven een schematisch beeld van het berichtontwikkelingsproces.




Analyse 1. Analyseer proces- en informatiestromen a. b. c. d. e. f.

Identificeer proces en processtappen Identificeer informatiestromen binnen proces en tussen processtappen Identificeer doel van informatiestromen Identificeer globale inhoud van informatiestromen Identificeer rollen en communicatiepartners Relateer rollen aan proces en processtappen

2. Optimaliseer informatieuitwisseling tussen communicatiepartners a. b. c.

Probleem analyse Identificeer bestaande oplossingen Definieer medium per informatiestroom

3. Identificeer nieuwe informatiestromen a. b.

Bepaal prioriteit per (nieuwe) informatiestroom Plan de realisatie van ( nieuwe) informatiestromen

4. Creëer analyserapport a. b.

Analyserapport vormt de input voor het ontwikkelingsproces Ontwikkelingsproces kan door een ander team worden uitgevoerd op basis van het analyserapport

Ontwerp / ontwikkeling 5. Definieer het communicatieproces a. b.

Specificeer informatieuitwisseling tussen communicatiepartners berichtscenario’s, volgorde en afhankelijkheid berichttypen Specificeer communicatiepartners

6. Definieer de functionele inhoud van berichten a. b. c. d.

Specificeer entiteiten en attributen Identificeer bestaande (delen van) berichten binnen registers Specificeer de berichthiërarchie Specificeer de berichtspecifieke functionele validatie regels

7. Creëer overzicht van functionele berichtspecificaties a.

Specificeer functionele berichtspecificaties

8. Kies uitwisselingssyntax per berichttype a.

Kies een uitwisselingssyntax choice

9a. Creëer technische XML specificatie

9b. Creëer technische Edifact specificatie

9c. Creëer technische ‘flat-file’ specificatie

a. b.

a. b.

a. b.

Definieer XML tags en XML Schema Valideer XML tags en XML Schema

Definieer mapping naar Edifact UNSM Valideer Edifact mapping

Definieer ‘flat - file’ specificatie Valideer ‘flat-file’ structuur

Implementatie 10. Creëer adapter voor informatiesysteem a. b. c.

Verwerk inkomende berichten Genereer uitgaande berichten Implementeer triggers om verwerking en aanmaken van berichten te initiëren

11. Configureer vertaler a. b.

Converteer intern bestandsformaat naar uitwisselingsformaat (afhankelijk van berichttype en communicatiepartner) Converteer uitwisselingsformaat naar intern bestandsformaat

12. Creëer verbinding met netwerk infrastructuur a.

Definieer en configureer de communicatieprotocollen

13. Test berichtuitwisseling a. b. c. d.

Test ontvangst en inlezen/valideren inkomende berichten Test samenstellen en versturen uitgaande berichten Test triggers voor verwerking en aanmaken van berichten Creëer testrapport

14. Setup beheersomgeving a. b. c.

Monitor status van berichten Monitor status van communicatiesessies Setup (automatische) error- handling in het geval zich een probleem voordoet

15. Certificering van de implemenatie door Trusted Third Party a.

Afsprakendocument inclusief detailspecificaties als contract vastleggen (SLA, SNO)

Toepassing parallel

16. Zenden en ontvangen van berichten

17. Vertalen en valideren van berichten

18. Operationeel beheer

a. b.

a.

a. b.

Routeren Adresseren

b.

Vertaal van/naar Edifact, XML en intern bestandsformaat Valideer conform Message Implementation Guidelines (MIG)

Uitrol van implementatie Monitor de operationele gang van zaken





Analyse, ontwerp, ontwikkeling Doel van de analyse fase is het vaststellen van de aanleiding, de primaire doelstellingen en de randvoorwaarden van de proces- en informatiestromen, alsmede het inventariseren van de te verwachten vraagstukken bij het ontwerp / de ontwikkeling van de proces- en informatiestromen. De resultaten uit de analyse fase vormen de grondslag voor de ontwerp/ontwikkeling fase. Doel van de ontwerp/ontwikkeling fase is om bericht implementatie richtlijnen op te stellen waarin het proces, de functionele inhoud, de syntax en de mapping van functionele inhoud op syntax en uitwisselingsformaat wordt gespecificeerd. Bericht implementatie richtlijnen worden opgesteld per berichttype, waarbij gerelateerde berichttypen liefst gelijktijdig ontworpen/ontwikkeld worden. De combinatie van functionele berichtspecificatie en technische berichtspecificatie samen vormt de bericht implementatie richtlijn voor een bepaald berichttype. Figuur 31 toont de analyse-, ontwerp/ontwikkeling-, implementatie- en toepassingsfase op hoofdlijnen. De analyse fase en de ontwerp/ontwikkeling fase worden beide uitgevoerd met gebruik van UML, zoals binnen de eerder genoemde internationale standaarden ook wordt aangeraden.

Implementatie en toepassing Doel van de implementatie fase is de feitelijke realisatie van de bericht implementatie richtlijnen, welke voortkomen uit de ontwerp/ontwikkeling fase. Dit betekent dat de bedrijfsapplicaties worden uitgebreid met een adapter waarin functionaliteit wordt opgenomen voor het verzenden en ontvangen van elektronische berichten. De bedrijfsapplicatie en de adapter werken hierbij nauw samen om de aangeleverde functionele (bericht)inhoud te converteren naar het vastgestelde uitwisselingsformaat (SGR, XML, SOAP, SuwiML). Uitgaande berichten worden verzonden via het Suwinet, inkomende berichten worden ontvangen via het Suwinet. De implementatie fase behelst daarom ook het realiseren van de connectiviteit van alle betrokken communicatie-actoren (Suwi partijen) met dit netwerk. De adapter, de conversie en de connectiviteit dienen uitgebreid getest te worden en indien mogelijk gecertificeerd te worden door een onafhankelijke derde partij (trusted third party). Doel van de toepassingsfase is het operationeel gebruik van de geïmplementeerde en geconfigureerde operationele componenten, zodanig dat uitgaande berichten conform de specificaties worden gegenereerd en inkomende berichten conform de specificaties worden gevalideerd en verwerkt. Een en ander vindt plaats in een volledig geautomatiseerde en geïntegreerde omgeving waarbinnen geen verdere (handmatige) acties noodzakelijk zijn. Het operationeel beheer in de toepassingsfase bestaat uit het uitrollen en configureren van de operationele componenten, versie beheer, het monitoren van berichtuitwisselingen en de berichtuitwisselingsomgeving in het algemeen, het inrichten en uitvoeren van de exceptie- en foutafhandelingsprocedures, communicatie-actor/account beheer (logins, passwords, etc.) en registreren van statistische gegevens.




5.4.

Methodische ondersteuning van het berichtontwikkelingsproces

Procesmodel Om de dynamiek van de omgeving goed te kunnen doorgronden is inzicht in het bedrijfsproces gewenst. Een bedrijfsprocesmodel welke de interactie en de gegevensuitwisseling tussen interne en externe systemen en/of communicatie-actoren in beeld brengt, moet hiertoe dienen. Met het gewenste inzicht in het bedrijfsproces, kan vervolgens de discussie worden gevoerd over mogelijke verbeteringen en/of optimalisaties in het bedrijfsproces. Uiteindelijk resulteert dit in een inzicht in het bestaande én gewenste bedrijfsproces. De onderkende interacties en gegevensuitwisselingen in het bedrijfsproces kunnen met behulp van verschillende media gerealiseerd worden, bijvoorbeeld telefoon, fax, brief, voice-response, webservice, elektronisch bericht. Afhankelijk van de noodzaak van een interactie of gegevensuitwisseling en de kosten en nadelen/voordelen verbonden aan een bepaald medium, wordt vastgesteld welke interactie of gegevensuitwisseling wanneer en middels welk medium gerealiseerd wordt. Modellering van het bedrijfsproces en de daarmee verband houdende interacties en gegevensuitwisselingen vindt met name plaats in de analyse- en ontwerp/ontwikkeling fase. Vaak worden voor de reeds bekende interacties en gegevensuitwisselingen elektronische berichtuitwisselingen gespecificeerd en gerealiseerd om op die manier het bestaande bedrijfsproces efficiënter te laten verlopen. Beter is het echter om eerst te streven naar een verbetering en/of optimalisatie van het bestaande bedrijfsproces, alvorens de dan onderkende interacties en gegevensuitwisselingen middels elektronische berichtuitwisseling te automatiseren. Met andere woorden: eerst streven naar een verbetering van de effectiviteit alvorens te streven naar een verbetering van de efficiëntie.

State-transition-diagram Een state-transition-diagram (STD) beschrijft de wijze waarop de interacties of gegevensuitwisselingen tussen twee systemen en/of communicatie-actoren, de toestand waarin het gehele bedrijfsproces zich bevindt, veranderen. Een compleet state-transition-diagram beschrijft alle mogelijke toestanden waarin het bedrijfsproces zich kan bevinden inclusief de wijze waarop iedere toestand bereikt kan worden. Compleet in deze, betekent dat alle mogelijke toestanden worden beschreven en iedere beschreven toestand ook daadwerkelijk bereikbaar is. Een state-transitiondiagram heeft altijd één starttoestand en één eindtoestand. Een state-transition-diagram beschrijft dus in feite de dynamiek van het bedrijfsproces en de wijze waarop het bedrijfsproces op bepaalde situaties reageert.

Time-sequence-diagram Een time-sequence-diagram (TSD) beschrijft bepaalde scenario’s (use cases) die zich binnen het bedrijfsproces kunnen voordoen. Een time-sequence-diagram beschrijft een specifieke chronologische aaneenschakeling van processtappen welke, aangevangen vanuit de starttoestand, uiteindelijk leiden tot de eindtoestand in het state-transition-diagram. Meerdere verschillende time-




sequence-diagrammen kunnen leiden tot de eindtoestand in het state-transition-diagram. Iedere toestand in het state-transition-diagram is bereikbaar via minimaal één time-sequence-diagram.

Informatiemodel en berichthiërarchie Voor iedere interactie of gegevensuitwisseling binnen het bedrijfsproces moet bepaald worden welke functionele inhoud daarbij een rol speelt. Met andere woorden: welke gegevens worden uitgewisseld en wat is daar de betekenis van? Om de uitgewisselde gegevens op consistente en complete wijze te kunnen definiëren wordt gebruik gemaakt van een gemeenschappelijk gegevensregister/informatiemodel waarin alle gegevens uit alle interacties of gegevensuitwisselingen worden gemodelleerd. Op basis van het gegevensregister/informatiemodel wordt vervolgens voor elk afzonderlijk berichttype de berichthiërarchie opgebouwd. Berichttypen die qua betekenis en toepassing sterk met elkaar verbonden zijn, kunnen in de praktijk het beste gebruik maken van één gemeenschappelijke transactiehiërarchie waaruit de afzonderlijke specifieke berichthiërarchieën worden afgeleid. Nadat de functionele berichtspecificaties op deze wijze zijn vastgesteld, moet worden bepaald op welke technische wijze de berichttypen uitgewisseld moeten worden, i.e. volgens welke uitwisselingssyntax. Binnen de Suwi keten wordt hiervoor gebruik gemaakt van XML (SuwiML).

5.5.

Specificatie van elektronische ketenberichten

Gegevensmodel Een gegevensmodel, zoals het Suwi Gegevensregister, kan worden beschouwd als een verzameling standaard bouwstenen. Iedere bouwsteen representeert de exacte definitie (formaat, waardebereik, betekenis, etc.) van een functioneel informatie-object dat wordt onderkend binnen het bedrijfsproces en op enig moment voor interactie of gegevensuitwisseling wordt gebruikt. Iedere bouwsteen (informatie-object) wordt precies één keer vastgelegd in het gegevensmodel. Het gegevensmodel bevat ook de verzameling van algemeen geldende relaties tussen deze informatie-objecten.

Berichtmodel Een berichtmodel beschrijft een hiërarchie. Een berichtmodel maakt gebruik van de informatieobjecten uit een gegevensmodel en voegt hieraan specifieke (contextuele) informatie toe. De informatie-objecten uit het gegevensmodel kunnen herhaald en op verschillende plaatsen in het berichtmodel worden gebruikt. De definitie van de informatie-objecten kan binnen de context van het berichtmodel worden aangescherpt en kan bovendien per voorkomen binnen het berichtmodel verschillen. Relaties uit het gegevensmodel kunnen binnen de context van het berichtmodel eveneens worden aangescherpt. Dit kan leiden tot ‘nieuwe’ relaties welke alleen binnen de context van het berichtmodel geldig en van toepassing zijn. Figuur 32 geeft een schematisch voorbeeld van een gegevensmodel welke als basis fungeert voor een aantal verschillende berichtmodellen. Het afleiden van de berichtmodellen uit een gegevensmodel komt overeen met de methode zoals verbeeld in Figuur 18 en Figuur 30.




A

B

C

D

Figuur 32: schematisch voorbeeld van een gegevensmodel. Figuur 33, Figuur 34, Figuur 35, Figuur 36 en Figuur 37zijn allemaal afgeleid van één en hetzelfde gegevensmodel. Op deze wijze is dus gegarandeerd dat al deze berichtmodellen consequent en consistent gebruik maken van de informatie-object definities zoals die zijn vastgelegd in het gegevensmodel.

A B

D

C Figuur 33: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32.

C A D

B


A

B

D

C


A B

D

C

C Figuur 36: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32. NB. in het berichtmodel in Figuur 36 komt informatie-object C tweemaal voor, waarbij de definities van C mogelijk aangescherpt zijn ten opzichte van het gegevensmodel en ten opzichte van elkaar kunnen verschillen.




A C D Figuur 37: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32. NB. in het berichtmodel in Figuur 37 komt informatie-object D direct onder informatie-object A voor, hetgeen een aanscherping is van de relaties in het gegevensmodel.

Specificatie van een elektronisch ketenbericht Onderdeel van een volledige en eenduidige beschrijving van een elektronisch ketenbericht zijn de volgende componenten: 1.

functionele berichtspecificatie;

2.

technische berichtspecificatie (SuwiML berichtschemaset);

3.

functioneel applicatieontwerp;

4.

transactiestandaard implementatiedocument.

Functionele berichtspecificatie De functionele specificatie van een berichttype kent twee onderdelen: 1.

hiërarchisch entiteiten-relaties overzicht (het berichtmodel / de berichthiërarchie);

2.

hiërarchisch entiteiten-attributen overzicht.

1. Hiërarchisch entiteiten-relaties overzicht (het berichtmodel / de berichthiërarchie). Het hiërarchisch entiteiten-relaties overzicht wordt vastgesteld per berichttype en geeft een opsomming van alle entiteit-instanties die binnen het betreffende berichttype voorkomen inclusief de relaties waarin de entiteit-instanties zich tot elkaar verhouden. Per relatie is bovendien aangegeven welke cardinaliteit (herhaalbaarheid) deze heeft en welke status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R), choice/keuze (X)) deze bezit. In geval de status van de relatie ‘afhankelijk’ is, moet er in ieder geval een ‘business rule’ worden gespecificeerd die beschrijft op welke wijze de betreffende relatie afhankelijk is. NB. bij het vaststellen van de berichthiërarchie voor een bepaald berichttype, is het van belang om niet alleen sec naar dit berichttype te kijken, maar vooral ook naar andere gelijkgeaarde berichttypen. Door de berichthiërarchieën van verschillende gelijkgeaarde berichttypen zoveel als mogelijk op elkaar af te stemmen (gelijkwaardig te maken) kan een aanzienlijk synergie voordeel optreden voor het beheer en de implementatie van deze elektronische ketenberichten. In onderstaand voorbeeld moet de entiteit-instantie ‘ClientSuwi’ verplicht 1x voorkomen. Voor deze ‘ClientSuwi’ moet bovendien een ‘DomicilieAdres’ opgegeven worden, hetgeen een keuze betekent tussen een ‘Straatadres’ en een ‘StraatadresBuitenland’. Voor deze ‘ClientSuwi’ kunnen daarnaast tot maximaal 99 ‘Arbeidsverhoudingen’ onderscheiden worden, echter een ‘Arbeidsverhouding’ is niet verplicht. Verder in de hiërarchie blijkt dat voor een ‘Partner’ en een ‘Onderhoudsplichtige’ ook




een ‘DomicilieAdres’ (inclusief keuze tussen ‘Straatadres’ en ‘StraatadresBuitenland’) kan worden opgegeven, echter in deze gevallen is het ‘DomicilieAdres’ niet verplicht. NB. het gaat hier feitelijk om verschillende instanties van de entiteit ‘DomicilieAdres’, hetgeen tot uitdrukking kan komen in de status van de attributen die per entiteit-instantie van ‘DomicilieAdres’ kan worden gespecificeerd (dit wordt verder uitgelegd in het hiërarchisch entiteiten-attributen overzicht). Tot slot blijkt dat ook voor een ‘Kind’ een ‘DomicilieAdres’ (inclusief keuze tussen ‘Straatadres’ en ‘StraatadresBuitenland’) kan worden opgegeven, echter deze entiteit-instantie van ‘DomicilieAdres’ is afhankelijk van een ‘business rule’ (br) die luidt: “Voor kinderen jonger dan 18 jaar moet het DomicilieAdres verplicht ingevuld worden, in alle andere gevallen is het DomicilieAdres niet noodzakelijk en kan het achterwege blijven.” ClientSuwi DomicilieAdres Straatadres StraatadresBuitenland Arbeidsverhouding Uitkeringsverhouding Huwelijk Partner DomicilieAdres Straatadres StraatadresBuitenland Onderhoudsplicht Onderhoudsplichtige DomicilieAdres Straatadres StraatadresBuitenland Kind DomicilieAdres Straatadres StraatadresBuitenland

1x 1x 1x 1x 99x 99x 9x 1x 1x 1x 1x 1x 1x 1x 1x 1x 99x 1x 1x 1x

R R X X O O O R O X X O R O X X O br01 D X X

br01: Voor kinderen jonger dan 18 jaar moet het DomicilieAdres verplicht ingevuld worden, in alle andere gevallen is het DomicilieAdres niet noodzakelijk en kan het achterwege blijven. 2. Hiërarchisch entiteiten-attributen overzicht. Per berichttype wordt naast een berichthiërarchisch entiteiten-relaties overzicht ook een hiërarchisch entiteiten-attributen overzicht vastgelegd. In het hiërarchisch entiteiten-attributen overzicht wordt per entiteit-instantie uit het hiërarchisch entiteiten-relaties overzicht de status van de attributen gespecificeerd die in de betreffende entiteit-instantie voorkomen. Dit betekent dat een entiteit, die in zijn geheel éénmaal wordt gespecificeerd in het Suwi Gegevensregister (SGR), per entiteit-instantie in het hiërarchisch entiteiten-relaties overzicht apart wordt gespecificeerd zodanig dat alleen de voor die entiteit-instantie beschikbare attributen worden vastgelegd met een status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R)) en een (eventueel aangepast) waardebereik.




Attributen kennen geen cardinaliteit, elk attribuut mag maximaal één keer voorkomen binnen een entiteit-instantie. NB. iedere afhankelijkheid moet aanvullend beschreven worden met een ‘business rule’. In onderstaand voorbeeld worden alle entiteit-instanties uit het hiërarchisch entiteiten-relaties overzicht opgesomd en wordt per attribuut behorend bij een entiteit-instantie de status en het waardebereik beschreven: •

‘ClientSuwi’ wordt in dit berichttype geïdentificeerd met behulp van een verplicht ‘Sofinummer’ en een optionele ‘Voornaam’ en ‘Achternaam’. Alle andere attributen van ‘ClientSuwi’ die in het SGR zijn gespecificeerd, zijn voor dit berichttype niet relevant en worden achterwege gelaten.

•

‘DomicilieAdres’ van ‘ClientSuwi’ moet, in het geval het een ‘Straatadres’ betreft, verplicht een ‘Straatnaam’, ‘Huisnummer’, ‘Postcode’ en ‘Woonplaats’ bevatten. ‘GemeenteCode’ is optioneel en bovendien, ten opzichte van alle mogelijke gemeentecodes vastgelegd in het SGR, voor dit berichttype beperkt tot de codes ‘AA’, ‘AB’ en ‘AC’.

•

‘DomicilieAdres’ van ‘ClientSuwi’ moet, in het geval het een ‘StraatadresBuitenland’ betreft, verplicht een ‘StraatnaamBuitenland’, ‘HuisnrBuitenland’, ‘WoonplaatsnaamBuitenland’ en ‘LandencdIso’ bevatten. ‘LandencdIso’ is bovendien, ten opzichte van alle mogelijke landencodes vastgelegd in het SGR, voor dit berichttype beperkt tot de codes ‘BE’, ‘VS’ en ‘FR’. ‘PostcdBuitenland’, ‘LocatieomsBuitenland’, ‘RegionaamBuitenland’ en ‘Landsnaam’ zijn optioneel.

•

‘DomicilieAdres’ van ‘Partner’ moet, in het geval het een ‘Straatadres’ betreft, verplicht een ‘Postcode’ bevatten.

•

‘DomicilieAdres’ van ‘Partner’ moet, in het geval het een ‘StraatadresBuitenland’ betreft, verplicht een ‘PostcdBuitenland’ bevatten.

•

‘DomicilieAdres’ van ‘Onderhoudsplichtige’ moet, in het geval het een ‘Straatadres’ betreft, verplicht een ‘Woonplaats’ bevatten.

•

‘DomicilieAdres’ van ‘Onderhoudsplichtige’ moet, in het geval het een ‘StraatadresBuitenland’ betreft, verplicht een ‘WoonplaatsnaamBuitenland’ bevatten.

•

‘DomicilieAdres’ van ‘Kind’ moet, in het geval het een ‘Straatadres’ betreft, een ‘Postcode’ bevatten en kan, afhankelijk van een ‘business rule’, een ‘WoningType’ bevatten. Deze ‘business rule’ luidt: “Voor kinderen ouder dan 4 jaar en jonger dan 18 jaar moet het WoningType verplicht ingevuld worden, in alle andere gevallen is het WoningType niet noodzakelijk en kan het achterwege blijven.”

•

‘DomicilieAdres’ van ‘Kind’ moet, in het geval het een ‘StraatadresBuitenland’ betreft, verplicht een ‘PostcdBuitenland’ bevatten.

•

In het voorbeeld wordt de meest rechter kolom met datatype-formaatdefinities (bijvoorbeeld an..140 of n8) direct afgeleid uit het SGR, deze is niet aanpasbaar op berichttype niveau. De datatype-formaatdefinities zijn alleen ter informatie en verduidelijking opgenomen.




ClientSuwi Sofinummer Voornaam Achternaam ClientSuwi – DomicilieAdres - Straatadres Straatnaam Huisnummer Postcode Woonplaats GemeenteCode ‘AA’ Aalsmeer ‘AB’ Abcoude ‘AC’ Achterberg ClientSuwi – DomicilieAdres - StraatadresBuitenland StraatnaamBuitenland HuisnrBuitenland PostcdBuitenland WoonplaatsnaamBuitenland LocatieomsBuitenland RegionaamBuitenland LandencdIso ‘BE’ België ‘VS’ Verenigde Staten ‘FR’ Frankrijk Landsnaam ClientSuwi - Arbeidsverhouding DatBArbeidsverhouding DatEArbeidsverhouding OmsRedenEindeArbeidsverhouding

R O O

an11 an..140 an..140

R R R R O

an..140 an..35 an6 an..70 a2

R R O R O O R

an..140 an..35 an..9 an..70 an..70 an..70 a2

O

an..70

R O D

n8 n8 an..280

br02

br02: OmsRedenEindeArbeidsverhouding moet verplicht gevuld worden als DatEArbeidsverhouding gevuld is, in alle andere gevallen mag OmsRedenEindeArbeidsverhouding niet gevuld worden. ClientSuwi - Uitkeringsverhouding DatBUitkeringsverhouding DatEUitkeringsverhouding OmsRedenEindeUitkeringsverh

R O D

n8 n8 an..280

br03

br03: OmsRedenEindeUitkeringsverh moet verplicht gevuld worden als DatEUitkeringsverhouding gevuld is, in alle andere gevallen mag OmsRedenEindeUitkeringsverh niet gevuld worden.




ClientSuwi - Huwelijk Huwelijksdatum HuwelijksGemeenteCode ‘AA’ Aalsmeer ‘CA’ Catzand ‘DO’ Domburg ‘TN’ Terneuzen

R O

n8 a2

ClientSuwi - Huwelijk - Partner Sofinummer Geboortedatum

R R

an11 n8

ClientSuwi - Huwelijk - Partner – DomicilieAdres - Straatadres Postcode

R

an6

ClientSuwi - Huwelijk - Partner – DomicilieAdres - StraatadresBuitenland PostcdBuitenland R ClientSuwi - Huwelijk - Onderhoudsplicht OnderhoudsplichtCode 1 Financieel 2 Onderdak 3 Voeding 4 Scholing ClientSuwi - Huwelijk - Onderhoudsplicht - Onderhoudsplichtige Sofinummer Geboortedatum

an..9

R

n1

R O

an11 n8

ClientSuwi - Huwelijk - Onderhoudsplicht - Onderhoudsplichtige – DomicilieAdres - Straatadres Woonplaats R an..70 ClientSuwi - Huwelijk - Onderhoudsplicht - Onderhoudsplichtige – DomicilieAdres - StraatadresBuitenland WoonplaatsnaamBuitenland R an..70 ClientSuwi - Kind Sofinummer Geboortedatum


R R

an11 n8



ClientSuwi - Kind – DomicilieAdres - Straatadres Postcode WoningType ‘WB’ Woonboot ‘WW’ Woonwagen ‘ET’ Etage ’RH‘ Rijtjeshuis ’VH‘ Vrijstaand huis

R D

an6 a2

br04

br04: Voor kinderen ouder dan 4 jaar en jonger dan 18 jaar moet het WoningType verplicht ingevuld worden, in alle andere gevallen is het WoningType niet noodzakelijk en kan het achterwege blijven. ClientSuwi - Kind – DomicilieAdres - StraatadresBuitenland PostcdBuitenland

R

an..9

Samenvattend moeten de volgende stappen doorlopen worden om te komen tot een functionele berichtspecificatie: •

Leg de definitie van alle benodigde informatie-objecten vast in het gegevensmodel, met behulp van entiteiten, attributen, domeinen, codelijsten en relaties.

•

Selecteer een gezichtspunt (hoofdonderwerp) op basis waarvan de berichthiërarchie (het berichtmodel) zal worden opgebouwd.

•

Stel het gekozen gezichtspunt (hoofdonderwerp) als root van de berichthiërarchie (het berichtmodel) en bepaal welke relaties tussen entiteiten voor dit berichtmodel van toepassing zijn. Bepaal daarbij ook de cardinaliteit (herhaalbaarheid) en status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R), choice/keuze (X)) van iedere hiërarchische entiteit-instantie. NB. houd rekening met andere gelijkgeaarde berichttypen en probeer de berichthiërarchieën zoveel als mogelijk op elkaar af te stemmen (gelijkwaardig te maken).

•

Bepaal per hiërarchische entiteit-instantie welke attributen uit de oorspronkelijke informatieobject definitie in het gegevensmodel, voor dit berichtmodel van toepassing zijn en bepaal bovendien de status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R)) van ieder attribuut.

•

Bepaal per hiërarchische entiteit-instantie, voor alle attributen waarvan de onderliggende domeindefinitie (het waardebereik) in het gegevensmodel gecodeerd is, welke codes toegestaan zijn en welke niet. Met andere woorden: bepaal de code-subsets per hiërarchisch voorkomen van een gecodeerd attribuut.

•

Stel alle business rules in het berichtmodel op. In de business rules worden de eisen verwoord die gelden voor dit specifieke berichtmodel ten aanzien van vulling, waardebereik, afhankelijkheden, etc. Business rules worden alleen apart opgesteld voor zover het eisen betreft die niet tot uitdrukking kunnen worden gebracht binnen een van de voorgaande stappen.

Appendix A geeft aan op welke wijze een functionele berichtspecificatie met behulp van het berichtmodelleertool EC-Design wordt vastgelegd.




Technische berichtspecificatie (SuwiML berichtschemaset) De wijze waarop de technische berichtspecificatie wordt opgebouwd, wordt beschreven in hoofdstuk 4. Belangrijk voordeel bij het vastleggen van de functionele berichtspecificatie in het berichtmodelleertool EC-Design, is dat de technische berichtspecificatie, i.e. de SuwiML body van de SuwiML berichtschemaset, voor het merendeel direct gegenereerd kan worden vanuit ECDesign. Functioneel applicatieontwerp Het functioneel applicatieontwerp binnen de specificatie van een elektronisch ketenbericht, bevat een gedetailleerde beschrijving van de wijze waarop elektronische ketenberichten worden gevuld danwel verwerkt door de bedrijfsapplicatie / het bedrijfsproces van de verzender respectievelijk ontvanger. Het functioneel applicatieontwerp beschrijft zeer exact de wijze waarop de interne structuur van een communicatie-actor (ketenpartij) wordt gemapt (inclusief eventueel noodzakelijk veldwaarde-transformaties) op de beoogde communicatiestructuur/uitwisselingsformaat. Transactiestandaard implementatiedocument Het transactiestandaard implementatiedocument beschrijft op welke manier de vrijheidsgraden binnen de SuwiML transactiestandaard zijn geïmplementeerd binnen de operationele omgeving van het elektronische ketenbericht. Het transactiestandaard implementatiedocument beschrijft welke specifieke keuzes zijn gemaakt tav time-out, herhalingspogingnummer, transactiemanagement, etc.




6. Definities

Binnen SGR/SuwiML worden een aantal specifieke begrippen gebruikt. Onderstaand volgt een beknopte lijst van begrippen met een beschrijving van de betekenis binnen SGR/SuwiML. berichttype Een berichttype is de aanduiding voor een logische proceskoppeling waarin gegevens middels een bericht worden uitgewisseld. Bijvoorbeeld het berichttype ‘Reïntegratieadvies’, ‘UwvDossierPersoon’ of ‘AanvraagWwb’. business operational view Business Operational View (BOV): a perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among organizations, which are needed for the description of a business transaction. (Open-EDI Reference Model Standard – ISO/IEC 14662). cluster Een cluster is een herbruikbare (verbijzonderde) hiërarchische berichtcomponent. Een cluster bevat definities van entiteiten inclusief relaties naar andere entiteiten. In een cluster wordt ook de cardinaliteit van de aanwezige relaties vastgelegd. Binnen de berichtdefinitie kan door middel van type-referentie gebruik worden gemaakt van clusters. complexType Een XML complexType is een XML type dat de structuur van een XML element definieert. Een XML complexType kan gebaseerd zijn op een ander XML complexType en daarop beperkingen (restriction) of uitbreidingen (extension) bevatten. Een XML complexType omvat een set elementen, waarvan elk element afzonderlijk gebaseerd is op een built-in datatype, simpleType of complexType. datatype (in XML Schema) Een datatype is een getypeerde tekenreeks of string die aan specifieke constraints moet voldoen. Er zijn standaard built-in XML datatypen, zoals string, integer, etc. die worden gebruikt. De constraints van deze datatypen liggen vast in de XML Schema standaard. SuwiML kent ook haar eigen datatypen, nummers, datums, alfanumerieke tekenreeksen, zoals deze in het SGR zijn gedefineerd. Bijvoorbeeld de minimale en maximale waarde van een getal of een enumeratie, zoals in “ja/nee”. domeindefinitie Een domeindefinitie is van toepassing op een attribuut binnen een entiteit, en beschrijft exact het toegestane waardebereik voor dit attribuut. In een domeindefinitie wordt vastgelegd welke karakters zijn toegestaan binnen het waardebereik, wat het maximaal aantal karakters is en wat het minimum, of er sprake is van een vaste lengte of juist een variabele, of het een numerieke waarde is of een string, of er een codelijst met codes van kracht is, etc.




edi message EDI message: an approved, published, and maintained formal description of how to structure the data required to perform a specific business function, in such a way as to allow for the transfer and handling of this data by electronic means. electronic business Electronic Business: a generic term covering information definition and exchange requirements within and between enterprises, including customers. electronic data interchange Electronic Data Interchange (EDI): the automated exchange of any predefined and structured data for business among information systems of two or more organizations. (Open-EDI Reference Model Standard – ISO/IEC 14662). entiteit Een entiteit is een verzameling van logisch bij elkaar horende gegevenselementen die elk afzonderlijk binnen de entiteit maximaal één keer voorkomen. Entiteiten binnen SGR/SuwiML liggen vast in het Suwi Gegevensregister. Een entiteit wordt in een schema vastgelegd in de vorm van een XML complexType. abstracte entiteit Een abstracte entiteit komt zelf nooit voor als instantie in een bericht. De eigenschappen van de entiteit (attributen) en relaties met andere entiteiten, worden gebruikt om afgeleide entiteiten (subclasses) vorm te geven. afhankelijke entiteit Een afhankelijke entiteit is een entiteit die alleen in combinatie met één of enkele andere entiteiten kan bestaan. fundamentele entiteit Een fundamentele entiteit is een entiteit die zelfstandig kan bestaan. relatie entiteit Een relatie entiteit is een afhankelijke entiteit die twee fundamentele entiteiten aan elkaar koppelt. Relatie entiteiten vertegenwoordigen veel-op-veel relaties en/of relaties die nog eigen gegevenselementen bevatten. functional service view Functional Service View (FSV): a perspective of business transactions limited to those information technology interoperability aspects of IT Systems needed to support the execution of open-EDI transactions. gegevenstype Een gegevenstype komt overeen met een SGR domeindefinitie welke wordt gebruikt door één of meer SGR gegevenselementen. Een gegevenstype is altijd gebaseerd op een built-in XML Schema datatype maar kan daarop nog constraints bevatten zoals het beperken van de lengte, bijvoorbeeld




'een string van 10 karakters'. Een gegevenstype is een simpleType of een complexType en vormt de basis voor een XML element definitie in een XML Schema. open-edi Open-EDI: electronic data interchange among multiple autonomous organizations to accomplish an explicit shared business goal according to open-EDI standards (i.e. that comply with the Open-EDI Reference Model Standard – ISO/IEC 14662). simpleType Een XML simpleType is een XML type dat de inhoud van een XML element of een XML attribute definieert. Een XML simpleType kan gebaseerd zijn op een ander XML simpleType of op een built-in XML Schema datatype en kan daarop nadere beperkingen bevatten.




7. Referenties

[ebxml] Electronic Business using eXtensible Markup Language (ebXML) http://www.ebxml.org [ec-design] Softwaretool dat de methodische ontwikkeling van elektronische berichten op basis van een gemeenschappelijk gegevensmodel ondersteunt. Berichtspecificaties worden opgesteld vanuit een logisch/functioneel gezichtspunt; de functionaliteit van een bericht is leidend en pas als deze volledig en eenduidig is vastgesteld, wordt vanuit de functionele berichtspecificatie het bijbehorende XML Schema gegenereerd. http://www.ec-design.nl http://www.digitect.nl [iso] International Organization for Standardization (ISO) Development of messages – ISO/NP 17113 Information technology - Metadata registries - ISO/IEC 11179 Open-EDI Reference Model – ISO/IEC 14662 http://www.iso.org [oasis] Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org [protocols] W3C Protocols http://www.w3.org/protocols [rup] IBM Rational Rose – Rational Unified Process methodology (RUP) http://www-130.ibm.com/developerworks/rational/products/rup [soap] Simple Object Access Protocol SOAP/1.1, W3C Note 08 May 2000 Authors: Don Box (DevelopMentor), David Ehnebuske (IBM), Gopal Kakivaya (Microsoft), Andrew Layman (Microsoft), Noah Mendelsohn (Lotus Development Corp.), Henrik Frystyk Nielsen (Microsoft), Satish Thatte (Microsoft), Dave Winer (UserLand Software, Inc.) http://www.w3.org/TR/2000/NOTE-SOAP-20000508




[uml] Object Management Group (OMG) – Unified Modelling Language (UML) http://www.omg.org/technology/documents/modeling_spec_catalog.htm [umm] United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) – Modelling Methodology (UMM) http://www.unece.org/cefact/umm/umm_index.htm [w3c] World Wide Web Consortium (W3C) http://www.w3c.org [web services] http://www-130.ibm.com/developerworks/webservices [xml] Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004 Editors: Tim Bray (Textuality and Netscape ), Jean Paoli (Microsoft <[email protected]>), C. M. Sperberg-McQueen (W3C ), Eve Maler (Sun Microsystems, Inc. <[email protected]>), François Yergeau () http://www.w3.org/TR/2004/REC-xml-20040204 [xml-namespaces] Namespaces in XML, W3C Recommendation 14 January 1999 Editors: Tim Bray (Textuality ), Dave Hollander (Hewlett-Packard Company ), Andrew Layman (Microsoft ) http://www.w3.org/TR/1999/REC-xml-names-19990114 [xml-schema] XML Schema (Second Edition), W3C Recommendation 28 October 2004 Editors (Part 0: Primer): David C. Fallside (IBM ), Priscilla Walmsley () http://www.w3.org/TR/2004/REC-xmlschema-0-20041028 (Part 0: Primer) Editors (Part 1: Structures): Henry S. Thompson (University of Edinburgh ), David Beech (Oracle Corporation ), Murray Maloney (for Commerce One <[email protected]>), Noah Mendelsohn (Lotus Development Corporation ) http://www.w3.org/TR/2004/REC-xmlschema-1-20041028 (Part 1: Structures) Editors (Part 2: Datatypes): Paul V . Biron (Kaiser Permanente, for Health Level Seven <[email protected]>), Ashok Malhotra (Microsoft (formerly of IBM) ) http://www.w3.org/TR/2004/REC-xmlschema-2-20041028 (Part 2: Datatypes)




[xslt] XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999 Editor: James Clark <[email protected]> http://www.w3.org/TR/1999/REC-xslt-19991116




Appendix A

Figuur 38: berichtmodel voor ReintegratieadviesCwiUwv zoals vastgelegd in EC-Design.

Auteur: Paul Vriend



Functionele berichtspecificatie zoals vastgelegd in EC-Design . Business chain:

SUWI Gegevensregister 2.01

Transaction type:

Reintegratieadvies

Functional message:

Reintegratieadvies CWI-UWV v0102-b09

Actor group:

Standard Messages

XML Tag Set:

SuwiML tagset




Summary Opdracht verzending melding Contactpersoon/-afdeling (Bron) Telefoonnummer Contactpersoon Afdeling E-mail adres Contactpersoon/-afdeling Vestiging SUWI Partij SUWI Kolom SUWI Reintegratieadvies Client SUWI Straatadres Straatadres buitenland Telefoonnummer Client E-mail adres client Nationaliteit Kwalificerende intake Uitkeringsverhouding SZ wet Partij SUWI Kolom SUWI Sollicitatie Wijze van solliciteren Reintegratieactiviteit Situatie client arbeidsinpassing Belemmering arbeidsinpassing Beroepsperspectief en realiteitszin Bijzonderheid werkaanvaarding Beschikbaarheid client voor arbeid Beroep Beroepsnaam ongecodeerd Motivatie client Zelfredzaamheid op de arbeidsplaats Arbeidsmarktorientatie Arbeidsmarktkwalificaties


1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, X 1..1, X 0..2, O 0..1, O 1..1, R 1..1, R 1..*, R 1..1, R 1..1, R 1..1, R 1..1, R 0..*, O 1..*, R 1..1, R 1..*, R 1..1, R 0..*, O 1..1, R 0..4, O 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R



OPDRACHT VERZENDING MELDING

1..1, R

OPDRACHT VERZENDING MELDING

xml tag: OpdrachtVerzendingMelding

Applied Transaction Rules TR-01 Status omschrijving versus code

Datum opdracht tot verzending bericht

R

n8

Tijdstip opdracht tot verzending bericht

R

n8

domain: Standaarddatum xml tag: DatOpdrachtTotVerzendingBericht domain: Tijdstip xml tag: TijdOpdrachtTotVerzendingBericht

CONTACTPERSOON/-AFDELING (BRON)

1..1, R

opdracht verzending melding - CONTACTPERSOON/ -AFDELING (BRON)

xml tag: Bron

Naam contactpersoon/-afdeling

R

an..35

domain: Omschrijving AN..35 xml tag: NaamContactpersoonAfd

TELEFOONNUMMER CONTACTPERSOON AFDELING 1..1, R opdracht verzending melding - contactpersoon/ -afdeling (bron) - TELEFOONNUMMER CONTACTPERSOON AFDELING

xml tag: TelefoonnrContactpersoonAfd

Netnummer

R

n..5

Abonneenummer

R

n..10

domain: Netnummer xml tag: Netnr domain: Abonneenummer N ..10 xml tag: Abonneenr

E-MAIL ADRES CONTACTPERSOON/-AFDELING

1..1, R

opdracht verzending melding - contactpersoon/ -afdeling (bron) - E-MAIL ADRES CONTACTPERSOON/ -AFDELING

xml tag: EMailAdresContactpersoonAfd

E-mail adres

R

an..320

domain: Email adres Applied Functional Message Rules FM-RL01 Waardebereik e-mail adres Bron xml tag: EMailAdres

VESTIGING SUWI

1..1, R

opdracht verzending melding - contactpersoon/ -afdeling (bron) - VESTIGING SUWI

xml tag: VestigingSuwi

Code vestiging SUWI

R

n4

Naam vestiging SUWI

R

an..70

domain: Code vestiging SUWI xml tag: CdVestigingSuwi domain: Naam AN..70 xml tag: NaamVestigingSuwi




PARTIJ SUWI

1..1, R

opdracht verzending melding - contactpersoon/ -afdeling (bron) - vestiging suwi - PARTIJ SUWI

xml tag: PartijSuwi

Code partij SUWI

R

n4

Naam partij SUWI

R

an..70

KOLOM SUWI

1..1, R

domain: Code partij SUWI Applied Functional Message Rules FM-RL03 Standaardwaarde partij Suwi Bron xml tag: CdPartijSuwi domain: Naam AN..70 Applied Functional Message Rules FM-RL03 Standaardwaarde partij Suwi Bron xml tag: NaamPartijSuwi

opdracht verzending melding - contactpersoon/ -afdeling (bron) - vestiging suwi - partij suwi - KOLOM SUWI

xml tag: KolomSuwi

Code kolom SUWI

R

n1

Naam kolom SUWI

R

an..35

REINTEGRATIEADVIES

1..1, R

domain: Code kolom SUWI xml tag: CdKolomSuwi code list: Code kolom SUWI (subset selected) 6 CWI domain: Omschrijving AN..35 Applied Functional Message Rules FM-RL02 Standaardwaarde naam kolom Suwi Bron xml tag: NaamKolomSuwi

opdracht verzending melding - REINTEGRATIEADVIES

xml tag: Reintegratieadvies

Applied Functional Message Rules FM-RL24 Waardebereik uitkeringsverhouding

Datum ondertekening reintegratieadvies

R

n8

Toelichting reintegratieadvies

R

an..1200

Datum vermoedelijke eerste werkloosheidsdag

R

n8

Code uitkeringssituatie

R

n1

R

an..80

domain: Standaarddatum xml tag: DatOndertekReintegratieadvies domain: Toelichting AN..1200 xml tag: ToelReintegratieadvies domain: Standaarddatum xml tag: DatVermoedEersteWerkloosheidsdag domain: Code uitkeringssituatie xml tag: CdUitkeringssituatie code list: Codelijst uitkeringssituatie (subset selected) 1 Ontvangt uitkering

Omschrijving uitkeringssituatie

domain: Omschrijving AN..80 xml tag: OmsUitkeringssituatie




Toelichting uitkeringssituatie

O

an..1200

domain: Toelichting AN..1200 xml tag: ToelUitkeringssituatie

CLIENT SUWI

1..1, R

opdracht verzending melding - reintegratieadvies - CLIENT SUWI

xml tag: ClientSuwi

Sofi-nummer

R

n9

O

a..200

Voorletters

R

a..6

Voorvoegsel

O

a..10

Significant deel van de achternaam

R

a..200

Geslacht

R

n1

Geboortedatum

R

n8

Code fictieve geboortedatum

R

n1

domain: Sofinummer Applied Datamodel Rules DM-RL01 Elfproef sofinummer xml tag: SofiNr

Voornamen domain: Naam persoon A..200 xml tag: Voornamen domain: Voorletters xml tag: Voorletters domain: Voorvoegsels xml tag: Voorvoegsel code list:Voorvoegsels (all selected) The codes of this codelist are documented in a separate document domain: Naam persoon A..200 xml tag: SignificantDeelVanDeAchternaam domain: Geslacht xml tag: Geslacht code list: Geslacht (subset selected) 1 mannelijk 2 vrouwelijk domain: Standaarddatum xml tag: Geboortedat domain: Code fictieve geboortedatum Applied Functional Message Rules FM-RL04 Vulling code fictieve geboortedatum xml tag: CdFictieveGeboortedat code list: Code fictieve geboortedatum (all selected) 0 geen enkel datumdeel is fictief geen enkel datumdeel is fictief 1 dag is fictief dag is fictief 2 maand is fictief maand is fictief 3 dag en maand zijn fictief dag en maand zijn fictief 4 jaar is fictief jaar is fictief 5 dag en jaar zijn fictief dag en jaar zijn fictief




6 7 8

maand en jaar zijn fictief maand en jaar zijn fictief dag, maand en jaar zijn fictief dag, maand en jaar zijn fictief onbekend welke datumdelen fictief zijn onbekend welke datumdelen fictief zijn

Omschrijving fictieve geboortedatum

R

STRAATADRES

1..1, X

domain: Omschrijving AN..80 xml tag: OmsFictieveGeboortedat

an..80

opdracht verzending melding - reintegratieadvies - client suwi - STRAATADRES

xml tag: Straatadres

Postcode

R

an6

Woonplaatsnaam

R

an..24

Gemeentenaam

O

an..24

Straatnaam

R

an..24

Huisnummer

R

n..5

Huisnummertoevoeging

O

an..6

domain: Postcode xml tag: Postcd domain: Naam adres Ned AN..24 xml tag: Woonplaatsnaam domain: Naam adres Ned AN..24 xml tag: Gemeentenaam domain: Naam adres Ned AN..24 xml tag: Straatnaam domain: Nummer adres Ned N..5 xml tag: Huisnr domain: Nummer adres Ned AN..6 xml tag: Huisnrtoevoeging

STRAATADRES BUITENLAND

1..1, X

opdracht verzending melding - reintegratieadvies - client suwi - STRAATADRES BUITENLAND

xml tag: StraatadresBuitenland

Postcode buitenland

R

an..9

Woonplaatsnaam buitenland

R

an..24

Landencode ISO

R

a2

Landsnaam

R

an..40

domain: Nummer adres Buitenl AN..9 xml tag: PostcdBuitenland domain: Naam adres Buitenl AN..24 xml tag: WoonplaatsnaamBuitenland domain: Landencode ISO A2 xml tag: LandencdIso code list:Landencode ISO A2 (all selected) The codes of this codelist are documented in a separate document domain: Naam adres Buitenl AN..40 xml tag: Landsnaam




Straatnaam buitenland

R

an..24

Huisnummer buitenland

R

an..9

TELEFOONNUMMER CLIENT

0..2, O

domain: Naam adres Buitenl AN..24 xml tag: StraatnaamBuitenland domain: Nummer adres Buitenl AN..9 xml tag: HuisnrBuitenland

opdracht verzending melding - reintegratieadvies - client suwi - TELEFOONNUMMER CLIENT

xml tag: TelefoonnrClient

Netnummer

R

n..5

Abonneenummer

R

n..10

E-MAIL ADRES CLIENT

0..1, O

domain: Netnummer xml tag: Netnr domain: Abonneenummer N ..10 xml tag: Abonneenr

opdracht verzending melding - reintegratieadvies - client suwi - E-MAIL ADRES CLIENT

xml tag: EMailAdresClient

E-mail adres

R

an..320

domain: Email adres xml tag: EMailAdres

NATIONALITEIT

1..1, R

opdracht verzending melding - reintegratieadvies - client suwi - NATIONALITEIT

xml tag: Nationaliteit

Code nationaliteit

R

n4

Omschrijving nationaliteit

R

an..80

KWALIFICERENDE INTAKE

1..1, R

domain: Tabel nationaliteiten xml tag: CdNationaliteit code list:Tabel nationaliteiten (all selected) The codes of this codelist are documented in a separate document domain: Omschrijving AN..80 xml tag: OmsNationaliteit

opdracht verzending melding - reintegratieadvies - client suwi - KWALIFICERENDE INTAKE

xml tag: KwalificerendeIntake

Datum einde kwalificerende intake

R

n8

R

n1

domain: Standaarddatum xml tag: DatEKwalificerendeIntake

Code fase-indeling

domain: Code fase-indeling xml tag: CdFaseIndeling code list: Code fase-indeling (subset selected) 2 fase 2: na kort arbeidsinpassingstraject bemiddelbaar fase 2: na kort arbeidsinpassingstraject bemiddelbaar 3 fase 3: na lang arbeidsinpassingstraject bemiddelbaar fase 3: na lang arbeidsinpassingstraject bemiddelbaar




Omschrijving fase-indeling

R

an..80

Code aanleiding kwalificerende intake

R

n2

Omschrijving aanleiding kwalificerende intake

R

an..80

UITKERINGSVERHOUDING

1..*, R

domain: Omschrijving AN..80 xml tag: OmsFaseIndeling domain: Code aanleiding kwalificerende intake xml tag: CdAanleidingKwalificerendeIntake code list: Aanleiding Kwalificerende Intake (all selected) 01 verzoek uitkerende instantie 02 einde bemiddelingsactiviteiten 03 op verzoek WIW-organisatie 04 einde inburgering 05 op verzoek klant 06 indicatie bij inschrijving/werkintake domain: Omschrijving AN..80 xml tag: OmsAanlKwalificerendeIntake

opdracht verzending melding - reintegratieadvies - client suwi - UITKERINGSVERHOUDING

xml tag: Uitkeringsverhouding

Applied Functional Message Rules FM-RL24 Waardebereik uitkeringsverhouding

SZ WET

1..1, R

opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - SZ WET

xml tag: SzWet

Code SZ wet

R

a..5

Omschrijving SZ wet

R

an..80

PARTIJ SUWI

1..1, R

domain: Tabel SZ-wetten Applied Functional Message Rules FM-RL05 Waardebereik code partij Suwi uitkering FM-RL06 Waardebereik naam partij Suwi uitkering FM-RL08 Waardebereik naam kolom Suwi uitkering FM-RL07 Waardebereik code kolom Suwi uitkering FM-RL24 Waardebereik uitkeringsverhouding xml tag: CdSzWet code list: Tabel SZ-wetten (subset selected) WW Werkloosheidswet domain: Omschrijving AN..80 xml tag: OmsSzWet

opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - PARTIJ SUWI

xml tag: PartijSuwi

Code partij SUWI

domain: Code partij SUWI Applied Functional Message Rules FM-RL05 Waardebereik code partij Suwi uitkering xml tag: CdPartijSuwi


R

n4



Naam partij SUWI

R

an..70

domain: Naam AN..70 Applied Functional Message Rules FM-RL06 Waardebereik naam partij Suwi uitkering xml tag: NaamPartijSuwi

KOLOM SUWI

1..1, R

opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - partij suwi - KOLOM SUWI

xml tag: KolomSuwi

Code kolom SUWI

R

n1

Naam kolom SUWI

R

an..35

SOLLICITATIE

1..1, R

domain: Code kolom SUWI Applied Functional Message Rules FM-RL07 Waardebereik code kolom Suwi uitkering xml tag: CdKolomSuwi code list: Code kolom SUWI (subset selected) 5 UWV domain: Omschrijving AN..35 Applied Functional Message Rules FM-RL08 Waardebereik naam kolom Suwi uitkering xml tag: NaamKolomSuwi

opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE

xml tag: Sollicitatie

Indicatie sollicitaties

R

n1

Code respons op sollicitaties

O

n1

O

an..80

domain: Code JaNee Applied Functional Message Rules FM-RL11 Status wijze van solliciteren FM-RL12 Status respons op sollicitaties FM-RL13 Status code gebruik informatiekanalen xml tag: IndSollicitaties code list: Code JaNee (all selected) 1 Ja Ja 2 Nee Nee domain: Code respons op sollicitaties Applied Functional Message Rules FM-RL12 Status respons op sollicitaties xml tag: CdResponsOpSollicitaties code list: Codelijst respons op sollicitaties (all selected) 1 Vaak 2 Soms 3 Niet

Omschrijving respons op sollicitaties domain: Omschrijving AN..80 Applied Functional Message Rules FM-RL12 Status respons op sollicitaties xml tag: OmsResponsOpSollicitaties




Toelichting respons op sollicitaties

O

an..800

Code beoordeling persoonlijke presentatie

R

n1

Omschrijving beoordeling persoonlijke presentatie

R

an..80

Toelichting beoordeling persoonlijke presentatie

O

an..800

Conclusie solliciteren

R

an..1200

WIJZE VAN SOLLICITEREN

0..*, O

domain: Toelichting AN..800 Applied Functional Message Rules FM-RL12 Status respons op sollicitaties xml tag: ToelResponsOpSollicitaties domain: Code beoordeling persoonlijke presentatie xml tag: CdOordeelPersoonlPresentatie code list: Code beoordeling persoonlijke presentatie (all selected) 1 Voor verbetering vatbaar 2 Goed domain: Omschrijving AN..80 xml tag: OmsOordeelPersoonlPresentatie domain: Toelichting AN..800 xml tag: ToelOordeelPersoonlPresentatie domain: Toelichting AN..1200 xml tag: ConclSolliciteren

opdracht verzending melding - reintegratieadvies - client suwi - sollicitatie - WIJZE VAN SOLLICITEREN

xml tag: WijzeVanSolliciteren

Applied Functional Message Rules FM-RL11 Status wijze van solliciteren

Code wijze van solliciteren

R

n1

Omschrijving wijze van solliciteren

R

an..50

Toelichting wijze van solliciteren

O

an..800

domain: Code wijze van solliciteren Applied Functional Message Rules FM-RL14 Status toelichting wijze van solliciteren xml tag: CdWijzeVanSolliciteren code list: Codelijst wijze van solliciteren (all selected) 1 Schriftelijk 2 Telefonisch 3 Open 4 Persoonlijk 9 Anders domain: Omschrijving AN..50 xml tag: OmsWijzeVanSolliciteren domain: Toelichting AN..800 Applied Functional Message Rules FM-RL14 Status toelichting wijze van solliciteren xml tag: ToelWijzeVanSolliciteren




REINTEGRATIEACTIVITEIT

1..*, R

opdracht verzending melding - reintegratieadvies - REINTEGRATIEACTIVITEIT

xml tag: Reintegratieactiviteit

Code reintegratieactiviteit

R

n2

Omschrijving reintegratieactiviteit

R

an..50

Toelichting reintegratieactiviteit

O

an..800

SITUATIE CLIENT ARBEIDSINPASSING

1..1, R

domain: Code reintegratieactiviteit Applied Functional Message Rules FM-RL17 Status toelichting reintegratieactiviteit xml tag: CdReintegratieactiviteit code list: Reintegratieactiviteiten (all selected) 01 specifieke bemiddeling 02 werkervaring/WIW 03 een WSW-dienstverband 04 orientatietraject 05 training 06 scholing 07 specifieke hulpverlening 08 REA 09 anders domain: Omschrijving AN..50 xml tag: OmsReintegratieactiviteit domain: Toelichting AN..800 Applied Functional Message Rules FM-RL17 Status toelichting reintegratieactiviteit xml tag: ToelReintegratieactiviteit

opdracht verzending melding - reintegratieadvies - SITUATIE CLIENT ARBEIDSINPASSING

xml tag: SituatieClientArbeidsinpassing

Toelichting persoonlijke situatie

O

an..1200

Conclusie persoonlijke situatie

R

an..1200

BELEMMERING ARBEIDSINPASSING

1..*, R

domain: Toelichting AN..1200 xml tag: ToelPersoonlijkeSituatie domain: Toelichting AN..1200 xml tag: ConclPersoonlijkeSituatie

opdracht verzending melding - reintegratieadvies - situatie client arbeidsinpassing - BELEMMERING ARBEIDSINPASSING

xml tag: BelemmeringArbeidsinpassing

Code belemmering arbeidsinpassing

R

n2

domain: Code belemmering arbeidsinpassing Applied Functional Message Rules FM-RL09 Vulling omschr.andere belemmering arbeidsinpassing xml tag: CdBelemmeringArbeidsinpassing code list: Belemmering Arbeidsinpassing (all selected) 00 Geen 01 Gezondheid - lichamelijk 02 Gezondheid - psychisch 03 Sociaal-maatschappelijk - financieel 04 Sociaal-maatschappelijk - huisvesting 05 Sociaal-maatschappelijk - justitieel




06 07 08 99

Sociaal-maatschappelijk - invloed persoonlijke omgeving/persoonlijke overtuiging Socia al-maatschappelijk - verslaving Sociaal-maatschappelijk - zorgtaken Anders

Omschrijving belemmering arbeidsinpassing

R

an..80

Omschrijving andere belemmering arbeidsinpassing

O

an..80

domain: Omschrijving AN..80 xml tag: OmsBelemmeringArbeidsinpassing domain: Omschrijving AN..80 Applied Functional Message Rules FM-RL09 Vulling omschr.andere belemmering arbeidsinpassing xml tag: OmsAndereBelemmeringArbeidsinpas

BEROEPSPERSPECTIEF EN REALITEITSZIN

1..1, R

opdracht verzending melding - reintegratieadvies - BEROEPSPERSPECTIEF EN REALITEITSZIN

xml tag: BeroepsperspectiefRealiteitszin

Conclusie beroepsperspectief en realiteitszin

R

an..1200

Toelichting vastgestelde bemiddelingsberoepen

O

an..320

BIJZONDERHEID WERKAANVAARDING

0..*, O

domain: Toelichting AN..1200 xml tag: ConclBeroepsperspectief domain: Toelichting AN..320 xml tag: ToelVastgesteldeBeroepen

opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - BIJZONDERHEID WERKAANVAARDING

xml tag: BijzonderheidWerkaanvaarding

Code bijzonderheid werkaanvaarding

R

n2

R

an..80

Toelichting bijzonderheid werkaanvaarding

R

an..1200

BESCHIKBAARHEID CLIENT VOOR ARBEID

1..1, R

domain: Code bijzonderheid werkaanvaarding xml tag: CdBijzonderheidWerkaanvaarding code list: Codelijst bijzonderheid werkaanvaarding (subset selected) 01 Arbeidsvoorwaarden 02 Werktijden 03 Vervoer 04 Beschikbaarheid 05 Reistijd

Omschrijving bijzonderheid werkaanvaarding domain: Omschrijving AN..80 xml tag: OmsBijzonderheidWerkaanvaarding domain: Toelichting AN..1200 xml tag: ToelBijzonderheidWerkaanvaarding

opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - BESCHIKBAARHEID CLIENT VOOR ARBEID

xml tag: BeschikbaarheidClientVoorArbeid

Aantal uren per week beschikbaar voor arbeid

domain: Aantal uren N4 xml tag: AantUrenWeekBeschikbVoorArbeid


R

n4



Indicatie beschikbaarheid conform richtlijn passende ar

R

n1

Toelichting beschikbaarheid voor arbeid

O

an..320

BEROEP

0..4, O

domain: Code JaNeeNVT Applied Functional Message Rules FM-RL10 Status toelichting beschikbaarheid voor arbeid xml tag: IndBeschikbheidConformRichtlijn code list: Code JaNeeNVT (all selected) 1 Ja Ja 2 Nee Nee 8 Niet van toepassing Niet van toepassing domain: Toelichting AN..320 Applied Functional Message Rules FM-RL10 Status toelichting beschikbaarheid voor arbeid xml tag: ToelBeschikbaarheidVoorArbeid

opdracht verzending melding - reintegratieadvies - BEROEPsperspectief en realiteitszin - BEROEP

xml tag: Bemiddelingsberoep

BEROEPSNAAM ONGECODEERD

1..1, R

opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD

xml tag: BeroepsnaamOngecodeerd

Applied Functional Message Rules FM-RL18 Status aansl. werkervaring op bemiddelingsberoep FM-RL19 Status aansl. werkervaring op arbeidsmarkt FM-RL20 Status aansl. opleiding op bemiddelingsberoep FM-RL21 Status aansl. opleiding op arbeidsmarkt FM-RL22 Status aansl. competentie op bemiddelingsberoep FM-RL23 Status aansl. competentie op arbeidsmarkt

Naam beroep ongecodeerd

R

an..120

domain: Omschrijving AN..120 xml tag: NaamBeroepOngecodeerd

MOTIVATIE CLIENT

1..1, R

opdracht verzending melding - reintegratieadvies - MOTIVATIE CLIENT

xml tag: MotivatieClient

Code beoordeling aantal sollicitaties

O

n1

O

an..80

domain: Code beoordeling aantal sollicitaties xml tag: CdBeoordAantSollicitaties code list: Beoordeling aantal sollicitaties (all selected) 1 Goed 2 Voldoende 3 Onvoldoende 4 Niet 9 Niet van toepassing

Omschrijving beoordeling aantal sollicitaties domain: Omschrijving AN..80 xml tag: OmsBeoordAantSollicitaties




Toelichting beoordeling aantal sollicitaties

O

an..800

Code bereidheid thvv reintegratieactiviteiten

R

n1

Omschrijving bereidheid thvv reintegratieactiviteiten

R

an..80

Toelichting bereidheid thvv reintegratieactiviteiten

O

an..800

Conclusie sollicitatiegedrag en bereidheid reintegratie

R

an..1200

ZELFREDZAAMHEID OP DE ARBEIDSPLAATS

1..1, R

domain: Toelichting AN..800 xml tag: ToelBeoordAantSollicitaties domain: Code bereidheid thvv reintegratieactiviteiten xml tag: CdBereidheidReintegratie code list: Bereidheid tot het volgen van reintegratieactiviteiten (all selected) 2 Voldoende 3 Onvoldoende 4 Niet domain: Omschrijving AN..80 xml tag: OmsBereidheidReintegratie domain: Toelichting AN..800 xml tag: ToelBereidheidReintegratie domain: Toelichting AN..1200 xml tag: ConclSollicitatiegedrag

opdracht verzending melding - reintegratieadvies - ZELFREDZAAMHEID OP DE ARBEIDSPLAATS

xml tag: ZelfredzaamheidOpDeArbeidsplaats

Code belemmering taalbeheersing

R

n1

Omschrijving belemmering taalbeheersing

R

an..80

Toelichting belemmering taalbeheersing

O

an..800

R

n1

domain: Code belemmering taalbeheersing Applied Functional Message Rules FM-RL15 Status toelichting belemmering taalbeheersing xml tag: CdBelemmeringTaalbeheersing code list: Code belemmering door taalbeheersing (all selected) 1 Niet 2 Enigszins 3 Mogelijk 4 Zeker domain: Omschrijving AN..80 xml tag: OmsBelemmeringTaalbeheersing domain: Toelichting AN..800 Applied Functional Message Rules FM-RL15 Status toelichting belemmering taalbeheersing xml tag: ToelBelemmeringTaalbeheersing

Indicatie aandachtspunten houding-gedrag-verantwoordeli

domain: Code JaNee Applied Functional Message Rules FM-RL16 Status toelichting aandachtspunten houding gedrag xml tag: IndAandachtspuntenHouding code list: Code JaNee (all selected) 1 Ja Ja 2 Nee Nee




Toelichting aandachtspunten houding-gedrag-verantwoorde

O

an..800

Conclusie zelfredzaamheid op de arbeidsplaats

R

an..1200

ARBEIDSMARKTORIENTATIE

1..1, R

domain: Toelichting AN..800 Applied Functional Message Rules FM-RL16 Status toelichting aandachtspunten houding gedrag xml tag: ToelAandachtspuntenHouding domain: Toelichting AN..1200 xml tag: ConclZelfredzaamhArbeidsplaats

opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTORIENTATIE

xml tag: Arbeidsmarktorientatie

Code realiteitszin werkgerichtheid

R

n1

R

an..80

Toelichting realiteitszin werkgerichtheid

O

an..800

Code gebruik informatiekanalen

O

n1

Omschrijving gebruik informatiekanalen

O

an..80

Toelichting gebruik informatiekanalen

O

an..800

Conclusie arbeidsmarktorientatie

R

an..1200

domain: Code onvoldoende voldoende goed xml tag: CdRealiteitszinWerkgerichtheid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende

Omschrijving realiteitszin werkgerichtheid domain: Omschrijving AN..80 xml tag: OmsRealiteitszinWerkgerichtheid domain: Toelichting AN..800 xml tag: ToelRealiteitszinWerkgerichtheid domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL13 Status code gebruik informatiekanalen xml tag: CdGebruikInformatiekanalen code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende domain: Omschrijving AN..80 xml tag: OmsGebruikInformatiekanalen domain: Toelichting AN..800 xml tag: ToelGebruikInformatiekanalen domain: Toelichting AN..1200 xml tag: ConclArbeidsmarktorientatie




ARBEIDSMARKTKWALIFICATIES

1..1, R

opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES

xml tag: Arbeidsmarktkwalificaties

Code aansluiting werkervaring op bemiddelingsberoep

O

n1

Omschrijving aansluiting werkervaring op bemiddelingsbe

O

an..80

Toelichting aansluiting werkervaring op bemiddelingsber

O

an..800

Code aansluiting werkervaring op arbeidsmarkt

O

n1

Omschrijving aansluiting werkervaring op arbeidsmarkt

O

an..80

Toelichting aansluiting werkervaring op arbeidsmarkt

O

an..800

Code aansluiting opleiding op bemiddelingsberoep

O

n1

domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL18 Status aansl. werkervaring op bemiddelingsberoep xml tag: CdAanslWerkervaringOpBeroep code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende domain: Omschrijving AN..80 xml tag: OmsAanslWerkervaringOpBeroep domain: Toelichting AN..800 xml tag: ToelAanslWerkervaringOpBeroep

domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL19 Status aansl. werkervaring op arbeidsmarkt xml tag: CdAanslWerkervaringOpArbeid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende domain: Omschrijving AN..80 xml tag: OmsAanslWerkervaringOpArbeid domain: Toelichting AN..800 xml tag: ToelAanslWerkervaringOpArbeid

domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL20 Status aansl. opleiding op bemiddelingsberoep xml tag: CdAanslOpleidingOpBeroep code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende




Omschrijving aansluiting opleiding op bemiddelingsberoe

O

an..80

Toelichting aansluiting opleiding op bemiddelingsberoep

O

an..800

Code aansluiting opleiding op arbeidsmarkt

O

n1

Omschrijving aansluiting opleiding op arbeidsmarkt

O

an..80

Toelichting aansluiting opleiding op arbeidsmarkt

O

an..800

Code aansluiting competentie op bemiddelingsberoep

O

n1

Omschrijving aansluiting competentie op bemiddelingsber

O

an..80

Toelichting aansluiting competentie op bemiddelingsbero

O

an..800

Code aansluiting competentie op arbeidsmarkt

O

n1

domain: Omschrijving AN..80 xml tag: OmsAanslOpleidingOpBeroep domain: Toelichting AN..800 xml tag: ToelAanslOpleidingOpBeroep

domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL21 Status aansl. opleiding op arbeidsmarkt xml tag: CdAanslOpleidingOpArbeid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende domain: Omschrijving AN..80 xml tag: OmsAanslOpleidingOpArbeid domain: Toelichting AN..800 xml tag: ToelAanslOpleidingOpArbeid

domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL22 Status aansl. competentie op bemiddelingsberoep xml tag: CdAanslCompetentieOpBeroep code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende domain: Omschrijving AN..80 xml tag: OmsAanslCompetentieOpBeroep domain: Toelichting AN..800 xml tag: ToelAanslCompetentieOpBeroep

domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL23 Status aansl. competentie op arbeid smarkt xml tag: CdAanslCompetentieOpArbeid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende




Omschrijving aansluiting competentie op arbeidsmarkt

O

an..80

Toelichting aansluiting competentie op arbeidsmarkt

O

an..800

Conclusie arbeidsmarktkwalificaties

R

an..1200

domain: Omschrijving AN..80 xml tag: OmsAanslCompetentieOpArbeid domain: Toelichting AN..800 xml tag: ToelAanslCompetentieOpArbeid domain: Toelichting AN..1200 xml tag: ConclArbeidsmarktkwalificaties




Domain specifications A Name

:

Aantal uren N4

Datatype Format Pattern Description

: : : : : :

Alpha Numeric, length 4 (fixed length) n4 \d{2}[0-5]\d HHMM HH = 00 tm 99 MM = 00 tm 59

Name

:

Abonneenummer N ..10

Datatype Format Pattern

: : :

Alpha Numeric, length 10 (variable length) n..10 [0-9]*

Name

:

Code JaNee

Datatype Format Pattern Code lists

: : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Code JaNee 1 Ja 2 Nee

Name

:

Code JaNeeNVT


: : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Code JaNeeNVT 1 Ja 2 Nee 8 Niet van toepassing

Name

:

Code aanleiding kwalificerende intake


: : : : : : : : : :

Alpha Numeric, length 2 (fixed length) n2 [0-9]* Aanleiding Kwalificerende Intake 01 verzoek uitkerende instantie 02 einde bemiddelingsactiviteiten 03 op verzoek WIW-organisatie 04 einde inburgering 05 op verzoek klant 06 indicatie bij inschrijving/werkintake

C




Name

:

Code belemmering arbeidsinpassing


: : : : : : : : : : :

Alpha Numeric, length 2 (fixed length) n2 [0-9]* Belemmering Arbeidsinpassing 00 Geen 01 Gezondheid - lichamelijk 02 Gezondheid - psychisch 03 Sociaal-maatschappelijk - financieel 04 Sociaal-maatschappelijk - huisvesting 05 Sociaal-maatschappelijk - justitieel 06 Sociaal-maatschappelijk - invloed persoonlijke omgeving/persoonlijke

overtuiging Sociaal-maatschappelijk - verslaving Sociaal-maatschappelijk - zorgtaken Anders

: : :

07 08 99

Name

:

Code belemmering taalbeheersing


: : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Code belemmering door taalbeheersing 1 Niet 2 Enigszins 3 Mogelijk 4 Zeker

Name

:

Code beoordeling aantal sollicitaties


: : : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Beoordeling aantal sollicitaties 1 Goed 2 Voldoende 3 Onvoldoende 4 Niet 9 Niet van toepassing

Name

:

Code beoordeling persoonlijke presentatie


: : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Code beoordeling persoonlijke presentatie 1 Voor verbetering vatbaar 2 Goed

Name

:

Code bereidheid thvv reintegratieactiviteiten


: : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Bereidheid tot het volgen van reintegratieactiviteiten 2 Voldoende 3 Onvoldoende 4 Niet




Name

:

Code bijzonderheid werkaanvaarding


: : : : : : : : : : :

Alpha Numeric, length 2 (fixed length) n2 [0-9]* Codelijst bijzonderheid werkaanvaarding 00 Geen 01 Arbeidsvoorwaarden 02 Werktijden 03 Vervoer 04 Beschikbaarheid 05 Reistijd 99 Anders

Name

:

Code fase-indeling


: : : : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Code fase-indeling 0 onbekend 1 fase 1: direct bemiddelbaar 2 fase 2: na kort arbeidsinpassingstraject bemiddelbaar 3 fase 3: na lang arbeidsinpassingstraject bemiddelbaar 4 fase 4: (nog) niet bemiddelbaar 5 fase nog nader te bepalen

Name

:

Code fictieve geboortedatum


: : : : : : : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Code fictieve geboortedatum 0 geen enkel datumdeel is fictief 1 dag is fictief 2 maand is fictief 3 dag en maand zijn fictief 4 jaar is fictief 5 dag en jaar zijn fictief 6 maand en jaar zijn fictief 7 dag, maand en jaar zijn fictief 8 onbekend welke datumdelen fictief zijn

Name

:

Code kolom SUWI


: : : : : : : : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Code kolom SUWI 0 Communicatie-actor 1 SV 2 Arbvo 3 GSD 4 SWI 5 UWV 6 CWI 7 Gemeenten 8 RIB 9 SIOD




Name

:

Code onvoldoende voldoende goed


: : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* CodeOnvoldVoldGoed 1 Goed 2 Voldoende 3 Onvoldoende

Name

:

Code partij SUWI


: : :

Alpha Numeric, length 4 (fixed length) n4 [0-9]*

Name

:

Code reintegratieactiviteit


: : : : : : : : : : : : :

Alpha Numeric, length 2 (fixed length) n2 [0-9]* Reintegratieactiviteiten 01 specifieke bemiddeling 02 werkervaring/WIW 03 een WSW-dienstverband 04 orientatietraject 05 training 06 scholing 07 specifieke hulpverlening 08 REA 09 anders

Name

:

Code respons op sollicitaties


: : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Codelijst respons op sollicitaties 1 Vaak 2 Soms 3 Niet

Name

:

Code uitkeringssituatie


: : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Codelijst uitkeringssituatie 1 Ontvangt uitkering 2 Uitkering aangevraagd 3 Meerdere uitkeringen aangevraagd 4 Geen uitkering (aangevraagd)

Name

:

Code vestiging SUWI


: : :





Name

:

Code wijze van solliciteren


: : : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Codelijst wijze van solliciteren 1 Schriftelijk 2 Telefonisch 3 Open 4 Persoonlijk 9 Anders

Name

:

Email adres

Datatype Format

: :

Alpha Numeric, length 320 (variable length) an..320

Name

:

Geslacht


: : : : : : : :

Alpha Numeric, length 1 (fixed length) n1 [0-9]* Geslacht 0 onbekend 1 mannelijk 2 vrouwelijk 9 niet gespecificeerd (het gegevenselement wordt niet gevoerd in de

E

G

administratie)

L Name

:

Landencode ISO A2

Datatype Format Code lists

: : : :

Alpha, length 2 (fixed length) a2 Landencode ISO A2 The codes of this codelist are documented in an appendix

Name

:

Naam AN..70

Datatype Format

: :


Name

:

Naam adres Buitenl AN..24

Datatype Format

: :


Name

:

Naam adres Buitenl AN..40

Datatype Format

: :


N




Name

:

Naam adres Ned AN..24

Datatype Format

: :


Name

:

Naam persoon A..200

Datatype Format

: :

Alpha, length 200 (variable length) a..200

Name

:

Netnummer


: : :


Name

:

Nummer adres Buitenl AN..9

Datatype Format

: :


Name

:

Nummer adres Ned AN..6

Datatype Format

: :


Name

:

Nummer adres Ned N..5


: : :


Name

:

Omschrijving AN..120

Datatype Format

: :


Name

:

Omschrijving AN..35

Datatype Format

: :


Name

:

Omschrijving AN..50

Datatype Format

: :


Name

:

Omschrijving AN..80

Datatype Format

: :


Name

:

Postcode


: : :

Alpha Numeric, length 6 (fixed length) an6 [1-9][0-9]{3}([a-z]|[A-Z]){2}

O

P




S Name

:

Sofinummer


: : :


Name

:

Standaarddatum


: : :

Description

: : : : :

Alpha Numeric, length 8 (fixed length) n8 (([0]{8})|([0]{4}((0[1-9])|(1[0-2]))((0[1-9])|([1-2][0-9])|(3[0-1])))|(([1-9][0-9]{3})|(0[1-9][09]{2})|(00[1-9][0-9])|(000[1-9]))((0[0-9])|(1[0-2]))((0[0-9])|([1-2][0-9])|(3[0-1]))) EEJJMMDD EE = 00 tm 99 JJ = 00 tm 99 MM = 00 indien DD, EE en JJ ook 00 zijn, anders 01 tm 12 DD = 00 indien MM, EE en JJ ook 00 zijn, anders 01 tm 31

Name

:

Tabel SZ-wetten


: : : : : : : : : : : : : :

Alpha, length 5 (variable length) a..5 Tabel SZ-wetten AAW (voormalige) Algemene Arbeidsongeschiktheidswet ABW Algemene Bijstandswet AKW Algemene Kinderbijslagwet ANW Algemene Nabestaandenwet AOW Algemene Ouderdomswet AWBZ Algemene Wet Bijzondere Ziektekosten AWW (voormalige) Algemene Weduwen en Wezenwet BBZ Besluit Bijstandverlening Zelfstandigen CSV Coördinatiewet Sociale Verzekering INTW Internationale wetten IOAW Wet Inkomensvoorz. Oudere en gedeeltelijk Arbeidsongesch.

T

: : : : : : : : : : : : : : : :

Werkloze Werknemers IOAZ Wet Inkomensvoorz. Oudere en gedeeltelijk Arbeidsongesch. gewezen Zelfstandigen KB Koninklijk besluit en aanverwante regelingen OSV Organisatiewet Sociale Verzekering PVW pensioenwetten REA Wet op de (RE)integratie Arbeidsgehandicapten RWW (voormalige) Rijksgroepregeling Werkloze Werknemers TW Toeslagenwet VUT VUT-regeling WAJ Wet Arbeidsongeschiktheidsvoorziening Jonggehandicapten (WAJONG) WAMIL Wet Arbeidsongeschiktheidsvoorziening Militairen WAO Wet op de Arbeidsongeschiktheidsverzekering WAZ Wet Arbeidsongeschiktheidsverzekering Zelfstandigen WBIA (Tijdelijke Wet) Beperking Inkomensgevolgen Arbeidsongeschiktheidscriteria WVG Wet Voorzieningen Gehandicapten WW Werkloosheidswet WWB Wet Werk en Bijstand




Wet Werk en Inkomen Kunstenaars Ziekenfondswet Ziektewet

: : :

WWIK ZFW ZW

Name

:

Tabel nationaliteiten


: : : : :

Alpha Numeric, length 4 (fixed length) n4 [0-9]* Tabel nationaliteiten The codes of this codelist are documented in an appendix

Name

:

Tijdstip

Datatype Format Pattern Description

: : : : : : : :

Alpha Numeric, length 8 (fixed length) n8 (([0-1][0-9])|(2[0-3]))([0-5][0-9]){2}[0-9]{2} HHMMSSDD HH = 00 tm 23 MM = 00 tm 59 SS = 00 tm 59 DD = 00 tm 99

Name

:

Toelichting AN..1200

Datatype Format

: :


Name

:

Toelichting AN..320

Datatype Format

: :


Name

:

Toelichting AN..800

Datatype Format

: :


Name

:

Voorletters


: : :

Alpha, length 6 (variable length) a..6 ([A-Z]{1,6})|[.]

Name

:

Voorvoegsels


: : : :

Alpha, length 10 (variable length) a..10 Voorvoegsels The codes of this codelist are documented in an appendix

V




Rule specifications DM-RL01

Elfproef sofinummer

Scope: Description:

Datamodel Het Persoon.Sofi-nummer moet voldoen aan de elfproef.

FM-RL01

Waardebereik e-mail adres Bron

Scope: Description:

Functional Message opdracht verzending melding - contactpersoon/-afdeling (bron) - EMAIL ADRES CONTACTPERSOON/-AFDELING.E-mail adres eindigt altijd op '@CWINET.NL'.

FM-RL02

Standaardwaarde naam kolom Suwi Bron

Scope: Description:

Functional Message opdracht verzending melding - contactpersoon/-afdeling (bron) vestiging suwi - partij suwi - KOLOM SUWI.Naam kolom SUWI heeft standaard de waarde Code kolom SUWI.Code kolom SUWI.6 (CWI)

FM-RL03

Standaardwaarde partij Suwi Bron

Scope: Description:

Functional Message opdracht verzending melding - contactpersoon/-afdeling (bron) vestiging suwi - PARTIJ SUWI.Code partij SUWI heeft standaard de waarde '0001' en opdracht verzending melding - contactpersoon/afdeling (bron) - vestiging suwi - PARTIJ SUWI.Naam partij SUWI heeft standaard de waarde 'CWI'.

FM-RL04

Vulling code fictieve geboortedatum

Scope: Description:

Functional Message Als opdracht verzending melding - reintegratieadvies - CLIENT SUWI.Code fictieve geboortedatum niet door het CWI wordt geregistreerd, dan moet het standaard met de waarde Code fictieve geboortedatum.Code fictieve geboortedatum.8 (onbekend welke datumdelen fictief zijn) gevuld worden.

FM-RL05

Waardebereik code partij Suwi uitkering

Scope: Description:

Functional Message Indien opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - PARTIJ SUWI.Code partij SUWI de waarde '0002', '0003', '0004', '0005' of '0006' hebben.




FM-RL06

Waardebereik naam partij Suwi uitkering

Scope: Description:

Functional Message Indien opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - PARTIJ SUWI.Naam partij SUWI de waarde 'UWV-GAK', 'UWV-Cadans', 'UWV-USZO', 'UWV-Bouwnijverheid' of 'UWV-GUO' hebben.

FM-RL07

Waardebereik code kolom Suwi uitkering

Scope: Description:

Functional Message Indien opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - partij suwi - KOLOM SUWI.Code kolom SUWI de waarde Code kolom SUWI.Code kolom SUWI.5 (UWV) hebben.

FM-RL08

Waardebereik naam kolom Suwi uitkering

Scope: Description:

Functional Message Indien opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - partij suwi - KOLOM SUWI.Naam kolom SUWI de waarde Code kolom SUWI.Code kolom SUWI.5 (UWV) hebben.

FM-RL09

Vulling omschr.andere belemmering arbeidsinpassing

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies - situatie client arbeidsinpassing - BELEMMERING ARBEIDSINPASSING.Omschrijving andere belemmering arbeidsinpassing wordt alleen gebruikt indien opdracht verzending melding - reintegratieadvies - situatie client arbeidsinpassing BELEMMERING ARBEIDSINPASSING.Code belemmering arbeidsinpassing gelijk is aan Code belemmering arbeidsinpassing.Belemmering Arbeidsinpassing.99 (Anders)




FM-RL10

Status toelichting beschikbaarheid voor arbeid

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies beroepsperspectief en realiteitszin - BESCHIKBAARHEID CLIENT VOOR ARBEID.Toelichting beschikbaarheid voor arbeid moet verplicht gevuld worden indien opdracht verzending melding reintegratieadvies - beroepsperspectief en realiteitszin BESCHIKBAARHEID CLIENT VOOR ARBEID.Indicatie beschikbaarheid conform richtlijn passende ar gelijk is aan Code JaNeeNVT.Code JaNeeNVT.2 (Nee)

FM-RL11

Status wijze van solliciteren

Scope: Description:

Functional Message Indien opdracht verzending melding - reintegratieadvies - client suwi SOLLICITATIE.Indicatie sollicitaties gelijk is aan Code JaNee.Code JaNee.2 (Nee) dan wordt opdracht verzending melding reintegratieadvies - client suwi - sollicitatie - WIJZE VAN SOLLICITEREN in zijn geheel niet gevuld.

FM-RL12

Status respons op sollicitaties

Scope: Description:

Functional Message Indien opdracht verzending melding - reintegratieadvies - client suwi SOLLICITATIE.Indicatie sollicitaties gelijk is aan Code JaNee.Code JaNee.2 (Nee) dan worden opdracht verzending melding reintegratieadvies - client suwi - SOLLICITATIE.Code respons op sollicitaties , opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE.Omschrijving respons op sollicitaties en opdracht verzending melding - reintegratieadvies - client suwi SOLLICITATIE.Toelichting respons op sollicitaties niet gevuld.

FM-RL13

Status code gebruik informatiekanalen

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ARBEIDSMARKTORIENTATIE.Code gebruik informatiekanalen moet verplicht gevuld worden indien opdracht verzending melding reintegratieadvies - client suwi - SOLLICITATIE.Indicatie sollicitaties gelijk is aan Code JaNee.Code JaNee.1 (Ja)

FM-RL14

Status toelichting wijze van solliciteren

Scope: Description:

Functional Message Indien opdracht verzending melding - reintegratieadvies - client suwi sollicitatie - WIJZE VAN SOLLICITEREN.Code wijze van solliciteren gelijk is aan Code wijze van solliciteren.Codelijst wijze van solliciteren.9 (Anders) dan moet opdracht verzending melding reintegratieadvies - client suwi - sollicitatie - WIJZE VAN SOLLICITEREN.Toelichting wijze van solliciteren verplicht gevuld worden.




FM-RL15

Status toelichting belemmering taalbeheersing

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Toelichting belemmering taalbeheersing wordt alleen gevuld indien opdracht verzending melding - reintegratieadvies - ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Code belemmering taalbeheersing ongelijk is aan Code belemmering taalbeheersing.Code belemmering door taalbeheersing.1 (Niet)

FM-RL16

Status toelichting aandachtspunten houding gedrag

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Toelichting aandachtspunten houding-gedrag-verantwoorde wordt verplicht gevuld indien opdracht verzending melding - reintegratieadvies ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Indicatie aandachtspunten houding-gedrag-verantwoordeli gelijk is aan Code JaNee.Code JaNee.1 (Ja)

FM-RL17

Status toelichting reintegratieactiviteit

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies REINTEGRATIEACTIVITEIT.Toelichting reintegratieactiviteit wordt verplicht gevuld indien opdracht verzending melding reintegratieadvies - REINTEGRATIEACTIVITEIT.Code reintegratieactiviteit gelijk is aan Code reintegratieactiviteit.Reintegratieactiviteiten.09 (anders)

FM-RL18

Status aansl. werkervaring op bemiddelingsberoep

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ARBEIDSMARKTKWALIFICATIES.Code aansluiting werkervaring op bemiddelingsberoep moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD gevuld is.

FM-RL19

Status aansl. werkervaring op arbeidsmarkt

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ARBEIDSMARKTKWALIFICATIES.Code aansluiting werkervaring op arbeidsmarkt moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD NIET gevuld is.




FM-RL20

Status aansl. opleiding op bemiddelingsberoep

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ARBEIDSMARKTKWALIFICATIES.Code aansluiting opleiding op bemiddelingsberoep moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD gevuld is.

FM-RL21

Status aansl. opleiding op arbeidsmarkt

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ARBEIDSMARKTKWALIFICATIES.Code aansluiting opleiding op arbeidsmarkt moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD NIET gevuld is.

FM-RL22

Status aansl. competentie op bemiddelingsberoep

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ARBEIDSMARKTKWALIFICATIES.Code aansluiting competentie op bemiddelingsberoep moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD gevuld is.

FM-RL23

Status aansl. competentie op arbeidsmarkt

Scope: Description:

Functional Message opdracht verzending melding - reintegratieadvies ARBEIDSMARKTKWALIFICATIES.Code aansluiting competentie op arbeidsmarkt moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD NIET gevuld is.

FM-RL24

Waardebereik uitkeringsverhouding

Scope: Description:

Functional Message Het opdracht verzending melding - REINTEGRATIEADVIES dient minimaal één opdracht verzending melding - reintegratieadvies client suwi - UITKERINGSVERHOUDING te bevatten waarvoor opdracht verzending melding - reintegratieadvies - client suwi uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet)




TR-01

Status omschrijving versus code

Scope: Description:

Transaction In het algmeen geldt dat indien een bepaald code-veld gevuld is, het bijbehorende omschrijving-veld ook gevuld moet zijn conform de vastgestelde codelijst. Dit geldt voor OPDRACHT VERZENDING MELDING en alle hiërarchisch gerelateerde entiteiten. Bijvoorbeeld als 'Code besluit naar aanleiding van kennisgeving' gevuld is met code 400, dan moet 'Omschrijving besluit naar aanleiding van kennisgeving' gevuld worden met 'Boete/maatregel opgelegd'.



SuwiML berichtstandaard

Recommend Documents