Binary content files can be imported and assigned to document objects in yuuvis® Momentum. Archiving can be managed and renditions can be retrieved.

Introduction

One of the key concepts of a document management system (DMS) is the effective handling of binary content files. On top of the basic operations like import, retrieval, update and deletion, further demands have to be considered in many companies. Each content update triggers the creation of a new version of the object whereas the previous object version is moved to the version history. Furthermore, in order to comply with legal bindings regarding the storage time, yuuvis® Momentum allows you to configure strict retention times during which the binary content files can neither be deleted nor updated. Binary content files of suitable formats can be analyzed in order to extract a text rendition that will be included in the full-text search. For many file types, also a PDF rendition can be retrieved.

General Characteristics

• The file size for binary content files in yuuvis® Momentum is limited to 32 GB per file.
• The core system can handle any file type as binary content file. For a wide range of file types, the generation of renditions is supported.
• Binary content files are stored in repositories that are managed by the REPOSITORY service and connected to yuuvis® Momentum via the ARCHIVE Service.
• Retention times can be specified in order to protect binary content files from deletion and modification.
• Binary content files can be assigned only to document objects. It is not possible to assign more than one binary content file per object.
  
• Document objects can be created without any binary content file assigned to them. Binary content files can be added to such already existing objects.
  
• Objects with a binary content file assigned to them have the section contentStreams in their JSON-formatted object representation.
  
  

Operations on Binary Content Files

Detailed guidelines and code examples for the individual scenarios are provided in our Example Tutorials.

Importing and Updating

The content stream properties that are available for import/update requests are described here.
>> Content Stream Properties

Binary content files can be assigned to objects in one call together with the object creation. The request has to be send with a multipart body specifying the assignments the of the binary content files to the corresponding document objects. Especially if you do not want to use the default repository, it is required to specify the target repository by its repositoryId.
>> POST /api/dms/objects

Alternatively, they can be assigned to already existing objects without a binary content file.
The same endpoint can be used to replace an existing content file. Again, if you do not want to use the default repository, it is required to specify the target repository. This is possible via X-OS-REPOSITORY-ID request header.
A new version of the entire object will be saved. The previous version of the object will be moved to the version history part of the database whereas the binary content file remains in the repository. Both metadata and binary content file will be available for version-specific operations as described below. Previous versions of objects and the text renditions of their binary content files are not included in search processes.
>> POST /api/dms/objects/{objectId}/contents/file

A binary content file under retention cannot be updated.

Depending on the configuration of the CONTENTANALYZER service, a text rendition will be extracted during an import or update of a binary content file if supported for its format. This rendition will be used for the full-text search together with all values of string properties within the metadata.

Retrieving Binary Content Files

The retrieval of the binary content file is requested via the object ID of the document object to which the file is assigned.
>> GET /api/dms/objects/{objectId}/contents/file

Moving Binary Content Files

It might be necessary to move binary content files from one repository to another. This might be useful, e.g., for downstream archiving on long-term media.
>> POST /api/dms/objects/{objectId}/actions/move/contents/repositories/{repositoryId}

Deleting Binary Content Files

Binary content files can only be deleted if the document object is deleted to which they are assigned. The version history of the object and the corresponding previous versions of the binary content file will be deleted as well.
>> DELETE /api/dms/objects/{objectId}

Objects with a binary content file under retention cannot be deleted.

Version-Specific Operations

For previous versions of objects, binary content files can be retrieved or moved from one repository to another one.
>> GET /api/dms/objects/{objectId}/versions/{versionNr}/contents/file
>> POST /api/dms/objects/{objectId}/versions/{versionNr}/actions/move/contents/repositories/{repositoryId}

Previous object versions can be deleted together with their assigned binary content files. Other versions of the same object as well as the current version remain unchanged.
>> DELETE /api/dms/objects/{objectId}/versions/{versionNr}

Renditions

Rendition operations are supported only for the current version of objects.

Text Rendition

The text rendition can be generated during the import or update by the CONTENTANALYZER service if text extraction is supported for the individual binary content files. Alternatively, a text rendition can be set by the user during an import or via the following endpoint for already existing objects.
>> POST /api/dms/objects/{objectId}/contents/renditions/text

The text rendition is stored in the Elasticsearch index and will be used for the full-text search together with all values of string properties within the metadata.

The text rendition can be retrieved.
>> GET /api/dms/objects/{objectId}/contents/renditions​/text

PDF Rendition

A PDF rendition can be generated and retrieved for binary content files if supported for their individual formats.
>> GET /api/dms/objects/{objectId}/contents/renditions​/pdf

Retention

Retentions can be used to customize and ensure binary content files are not deleted or changed through setting proper times/dates. A retention can be set for individual objects if their object type definition references the secondary object type (SOT) system:rmDestructionRetention. This SOT provides properties for setting an expiration and destruction date. The object's life can even be extended up to an infinite amount of years for the sake of your archiving needs.
>> Document Retention

For binary content files assigned to objects without such individual retention settings, the default retention of the repository will be used where the binary content file is stored. This default retention can be defined in the corresponding archive profile. If the default retention is defined, the SOT system:rmDestructionRetention containing the specified value will be assigned automatically to those objects during the import.
>> application-storage.yml

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. Objects without the SOT system:rmDestructionRetention do not have a retention.

Summary

Binary content files can be assigned to document objects and each content-related operation is requested via the corresponding object. Thus, content updates trigger the creation of a new object version. Operations on older versions are supported as well. For a wide range of supported formats, a text or PDF rendition can be generated. Retention times can be defined during which the corresponding binary content files can not be deleted or modified.