Naam: Architectuur team EGEM i-teams Versie: 1.0 Datum: 22-04-2009 gebaseerde koppelingen of services Integratie-eisen en negen voorbeelden voor betere koppelingen of services
Inhoudsopgave 1. Inleiding...5 1.1. Reikwijdte...6 1.2. Leeswijzer...8 2. Proces...9 2.1. Analyse...10 2.2. Opstellen voorlopig bestek...10 2.3. Afstemming / Advies...11 2.4. Definitief maken en samenvoegen bestek...11 2.5. Aanbesteding...11 2.6. Ontwikkeling / Installatie / Configuratie...12 2.7. Levering / Integratie...12 2.8. Acceptatie / Toetsing...12 2.9. Beheer...12 3. Adviezen voor StUF bestekteksten...13 3.1. Keuze StUF koppelpatroon...13 3.2. Overzicht van de parameters...15 3.3. Specificatie Proces/Contet...18 3.4. Keuze StUF sectormodel...19 3.5. Keuze interactiepatroon...20 3.6. Keuze protocolbinding...21 3.7. Keuze van de StUF versie...22 Bijlage A. Algemene integratie-eisen aan StUF koppelingen...23 A.1. Beveiligingseisen...23 A.2. Kwaliteit...24 A.3. Volume- / prestatie-eisen...24 A.4. Eisen m.b.t. testbaarheid...24 A.5. Foutafhandelingseisen...25 A.6. Compatibiliteitseisen...25 A.7. Eisen m.b.t. overdracht aan beheerorganisatie...26 A.8. Eisen m.b.t. beheer...26 A.9. Eisen m.b.t. nazorg / onderhoud...27 A.10. Documentatie-eisen...27 A.11. Trainings- / opleidingseisen...27 A.12. StUF referentie documenten...28 A.13. Overige informatie bronnen...28 Bijlage B. Voorbeeld bestekteksten...29 Bijlage C. Leeg sjabloon StUF koppeling...47 Pagina 2
Bijlage D. Entiteittypen...48 D.1. StUF-BG...48 D.2. StUF-ZKN...50 Bijlage E. Berichtcodes...51 Bijlage F. Lijst van gehanteerde afkortingen...54 Pagina 3
Versiebeheer bestekteksten StUF Auteur: Projectteam Versterking StUF Versie Datum Toelichting 0.1 0.8 //2009 Diverse werkversies 0.9 19-03-09 Concept ter review van de leden van StUF Epert en Regiegroep en verschillende I&A medewerkers van gemeenten 1.0 22-04-2009 Uit de review ontvangen opmerkingen verwerkt. Bijdragen Onderstaande personen hebben bijgedragen aan de totstandkoming of als reviewer van dit document: Robert Melskens, EGEM i-teams Peter Klaver, EGEM i-teams (projectleider) Henri Korver, EGEM i-teams Joël van der Elst, EGEM i-teams Paul Wouters, EGEM i-teams Wilfred Burleson, EGEM i-teams Pieter Weeber, PinkRoccade Local Government Rene Kok, VROM/BAG Jos Dirksen, Atos Origin Joris Graaumans, Atos Origin Adrie van Zundert, GouwIT Cor de Rijke, Gemeente Veere Gert Hoff, Procura Maarten van den Broek, Message-Design Marianne Faro, Gemeente Leidschendam-Voorburg Peter Visser, VROM Patrick Castenmiller, Gemeente Hoorn Ruud Kathman, Waarderingskamer Tom Peelen, ICTU/OSB Pagina 4
1. Inleiding Voor opstellers van een programma van eisen of een bestek blijkt het vaak lastig om de eisen van op de StUF standaard op papier te zetten. EGEM i-teams heeft dit probleem onderkend en met dit document reiken wij u een helpende hand. Dit document heeft als doel het verhogen van de kwaliteit van programma's van eisen of bestekken op het onderdeel dat gaat over de op StUF. Met het bereiken van die doelstelling zullen ook andere doelen binnen handbereik komen, namelijk: meer eenduidige vraagstelling en beter opdrachtgeverschap richting ICT leveranciers; verlagen van de risico's ten aanzien van applicatie- integratie; efficiencyvoordelen bij het opstellen van integratie-eisen. Gebruik van deze handreiking betekent bijvoorbeeld dat koppelingen of services veel minder uitgebreid (functioneel en technisch) gespecificeerd hoeven te worden of dat een bestek veel minder overlapt met onderwerpen die reeds in de StUF standaard zijn beschreven. Het beschrijven van alleen die aspecten of onderwerpen die variabel danwel aanvullend zijn, is afdoende en geeft meer zekerheid dat koppelingen werken en conform de StUF standaard in de software zijn ingebouwd. In dit document zijn zowel de werkwijze voor het opstellen als de standaard bestekteksten met de integratie eisen beschreven. De standaard bestekteksten zijn opgedeeld in twee delen, te weten: 1. Sspecificaties die in het algemeen voor alle StUF koppelingen gelden. Deze algemene integratie-eisen zijn opgenomen in Bijlage A; 2. Specificaties van een aantal veel voorkomende en karakteristieke (StUF) patronen. Hiervoor zijn in Bijlage B negen voorbeeldteksten opgenomen die relatief snel en eenvoudig toegesneden kunnen worden op een specificatie van één StUF koppeling of service. Het toepassen van de handreiking leidt tot een set van integratie-eisen die als onderdeel opgenomen dienen te worden in een totaalbestek waarin u bijvoorbeeld ook juridische- en inkoopvoorwaarden opneemt. Dit document is primair bedoeld voor informatie-analisten, ICT architecten en integratie-adviseurs die de integratie-eisen op- en vaststellen. Kennis van de gemeentelijke informatievoorziening, informatie en ICT architectuur, applicatie-integratie en basiskennis van de StUF standaard is gewenst. Pagina 5
1.1.Reikwijdte Dit document richt zich op het opstellen van de integratie-eisen voor te leveren applicatiekoppelingen of -services die aan de StUF standaard moeten voldoen. De opgestelde integratie-eisen vormen een deel van een totaalbestek voor de selectie van (pakket)software of de te ontwikkelen software. De te leveren koppeling of service is als invalshoek gekozen. (zie figuur 1). Figuur 1. Koppeling of service als invalshoek In dit document wordt verder het begrip koppeling gebruikt voor zowel services als koppelingen. De StUF standaard is een familie die bestaat uit meerdere onderdelen die logisch met elkaar samenhangen. Door deze familiestructuur heeft StUF binnen de overheid een breed toepassingsen werkingsgebied. StUF wordt gebruikt voor het uitwisselen en opvragen van gegevens uit verschillende landelijke basisregistraties en landelijke voorzieningen, verschillende sectorale ketens en voor binnengemeentelijke integratiedoeleinden. Dit document gaat vooral in op het laatste toepassingsgebied, binnengemeentelijke integratie. Het hiervoor relevante gedeelte van de StUF standaard is in de onderstaande figuur aangegeven. Figuur 2. Het voor dit document relevante deel van de StUF familie Pagina 6
Meestal zal de leveringsomvang van een ICT voorziening of van software uit meer bestaan dan alleen koppelingen. De eisen die u stelt aan de andere benodigde functies of componenten dient u aan uw totaalbestek toe te voegen. Ditzelfde geldt voor onderwerpen zoals de te hanteren procedures, inkoopvoorwaarden, selectiecriteria, financiën en juridische voorwaarden alsmede eisen over implementatie, planning en projectleiding. Voor een volledige specificatie van gedigitaliseerde koppelingen dienen alle communicatielagen uit figuur 3 te worden ingevuld. Dit document dekt samen met de standaarden uit de StUF familie alleen de eisen af van de lagen 2 tot en met 5. De onderste laag (1) is buiten beschouwing gelaten omdat het hier gaat om de technische infrastructuur die per gemeente kan verschillen en omdat deze buiten de StUF standaard valt. Dit betekent onder andere dat de keuze tussen de protocollen 'http' en 'https' niet binnen de scope van dit document valt. De bovenste laag (5) gaat met name over de procesmatige en organisatorische samenwerkingsafspraken over gegevensuitwisseling. Deze worden deels afgedekt. Pagina 7
Figuur 3. Communicatiemodel. 1.2.Leeswijzer In hoofdstuk 2 wordt het proces voor het opstellen tot en met het gebruik van de integratie-eisen voor koppelingen beschreven. In hoofdstuk 3 staan inhoudelijke adviezen die van belang zijn bij het opstellen van integratie eisen. Het gaat om het kiezen van het koppelpatroon, een overzicht van de parameters en de daarmee gerelateerde informatie, het specificeren van de contet en het proces, de keuze van het sectormodel, de keuze van het interactiepatroon, de keuze van de protocolbinding en het kiezen van de StUF versie. In de bijlagen vindt u tenslotte de voorbeeldteksten die u kunt overnemen en waarmee u uw eigen integratie-eisen kunt samenstellen. Pagina 8
2. Proces Het proces van voorschrijven, aanbesteden, realiseren, implementeren tot en met het beheren van een op StUF gebaseerde koppeling in verhouding tot het opstellen en gebruik van een 'totaalbestek' is in onderstaande figuur schematisch weergegeven. Figuur 4. Procesmodel Pagina 9
Het procesmodel toont hoe een opgesteld bestek ook van invloed is en gebruikt wordt in de daaropvolgende processtappen. Hieronder lopen we de stappen kort door. 2.1.Analyse In de eerste processtap wordt een analyse gemaakt van de huidige situatie versus de gewenste situatie van de informatie voorziening. Wat wilt u precies en welke wijzigingen moeten daarin worden gerealiseerd om de gewenste situatie te bereiken? In deze stap bepaalt u dus welke (bestaande en nieuwe) systemen met elkaar gekoppeld moeten worden, hoe de functionaliteit van die koppelingen eruit ziet en welke aanvullende eisen u daaraan stelt. De keuze wordt mede beïnvloed door uw eigen ambitie en door de geplande opleverdatum. De input voor deze stap wordt dan ook gevormd door: uw ICT strategie, ambitie en architectuur (bijv. volgt u een pakket of maatwerkbenadering?); de legitimatie en de eisen en wensen vanuit de bedrijfsvoering om de gewenste situatie te realiseren; de huidige situatie van het applicatielandschap waarbinnen de koppeling(en) / service(s) gerealiseerd moet(en) worden; de door uw organisatie gewenste planning waarbinnen de koppeling(en) / service(s) gerealiseerd moet(en) zijn; het beschikbare budget voor investering en eploitatiekosten. 2.2.Opstellen voorlopig bestek Op basis van de uitkomsten van de eerste processtap wordt een voorlopige versie van het bestek samengesteld worden. Hiervoor neemt u de algemene eisen over uit bijlage A en wijzigt deze naar uw eigen situatie, eisen en wensen. Vervolgens kiest u voor elke gewenste koppeling het meest overeenkomstige StUF koppelpatroon. In paragraaf 3.1 is dit nader toegelicht. Voor elke benodigde koppeling neemt u de bijbehorende voorbeeld-bestektekst over uit bijlage B. De overgenomen voorbeeld-bestekteksten vult u aan en wijzigt u afhankelijk van uw eigen situatie, eisen en wensen. Voor de keuzes die u moet maken kunt u gebruik maken van: het overzicht van de parameters in 3.2; een toelichting m.b.t. het specificeren van het Proces en de Contet in 3.3. het kiezen van een StUF sectormodel en informatie objecten in 3.4. de toelichting op het kiezen van de interactiepatronen in 3.5; een toelichting bij het kiezen van de protocolbindingen in 3.6; een toelichting op het kiezen van de StUF versie in 3.7. Pagina 10
Deze stap resulteert in een voorlopig bestek met integratie-eisen dat gebruikt wordt in het vervolgtraject. 2.3.Afstemming / Ad vies In deze stap vindt afstemming plaats tussen u en de koppelpartijen. De koppelpartijen zijn de eigenaren van het systeem of systemen waaraan gekoppeld gaat worden of de leverancier(s) daarvan. Het voorlopige bestek met de integratie-eisen is het vertrekpunt. Zo nodig wordt advies ingewonnen en/of vindt een marktverkenning plaats om te onderzoeken in hoeverre en op welke termijn de gevraagde software beschikbaar is. Hierin wordt ook de keuze van de StUF versie meegenomen. Het advies en onderzoek kunt u gebruiken om de voorlopige keuzes aan te scherpen en/of uw eisen bij te stellen. 2.4.Definitief maken en samenvoegen bestek Nu het beeld van de te realiseren oplossing helder is en het voorlopige bestek afgestemd is met betrokken koppelpartijen kunt u het definitief toesnijden op de gewenste situatie. De inhoud van de StUF parameters wordt definitief vastgesteld. Zonodig kunt u weer gebruik maken van de adviezen in hoofdstuk 3. Het resultaat bestaat uit: uw algemene integratie-eisen, van toepassing op alle gewenste koppelingen; uw bestekteksten voor alle gewenste koppelingen. Tenslotte worden deze twee resultaten in het totaalbestek opgenomen. 2.5.Aa nbesteding Aanbesteding van een ontwikkel- of pakketimplementatietraject gebeurt op basis van het in de vorige stap vervaardigde totaalbestek. Op basis hiervan kunnen leveranciers een aanbieding en/of offerte uitbrengen. Toetsing van de aanbieding en/of offerte moet plaatsvinden tegen het totaalbestek. Uw totaalbestek is de graadmeter bij het beoordelen van de bij de koppelingen voorgestelde oplossing. Uiteindelijk zal dit alles tot een contract met de leverancier leiden waarin het totaalbestek verankerd moet worden. Hierdoor wordt duidelijk waaraan elk product getoetst moet worden. EGEM i-teams adviseert om bij het aangaan van het contract per koppeling alle bij die koppeling betrokken leveranciers een formeel akkoord te laten geven op de gespecificeerde koppelvlakken. Ook de leverancier van het systeem waaraan gekoppeld wordt, dient te accorderen. Pagina 11
2.6.Ontwikkeling / Installatie / Configuratie In uw bestek is gespecificeerd wat u van de te realiseren oplossing verwacht. Na aanbesteding kan de leverancier aan de slag om de software te ontwikkelen danwel de pakketsoftware te configureren en in te richten. Ook hiervoor biedt uw bestek nog steeds de rode draad, al maakt het inmiddels deel uit van het contract. In de te realiseren oplossing moeten alle in het contract, en in het bestek, genoemde punten afgedekt worden. 2.7.Levering / Integratie De levering of integratie van de oplossing gebeurt conform het contract. 2.8.Acceptatie / Toetsing In de acceptatie / toetsing stap bent u weer aan de beurt. Het contract, waarvan het bestek een onderdeel is, dient in deze processtap als toetsingskader voor de acceptatie van koppeling(en). Hebben de leverancier en de betrokken koppelpartijen inderdaad dat opgeleverd wat u gevraagd heeft, functioneren alle koppelingen? EGEM i-teams is van plan om een geautomatiseerde compliancy- en testvoorziening te realiseren. Met zo'n voorziening kunnen StUF koppelingen in software vooraf deels getest en getoetst worden. Zodra deze voorziening beschikbaar is, kan het overleggen van een 'keurmerk' door de betreffende leverancier onderdeel uitmaken van de acceptatie. 2.9.Beheer Eenmaal opgeleverd, geaccepteerd en in gebruik genomen zal de oplossing door een beheerorganisatie in beheer genomen worden. In het bestek staan diverse proces-parameters die juist voor de beheer-fase van belang zijn. Denk daarbij o.a. aan performance en beschikbaarheid. Ook hier vormt het contract, en dus het bestek, de basis voor afspraken m.b.t. de service-niveaus. Pagina 12
3. Adviezen voor StUF bestekteksten 3.1.Keuze StUF koppelpatroon Aangezien het ondoenlijk is om alle mogelijke koppelingen apart te beschrijven is er voor gekozen om een aantal voorbeeld-bestekteksten op te nemen van koppelingen (zie tabel 3.1.). De gekozen voorbeelden zijn veel voorkomende en karakteristieke koppelpatronen. Bij het opstellen van het voorlopige bestek gaat het er om dat u de meest op uw situatie gelijkende koppelpatronen uit de onderstaande tabel kiest. De criteria die daarbij het meest van belang zijn, zijn: de positionering in de GEMMA applicatie architectuur (zie figuur 5.). De codes A t/m I in de onderstaande tabel corresponderen met dezelfde codes in figuur 5.; De richting van het berichtenverkeer (FO à MO, BO à MO, etc...), incl. de omschrijving van het patroon. Tabel 3.1.: StUF koppelpatronen StUF Koppelpatroon en Functionaliteit A B C D E FO à MO: Registratie sterfgeval Opvragen van persoonsgegevens van 1 persoon t.b.v. prefill (registreren van een sterfgeval). Relatie naar de StUF standaard StUF Interactie Sectormodel patroon BG0310: Personen en Adressen FO à MO: Doorgeven binnengemeentelijke verhuizing Opvragen gezinsgegevens t.b.v. prefill (doorgeven van een verhuizing). FO à MO: WOZ waardebepaling Leveren van in een FO-applicatie ingevulde gegevens t.b.v. WOZ waardebepaling. FO à MO: Aanvragen uittreksel GBA Leveren van ingevulde e-form gegevens t.b.v. Het aanvragen van een uittreksel GBA. BO à MO: Opsporing fraude Opvragen persoonsgegevens met historie van meerdere personen door een Fraude Opsporingssysteem (Sociale dienst). BG0310: Personen, Adressen BG0310: WOZ- Object BG0310: Personen en Adressen BG0310: Personen en Adressen synchroon synchroon synchroon asynchroon asynchroon Protocolbinding SOAP/WSDL SOAP/WSDL SOAP/WSDL ebms SOAP/WSDL i.c.m. Bestand Pagina 13
F G H I BO à BO: Persoonsgegevens voor uitkeringssysteem Binnengemeentelijke GBA levert BG0310: Personen persoonsgegevens aan een en Adressen uitkeringssysteem (Sociale dienst). BO à BO: Persoonsgegevens voor verkiezingssysteem Binnengemeentelijke GBA levert BG0310: Personen eenmalig persoonsgegevens aan een en Adressen verkiezingssysteem (Sociale dienst). LV à MO: NAW-gegevens voor PIP Opvragen van NAW-gegevens door een PIP bij een gemeentelijk gegevensmagazijn. BG0310: Personen en Adressen asynchroon asynchroon synchroon SOAP/WSDL Bestand OSB-WUSlite LV à MO: Statusgegevens binnengemeentelijke verhuizing voor PIP Opvragen van statusgegevens door een PIP bij een zakenmagazijn m.b.t. een binnengemeentelijke verhuizing. ZKN0300 synchroon OSB-WUS Na het maken van de keuze kunt u uit bijlage B de gerelateerde patronen kopiëren naar uw eigen bestek. Het document dat u dan tot uw beschikking hebt kunt u gebruiken om de ideeën die u heeft omtrent de te realiseren koppeling te bespreken in de volgende stap (afstemming / advies) Pagina 14
In de onderstaande illustratie zijn de koppelpatronen in het GEMMA architectuur-model gepositioneerd Figuur 5. Positionering gekozen patronen binnen GEMMA applicatie architectuur 3.2.Overzicht van de parameters Voor elk van deze patronen is een voorbeeld bestektekst opgenomen in de Bijlage B. Het beschrijven van deze patronen gebeurt aan de hand van de parameters die zijn gekozen op basis van het communicatiemodel (zie figuur 3). De patronen zelf beschouwen we overigens als één van de parameters ('Proces/Contet'), deze weerspiegelt laag 1 de bedrijfsproces-laag, van het communicatiemodel. De parameters Informatie, Interactiepatroon en Protocol weerspiegelen respectievelijk laag 4, 3 en 2 van de lagen uit het communicatiemodel. In de onderstaande figuur ziet u de parameters terug als kind van Koppeling / Service. Tevens is aangegeven met welke laag in het communicatiemodel de parameters overeenkomen. Pagina 15
Figuur 6. Parameter Structuur voor toepassing StUF standaard De parameter Technische infrastructuur komt niet terug in de bestekteksten. Deze parameter is namelijk een weerspiegeling van de Datacommunicatievoorziening laag waarover reeds opgemerkt is dat deze buiten beschouwing gelaten wordt. In de onderstaande tabel vindt u per parameter alle mogelijke informatiecomponenten. Tabel 3.2.: Toelichting parameters Proces/contet Contet beschrijving Geeft een korte beschrijving van de koppeling. Tevens worden de applicaties aan weerszijden van de koppeling benoemd. Fleibiliteitseisen Hierbij worden eventuele configureerbare parameters beschreven waarmee de functionaliteit van de koppeling beïnvloed kan worden. Precondities Beschrijft de voorwaarden waaraan voldaan moet worden voordat een koppeling werkt. Functionaliteit Beschrijft de functionaliteit die door de koppeling ingevuld moet worden. Pagina 16
Informatie (sectormodel) Serviceniveau Eenmaal in gebruik zal de service aan voorwaarden moeten voldoen. Denk hierbij aan volumes, responstijden en beschikbaarheid. Beveiliging (aanvullend) Etra eisen m.b.t. Beveiliging. StUF-Configuratieschema De koppeling wordt gerealiseerd met het oog op de overdracht van informatie. De identificatie van de informatie gebeurt o.a. met een configuratieschema waarmee in feite de set van te gebruiken XML- Schema's wordt aangeduid. Deelset van het sectormodel Het configuratieschema geeft niet eact aan welke informatiecomponenten gebruikt worden, daarom wordt daar hier nog eens specifiek op in gegaan. Indien daar binnen de te realiseren koppeling behoefte aan is worden hier ook de te gebruiken etra StUF elementen aangegeven. Interactiepatroon Koppelingstype Geeft aan of een koppeling synchroon of asynchroon is. Berichtuitwisselingspatroon Geeft aan om wat voor type bericht het gaat. bijv. Vraag/Antwoord of Kennisgeving. Interactiediagram Met behulp van een UML-interactiediagram wordt de gewenste interactie gevisualiseerd. Protocolbinding Communicatieprotocol Geeft het te gebruiken communicatieprotocol aan (zie figuur 6.). Pagina 17
3.3.Specificatie Proces/Contet In een bestek moet het proces waarvan de te realiseren koppeling deel uitmaakt en de contet waarbinnen dit proces zich zal gaan afspelen duidelijk zijn. Geef daarvoor met betrekking tot de volgende punten een korte beschrijving: 1. Contet beschrijving Dit bevat de legitimatie waarom en waarvoor de koppeling noodzakelijk is. Dit onderdeel is tevens een grove schets van de koppeling waarin voor elke te koppelen applicatie wordt aangegeven of het gaat om een nieuwe of bestaande situatie. Tevens bevat dit de naam en versie van de applicatie en een indicatie of het gaat om de bron danwel de afnemer van de informatie. 2. Fleibiliteitseisen Sommige koppelingen moeten aan hogere fleibiliteitseisen voldoen, denk daarbij aan veranderende toekomstige wensen. De koppeling moet in dat geval configureerbaar zijn. De hier vermelde eisen zijn met name van belang voor datadistributie, middleware en integratie voorzieningen. 3. Precondities Indien nodig kunt u hier voorwaarden opnemen waaraan moet worden voldaan voordat een koppeling kan functioneren. Het kan daarbij bijv. gaan om processen die vooraf moeten hebben gedraaid of om informatie waarover beschikt moet kunnen worden. 4. Functionaliteit De koppeling vervult zelf een functie binnen de totale applicatie. Hier geeft u aan wat een koppeling moet doen, welke informatieobjecten daarbij een rol spelen en hoe deze informatieobjecten vervolgens verwerkt worden. Bij informatieobjecten moet u dan bijv. denken aan personen, adressen, een vergunningsaanvraag of zelfs een combinatie van objecten; 5. Serviceniveau Zodra de applicatie waarvan de koppeling deel uitmaakt in gebruik wordt genomen zal de koppeling aan serviceniveau eisen moeten voldoen. Dit zijn bijvoorbeeld: de hoeveelheid berichten per tijdseenheid die minimaal over de koppeling verzonden kunnen worden; de omvang van de berichten die de koppeling minimaal aan moet kunnen; de responstijd; eventueel eisen m.b.t. de actualiteit van de brongegevens die u wil ontvangen; de beschikbaarheid van de koppeling. Bijvoorbeeld '7 24' uur indien de koppeling voor diensten op het internet wordt gebruikt of 'kantooruren' indien alleen in die periode van de dienst gebruik wordt gemaakt. 6. Beveiliging (aanvullend) Eisen met betrekking tot beveiliging die voor een specifieke koppeling van belang zijn. Pagina 18
3.4.Keuze StUF sectormodel De StUF familie bestaat uit onderdelen die met elkaar samenhangen: een generieke onderlaag en horizontale en verticale sectormodellen. StUF onderdelen in de StUF familie zijn onderling afhankelijk, bovenliggende StUF onderdelen zijn gebaseerd op onderliggende StUF onderdelen (zie figuur 7). Figuur 7. StUF familie De generieke onderlaag is de algemene en sectoronafhankelijke basislaag van StUF met generieke functionaliteit van berichtenuitwisseling en met de aansluiting op protocollen voor transport en logistiek zoals de protocollen voor de OverheidsServiceBus. De sectormodellen bevatten de berichtdefinities en informatieobjecten (of entiteittypen) die uitgewisseld kunnen worden. De horizontale sectormodellen specificeren berichtdefinities en entiteittypen met een sectoroverschrijdend karakter terwijl de verticale sectormodellen dit juist doen voor een specifieke sector Het gaat daarbij om: XML Schema Definitions (XSD bestanden) met daarin de berichtschema s en de daarbij horende gegevenselementen; WSDL-bestanden met daarin de operaties en de te gebruiken berichtschema s In het bestek moet u aangeven welke StUF sectormodellen en welke entiteittypen binnen die sectormodellen u nodig heeft. Het kiezen van die StUF sectormodellen en daarbinnen de entiteittypen kunt u met behulp van de volgende stappen doen: 1. Aan de hand van de in de voorgaande paragraaf bepaalde informatieobjecten bepaalt u nu de StUF sectormodellen waarbinnen deze informatieobjecten te vinden zijn. Zie bijlage D voor Pagina 19
een lijst met entiteittypen per sectormodel. Hiermee bepaalt u tevens de basisvorm van het StUF configuratieschema, dat wil zeggen zonder versienummer; 2. Stel de deelverzameling van de entiteiten in de StUF sectormodellen op. Bepaal dus welke StUF entiteittypen inclusief de relatie-entiteiten die over de koppeling verzonden moeten worden; 3. Bepaal de eventuele etra benodigde StUF elementen ('etraelement'). 3.5.Keuze interactiepatroon Bij de keuze van het koppelingstype en berichtuitwisselingspatroon kunt u gebruik maken van de volgende tabel Tabel 3.3.: Keuze interactiepatroon Bevraging Transactie Onmiddellijk 1. Onmiddellijke businessbevraging 3. Onmiddellijke businesstransactie Uitgesteld 2. Businessbevraging met uitstel 4. Businesstransactie met uitstel Bepaal eerst of de door u gewenste businessinteractie direct moet plaatsvinden of uitgesteld mag plaatsvinden. In dat laatste geval hoeft niet direct over het resultaat van de interactie beschikt te kunnen worden. Interacties waarbij sprake is van een directe menselijke behoefte of waarbij de actualiteitswaarde van de gegevens hoog is zullen bijvoorbeeld vaak niet uitgesteld plaats mogen vinden. Daarna dient u te bepalen of het bij de gewenste interactie dient te gaan om een bevraging of om een transactie. Interacties waarbij het de bedoeling is dat de verzonden gegevens opgeslagen moeten worden in een gegevensbank zijn over het algemeen transacties. Aan de hand van deze keuzes bepaalt u welk kwadrant voor u van toepassing is. Is kwadrant 1 van toepassing dan hebt u te maken met een synchrone vraag/antwoord interactie; Kwadrant 2 staat voor een asynchrone vraag/antwoord interactie; Kwadrant 3 voor een synchrone kennisgeving interactie; Kwadrant 4 staat voor een asynchrone kennisgeving interactie. Indien nodig kunt u nu het interactiepatroon in uw bestektekst wijzigen. Vergeet niet om eventueel ook het interactie diagram te wijzigen. Zo mogelijk en bekend voegt u berichtcodes aan het interactie diagram toe (zie Bijlage E). Pagina 20
3.6.Keuze protocolbinding Bij gemeentelijke berichtuitwisseling kan onderscheid gemaakt worden in berichtuitwisseling tussen gemeenten en andere overheidsorganen en in berichtuitwisseling binnen de gemeente. Gemeenten en andere overheidsorganen In de communicatie tussen gemeenten en andere overheidsorganen zal gebruik gemaakt worden van de OverheidsServiceBus (OSB). De OSB onderkent twee vormen van berichtuitwisseling: Het raadplegen van gegevens over een verbinding zonder betrouwbare en gegarandeerde overdracht. De koppelvlakstandaard hiervoor is OSB WUS en wordt veel gebruikt voor bevragingen; Het gegarandeerd overdragen van een bericht. De koppelvlakstandaard hiervoor is OSB ebms. OSB ebms wordt veelal gebruikt voor het door de zender van een bericht laten doorvoeren van een transactie bij de ontvanger van een bericht; Wat StUF 3.10 betreft is de keuze van de protocolbinding al voor u gemaakt. In het document 'Protocolbindingen' ([13]) is per berichtcode aangegeven van welke protocolbinding gebruik gemaakt dient te worden. In de onderstaande tabel vindt u de mapping terug. Tabel 3.4: Keuze protocolbinding StUF Berichtcode Di01/Du01 Di02/Du02 LvN/LaN Lk0n OSB Profiel OSB ebms OSB ebms of OSB WUS OSB WUS (N oneven) OSB ebms (N even) OSB ebms Zie Bijlage E. voor een verklaring van de berichtcodes. Voor zowel WUS als ebms geldt dat er zware eisen gesteld worden aan de applicatieinfrastructuur. Mocht de infrastructuur van uw organisatie niet geschikt zijn dan kunt u ervoor kiezen gebruik te maken van de OSB-Gateway. Een andere broker/esb is echter ook toegestaan. Bij de OSB-Gateway kunt u gebruik maken van WUS-lite of OSB-JMS. Welke keuze u maakt is afhankelijk van de ondersteuning in uw eigen applicatie ontwikkelomgeving en organisatiespecifieke voorkeuren (bijvoorbeeld op basis van kennis). Meer informatie over de OSB kunt u vinden in de OSB architectuur 1.0 [9]. Pagina 21
Binnengemeentelijk Ook in de binnengemeentelijke communicatie kan tabel 3.4. enig houvast bieden. Daar waar OSB-WUS staat is SOAP/WSDL van toepassing, waar OSB-ebMS staat is ebms van toepassing. Omdat bij binnengemeentelijke communicatie vaak geen gebruik wordt gemaakt van het internet wordt echter veelal SOAP/WSDL gebruikt. Betrouwbaarheid is in dat geval immers van minder belang. Tenslotte heeft u natuurlijk ook de mogelijkheid om te communiceren via andere protocollen of zelfs bestanden. De drijfveer voor de keuze van het communiceren middels bestanden is vaak de hoeveelheid aan gegevens en het niet direct nodig hebben van de resultaten. 3.7.Keuze van de StUF versie Voor gebruik van StUF binnen de eigen informatievoorziening zal u bij de keuze van een versie van een StUF onderdeel rekening houden met een aantal criteria. Daarbij zijn uw eigen ambitie, de doelstellingen, de ICT strategie, het budget, de ketenafspraken en de lifecycleplanning van het applicatieportfolio van belang. Echter ook de beschikbaarheid van (standaard)software, de status van de benodigde onderdelen van de StUF standaard en de opgestelde eisen. Welk criterium uiteindelijk de doorslag geeft zal van geval tot geval verschillen. EGEM i-teams adviseert u: bij pakketsoftware de laatste vastgelegde StUF versie in te brengen binnen de betreffende gebruikersvereniging, zodat dit in de pakketsoftware meegenomen wordt, en rekening te houden met de planning van de pakketontwikkeling; indien u zelf de regie voert over de eigen applicatieportfolio, de meest recent vastgestelde StUF versie voor te schrijven voor nieuwe software en bij vervanging of upgrading van bestaande koppelingen deze mee te nemen in de onderhoudsplanning. Het zal niet altijd mogelijk zijn aan deze eis vast te houden omdat u ook te maken hebt met applicaties met andere StUF versies. daar waar de leverancier niet beschikt over een onderhoudsplanning eisen te stellen aan de releaseplanning en afspraken te maken over het upgraden naar een nieuwe StUF versie. in uw bestek op te nemen dat applicaties die gericht zijn op integratie (zoals middleware, brokers, servicebus en distributiesystemen) van alle relevante StUF configuraties ten minste twee opeenvolgende versies tegelijkertijd dienen te ondersteunen. Dit is inclusief eventuele vertaalfunctionaliteit in twee richtingen en heeft als doel etra fleibiliteit te creëren. Zodra u een keuze hebt gemaakt voor een bepaalde versie van StUF dan kunt u het configuratieschema dat u in paragraaf 3.4 hebt samengesteld afronden. Pagina 22
Bijlage A. Algemene integratie-eisen aan StUF koppelingen In het algemeen geldt dat een koppeling dient te voldoen aan alle eisen die voortvloeien uit de formeel vastgestelde en gepubliceerde StUF documenten die zijn vermeld in paragraaf A.12 tenzij anders is aangegeven. Bij opmerkingen tussen vishaken <...> is het de bedoeling dat de opsteller van het bestek informatie aanvult, wijzigt of verwijdert naar behoefte. A.1.Beveiligingseisen De eisen die gesteld worden aan de betrouwbaarheid, integriteit en eclusiviteit van het berichtenverkeer zijn hoog, met name omdat er sprake kan zijn van privacy-gevoelige gegevens (zoals de persoonsgegevens). Zeker bij communicatie over het internet zijn deze eisen van belang. Met betrekking tot status-updates is weer een ander aspect van belang, namelijk de rechtszekerheid. Gedurende <> tijd dient achterhaald te kunnen worden op basis van welk bericht een wijziging in een registratie is doorgevoerd. <aanvullen> 1. Authenticatie Authenticatie dient door het ontvangende systeem plaats te vinden. Het ontvangende systeem dient de identiteit van het zendende systeem te authenticeren. 2. Autorisatie Autorisatie dient op medewerker/applicatie/systeem niveau door het zendende systeem plaats te vinden. Autorisatie dient op organisatie niveau door het ontvangende systeem plaats te vinden. Op basis van de gegevens organisatie/applicatie</administratie></gebruiker> van het zendende systeem dient het ontvangende systeem te bepalen of de gevraagde service / koppeling door het zendende systeem mag worden gebruikt. <OSB: Het is de verantwoordelijkheid van het zendende systeem dat de service / koppeling daadwerkelijk wordt gebruikt voor een gespecificeerde combinatie van applicatie/administratie/ gebruiker.> <Binnengemeentelijk: PKI-certificaten dienen te worden gekoppeld aan fijnmazige combinaties van organisatie/applicatie/administratie/gebruiker, zodat het ontvangende systeem beter in staat om te zender te authenticeren.> 3. PKI-certificaat <Een PKI-certificaat is niet noodzakelijk.> Pagina 23
<Het zendende systeem dient te beschikken over een geldig PKI-certificaat zodat het ontvangende systeem de identiteit van het zendende systeem kan vaststellen.> <Het ontvangende en het systeem dient te beschikken over een geldig PKI-certificaat zodat het de berichten kan encrypten.> <OSB: De voorschriften van het OSB dienen gevolgd te worden.> <Binnengemeentelijk: Certificaten dienen op het niveau van administratie te worden toegepast.> <aanvullen> 4. Encryptie van berichtenverkeer <aanvullen> A.2.Kwaliteit Essentiële voorwaarde voor het succesvol kunnen uitwisselen van gegevens is de garantie van de kwaliteit van de gegevens. De afnemer moet daar blindelings op kunnen vertrouwen. Dit betekent dat per gegeven ook de kwaliteit van dat gegeven moet worden bewaakt. In de beschrijving van de StUF standaard [1] en [3] zijn reeds enkele eisen m.b.t. de kwaliteit opgenomen. Naast deze eisen gelden ook de volgende eisen: 1. Authenticiteit (bijv. bron is vastgesteld); 2. Actualiteit (bijv. gegevens zijn vigerend); 3. <aanvullen> A.3.Volume- / prestatie-eisen De leverancier dient de bij de services vermelde eisen te garanderen m.b.t.: 1. Volumes; 2. Responstijden; 3. Beschikbaarheid; 4. Schaalbaarheid De koppeling moet aan een hogere of lagere load aangepast kunnen worden (up- & downscaling). 5. <aanvullen> A.4.Eisen m.b.t. testbaarheid 1. De software ondersteunt het testen van berichtenverkeer en koppeling. De software ondersteunt daarvoor tenminste: het kunnen simuleren van het berichtenverkeer; wat betekent dat in de acceptatieomgeving voorzieningen aangebracht moeten kunnen worden om de gehele of minimaal het relevante gedeelte van de interactie te kunnen testen; het opslaan van inkomend/uitgaand berichtenverkeer; het raadplegen van de opgeslagen in- en uitgaande berichten in een voor mensen goed leesbare vorm. Pagina 24
2. Testomgeving / infrastructuur Het moet mogelijk zijn om eenvoudig een testomgeving in te richten. 3. Testplan De leverancier stelt een testplan op inclusief testscenario's en testscripts. Het testplan wordt voraf ter goedkeuring aangeboden aan de opdrachtgever. Het testplan moet inzicht geven in de dekkingsgraad van de toegepaste testgevallen. De uit te voeren testen dienen in duidelijke scenario s verwoord te worden. 4. Testdata De testdata dienen de opgestelde testscenario s te ondersteunen. 5. Acceptatie De leverancier zorgt voor een bedrijfsklare oplevering van de software inclusief de bijbehorende documentatie en dienstverlening. De opdrachtgever toetst het opgeleverde aan de gestelde eisen. <aanvullen met acceptatie eisen> A.5.Foutafhandelingseisen 1. Herstelbaarheid Berichten moeten getraceerd, aangepast & opnieuw aangeboden kunnen worden. Daarbij moet dan gedacht worden aan: het herstellen van koppelingen; Het detecteren van dubbele en foute berichten conform de StUF onderlaag; Het loggen van foute berichten; <aanvullen> 2. Doorlooptijden Technisch beheer moet binnen <n> uur fouten kunnen detecteren en herstellen. Bij voorkomende fouten dient technisch beheer d..m.v. een bericht op de hoogte gesteld te worden. 3. Resilience Voor de berichtentypes <noemen> moet de koppelingssoftware de berichten tijdelijk bewaren als de afnemende applicatie niet beschikbaar is door een storing. A.6.Compatibiliteitseisen Integratieapplicaties Om migraties te vereenvoudigen dienen applicaties die gericht zijn op integratie ten minste de twee opeenvolgende (vastgestelde) StUF configuraties gelijktijdig te ondersteunen. Dit geldt voor applicaties zoals middleware, brokers, servicebus en distributiesystemen. Dit soort applicaties levert meestal koppelingen aan meerdere afnemende applicaties. Deze integratie applicaties dienen zowel de laatste als de voorlaatste StUF versie met de status 'In gebruik' te ondersteunen. Pagina 25
Overige applicaties Alle overige applicaties dienen minimaal de voorlaatste StUF versie met de status 'In gebruik' te ondersteunen. Daarnaast dient de leverancier van dit soort applicaties binnen 3 maanden na vaststelling van een nieuwe StUF versie aan te geven wanneer de software aangepast is. A.7.Eisen m.b.t. overdracht aan beheerorganisatie Na acceptatie door de gemeente zal het systeem door de leveranciers worden overgedragen aan. 1. <Informatiemanagement> 2. <Functioneel beheer> 3. <Applicatiebeheer> 4. <Technisch beheer> <wat moet de leverancier doen?> A.8.Eisen m.b.t. beheer 1. Het functioneel en technisch applicatiebeheer dient zelfstandig door één (of meerdere) medewerker(s) uitgevoerd te kunnen worden. Deze rollen dienen middels autorisatie toegekend kunnen worden. 2. De functioneel applicatiebeheerder moet de mogelijkheid hebben om zelfstandig het beheer te voeren over: de parameterinstellingen; de authenticatie van de zendende partij; <de contet afhankelijke helpteksten.> 3. De functioneel applicatiebeheerder moet zelf autorisatiebeheer kunnen regelen en op eenvoudige wijze per onderdeel en per gebruiker kunnen autoriseren. 4. De technisch applicatiebeheerder moet: de kwaliteit van de gegevens kunnen monitoren (consistency checks) <beschrijf wat je onder kwaliteit verstaat> <welke gegevens moeten gemonitord worden?> <waar moeten de gegevens aan voldoen?>; de systeemprestaties kunnen monitoren (performance, volumes, beschikbaarheid, etc.); zelfstandig back-up gegevens kunnen terugzetten; 5. De leverancier dient voldoende consultancy/epertise beschikbaar te hebben om op aanvraag ondersteuning te bieden op het gebied van applicatiebeheer. Dit houdt bijvoorbeeld in dat: de reactietijd korter is dan <n uur/dagen>; <aanvullen>; 6. De leverancier moet beschikken over een interactief meldingenregistratiesysteem waar vragen/problemen/bugs aangemeld kunnen worden. Met behulp van dit systeem moet de Pagina 26
leverancier de klant op de hoogte houden over de oplossing van het probleem. Problemen die niet direct opgelost kunnen worden, moeten ingepland worden voor een bugfi/nieuwe release. A.9.Eisen m.b.t. nazorg / onderhoud De leverancier dient zich te conformeren naar het releasebeleid zoals beschreven in het beheermodel [6]. 1. Leverancier dient te garanderen dat aanpassingen in het systeem naar aanleiding van wetswijzigingen, jurisprudentie en andere nieuwe ontwikkelingen tijdig worden aangebracht als onderdeel van het onderhoudscontract. 2. Updates voor aanvulling en verbeteringen van fouten van de applicatie maken deel uit van het onderhoudscontract. 3. <aanvullen> A.10.Documentatie-eisen 1. De leverancier levert voorafgaand aan de installatie en ingebruikname van de software de volgende documentatie: Op detailniveau alle aanvullingen of verscherpingen van de genoemde StUF standaarden (bijv. de bij de StUF community aangemelde etra elementen). Documentatie voor technisch beheer t.b.v. Installatie van de software (her)starten van de software Uit te voeren technisch beheer <aanvullen> Documentatie voor functioneel beheer Documentatie van de geconfigureerde koppelingen Functionele documentatie Technische documentatie voor het aansluiten van nieuwe koppelingen en het wijzigen van bestaande. StUF configuratieschema s 2. Helpbestanden en documentatie wordt up-to-date gehouden met nieuwe releases van de applicatie. 3. <aanvullen> A.11.Trainings- / opleidingseisen <Zelf naar wens in te vullen> Pagina 27
A.12.StUF referentie documenten [1] Standaard Uitwisseling Formaat - StUF 02.04: In Gebruik (03-04-2006) - http://www.egem-iteams.nl/system/files/stuf_204.pdf [2] Sectormodel StUF-BG: Berichtdefinities, 2.04: In Gebruik (23-01-2007) - http://www.egem-iteams.nl/system/files/stuf_bg+_204.pdf [3] Standaard Uitwisseling Formaat - StUF 03.01: In Gebruik (6-1-2009) - http://www.egem-iteams.nl/system/files/... [4] Sectormodel StUF-BG: Berichtdefinities, 3.10: In Ontwikkeling (--2009) - http://www.egem-iteams.nl/system/files/... [5] Sectormodel StUF-Zaken, 3.: In Ontwikkeling (--2009) - http://www.egem-iteams.nl/system/files/... [6] Beheermodel en releasebeleid - StUF standaarden, 1.0 (22-10-2008) - http://www.egem-iteams.nl/system/files/stuf+beheermodel+en+releasebeleid.pdf A.13.Overige informatie bronnen [7] Web Services Description Language (WSDL) 1.1 - http://www.w3.org/tr/wsdl [8] Simple Object Access Protocol (SOAP) - http://www.w3.org/tr/soap [9] OSB Architectuur 1.0 - http://www.overheidsservicebus.nl/documentatie/algemeen [10] OSB-WUS (0.92, 1.0 of 1.1) - http://www.overheidsservicebus.nl/documentatie/algemeen [11] OSB-ebMS (0.93, 1.0 of 1.1) - http://www.overheidsservicebus.nl/documentatie/algemeen [12] OSB-WUS-lite - http://... [13] Protocolbindingen - http://... [14] Gebruik en achtergrond certificaten - http://www.overheidsservicebus.nl/documentatie/algemeen Pagina 28
Bijlage B. Voorbeeld bestekteksten In deze bijlage vindt u een overzicht van een aantal karakteristieke en veelvoorkomende patronen. Bij de patronen zijn een aantal voorbeeld bestekteksten gegeven die u kunt gebruiken als basis voor uw eigen bestekteksten. Ook in deze bijlage geldt dat bij opmerkingen tussen vishaken de opsteller van het bestek etra teksten kan aanvullen met eigen eisen en wensen en eisen. A. FO MO: Aangifte overlijden Opvragen van persoonsgegevens van 1 persoon t.b.v. prefill (registreren van een sterfgeval) synchroon Contet De koppeling ondersteunt het voorinvullen van de bekende persoonsgegevens van één persoon uit de MO (B) in de FO applicatie (A) waarmee een begrafenisondernemer een sterfgeval kan registreren. A (Nieuw) <Applicatie naam> <Versie> (Bestaand) B <Applicatie naam> <Versie> Proces Preconditie Naam, adres en woonplaats van de overleden persoon is bekend.. 1. Functionaliteit: M.b.v. de koppeling worden gegevens opgehaald bij applicatie B. Daarvoor worden door de applicatie A id's m.b.t. de identificatie van de gewenste gegevens verstuurd waarna applicatie B de gewenste gegevens terugstuurt. 2. Service niveau: Volumes Omvang van de berichten: <grootte> (gemiddeld) Aantal berichten per koppeling: <aantal per tijdseenheid> Responstijden Maimale doorlooptijd van het bericht in de koppeling van <n> seconde Actualiteit <Eisen aan de actualiteit van de te leveren brongegevens> Pagina 29
Informatie (sectormodel) Beschikbaarheid 7 24 uur. 3. Beveiliging <Evt. contet specifieke beveiligingseisen> Configuratieschema: StUF-BG (3.10) StUF (3.01) Interactiepatroon Deelset van het sectormodel: Synchroon Vraag/Antwoord Personen (natuurlijk) Adressen Protocol binding SOAP/WSDL (zie [7], [8]) Pagina 30
B. FO MO: Doorgeven binnengemeentelijke verhuizing Opvragen persoonsgegevens van alle personen wonend op hetzelfde adres t.b.v. prefill (doorgeven van een verhuizing) synchroon Contet De koppeling ondersteunt het voorinvullen van de bekende persoonsgegevens van personen wonend op hetzelfde adres uit de MO (B) in de FO applicatie (A) waarmee burgers een verhuizing kunnen doorgeven. A (Nieuw) <Applicatie naam> <Versie> (Bestaand) B <Applicatie naam> <Versie> Proces Preconditie De benodigde autorisatie is m.b.v. DigiD verkregen en de betreffende DigiD dient als key voor de op te halen gegevens. Tevens dient de aangever bevoegd te zijn tot het doen van aangifte binnengemeentelijke verhuizing van de andere personen. Op basis van de gegevens op de Persoonslijst (die uit de GBA komt) van de aangever is na te gaan voor welke personen de aangever bevoegd is de aangifte te doen. 1. Functionaliteit: Op basis van het door applicatie A verstrekte burgerservicenummer van de aanvrager geeft applicatie B de naam en adres gegevens terug van de aanvrager en het burgerservicenummer, de naamgegevens en de geboortedatum van alle op dat adres ingeschreven personen, waarvoor de aanvrager bevoegd is om aangifte van een verhuizing te doen. 2. Service niveau: Volumes Omvang van de berichten: <grootte> (gemiddeld) Aantal berichten per koppeling: <aantal per tijdseenheid> Responstijden Maimale doorlooptijd van het bericht in de koppeling van <n> seconde Actualiteit <Eisen aan de actualiteit van de te leveren brongegevens> Pagina 31
Informatie (sectormodel) Beschikbaarheid 7 24 uur. 3. Beveiliging <Evt. contet specifieke beveiligingseisen> Configuratieschema: StUF-BG (3.10) StUF (3.01) Interactiepatroon Deelset van het sectormodel: Synchroon Vraag/Antwoord Personen (natuurlijk) Protocol binding SOAP/WSDL (zie [7], [8]) Pagina 32
C. FO MO: WOZ waardebepaling Leveren van in een FO-applicatie ingevulde gegevens t.b.v. WOZ waardebepaling synchroon Contet De koppeling ondersteunt het leveren van de in een FO-applicatie ingegeven gegevens (A) door ambtenaren aan een MO applicatie (B) t.b.v. de WOZ waardebepaling. A (Nieuw) <Applicatie naam> <Versie> (Bestaand) B <Applicatie naam> <Versie> Proces Preconditie Applicatie B heeft zich op de gewenste gegevens geabonneerd met een afnemerindicatie. 1. Functionaliteit: M.b.v. de koppeling worden de in applicatie A ingegeven gegevens op een betrouwbare wijze naar applicatie B verstuurd. 2. Service niveau: Volumes Omvang van de berichten: <grootte> (gemiddeld) Aantal berichten per koppeling: <aantal per tijdseenheid> Responstijden Maimale doorlooptijd van het bericht in de koppeling van <n> seconde Actualiteit <Eisen aan de actualiteit van de te leveren brongegevens> Informatie (sectormodel) Beschikbaarheid Kantooruren. 3. Beveiliging <Evt. contet specifieke beveiligingseisen> Configuratieschema: StUF-BG (2.04) StUF (2.04) Deelset van het sectormodel: WOZ-Object Pagina 33
Interactiepatroon Synchroon Kennisgeving (verplichte overname) Protocol binding ebms (zie [11]) Pagina 34
D. FO MO: Aanvragen uittreksel GBA Leveren van ingevulde e-form gegevens t.b.v. Het aanvragen van een uittreksel GBA asynchroon Contet De koppeling ondersteunt het leveren van de door burgers in een e- formulier ingegeven gegevens (A) aan een MO applicatie (B) t.b.v. het aanvragen van een uittreksel GBA. De MO applicatie wordt beheerd door een centrale instantie. Het uittreksel wordt per post naar het adres gestuurd waarop de aanvrager staat ingeschreven. A (Nieuw) <Applicatie naam> <Versie> (Bestaand) B <Applicatie naam> <Versie> Proces Preconditie De MO-applicatie heeft in de Persoonslijst gecontroleerd of de burger het bewuste uittreksel mag/kan aanvragen. 1. Functionaliteit: M.b.v. de koppeling worden de in applicatie A ingegeven gegevens op een betrouwbare wijze naar applicatie B verstuurd. 2. Service niveau: Volumes Omvang van de berichten: <grootte> (gemiddeld) Aantal berichten per koppeling: <aantal per tijdseenheid> Responstijden Maimale doorlooptijd van het bericht in de koppeling van <n> seconde Actualiteit <Eisen aan de actualiteit van de te leveren brongegevens> Beschikbaarheid 7 24 uur. 3. Beveiliging <Evt. contet specifieke beveiligingseisen> Pagina 35
Informatie (sectormodel) Interactiepatroon Configuratieschema: Deelset van het sectormodel: Asynchroon Kennisgeving StUF-EF (1.00) StUF-BG (2.04) StUF (2.04) Personen (natuurlijk) Adressen Protocol binding ebms (zie [11]) Pagina 36
E. BO MO: Opsporing fraude Opvragen persoonsgegevens met historie van meerdere personen aan een Fraude Opsporingssysteem (Sociale dienst) asynchroon Contet De koppeling ondersteunt het leveren van de gegevens van meerdere personen, incl. hun historie, aan een Fraude opsporingssysteem van de Sociale Dienst in de Back-Office (B). Met name de verhuishistorie is hierbij van cruciaal belang. Vanwege het mogelijke grote aantal gegevens vindt de koppeling deels plaats via een bestand. A (Bestaand) <Applicatie naam> <Versie> (Bestaand) B <Applicatie naam> <Versie> Proces De koppelvlakken dienen door beheer geconfigureerd te kunnen worden. Daarbij moet gedacht worden aan instellingen als: 1. Locatie waarop het bestand met het antwoord moet worden geplaatst. 2. Naam van het bestand met het antwoord. Preconditie <Invullen> 1. Functionaliteit: M.b.v. de koppeling worden de in applicatie A ingegeven gegevens op aanvraag naar applicatie B verstuurd. In het bericht moet de materiële historie meegezonden worden. 2. Service niveau: Volumes Omvang van de berichten: <grootte> (gemiddeld) Aantal berichten per koppeling: <aantal per tijdseenheid> Responstijden Maimale doorlooptijd van het bericht in de koppeling van 1 dag Actualiteit <Eisen aan de actualiteit van de te leveren brongegevens> Beschikbaarheid Kantooruren. 3. Beveiliging <Evt. contet specifieke beveiligingseisen> Pagina 37
Informatie (sectormodel) Configuratieschema: StUF-BG (3.10) StUF (3.01) Deelset van het sectormodel: Personen (natuurlijk) Adressen Interactiepatroon Alle informatie met historische gegevens. Asynchroon Vraag/Antwoord Protocol binding SOAP/WSDL (zie [7], [8]), Vraag bericht. Bestand, Antwoord bericht. Pagina 38
F. BO BO: Persoonsgegevens voor uitkeringssysteem Binnengemeentelijke GBA levert persoonsgegevens aan een uitkeringssysteem (Sociale dienst) asynchroon Contet M.b.v. de koppeling wordt op gezette tijden updates van de persoons- en adres-gegevens naar het uitkeringssysteem in de Back-Office (B) gestuurd door de binnengemeentelijke GBA (A). In het uitkeringssysteem kunnen ook historische gegevens worden vastgelegd. A (Bestaand) <Applicatie naam> <Versie> (Bestaand) B <Applicatie naam> <Versie> Proces De koppelvlakken dienen door beheer geconfigureerd te kunnen worden. Daarbij moet gedacht worden aan instellingen als: 1. Aantal te verzenden updates per dag; 2. Tijdstip(pen) van verzenden. 3. <Aanvullen> Preconditie Het uitkeringssysteem heeft zich geabonneerd met een afnemerindicatie. 1. Functionaliteit: M.b.v. de koppeling worden de, sinds de laatst verstuurde update, in applicatie A uitgevoerde aanpassingen naar applicatie B verstuurd. Applicatie B is niet verplicht om de aanpassingen ook te verwerken. 2. Service niveau: Volumes Omvang van de berichten: <grootte> (gemiddeld) Aantal berichten per koppeling: <aantal per tijdseenheid> Responstijden Maimale doorlooptijd van het bericht in de koppeling van 1 dag Actualiteit <Eisen aan de actualiteit van de te leveren brongegevens> Beschikbaarheid Kantooruren. 3. Beveiliging <Evt. contet specifieke beveiligingseisen> Pagina 39