Part 1 – Portal roles vs NWBC roles
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 😀 . 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 – 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 😀 , 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 🙁 . 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!
Nice .. liked the way you presented .. would have been better if we got a more insight into how to do it .. maybe in your next blog ?
Hi Vinita, thanks for your feedback. I think the help guide from SAP actually does a really good job at explaining the "how-to" - I don't want to just repeat the help documentation, instead I would like to compare the concepts in both portal and NWBC and show where there are similarities and where there are differences. I hope that doesn't put you off reading the upcoming posts! 🙂
Hey Simon
Not at all I would definitely be following up your next posts on this ..
I quite liked it infact 🙂
Dear Simon,
a decision tree to help to decide whether or not to split the "NWBC menu roles" and "authorisation roles" could be handy. Important factors are the size of the company (and the number of derived authorisation roles by organizational unit) and if it's a green field installation or an existing system with many existing roles.
A point we still struggle with is the granularity of the roles.
How to manage menu roles if many exist and keep a logic order of the transactions (each time the sequence create-change-display) ?
And how to manage the OBN targets? Should we to combine them in a separate folder in order not to duplicate them and allow to change them easily when needed (consistancy) or should we keep them grouped with the POWL where used (completeness) ?
What are SAP’s recommendations and best practices?
Hi Dirk,
Great questions. I would also love to see some best practice guides from SAP for building NWBC roles. From looking at some of the standard roles they deliver we might get some insights. From what I've seen they provide separate Side Panel roles (search for *BSSP*) as far as OBN goes I have seen the navigation targets added to the roles directly. In the portal the navigation targets for OBN tend to be added to a separate folder in the role called "Navigation" - this seems to work quite well.
There certainly needs to be some discipline and rules laid down to make sure roles are built in a consistent way.
Perhaps somebody from SAP will leave a comment here to guide us.
Cheers,
Simon