Controlling Personas Widget Visibility with User Security Roles

[former_member560406]

Overview

SAP Personas has proven itself to be a valuable tool to help simplify the user navigation in the SAP environment. The ability to create a customized, web-based, user-centric user interface has greatly improved and expanded how we leverage SAP ECC at Thrush Aircraft Inc.

One limiting factor for SAP Personas is the ability to adjust widget visibility based on the type of end-user. If a user does not either have access to a function (or need it at that time) then it should not be available. This keeps the screen uncluttered, simple, and succinct. Prior to using the method mentioned herein we used variable flavors for variable users. This led to multiple flavors that may need all to be updated following a design change. Multiple Flavors on one transaction is not difficult to maintain when there are two or three, but the effort greatly increases as the number of flavors increases. For a high flavor count scenario, the need for granular control of widget visibility becomes a necessity.

This article will provide a case-study outlining how Thrush Aircraft implemented a methodology using a baseline BAPI to aid in controlling widget visibility and reduced transaction flavors from many to one.

Case Study

Our Personas implementation was initially focused on two general user types for the manufacturing floor:

1. Shop Floor - those that follow a basic confirmation process


2. Final Line – those that follow a non-sequential confirmation process.

These two user types could also have the option of processing batch confirmations (AKA “Collective Entry”).  Users log into Personas and the default transaction displayed is SMEN; we refer to this as the “LaunchPad”.

A fragment of the LaunchPad provides the following options to Shop Floor users:



Similarly, Final Line users are provided:

The Need for More Flavors

Over time we added more functionality to Personas including QA Inspection and Indirect Labor Confirmations. These new requirements meant that at least two more flavors should be created, plus any variations where a user is cross functional. The number of flavors could easily increase to eight or more. Maintaining many flavors is a daunting task for a small development team and certainly not an ideal scenario. We needed the ability to display and hide buttons based on the type of user accessing the application to reduce the number of supported flavors.

With the new user functionality available we now have six possible transaction options available. Some of these options are shared by all users and others are limited to specific users.



Visibility for each of the buttons should be determined by the user currently logged into Personas.  The following graphic and table describes who should have visibility to which buttons.

User Type	Security Role	Work Center Schedule	Non-Sequential	Batch Entry	Indirect Labor	Schedule Refresh	Inspection
Final Line	Z_SAP_PERSONAS_SHOPFLOOR_FL	Show	Show	Hide	Hide	Show	Hide
Collective Entry	Z_SAP_PERSONAS_SHOPFLOOR_CE	Show	Hide	Show	Hide	Show	Hide
Indirect Labor	Z_SAP_PERSONAS_INDIRECT_LABOR	Show	Hide	Show		Show	Hide
QA Inspector	Z_SAP_PERSONAS_QA_INSP	Show	Hide	Hide	Hide	Show	Show

The following graphics are examples of what the implementation should look like from the perspective of end users.

Shop Floor User



Final Line User



Collective Entry Add-on User



Indirect Labor Add-on User



QA Inspection Add-on User

Widget Visibility via SAP Security

The solution was to take advantage of an SAP baseline BAPI that provides visibility based on a user’s assigned security group(s). Once the user security is known we can then programmatically control widget visibility on a user-by-user basis.

The SAP BAPI named ‘BAPI_USER_GET_DETAIL’ can be used to provide a list of user assigned security groups and can be called from a Personas script.

I’ve provided more details on this BAPI at the end of this document, but the implementation is shown below.

Script Implementation

To leverage the BAPI we need to create a new Personas script on the transaction. The premise is straight-forward:

1. Get the username of the current user


2. Invoke the BAPI to return all security groups assigned to the current user


3. Using basic logic, toggle show/hide on each of the buttons based on the current user security group.

Note: Your Personas users will need to be assigned a profile named ‘S_BI-WX_RFC’ to make RFC calls from Personas. Check with your BASIS people for assistance.

For obvious reasons, if you want to test this on your own instance, you will need to update the security groups and button IDs. (See the section ‘Sidenote’ for a quick primer on inserting a BAPI into the script.)

var username = session.info.user; //Built-in function that returns the SAP username for the current user



