Versions Compared

Key

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


Dynamic catalogs are introduced with version 2021 Summer at the latest. Beginning with 2021 Summer Alpha2, the Web-API Gateway offers the endpoints for maintaining such catalogs, and the users are offered a pick-up list including an edit dialog if the property readonly is not set.

These catalogs are named dynamic because they can be changed by responsible users without changing the schema configuration.

...

Page Properties
hiddentrue
idrDOC

Product Version2021 Summer
Report Note
AssigneeMartin & Antje

Resources & Remarks


Modification History

NameDateProduct VersionAction
Antje13 APR 20212021 SummerrDOC



Excerpt

Explanation of the usage of dynamic catalogs provided by the Web-API Gateway as editable pick-up lists in metadata forms.


Section
bordertrue


Column

Table of Contents

Table of Contents
exclude(Table of Contents|Summary|Read on|Another Tutorial|Another Concept Article|Another interesting Tutorial|Ressources|Remarks|Authentication against the Core API|Graphical Overview \/ Use Cases \(Flows\)|Login to the Core API \(Java\)|yuuvis® Momentum Services|Basic Use Case Flows)


Introduction

In some metadata fields, you may want to provide a selection list of possible values from which the users have to choose. Those lists are configured via so-called catalogs. By setting or not setting the property readonly in their schema definition, they can be configured to be editable directly in your client  for users with the proper authorization. A change in the schema definition is not required in order to modify the so-called dynamic catalogs.

Dynamic catalogs are introduced with version 2021 Summer at the latest. Beginning with 2021 Summer Alpha2, the Web-API Gateway offers the endpoints for maintaining such catalogs.

Notes:

  • We use the term catalog from a technical perspective and the term list from the user's perspective.
  • The catalog elements can't be localized.
  • The elements of a list can't be manipulated by client form scripting.

Dynamic

...

Catalogs used by

...

one specific

...

Tenant

If only a one specific tenant will use a dynamic catalog, it is recommended to configure this catalog with a classification-tag for the field that should contain one of its values:values. In the following code block, an example schema definition of the example string property contract is displayed. The property is available (question)only within the tenant Mytenant. The property is classified by line 6 to be a a dynamic catalog that is displayed with the technical name contracts in your client. Initially, the list of values offered to users will be empty.

Code Block
languagexml
titleSchema excerpt example of a field of type string of classification dynamic catalog
linenumberstrue
	<propertyStringDefinition>
		<id>contract</id>
		<propertyType>string</propertyType>
		<cardinality>single</cardinality>
		<required>false</required>
        <classification>dynamic:catalog[tenMytenant:contracts]</classification>
	</propertyStringDefinition>

After uploading Upload the tenant -schema 'Mytenant' the user schema via the endpoint POST /api/admin/schema as a user of the tenant Mytenant. After uploading, the users will get an empty pick-list for that field. A user with the role YUUVIS_MANAG_SETTINGS can maintain this list. The following actions are supported:

  • Create a new list element.
  • Remove a list element. A warning is given if this element is used by an object.
  • Disable a list element. Such elements are offered for search but not during creating or editing an object.

An administrator with the role YUUVIS_TENANT_ADMIN can maintain the dynamic catalog contracts using the Web-API Gateway GET and POST endpoints httpsendpoints https://<domain>/api-web/admin/catalogs/tenMytenant:contracts of the admin-controller.

The catalog data is saved in the config server beside the tenant-schema configuration.

...