Classification term relation
A classification term relation models the relationship between two classification terms. It specifies the database table where the relationship between the two classification terms is stored.
The relationships between classification terms are stored in the test data index to enable the test data finder to search for all attributes associated with a classification term.
A relation always has a start and an end over which the direction of the relation is modeled. When evaluating the relation, the data is built up according to the start direction.
Properties
The table below documents the available properties for classification term relations. The 'name' column displays the property name as it can be used in Groovy and Java Scripts.
Name |
Type |
Default |
Description |
|---|---|---|---|
|
active |
Boolean |
true |
Specifies whether the rule is active and therefore used, or inactive and therefore ignored, when a task is executed. |
|
additionalColumns |
String |
n/a |
Specifies columns from the relationship table to include in the test data index. These columns may contain additional information about the type of relationship. This information is displayed when searching for matching test data. |
|
applicationModelFrom |
ApplicationModel |
n/a |
The start application model in which the start classification term is specified via a classification term usage. The selected application model provides the list of possible classification terms that can be specified by the Classification Term From field. |
|
applicationModelTo |
ApplicationModel |
n/a |
The target application model in which the target classification term is specified via a classification term usage. The selected application model provides the list of possible classification terms that can be specified by the Classification Term To field. |
|
classificationTermFrom |
ClassificationTerm |
n/a |
The selected classification term that specifies the start of the relation. When building the test data index, the relation is followed for all values found for this classification term. |
|
classificationTermTo |
ClassificationTerm |
n/a |
The selected classification term that specifies the end of the relation. |
|
columnsFrom |
String |
n/a |
The column that stores the start value of the relation for the selected classification term. |
Column values identical to term values columnsMatchDefinition |
Boolean |
false |
Controls whether the values of the mapping table contain concrete classification term values or whether the mapping is done via a technical key. If the mapping is done by a technical key, the table cannot be used for direct mapping between classification term values. Another table must be accessed to resolve the mapping between the classification term values and the technical key. |
|
columnsTo |
String |
n/a |
The column that stores the end value of the relation for the selected classification term. |
|
conditionExpression |
String |
n/a |
A condition script must be specified if not all rows of the relation table should be processed. There are relation tables that store different relations for the same classification term, but with a different meaning. In this case the condition expression can be used to select the proper relation entries. The condition expression will be a part of the SQL WHERE condition that selects the rows for the test data index. |
|
description |
String |
n/a |
An optional description for this object. The description can contain multiple lines to give more context on the configured object. The description is not used in a technical context. |
|
displayName |
String |
n/a |
Specifies the name of the object. The name is used to display and identify the object in lists. The name can contain any valid UTF-8 characters. This field is mandatory. |
|
schemaPattern |
String |
% |
Specifies a selection pattern which is used to match the schema of database objects of the specified object type. |
|
table |
String |
n/a |
The database table that stores the relationship between the two selected classification terms. The table must exist in the connection specified for the application model on which the classification term relation is defined. |
|
tags |
Tag |
n/a |
Contains the tags that apply to this object. These tags can be used in the search to find objects quickly and effortlessly. |
Actions
The available actions are described below. Some actions apply to the list, while others are specific to selected classification term relations.
List Actions
The following actions are available on the classification term relations list. If the action is disabled a tooltip will provide the exact reason for the deactivation. The required permissions are described in detail for each action.
-
Bulk Delete
-
Create
-
Export CSV
-
Import CSV
-
List History
Delete the selected objects.
The following options are available:
- Cascade
-
Recursively delete depending objects.
|
When using cascade, dependent objects are deleted first also with cascade enabled. Thus, a cascade deletion is a recursive function that deeply searches for dependent objects and deletes them first. There is only a confirmation for the first object. The dependent objects are deleted without confirmation but only when the user has the DELETE permission. This feature is only available in development mode. More information about development mode can be found in the chapter User Settings. It should be used with caution. |
An object in the result list can have two different states, these are:
- DELETED
-
The object could be deleted.
- NOT_DELETED
-
The object could be not deleted. This may be because the executing person does not have a delete permission on the object or the object is still referenced by others. A detailed reason can be determined with the help of the error message. If the object is still in use, these objects are also displayed.
The following permissions are required on the list:
-
READ
-
WRITE
Creates a new object in the current list. Depending on the object type either a popup dialog is shown for the most important settings, or the complete object is shown in edit mode. The dialog provides the option to create the object and remain in the current list or to switch to the newly created object in edit mode to perform further changes.
The following permissions are required on the list:
-
CREATE
Exports the current list in CSV format. This will start a download operation for your browser.
The following permissions are required on the list:
-
READ
Creates new objects in the list from a CSV file. The format must comply with the format produced by the export. All imported objects will be added to the list. The import terminates with an error message if an object with the same name already exists and Replace rules is set to false.
- Replace rules
-
The Replace rules option determines whether a rule is appended or replaced. If set to true, all current rules will be replaced with the new rules, otherwise the new rules are appended to the existing rules.
The following permissions are required on the list:
-
WRITE
The history list tracks all modifications made to objects within it. A new record is added each time an object is created, edited, or deleted. A record indicates who made the change, which object was affected, and when the change was made.
For more information about the concept of the history refer to the history concepts.
The following permissions are required on the list:
-
READ
Object Actions
The following actions are available on specific classification term relations. In order to execute the action, the user must possess the necessary permissions for the object. The permissions required for each action are described individually. If the user does not have these permissions, the action will be disabled and the tooltip will provide the exact reason for the deactivation.
-
Check
-
Delete
-
Duplicate
-
Edit
-
Object History
This action validates the object and its dependencies, reporting configuration errors that could cause issues during task or workflow execution. The validation will cascade through the child objects of the checked objects and objects referenced by them.
For instance, if an installed application of an environment is checked, the check will process the application model, the specified version, the connection, modification sets, and involved modification methods. If an object has rules, all active rules will be checked. The modeling connection and version, including their modification sets and methods, will also be checked. Deactivated objects will not be included in recursive checks, but can be checked individually if the check is executed on the object itself.
Checks often require additional information from the context of the objects being checked, such as necessary connections or custom parameter values. The check will gather information from the objects being checked and use it to perform checks on child objects. Any required additional information must be provided before the check begins. The check queries the user to provide these missing information.
- Database object checks
-
For all rules which reference database objects such as tables, columns, etc, the check verifies that the those objects exist in the database system. If a connection can be inferred from the context, then this connection is used. If no connection is available in the context, it must be specified before the check is executed.
- Connection checks
-
For objects which configure access to external systems, such as connections or storage locations, the configuration check verifies that access can be established using the given credentials. Furthermore, additional operations on database connections are performed to check whether the credential user has the necessary authorization to access relevant database objects. In particular, the credential user’s permission to read source tables and write to target tables is verified. Similarly, for storage locations the check verifies that the credential user has permission to write to the working directory.
- Code checks
-
For all entities containing code segments, such as modification methods or condition scripts, the syntax for the code is checked. This does not check, however, whether at run time all necessary variables are likely to be available.
The following permissions are required:
-
READ
Delete the object. If the object is still used by another entity, an error message is displayed, and the object is not deleted. The delete operation must be confirmed in a separate popup.
The following options are available:
- Cascade
-
Recursively delete depending objects.
|
When using cascade, dependent objects are deleted first also with cascade enabled. Thus, a cascade deletion is a recursive function that deeply searches for dependent objects and deletes them first. There is only a confirmation for the first object. The dependent objects are deleted without confirmation but only when the user has the DELETE permission. This feature is only available in development mode. More information about development mode can be found in the chapter User Settings. It should be used with caution. |
The following permissions are required:
-
READ
-
WRITE
Will create an exact copy of the current object with a different display name in the same list. Users can decide whether they want to copy child objects like rules, permissions or tasks. It is only possible to select complete classes of objects and not to select individual child objects. Copied child-objects will preserve their display name. The default is to copy all child objects.
The following permissions are required:
-
CREATE
-
READ
Opens the current entity in edit mode.
The following permissions are required:
-
READ
-
WRITE
The history displays all changes made to the respective XDM object, including any changes made to its rules.
Each change record includes information about the operation performed (e.g. CREATE, UPDATE, DELETE), the timestamp, and the user responsible for the change.
For more information about the concept of the history refer to the history concepts.
The following permissions are required:
-
READ