Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties
hiddentrue
idPROGRESS

Product Version2021 Summer
Report Note
AssigneeAntje

Resources & Remarks

Modification History

NameDateProduct VersionAction
Antje29- APR 20212021 SummerWriting started.
Agnieszka02 JUNE 20212021 SummerrLANG



Excerpt

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

...

The representation of objects in yuuvis® Momentum depends on their situation within the processing chain, but is always organized in a JSON structure. On the top level, this JSON structure always contains always the list objects. Each entry of the this list represents a set of metadata assigned to one object. The metadata are grouped into sections. The section properties is always present whereas the sections contentStreams, renditions and options are not always present.

During an import process, the JSON objects list is integrated into a multipart body. Thus, it is possible to handle binary content together with the metadata in one call. Multiparts are not discussed in this article, please . Please refer to the import endpoint description POST /api/dms/objects.

...

The code block below shows a small example for an objects list as it could appear in an import request body. Since there is no contentStreams section contentStreams, no binary content file will be assigned to the object. The properties section properties contains the required system:objectTypeId with the specified value that has to be an object type available in the applied schema. Additionally, a property name is set , that which does not have any prefix. The import body is valid only if the property is defined in the global schema.

...

Code Block
languageyml
titleSmall Example: Import without Content
{
	"objects": [{
		"properties": {
			"system:objectTypeId": {
				"value": "smallDocument"
			},
			"name": {
				"value": "exampledocument-without-content"
			}
		}
	}]
}

The metadata will be automatically enriched with the not-specified system properties automatically. If the same object is retrieved later, they these properties will be listed in the response body as shown in the following example code block.

Code Block
languageyml
titleSmall Example: Retrieve Retrieving Metadata
{
    "objects": [{
        "properties": {
            "system:objectId": {
                "value": "cdc7095f-a5ce-486d-92a7-6d0955d969ee"
            },
            "system:baseTypeId": {
                "value": "system:document"
            },
            "system:objectTypeId": {
                "value": "smallDocument"
            },
            "system:createdBy": {
                "value": "0d7fd0be-6a0b-4d3b-933c-25e0c4c5d794"
            },
            "system:creationDate": {
                "value": "2018-01-26T15:21:170Z"
            },
            "system:lastModifiedBy": {
                "value": "0d7fd0be-6a0b-4d3b-933c-25e0c4c5d794"
            },
            "system:lastModificationDate": {
                "value": "2018-01-26T15:21:170Z"
            },
            "system:versionNumber": {
                "value": 1
            },
            "system:tenant": {
                "value": "tenant1"
            },
            "system:traceId": {
                "value": "97a35859dbb4c435"
            },
            "name": {
				"value": "exampledocument-without-content"
			}
    }]
}

...

The values for table properties are specified in two lists as shown in the example below. The names of the table columns are listed in the correct order in columnNames. In the value array, for each table row a list of individual values is expected. The length of those lists has to equal to the length of the the  columnNames list columnNames. The individual values need to have the appropriate type that is defined in the table property definition for the corresponding column.

...

Tags can be managed independently but also also in one call together with the metadata. The tags are stored in the system property system:tags system property in table format as described before.

...

The section contentStreams is always present for objects with a binary content file assigned to them. It is a list with one entry containing a set of content stream properties.
>> Schema - Defining Object Types#DefiningObjectTypes-ContentStreamProperties

Each object with an assigned content file stored in yuuvis® Momentum has the full set of those properties in addition to the previously described properties section.

...

Code Block
languageyml
titleExample with already existing Content
{
	"objects": [{
		"properties": {
			"system:objectTypeId": {
				"value": "largeDocument"
			},
			"name": {
				"value": "exampledocument-with-content"
			}
		}
		"contentStreams": [{
            "contentStreamId": "2B797243-A1F5-11EA-A814-9FABD98CE7A7",
            "repositoryId": "repo252"		
        }]
	}]
}

The metadata will be automatically enriched with the not-specified system properties automatically. If the same object is retrieved later, they the properties will be listed in the response body as shown in the following example code block.

...

If a content file of appropriate format is imported in yuuvis® Momentum, the CONTENTANALYZER service can create a full-text rendition. The service will automatically add the section renditions to the corresponding object automatically.

If the section renditions is already specified by the user in the initial request body, the CONTENTANALYZER will not extract the full - text from the corresponding content file. Instead, the user-specified text - rendition will be stored in the Elasticsearch index. This might be useful if the CONTENTANALYZER service is not used or the content file's format is not supported for the full-text analysis.

The example objects list below is taken from an import request body in which an email e-mail file is assigned as binary content file. Since also the section renditions is is also specified, the CONTENTANALYZER will not analyse analyze the email file. The plain text read from the file content.txt will be stored in Elasticsearch for the full-text search.

Code Block
languageyml
titleExample from an import request body.
{
	"objects": [{
		"properties": {
			"enaio:objectTypeId": {
				"value": "E13C7EBF4B974B3A9FF296C01F90D0EE"
			},
			"sysfrom": {
				"value": "Garco Meissler <garco@example.de>"
			},
			"systo": {
				"value": "Dudreas Annkel <dudreas@example.de>"
			},
			"syscc": {
				"value": "Kruedeas Anger <kruedeas@example.de>"
			},
			"syssubject": {
				"value": "Wachsmalstift rückwärts kontrollieren"
			},
			"redline:baseTypeId": {
				"value": "DOCUMENT"
			},
			"redline:mandant": {
				"value": "default"
			}
		},
		"contentStreams": [{
			"mimeType": "message/rfc822",
			"fileName": "upload.eml",
			"cid": "cid_63apple"
		}],
		"renditions": [{
			"mimeType": "text/plain",
			"kind": "text",
			"contentStream": {
				"length": 39939,
				"mimeType": "text/plain",
				"fileName": "content.txt",
				"cid": "rendition_0"
			}
		}]
	}]
}

...