Nederlandse Proces Architectuur

Uit Logius SBR Wiki
Ga naar: navigatie, zoeken

Pagina In Ontwikkeling

Inhoud

Inleiding

Context

SBR streeft naar standaardisatie van (financiële-)rapportagestromen in richting van de overheid en private partijen. Optimalisatie van de rapportageketens vergt dat het helder is welke standaarden, processen en technieken gebruikt kunnen worden. Dit geldt zowel voor de publieke en private afnemers als voor de partijen die rapportages aanleveren of ontvangen (ophalen) of daar anderszins bij betrokken zijn.

Het SBR Platform heeft opdracht gegeven om, in analogie met de Nederlandse Taxonomie Architectuur (NTA), de Nederlandse Proces Architectuur (NPA) uit te werken. De richtlijnen in de NPA geven zowel marktpartijen als nieuwe (en bestaande) SBR partners handvatten om op gestandaardiseerde wijze de onderlinge digitale interactie met een SBR infrastructuur in te richten om tot een beperking van kosten voor marktpartijen die aansluiten op deze infrastructuur te komen. De NPA en de NTA bepalen gezamenlijk de invulling van SBR.

Doel

Overheden en Banken streven, in het kader van SBR, naar standaardisatie van de system-to-system interactie met een SBR-infrastructuur. Doel van de NPA is te komen tot een overzicht met richtlijnen en generieke architectuur principes die handvatten bieden voor deze standaardisatie.

Principes moeten toekomstvast zijn en onafhankelijk van de huidige implementatie opgesteld worden. Met de NPA wordt geborgd dat SBR implementaties aan generieke- en kwaliteitseisen voldoen: er wordt zo veel mogelijk één standaard gehanteerd richting marktpartijen (softwareontwikkelaars) waarbij de informatieprocessen op eenduidige wijze worden afgehandeld.

Nieuwe en bestaande SBR partners dienen zich, bij gebruik en de implementatie van een SBR-infrastructuur, volgens de SBR Governance zoveel mogelijk aan de NPA principes te houden. SBR Partners kunnen, met duidelijke verantwoording en onderbouwing, hierbij wel afwijken van de NPA principes.

Opstellers

Naam Organisatie
Stephan Kockelkoren Logius
Niels de Winne Logius
Marcel Ermers Belastingdienst
Ton Wessels CBS
Maurice Mesman / John Sloof Kamer van Koophandel
Okko Smit FRC
Alie van Nieuwenhoven FRC
Emiel Kahlmann FRC
Victor Pekárek FRC

Definities

De in dit document gehanteerde begrippen worden in de onderstaande tabel gedefinieerd:

SBR Partner Zowel publieke als private partijen die voldoen aan alle eisen/verplichtingen vanuit het SBR-stelsel en die derhalve voluit als zodanig binnen het stelsel participeren en onderdeel zijn van de publiek-private governancestructuur, zoals beschreven in de SBR Governance. (zie SBR_governance_april_2013)
Begrip Definitie
Afnemer Een entiteit (overheid of banken) die voor de uitoefening van een publieke of private taak elektronisch verkeer met andere overheden, burgers en/of bedrijven wenselijk acht en daarbij gebruik maakt van SBR om elektronische berichten te ontvangen of versturen (mede te delen). (Afnemer wordt ook wel ‘uitvragende partij’ genoemd)
Gebruiker Een onderneming, rechtspersoon of natuurlijke persoon die gebruik maakt van SBR ten behoeve van het elektronische verkeer met één of meerdere Afnemers (ook wel aanleveraar, bedrijf of intermediair)
Belanghebbende Een onderneming, rechtspersoon of natuurlijke persoon namens wie een gebruiker –of die zelf als gebruiker- gebruik maakt van SBR. De aan te leveren of op te halen informatie heeft betrekking op deze entiteit.
Certificaat Een digitaal document dat gegevens bevat voor de waarborging van de integriteit van bestanden en/of opzetten van een beveiligde verbinding. Ook kan een certificaat worden gebruikt voor authenticatie, zowel op technisch niveau als ook op het niveau van een persoon of organisatie.
SBR-infrastructuur Een voorziening die geautomatiseerd keteninformatieprocessen uitvoert op basis van SBR gegevensstandaarden, processtandaarden en technische standaarden. Een SBR-infrastructuur zorgt voor het gestandaardiseerd uitvoeren en beheren van informatie-uitwisselingsprocessen, en bestaat uit een digitale toegangspoort van bijvoorbeeld de overheid of Banken. De aanleverportalen (van SBR partners) maken geen deel uit van de SBR infrastructuur en vallen buiten scope van de NPA.
Koppelvlak Een koppelvlak is een system-to-system verbinding tussen informatiesystemen dat de uitwisseling van informatie faciliteert. Het definieert de interactie tussen SBR-infrastructuur en de gebruiker of de interactie tussen SBR-infrastructuur en afnemer
Proces Een doelgericht samenhangend geheel van opeenvolgende activiteiten in de tijd.


