What's new in this release

Features

Here, you will find some of the new release's features. Check out the Change Log for further information on all changes. 

Schema - Defining Object Types

According to your specific needs you set up the underlying schema. It is based on a set of so called object types and a set of properties. In detail you define object type definitions for documents, secondary object types as well as folders.

Secondary Object Types

Secondary object types allow you to design a more complex schema. In a way the idea correlates to the concept of inheritance: they can be used to create property groups which can be referenced by other object types (e.g., documents or folders). Like other object types, a secondary object type itself can have references to properties. By referencing a secondary object type, the properties of the group will be "inherited" by the object type. In general, secondary object types are abstract and cannot be instantiated.

Folder Object Type Definition

You define folders as structuring elements either in your global, tenant-specific or application schema. They do not have their own content files in contrast to document object types and cannot be set up in a hierarchical structure – a folder inside a folder is not allowed. (As of version 2.4, a folder hierarchy will be possible.) Folders allow the grouping of multiple documents and have their own metadata which will not be inherited by the assigned documents. Similar to a document object type a folder can reference a secondary object type's property group. The properties can be used as regular properties on folder level. Folders with documents assigned to them cannot be deleted.

The document object types are the elementary object types of your schema in which the "real" content is stored. During import or update of a document the object ID of the target folder is provided as the new object's parent ID (system:parentId). Actions such as assigning documents, moving them to or removing them from a folder can easily be carried out in this way. A validation takes place and checks whether the given ID is a folder and does exist.  By assigning documents to a configured folder you set an exact filing location and ensure a "tidy" storage of documents within your repository – if needed for your use case.
(OKTO-4091 | OKTO-3688)

Classification Attribute for Property Definition

When defining the set of properties for your object type additional attributes are available per property. For further processing – e.g., for the presentation and validation in the client – a <classification> attribute can be added. It classifies the property further and you could for example classify string properties as 'phone', 'email' or 'url'. The client can use this information to present the content in an appropriate way and can validate the user's input via regular expressions if wanted.
(OKTO-3758)

Webhooks - Manipulating Metadata

System hooks (AMQP Hooks and Webhooks) are functions that apply to core functions of the yuuvis® Momentum API whenever certain conditions are met and that extend or modify those functions. As such, they serve as a modular, external approach for the introduction of new functionalities as extensions of already existing ones. A webhook extends the function by an HTTP call. Whenever the condition is true, an optional HTTP call to a web URL is performed.

For the manipulation of an object's metadata upon the first import, we introduced a new POST webhook type dms.request.import.storage.before.  For this call, the metadata of the CONTENTANALYZER service is available for the object to be imported. The call takes place just before the object is going to be filed in the repository. You configure the webhook for the entire system and not on tenant level.
(OKTO-3962)