Schema - Defining Object Types
Define properties and reference them in object type definitions for the entire system, for individual tenants or for a specific app.
Table of Contents
Introduction
In yuuvis® Momentum, document and folder objects can be created.
- Each object has its own metadata including a fixed set of general system properties like
system:versionNumber
orsystem:lastModificationDate
. Objects with a binary content file assigned to them additionally have a set of content stream properties. Those system properties are predefined. - Further metadata properties can be defined in an XML schema file as described below. Those metadata properties can be referenced in object type definitions, usually in the same schema file.
Each object instantiated in yuuvis® Momentum has exactly one of the defined document or folder object types during its entire lifecycle. The properties referenced in the corresponding object type definition are optional or required for the instantiated objects as specified in their definition.
In a schema, it is possible to define secondary object types (SOTs) as well. Those object types cannot be instantiated, but referenced in document or folder object type definitions. The properties of the SOT can be added to the properties of the document or folder object type for the objects that will be instantiated - either during the objects' creation or even during their lifecycle (floating reference).
Tenant-specific (or app-specific) properties and object types should be defined in a tenant (or app) schema, whereas the properties and object types defined in the global schema are available for all tenants and apps.
Schema Outline
A schema contains property definitions and object type definitions in XML format in the following mandatory order. It is possible to skip parts but not to change their order.
- Label (as of 2023 Autumn)
- Property definitions
- Object Type definitions:
- Document type definitions
- Folder type definitions
- Secondary object type definitions
The label
is an optional string field to specify a project-specific schema versioning information. Its string value is limited to 128 characters.
<schema xmlns="http://optimal-systems.org/ns/dmscloud/schema/v5.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://optimal-systems.org/ns/dmscloud/schema/v5.0/ dmsCloud-schema.xsd"> <propertyStringDefinition> <id>from</id> <propertyType>string</propertyType> <cardinality>single</cardinality> <required>true</required> </propertyStringDefinition> <propertyStringDefinition> <id>to</id> <propertyType>string</propertyType> <cardinality>multi</cardinality> <required>true</required> </propertyStringDefinition> <propertyStringDefinition> <id>subject</id> <propertyType>string</propertyType> <cardinality>single</cardinality> <required>true</required> <defaultValue>hello</defaultValue> <maxLength>20</maxLength> <minLength>4</minLength> </propertyStringDefinition> <propertyDateTimeDefinition> <id>received</id> <propertyType>datetime</propertyType> <cardinality>single</cardinality> <required>true</required> </propertyDateTimeDefinition> <typeDocumentDefinition> <id>email</id> <baseId>system:document</baseId> <propertyReference>from</propertyReference> <propertyReference>to</propertyReference> <propertyReference>received</propertyReference> <contentStreamAllowed>required</contentStreamAllowed> </typeDocumentDefinition> </schema>
Scopes and Endpoints for Schemata
In the multi-tenant landscape of yuuvis® Momentum, it is important to be aware of the scope of property and object type definitions.
- Any object types or properties that should be available for all tenants should to be introduced to the global schema.
- To prevent cluttering the global schema and allow for duplicate names, app schemata can be used. They provide a namespace for properties and object types pertaining to a particular use case. An app schema is available in all tenants where the app is enabled.
- Each tenant can have exactly one tenant schema that allows to define properties and object types for usage only within the specific tenant.
Note: By default, the maximum number of property definitions in a tenant-specific schema is 20. A system integrator can change this limit via theschema.tenant.properties.limit
parameter in the SYSTEM service. If you want to increase this limit, it is recommended to increase the maximum number of fields in your Elasticsearch index as well. - For each tenant, the global schema and the tenant schema are merged with the app schemata for those apps that are enabled for the tenant. The resulting applied tenant schema is used for DMS operations like object import, update or search.
Depending on the schema scope, the schemata are managed via specific endpoints. Furthermore, their property and object type IDs have specific prefixes as described below.
Retrieval | Validation | Update | |
---|---|---|---|
global schema | GET /api/system/schema | POST /api/system/schema/validate | POST /api/system/schema |
app schema | GET /api/system/apps/{app}/schema | POST /api/system/apps/{app}/schema/validate | POST /api/system/apps/{app}/schema |
tenant schema of any tenant | GET /api/system/tenants/{tenant}/schema | POST /api/system/tenants/{tenant}/schema/validate | POST /api/system/tenants/{tenant}/schema |
tenant schema of the own tenant | POST /api/admin/schema/validate | POST /api/admin/schema |
Naming Conventions for Property and Object Type IDs
In every property definition and every object type definition the id
attribute is required. It is used to identify the object type or property. An ID is a string with a maximum of 63 characters and it must match the regular expression
([a-zA-Z][a-zA-Z0-9]*:)?[a-zA-Z][a-zA-Z0-9]*.
The IDs are also used as the name of the type, e.g., in query operations. Hence, it is recommended to choose meaningful values for type IDs.
The part before the :
character is the prefix. It is useful to specify the scope of the corresponding schema. Within the schema file, all references on the same ID have to be EITHER with OR without prefix. Depending on the situation, the prefix can be omitted, for example to broaden a search query across multiple application schemata.
- In tenant-specific (app-specific) definitions, only prefixes matching "ten" + <tenant name> ("app" + <app name>) are allowed. The tenant (app) name is case insensitive when used as a path or search parameter. If no prefix is specified, the prefix is added automatically in the applied tenant schema. Thus, the same object type name can occur in multiple tenant (app) schemata.
- In the global schema all prefixes are allowed, as long as they do not start with
ten
orapp
or equalsystem
. Alternatively, they can also have no prefix.
Note: An exception are column names in Table Property Definitions, where prefixes are prohibited as of version 2020 Winter.
As of 2021 Winter, it is possible to use the -
character as an additional separator within prefixes for tenant-specific IDs if matching the following regular expression:
([a-zA-Z][a-zA-Z0-9-]*:)?[a-zA-Z][a-zA-Z0-9]*
Property Definitions
General Attributes
All property definitions have the following attributes:
Attribute | Type | Required | Description |
---|---|---|---|
id | String | yes | The ID of the property matching the regular expression. It uniquely identifies the property in the schema. |
localNamespace | URI | no | By using namespaces, it is possible to form groups of properties and object types. |
description | String | no | Describes the property. |
propertyType
| Enum | yes | Specifies the type of this property. The following types are supported:
|
cardinality | Enum | yes | Defines whether the property can have a maximum of one or an arbitrary number of values. Possible values are single and multi. |
required | Boolean | yes | If This attribute can be overwritten in the property references of object type definitions. Hence, the same property can be required in one object type and not required in another object type. |
queryable | Boolean | no | Specifies whether or not the property may appear in the WHERE clause of a query statement. Default is true . false is only allowed for table properties. |
classification | String | no | Declares the classifications this property belongs to. There is no validation or use in the system itself. For example, string properties can be classified as Note: Make sure to validate the strings you set for the classification attribute, such that your client application will not fail if a string does not match the expected syntax. |
defaultValue | depending on thepropertyType | no | The value that the system sets for the property if no value is provided during object creation. If the Default values can be also applied by update. Assume a secondary object type has property types with default values. If you add this secondary object type to an existing object by update, these default values are applied, if the update does npt set values for these properties and the properties were not allowed in the object before the update. |
Depending on the property type, a property can have specific attributes.
Attributes for Integer Property Definitions
Attribute | Type | Required | Description | Technical Limit used as Default |
---|---|---|---|---|
maxValue | Integer | no | The maximum value allowed for this property | 9223372036854775807 |
minValue | Integer | no | The minimum value allowed for this property. | -9223372036854775808 |
Attributes for DateTime Property Definitions
Attribute | Type | Required | Description |
---|---|---|---|
resolution | Enum | no | The only supported value is date. If the resolution is set to date, the property can only store values without a time part and these values have the format yyyy-MM-dd. |
Attributes for Decimal Property Definitions
Decimal properties support values of 64-bit precision (IEEE 754). The values have to be specified in decimal notation. However in the table below, the technical limits are provided in base 2 scientific notation in order to display the values in a condensed and comfortable format. This format cannot be used to specify the value for a maxValue
or minValue
attribute in a decimal property definition.
Attribute | Type | Required | Description | Technical Limit used as Default |
---|---|---|---|---|
maxValue | Decimal | no | The maximum value allowed for this property | (2-2 -52 )·2 1023 |
minValue | Decimal | no | The minimum value allowed for this property. | -(2-2 -52 )·2 1023 |
Please note the additional limit of precision: values of magnitude smaller than 2 -1074 will be rounded to 0.
Attributes for String Property Definitions
Attribute | Type | Required | Description |
---|---|---|---|
maxLength | Integer | no | The maximum length (in characters) allowed for a value of this property. |
minLength | Integer | no | The minimum length (in characters) allowed for a value of this property. |
fulltextIndexed | Boolean | no | If |
In general, the length of a string is limited to 8192. Hence, the maximum value for maxLength
and minLength
is 8192.
Attributes for Table Property Definitions
Table
A table property definition contains a list of one or more sub-property definitions, the columns.
The cardinality
of a table property definition must be single
.
Table properties differ depending on the value of the property queryable
. If queryable
is false
, the table must not appear in WHERE
clauses in search queries. However, you can still find objects using full-text conditions on values stored in a table (query keyword CONTAINS
). If queryable
is true
, you can apply more precise search queries to a table, but you will need more disk space to store objects.
The number of rows and columns of a table property definition is limited to a maximum of 512 columns and 1024 rows.
Columns
Each column can have a different property type and has its own attributes, such as required
, defaultValue
or cardinality
(single
or multi
). The values are applied to each row entry.
As of version 2020 Winter, the column names specified via <id>examplecolumn</id>
must not contain a prefix. They have to follow the convention [a-zA-Z][a-zA-Z0-9]*. Otherwise, the schema containing the corresponding property definition will not pass the validation.
Example
<schema xmlns="http://optimal-systems.org/ns/dmscloud/schema/v5.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://optimal-systems.org/ns/dmscloud/schema/v5.0/ dmsCloud-schema.xsd"> <propertyTableDefinition> <id>aTableProperty</id> <propertyType>table</propertyType> <cardinality>single</cardinality> <required>false</required> <propertyStringDefinition> <id>col0</id> <propertyType>string</propertyType> <cardinality>single</cardinality> <required>false</required> </propertyStringDefinition> <propertyIntegerDefinition> <id>col1</id> <propertyType>integer</propertyType> <cardinality>single</cardinality> <required>false</required> </propertyIntegerDefinition> <propertyDateTimeDefinition> <id>col2</id> <propertyType>datetime</propertyType> <cardinality>single</cardinality> <required>false</required> </propertyDateTimeDefinition> <propertyDecimalDefinition> <id>col3</id> <propertyType>decimal</propertyType> <cardinality>single</cardinality> <required>false</required> </propertyDecimalDefinition> </propertyTableDefinition> </schema>
Structured Data Property Definition
As of version 2021 Summer, yuuvis® Momentum offers a property type for the storage of structured data in JSON format. Thus, it is possible to store interleaved data structures in a queryable way without defining each single sub-property in the schema. An example definition is shown in the code block below. The schema validation checks if the ID follows the convention. Only the value single
is allowed as cardinality
.
Note: The structured data properties should NOT be considered to replace the concept of a well-defined schema. They should be used only if the handling of objects' metadata via the conventional property definitions is not reasonable.
<propertyStructuredDataDefinition> <id>customerdetails</id> <propertyType>structureddata</propertyType> <cardinality>single</cardinality> <required>false</required> </propertyStructuredDataDefinition>
Even if the schema allows various structured data properties in an object, the instantiated object can contain a value for at most one structured data property.
There are strict rules for the values that can be specified for structured data properties assigned to an object. Find all details in the linked chapter.
>> Structured Data in Request Bodies
Structured data properties are queryable similar to table properties.
>> Queries on Structured Data
This example tutorial provides explanations and code examples to get an idea on how to define and specify structured data properties and on how to query them.
>> Setting and Querying Structured Data
Object Type Definitions
There are different groups of object type definitions:
In a schema, all object type definitions must appear in this order. First all document object type definitions, then all folder object type definitions and so on.
All object type definitions have the following attributes:
Attribute | Type | Required | Description |
---|---|---|---|
id | String | yes | The type ID of the object type. It uniquely identifies the object type in the schema. |
localNamespace | URI | no | By using namespaces, it is possible to form groups of properties and object types. |
description | String | no | Describes the property definition. |
baseId | Enum | yes | Specifies the base type of this object type. The following object types are supported:
|
propertyReference | String | no | Reference by ID to a property. An object type definition can have an arbitrary number of property references. |
A tenant-specific object type can have references to both tenant-specific and global properties.
Document Object Type Definitions
Document object types are the elementary object types. To store objects with content, the objects' type must be a document type.
Note
As of 2023 Spring, the predefined object type system:document
can be used as object type. It automatically has a floating reference on all SOTs that are available in the applied tenant schema as described below.
Custom document object type definitions have the following specific attributes:
Attribut | Type | Required | Description |
---|---|---|---|
contentStreamAllowed | Enum | yes | Specifies whether objects of this type must, must not, or may have content. Possible values are:
Note The attribute is also available for secondary object type definitions. If a secondary object type with a specified |
secondaryObjectTypeId | String | no | References to secondary object types (if there are several secondary object types, they are listed one below the other). Determines which secondary object types an instance of this object type receives upon creation ( Note: If you use the predefined In contrast to the CMIS specification (Content Management Interoperability Services), in which the secondary object types can be determined freely for each object instance, the schema specifies which secondary object types an object instance must have. |
Folder Object Type Definitions
Folder objects do not have their own content files in contrast to document objects. In yuuvis® Momentum versions 2020 Autumn and older, folders cannot be set up in a hierarchical structure – a folder inside a folder is not allowed. As of version 2020 Winter, a folder hierarchy is possible. Folders allow the grouping of multiple objects and have their own metadata which will not be inherited by the assigned objects. They act as object parent being referred to by its system:objectId
property value in the individual metadata of the child objects as system:parentId
and thus are also taken into account during the search. 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 objects assigned to them cannot be deleted.
The following code block shows the example folder object type definition "dossier" that can be integrated into any given schema. Note that folder object type definitions need to be defined after all document type definitions, yet before any secondary object type definitions.
<schema xmlns="http://optimal-systems.org/ns/dmscloud/schema/v5.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://optimal-systems.org/ns/dmscloud/schema/v5.0/ dmsCloud-schema.xsd"> <propertyStringDefinition> <id>str1</id> <propertyType>string</propertyType> <cardinality>single</cardinality> <required>true</required> </propertyStringDefinition> <typeDocumentDefinition> <id>documentType1</id> <baseId>system:document</baseId> <propertyReference>str1</propertyReference> <contentStreamAllowed>required</contentStreamAllowed> <secondaryObjectTypeId>secondaryA</secondaryObjectTypeId> </typeDocumentDefinition> <typeFolderDefinition> <id>dossier</id> <baseId>system:folder</baseId> <propertyReference>title</propertyReference> <propertyReference>type</propertyReference> <propertyReference>description</propertyReference> </typeFolderDefinition> </schema>
During import or update of a document object the object ID of the target folder is provided as the new object's parent ID (system:parentId
). Actions such as assigning objects, 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. Furthermore, as of version 2020 Winter, folders in a folder will be allowed. The folder hierarchy will represent a tree structure where each folder cannot appear as a parent in different levels of the structure. Hierarchies that do not adher to this structure will not pass validation.
After schema modification, a folder object can be created by importing the following metadata:
{ "objects": [ { "properties": { "system:objectTypeId": { "value": "dossier" }, "title": { "value": "My E-mail Folder #1" }, "type": { "value": "E-mails" }, "description": { "value": "This folder holds all the e-mails authored by me" } } } ] }
After extracting the object ID of the folder from the import response, you can start populating the folder with documents:
{ "objects": [ { "properties": { "system:objectTypeId": { "value": "documentType1" }, "system:parentId": { "value": "<the Folder object ID from the import response" }, "str1": { "value": "Some important business documents" }, "description": { "value": "This folder holds all the e-mails authored by me" } } } ] }
Folder object type definitions have the following specific attributes:
Attribute | Type | Required | Description |
---|---|---|---|
secondaryObjectTypeId | String | no | References to secondary object types (if there are several secondary object types, they are listed one below the other). Determines which secondary object types an instance of this object type receives upon creation ( In contrast to the CMIS specification (Content Management Interoperability Services), in which the secondary object types can be determined freely for each object instance, the schema specifies which secondary object types an object instance must have. |
Secondary Object Type Definitions
Secondary object types are abstract. This means that they cannot be instantiated. They allow you to design a more complex schema. In a way the concept of secondary object types is similar to the concept of inheritance.
Secondary object types can be used to group properties and then assign these property groups to object types (e.g., documents or folders). Like other object types, a secondary object type can have references to properties. They can also have no properties at all which can be understood as a way of categorizing document types (tagging). Document or folder object types can in turn reference secondary object types, which give them their properties. There are two ways for secondary object types to be referenced by an object in the schema definition: as static or as floating.
<secondaryObjectTypeId static="true">INV</secondaryObjectTypeId>
.<secondaryObjectTypeId static="false">INV</secondaryObjectTypeId>
.
As of 2023 Spring, the predefined object type system:document
automatically has a floating reference on all SOTs that are available in the applied tenant schema. Nevertheless, the rules for the contentStreamAllowed
attribute for the the individual SOTs have to be considered before they are assigned to an object.
The property groups of static referenced secondary object types are automatically available in all instances of the object type. Floating secondary object types can be handled in a flexible way during the import (POST /api/dms/objects endpoint) or at runtime for already existing instances of an object type with an update (POST /api/dms/objects/{objectId} / PATCH /api/dms/objects/{objectId}). The keywords "add":,
"value":
or "remove":
can be used in the "system:secondaryObjecttypeIds":
property area of the metadata.json filecan.
Keyword | Type | Description | metadata.json |
---|---|---|---|
"value": | array, comma-separated list | during import or update adds one or multiple secondary object types to an object Note that the list of "floating" secondary object types transferred will replace all existing ones. This includes the related properties and their metadata values. If you want to keep an existing "floating" secondary object type, you have to list it as well. | { "objects": [{ "properties": { "system:objectTypeId": { "value": "appSot:document" } "system:secondaryObjectTypeIds": { "value": ["INV","SUP"] } ... |
"add": | string | during update adds a single secondary object type to an object | { "objects": [{ "properties": { "system:secondaryObjecttypeIds": { "add": "INV" }, ... |
"remove": | string | during update removes a single secondary object type from an object Note: The metadata assigned to the object by referencing the secondary object type will be deleted for the current object version! | { "objects": [{ "properties": { "system:secondaryObjecttypeIds": { "remove": "INV" }, ... |
Document object types have a system:secondaryObjectTypeIds
property that contains the secondary object types associated with the document object type in the schema. This allows secondary object types to be taken into account during the search. The secondary object type must be explicitly specified in the FROM clause: select * from appSot:INV.
The system:secondaryObjectTypeIds
property is set by the repository using the schema.
<schema xmlns="http://optimal-systems.org/ns/dmscloud/schema/v5.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://optimal-systems.org/ns/dmscloud/schema/v5.0/ dmsCloud-schema.xsd"> <propertyStringDefinition> <id>appSot:dateOfReceipt</id> <propertyType>date</propertyType> <cardinality>single</cardinality> <required>true</required> </propertyStringDefinition> <propertyStringDefinition> <id>appSot:comment</id> <propertyType>date</propertyType> <cardinality>single</cardinality> <required>true</required> </propertyStringDefinition> <propertyStringDefinition> <id>appSot:invoiceNo</id> <propertyType>string</propertyType> <cardinality>single</cardinality> <required>true</required> </propertyStringDefinition> <propertyStringDefinition> <id>appSot:paymentTerm</id> <propertyType>string</propertyType> <cardinality>single</cardinality> <required>true</required> </propertyStringDefinition> <typeDocumentDefinition> <id>appSot:document</id> <baseId>system:document</baseId> <propertyReference>appSot:dateOfReceipt</propertyReference> <contentStreamAllowed>required</contentStreamAllowed> <secondaryObjectTypeId>appSot:basicInfo</secondaryObjectTypeId> </typeDocumentDefinition> <typeSecondaryDefinition> <id>appSot:basicInfo</id> <baseId>system:secondary</baseId> <propertyReference>appSot:comment</propertyReference> </typeSecondaryDefinition> <typeSecondaryDefinition> <id>appSot:invoice</id> <baseId>system:secondary</baseId> <propertyReference>appSot:invoiceNo</propertyReference> <propertyReference>appSot:paymentTerm</propertyReference> </typeSecondaryDefinition> </schema>
Consider the example schema. If a document of the type appSot:document
is created, it may have values for the properties appSot:dateOfReceipt
and appSot:comment
. For the appSot:dateOfReceipt
property definition this is obvious, because there is a direct reference in the document type definition of appSot:document
.
The appSot:comment
property definition is not directly referenced but the definition of appSot:document
has a reference to the secondary object type appSot:basicInfo
which references the appSot:comment property definition. Thus, both properties are available for creating documents.
Furthermore, properties passed on by secondary object types are treated like "regular" properties in a document. The attributes of a property are taken into account. For example, a document of the type appSot:document
not only may have a value for appSot:comment
, it must have a value, because it is a required property. It makes no difference, whether a document type references the property definitions directly or indirectly via a secondary object type reference.
You cannot tell from the metadata of a document any longer if a property is referenced directly or indirectly in the schema. All properties are plain in the properties list. For example, the metadata of a document based on the appSot:document
document type definition may look like this:
{ "objects": [ { "properties": { "system:objectId": { "value": "7bce6618-2b0e-4abf-af26-e4137e6b0461" }, "system:baseTypeId": { "value": "system:document" }, "system:objectTypeId": { "value": "appSot:document" }, "system:secondaryObjectTypeIds": { "value": [ " appSot:basicInfo" ] }, <...> " appSot:dateOfReceipt": { "value": "2020-02-20T02:02:20.220Z" }, "appSot:comment": { "value": "Yearly invoice - payment 1 out of 12 monthly payments." } }, "contentStreams": [ <...> ] } ] }
Secondary object type definitions have the following attributes:
Attribute | Type | Required | Description |
---|---|---|---|
| Enum | no | Can substantiate the For the final document, content will be For the final document, content will be Conflict situation leading to invalid documents: any combination of at least once
If |
Validation
It is not possible to post an invalid schema via yuuvis® Momentum API. A new schema is always validated before it is introduced into the system. Additionally, specific validation endpoints are available to check the new schema before sending an update request.
>> Schema Management Endpoints
The response of schema validation (or update) endpoints are always structured as shown in the following example.
{ "validationErrors": [], "changes": [{ "type": 1000, "message": "Document type was removed.", "id": "appEmail:obsoleteType", "affectedObjects": { "tenant1": 10, "tenant2": 4 } }, { "type": 1200, "message": "A property reference was removed from a document type.", "id": "appEmail:email", "reference": "appEmail:bcc", "affectedObjects": { "tenant1": 1, "tenant2": 3 } } ] }
Failed Validation
If the schema is invalid, the corresponding validation errors are listed in validationErrors
as described here:
>> Error Lists during Validation Processes
Passed Validation
If the schema is valid, the validationErrors
list is empty. The schema can be (is) updated.
However, the new schema might define different structures for DMS objects that are not matched by previously imported objects. Thus, affected objects are invalidated as soon as the new schema is introduced into the system. Invalidated objects are still stored in the system, but their availability and behavior deviates from expectation as described in the following table and below.
The changes
list in the validation request contains all detected differences between the new schema and the previously used schema that could lead to invalidation of existing DMS objects. The following table documents the detectable types of schema changes and their individual values/meanings of the sub-parameters for each element in the changes
list:
type
message
id
reference
- if the validation (or update) endpoint is called with the query parameter
verbose=true
:affectedObjects
Note
A non-empty changes
list in the validation request does NOT prevent a schema update.
type | message | id | reference | Description and Impact of Schema Update |
---|---|---|---|---|
1000 | Document type was removed. | ID of the removed document type | - | As it is not possible to replace the object type of existing objects, it is not possible to adjust affected objects. They cannot be updated anymore. |
1001 | Folder type was removed. | ID of the removed folder type | - | See impacts of change type 1000. |
1100 | A secondary object type reference was removed from a document type. | ID of the document type | ID of the secondary object type | If the corresponding SOT includes required properties, see the impacts of change type 1200. |
1101 | A secondary object type reference was removed from a folder type. | ID of the folder type | ID of the secondary object type | If the corresponding SOT includes required properties, see the impacts of change type 1200. |
1110 | A document type got a new static secondary object type reference. | ID of the document type | ID of the secondary object type | A static secondary object type reference was added to a document type definition. Or an existing non-static secondary object type reference on a document type definition became static. If the corresponding SOT includes required properties, see the impacts of change type 1300. |
1111 | A folder type got a new static secondary object type reference. | ID of the folder type | ID of the secondary object type | A static secondary object type reference was added to a folder type definition. Or an existing non-static secondary object type reference on a folder type definition became static. If the corresponding SOT includes required properties, see the impacts of change type 1300. |
1200 | A property reference was removed from a document type. | ID of the document type | ID of the property | Any metadata retrieval of affected objects excludes the removed property. Search result lists, e.g., are affected as well. However, the existing values remain in the database and the search index. Thus, in case of a removed string property, the existing values are still considered for full-text search. The corresponding values are removed automatically during the next PATCH or POST update on the affected objects. |
1201 | A property reference was removed from a folder type. | ID of the folder type | ID of the property | See impacts of change type 1200. |
1210 | A property reference was removed from a secondary object type. | ID of the secondary object type | ID of the property | See impacts of change type 1200. |
1300 | A non-required property type became required. | ID of the property | - | POST metadata updates on affected objects are only allowed if the new required property is properly added. |
1310 | A required property reference was added to a document type, or a non-required property reference became required. | ID of the document type | ID of the property | See impacts of change type 1300. |
1311 | A required property reference was added to a folder type, or a non-required property reference became required. | ID of the folder type | ID of the property | See impacts of change type 1300. |
1320 | A required property reference was added to a secondary object type, or a non-required property reference became required. | ID of the secondary object type | ID of the property | See impacts of change type 1300. |
2000 | Content stream becomes required on a document type. | ID of the document type | - | Updates on affected objects are only allowed if a binary content file is thereby added. |
2001 | Content stream becomes not allowed on a document type. | ID of the document type | - | Updates on affected objects are only allowed if a binary content file is thereby deleted. Thus, affected objects with a binary content file under retention cannot be updated via yuuvis® Momentum at all. |
2010 | Content stream becomes required on a secondary object type. | ID of the secondary object type | - | See impacts of change type 2000. |
2011 | Content stream becomes not allowed on a secondary object type. | ID of the secondary object type | - | See impacts of change type 2001. |
3000 | The cardinality of a property becomes 'single'. | ID of the property | - | Updates on affected objects are only allowed if the value of the modified property is properly replaced. Especially, pure tag and content operations are only allowed after a proper update of the metadata. |
Following schema changes are NOT detected during the validation, but can affect existing objects as well:
- The type of a property definition changed. → See impacts of change type 3000.
- The range of a property definition changed. → See impacts of change type 3000.
- A default value was added to a property definition or reference. → The new default value is only used for the creation of new objects.
- In a table property definition, the value for the queryable attribute was changed. → Affected objects can be adjusted via COMMANDER service.
- The base type of an object type changed from
system:folder
tosystem:document
with content stream required. → See impacts of change type 2000. - The base type of an object type changed from
system:document
tosystem:folder
. → See impacts of change type 2001. - The base type of an object type changed from
system:document
orsystem:folder
tosystem:secondary
. → See impacts of change type 1000.
System Properties
General Object Properties
In addition to the properties assigned to the object types in the schema, each instantiated object has a set of general system properties. Some system properties are set by the system and some system properties can be set by the user.
Property | Type | Description | Set by |
---|---|---|---|
system:objectId | string | Identifies the object in the database. | system |
system:baseTypeId | string | Identifies the object type the object instantiates. Secondary object types are not allowed. | system |
system:objectTypeId | string | Required during an import and cannot be changed lateron. Identifies the object's type. | user |
| JSON list of strings | Contains the secondaryObjectTypeId for each secondary object type associated with the document object type in the schema. | user |
system:createdBy | string | userId of the user that has initially created the object. | system |
system:creationDate | string | Date of the object's creation in format yyyy-MM-ddTHH:mm:ss.fffZ. | system |
system:lastModifiedBy | string | userId of the user that sent the last successful POST request on the object. | system |
system:lastModificationDate | string | Date of the last successful POST request on the object as a string in format yyyy-MM-ddTHH:mm:ss.fffZ. | system |
| string |
During an import or update operation, the object can be assigned to an existing folder by referencing its | user |
system:parentObjectTypeId | string | Identifies the folder object type of the parent folder that is specified by Available for document object types and as of version 2020 Winter, also for folder object types. | system |
system:versionNumber | integer | Integer object version number. Corresponds to the number of POST requests on the object starting with the initial creation. | system |
system:tenant | string | Identifies the tenant the object belongs to. | system |
system:traceId | Hexadecimal lowercase string with maximum length 16 | The traceid of the import operation or last update operation.Unique process number of any operation. If not specified in the request, a random string value will be set. | system |
| JSON table of strings and integers | Contains the properties of the tags assigned to the object. >> Tagging | user |
| string | Only available for documents. Secondary object type The binary content of the object cannot be changed or deleted before this date, but metadata updates are allowed. In an update request, the | user |
| string | Only available for documents. Secondary object type This date defines the start of the retention time. It has to be earlier in time than the | user |
| string | Only available for documents. Secondary object type If | user |
Content Stream Properties
The contentStreams
group of properties comprises system properties of document objects containing binary content. Thus, their contentStreamAllowed
attribute has to be required
or allowed
. The properties in contentStreams
contain all information necessary to be able to handle binary content. Depending on the type of operation, different properties are required for import/update requests or are displayed in a response.
Property | Type | Description | In an Import/Update Request | In a Response |
---|---|---|---|---|
contentStreamId | String | Points to existing content within a repository. | Required only for pointing to existing content during an import. If not specified, the system generates a UID. | displayed |
length | Integer | Length of the binary content, determined by the system. | - | displayed (if system could determine the value) |
mimeType | String | Mime type of the content file. The CONTENTANALYZER service can be configured to determine (scenario A) or not determine (scenario B) the If | Scenario A: The CONTENTANALYZER determines In an import request, the automatically determined Scenario B: In an import request via POST /api/dms/objects, In a content update via POST /api/dms/objects/{objectId}/contents/file, | displayed |
fileName | String | Name of the content file. | If In a content update via POST /api/dms/objects/{objectId}/contents/file, In an import request via POST /api/dms/objects, | displayed |
digest | String | SHA-256, automatically determined by REPOSITORY Service based on the binary content. Can be used to detect changes in the binary content. >> GET /api/dms/objects/{objectId}/actions/validate/digest | - | displayed |
repositoryId | String | ID of the repository that will be used for storage of the binary data. | Required only for pointing to existing content during an import. If not specified, the default repository defined in the repository service configuration will be set. | displayed |
archivePath | String | Path structure for the content file within the binary storage. | Required only for pointing to existing content during an import if reconstruction is not possible with metadata information (e.g,, if a pathTemplate containing dynamic path elements like DATE is configured in the archive profile). | displayed if it was set
|
range | String | Applies to compound documents only. Defines a certain segment of compound documents that should be provided for content retrievals. | Optional in the import request body and only available for compound documents. | displayed only if it was set |
ci d | String | Assigns the corresponding multipart content. | Required in the import request body. Not needed later on and therefore not stored in the system. | - |