Governance

Werkgroep NPA

Er is een nieuw overleg gremium in het leven geroepen: de SBR werkgroep NPA. Alle SBR Partners nemen deel aan dit overleg. Het overleg staat onder leiding van Logius (beheer NPA) en zal minimaal 4 keer per jaar plaatsvinden. Indien er geen agendapunten zijn ingebracht zal de werkgroep geen doorgang vinden, als agenda punten aanleiding geven tot het beleggen van een extra bijeenkomst zal deze georganiseerd worden.


Totstandkoming NPA

Bij de totstandkoming van de NPA zijn onderstaande stappen doorlopen.

Opstellen startdocument

In de Werkgroep NPA (SBR Partners) is een startdocument opgesteld met de scope van de NPA, bouwblokken (onderwerpen die aan bod komen) en een voorstel rond de Governance.

Input Expertgroep Processen en Techniek

Het startdocument is voorgelegd aan EG P&T. De EG is gevraag input en advies op de bouwblokken en scope van de NPA te geven.

Adviseren Platform

In de Werkgroep NPA is de input uit de EG P&T verwerkt en is een definitief document, met daarin de NPA, opgesteld. Dit definitieve document id aan de EG P&T en het Platform verstuurd worden. Het advies en de procesgang (afstemming) is in de vorm van een oplegnotitie meegestuurd.

Bekrachtiging NPA

Het SBR-Beraad beslist, op voordracht van het Platform, over bekrachtiging van de NPA. Het Beraad vergewist zich ervan dat de brede SBR-community, vertegenwoordigd in de expertgroep P&T, in de gelegenheid is gesteld hierover te adviseren.


Governance

Logius beheert de NPA. Aanpassingen op de NPA kunnen worden ingebracht via onderstaand afsprakenstelsel. Details worden weergegeven in de #BPMN procesplaten.

Input voor aanpassingen

Op verschillende manieren kunnen zowel marktpartijen / softwareleveranciers als NPA-partners aanpassingsvoorstellen op de NPA indienen. Het NPA beheerteam van Logius agendeert het voorstel in de werkgroep NPA. Zie #BPMN Procesplaten, Procesplaat 1.

Verwerking aanpassing

De werkgroep NPA komt bijeen en beoordeelt wenselijkheid, eventueel na afstemming met technische experts. Indien er een mogelijk grote impact bestaat zal een Request for Comments worden gepubliceerd (op website SBR-nl.nl) en verstuurd aan de deelnemers van de EG P&T. De werkgroep NPA doet, na impact bepaling op implementatie, een voorstel over de voorgenomen aanpassing van NPA en implementatie termijn. Zie #BPMN Procesplaten, Procesplaat 2.

Vaststellen aanpassing

Voor in gebruik name van een aanpassing van de NPA wordt de Expertgroep Processen en Techniek geïnformeerd en om advies gevraagd, waarna de aanpassing wordt bekrachtigd in het Platform en voorgelegd aan het SBR Beraad. Zie #BPMN Procesplaten, Procesplaat 3.


NPA: Scope

Onderstaande punten en schema geven de scope weer van de NPA.

