Hoe het genereren van een documentidentificatie zou moeten werken: Vanuit een pure CMIS applicatie wordt een document aangemaakt en vastgelegd in DMS. Deze applicatie is niet in staat via StUF een unieke documentidentificatie op te halen bij het Zaaksysteem. Via het ophalen van de CMIS changelog krijgt het zaaksysteem door dat er een nieuw document is toegevoegd. Het Zaaksysteem maakt de Documentidentificatie aan en brengt vervolgens het DMS op de hoogte van dit nummer waardoor ook in het DMS de Documentidentificatie beschikbaar is.
De manier waarop het nu beschreven staat in de standaard wijkt hiervan af en zegt dat een documentidentificatie alleen via een StUF service bij het Zaaksysteem opgevraagd kan worden. Dit zorgt ervoor dat CMIS consumers die niet in staat zijn om een eigen Documentidentificatie te genereren afhankelijk zijn van een StUF service.
- Delen de werkgroepleden het beeld van hoe het nu werkt?
- Delen de werkgroepleden het beeld van de wijze waarop het zou moeten werken? Zo niet, welk alternatief wordt dan voorgesteld?
De stelling is dat een applicatie die een nieuw zsdms:edc document aan een zaak wil toevoegen, maar toch niets van het zaaksysteem af wil weten qua communicatie en alleen CMIS moet kunnen communiceren. Hier zijn we als Roxit het niet mee eens; dat moet je niet willen binnen deze zaak-standaard. Als een applicatie een zsdms:edc document wil toevoegen, moet hij besef hebben van het RGBZ en dus de verplichte documentidentificatie (en niet te vergeten de folder structuur van zaken in het DMS zoals vastgelegd in de zkn-dms standaard). Welke webservice hij moet aanspreken om deze identificatie te krijgen maakt dan toch niet meer uit?
Vanuit PinkRoccade zien we ook graag dat applicaties die een EDC aanmaken zelf de sleutelservice hebben aangeroepen. Dit maakt namelijk de verwerking binnen het Zaaksysteem minder complex. Wel zijn er natuurlijk applicaties die documenten genereren en momenteel niets van StUF weten. De vraag is natuurlijk hoe gaan we daarmee om? Ik hoorde dan wel weer dat applicaties als Kofax zich ook gaan richten op StUF. Dit zou dus weer betekenen dat het aantal pure CMIS applicaties nihil op termijn zal zijn.
De ZS-DMS standaard is in het leven geroepen omdat er partijen zijn die geen StUF-ZKN spreken. Als de DsC dat wel kan, waarom is er dan nog behoefte aan een het CMIS-protocol voor de DsC? Laat dan de DsC gewoon puur StUF spreken - dat maakt ook de postintake (waarbij zaken moeten worden aangemaakt) een stuk overzichtelijker.
Aangenomen dat er nog steeds wel behoefte is aan CMIS-ondersteuning voor DsC's is het simpele alternatief dat de DsC de zsdms:documentidentificatie leeg laat (hij gaat daar immers niet over), waarna het zaaksysteem het nieuwe document ziet uit de changelog en daarop alsnog de documentidentificatie toewijst met cmis:updateProperties.
Wat mij betreft houden we daarmee de architectuur eenduidiger. Niet zo eenduidig natuurlijk als wanneer we iedereen verplichten StUF-ZKN te praten - maar de gedachte achter deze standaard was nou net dat we dat niet wilden.
Hoe Joost het beschrijft is hoe het zou moeten werken.
Het klopt ook dat de documentidentificatie alleen bij het ZS kan worden gegenereerd. Dit zijn twee onafhankelijke punten en bijten elkaar toch niet?
In CMIS is deze documentidentificatie niet verplicht en is in de changelog van het DMS niet zichtbaar. Het ZS weet zo dat dit document nieuw is toegevoegd en plaatst de eigen documentidentificatie in het DMS.
Het kan niet de bedoeling zijn dat een CMIS DsC of een DMS een documentidentificatie moet gaan opvragen bij een ZS alleen maar om het document te kunnen registreren. Voor het DMS is de documentidentificatie slechts een referentienummer en niet noodzakelijk.
Grappig dat Dennis stelt dat ook Kofax StUF gaat praten en de aanname doet dat CMIS applicaties nihil worden. Dan kunnen we net zo goed een StUF-stekker op een DMS zetten (zoals bij Alfresco wordt gedaan). Dan hoeven we CMIS niet meer te gebruiken....
Deze discussie raakt een fundamenteel principe binnen de specificaties waarvan ik persoonlijk vind dat het niet juist is. En wat vervolgens voorspelbaar tot de nodige verwarring en discussies leidt. Het gaat om uitgangspunt 11 "Binnen één gemeente wordt elk zaakgerelateerd document geïdentificeerd met één uniek kenmerk, de ‘documentidentificatie’; de authentieke bron voor documentidentificaties is het ZS". De authentieke bron voor -documenten- is volgens mij niet het ZS maar het DMS. De bron voor -documentidentificaties- kan divers zijn (zie ook blz 40: “De DSC kan zelf een documentidentificatie genereren”). Consumers verplichten om voor een documentidentificatie een zaaksysteem aan te roepen lijkt me dan ook zeer onwenselijk. Als ze al iets aanroepen (wat zeker niet altijd het geval hoeft te zijn) dan zou het het DMS moeten zijn.
Volgens de Zaak- en documentservice specificaties is de documentidentificatie een verplicht gegeven. Het kan dus niet zo zijn dat deze property niet wordt gezet omdat het DMS deze niet nodig heeft. Het feit dat er waardevolle DsC's op de markt zijn (en gaan komen) die geen StUF ondersteunen maakt het verleidelijk een dergelijke aanpak te ondersteunen. Maar wat doen we dan straks met andere verplichte metadata zoals Documenttype en Vertrouwelijkheid waarvan de domeinwaarden moeten worden gesynchroniseerd met de Zaaktypecatalogus? Dat zal functionaliteit zijn die deze DsC's mogelijk ook niet ondersteunen. En die kunnen we waarschijnlijk ook niet vanuit het Zaaksysteem aanvullen. Ik denk dat de tip van Ad (“De DSC kan zelf een documentidentificatie genereren”) de beste oplossing voor dit probleem is. Of de gebruiker van de betreffende DsC roept op een andere wijze de genereer service aan en tikt de identificatie over.