Andere tussenvarianten zoals JMAILBOX kwamen aan het licht. Deze bevatten reële XML-berichten of met escaped characters

Datum creatie: 13/01/2010 Datum laatste wijziging: 18/08/2014

PROJ ECT « S ET V AN BERICHTEN » (LOT DE M ESSA GES [ LD M]). S IT U E R IN G De migratie van de toepassingen van de mainframe, de goedkeuring van de XML-standaarden (W3C) voor de gegevensuitwisseling hebben de informaticaverantwoordelijken van de KSZ ertoe aangezet om de procedure voor de uitwisseling van bestanden te herzien. Enerzijds zijn er bestanden met een reeks van berichten die individueel moeten worden verwerkt maar er zijn ook andere bestanden waarin elk bericht deel uitmaakt van een geheel. Anderzijds kan het formaat en de codering ervan verschillend zijn : variabele lengte / vaste lengte (mainframe) ‘carriage return-line feed’/ ‘line feed’ (windows-linux) ebcdic/ascii/utf8. Als aanvulling op de problematiek van de materiële uitwisseling van bestanden bestaat de behoefte om een synthese van de inhoud ervan mee te delen. In het kader van de mailbox A1 vertaalde dit zich door het versturen van een overzicht met daarin de functionele inhoud. Andere tussenvarianten zoals JMAILBOX kwamen aan het licht. Deze bevatten reële XML-berichten of met “escaped characters”. We moeten voorbereid zijn om talrijke bestanden te verwerken waarin geen gebruik wordt gemaakt van de generieke oplossingen A1, ssdn-batch, … van de KSZ en we mogen deze berichten niet uitsluiten van een gecentraliseerd beheer.

DOELSTELLINGEN We hebben bijgevolg de lijst opgemaakt van de te voorziene functies. Een gemeenschappelijke procedure vastleggen, ongeacht het soort bestand, voor de uitwisseling van berichtensets 1» ; deze sets moeten door de KSZ en haar partners worden verwerkt. De ‘Berichtensets’ aan de hand van expliciete elementen kunnen oriënteren naar het geschikte verwerkingsproces . Over een communicatiemiddel beschikken om de inhoud ervan of de stand van verwerking ervan te kunnen toelichten. De integriteit van de overgemaakte LDM (bestand) garanderen of over een middel beschikken om de integriteit van de ontvangen LDM (bestand) te kunnen controleren. De afzender identificeren / authentiseren. Elk van de LDM’s eenduidig identificeren LDM moet op alle soorten bestanden of inhoud kunnen worden toegepast : Page 1 of 13 10soa_LotDeMessages_NL.doc

1

Het woord Berichtenset werd gekozen omdat het voor alle situaties geschikt is.

Page 2 of 13 10soa_LotDeMessages_NL.doc

o bestanden met records met A1 (of A0)-prefix van de KSZ (bijvoorbeeld : de A1mailboxen), o bestanden met records met een vaste lengte (bv: bestanden met de feedback van de perso SIS), o bestanden specifiek aan niet-generieke toepassingen: eenmalige toepassingen, … o bestanden met één enkel XML-bericht met verschillende informatiegegevens (bijvoorbeeld : de mutaties van het Pensioenkadaster, de lijst van de personen die in het kader van het sociaal tarief beschermd zijn, …), o met SOAP-berichten (conform de WSDL) (WS-addressing ),

ONT WE RP We hebben enerzijds het of de bestanden die moeten worden uitgewisseld, de zogenaamde « gegevensbestanden » en anderzijds een beschrijvend bestand waardoor elk van de partners "kennis" kan nemen van het onderwerp van zijn gegevensbestanden. In dit beschrijvend bestand staat informatie over: zijn identificatie: o zijn naam, o de organisatie die het heeft verstuurd, o de tijdspanne ervan o een eenduidig identificatienummer de verwerking ervan o het onderwerp ervan o de structuur ervan o de inhoud / het formaat o de codering o de bestemmeling de integriteit ervan o de grootte o het aantal records o het controlemiddel o de afdruk: Message Digest hashing algoritme (MD5) o de digitale handtekening (DSIG)


R E A L IS A T IE De aanpak bestond erin om een mechanisme vast te leggen voor de uitwisseling van één of meerdere gegevensbestanden en om vervolgens de inhoud van het beschrijvend bestand te specificeren teneinde te voldoen aan de functies. We hebben bijgevolg een specifiek XML-bericht gedefinieerd om de inhoud van het beschrijvend bestand te beschrijven. Het element «lotPackageVoucher » omvat alle parameters aan de hand waarvan kan worden tegemoetgekomen aan de hierboven beschreven functies. [cf. schema LotPackageVoucher_20090716.xsd]. We hebben tevens een naam afgesproken om een onderscheid te kunnen maken tussen deze beschrijvende bestanden en de gegevensbestanden.

