Skip to Content

This is final installment of a multi-part series addressing myths about SAP Screen Personas.

/wp-content/uploads/2014/01/myth11_364929.png

Again, this myth is based on a foundation of truth. When we started developing SAP Screen Personas, we imagined a world where anyone could modify their SAP screens to meet their unique needs. In our customer validation phase, prior to the release of Personas 1.0, most of the IT professionals we talked to described a potential support problem in a typical enterprise environment with thousands of users.

Fortunately, we had already built all the proper controls into the product to enable IT to control who sees what screens. This can vary from the ability to change anything (this is rare) to the ability to use the screens as delivered by IT without being able to modify anything (more common). For users that are allowed to modify screens (typically one or two key users per department), the IT organization has extensive and granular controls so they can determine what permissions a user has for modifying screens.

Personas ships with several roles already defined. As you can see in the screen below, I have been assigned “FULL_EDIT_ACCESS.”

/wp-content/uploads/2014/01/myth11_edit_access_364930.png

IT can assign any of the other roles to any user or group. Or, they can create a different permission configurations using the transaction SPRO. The expected value is a signed 32 bit integer value representing the bit mask which defines whether an individual feature is available to a user who has the permission configuration assigned. To calculate the correct value, define the bit mask as described in the configuration guide, and transform it into a signed int. One simple way to do so is to use Microsoft calc.exe, in programmer view, and configure it to use a DWORD (32 bit), enter the bit mask as a sequence of BITs (BIN) and change the number format to decimal (DEC).

These permission configurations can be assigned to user & system combinations in the SAP Screen Personas administration transaction (/n/persos/admin_ui). A mass assignment is supported as well. Groups in Personas can also be derived from existing roles.

While Personas supports flavors down to the individual user level, most organizations use the existing roles they have defined in SAP.

/wp-content/uploads/2014/01/conclusion_true_364931.png

But only if IT makes it true!

This is the last planned post in the Myth vs. Truth series. If we hear other partial truths, we will address them on SCN. If you hear something about Personas that sounds too good to be true, just ask as a comment on any of the posts in the series and we’ll answer your question as a reply or a full blog post, if it warrants.

Thanks to everyone for staying with us throughout the series.

For SAP Imagineering, Peter Spielvogel.

Read the entire SAP Screen Personas Myth vs. Truth series

Introduction

Myth 1

Myth 2

Myth 3

Myth 4

Myth 5

Myth 6

Myth 7

Myth 8

Myth 9

Myth 10

Myth 11 (this post)

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Trond Stroemme

    Hi Peter,

    nice blogs! Quick question: I’ve been told that SSP relies on Silverlight, which is now apparently being discontinued/decommissioned by Microsoft. Is this correct? If so, do you envision another solution/way forward?

    Regards,

    Trond

    (0) 
    1. Peter Spielvogel Post author

      Hi Trond,

      Yes, the current version of Personas relies on Microsoft Silverlight for client-side rendering. Microsoft will be supporting Silverlight through 2021. We are aware of this limitation and are working on a new version that will eliminate this dependency by using HTML instead.

      Our plan is for customers on the current Silverlight version to be able to migrate the flavors (screens) that they build to the new version.

      Regards,

      Peter

      (0) 

Leave a Reply