1. Overview
This tutorial shows how to change the set of available metadata properties for individual DMS objects during their entire lifecycle. Classify objects at a later point in time, add or remove property groups at runtime by defining and referencing floating secondary object types (SOTs).
2. Requirements
To work through this tutorial, the following is required:
-
Set-up yuuvis® Momentum core system (see Installation Guide)
-
A user with
readandwritepermissions on a document type in the system (see Access Management)
3. Example Use Case
Since a high variety of customized business processes can be set up for managing content, this tutorial shows one basic example to give you a better understanding of the idea behind the provided functionality. Let us imagine the following initial situation: we want to import documents and do not know the content types yet. At a later point in time, if the content type is known, we would like to add the needed group of properties for invoice, delivery slip and supplier metadata by using floating secondary object types.
3.1. Defining Document Object Types
Add a new document object type definition (document) with a single property (DateOfReceipt) to your schema to enable the import in general. To store objects with content, the objects' type must be a document type and the contentStreamAllowed attribute must specify that this type can or must have content (allowed or required).
...
<typeDocumentDefinition>
<id>appSot:document</id>
<baseId>system:document</baseId>
<contentStreamAllowed>allowed</contentStreamAllowed>
<propertyReference>appSot:DateOfReceipt</propertyReference>
</typeDocumentDefinition>
...
3.2. Define Secondary Object Types
Add three new SOTs to your schema - each representing a group of properties used for specifying the content type in detail (INV invoice, DEL delivery slip and SUP supplier). At this point, it does not matter whether the SOT will be used later on by a document object type as static or floating.
...
<typeSecondaryDefinition>
<id>appSot:INV</id>
<baseId>system:secondary</baseId>
<propertyReference>appSot:invoiceNo</propertyReference>
</typeSecondaryDefinition>
<typeSecondaryDefinition>
<id>appSot:DEL</id>
<baseId>system:secondary</baseId>
<propertyReference>appSot:deliverySlipNo</propertyReference>
</typeSecondaryDefinition>
<typeSecondaryDefinition>
<id>appSot:SUP</id>
<baseId>system:secondary</baseId>
<propertyReference>appSot:name</propertyReference>
<propertyReference>appSot:address</propertyReference>
<propertyReference>appSot:phone</propertyReference>
</typeSecondaryDefinition>
...
3.3. Adding References to Secondary Object Types
Now, add three references to the secondary object types for your defined document object type (document). All three are floating references (static="false"), since they should only be used if the content type is known and the properties are useful and necessary.
...
<typeDocumentDefinition>
<id>appSot:document</id>
<baseId>system:document</baseId>
<contentStreamAllowed>allowed</contentStreamAllowed>
<secondaryObjectTypeId static="false">appSot:INV</secondaryObjectTypeId>
<secondaryObjectTypeId static="false">appSot:DEL</secondaryObjectTypeId>
<secondaryObjectTypeId static="false">appSot:SUP</secondaryObjectTypeId>
</typeDocumentDefinition>
...
3.4. Importing New Documents
First of all, import your documents as a simple instance of document including the values for the date of receipt using the POST /api/dms/objects endpoint.
{
"objects": [{
"properties": {
"system:objectTypeId": {
"value": "appSot:document"
}
"appSot:DateOfReceipt": {
"value": "2020-10-07"
}
}
}]
}
3.5. Adding Secondary Object Types
3.5.1. During the Lifecycle
If the content type is known, you update the DMS object’s metadata structure by assigning the necessary SOTs (POST /api/dms/objects/{objectId} or PATCH /api/dms/objects/{objectId}). Use the keyword add for a single secondary object type, or value with a comma separated list, e.g., ["INV","SUP"] for multiple ones. Note that by using the keyword value, the list of floating SOTs transferred will replace all existing ones. This includes the related properties and metadata values. If you want to keep the existing floating SOTs, you have to list them as well.
{
"objects": [{
"properties": {
"system:secondaryObjecttypeIds": {
"add": "INV"
},
"appSot:invoiceNo": {
"value": "K0815-2020-1894834"
}
}
}]
}
{
"objects": [{
"properties": {
"system:secondaryObjecttypeIds": {
"value": ["INV","SUP"]
},
"appSot:invoiceNo": {
"value": "K0815-2020-1894834"
},
"appSot:name": {
"value": "Supplier Smith"
},
"appSot:address": {
"value": "7 Main Street, London"
},
"appSot:phone": {
"value": "004420834029390"
}
}
}]
}
3.5.2. Right at the Start of the Lifecycle (Import)
If you already know what content type you are going to import (e.g., an invoice), you can add one or more floating SOTs right away. Use the keyword value with a comma separated list, e.g., ["INV","SUP"] and the POST /api/dms/objects endpoint.
{
"objects": [{
"properties": {
"system:objectTypeId": {
"value": "appSot:document"
}
"system:secondaryObjectTypeIds": {
"value": ["INV","SUP"]
}
"appSot:DateOfReceipt": {
"value": "2020-10-07"
}
}
}]
}
3.6. Removing Secondary Object Types
When a floating SOT is not needed any longer, you remove it from the DMS object using the update endpoints (POST /api/dms/objects/{objectId} or PATCH /api/dms/objects/{objectId}). All related properties and metadata values will be removed as well.
{
"objects": [{
"properties": {
"system:secondaryobjecttypeids": {
"remove": "INV"
}
}
}]
}
3.7. Searching for Objects
You search for objects that use secondary object types by explicitly specifying them in the FROM clause:
The search result delivers the entire object and not only the properties of the specified secondary object type.