Definition of Validations and Derivations

You use this Web Dynpro application (USMD_RULE) to define validation and derivation rules for a specific data model of Master Data Governance. Derivation rules are designed to simplify the entry of master data, whereas validation rules ensure consistency of the master data entered.

Integration

After you specify a data model, the Web Dynpro application launches the Business Rule Framework plus (BRFplus) application. For more information, see Business Rule Framework plus (available in English only).

Prerequisites

You have created the data model for which you want to define derivations and validations.

Features

Trigger Functions

You can assign trigger functions to the following events to validate master data changes:

CHECK_ENTITY (Check entity): The system executes the function assigned to this event when entity values are validated during single or collective processing, when mass changes are made, or during the upload process.
CHECK_CHANGE_REQUEST (Check change request): The system executes the function assigned to this event when the change request is checked. It also executes the function prior to the final check of the change request.
CHECK_EDITION (Check edition): The system executes the function assigned to this event before an edition is released.
CHECK_ENTITY_HRY (Check hierarchy information of an entity): The system executes the function assigned to this event after the hierarchy of an entity type is changed.
CHECK_CHANGE_REQUEST_HRY (Check hierarchy information of a change request): The system executes the function assigned to this event at the same time as CHECK_CHANGE_REQUEST. The function assigned to the CHECK_CHANGE_REQUEST_HRY event is used to check the hierarchy information.
CHECK_EDITION_HRY (Check hierarchy information of an edition): The system executes the function assigned to this event at the same time as CHECK_EDITION. The function assigned to the CHECK_EDITION_HRY event is used to check the hierarchy information.
DERIVATION (Derivation): The system executes the function assigned to this event when data is entered during single processing or the upload process.

When defining rules for CHECK events, you can define an action for issuing a message and control further processing in Master Data Governance based on which message type you select.

When defining rules for the DERIVATION event, you can use the Change Context action to change the attribute values of the entity type.

You can also trigger other actions (for example, by means of a static method) and include additional information in the computation.

For each entity type of the data model with storage and use type 1 or 4, the system generates a structure-type data object when you start this Web Dynpro application for the first time. Each time you subsequently activate a change to the data model, the system again generates the data objects the next time the user starts the Web Dynpro application.

BRFplus Structure Generation

If entity type 1 and entity type 4 have the cardinality 1:N, the BRFplus catalog generation does not add the fields of entity type 4 to the fields of entity type 1.

If entity type 1 and entity type 4 have the cardinality 1:1, the structure generation and the derivation function in BRFplus treat entity type 4 as an extension of entity type 1.

If entity type 1 and entity type 4 have the cardinality 1:1, the BRFplus catalog generation adds the fields of entity type 4 to the fields of entity type 1.

Note Note

If entity type 1 and entity type 4 have the cardinality 1:1, instead of calling the derivation function of entity type 4, the system calls the derivation function of entity type 1.

End of the note.

Naming Conventions

The following naming conventions apply to the relevant nodes, objects, applications, and catalogs:

Trigger function nodes in the catalog structure
The naming convention for validation-based trigger function nodes of a catalog structure is: CHECK_<name of entity type>, for example, CHECK_ACCOUNT.

The naming convention for derivation-based trigger function nodes of a catalog structure is DERIVE_<name of entity type>, for example, DERIVE_ACCOUNT.

Note
These naming conventions apply only to the naming of the trigger function nodes of a catalog structure. They do not apply to the naming of the trigger functions linked to the nodes. Each entity type should have a maximum of one trigger function per event. The nodes of the respective function branch of the trigger function represent the corresponding application options.

End of the note.
Data objects
Data objects are automatically generated from the data model definition. The structure-type data objects have the same names as their respective entity types.

Note
The naming conventions valid for SAP enhancement package 4 are still supported. However, we recommend that you discontinue their use.

End of the note.

