Is er een partij die voornemens is vanuit de rol DocumentservicesConsumer (DsC) het DMS te gaan bevragen obv CMIS berichten, of dat wellicht al doet?
Als het in de praktijk niet wordt gebruikt, moeten we dan niet de eis te laten vallen dat het DMS het CMIS-koppelvlak richting DsC verplicht moet ondersteunen. Zouden we dan niet moeten zeggen dat het DMS óf CMIS óf StUF-zkn (edc-berichten) moet ondersteunen?
Dit punt is besproken tijdens de werkgroep en het standpunt is dat dit een gepasseerd station is. Voor een DocumentserviceProvider is ondersteuning van de gehele CMIS 1.0 standaard verplicht, voor een DocumentserviceConsumer dat deel wat in de standaard beschreven staat.
In december 2014 is CMIS 1.0 (de CMIS versie die in de Zaak- en Documentservices verplicht is) op de “pas toe of leg uit lijst” van het Nationaal Beraad Digitale Overheid (voorheen College Standaardisatie) geplaatst, zie ook https://lijsten.forumstandaardisatie.nl/open-standaard/cmis.
Dat betekent dat CMIS een verplicht karakter heeft gekregen voor gebruik binnen de overheid. Voor softwareleveranciers is het van belang dat ze zich conformeren aan deze open standaarden.
Hoewel het station al gepasseerd is toch even de mededeling uit het veld dat binnen gem.Nijmegen is besloten om CMIS als standaard te hanteren. En ja, we verwachten dat een leverancier van een consumerapplicatie dit ondersteunt.
We zijn ondertussen 2 jaar verder en afgaand op de Softwarecatalogus en de geluiden uit de markt lijken er nog steeds geen DSC's te zijn die van de CMIS-documentservices gebruik maken. Sterker nog: bij de compliancytesten is zelfs nog geen mogelijkheid voor een DSC om CMIS-compliancy te testen ("Testscope: Documentservice Consumer (CMIS) De huidige versie van de testset biedt geen testdekking voor CMIS Document Consumers").
Hoe serieus wordt dit waardevolle deel van de standaard dan genomen? Er staat immers: "Referentiecomponent Documentserviceconsumer (DSC): Een systeem dat invulling geeft aan de DSC geeft daarmee aan dat voor het onderhouden en ontsluiten van zaakgerelateerde documenten gebruik wordt gemaakt van de StUF-documentservices of de CMIS-documentservices.". En is het geen tijd om hier actie op te ondernemen? Op deze manier is het een wassen neus en kun je als gemeente je architectuur nog steeds niet verder ontwikkelen.
Het zaaksysteem uit de Zaak- Documentservices is technisch gesproken ook een DSC. Immers, het zaaksysteem gebruikt CMIS om te communiceren met het DMS.
Een compliancy test voor DSC's is nogal ingewikkeld. Mij lijkt ondersteuning vanuit de service provider het belangrijkste, dat is immers de partij die de gevraagde services moet ondersteunen. In de Zaak- Documentservices staan maximale voorbeelden van hoe CMIS gebruikt kan worden om een aantal documentservices te gebruiken. Het is echter niet verplicht al deze services toe te passen. Wanneer een DSC al de informatie heeft om een repository of zelfs een document rechtstreeks te benaderen is het niet nodig of verplicht om bijvoorbeeld de CMIS discoveryservices te ondersteunen. Andersom moet een DMS dit wel omdat er altijd een DSC kan zijn die deze services nodig heeft.
In zo'n geval is dus de vraag: wat is de minimum set die nodig is om compliant te zijn? Volgens mij kan die niet vastgesteld worden want wat voor de ene DSC voldoende is om een document op te kunnen vragen hoeft voor de andere niet voldoende te zijn. In dit geval kunnen we niets anders zeggen dat het gewoon moet werken en alle CMIS operaties ondersteund moeten worden die voor het correct functioneren van die specifieke DSP nodig zijn.
Ik ,bedoelde taakspecifieke applicaties, maar je hebt natuurlijk gelijk dat ook zaakregistratiesystemen de rol van DSC hebben.
Mbt compliancy vaststellen snap ik niet waarom dit in dit geval lastiger zou zijn dan in andere gevallen. Kijkend naar de consumerservices binnen CMIS-documentservices zou ik verwachten dat je ze alle 9 moet ondersteunen om compliant te zijn. In zijn algemeenheid geldt bij voldoen aan standaarden dat je in de praktijk niet altijd alles gebruikt wat binnen de standaard valt.
Maar het allerbelangrijkste blijft de uitdaging om beweging te creëren bij leveranciers van taakspecifieke applicaties om de CMIS-documentservice te gaan ondersteunen. Anders kunnen we het wel mooi als voorkeurvariant benoemen maar kun je hem in praktijk nooit toepassen...
Voor zover ik weet zijn consumer applicaties altijd vrij in het ondersteunen van de services die ze nodig hebben voor het uitvoeren van hun taak. Bijvoorbeeld een Zaakservices Consumer (ZSC) die niets met documenten doet heeft geen noodzaak tot het ondersteunen van gebruik van de documentservices uit de Zaak- Documentservices. Maar kan wel heel goed compliant zijn aan de zaakservices en daarmee aan de zaak- documentservices als consumer.
Hetzelfde geldt voor CMIS: wanneer in een consumer applicatie ingesteld kan worden welk DMS gebruikt moet worden, welke repository etc. is er geen noodzaak tot het ondersteunen van de CMIS functies om al deze dingen dynamisch op te kunnen vragen. Een provider moet deze services wel ondersteunen om consumers die deze informatie niet op kunnen slaan ook te kunnen ondersteunen.
Wel is het naar mijn mening zo dat als een consumer applicatie een bepaalde functie/service moet gebruiken deze uit de standaard moet komen. Dus wanneer repository informatie uitgevraagd wordt dienen hiervoor de correcte CMIS functies uit de standaard voor gebruikt te worden. Dit is inderdaad de uitdaging om leveranciers in beweging te krijgen deze standaarden correct te ondersteunen.