| Page Properties |
|---|
|
| Product Version |
|
|---|
| Report Note | presentable, review (move stuff into tutorials) |
|---|
| Assignee |
|
|---|
Resources & Remarks - There is already good text available in the tutorial section - it needs to be split into concept article and tutorial.
- The app schemata article, originally located in the Tutorials section, has been moved into this article. The REST endpoint overview around the application schemata topic should probably be moved back into the tutorials and linked here.
- v2.2 - Inga: "floating" secondary object type infos added
- Antje: add Content Stream Properties as a new section in the hidden part.
- Antje: move Content Stream Properties to the public section "System Properties"
- Antje: contentStreamAllowed attribute added for SOTs
Modification History | Name | Date | Product Version | Action |
|---|
| Antje | 08 FEB 2021 | 2020 Winter | New page properties macro. | | Agnieszka | 02 JUNE 2021 | 2021 Summer | rLANG (partial) |
|
...
Attribute | Type | Required | Description |
|---|
contentStreamAllowed
(As of product version 2020 Autumn)
| Enum | no | Can substantiate the contentStreamAllowed attribute of document type definitions. Possible values are analogous to document object type definitions: required, notallowed, allowed. For the final document, content will be allowed if only allowed values occur in the document type definition and included secondary object type definitions for this attribute. For the final document, content will be required (notallowed) if the value is required (notallowed) in at least one object type definition – either document type definition or included secondary object type definition. Conflict situation leading to invalid documents: any combination of at least once required and at least once notallowed in included secondary object type definitions or the document object type definition itself. - If the conflict occurs between the document object type definition and a secondary object type definition, the whole schema is invalid.
- If the conflict occurs between secondary object type definitions with at least one of them referenced as static, the schema is valid but the document validation will fail (instantiated documents will be invalid).
If the conflict occurs exclusively between secondary object type definitions referenced as floating, a document cannot have conflicting secondary object types at the same time. If a secondary object type with the value required (notallowed) is added to the document, all secondary object types with the value notallowed (required) must be removed by means of the keyword "remove":.
If contentStreamAllowed is specified in a secondary object type definition, this secondary object type cannot be referenced in folder object type definitions. The schema would be invalid. |
...
| 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. If not specified, the system generates a UID. | displayed |
length | Integer | Length of the binary content, determined by the system. | -displayed | displayed (if system could determine the value) |
mimeType | String | Mime type of the content file. Determined by the content analysis, but can be overwritten by user specification in the import bodyThe CONTENTANALYZER service can be configured to determine (scenario A) or not determine (scenario B) the mimeType.
>> serviceConfiguration.json If mimeType can/should not be determined and is not specified, the default value application/octet-stream is used. | Scenario A: The CONTENTANALYZER determines mimeType from the corresponding binary content file. It is not possible to set a value via a request header. In an import request, the automatically determined mimeType can be overwritten by specifying a value in the import JSON. Scenario B: In an import request via POST /api/dms/objects, mimeType is determined based on the Content-Type header that is specified for the request's part related to the corresponding binary content file. If mimeType is specified in the import JSON, this value is used instead of the automatically determined one. In a content update via POST /api/dms/objects/{objectId}/contents/file, mimeType is determined based on the Content-Type header specified for the entire HTTP request. | displayed |
fileName | String | Name of the content file. Can be set in the request body. If not specified, fileName will be determined automatically depending on the operation type: During an import, fileName is automatically determined from the multipart information. In case of a pure content update, fileName will be determined from the content disposition | If fileName is not specified as follows and cannot be determined, the default value upload.bin will be set. In a content update via POST /api/dms/objects/{objectId}/contents/file, fileName is determined based on the Content-Disposition header that is specified for the entire HTTP request. In an import request via POST /api/dms/objects, fileName is determined based on the Content-Disposition header that is specified for the request's part related to the corresponding binary content file. If fileName is specified in the import JSON, this value is used instead of the automatically determined one. | displayed |
digest | String | SHA-256, automatically determined from the binary content. | - | displayed |
repositoryId | String | ID of the repository that will be used for storage of the binary data. | Required only for pointing to existing content. If not specified, the default repository defined in the repository service configuration will be set. | displayed |
archivePath | String | Additional and optional path structure of the stored object. | Required only for pointing to existing content if reconstruction is not possible with metadata information | displayed only if it was set |
range | String | Applies to Compound Documents only. Defines a certain segment from compound documents that should be provided for content retrievals.
| Optional in the request body and only available for compound documents. | displayed only if it was set |
cid | String | Assign the corresponding multipart content. | Required in the import request body. Not needed later on and therefore not stored in the system. | - |
...
The app schema endpoints are:
When uploading an app schema, all properties that do not specify a prefix will have that prefix generated as app<app name> where <app name> is equal to the path parameter {app}.
...
Each object type ID and property type ID has the prefix ten + <tenant name>. Thus, the same object type name can occur in multiple tenant schemata.
...
| Info |
|---|
|
Read on
| Section |
|---|
| Column |
|---|
| | Insert excerpt |
|---|
| Managing the Schema |
|---|
| Managing the Schema |
|---|
| nopanel | true |
|---|
|
Keep reading
|
| Column |
|---|
| | Insert excerpt |
|---|
| Importing Documents via Core API |
|---|
| Importing Documents via Core API |
|---|
| nopanel | true |
|---|
|
Keep reading
|
| Column |
|---|
| | Insert excerpt |
|---|
| Changing Schema Structures ("Schema Flow") |
|---|
| Changing Schema Structures ("Schema Flow") |
|---|
| nopanel | true |
|---|
|
Keep reading
|
|
|
...