The standard system features the following predefined data objects, which you can use within rules and functions, as additional input parameters:
- SAPFMDM_CREQUEST_TYPE: Change of change request type ID
- SAPFMDM_CREQUEST: Change of change request ID
- SAPFMDM_EDITION_TYPE: Edition type ID
- SAPFMDM_EDITION: Edition ID
- SAPFMDM_PROCESS: Business activity
- SAPFMDM_CREQUEST_STEP: Change request step
- SAPFMDM_CREQUEST_INDEX: Change request index
- SAPFMDM_WORKITEM_ID: Work item
- SAPFMDM_HRY_DELTA: Deep structure consisting of a hierarchy relationship (or an associated pair of objects) for validation
  This must be used in the hierarchy-based validation events CHECK_ENTITY_HRY, CHECK_CREQUEST_HRY, and CHECK_EDITION_HRY.
  
  Note
  If a trigger function contains the predefined data objects only, it is executed once during the validation.
  
  End of the note.
- BRFplus application and catalog
  The system creates the BRFplus application and catalog structure automatically for each data model when you define validations or derivations.
  
  Note
  Use the namespace for the system-generated BRFplus application and catalog structure to create your own applications and catalogs. The system uses the syntax FMDM_MODEL_<name of data model>, for example, FMDM_MODEL_0G for data model 0G.
  
  End of the note.

Enhancement for Validation and Derivation

The Business Add-In (BAdI) Define Validations/Derivations is provided as an enhancement implementation of this Web Dynpro application. This enables you to define validations and derivations using alternative code.

To call the BAdI, in Customizing for Master Data Governance choose Start of the navigation path General Settings Next navigation step Data Quality and Search End of the navigation path and choose the Customizing activity BAdI: Define Validations/Derivations.

If entity type 1 and entity type 4 have the cardinality 1:N, in the derivation function of the entity type 4 you have read access to the values of entity type 1 for determining entity type 4.

In the derivation function of entity type 1, you do not have read access to the values of entity type 4.

Activities

To start this Web Dynpro application, in Customizing for Master Data Governance choose Start of the navigation path General Settings Next navigation step Data Quality and Search End of the navigation path and choose the Customizing activity Define Validation and Derivation Rules.

Example

Creating BRFplus functions for derivations of entities with storage and use type 4

The following table shows an example of the different cardinalities, which are described in the BRFplus Structure Generation section.

Entities	Entity Type	Attributes
CARR	1
		CURRCODE
CARR_DELTA	4 with 1:1 cardinality
		URL
COUNTER	4 with 1:N cardinality
		COUNTNUM
		AIRPORT
		C_URL

This example contains the entity CARR with storage and use type 1 along with the dependent entities CARR_DELTA and COUNTER, which have storage and use type 4. CARR_DELTA has the cardinality 1:1 and COUNTER has the cardinality 1:N. The third column shows the attributes of the entities.

Generated BRFplus Structures

Entities	Attributes of the Generated BRFplus Structures
CARR
	CARR
	CURRCODE
	URL
CARR_DELTA
	URL
COUNTER
	CARR
	COUNT_NUM
	AIRPORT
	C_URL

In the data model, the entities with storage and use type 4 have their own attributes. In contrast, in generated BRFplus structures, the system adds the attributes of the entities with storage and use type 4 with cardinality 1:1 to the attributes of entity type 1. For this reason, the CARR structure has the additional URL attribute.

Derivations for entities with cardinality 1:1
- UIs based on Web Dynpro application USMD_ENTITY_VALUE2
  If you want to create a derivation for CARR_DELTA in BRFplus, you can execute this only with the function DERIVE_CARR, but not with the DERIVE_CARR_DELTA function. When entities have the cardinality 1:1, in BRFplus you access derivations using the entity type 1.
- UIs based on the Convenience API CL_USMD_CONV_SOM_GOV_API
  If you want to create a derivation for CARR_DELTA in BRFplus, you can execute this only with the function DERIVE_CARR_DELTA, but not with the DERIVE_CARR function.
The generated BRFplus structure of the entity type 1 contains the attributes of the entity type 4 with cardinality 1:1. If you specify the signature for the BRFplus function, you must use the structure of the type-1 entity CARR.
In contrast, to access an entity type 4 with cardinality 1:N (for example, COUNTER), you call the DERIVE_COUNTER function.
The signature of the BRFplus function DERIVE_COUNTER is the COUNTER structure.