Wiki broncode van Release notes 360º Overheid versie 3.0

Laatst gewijzigd door Afgeschermd op 21-01-2017 15:07:13

version	line-number	content
39.1	1	{{box cssClass="floatinginfobox" title="Inhoud"}}
12.1	2	{{toc/}}
39.1	3	{{/box}}
3.1	4
12.1	5	= Inleiding =
	6
14.1	7	Nagenoeg een jaar geleden begonnen we, De KennisFabriek, aan deze release van 360º Overheid. Hiervoor waren meerdere redenen:
7.1	8
9.2	9	* Onze klanten gaven heel waardevolle feedback. Zo had de [[gemeente Heerlen>>https://heerlen.gemeente.wiki\|\|rel="noopener noreferrer" target="_blank"]] behoefte aan de registratie van zogenaamde 'Use Cases' en vroegen de [[Omgevingsdienst Groningen>>https://groningen.omgevingsdienst.wiki\|\|rel="noopener noreferrer" target="_blank"]] en [[RUD Drenthe>>https://drenthe.rud.wiki\|\|rel="noopener noreferrer" target="_blank"]] om functionaliteit voor het vastleggen van //vrije inhoud//, bijvoorbeeld voor werkinstructies en veelgestelde vragen. En uit onze gesprekken met meerdere klanten ontstonden ideeën voor een verbeterde versie van de producten- en dienstencatalogus, zodat organisatiespecifieke aspecten (denk aan tarieven, kentallen, et cetera) ook per organisatie kunnen worden vastgelegd.
10.1	10	* De basis ([[XWiki>>http://xwiki.org\|\|rel="noopener noreferrer" target="_blank"]]) onder het 360º Overheid-platform werd ingrijpend veranderd door de introductie van zogenaamde //nested spaces//. Daarmee werd de tweelaags-structuur van XWiki omgevormd naar een echte boomstructuur. Wij simuleerden - via een //work-around// - deze functionaliteit al via 'ouder-kind'-relaties, dus waren we erg blij dat de boomstructuur ook daadwerkelijk ondersteuning kreeg in de XWiki-basis.
8.2	11	* Onze - talrijke - toevoegingen aan de XWiki-basis, waren lastig 'uit te rollen' en vergden veel handmatig beheer. Versie 3.0 van 360º Overheid implementeert deze toevoegingen volgens de systematiek van XWiki (via uitbreidingen - //extensions// - op de XWiki-basis), waardoor dit beheer veel eenvoudiger wordt.
	12	* Onze technische infrastructuur vergde - naar onze mening - teveel handmatig beheer. De verschillende componenten (LDAP, database server, applicatieserver, webserver) moesten afzonderlijk worden geconfigureerd en beheerd. Het opbouwen van een nieuwe omgeving was daardoor zeer arbeidsintensief en foutgevoelig.
	13	* Beveiliging was altijd al een belangrijk aandachtspunt - veel gebruikers vervloeken ons vanwege de uitgifte van 'sterke' wachtwoorden die ze niet zelf kunnen aanpassen, sorry daarvoor -, dus we wilden heel graag alle 360º Overheid-omgevingen beveiligen met SSL-certificaten.
7.1	14
10.1	15	Deze wensenlijst - die in de praktijk nog véél langer was - leidde ertoe dat we veel, heel veel, programmacode hebben herontworpen / herontwikkeld. Deze aanpassingen zijn niet altijd zichtbaar voor eindgebruikers en beheerders, maar stellen ons wel in staat 360º Overheid in de toekomst robuust en beheer(s)baar door te ontwikkelen. Hieronder beschrijven we achtereenvolgens de belangrijkste wijzigingen voor eindgebruikers en beheerders.
	16
22.1	17
14.2	18	= Wijzigingen voor eindgebruikers =
10.1	19
14.2	20	== Nested spaces ==
10.1	21
	22	De oorspronkelijk 'platte' structuur van XWiki van mappen met daarin pagina's is volledig omgevormd naar een boomstructuur. Eindgebruikers merken hier niet veel van, omdat we in de vorige versie van 360º Overheid al een boomstructuur 'simuleerden' die technisch werd vertaald naar eerdergenoemde platte structuur. Het heeft voor ons wel betekend dat we de volledige programmacode die deze structuur simuleerde, moesten aanpassen aan de nieuwe structuur van XWiki.
	23
14.2	24	=== Nieuwe functionaliteit ===
10.1	25
	26	De //nested spaces// stellen ons in staat om flexibeler met de functionaliteit van 360º Overheid om te gaan. Zo hebben we de mogelijkheid gecreëerd (én bij een aantal klanten benut) om een gelaagdheid in de producten- en dienstencatalogus aan te brengen. Bij de Omgevingsdienst Groningen en RUD Drenthe konden we daardoor twee versies (2016 en 2017) van de producten- en dienstencatalogus naast elkaar laten bestaan en bij de Veiligheidsregio's in Brabant hebben we deze functionaliteit benut om een externe en een interne producten- en dienstencatalogus te onderscheiden.
	27
27.2	28	[[image:Nested-spaces-example_GrDr.png\|\|height="145" width="640"]]
10.1	29
12.1	30
14.2	31	=== Wijzigingen in de User Interface ===
10.1	32
	33	De //nested spaces// hebben ook geleid tot nieuwe mogelijkheden in de User Interface. Zo gebruiken we zogenaamde //tree views// op de homepage om gebruikers sneller naar de door hen gewenste informatie te laten navigeren.
	34
27.2	35	[[image:Treeview-example_demo.png\|\|height="498" width="480"]]
10.1	36
	37	Ook in de //breadcrumbs// (broodkruimels) die op elke pagina staan, is zo'n //treeview// geïntroduceerd:
	38
27.2	39	[[image:Breadcrumb-example_demo.png\|\|alt="webkit-fake-url://4972cbd5-b79d-4ba9-b272-f270877197e8/image.tiff" height="333" width="480"]]
10.1	40
	41
14.2	42	=== Rechten ===
10.1	43
13.2	44	De //nested spaces// in combinatie met de fijnmazige rechtenstructuur waarover 360º Overheid beschikt, maakt het mogelijk onderdelen van de wiki beschikbaar te stellen aan specifieke groepen gebruikers. In de vorige versie van 360º Overheid maakten we onderscheid in twee groepen gebruikers: Beheerders en Gebruikers, beide van de gebruikende organisatie. Beheerders kunnen pagina's en objecten wijzigen, gebruikers kunnen pagina's en objecten bekijken en daar opmerkingen bij maken.
	45
	46	In deze nieuwe versie hebben we daar de groep Klanten aan toegevoegd, zodat we - in overleg met de gebruikende organisatie - medewerkers van opdrachtgevers (bijvoorbeeld gemeenten die opdrachtgever zijn van omgevingsdiensten en veiligheidsregio) toegang kunnen geven tot informatie die voor een gastbezoeker onzichtbaar blijft.
	47
14.1	48	Binnen alle groepen gebruikers kunnen 'subgroepen' worden aangemaakt, zodat 360º Overheid-omgevingen die door meerdere organisaties worden gebruikt ook functioneel eenvoudiger kunnen worden gescheiden. Een goede casus daarvoor is de 360º Overheid-omgeving die door de Omgevingsdienst Groningen en de RUD Drenthe wordt gebruikt: daarin worden zowel gedeelde werkinstructies bijgehouden als werkinstructies die specifiek zijn voor elk van de organisaties. Door subgroepen aan te maken onder de groep Gebruikers, is het mogelijk de gebruikers van Omgevingsdienst Groningen alleen toegang te geven tot de werkinstructies van de Omgevingsdienst Groningen, en de gebruikers van de RUD Drenthe tot de werkinstructies van de RUD Drenthe. Alle Gebruikers houden uiteraard toegang tot de gedeelde werkinstructies.
13.2	49
14.1	50	* Groep 'Gebruikers': toegang tot 'Kennis en documentatie / Gedeeld'
	51	** Groep 'GebruikersGroningen': toegang tot 'Kennis en documentatie / Omgevingsdienst Groningen'
	52	** Groep 'GebruikersDrenthe': toegang tot 'Kennis en documentatie / RUD Drenthe'
13.2	53
14.3	54	Het beheer van dit soort rollen en rechten kan nog niet door de Beheerders van een 360º Overheid-omgeving worden uitgevoerd. Enerzijds niet omdat de basis voor die rollen en rechten moet worden gelegd in de LDAP-server en anderzijds niet omdat de XWiki-rechtenstructuur waarop de rechten voor 360º Overheid-omgevingen zijn gestoeld, complex zijn en daardoor fouten - waardoor gebruikers bepaalde functionaliteit of informatie niet (of juist wel, terwijl dat niet zou moeten) kunnen bereiken - eenvoudig kunnen worden gemaakt. Vooralsnog zal dit beheer van rollen en rechten dus door De KennisFabriek worden uitgevoerd. Dit stelt ons ook in staat kritisch te blijven kijken naar de functionele of technische noodzaak voor het aanmaken en gebruiken van rollen en rechten: naast alle goede en mooie dingen die met rollen en rechten kunnen worden gerealiseerd, is het namelijk ook heel eenvoudig om een 360º Overheid-omgeving (met honderden //spaces// en duizenden pagina's) volledig onbeheer(s)baar te maken door een té enthousiast gebruik van rollen en rechten.
13.2	55
14.1	56
14.2	57	== Producten- en dienstencatalogus ==
	58
14.5	59	De producten- en dienstencatalogus is qua structuur drastisch herzien. Hierover is lang nagedacht door De KennisFabriek en we hebben zelfs geaarzeld of we wel 'zo ver zouden moeten willen gaan'. Omdat er geen andere manier is om tot een zuivere - bedrijfseconomische - beschrijving van producten en diensten te komen, hebben we de complexe praktijk tóch geïmplementeerd in het model van de producten- en dienstencatalogus. Uiteraard kan elke gebruikende organisatie zelf bepalen tot op welk niveau dat model wordt gebruikt.
14.2	60
14.5	61	In de vorige versie van 360º Overheid was de structuur als volgt:
	62
14.2	63	* Product A
14.3	64	** Varianten
	65	*** Variant 1
	66	*** Variant 2
	67	** Onderdelen
	68	*** Onderdeel a
	69	*** Onderdeel b
14.2	70	* Product B
14.3	71	** Varianten
	72	*** Variant 1
	73	*** …
	74	** Onderdelen
	75	*** Onderdeel a
	76	*** …
14.2	77
14.3	78	In de nieuwe versie is de structuur:
14.2	79
14.3	80	* Product A
	81	** Varianten
	82	*** Variant 1
	83	**** VariantKenmerken van organisatie I
	84	**** VariantKenmerken van organisatie II
	85	**** Bijdrage-varianten
14.4	86	***** Bijdrage-variant: Variant 6 (van Product B)
	87	***** Bijdrage-variant: Variant 9 (van Product B)
14.3	88	**** Onderdelen
	89	***** Onderdeel a
	90	****** OnderdeelKenmerken van organisatie I
	91	****** OnderdeelKenmerken van organisatie II
	92	***** Onderdeel b
	93	****** OnderdeelKenmerken van organisatie I
	94	****** OnderdeelKenmerken van organisatie II
	95	*** Variant 2
	96	**** …
	97	*** …
	98	* Product B
	99	** Varianten
	100	*** Variant 6
	101	**** Variantkenmerken van organisatie I
	102	**** Variantkenmerken van organisatie II
	103	**** Bijdragevarianten
	104	**** Onderdelen
	105	*** …
	106	*** Variant 9
	107	**** …
	108
	109	=== Varianten en Onderdelen 'geknipt': kenmerken apart ===
	110
	111	Zowel de objecttypen 'Variant' als 'Onderdeel' zijn 'geknipt': de code en naam van een Variant of Onderdeel zijn attributen gebleven van het Variant- respectievelijk Onderdeel-object, maar de organisatiespecifieke kenmerken (zoals een kental of uurtarief) zijn een niveau lager gelegd in VariantKenmerken en OnderdeelKenmerken. Zo kunnen pér gebruikende organisatie van een 360º Overheid-omgeving andere kenmerken (kental, uurtarief, etc.) worden vastgelegd, terwijl ze tóch een gemeenschappelijke producten- en dienstencatalogus hanteren.
	112
	113	Let op: het was de bedoeling om al in deze release van 360º Overheid automatisch de juiste rechten te zetten op de Kenmerken van Varianten en Onderdelen. Dit opdat dit soort 'concurrentiegevoelige' informatie (met bijvoorbeeld uurtarieven en kentallen voor het aantal uren dat een specifieke organisatie besteed aan een product of dienst) alleen zichtbaar zou zijn voor specifieke groepen gebruikers (bijvoorbeeld de medewerkers of opdrachtgevers van organisatie I zien alleen de …Kenmerken van organisatie I). Tijdens het testen bleek deze functionaliteit tóch te fragiel / foutgevoelig, dus die hebben we moeten aanhouden voor een volgende release. Dit betekent dat Variant- en OnderdeelKenmerken nog niet zijn af te schermen en dus zichtbaar zijn voor alle gebruikers die de betreffende producten kunnen bekijken.
	114
	115	=== Onderdelen zijn 'kind' geworden van Variant ===
	116
	117	In de vorige versie van 360º Overheid had een Product 'Varianten' en 'Onderdelen' als kinderen. Daarbij was een Variant het 'kostprijsbepalende' element van een product en was een Onderdeel het optionele, kostprijsverhogende, element. Dat beide objecttypen op hetzelfde niveau waren gemodelleerd bleek in de praktijk niet handig: Onderdelen moesten specifiek kunnen worden gemaakt voor een Variant van een Product. Daarom zijn Onderdelen nu 'onder' een Variant gehangen.
	118
	119	Let op: voor bestaande 360º Overheid-omgevingen waarin zowel Varianten als Onderdelen werden gebruikt, betekent dit dat elk Onderdeel dat in de vorige versie een 'kind' was van een Product, nu een 'kind' is geworden van elke Variant van dat Product. Dat is de enige manier om geen informatie te verliezen bij de migratie naar de nieuwe 360º Overheid-omgeving. Als er dus in de oude omgeving een Product bestond met 5 Varianten en 10 Onderdelen, dan heeft dat Product nu nog steeds 5 Varianten, maar heeft elk van die Varianten 10 Onderdelen! U zult helaas bij elke Variant moeten beoordelen of alle daaronder gecreëerde Onderdelen relevant zijn voor die specifieke Variant. Als dat niet het geval is, kunt u de betreffende Onderdelen gewoon verwijderen.
	120
	121	=== Bijdrage-varianten voor 'halffabrikaten' ===
	122
14.4	123	Sommige Varianten kunnen zowel zelfstandig bestaan, als worden toegepast in het vervaardigen van een - Variant van - een ander product. Zie bijvoorbeeld de volgende - vereenvoudigde - casus uit het domein van Vergunningverlening, Toezicht en Handhaving:
14.3	124
14.4	125	* Product: //Omgevingsvergunning//
	126	** Variant: //Oprichtingsvergunning milieu-inrichting//
	127	*** Onderdeel: //Advies brandveilig gebruik// (wordt 'extern ingekocht' bij de Brandweer)
	128	* …
	129	* Product: //Advies//
	130	** Variant: //Advies Geluid//
	131	** Variant: //Advies Milieu//
	132	** Variant: //Advies Luchtkwaliteit//
	133	** …
	134
15.1	135	De Varianten van het Product 'Advies' kunnen direct door opdrachtgevers worden afgenomen (bijvoorbeeld voor het opstellen van een bestemmingsplan / omgevingsplan of het beoordelen van een Aanvraag Omgevingsvergunning met het zwaartepunt op de activiteit 'Bouwen' die zij zelf behandelen, maar waarvoor ze een advies van een omgevingsdienst nodig hebben). De adviezen kunnen echter ook door 'interne' afnemers (de behandelaar van de Variant 'Oprichtingsvergunning milieu-inrichting' wil advies op het aspect 'Geluid' en 'Luchtkwaliteit') worden besteld. Daarmee worden de Varianten van het product 'Advies' een halffabrikaat voor een ander 'eigen' product, de 'Omgevingsvergunning' in de Variant 'Oprichtingsvergunning milieu-inrichting'. En vormen zij dus ook een 'kostprijsverhogend' element: hoe meer adviezen nodig zijn voor de behandeling van zo'n aanvraag, hoe duurder het product wordt. In de vorige versie van 360º Overheid moesten deze 'eigen' halffabrikaten (Varianten van een ander Product) als Onderdeel worden gedefinieerd en moesten de kenmerken van die Varianten worden overgenomen in de Onderdeelkenmerken. Dat overnemen en gesynchroniseerd houden van die kenmerken gaat natuurlijk vroeg of laat mis. Bovendien is er geen relatie tussen een Onderdeel en een Zaaktype: die relatie wordt gelegd bij de Varianten van een product.
14.4	136
	137	Om dit soort halffabrikaten die in eigen huis worden geproduceerd op de juiste manier aan een samengesteld product te kunnen verbinden, is de Bijdrage-variant geïntroduceerd in deze versie van 360º Overheid. Daarmee wordt een relatie gelegd tussen de Variant die het samengesteld product levert (in dit voorbeeld: de Variant 'Oprichtingsvergunning milieu-inrichting' van het product 'Omgevingsvergunning') en een elders in de producten- en dienstencatalogus gedefinieerde Variant van een ander product (in dit voorbeeld: de Varianten van het Product 'Advies'). Met als belangrijkste voordelen dat de kenmerken van zo'n halffabrikaat maar op één plaats hoeven te worden gedefinieerd én dat de relatie naar het zaaktype (in dit voorbeeld: 'Advies verstrekken') van dat soort Bijdrage-varianten behouden blijft.
	138
	139
15.1	140	== Deskundigheidsgebieden ==
	141
	142	In de vorige versie van 360º Overheid waren deskundigheidsgebieden vooral 'labels' die aan een Taak konden worden gekoppeld. Bovendien bood 360º Overheid slechts ruimte aan één 'lijst' van deskundigheidsgebieden. In deze versie van 360º Overheid zijn deskundigheidsgebieden ondergebracht in 'domeinen' (bijvoorbeeld: het domein 'VTH-kwaliteitscriteria') en 'subdomeinen' (bijvoorbeeld 'Generieke deskundigheidsgebieden' en 'Specialistische deskundigheidsgebieden accent milieu'). Daarnaast zijn de deskundigheidsgebieden 'verdiept' met zogenaamde Profielen, zodat voor specifieke activiteiten die door een organisatie worden uitgevoerd, ook een echt curriculum (met werkervaring, opleidingseisen, 'vlieguren', et cetera) kan worden beschreven:
	143
27.2	144	[[image:Deskundigheidsprofiel-example_demo.png\|\|alt="webkit-fake-url://1ea006ac-5268-4d75-a3e0-1d926c59b01e/image.tiff" height="424" width="800"]]
15.1	145
	146
16.1	147	De 'kenner' herkent in bovenstaande afbeelding ongetwijfeld de elementen uit de VTH-kwaliteitscriteria, maar deze zijn uiteraard even goed bruikbaar in andere domeinen. De KennisFabriek heeft nog niet alle deskundigheidsprofielen van de VTH-Kwaliteitscriteria ingevoerd; dat is een forse klus, maar gaat wel gebeuren. Het is bedoeling de volledige VTH-Kwaliteitscriteria vervolgens als afzonderlijk 'Content package' beschikbaar te stellen aan gebruikende organisaties. Uiteraard kunnen organisaties ook andere domeinen toevoegen of bestaande domeinen en subdomeinen wijzigingen. De KennisFabriek helpt graag bij het maken van de juiste structuur daarvoor (gebruik de Ondersteuningsverzoek-functie om daarvoor een verzoek in te dienen).
15.1	148
22.1	149
17.1	150	== Overeenkomsten ==
16.1	151
17.1	152	Met de functionaliteit voor Overeenkomsten wil De KennisFabriek de mogelijkheid bieden aan gebruikende organisaties om de Dienstverleningsovereenkomsten (contracten) die zijn aangegaan met klanten / opdrachtgevers goed vast te leggen. DIt opdat ondubbelzinnig duidelijk is welke taken een specifieke klant / opdrachtgever aan de gebruikende organisatie heeft opgedragen, welke producten en diensten daarbij horen en welke afspraken er - bijvoorbeeld - zijn gemaakt over mandatering, et cetera. Omdat dit behoorlijk complexe materie is en we eerst ervaring willen opdoen met de gewijzigde producten- en dienstencatalogus, hebben we deze functionaliteit in de huidige release uitgeschakeld.
	153
	154
18.1	155	== Vertalingen en andere ondersteuning ==
17.1	156
19.1	157	De basis onder 360º Overheid is XWiki, een van origine Engelstalig product. XWiki biedt echter uitstekende ondersteuning voor 'vertalingen' van nagenoeg alle elementen van XWiki. De KennisFabriek heeft bijna alle elementen (vele duizenden!) van XWiki vertaald naar het Nederlands en weer 'teruggegeven' aan de XWiki-community zodat iedereen ervan kan profiteren. Sinds deze versie van 360º Overheid gebruiken wij dezelfde systematiek van vertalingen voor alle elementen die we in 360º Overheid aan gebruikers tonen. Daarmee kunnen we - althans in theorie - het 360º Overheid-platform ook relatief eenvoudig in een andere taal beschikbaar stellen (@Fumo: vertaling naar het Fries staat nog niet op de releasekalender! :-) ). Belangrijker - voor ons althans - was dat we zo geen teksten die op het scherm worden getoond, hard in de programmacode hebben opgenomen, maar in eenvoudiger te beheren vertaalbundels hebben gestopt.
18.1	158
19.1	159	Daardoor konden we ook betere gebruikersondersteuning in deze versie van 360º Overheid opnemen, zoals de //tooltips// die op nagenoeg alle elementen van 360º Overheid verschijnen als u er ongeveer anderhalve seconde de muispijl op laat rusten (//hovering//):
18.1	160
27.2	161	[[image:Tooltip-example_demo.png\|\|height="403" width="800"]]
18.1	162
	163
19.1	164	(% id="H" %)
	165	Waar mogelijk - bijvoorbeeld in de Zaaktypecatalogus - hebben we in deze teksten gebruik gemaakt van de teksten uit de landelijke standaarden.
	166
	167	Er zijn helaas altijd elementen in de XWiki-basis die wij nog niet hebben vertaald, bijvoorbeeld omdat die aan de nieuwste versie van XWiki zijn toegevoegd en wij pas na het verschijnen van zo'n nieuwe versie de vertalingen kunnen maken en aan XWiki kunnen aanbieden. Als u daarvan hinder ondervindt, kunt u ons altijd via een Ondersteuningsverzoek attenderen op ontbrekende vertalingen, dan zorgen wij dat de vertalingen worden gemaakt. Normaal gesproken zijn ze dan opgenomen in de eerstvolgende release van XWiki en/of 360º Overheid.
	168
17.1	169
40.1	170	= Wijzigingen voor beheerders =
22.1	171
19.1	172	Uiteraard geldt al het bovenstaande ook voor Beheerders. Daarnaast beschikken Beheerders over onderstaande nieuwe / aangepaste functionaliteit in deze nieuwe versie van 360º Overheid.
	173
22.1	174
20.1	175	== Gewijzigde lay-out van invoerschermen ==
19.1	176
20.1	177	De lay-out van invoerschermen is aangepast, enerzijds om deze minder 'onrustig' te laten ogen, maar vooral om ruimte te creëren voor permanente uitleg / ondersteuning (via de teksten uit de tooltips die hierboven ook zijn genoemd) bij het invoeren van nieuwe gegevens:
19.1	178
28.2	179	[[image:Edit-object-example_demo.png\|\|alt="webkit-fake-url://07a4c4f1-44b1-4c34-8d06-9ac1ee53c380/image.tiff" height="490" width="800"]]
19.1	180
20.1	181
	182	== Gewijzigde WYSIWYG-editor ==
	183
22.1	184	Voor de invoer van gegevens __//met opmaak//__ wordt in deze nieuwe versie van 360º Overheid gebruik gemaakt van een nieuwe WYSIWYG-editor. De 'oude' editor was technisch gedateerd en niet heel erg gebruiksvriendelijk. De ontwikkelaars van XWiki zijn nog druk doende met een nog betere integratie van de nieuwe editor, dus in volgende versies zullen ongetwijfeld nieuwe //features// zijn toegevoegd. Deze nieuwe editor is zo'n component die we nog niet helemaal hebben kunnen [[vertalen>>\|\|anchor="HVertalingenenandereondersteuning"]].
21.1	185
22.3	186	Let op: Een enkele keer overkomt het ons dat de nieuwe editor een 'spinning wheel' laat zien. Het opnieuw laden van de pagina lost dit probleem op.
21.1	187
22.1	188
	189	== Kopieer een zaaktype ==
	190
22.2	191	Een zaaktype bestaat uit een heleboel elementen (een gemiddeld zaaktype bestaat al snel uit zo'n 100 objecten met bijbehorende pagina's). Het maken van een nieuw zaaktype 'vanaf //scratch//' is daarom ook best een klus. Daarom hebben we functionaliteit toegevoegd waarmee beheerders een bestaand zaaktype kunnen kopiëren. Dit kan zowel binnen één zaaktypecatalogus als van de ene zaaktypecatalogus naar een andere zaaktypecatalogus (alleen voor 360º Overheid-omgevingen waarin meer dan één zaaktypecatalogus wordt beheerd). Vervolgens kan het nieuwe zaaktype uiteraard worden bewerkt zoals elk ander zaaktype. In de volgende release van 360º Overheid zullen we ook de kopieerfunctie hebben uitgebreid naar het kopiëren van zaaktypen vanaf de [[360º Overheid Marktplaats>>http://marktplaats.360overheid.wiki]], zodat u ook zaaktypen kunt kopiëren die zijn gemaakt in omgevingen van andere 360º Overheid-gebruikers.
	192
33.2	193	Let op: Bij het kopiëren van een zaaktype 'springt' de voortgangsbalk soms heen-en-weer (in bepaalde situaties zelfs tot 100% en dan weer terug). Dit heeft te maken met de verschillende //jobs// die worden gestart voor het kopiëren van een zaaktype. Helaas is het in deze release niet gelukt de progressie - van die //jobs// - in één consistent voortgangsoverzicht te vatten. Naar de oorzaak van dit probleem zoeken wij nog. Voor de gebruiker / beheerder: er gaat dus niets mis: zodra u de terugkoppeling van de kopieeractie op het scherm ziet verschijnen, is het zaaktype gekopieerd.
22.2	194
33.2	195
22.2	196	== Consistentie van roltypen controleren ==
	197
	198	Omdat roltypen niet - zoals informatieobjecttypen en besluittypen - centraal binnen de zaaktypecatalogus worden bijgehouden, maar per zaaktype moeten worden benoemd, is het lastig daarbij 'over zaaktypen heen' altijd consistent te blijven. Met deze functionaliteit kunt u de roltypen van alle zaaktypen tonen en ziet u in één oogopslag (nou ja, twee misschien) waar de verschillen zitten.
	199
	200
	201	== Consistentie van statustypen controleren ==
	202
22.3	203	Voor statustypen geldt hetzelfde als voor roltypen: omdat ze per zaaktype worden gedefinieerd is het lastig statussen die hetzelfde beogen, consistente namen, doorlooptijden et cetera, te geven. Met dit overzicht is die consistentie eenvoudig te controleren.
	204
	205
	206	= Techniek (voor de nerds onder ons) =
	207
29.2	208	Als u het lezen tot hier hebt volgehouden bent u een held! En als u hier bent terechtgekomen via de hyperlink bovenaan deze pagina, heeft u vast een bovengemiddelde interesse in de technologie die De KennisFabriek toepast.
	209
	210
	211	== Gescheiden Ontwikkel-, Test, Acceptatie en Productie-omgevingen (OTAP) ==
	212
32.2	213	Alles wat De KennisFabriek ontwikkelt, doorloopt een Ontwikkel, Test, Acceptatie en Productie-cyclus (OTAP) in - functioneel en technisch - van elkaar gescheiden omgevingen. Hiermee zorgen we we ervoor dat wijzigingen na Ontwikkeling (in een separate omgeving) en het Testen van die ontwikkeling (in een separate omgeving) Acceptatie door de gebruikende organisatie (in een separate omgeving) kan plaatsvinden voordat de nieuwe / gewijzigde functionaliteit in een Productieomgeving wordt geïmplementeerd.
29.2	214
	215
32.2	216	== OTAP-omgevingen op PaaS / CaaS-omgevingen in Nederlandse datacentra ==
	217
38.1	218	Alle omgevingen van 360º Overheid worden gehost in Nederland in een Tier-3 datacenter. De Test-, Acceptatie- en Productieomgevingen zijn geïmplementeerd op een Jelastic-platform (//Platform as a Service, PaaS)//, waardoor 360º Overheid-omgevingen zowel eenvoudig verticaal (lees: door toevoeging van meer CPU-capaciteit, meer geheugen, meer opslag) als horizontaal (lees: door toevoeging van meer //nodes/servers// voor één of meer componenten) kunnen worden 'geschaald'.
32.2	219
37.1	220	De KennisFabriek was één van de de aanjagers en //early adopters// van de mogelijkheid om - bovenop het Jelastic Platform - servercomponenten te implementeren op basis van Docker-images. Deze functionaliteit is inmiddels toegevoegd aan het hostingplatform, waardoor alle Ontwikkel-. Test-, Acceptatie- en Productieomgevingen op basis van door De KennisFabriek gestandaardiseerde en volledig geconfigureerde, Docker-images zijn opgebouwd. Dankzij deze - aan het Jelastic-platform toegevoegde - technologie, is de volledige infrastructuur van de OTAP-omgevingen van 360º Overheid-omgevingen //container-based// //(Container as a Service, CaaS)//.
32.2	221
29.2	222	== Architectuur microservices ==
	223
37.3	224	Voor het ontwikkelen, testen, accepteren en in productie nemen van 360º Overheid-omgevingen, wordt te allen tijde het hierboven beschreven OTAP-proces doorlopen. Alleen zo kunnen we garanderen dat alle waarborgen voor een goed functionerende 360º Overheid-omgeving zijn getroffen. Om die 'OTAP-straat', zoals dat in programmeurs-termen heet, consequent en reproduceerbaar te kunnen doorlopen, hebben we alle componenten die daarvoor nodig zijn gestandaardiseerd o.b.v. eerdergenoemde 'Docker-images'. Die architectuur van microservices ziet er als volgt uit:
29.2	225
32.2	226	(% style="text-align:center" %)
	227	[[image:360-architecture-microservices.svg\|\|height="778" width="640"]]
29.2	228
43.1	229	{{velocity}}#set($docextras=[]){{/velocity}}