Resources & Remarks

article is too brief and not fitting the intended structure. Topic should actually link to SOTs, link to the endpoints for changing storage, and link to a tutorial outlining the usage.

Introduction

...

Introduction

This article is based on the knowledge of schema structures.

yuuvis® Momentum provides the possibility to prohibit object deletion requests as well as deletion or change requests on binary content files via an expiration date property called system:rmExpirationDate. The property is predefined in all systems and is part of the also predefined secondary object type (SOT) system:rmDestructionRetention. This SOT can be referenced in any document object type definition in any schema (global, app specific or tenant specific). Thus, an expiration date can be set for each object of such a document object type. If a document object has the system:rmExpirationDate property and if the value of this property lies in the future. The object's life can be extended up to an infinite amount of years , it is under retention until the expiration date is reached. There is no maximum retention time. You can specify any date in the future as expiration date to ensure storage time for the sake of your archiving needs.

Precondition

There is a secondary object type system:rmDestructionRetention. To use retentions, the schema must contain an object type that uses this secondary object type (Schema Definition). Objects of this type can have retentions.

...

Since the retention is stored within the objects' metadata, the individual values can be retrieved like other object properties, e.g., via the GET /api/dms/objects/{objectId}endpoint. It is not possible to define retention periods for objects without the system:rmDestructionRetention.

'system:rmDestructionRetention' SOT

To specify a retention for an individual object, the following properties are predefined in yuuvis® Momentum.

The following code block shows the predefined properties that are related to retention. It is not possible to edit or overwrite those definitions.

	<propertyDateTimeDefinition>
		...
<propertyDateTimeDefinition>
    <id>system:rmExpirationDate</id>
		    <description>contains the date until the document's content is preserved</description>
    <propertyType>datetime</propertyType>
		    <cardinality>single</cardinality>
 		   <required>false</required>
	</propertyDateTimeDefinition>
	<propertyDateTimeDefinition>
   		 <id>system:rmStartOfRetention</id>
		<propertyType>datetime</propertyType>
		
    <description>contains the date from which the retention time was calculated (for documentation purposes only)</description>
    <propertyType>datetime</propertyType>
    <cardinality>single</cardinality>
		    <required>false</required>
	</propertyDateTimeDefinition>
	<propertyDateTimeDefinition>
		    <id>system:rmDestructionDate</id>
		
    <description>holds the date when the destruction process should be triggered</description>
    <propertyType>datetime</propertyType>
    		<cardinality>single</cardinality>
		    <required>false</required>
	</propertyDateTimeDefinition>

...

</propertyDateTimeDefinition>
...

All three of those properties are referenced in the system:rmDestructionRetention SOT. The following code block shows its predefined structure. It is not possible to edit or overwrite this definition.

...
<typeSecondaryDefinition>
    <id>system:rmDestructionRetention</id>
    <localNamespace>urn:optimal-systems.de:dmscloud:system</localNamespace>
    <description>can be used to apply retentions on objects</description>
    <baseId>system:secondary</baseId>
    <propertyReference>system:rmExpirationDate</propertyReference>
    <propertyReference>system:rmStartOfRetention</propertyReference>
    <propertyReference>system:rmDestructionDate</propertyReference>
</typeSecondaryDefinition>
...

Assigning a Retention

To use retentions, your applied schema must contain a document object type that references the predefined system:rmDestructionRetention SOT. For document objects of this type, you can specify retention properties via yuuvis® Momentum API. The following code block shows an example object type definition.

...
<typeDocumentDefinition>
    <id>document</id>
    <description>a document with retention</description>
    <baseId>system:document</baseId>
    <propertyReference>name</propertyReference>
    <propertyReference>date</propertyReference>
    <contentStreamAllowed>required</contentStreamAllowed>
    <secondaryObjectTypeId>system:rmDestructionRetention</secondaryObjectTypeId>
</typeDocumentDefinition>
...

By means of yuuvis® Momentum core API, there are two ways to set an object under retention:

• the object can

...

• directly be imported with an expiration date or
• an expiration date can be added to a previously existing object using a metadata update.

There are some conditions to the values of these retention properties. If an expiration date is set on an import or update, its value must not lie in the past. Also, if the expiration date is null, the start of retention and the destruction date must be null as well. Lastly, if a destruction date is set, it must either equal to or surpass the expiration date.An example data set as retrievable via GET /api/dms/objects/{objectId} is shown in the following code block.

{
    "objects": [{
        "properties": {
            "system:objectTypeId": {
                "value": "document"
            },
            "name": {
                "value": "exampledocument"
            },
            "system:rmStartOfRetention": {
                "value": "2018-07-20T11:52:00.000Z"
            },
            "system:rmExpirationDate": {
                "value": "2028-12-28T11:52:00.000Z"
            },
            "system:rmDestructionDate": {
                "value": "2028-12-28T11:52:00.000Z"
            }
        },
         
        ... // the content streams section is missing here
    }]
}

Effects of Retentions

If an expiration date has been set for a document object, it is not possible to change or delete its binary content file or delete the object before its expiration date. The other two properties have no particular uses provided by the system. Also, if an object is under retention, it is still possible to update its metadata; however, the expiration date cannot be removed or replaced by an earlier date.

An object under retention cannot be deleted or changed even by users that have a write or delete permissionpermissions; retentions are stronger than write or delete permissions.take precedence over write or delete permissions.

Automated Retention Management

It is possible to extend the functionality of yuuvis® Momentum by configuring webhooks and adding custom microservices. Thus, you can build your own specialized solution to realize automated retention management.

One possible use case would be to calculate the required retention values based on the individual object's metadata and set them, e.g.,

• during the object creation,
• during a specific update of the object's metadata, or
• triggered by a specific metadata update of the parent folder object (if you use system:parentId).

For the deletion of document objects with expired retention, you can introduce automated custom solutions as well. E.g., with a custom microservice in your system that automatically searches for objects with expired retention and

• deletes them,
• updates their state in the lifecycle via tagging, or
• starts a workflow process asking assigned users to delete them (if BPM-ENGINE Service is used).

Summary

Retentions can be set for document objects via a predefined SOT that provides an expiration date property. Before this date is reached, the document object cannot be deleted and its assigned binary content file cannot be updated or deleted via yuuvis® Momentum API.