Binnen Scope

  • Zoals de NTA over gegevens (harmonisatie) en XBRL (technische standaard) gaat, gaat de NPA over processen en het gebruik van en de eisen aan de onderliggende technische standaarden gaan.
  • De NPA ziet op de interactie met de SBR infrastructuur. De verschillende interacties tussen gebruiker en verwerkende infrastructuur zijn gebundeld in een SBR proces. Ieder proces stelt functionele eisen aan de standaard ‘bouwblokken’ waaruit het proces bestaat.

Bouwblokken SBR


  • Er wordt onderscheid gemaakt tussen functionele eisen en randvoorwaardelijke voorzieningen,
    1. Functionele eisen in de NPA zien, per bouwblok op eenduidige terminologie, conventies en requirements ten aanzien van randvoorwaardelijke voorzieningen.
    2. Randvoorwaardelijke voorzieningen (standaarden, technische aspecten en stelsels) die buiten de SBR Governance liggen worden in de NPA als zodanig benoemd. In de NPA wordt bepaald welke onderdelen van standaarden gebruikt worden in het kader van SBR.
  • De NPA is gebaseerd op de huidige SBR architectuur principes zoals geïmplementeerd in Digipoort en BIV.
  • SBR processen en bouwblokken die door één partij zijn ontwikkeld en geïmplementeerd vormen de facto de huidige standaard en zijn opgenomen in de NPA om standaardisatie te bevorderen. Bij in gebruik name van deze processen of bouwblokken door andere SBR partners zullen de principes en richtlijnen, zoals geformuleerd in dit document, als leidraad gelden. Afwijkende wensen en use-cases zullen in de werkgroep NPA besproken worden en kunnen leiden tot een aanpassing van de NPA.
  • SBR Partners streven naar standaardisatie, maar domein specifieke invulling door de afnemers (SBR Partners) is mogelijk. Zij blijven zelf beslissingsbevoegd over voorschriften uit de NPA, maar moeten verantwoording in Expertgroep en Platform afleggen over hun keuzes.


Buiten scope

  • Procesafwikkeling en berichtverwerking volgend op interactie met de gebruiker valt buiten de scope van de NPA. Dit ziet zowel op interne berichtafhandeling binnen een SBR infrastructuur als berichtafhandeling door een afnemer.
  • De aanleverportalen (van SBR Partners) maken geen deel uit van de SBR infrastructuur en vallen buiten scope van de NPA.
  • Aspecten van de een SBR service organisatie zoals bijvoorbeeld aansluitondersteuning, klantondersteuning, machtingsprocessen (B2), het verzorgen van een ingerichte beheerorganisatie, interactie tussen SBR infrastructuur en afnemer (bijvoorbeeld Digipoort – Belastingdienst) en afspraken rond service niveaus (openstellingstijden, verwerkingscapaciteit, betrouwbaarheid, etc.) vallen buiten de scope van de NPA.
  • De NPA is geen "SBR roadmap": er wordt geen toekomst visie / roadmap voor de komende jaren geschetst. Er wordt wel rekening gehouden met ontwikkelingen in de nabij toekomst.


NPA: Processen

De gebruiker (aanleverende partij) communiceert met de SBR infrastructuur door interacties met een SBR proces. Ieder proces (aanleveren, e-Mededelen en statusinformatie) bestaat uit een aantal bouwblokken, welke in het volgende hoofdstuk worden weergegeven.


Aanleveren

Aanleveren bestaat uit het door de gebruiker versturen van een bericht naar een SBR-infrastructuur en het ontvangen van het resultaat van de verwerking.

Interactie

Er zijn twee vormen van aanlever interactie te onderkennen: een synchroon en een a-synchroon proces:

  • Synchroon: Indien de gehele verwerking van een aanleververzoek (request) binnen de SBR infrastructuur , inclusief aflevering aan een afnemer, succesvol verlopen is, wordt er een SOAP response verzonden. De response maakt melding van het ‘kenmerk’ van het proces.
  • A-Synchroon: Indien de technische verwerking van een aanleververzoek (request) in de aanleverservice succesvol verlopen is, wordt er een SOAP response verzonden. De response maakt melding van het ‘kenmerk’ van het proces. Dit kenmerk moet worden gebruikt om de status van verwerking te bekijken met de statusinformatieservice.