//This block of code calls the BAPI FM via RFC

 var oRFC = session.createRFC("BAPI_USER_GET_DETAIL");

 oRFC.setParameter("USERNAME", username);

 oRFC.setParameter("RETURN", [{"TYPE":"","ID":"","NUMBER":"000","MESSAGE":"","LOG_NO":"","LOG_MSG_NO":"000000","MESSAGE_V1":"","MESSAGE_V2":"","MESSAGE_V3":"","MESSAGE_V4":"","PARAMETER":"","ROW":0,"FIELD":"","SYSTEM":"0000000000"}]);

oRFC.requestResults(["ACTIVITYGROUPS","RETURN"]);

 oRFC.send();



var _RETURN = oRFC.getResultObject("RETURN");

var agr_result = oRFC.getResult("ACTIVITYGROUPS");



session.utils.log(agr_result + "" ); //Debugging line to display the user roles



//Perform a basic array search for the key words based on the roles we are looking to find. This is a regex search. The search will return either the position of the search term in the array or -1 if not found.

var finalline = agr_result.search("Z_PERSONAS_SHOPFLOOR_FL");

var shopfloor_ce = agr_result.search("Z_PERSONAS_SHOPFLOOR_CE");

var indirectlabor = agr_result.search("Z_PERSONAS_DIRECT_LABOR");

var qa_insp = agr_result.search("Z_QA_INSPECTOR");



//Variables listing for the buttons. Note: The ids will not be the same for your instance.

var ctrl_nonseq = session.findById("wnd[0]/usr/boxPersonas_15299418049708/btnPersonas_153393526893439");

var ctrl_batch = session.findById("wnd[0]/usr/btnPersonas_153393532570646");

var ctrl_indirectlabor = session.findById("wnd[0]/usr/btnPersonas_153393520006175");

var ctrl_qa_insp = session.findById("wnd[0]/usr/boxPersonas_15299418049708/btnPersonas_153332559338375");



//If the search term was not found then the value of the search is -1. 

//Lacking the security role means we want to hide the control



if (finalline === -1) {

	session.utils.log("Hiding FinalLine");

	ctrl_nonseq.hide();

}



if (shopfloor_ce === -1) {

	session.utils.log("Hiding Shopfloor CE");

	ctrl_batch.hide();

}



if (indirectlabor === -1) {

	session.utils.log("Hiding Indirect Labor");

	ctrl_indirectlabor.hide();

}



if (qa_insp === -1) {

	session.utils.log("Hiding QA Inspector");

	ctrl_qa_insp.hide();

}



//End of script

For demonstration purposes we will allow the debugging line to display the output from the BAPI call. Run the script and review the output to see which groups are assigned to the user. You should see output like the following:



By changing the security group(s) assigned to the current user you can observe how the script changes button visibility.

Sidenote

A simple technique to generate the required lines to call a given RFC into the script. From the scripting control, select the ‘RFC Tool’ menu, enter the name of the BAPI FM into the search, click on the resulting listing. Now toggle the ‘RFC Parameter’ that will be provided and do the same for the ‘RFC Results’ that need to be returned. Finally, click on ‘Copy RFC template code’ to copy into the script editor.

More About BAPI_USER_GET_DETAIL

To learn more about BAPIs you can log into SAP ECC and simply type in the word ‘BAPI’ as a transaction name to run the ‘BAPI Explorer’. The specific BAPI we are using here is named ‘BAPI_USER_GET_DETAIL’ and can be found in the Hierarchical listing under ‘Basis Components’>Security>User>GetDetail.



Notice that the function module (FM) name is ‘BAPI_USER_GET_DETAIL’; this is the name used to access the RFI from Personas.

In the BAPI Explorer you can view the internals for the FM by double clicking on the name. On the resulting page you can then test out the FM by clicking on the ‘Test/Execute’ icon as shown circled below:



The function expects an input parameter for an SAP username. Enter a username as the value (see example below) then execute.



The function will return lots of information about the given user but for this article we are concerned about the ACTIVITYGROUPS table entries. Expand the entries by clicking on the PROFILES icon (see circled below).



The entries will contain a listing of assigned security roles for the selected user:



Note: Some BAPIs will need to have a manually entered whitelisting to be called from Personas. This webpage provides more information on how to do that: (http://www.kodyaz.com/sap-abap/personas-function-module-whitelist-entry.aspx)

Conclusion

Now that we have more control over widget visibility our ability to create customized UIs for our end users without the need to maintain many similar flavors. This method simplifies Personas scripts and helps us to make and release changes more efficiently.