...
| Page Properties | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
Resources & Remarks
Modification History
Modified:
To be added in table row "name": As of version 2021 Summer, the suffix new section: Resistant TagsAs of version 2021 Summer, it is possible to assign resistant tags that are automatically transferred to the new version of an object. If a new version of an object is created, e.g., by a POST update of the metadata or the binary content file, those tags will be removed from the old object version and assigned to the new object version. As usual, the previous object version will not have any tags afterwards. However, the new version will have all the resistant tags assigned to it that were originally assigned to the previous version. Resistant tags are identified by the suffix
|
| Excerpt |
|---|
Tags are used to describe the status of an object within a process chain independently of the object's metadata, which means no need of definition in the schema and no triggering of new versions. |
...
The special feature of tags is the independence of versioning and schema definitions. Tags can only be attached to the current version of an object, whereas previous versions cannot have tags. For version-specific information, metadata provide the suitable options. They have to be defined in the Schema.
| Note | ||
|---|---|---|
| ||
If a new version of an object is created, e.g. by a POST update of the metadata or the binary content file, all tags are removed from the object. The new version will not have any tags. In order to assign version-independent processing information, please use resistant tags as described below. |
Tag Management
Endpoints
Tags can be set in any object creation body in the system property system:tags. In the same way, it is also possible to set tags for the new version of an object in any POST/PATCH update call. A POST update without the explicit specification of already existing tags will remove them from the corresponding object.
...
| Property | Type | Description | In a request |
|---|---|---|---|
name | String | Name of the tag for identification. It has to be unique for the corresponding object. The tag names are validated during a tag creation or update process. To pass the validation, they have to match the regular expression [a-z](:?[a-z][a-z0-9]*)* and must not be longer than 32 characters. As of version 2021 Summer, the suffix | required |
state | Integer | Represents the status of the corresponding object in a process chain. | required |
creationDate | String | Date and time of the last modification of the tag. It is set automatically by the system. | optional, only available in search queries |
traceidtraceId | Hexadecimal lowercase string with maximum length 16 | Unique process number of any tag operation. If not specified in the request, a random String value will be set after the tag operation. In a tag update or delete request, the request parameter Per default, | optional, specified by means of the HTTP header X-B3-TraceId |
In a request, the corresponding properties are included directly in the URL for the call of the endpoint. In contrast, if tags are displayed in a response body, their properties are listed as a part of a JSON structure in the value of the property system:tags.
Handling of the
...
'traceId'
The traceid traceId is a unique process number that provides the possibility to retrace tag operations and tune the update or deletion permissions for the tag. In the HTTP header, the request parameter traceIdMustMatch can be changed from its default value false to true. Thus, two different scenarios are possible:
- Call with
traceIdMustMatch=false(default)traceidtraceIdfor the tag.
In case of a tag deletion, the endpoint removes the tag from the corresponding object without checking the currenttraceidtraceIdof the tag to be deleted. - Call with
traceidMustMathtraceIdMustMath=true
An update or deletion endpoint takes thetraceidtraceIdfrom the request and compares it to the currenttraceidtraceIdof the requested tag. The update or deletion operation will be performed only if the values are matching. Thus, the tag can only be updated or deleted if the previoustraceidtraceIdis known to the caller.
In case of a tag creation, this condition would never match and should therefore not be used.
Anchor ResistantTags ResistantTags
Resistant Tags
As of version 2021 Summer, it is possible to assign resistant tags that are automatically transferred to the new version of an object. If a new version of an object is created, e.g., by a POST update of the metadata or the binary content file, those tags will be removed from the old object version and assigned to the new object version. As usual, the previous object version will not have any tags afterwards. However, the new version will have all the resistant tags assigned to it that were originally assigned to the previous version.
The resistant Resistant tags are identified by the suffix :resistant at the end of the string tag name.
...