HET MECHANISME VAN BESTANDENOVERDRACHT De KSZ evenals de partner kunnen beslissen om één of meerdere te verwerken gegegevensbestanden ter beschikking te stellen. Anderzijds is elk soort gegeven (elk bestand) gelinkt aan een (al dan niet generische) specifieke toepassing. Om te vermijden dat talrijke naamafspraken voor elk van hen zouden worden gemaakt, heeft de KSZ een systeem uitgewerkt op basis van een algemeen beschrijvend bestand dat meegestuurd wordt met het (de) desbetreffende bestand(en). De naamafspraak waardoor de beschrijvende bestanden kunnen worden erkend is van essentieel belang. Het werkingsprincipe is het volgende: De partner plaatst eerst alle gegevensbestanden op de FTP-server. Hij plaatst als laatste het beschrijvend bestand (voucher) op de FTP-server De bestemmeling (de KSZ) zoekt regelmatig naar bestanden die aan het criterium « *voucher.xml » voldoen Hij downloadt dit bestand Hij bewerkt het : o opent het bestand en beschikt over informatie :  een lotnummer  een lijst van bestanden (of één enkel)  de manier om ze (het) goed te keuren  de betrokken toepassing (applicationCode en operationCode (voor xml = de naam van het root-element) o downloadt elk van de bestanden en keurt ze goed o deelt het resultaat van dit verloop mee o stuurt deze bestanden door naar de betrokken toepassingen (indien positieve integriteit) Page 4 of 13 10soa_LotDeMessages_NL.doc

o

ingeval van positieve controle veiWijdert hij het volgende van de FTP-server: de <>. Het prtncipe is dat de nag hangende bestanden op de server blijven staan.

De levering van de bestanden na veiWerking ervan volgt dezelfde werkwijze maar hierbij worden de woorden <<de partner>> door<< de KSZ >> vervangen en omgekeerd.

Page 4 of13 lOsoa_LotDeMessages_NL.doc

STRUCTUUR VAN HET BERICHT « BESCHRIJVEND BERICHT / VOUCHER » We beperken ons tot het kort beschrijven van de inhoud van dit bericht. Het schema bevat als commentaar een meer gedetailleerde beschrijving. Het beschrijvend bericht ziet er als volgt uit : metaData : bevat de informatie voor de identificatie van de Berichtenset en de verwachte verwerking packagedLotFiles : maakt een lijst op van de materiële bestanden, de specificaties ervan (structuur en inhoud) en het middel om de integriteit ervan te controleren

Een Berichtenset kan uit één of meerdere gegevensbestanden bestaan.


Het gedeelte metadata :

Bevat de naam van het beschrijvend bestand.

Voorziene versie ingeval van « rerun » te wijten aan een fout Identificeert de Berichtenset Kan worden gelinkt aan een uitvoeringsfrequentie Bv. 2010Q1 Tijdspanne van het beschrijvend bestand : 20100105…. « afzender » « bestemmelingen » maakt het mogelijk om incoherenties aan het licht te brengen Uitvoeringsomgeving Acroniem van de toepassing (bv SOCTAR voor FOD Economie, TSGE voor DGPH, OCMW, RVP, …) Naam van het root-element van het gegevensbestand ingeval van XML Om een melding te krijgen van de downloading en van de geldigheid ervan


Voor elk bestand in een set beschikken we over de volgende informatie

Geeft de naam van het origineel te verwerken bestand

Eventueel de naam van het te downloaden bestand indien hij gezipt is

Tijdsaanduiding van het overeenstemmende gegevensbestand Bepaalt de codering van de karakters Beschrijft de structuur van de berichten van het gegevensbestand Methode en integriteitswaarde Levert de functionele inhoud


B IJ L A G E 1 : S P E C IF IC A T IE S STRUCTUUR VAN HET GEGEVENSBESTAND DAT « EEN GEHEEL VORMT » In het kader van soortgelijke projecten2 werd overeengekomen om een XML-formaat te gebruiken voor de organisatie van de informatiegegevens. Om geldig te zijn, moet het correct samengesteld zijn: d.w.z. dat elke geopende opmaakcode gesloten moet zijn en elk van de elementen in één enkele opmaakcode moet zijn opgenomen , moet het in overeenstemming zijn met een schema, d.w.z. dat de te gebruiken opmaakcodes moeten zijn voorzien, dat de cardinaliteiten, de volgorde, de verplichte of facultatieve aanwezigheid ervan en de soort inhoud moeten overeenstemmen.

NAAMAFSPRAAK MET BETREKKING TOT DE BESCHRIJVENDE BESTANDEN De naamafspraak voor dit beschrijvend bestand, de zogenaamde voucher, volgt de volgende afspraak : <env>

identificatie> voucher.xml De beschrijving van elk van de elementen waaruit het is samengesteld, wordt meegedeeld voor de gegevensbestanden Dit bestand kan gemakkelijk worden teruggevonden in de folder van de FTP-server.

NIEUWE NAAMAFSPRAAK VOOR DE GEGEVENSBESTANDEN Deze afspraak moet niet verplicht worden nageleefd maar de KSZ zal die geleidelijk aan gebruiken voor haar uitwisselingen. Het is op de SOA-berichten of eenvoudigweg de XML-berichten van toepassing. <env>

toepassing> > identificatie> .xml t / a /p : definieert de omgeving from/to : specificeert het versturen of de ontvangst vanwege de partner van de KSZ snnnnnn : de sector en het type instelling s012000 = RSZ, s013002 = RSZPPO, s040001 = CORVE - VZV

of en{10} het ondernemingsnummer voor de instellingen buiten de sociale zekerheid e0314595348 = FOD Economie

Het gaat om toepassingen zoals de mutaties van het pensioenkadaster, die van DIMONA, van het Sociaal Tarief Gas en Elektriciteit, Handichild, enz. 2


-xml-

de inhoud voldoet aan de xml-norm dyyyy dyyyyMM dyyyyMMdd geeft de frequentie en de tijdspanne aan u timestamp of andere

Bijvoorbeeld : voor de partners in de voorbeelden. tfs012000-xml-d20091001u123.xml tfs013002-xml-d20091001u468.xml tts040001-xml-d20091210u10000.xml ate0314595348-xml-d20091210u10000.xml


V O O R B E E L D V A N IN H O U D V A N E E N « B E S C H R IJ V E N D / V O U C H E R » - B E S T A N D Sociaal tarief voor gas en elektriciteit

tte0314595348-xml-d20100105u6voucher.xml t= test

t= to


Lijst van de te downloaden gegevensbestanden

<metaData> tte0314595348-xml-d20100105u6voucher.xml 1 6 <mileStone>20091223 2010-01-05T17:29:03.708 <socialSecurityOrganization> <sectorCode>25 0 0314595348 <environment>T SOCTAR communicateFinalClientListBatchResponse <packagedLotFiles> <packagedLotFile> tte0314595348xml-d20091210u02_reduced tte0314595348xml-d20091210u02_reduced.zip 2010-01-05T17:30:08.463 <encoding>UTF8 <messageStructure> <patternLength>variable <syntax>XML

Identificatie van de berichtenset en verwachte verwerking

e= enterprise SPF ECONOMIE

HandiChild <metaData> tts040001-xml-d20100112u5voucher.xml 1 5 <mileStone>20100112 2010-01-12T12:20:51.051 <socialSecurityOrganization> <sectorCode>25 0 <socialSecurityOrganization> <sectorCode>40


Integritei t

node finalClientGE 38 hasRight true 0 hasRight false 38 status MSG00008 1

Functionele inhoud

MD5 39fe7909bd76826e2437b238d15cda76

1 <environment>T HaChiA652 SendHandiChildA652Responses <packagedLotFiles> <packagedLotFile> tts040001-xml-d20100112u0000005.xml tts040001-xml-d20100112u0000005.xml.zip 2010-01-12T12:21:52.297 <encoding>UTF8 <messageStructure> <patternLength>variable <syntax>XML MD5 e7d873ae0372326a5e0f894b77bc4a9c node SendHandiChildA652Responses 1 node SendHandiChildA652Response 13


Project « set van berichten » (Lot de messages [LDM]). ........................................................................................... 1 Situering................................................................................................................................................................................... 1 Doelstellingen ........................................................................................................................................................................ 1 ONTWERp ............................................................................................................................................................................... 2 Realisatie.................................................................................................................................................................................. 3 het mechanisme van bestandenoverdracht ......................................................................................................... 3 STRUCTUUR VAN HET BERICHT « BESCHRIJVEND BERICHT / voucher » ............................................ 5 Bijlage 1: specificaties ........................................................................................................................................................ 8 Structuur van het gegevensbestand dat « een geheel vormt » ..................................................................... 8 Naamafspraak met betrekking tot de beschrijvende bestanden ................................................................. 8 Nieuwe naamafspraak voor de gegevensbestanden......................................................................................... 8 Voorbeeld van inhoud van een « beschrijvend/voucher »-bestand ............................................................ 10


Andere tussenvarianten zoals JMAILBOX kwamen aan het licht. Deze bevatten reële XML-berichten of met escaped characters

Recommend Documents