Friday, March 18

SAP EP-Role maintenance


What are Portal Roles?
Technically speaking, a role is a hierarchy of folders. Folders in the hierarchy contain portal content. Portal content is iviews, pages, worksets etc. Portal roles can be assigned to user or a group of users. IN an organization there are various responsibilities assigned to various people. Based on their responsibility and daily work, they are assigned roles in portal. So a market analyst would have say role 1 and a marketing executive would have another role say role 2. The content of these roles will differ from each other. Roles are created in the portal based on the requirement of the company. As a portal user I will be able to see only that content of the portal whose role is assigned to me ID in portal. So only a single portal can cater to the needs to various department employees in an organization.

As already mentioned worksets are assigned to role. So to better understand the role concepts, we must be clear with what is a workset ?
Workset is a collection of applications or information which caters to a specific activity area like controlling and budgeting.
A role is based on the organizational structure. There are managers in the organization, there are delivery heads, there are marketing executives, there are business analysts. So corresponding these roles in the organization, there are roles defined in the enterprise portal.
 Now a manager may have various responsibilities or activities to do in his/her job. These activities are modeled as worksets in the portal. Then these worksets are assigned to respective roles.  Portal content is stored in portal content directory.

Maintaining portal content
Portal content is available in portal catalog and can be maintained in portal content studio. In the content administration role, choose Content Administration -> Portal Content. Enter general properties for the new role. Enter the folder for storing the new role in the Portal Catalog. Check all properties. The new role is created and is now visible in the Role Editor. Create the role hierarchy and add content objects (roles, worksets, pages, iViews) to the role as delta link. Change the properties in the Property Editor (optional)  Objects are added to roles and worksets as delta links.

Delta Links

We can maintain relationship between portal content. In a relationship using the delta link, there are two objects, the source object and the target object. The properties of the source object are copied to the target object.
And if a change is made in the source object’s properties, they are reflected in the target object. But vice versa is not possible.


There are few points which should always be kept in my while creating roles in a portal. Please read below…

 The basic purpose of enterprise portal is to provide a single point of access to all the people and teams involved in a business. So while creating roles, all of them should be kept in mind and then roles should be decided upon. Also long term goals of the company should be kept in mind while creating roles.
Analyse what all content will the portal hold to be displayed to its users. If it mainly contains static content like standalone websites and there is not going to be any more additions, roles are not so important there.
Based on roles, navigation structure within the portal is defined. But in some scenarios, the content available to a user (ie to his role) is very large. In such cases, search functionality using TREX and SAP KM gives faster results than using the portal roles navigation and reaching the desired content.
The best person to describe what all content should be available in a role is the one to whom that role in the organization belongs to.
As a good practice not more that 8 to 10 roles should be given to a portal user. Whatever content is needed by the user of that role should be wrapped up within 8 to 10 roles. Navigation becomes a real irritant if huge number of roles are present for that user.
While creating the content of the role, key consideration should be that the user navigates to the right content be reading the description of the portal content. So the description of portal content within a role should be consistent with each other rather than being consistent with the description of the actual content.
There should not be too many levels while designing the portal roles. It becomes a real problem if the portal role structure is deep say 5 levels deep. Also each level should not have more that 10 to 12 items.
The content available in a portal role should not be repeated in other roles. This may happen as per business needs but should be avoided as much as possible. The portal roles should be planned and designed for growth and change.
The number of portal roles should be as low as possible. This will reduce total cost of ownership of the portal.
Always keep in mind to arrange the content within a portal nicely. Avoid putting huge number of menu items. It becomes difficult for a end user to find out a specific content.
Few things like favorite-style iviews, portal eventing functionality come handy to simplify portal structures.
Out of all the content present in a role, some is used very frequently by the user and the user would want to see that first as soon as he/she navigates to his page. A well designed role should arrange the content in such a manner that most frequently content is displayed first.
Portal may use content from many resources. One such source is the SAP R/3 system. So a relationship between portal roles and the sap r/3 authorization roles should be established.
There are various ways portal roles and hence navigation can be designed. But the aim should be keep it simple. Avoid embedding roles within roles. You should bear in mind that whatever is created during implementation needs to maintained as the organization changes and grows. So the cost of maintenance should be as low as possible. Delta link capabilities should be least used.
Some portal roles need to be assigned to huge number of people in the organization whose responsibilities are heterogenous in nature. Roles should be designed only if they are usable. For the people in the company who are not versed with the IT solutions, designing role is waste of time and money and maintaining it is a paranoid.





No comments:

Post a Comment

You are welcome to express your views here...