Introduction to Relations in SAP PaPM Cloud Universal Model!

[veselm]

Now that you are familiar with SAP Profitability and Performance Management Cloud Universal Model (SAP PaPM Cloud UM) and some of it’s features and actions buttons, let me make you more comfortable when modeling and building transactional use cases by introducing the relations to you. Transactional use cases are the focus of Universal Model, where data lifecycle management is possible, from sophisticated input data validation, through establishing relations between tables to archiving! 

Having said that, today’s topic will cover the way to create relations in SAP PaPM Cloud UM, turning the flat structures into the nested ones and introducing dependencies between Models.  

Relations can be of type Association and Composition where a key difference between them exists. What is important to distinguish is that Association type relations relate two different Model Functions to each other but they still remain independent Models, where for Composition the related tables are dependent on each other. When two tables are in a relation of Association type, records can be created in both tables separately but for the tables which are related to each other via Composition, the records can be created via the root entity. The root entity is the Model function where the relation is being created in, and it will be related to the Model function defined as Target Model in the relation. 
 
Tip: PK – Primary key; FK- Foreign key

 

Spoiler

Since this dependency between the root entity and Target Model exists, if Composition relation is created between them, to disable the creation of records via Show screen of Target Model, user has to change the Restriction of it to Disable Odata draft.

Relations 

Relations are a new feature that SAP PaPM Cloud UM introduced, and with the help of relations different Model functions can be related to each other in different ways. 

There are three types of Relations available: 

1.  Association to One 

1.  Association to Many 

1. Composition of Many 

To learn more about the different types refer to Types of relations 

Chapter 1: Association to One 

As mentioned before, since this is Association type, the models that have this relation established will still be independent, where “to One” tells us that each record from the root entity is related to exactly one record in the Target Model. 

This relation type can be used to visualize the fields from other Models in the root entity.  

To configure Association to One relation user needs to maintain Join Condition, a statement based on which the tables will be joined.  

Spoiler

If you write the name of the relation followed by ‘.’ and then the Field name, this means that you want to refer to the field from the Target Model, and if you write just the name of the Field than this will refer to a field from the Model where the relation is being created in.  
Example: RelationName.FieldFromTarget = FieldFromRootEntity 

This is applicable for all types of relations! 

Additionally user can specify ‘On’ conditions in Join Condition to do further selection of the values. Example RelationName.FieldFromTarget = FieldFromRootEntity AND FieldFromTarget = ‘SpecificValue’

Note: If you are using an Association field in the Join Condition, since Association field is pointing to it’s Master Data function, which can contain more than one field, user needs to specify which field from the Master data function will be used in the Join condition by adding ‘.’ to the Association field’s name and specifying the Field name from the Master Data function like so AssociationField.Code where Code is the Key field from AssociationField’s Master Data function.  

Disclaimer: The examples are using illustrative scenarios used to simplify and focus just on each type of relation and their characteristics. SAP PaPM Cloud Universal Model is a product to create financial applications and with this in mind the scenarios built in real life applications are also financial ones.

This relation type can be explained with the following example: 

• Students table holds student information. 

• Books table holds the information of which student rented which book and what is the due date of the return. 

• One student can rent multiple books, and we would like to include the number of rented books per student in the Students table and for this number to change automatically if the student rents more books or returns some. 
  

Spoiler

In order to do these “on the fly” calculations, Model functions can be used. They create views instead of procedures in the database, which means that the results are available right away, without the need to run the function. 

After aggregating the Books Table per student and getting the count of the rented books we can create the Association to One between Students Table and Books Per Student Model View. One record in the Student Table matches exactly one record in the Books Per Student Model View! When creating this type of relation make sure that this is the case, otherwise use Association to Many or Composition of Many, depending on your use case. 

This is the example data: 

And how to configure Association to One relation in the system? Here is a short gif to demonstrate: 

Important: Make sure that your Target Model has a "Key" Value help tag defined.

Spoiler

To add the information of number of books per student user needs to add this field from Adapt UI in Show screen of Students Table. This is true for individual records view, for all records view, user can add this fields using the columns tab of the Show screen. This is how to do that: 

Chapter 2: Association to Many 

Association to Many type of relation is similar to Association to One in regards that the Models with this relation are independent, but the difference is that one record in the root entity is related to multiple records from the Target Model. 

While creating Association to Many either Join Condition or backlink field is required which will define how the tables are joined. 

Spoiler

Backlink field is an Association field in the target Model which has the root entity as Master Data function. 

The following example can explain Association to Many relation: 

• Students table holds student information. 

• Books table holds the information of which student rented which book and what is the due date of the return. 

• One student can rent multiple books, and we would like to include the book information on Students Table. 

This is the example data: 

 

Let’s see how this can be setup in the system: 

Spoiler

To see the information of the Target Model in the root entity’s Show screen user can add it via Columns tab or via Adapt UI. This way information from relation is readonly and cannot be edited. 

Chapter 3: Composition of Many 

Composition relation differs from Association in terms that by creating it between Models they will become dependent on one another and will have parent-childs relation established, where “of Many” refers to one record from the parent Model (root entity) being related to multiple records from the child Model (Target Model). 

In other words Composition will create a new structure on the parent’s Show screen and creation or editing of records is possible only from parent's Show screen. In this relation type all child Models need to have Restriction set to Disable Odata Draft.  

Spoiler

Composition relations are supported only for Model Entities! 

While creating Composition of Many either Join Condition or backlink field is required which will define how the tables are joined. 

Spoiler

Backlink field is an Association field in the target Model (child) which has the parent (root entity) as Master Data function. 

The following example can explain Composition of Many relation: 

• Students table holds student information. 

• Books table holds the information of which student rented which book and what is the due date of the return. 

• One student can rent multiple books, and we would like to be able to add or remove books for students in the Students Table Show screen. 

 The data will look like this since the tables are no longer independent:

In SAP PaPM Cloud UM composition relation can be created like this: 

 Note: User needs to make sure that the Restriction of child Model is set to Disable Odata Draft! This way the user is explicitly allowing the editing of the records only from the parents Show screen. 

 User can create records from parent’s Show screen for both tables at once.

Now that you are familiar with different types of relations that exist in SAP PaPM Cloud UM you can start to think of the ways to implement them for your use cases and maintain the data lifecycle easily. But this is not the end when it comes to relations, so stay tuned for the next part where relations will be used for Master data creation and also for input data validation! Until then, have fun modeling in SAP PaPM Cloud UM! 😊