- SAP Managed Tags:
Recently, SAP Profitability and Performance Management On-premise 3.0 released blog posts where Object based authorization is configured with the help of SAP Business Warehouse. If you are not aware, you can click these links below to check it out:
On SAP Profitability and Performance Management Cloud, connection to SAP Business Warehouse is not required anymore, but an equivalent feature of Object Based Authorization is introduced called Analytic Privileges.
To give an overview of what is Analytic Privileges, it allows you to grant an authorization for certain Users to have Read and Write access to the master data. If the users have Read Access, they will have data visibility to the master data; then if the users have Write access, users will be able to manipulate the data records linked to the master data in Input/Output Activity (Editable Query).
With this blog post, I will focus on how users can set up the Analytic Privileges in Characteristic fields with master data enabled and assigned team/s.
I will give you 2 different scenarios on how you can use the Analytic Privileges in SAP Profitability and Performance Management Cloud. Before we jump into those scenarios, ensure to perform below pre-requisites.
Pre-requisite:
- Create teams with assigned users.
- Create a Characteristic field with master data value.
Scenario 1: Read Access
Here are the master data values that will be used in our scenarios for this blog post. To highlight a bit, I intentionally did not assign any Team in Read Access and Write Access columns to show you that by default, if a master data has not been assigned with any team in the Read Access and Write Access columns, all data records coming from the input function will be displayed (and optionally can be edited) to all users.
The image below shows all data records from the Input Function (having 4 data records) were projected in the Editable Query.
As promised, for the scenario 1 I will show you how we can restrict the data records to only be viewed by set of users with a use of Analytic Privileges. To perform this, as a modeler go to the characteristic with master data then:
- Choose the dropdown to show the available Teams in the Team Management.
- Select the teams that you want to give access to. In this case we will choose TEAM1 and TEAM2 wherein TEAM1 is authorized to Read Data records in combination with CC1, CC2, CC3 master data and TEAM2 with CC4 master data.
- Save the changes.
Note: We will leave the Write Access column empty to emphasize that if there’s no Team maintained to its column, updating, or editing of master data values is possible for every user which has Read Access.
Now, let us revisit the Editable Query function and see the results. Since I am one of the users under TEAM1 and not TEAM2, I am only authorized to see CC1, CC2, and CC3.
If you are curious how the results look like for users assigned in TEAM2, see image below:
Now going back on TEAM1 perspective, as we left the Write Access empty, it is expected that I as part of TEAM1 is also allowed to manipulate the data in the Editable Query. Let us try!
- Double click the master data cell.
- Click the dropdown to show the list of master data (or update the other CHARs and KFs).
- Select one (1) master data in the list.
- Press Enter.
The update was successful! As mentioned before, if Write access doesn’t have a Team assignment, by default, everybody (with Read Access) will be able to write on the master data.
Now, the question is, “how are we able to further restrict data manipulation for a specific master data?”. This topic will be discussed on the scenario 2 of this blog post.
Scenario 2: Write Access
Configuration of Teams in Write Access has the same step as how we did it for Read Access. Once the setup is ready, we can go back to the Editable Query function for the next steps. You must also take note that all teams assigned with Write Access should have Read Access. If we will interpret below image for master data CC1, you can see here that TEAM1 has read access to CC1, but only TEAM1SUBSET has Read and Write access to the said master data.
Let us revisit the Editable Query to see if my user (part of TEAM1, but not part of TEAM1SUBSET) can still manipulate the data records. The expectation is I could still read the data records CC1, CC2, CC3, but should not be able to edit.
Fast forward after changing a data record and hitting Enter, I got a healthy error that can be interpreted as my user is not entitled to manipulate the data records in the Editable Query (since I am not part of TEAM1SUBSET)
After going through Scenario 1 and Scenario 2, you are now fully equipped on how to use Analytic Privileges in SAP Profitability and Performance Management Cloud. But since this is my first blog post, and you made it this far, I will give you a bonus Tips and Tricks on how to manage Duplicate Data in Query function due to different process instance execution by using Analytic Privileges.
In On-premise, recently, there was a released blog post concerning the same scenario. Which is, 'How to manage “Duplicate Data” in Query Functions’ Analyze Screen of SAP Profitability and Performance Management 3.0. But on this blog post, I will show you how to control the same situation by leveraging PaPM Cloud Analytic Privileges.
On this example, below are the 2 process templates that will be used. In both Process templates, an Activity (View) has been added.
If the same view function will be executed outside a process template, below result will be achieved.
Execution of View function without a Process Template:
As you can see on the image above, we have added a column which is PROCESSID to visually represent which process template got executed and produced the data records projected by the view function. Since it got executed without the use of process template, this column will be empty.
However, to know which process instance (or template) executed the activity, we will maintain a formula :l_proc_id in the View function which will automatically assign the process id of the executed process template to PROCESSID field.
Fast forward where the view got executed by process templates TEAM1 and TEAM2, below result will be displayed. Blurring the PROCESSID or if the PROCESSID field is not present, users can easily assume that “duplicate” records were produced after executing the view.
Now let us fix this using Analytic Privileges.
In order for the users to see the results of the process instance that they are assigned on, I put the process template IDs as master data entries of PROCESSID field then have a Read Access restriction for each row or each process template IDs.
To briefly explain the image above, let’s say I am part of TEAM1, and is entitled to execute process template TEAM1, I will only be able to see the records produced by process template TEAM1 instead of seeing different process instance(s) execution results.
Without Read Access: I can see all process template execution results
With Read Access: (TEAM1 Perspective): I am no longer seeing “assumed” duplicate records
With the given two simple scenarios in this blog post, I hope it provides enough information on how you can control and restrict your data effectively. Aside from that, I also hope that the bonus tips and tricks regarding how to manage a suspected duplicate of data can be useful for you in the future.
I also welcome any feedback that you could share in the comments section.
You might as well browse any other Community Topics that will be helpful for you.
Thank you everyone and Cheers!
3 Comments
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
