Van PinkRoccade ontvingen wij het volgende bericht, waarop wij graag reacties hebben van alle werkgroepleden. Na deze reacties volgt de visie van KING:
Indien Zaken of Documenten vanuit het DMS worden verwijderd dan kan deze mutatie via de CMIS changelog bij het Zaaksysteem terecht komen. De CMIS changelog bevat standaard echter alleen het objectId (de technische sleutel aan de kant van DMS) van het zojuist verwijderde object en niet de functionele sleutels, zoals zaak- of documentidentificatie. Het mechanisme aan de kant van het Zaaksysteem (in ons geval Makelaarsuite) gaat met het opgehaalde objectId de vervolgacties uitvoeren (bijvoorbeeld synchronisatie naar Zakenmagazijn). Echter indien het zaaksysteem met het opgehaalde objectId aan DMS vraagt wat de functionele sleutels zijn van het verwijderde object dan geeft DMS natuurlijk geen antwoord meer, aangezien het objectId al niet meer bestaat. Er is namelijk ook bewust voor gekozen om de objectId’s niet vast te leggen aan de kant van het Zaaksysteem. Dit zou namelijk alleen maar ballast zijn om de technische sleutels van het DMS aan de kant van het Zaaksysteem op te slaan, dat is juist niet hoe het nieuwe koppelvlak bedacht is! De insteek was communicatie op functionele gegevenselementen (zie ook weer de blauwe tekst bij punt 2):
Deze specificatie streeft ernaar, om, conform GEMMA, informatie slechts op één plek vast te leggen. Een set van vijf gemeenschappelijke gegevenselementen is nodig om een relatie te leggen tussen zaakgegevens in het ZS en documentgegevens in het DMS. Dit zijn:
- Zaakidentificatie;
- Zaaktype;
- Documentidentificatie;
- Documenttype;
- Resultaat
CMIS ondersteunt het blijkbaar niet dat bijvoorbeeld zaakidentificatie of documentidentificatie meegegeven kan worden bij een delete actie die terug te vinden is in de changelog. De vraag is wat de visie is van KING rondom dit onderwerp.
Er is gekozen voor de CMIS standaard voor de communicatie en daar hebben we ons aan te confirmeren. Deze specificeert duidelijk het ObjectId als identificerend gegeven in de communicatie. Daar zal het zaaksysteem dus op voorbereidt moeten zijn, niet andersom. Dat je dat niet wilt in het zaaksysteem, en je daarmee beroept dat dit conform GEMMA is, is onlogisch; er zijn niet voor niets de sleutels verzendend, ontvangend en gegevensbeheer gedefinieerd in StUF: ieder systeem kent eigen id's en daar heb je maar mee om te kunnen gaan.
Wat Wouter voorstelt zou kunnen werken als de objectId's aan de kant van DMS (qua lengte) passen in het StUF-attribuut 'sleutelVerzendend'. En dat is niet altijd het geval.
Binnen de CMIS standaard is het mogelijk om in de changelog niet alleen het objectid mee te geven maar ook de eigenschappen van het object waar het om gaat. De CMIS 1.0 standaard specificeert dat de repository dat mag doen (optioneel) voor update-operaties.
Voor het DMS is het een kleine moeite om dat ook te doen voor delete operaties. De CMIS standaard specificeert niet expliciet dat dat mag, maar specificeert ook niet dat dat niet mag. Als de repository dat gewoon zou doen, levert het extra gegevens waar de CMIS-client al dan niet gebruik van kan maken - CMIS clients die die data niet verwachten hebben er ook geen last van.
Op die manier kunnen de zaak- en documentidentificaties gewoon direct uit de changelog worden uitgelezen en wordt een hoop verkeer en synchronisatie van nummertjes uitgespaard. De kosten aan de kant van de CMIS-client omvatten niet meer dan een actieve check op de aanwezigheid van additionele data in de changelog.
Ik zie hier een eenvoudige optimalisatie tegen lage kosten, die geen negatief effect heeft voor partijen die deze optimalisatie niet willen. Ik zou dus willen voorstellen dat we van deze mogelijkheid gebruik kunnen maken, hoewel de CMIS standaard er niet expliciet over spreekt.
Dit is na overleg in de werkgroep conform voorstel van Frans opgenomen in documentversie 1.02-02 (conceptversie), item is geregistreerd als [ZDS-22].