Voor beide processenimplementaties gelden onderstaande generieke interactie principes:

  • Iedere aanlevering is voorzien van een gestandaardiseerde set (conform het afgesproken koppelvlak) gegevens om het bericht op de juiste wijze te verwerken.
  • Indien de technische verwerking van een verzoek (request) niet succesvol verlopen is, wordt er een SOAP fault verzonden.
    1. Het foutbericht bevat een gedetailleerde beschrijving van de fout en een code waarmee in documentatie toelichting van de fout is te achterhalen.
    2. Het foutbericht is op eenduidige wijze opgesteld: syntax (gedefinieerde velden voor foutbericht) en semantiek (standaard wijze van fout(code) opmaak) zijn gestandaardiseerd.

Bouwblokken

Bouwblok Eis
Authenticatie verplicht
Beveiliging verplicht
Validatie verplicht
Autorisatie:

machtiging controleren

optioneel

(*) ‘optioneel’ zie eisen van de afnemer.


eMededelen

eMededelen bestaat uit het ophalen van een bericht door een (gemachtigde) gebruiker uit een SBR-infrastructuur en verifiëren of diegene die het bericht ophaalt gerechtigd is dit te doen.

Interactie

Hierbij gelden onderstaande generieke interactie principes:

  • Ieder verzoek om een bericht op te halen is voorzien van gegevens om het op te vragen bericht te identificeren.
  • Ieder verzoek om een bericht op te halen wordt getekend met een certificaat waarin identificerende gegevens van de gemachtigde zijn opgenomen.
  • Indien de gebruiker geen kenmerk heeft van het op te halen bericht zal, voordat een bericht wordt opgehaald, moeten worden vastgesteld welke berichten opgehaald kunnen worden. Er wordt een lijst met klaarstaande berichten opgevraagd (totale lijst, of overzicht van mutaties sinds de vorige lijst) en daarna aan de hand van een specifiek kenmerk het bericht zelf.
  • Indien de technische verwerking van een ophaalverzoek (request) succesvol verlopen is, wordt er een SOAP response verzonden. De SOAP respons bevat het op te halen bericht.
  • Indien de technische verwerking van een verzoek (request) niet succesvol verlopen is, wordt er een SOAP fault verzonden.

- Het foutbericht bevat een gedetailleerde beschrijving van de fout en een code waarmee in documentatie toelichting van de fout is te achterhalen.

Bouwblokken

Bouwblok Eis
Authenticatie verplicht
Beveiliging verplicht
Validatie verplicht
Autorisatie:

machtiging controleren

verplicht


Statusinformatie

De gebruiker dient op eenduidige wijze statusinformatie te kunnen inzien met betrekking tot de aangeleverde berichten. De statusinformatieservice is een webservice waarbij gebruikers informatie kunnen opvragen met betrekking tot het verwerkingsproces van een door hen zelf aangeleverd bericht. Er dient gecontroleerd te worden of een gebruiker gerechtigd is de statusinformatie in te zien.


Interactie

  • Indien een afnemer na ontvangst van een bericht, eigen controles toepast op de berichtinhoud alvorens het bericht te accepteren voor inhoudelijke behandeling, dient de statusinformatie uit dit proces beschikbaar te worden gesteld via dezelfde service als de statusinformatie uit de SBR-infrastructuur.
  • Hiertoe dient een tussen afnemers gestandaardiseerde syntax (gedefinieerde velden voor statusbericht) en semantiek (standaard wijze van status(code) opmaak) te worden gebruikt.
  • In documentatie dient aangegeven te worden welke statuscodes een 'eindstatus' betreffen en wat het juridische betekenis is van een bepaalde status. De documentatie en juridische betekenis kan per SBR-partner verschillen.
  • De statusinformatie met betrekking tot aangeleverde berichten, kan op verschillende manieren worden opgevraagd:
    1. Door het opgeven van een specifiek ‘kenmerk’, zoals ontvangen in de respons bij het aanleveren van het betreffende bericht, geeft de statusinformatieservice de statusinformatie met betrekking tot dit specifieke bericht terug.
    2. Optioneel kan door het opgeven van een ‘berichtsoort’ en eventueel een periode, een lijst met kenmerken van berichten opgevraagd worden, die onder een bepaalde berichtsoort zijn aangeleverd. Aan de hand van de ontvangen kenmerken kan vervolgens de statusinformatie, behorende bij de betreffende gegevens, worden opgevraagd volgens de methode onder punt 1.

