Specificaties Aanleverkoppelvlak LVBB

Transcriptie

1 Specificaties Aanleverkoppelvlak LVBB Versie 0.85 Geonovum - KOOP Datum: januari 2018

2

3 Colofon Documentnaam Aanleverkoppelvlak LVBB Projectnaam Standaard Officiële Publicaties met Specifieke Toepassing voor omgevingsdocumenten Projectnummer PR04 Versienummer 0.85 Locatie Amersfoort Projectleider Eric van Capelleveen Auteurs Frank Robijn Pagina 3 van 19

4

5 Inhoud 1 Inleiding De LVBB in het bekendmakings- en publicatieproces Bekendmaken en beschikbaar stellen van besluiten Publiceren en beschikbaar stellen van kennisgevingen en mededelingen Op het Aansluitkoppelvlak aangesloten organisatie 10 3 Interactie met het Aanleverkoppelvlak Validatie van een officiële publicatie Publicatie/bekendmaking van een officiële publicatie Afbreken van een opdracht Synchronisatie service 13 4 Informatiemodel voor opdrachten en verslagen Opdracht en Digikoppeling bericht Antwoordbericht en verslag 16 5 Technische aansluiting Pagina 5 van 19

6 1 Inleiding De Standaard Overheids Publicaties (STOP) een generieke, overkoepelende standaard voor officiële overheidspublicaties, met toepassingsprofielen voor specifieke domeinen, zoals TPOD voor omgevingsdocumenten. Een van de belangrijkste toepassingen van de standaard betreft de aanlevering van officiële publicaties door de bevoegd gezagen aan de Landelijke Voorziening Bekendmaken en Beschikbaarstellen (LVBB. De LVBB is in het leven geroepen zodat overheden maar één keer een officiële publicatie hoeven aan te leveren aan een centrale voorziening. De LVBB draagt zorg voor: De bekendmaking of publicatie volgens de juridische vereisten. Voor besluiten: opname van de besluiten en de geconsolideerde regelingen die daar uit volgens in wetten- en regelingenbanken en registers, volgens wettelijke vereisten. De LVBB heeft daartoe een Aanleverkoppelvlak dat diensten levert aan de (software van) overheden om officiële publicaties correct te kunnen aanleveren. De LVBB en de op de LVBB aangesloten systemen verzorgen verdere verspreiding van de officiële publicaties en geconsolideerde regelingen. Het Register Omgevingsdocumenten (ROD) is een van de systemen die in LVBB participeert en die de verspreiding naar het Digitaal Stelsel Omgevingswet (DSO) faciliteert. Dit document beschrijft uitsluitend het aanleverkoppelvlak van de LVBB. Het betreft de interactie tussen software van bevoegd gezagen (of hun vertegenwoordigers) en de LVBB voor de aanlevering van officiële overheidspublicaties en voor terugmeldingen van bekendmakingen. Via dit koppelvlak worden ook (besluiten en kennisgevingen over) omgevingsdocumenten aangeleverd, maar het koppelvlak is ook bedoeld voor officiële publicaties uit andere domeinen. Dit document beschrijft niet het distributieproces binnen de LVBB en aangesloten systemen dat volgt op een aanlevering aan het koppelvlak. Pagina 6 van 19

7 Visies & plannen Juridische / Awb procedure AANLEVERKOPPELVLAK LVBB Versie 0.85 Standaard Officiële Publicaties januari 18 2 De LVBB in het bekendmakings- en publicatieproces 2.1 Bekendmaken en beschikbaar stellen van besluiten Het aanleverkoppelvlak van de LVBB biedt diensten aan de software van overheden om besluiten bekend te maken volgens de Awb en gerelateerde wet- en regelgeving. Na de bekendmaking van de besluiten verzorgt de LVBB de verspreiding van de besluiten en/of de resulterende regelingen, onder andere naar landelijke systemen die zorgen voor het beschikbaar stellen van de besluiten en regelingen. Het aanleverkoppelvlak verzorgt zelf de verspreiding naar software van (andere) overheden. Overheden Berichtenverkeer LVBB ROD DSO Overheid.nl etc Verbeelding van besluit 3 Besluit Besluit 4 Besluitproces- & consolidatie informatie Validatie / Registratie Besluit Verbeelding van besluit / bekendmaking Bekendmakingen & DSO 6 Onveranderlijke weergave Verbeelding van regeling Toestand (oud) Toestand (nieuw) Toestand (nieuw) Verbeelding van regeling Wetten- en regelingenbank & DSO 1 Synchronisatie Blauw = opgesteld door gebruiker Geel = afgeleid door software (evt met hulp van gebruiker) Groen = toepassing van standaard LVBB is daarmee onderdeel van een proces dat begint met de wens van een bevoegd gezag om een regeling (zoals een omgevingsplan) in te stellen of te wijzigen. Het betreft een proces dat af zal wijken van de huidige processen omdat de STOP standaard een verdergaande automatisering mogelijk maakt. Naar verwachting zal het proces er op hoofdlijnen uitzien als: 1. Ophalen geldende versie. Als het een wijziging betreft en de software van het bevoegd gezag beschikt nog niet over de meest recente versie/toestand van de regeling, dan haalt de software die op bij de LVBB. Daarvoor wordt de synchronisatieservice van het aanleverkoppelvlak gebruikt. Overigens is de verwachting dat de software van het bevoegd gezag als bronhouder in het algemeen wel beschikt over zowel de eerder bekendgemaakte als de nog niet bekendgemaakte toestanden van de regeling. 2. Opstellen/aanpassen van de regeling Medewerkers maken op basis van een eerder bekendgemaakte versie een nieuwe versie waarin de beoogde wijzigingen zijn aangebracht. Pagina 7 van 19

8 3. Opstellen en goedkeuren besluit Het bevoegd gezag moet een formeel besluit nemen over de wijziging. De beschrijving van de wijzigingen wordt door software bepaald; de medewerkers vullen dat aan met bijvoorbeeld een motivatie voor het wijzigen van de regeling. 4. Valideren/registreren van het besluit Na goedkeuring zal het besluit ter bekendmaking aan de LVBB worden verstuurd. De software van het bevoegd gezag stelt het bericht samen en verstuurt het. Desgewenst kan eerst een besluit gevalideerd worden; de validatie maakt ook onderdeel uit van de acceptatie van het besluit ter bekendmaking. De LVBB houdt de versturende software op de hoogte van de voortgang en uitkomst van het validatie/registratie proces. Bij de validatie wordt onderscheid gemaakt naar blokkerende bevindingen die leiden tot afbreken van het proces en bevindingen (waarschuwingen) over aspecten die het proces niet in de weg staan maar die mogelijk duiden op een verschil tussen de dienst die LVBB verleent en de verwachting die de aanleverende software daarvan heeft. 5. Samenstellen geconsolideerde regeling Als onderdeel van de validatie van een besluit zal de LVBB de geconsolideerde regeling samenstellen. De LVBB voert geen consolidatie uit maar gebruikt de aanwijzingen die de software van het bevoegd gezag heeft meegestuurd om de versie van de regeling samen te stellen. Als dit niet mogelijk is, of als de geconsolideerde regeling niet aan de gestelde eisen voldoet (zoals vermeld in de STOP standaard en in het toepassingsprofiel voor de regeling), dan wordt het besluit als niet valide beschouwd en kan het niet bekendgemaakt worden. 6. Bekendmaken van het besluit De LVBB zorgt ervoor dat het besluit bekendgemaakt wordt. Pas na bekendmaking van het besluit kan de inhoud ervan (en de nieuwe toestand van de geconsolideerde regeling) in werking treden. De LVBB zorgt er ook voor dat zowel het besluit als de regeling verder verspreid worden. Zo zijn de omgevingsdocumenten na de bekendmaking beschikbaar voor het ROD/DSO. 7. Synchronisatie door systemen van mede-bronhouders Na validatie en registratie van het besluit (dus nog voor de bekendmaking) zal via het aanleverkoppelvlak een notificatie verstuurd worden aan bevoegd gezagen die (mede-)bronhouder zijn van het besluit en/of de resulterende regelingen dat nieuwe versies beschikbaar zijn. De besluiten en regelingen zijn ook op te halen. Dit maakt het voor systemen van een bevoegd gezag mogelijk om een eigen administratie bij te houden van relevante besluiten en versies van regelingen van andere bevoegd gezagen. Dat is geen verplichting: ook op een later tijdstip kan die informatie geleverd worden. Het diagram illustreert een aantal uitgangspunten van de LVBB architectuur: Pagina 8 van 19

9 1. De LVBB is geen samenwerkingsruimte. Een besluit of versie van een regeling is pas beschikbaar via de synchronisatie service na bekendmaking van het besluit. 2. Uitgangspunt bij de STOP standaard is dat elk softwareproduct dat de standaard implementeert hetzelfde beeld van een besluit of regeling geeft. Er is daarom geen processtap tussen het versturen van het besluit ter acceptatie en de daadwerkelijke bekendmaking om te verifiëren dat de inhoud en verbeelding van een besluit (die ook voor de bekendmaking gebruikt wordt) conform het opgestuurde besluit is. Er is nog discussie of dit het goede proces is. Moet er wel een controlestap komen waarbij het bevoegd gezag kan controleren dat de bekendmaking correct is opgesteld? In dat geval komt er na de registratie een extra processtap bij. Het bekendmakingsproces gaat pas verder als de bekendmaking zoals LVBB die maakt goedgekeurd is. Tevens is nog niet bepaald hoe foutcorrecties uitgevoerd gaan worden als blijkt dat er in het proces toch iets mis is gegaan. Hiervoor bestaat een mechanisme (rectificaties) maar het is nog niet duidelijk of dat voldoende is. 3. De LVBB past de verbeeldingstandaard toe om een onveranderlijke weergave te maken van een bekendmaking die voldoet aan strenge eisen van onveranderlijkheid en duurzaamheid. Deze weergave dient om te borgen dat ook in de verre toekomst na te gaan is wat besloten is door het bevoegd gezag en vult daarmee een juridische eis in. De software van het bevoegd gezag hoeft daar geen aparte actie voor te ondernemen. NNTB Naast het publiceren van officiële publicaties zal het ook mogelijk zijn om wijzigingen aan te brengen aan een geconsolideerde regeling zonder een besluit te hoeven nemen, en dus zonder de noodzaak tot bekendmaken. Het gaat dan bijvoorbeeld om wijzigingen of toevoeging van annotaties die niet in de verbeelding van een besluit terugkomen, of om het doorgeven van een rechterlijke beslissing. De verwachting is dat deze wijzigingen behoudens bekendmaking hetzelfde proces zullen volgen als een besluit. 2.2 Publiceren en beschikbaar stellen van kennisgevingen en mededelingen De LVBB kan ook mededelingen en kennisgevingen bekendmaken c.q. publiceren. Deze functionaliteit is nog niet voorzien voor omgevingsdocumenten. Het proces is dan eenvoudiger: Pagina 9 van 19

10 Overheden Berichtenverkeer LVBB Overheid.nl 2 Mededeling Mededeling 3 Procesinformatie Validatie / Registratie Mededeling Verbeelding van mededeling Bekendmakingen 4 Onveranderlijke weergave 1 5 Synchronisatie Blauw = opgesteld door gebruiker Geel = afgeleid door software (evt met hulp van gebruiker) Groen = toepassing van standaard 1. Ontstaan van een aanleiding om een mededeling of kennisgeving te doen. 2. Opstellen van de mededeling (of kennisgeving). 3. Validatie/registratie van de mededeling. 4. Bekendmaking c.q. publicatie van de mededeling, met het maken van een onveranderlijke weergave. 5. Synchronisatie door andere systemen. Voor het overige zijn de stappen gelijk aan de stappen bij het bekendmaken van een besluit. 2.3 Op het Aansluitkoppelvlak aangesloten organisatie In de procesbeschrijving is aangegeven dat de software van het bevoegd gezag communiceert met de LVBB. Dat is niet helemaal correct: de LVBB communiceert met software van een organisatie die gemachtigd is om namens het bevoegd gezag besluiten ter validatie/bekendmaking aan te bieden. Dit ondersteunt scenario s waar het bevoegd gezag niet zelf de besluiten instuurt (of opstelt), maar dat door een andere organisatie laat doen. Gemeenten die samenwerken kunnen dan een gezamenlijke dienst hebben die de besluiten voor alle gemeenten verwerkt. De LVBB gaat er vooralsnog van uit dat de organisatie die besluiten namens een bevoegd gezag mag aanleveren, ook alle besluiten van dat bevoegd gezag mag aanleveren. De LVBB heeft geen mogelijkheid om onderscheid in autorisatie te maken tussen organisaties (bijvoorbeeld een dienst die alleen omgevingsdocumenten mag aanleveren en een andere dienst alleen verkeersbesluiten). Pagina 10 van 19

11 3 Interactie met het Aanleverkoppelvlak 3.1 Validatie van een officiële publicatie Aangesloten software kan een opdracht tot validatie van een officiële publicatie (besluit, kennisgeving of mededeling) opsturen. De interactie volgt het patroon: Software bevoegd gezag Aanleverkoppelvlak LVBB Opdracht *Levensteken Validatieverslag De opdracht voor validatie bevat dezelfde informatie als de opdracht voor publicatie, op de naam van de service na. Daarnaast bevat de opdracht de officiële publicatie volgens STOP standaard. NNTB: het is mogelijk in de opdracht aan te geven dat slechts een deel van de validatie uitgevoerd hoeft te worden. Het is nog niet duidelijk welke deelvalidaties aangeboden zullen worden. Het is niet voorzien dat de validatie service andere dan officiële publicaties (zoals losse versies van de geconsolideerde regelingen) of delen ervan zal kunnen valideren. De validatie is functioneel gelijk aan de validatie die uitgevoerd wordt als eerste stap van de publicatieservice en gaat na dat de situatie correct is die ontstaat na bekendmaking of publicatie: 1. De opdracht wordt aangeleverd door software van een organisatie die daartoe gerechtigd is, conform de aansluitvoorwaarden van de LVBB. 2. De opdracht is (technisch) correct geformuleerd en kan door de LVBB uitgevoerd worden. 3. De officiële publicatie is correct geformuleerd conform de STOP standaard en het toepassingsprofiel voor de publicatie. 4. Voor een besluit: a. De informatie die de resulterende geconsolideerde regelingen beschrijft is toepasbaar. Dit valt in drie delen uiteen: i. De resulterende versies/toestanden van een regeling zijn in te passen in de regeling (= te combineren met eerder bekendgemaakte toestanden voor de regeling). ii. De objecten om de toestanden mee op te bouwen zijn inpasbaar (= te combineren met de objecten uit eerder bekendgemaakte toestanden). Pagina 11 van 19

12 iii. De objecten zijn correct geformuleerd en geschikt voor gebruik in de regeling (conform de STOP standaard en het betreffende toepassingsprofiel). b. De resulterende versies (toestanden) van de geconsolideerde regeling(en) zijn correct (conform de STOP standaard en het betreffende toepassingsprofiel). Bij de validatie wordt zoveel mogelijk informatie gevalideerd; de validatie stopt pas als het niet meer mogelijk of zinvol is een volgende stap te zetten. De uitkomst van de validatie van een besluit is in principe afhankelijk van het moment dat de validatie wordt uitgevoerd, omdat bij het samenstellen van de resulterende geconsolideerde regeling rekening gehouden moet worden met eerder bekendgemaakte besluiten en andere mutaties van de geconsolideerde regeling. 3.2 Publicatie/bekendmaking van een officiële publicatie De software van het bevoegd gezag gebruikt de publicatieservice om een officiële publicatie bekend te maken of te publiceren. Daartoe stuurt het een opdracht naar het Aanleverkoppelvlak. De opdracht bestaat in het algemeen uit twee delen. Het eerste deel beschrijft wat de LVBB moet doen en bevat de gegevens daarvoor; dit deel is specifiek voor het Aanleverkoppelvlak van de LVBB en wordt in dit document beschreven. Als de opdracht een officiële publicatie betreft is het tweede deel de officiële publicatie; deze is (in XML) gemodelleerd volgens de STOP standaard die in de hele keten geldt en wordt hier buiten beschouwing gelaten. Software bevoegd gezag Aanleverkoppelvlak LVBB Opdracht *Levensteken Validatieverslag Publicatieverslag (na registratie) Publicatieverslag (na publicatie) De LVBB zal na het afronden van de verschillende stappen een verslag sturen. De stappen zijn: 1. Valideren van de officiële publicatie. Dit is gelijk aan het uitvoeren van de validatie service. 2. Registreren van de officiële publicatie. Pagina 12 van 19

13 De LVBB zorgt ervoor dat alles in gereedheid wordt gebracht om de officiële publicatie te kunnen bekendmaken of publiceren. De aanleverende software mag ervan uitgaan dat deze stap slaagt als de validatie succesvol is afgerond; de LVBB verstuurt ook een verslag van de afronding van deze stap. Als het om technische redenen niet mogelijk blijkt de bekendmaking of publicatie op het gevraagde moment uit te voeren, zal dat in het publicatieverslag aangegeven worden. 3. Publiceren/bekendmaken van de officiële publicatie. De LVBB zorgt ervoor dat de officiële publicatie bekendgemaakt wordt op het gevraagde moment, en dat de overige systemen die op de LVBB zijn aangesloten op dat moment over de officiële publicatie beschikken. Als het om een besluit gaat, zijn vanaf dat moment ook de resulterende geconsolideerde regelingen beschikbaar via LVBB en via de overige systemen. Als het om technische redenen niet mogelijk was de bekendmaking of publicatie op het gevraagde moment uit te voeren, zal dat in het publicatieverslag aangegeven worden. NNTB Mogelijk komt er een extra stap tussen 1 en 2 of tussen 2 en 3 waarin bevoegd gezag kan nagaan of de officiële publicatie correct in de LVBB is overgenomen. Als dat het geval is wordt de service mogelijk opgesplitst, wordt de uitvoering van de opdracht tot publicatie gepauzeerd en moet de aangesloten software een tweede opdracht versturen om het publicatieproces voort te zetten. 3.3 Afbreken van een opdracht De software van het bevoegd gezag heeft de mogelijkheid een (potentieel) langlopende validatie- of publicatie opdracht af te breken. Dat gebeurt door het sturen van een nieuwe opdracht om de lopende opdracht te beëindigen. NNTB. Moet nog ontworpen worden 3.4 Synchronisatie service Via de synchronisatie service wordt een bevoegd gezag geïnformeerd over het beschikbaar komen (na bekendmaking) van besluiten en regelingen, voor zover deze als basis dienen voor besluiten van het bevoegd gezag. Deze service is bedoeld om bijvoorbeeld bij meervoudig bronhouderschap de overige bronhouders te informeren. NNTB. Moet nog ontworpen worden Pagina 13 van 19

14 4 Informatiemodel voor opdrachten en verslagen Sommige informatie wordt op meerdere plaatsen doorgegeven. Er wordt nog onderzocht of die doublures eruit gehaald kunnen worden. 4.1 Opdracht en Digikoppeling bericht Een opdracht aan de LVBB bestaat uit een gecomprimeerd (zip) bestand dat tenminste twee XML bestanden bevat: manifest.xml Een XML bestand dat informatie bevat over de bestanden in het zip bestand. opdracht.xml Een XML bestand met een beschrijving van de opdracht. Indeling opdrachtbestand Opdrachtbestand (*.zip) manifest.xml opdracht.xml manifest bestand: BestandType [2..*] BestandType 1 2..* bestandsnaam: NCName contenttype: string Het zip formaat bevat informatie over grootte van een bestand en bevat een checksum (CRC-32). Zip uitpak software gebruikt dat om te controleren dat het uitgepakte bestand correct is. 1..* Bestandsnamen in de zip zijn hoofdlettergevoelig: als naar een bestand verwezen wordt, dan moet de naam exact overeenkomen met de naam in het zip bestand (pad naar bestand in zip) OpdrachtType idlevering: string publicatie: NCName toepassingsprofiel: string ValidatieOpdrachtType datumbekendmaking: date PublicatieOpdrachtType datumbekendmaking: date In het manifest staat voor elk bestand in het zip bestand, inclusief manifest.xml en opdracht.xml, aangegeven wat de naam is en wat voor type content (MIME type) in het bestand is opgeslagen. Bij de validatie wordt nagegaan dat alle genoemde bestanden aanwezig zijn, en dat voor het uitvoeren van de opdracht geen bestand nodig is dat niet in het manifest staat. In het opdracht XML bestand staat een beschrijving van de opdracht. Op dit moment zijn alleen de opdrachten voor de validatie- en publicatieservice gemodelleerd: idlevering Unieke identificatie van de opdracht. De validatie faalt als de waarde van een idlevering al eerder gebruikt is voor een opdracht van hetzelfde bevoegd gezag. publicatie De naam van het XML bestand in het zip bestand dat de officiële publicatie conform STOP formaat bevat. Informatie over dit bestand moet in het manifest opgenomen zijn. toepassingsprofiel Het toepassingsprofiel dat de officiële publicatie beschrijft. NNTB: dit gegeven kan onderdeel worden van de XML in het publicatie bestand. datumbekendmaking De datum waarop de officiële publicatie bekendgemaakt moet worden. Pagina 14 van 19

15 De opdracht (het zip bestand) dient volgens het Digikoppeling ebms 2.0 protocol 1 aangeleverd te worden aan de LVBB, volgens het osb-rm-s profiel. Daartoe stuurt de software van het gevoegd gezag twee bestanden via ebms naar het Aanleverkoppelvlak: Een XML bericht met als inhoud het leveringverzoek dat hoort bij de opdracht (validatieverzoek of publicatieverzoek). Het zip bestand van de opdracht. Het leveringsverzoek is gemodelleerd als: Opdrachtbestand moet bij dit bericht zijn gevoegd LeveringVerzoekType idlevering: string softwareversie: SoftwareVersieType SoftwareVersieType leverancier: string product: string [0..1] versie: string [0..1] validatieverzoek publicatieverzoek LeveringGBVerzoekType external-data-reference: data-reference (Digikoppeling GB) data-reference (Digikoppeling GB) validatiegbverzoek publicatiegbverzoek Opdrachtbestand moet door LVBB worden opgehaald idlevering leverancier product versie De unieke identificatie van de opdracht; moet gelijk zijn aan de waarde die in opdracht.xml wordt gebruikt. De naam van de leverancier van de software van het bevoegd gezag De naam van het software pakket/product De versie van de software Het osb-rm-s profiel van Digikoppeling ebms schrijft zowel transport- als berichtbeveiliging voor. De transportbeveiliging betreft een SSL/TLS verbinding die met PKIo certificaten beveiligd wordt. De aangesloten software moet daarvoor een PKIo certificaat gebruiken met daarin het OIN van ofwel het bevoegd gezag, ofwel de organisatie die het bericht daadwerkelijk verstuurt. De berichtbeveiliging bestaat eruit dat het XML bericht met daarin leveringverzoek digitaal getekend wordt met het PKIo certificaat van het bevoegd gezag dat verantwoordelijk is voor de officiële publicatie. Beide certificaten zijn onderdeel van het technisch aansluitcontract (de CPA) die voor de ebms aansluiting wordt opgesteld. 1 Voor technische documentatie: zie Pagina 15 van 19

16 Het aanleverkoppelvlak ondersteunt ook het Digikoppeling Grote Berichten protocol. Als het zip bestand groter is dan (NNTB) dan is het Grote Berichten protocol verplicht; is ht zip bestand kleiner in grootte dan mag de aanleverende software kiezen om het protocol al dan niet te gebruiken. Als het protocol gebruikt wordt, dan verstuurt de software alleen een XML bestand met daarin een validatiegbverzoek of een publicatiegbverzoek via ebms (wederom volgens het osb-rm-s profiel). In die XML is een extra element opgenomen dat beschreven is in de Digikoppeling documentatie, en dat aangeeft waar het opdracht zip bestand op te halen is. De LVBB zal dat zip bestand vervolgens ophalen. 4.2 Antwoordbericht en verslag De LVBB verstuurt een antwoordbericht als (een stap voor) een opdracht is uitgevoerd. Op dit moment wordt onderscheid gemaakt in een validatie- en een publicatie antwoordbericht. De antwoordberichten voor synchronisatie ontbreken nog. VerzoekResultaatType code: VerzoekUitkomstCode meldingen: stop:melding [0..1] 1 «enumeration» VerzoekUitkomstCode succes mislukt OpdrachtverslagType idlevering: string meldingen: stop:melding [0..1] tijdstipverslag: datetime 0..* 0..* 15 Meldingen (STOP / TP) ValidatieVerzoekResultaatType verslag: ValidatieVerslagType [0..1] ValidatieVerslagType uitkomst: ValidatieUitkomstCode [0..1] voortgang: ValidatieVoortgangCode [0..1] «enumeration» ValidatieUitkomstCode valide niet-valide opdracht-niet-valide behandeling-afgebroken «enumeration» ValidatieVoortgangCode opdracht-ontvangen validatie-voltooid behandeling-afgebroken PublicatieVerzoekResultaatType verslag: PublicatieVerslagType [0..1] PublicatieVerslagType tijdstippublicatie: datetime [0..1] uitkomst: PublicatieUitkomstCode [0..1] voortgang: PublicatieVoortgangCode [0..1] «enumeration» PublicatieUitkomstCode gepubliceerd niet-valide opdracht-niet-valide behandeling-afgebroken «enumeration» PublicatieVoortgangCode registratie-voltooid publicatie-voltooid code verslag idlevering tijdstipverslag voortgang uitkomst Uitkomst van de behandeling van het verzoek dat aan de LVBB is gestuurd. De behandeling is een succes als de LVBB de bijbehorende opdracht kan lezen. Het verslag van de uitvoering van de opdracht. Het verslag is beschikbaar vanaf het moment dat de opdracht in behandeling is genomen. De identificatie van de opdracht. Tijdstip waarop het verslag voor het laatst is bijgewerkt. De voortgang van de uitvoering van de opdracht. Het resultaat van de opdracht. Deze is pas beschikbaar als de uitvoering van de opdracht is beëindigd. Op twee plaatsen komen (fout)meldingen voor. De meldingen in het verzoekresultaat gaan over het behandelen van het verzoek; een mogelijke foutmelding is dat de LVBB de opdracht niet kan lezen. De meldingen in het verslag gaan over de uitvoering van de opdracht. Voor de meldingen wordt hetzelfde mechanisme gebruikt als voor meldingen die geassocieerd zijn met de bedrijfsregels in het toepassingsprofiel. Pagina 16 van 19

17 NNTB. Het is nog niet duidelijk of en hoe meldingen geassocieerd met bedrijfsregels in het toepassingsprofiel gemodelleerd gaan worden. Onderstaande beschrijving is een schets van een mogelijke aanpak. IMTP: definitie van melding in toepassingsprofiel STOP: definitie van melding in antwoordberichten imtp:melding beschrijving: string categorie: string [0..1] code: string definitie: string soort: stop:meldingsoortcode stop:melding beschrijving: string categorie: string [0..1] code: string ernst: stop:meldingernsttype soort: stop:meldingsoortcode «enumeration» stop:meldingernsttype fout waarschuwing informatie «enumeration» stop:meldingsoortcode imtp:eigenschappen * stop:metadata 0..* technisch inhoudelijk imtp:eigenschap cardinaliteit: int / int definitie: string naam: string waarde: datatype stop:uitspraak property: string waarde Het meldingen mechanisme bestaat uit twee delen. Er is een beschrijving van alle mogelijke meldingen (links in het diagram) die voor elke melding (geïdentificeerd met een code) beschrijft wat de aanleiding is voor de melding en enkele karakteristieken geeft. Bijvoorbeeld of het een technische melding betreft (de software heeft een probleem veroorzaakt) of een inhoudelijke (de eindgebruiker heeft verkeerde informatie verstrekt). Onderdeel van de beschrijving is ook een standaardtekst voor de melding. Het overzicht van alle mogelijke meldingen wordt op een nader te bepalen manier beschikbaar gemaakt voor de leveranciers van software die op het koppelvlak aansluit. In de antwoordberichten worden de meldingen met de code geïdentificeerd. Of de tekst van de melding meegeleverd zal worden is nog een discussiepunt. De informatie die nodig is om de tekst samen te stellen wordt in ieder geval bijgeleverd, zodat de aangesloten software in staat is zowel de standaardtekst te gebruiken als een melding te genereren die beter aansluit bij de functionaliteit van de software. Een voorbeeld van een beschrijving van een melding is: Pagina 17 van 19

18 <melding code= tpod:omgevingsplan_sjabloon_123 > <tekst> Het omgevingsplan <param id= besluit /> voldoet niet aan de voorgeschreven indeling </tekst> <soort>technisch</soort> <categorie>tekst</categorie> <betreft> <element id= regeling > </element> <element id= besluit > </element> </betreft> </melding> Een voorbeeld van een melding is: <melding> <code>tpod:omgevingsplan_sjabloon_123</code> <ernst>fout</ernst> <betreft> <uitspraak property= regeling> </uitspraak> <uitspraak property= besluit > </uitspraak> </betreft> </melding> Pagina 18 van 19

19 5 Technische aansluiting Voor de aansluiting op het koppelvlak is een technisch aansluitcontract (CPA) nodig. Dit CPA wordt verstrekt bij aansluiting op het koppelvlak. De overige technische artefacten (zoals XML schema s voor de XML berichten en bestanden) worden meegeleverd met de CPA. De XML schema s houden gelijke tred met de realisatie van het LVBB aanleverkoppelvlak. De schema s voor de informatiemodellen in dit document zijn nog niet beschikbaar. Pagina 19 van 19