Master data and high end data validation using relations in SAP PaPM Cloud Universal Model

[veselm]

Now that you are familiar with the basics of relations in SAP PaPM Cloud Universal Model, let’s dive deeper and see how we could utilize relations to create Master data for String data type and high end data validations.  

Chapter 1: Master data using relations

One way to introduce master data to SAP PaPM Cloud Universal Model is through Association field and specifying the Master data function which will hold the master data values for it. To know more about it visit the documentation about Association field and how to configure master data. This would be creating of managed association, compared to unmanaged associations that you can build via relations.  

Speaking of relations, the other way to do it is using them. This option will allow you to assign master data even for the String fields. This is specially useful to fields coming from some external sources through connections since they can’t be registered as Association fields, rather as String fields.  
 
Note: If this master data assignment option has been used, remember that this string field will be assigned with master data only in the Model which has the relation to the master data table. If the same field is used in some other Model then it will be just a normal string accepting any string values.

To configure this we would need to specify the following:

Procedure:

Step 1: Maintaining Relation ID and Description 

As we did before we need to maintain ID and Description of the relation.

Step 2: Maintaining the Type of relation to Association to one 

When we are configuring this type of relation only Association to One can be used.

Step 3: Choosing the Target Model 

Target Model will act as Master Data Function for the String field we want to define master data for. This can be a Model Entity, Model Reference and Model View or Model HANA which have a field with ‘Key’ Value Help Tag. 

Step 4: Maintaining the Join Condition 

If a Target Model has multiple fields with ‘Key’ as Value Help Tag, which can be the case for Model HANA, then the important thing that needs to be setup is the Join Condition so the system knows to which ‘Key’ to equate the values of the String field we are creating master data for. If it has only one ‘Key’ field than system will use it and you don’t have to explicitly maintain the Join Condition. You can still choose to do so and get the same result and provide some additional ‘on conditions’ which will limit the values.

Spoiler

To maintain ‘on condition’ you can write Join condition in the following format: <RelationName>.<KeyFieldFromTarget> = <FieldFromRootEntity> AND <FieldFromRootEntity> = <‘Value’> where values inside of <> are specific to your case. 

Step 5: Choosing the Validation Type

And lastly to indicate that you want to create Master data with relations you need to setup the Validation type to Value Help. 

Step 6: Choosing the Validation Field 

With Validation Field you will be specifying the field from the root entity for which you want to create master data. 

Example for Master Data 

Let’s visualize this in an example. Our scenario will have:  

• Documents and Items tables related together with Composition of Many relation 

• Cost Centers Model Entity which holds Master data for Cost Center Association field 

• A mapping table between Countries and Regions 

• Periods Model Entity which holds Master data for Period String field 

Requirements 

1. Create Master data for String field Period and use Periods Model Entity as Master Data function 
2. Limit the values of the master data to 2024 and 2023 with the ‘on condition’ 

Requirement 1 and 2 - Let’s see how to configure this in the system:

Now let’s see on Show screen if we get a value help for field Period and if the values are limited to 2024. 

As you can see you can still see all of the values that are present in the Master data function, but choosing only the value 2024 is allowed. The ‘on condition’ is not mandatory and if it was not set then all the values from the master Data function would be accepted but values outside of master data would not be accepted. So let’s delete the on condition so all of the master data values are excepted. And our relation would look like this now. 

Chapter 2: High end data validations using relations 

With relations you could create all kinds of validations that suit your use case and achieve the high end data validation, but let’s see how to configure relations for this purpose and what are the different options we can specify.  

To configure this we would need to specify the following:

Procedure:

Step 1: Maintaining Relation ID and Description 

As we did before we need to maintain ID and Description of the relation. 

Spoiler

When used for data validation, description of the relation will be shown to the user if some of the data records get validated. So it should be as user friendly as possible, for example if we are validating if the DateFrom is before DateTo then the message should state something like: ‘DateFrom should be before DateTo!’. To get more detailed message user can also add the following: ‘Entity {0} Record {1} Field {2} Value {3} Target {4}’ where the arguments in the curly brackets will be replaced by the system with the data record which is being validated specific information. 

Step 2: Maintaining the Type of relation to Association to many 

Data validations can only be used with Association to Many relation type, so this is the one we need to choose while building the validations.

Step 3: Choosing the Target Model 
 
And speaking of that, the Target Model can be a different Model or the same Model where we are creating the relation in, or in other words root entity.

Step 4: Maintaining the Join Condition if backlink doesn’t exist  

What’s important is for the system to know how to connect the root entity and Target Model. To declare this you can use Join Condition or a backlink field.  

Step 5: Choosing the Validation Type 

Next thing that needs to be determined is when we have multiple matching records from root entity and Target Model is 

• If we want to have at least one of them to satisfy the condition from the Default Filter and ‘on condition’ we use Fulfilled 
• If we want that none of them satisfy them we use Not Fulfilled. 

Spoiler

Fulfilled will ensure that at least one matching record satisfies the condition set in Default Filter and ‘on condition’ 

Not Fulfilled will ensure that zero records satisfy the condition set in Default Filter and ‘on condition’ 

Step 6: Maintaining Default Filter 

Which brings us to the expression which we need to maintain in Default Filter, which will hold the logic of our validation.

Spoiler

If the root entity and Target Model have the same field names then in Default filter to specify that the field is coming from the root entity you need to put _m. before it.

Step 7: Choosing the Validation Field 

And lastly to specify some field from the root entity which we want to be validated we can maintain Validation field and then our validation message will be more detailed and will indicate this field in the message. 

In the message we will get more detailed information then:

Example for Data Validation: 

Still with the same scenario we will build validations. 

Requirements: 

1. Validate that at least one item per document contains Period ‘2024’ 
2. Validate that no item contains Cost Center ‘CC1’ 
3.  Validate that Country matches the Region according to a Mapping table of Countries and Regions 

Requirement 1:  We will add some validation checks to our Model Entities, starting with the check that will ensure that at least one Item per Document contains the value 2024 for Period. To configure it we will go to Documents and create an Association to Many relation. For this use case we will use Fulfilled Validation type because it will check if at least one record satisfies the condition in Default filter and ‘on condition’.

Configuration would look like this: 

On the Show screen we will only be able to create the record if there is at least one item with Period 2024.

Requirement 2: Now what if we want that none of the Items fulfill the expression we maintained in the Default filter, then we would use Not Fulfilled Validation type and for this let’s create a validation which will ensure that no item has Cost Center CC1. Since Cost Center is an Association Field to refer to it in Default Filter we need to refer to the Key field of it’s Master data function. 

Now on Show screen we will not be able to choose CC1. 

Requirement 3: And lastly we would like to make sure that according to the mapping table between Country and Region we want to ensure that we choose the correct Region for a Country. Since here our root entity and Target Model have the same field names to tell the system that the field is coming from the root entity in the Default Filter you need to specify _m. before fields name. If they are not the same this can be omitted.

On the Show screen if we choose a Region that doesn’t match the Country we will get a validation message. 

Spoiler

All the validations we created, either the master data ones or custom ones will also be present if you Import Data through modeling or Activities, or try to insert via Writer. There is an option to turn these errors into notifications, warnings or information so the data can be imported but with a message displayed to the user, and for this you can use Reclassify Error Message. 

To showcase this we will change the relations we had to: 

1. Information:




2. Notification




3. Warning



Now we would not get errors if the data doesn’t satisfy these validations rather information, notification and a warning and data will be successfully saved. 

I hope you learned about how to tackle different scenarios and that you already got an idea on how to utilize these validations for your use cases. The sky is the limit! Have fun modeling and until next time! 😊