Bouwblokken

Bouwblok Eis
Authenticatie verplicht
Beveiliging verplicht
Validatie verplicht
Autorisatie:

machtiging controleren

verplicht*

(*) verplicht indien statusinformatie niet wordt opgehaald met een zelfde certificaat als gebruikt bij aanlevering (overheid).


NPA: Bouwblokken

Zoals in de scope is aangegeven wordt ieder SBR proces opgebouwd op basis van bouwblokken. Er wordt onderscheid gemaakt tussen functionele eisen en randvoorwaardelijke voorzieningen die gebruikt worden in de SBR infrastructuur om aan de functionele eisen te voldoen.


Algemeen

Niet-Functionele eisen

  • Alle wijzigingen in een SBR infrastructuur worden op die wijze aangebracht dat het voor aangesloten partijen mogelijk blijft de bestaande functionaliteit een reële periode te blijven gebruiken alvorens over te gaan op gewijzigde functionaliteit.
  • Iedere wijziging zal, waar mogelijk, worden ingeleid door een overgangsperiode, die na consultatie in de markt (expertgroep) is vastgesteld, om partijen de tijd te geven nieuwe functionaliteit te implementeren. Tijdens de overgangsperiode wordt de oude functionaliteit ondersteund.

Functionele eisen

  • SBR informatie stromen worden system-2-system afgehandeld.
  • Interactie met een SBR-infrastructuur gebeurt middels webservices.
  • N:1:N: De SBR-infrastructuur kent zowel aan aanlever- als afleverkant meerdere koppelingen met ketenpartners.
  • 1:1:1: Ieder bericht wordt vanuit 1 partij naar 1 partij verzonden. Berichten worden niet opgesplitst, samengevoegd of naar meerdere partijen verzonden.
  • Berichtverwerking is ‘transactiegewijs’ (in tegenstelling tot batchgewijs). Ieder bericht betreft één transactie en is zodanig te herkennen.
  • Het endpoint waarop de webservice wordt aangesproken kan zowel generiek (voor meerdere berichtsoorten) als specifiek (per berichtsoort / operatie) worden ingezet.

Randvoorwaardelijke voorzieningen

  • SBR implementaties door overheidspartijen gebruiken de door Digikoppeling voorgeschreven koppelvlak standaarden: WUS voor bedrijven 2.0 versie 1.2
  • SBR implementaties door private partijen gebruiken op Digikoppeling gebaseerde koppelvlak standaarden om een zo groot mogelijke eenduidigheid naar de markt te creëren


Authenticatie

Functionele eisen

De authenticiteit van systemen in de SBR-infrastructuur en van de gebruikers van een service moet door alle deelnemende partijen vastgesteld kunnen worden voordat een datacommunicatiesessie (transportniveau) wordt gestart.

Randvoorwaardelijke voorzieningen

  • De verbinding tussen de client en de SBR-infrastructuur dient volgens het TLS/SSL-protocol met een certificaat opgezet te worden. De authenticiteit dient te worden gecontroleerd met behulp van PKIoverheid-certificaten (X.509).
  • De geldigheid van het client certificaat dient aan de hand van de gegevens in het certificaat gecontroleerd te worden. Er dient tegen een Certificate Revocation List (CRL) gecontroleerd te worden of het certificaat niet is ingetrokken.


Beveiliging

Functionele eisen

