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

Table of Contents

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

Up to product version 2023 Spring, 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 unter retention cannot be deleted. with a binary content file under retention cannot be deleted.

As of 2023 Summer, an endpoint allows to remove the binary content of a DMS object. A new version without content is created while the previous content is still assigned to the previous object version.
>> DELETE /api/dms/objects/{objectId}/contents/file

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

Text Rendition

Text rendition operations are supported only for the current version of objects.

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

As of 2022 Winter, PDF renditions of binary content files assigned to a previous object version can be retrieved as well.
>> GET /api/dms/objects/{objectId}/versions/{versionNr}/contents/renditions/pdf

Rendition Repository

As of 2021 Winter, a default rendition repository can be configured. Renditions of supported types (listed below) of binary content files assigned to objects can be stored in the default rendition repository. Thus, renditions can be retrieved from storage and are not regenerated for each retrieval request.
>> REPOSITORY Service

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. The default retention is NOT applied to objects that already have the SOT, even if the default retention would result in a later expiration date.
>> 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.

Note: The retention defined in the SOT protects binary content files from beeing modified/deleted via yuuvis® Momentum API. However, objects under retention can still be modified/deleted by administrators having direct access to the used storage. To prohibit such administrative operations, some archives offer an archive-internal retention as well. In those archives, the retention specified in the individual objects' metadata is set as an individual archive-internal retention.
>> Supported Archive Drivers

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.

Read on

Importing Documents via Core API

This tutorial shows how documents can be imported into a yuuvis® API system via the Core API. During this tutorial, a short Java application will be developed that implements the HTTP requests for importing documents. We additionally provide a JavaScript version of this tutorial. Keep reading

Object Representation Formats

A description of the structure in which yuuvis® Momentum expects objects to be formatted and returns objects. Keep reading

Document Retention

A retention can be used to ensure that a document object is not deleted and the binary content file assigned it is not deleted or changed. Keep reading

Browser not supported