Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
7,273

Introduction

This is the first installment in the series of posts I hope to write targeted at NetWeaver Portal consultants and administrators looking to become familiar with the NetWeaver Business Client (NWBC). You can find out more about the background to this in my introductory post here The NetWeaver Business Client (NWBC) - A Portal Consultants Guide my aim is for each part to be relatively short and concise (no TL;DR here!) so here we go...

Roles

This post is going to deal with roles - the boring kind not the type you have with soup :grin: .

I am also going to assume that in the case of NWBC that NWBC is not getting roles from the portal (e.g. NWBC is connecting to an ABAP system) - connecting the NWBC to the portal probably deserves a whole chapter to itself.

In general the roles a user is assigned determines two things:

1. What they see in their navigation (menu)


2. What they can access (authorizations)

Bread rolls

Bread Rolls - Yum!

By Bangin (Own work) [GFDL, CC-BY-SA-3.0 or CC-BY-2.5], via Wikimedia Commons


This is true for both NWBC and Portal although they are implemented slightly differently in each. Portal roles are built by the portal administrator in the Portal Content Directory (PCD) and traditionally ABAP roles (or so called PFCG roles - PFCG is the transaction used for role maintenance) are created in the ABAP system by the security or basis team.


My experience to date is that portal people are generally quite good at designing the navigation structures and so called "information architecture" for the users and the security/basis guys tend to focus more on the access/authorizations and less on the menu/navigation. I strongly believe that both need to be given equal importance. It is very important to get both points 1 & 2 above correct, no point in letting people see stuff they can't access or giving access to something they can't see. For me as a portal guy this has mean't sitting down with the security guys and explaining how important the menu structure is when using NWBC - I've also learn't a lot about authorizations on the way :grin: , so spend some time with your security friends I think you'll both learn something useful.


Roles need something in them... (Sandwich anyone?)

A role on its own is a pretty desolate place... lots of folders with no content - how sad :sad: . So we need to add some fillings. In the portal you would do this again in the PCD and you would add pages and iViews to your role, usually grouped in folders to make things nice and organized and easier to find.

Again you pretty much have the same concept in PFCG, you can add pages in the form of Web Dynpro for ABAP applications and pages (these pages can contain CHIPs), you can add BSP applications, SAP GUI transactions, WebUI (CRM) and pretty much any URL. The online help documentation is very good, I suggest you spend some time reading it. In my "portal-biased" mind at least these are the equivalent of iViews and iVIew templates. You can also add all of these things from remote systems (e.g. your SRM or CRM system) just like you would in the portal by specifying the system property in the iView definition (more on that in another post).

Another nice feature which also mirrors the portal is that once you have built your role all the content is searchable in the NWBC quick launch bar (currently only in the desktop version). So a user can just start to type what they are looking for and be presented with a list of matching options.

Other features

Some of the other things you can do in portal roles also exist for PFCG role menus. You can set the sort order for folders and you can even merge folders like you can in the portal, although this feature is arguably a bit less flexible than it is using merge ids in the portal.

NWBC also has the concept of Service Maps and Useful Links (called Link Collections) just like in the portal. NWBC also caters for Object Based Navigation (OBN) so you can have folders in your PFCG menus that have lots of (invisible) navigation targets, just like you do in your portal roles. I thin OBN probably deserves its own post at some point.

Something that the PFCG roles have which the portal doesn't is the concept of Side Panels. Side Panels are a topic all to themselves, but check them out, they are a neat way of augmenting/enhancing a classic SAP GUI screen without making any modifications to the original screen.

What's missing?

Not much really... but maybe just one thing that I really like about the portal roles is the inheritance model that can be applied to any PCD object including roles. This means that you can have a parent role in the portal with multiple children. you can make changes to the children that will overwrite the inheritance from the parent but you can also propagate common properties from the parent to the children. I know that there are so called "Derived Roles" in PFCG and perhaps something similar is possible, but I haven't seen it yet. If anyone knows please comment below and I will update this post.

Summing up

I think I'll wrap that up here for now (I'm feeling hungry for some reason :???: ), both NWBC and Portal provide a comprehensive set of features for role creation and administration. Many of the same features and concepts exist in both so you should be able to pick them up and apply them fairly easily. Don't underestimate the effort required to get your roles right - they determine what the user sees at the end of the day and what the user sees ultimately drives how they perceive the system. In a large system landscape with many systems (SRM, CRM, BW, GRC, ERP etc...) you will need to carefully plan your role design, I hope to post something about this soon too... stay tuned! In the mean time I'd love to hear about how you tackled the job of designing and building your NWBC roles, did you create separate "menu roles" that contain only menus and no authorization profiles, or did you combine the two and have both menu and authorizations in the same role(s)? How did you deal with roles from other systems?

As always I really love reading and responding to your feedback.... so please leave a comment below. Thanks!

5 Comments
Labels in this area