Op berichtniveau moet de integriteit van het bericht zelf vastgesteld kunnen worden (bericht is ongewijzigd tijdens transport). Hiertoe dienen aangeleverde berichten te worden ondertekend met een certificaat die voldoet aan de informatie beveiligingseisen voor het desbetreffende bericht. De ondertekening bestaat uit de met het certificaat versleutelde digest (hash van het bericht).

Randvoorwaardelijke voorzieningen

  • Zowel het aanleverbericht (request) als het retourbericht (respons) wordt ondertekend (met behulp van PKIoverheid-certificaten (X.509) met de WS-Security standaard.
  • Het bericht dient beveiligd te zijn met een handtekening over de SOAP body- en de SOAP header-elementen (die door de koppelvlakspecificaties zijn vereist), volgens het WS-Security protocol.


Autorisatie: machtiging controleren

Functionele eisen: Aanleveren

De relatie tussen de verzender van een bericht (Gebruiker) en de belanghebbende kan (optioneel, door de eigenaar van de berichtstroom bepaald) worden vastgelegd in een extern machtiging register. Bij aanlevering van een bericht dient het adres van de AuSP meegegeven te worden zodat de SBR infrastructuur de machtigings relatie kan controleren.

Randvoorwaardelijke voorzieningen: Aanleveren

• Machtigingen ten behoeve van aanlevering van SBR berichten kunnen (optioneel) worden vastgelegd bij een extern Autorisatie Service Provider, welke het register door middel van een webservice beschikbaar stelt.

Functionele eisen: Statusinformatie

De statusinformatie service controleert of de gebruiker voor elke status of kenmerk geautoriseerd is. Een gebruiker is geautoriseerd als óf

  • de statusinformatie wordt opgevraagd met hetzelfde certificaat waarmee het oorspronkelijke bericht is aangeleverd en het certificaat een PKIoverheidscertificaat is.
  • Of een externe AuSP succesvol vaststelt dat de gebruiker geautoriseerd is de statusinformatie in te zien.

Randvoorwaardelijke voorzieningen: Statusinformatie

  • Machtigingen ten behoeve van aanlevering van SBR berichten kunnen (optioneel) worden vastgelegd bij een extern Autorisatie Service Provider, welke het register door middel van een webservice beschikbaar stelt.

Functionele eisen: eMededelen

De relatie tussen de partij die een bericht ophaalt (Gebruiker) en de belanghebbende, in combinatie met de dienst waarop het betrekking heeft, dient expliciet te zijn vastgelegd in een machtiging register. Bij het ophalen van een bericht worden controles uitgevoerd ter autorisatie van de handeling:

  • Het KvK nummer in het certificaat waarmee het bericht wordt opgehaald moet identiek zijn aan het nummer dat is vastgelegd in het machtigingen register.
  • De relatie tussen het op te halen bericht (dienst / berichtsoort) en de gemachtigde wordt gecontroleerd op basis van identificerend nummer (KvK) van de gemachtigde in het certificaat.

Randvoorwaardelijke voorzieningen: eMededelen

  • Alle machtigingen ten behoeve van het ophalen van mededeling dienen te worden geregistreerd in het B2 machtigingen register.


Validatie

Functionele eisen

Ieder aangeleverd bericht (inhoud) door een gebruiker wordt gevalideerd door de SBR infrastructuur om de kwaliteit van het ingestuurde bericht te toetsen en de gebruiker direct terugkoppeling te geven over de verwerkbaarheid van het bericht. Validatie kan o.a. plaatsvinden op basis van de voorgeschreven taxonomie.

Randvoorwaardelijke voorzieningen

  • Alle XBRL berichten worden minimaal gevalideerd op:
    1. XML validatie
    2. XML schema validatie
    3. XBRL validatie

BPMN Procesplaten

Procesplaat 1: NPA Wijzigen: Input

caption

Procesplaat 2: NPA Wijzigen: Verwerken Input

caption

Procesplaat 3: NPA Wijzigen: Vrijgeven

caption

Persoonlijke instellingen
Naamruimten

Varianten
Handelingen
Navigatie
SBR Wiki's
Nederlandse Taxonomie en Architectuur
Processen en middelen
Body of Knowledge
Hulpmiddelen