To EP or Not to EP? That is the question

former_member195896 · ‎05-31-2007

This is a question that often perplexes both customers and consultants alike: Should we use Enterprise Portal (EP) in our implementation now or should we open the lid of that box a little later… or perhaps not at all? In the current scenario it is often easier to just take a look at the immediate SAP requirement and make a decision on the usage of the Portal. Some of us know that this is really not the best way to decide the existence and usage of SAP Netweaver Portal in our landscapes.

The first thing to do is to take a look at the bigger picture and try to see what exactly a portal means. I think the main question to answer is: Is the Portal just another client for my users to access the ERP application or can the Portal be my gateway to controlling access to IT applications/knowledge centres/unstructured information/business applications/tools etc. through a single access system with a unified look and feel to my applications?

These questions may be easier to answer if you understand the direction SAP is taking with its User Interface (UI) Engine. After all, you would like to implement something that is in line with their strategy so as to make things easier in the future, wouldn’t you? And a single access point for UI changes for applications does not seem like a bad idea, does it?

Unified Rendering Framework

The Unified Rendering Framework is used for formatting all SAP web applications (NW2004s). It is used in both the SAP Netweaver Portal and Web Dynpro. If you use the Portal you can use the theme editor to change styles and CSS files for a theme set in the Unified Rendering Framework. For more information, look at the following SAP Help links:

http://help.sap.com/saphelp_nw2004s/helpdata/en/44/317d1f955e3f0ae10000000a114a6b/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/42/c1dd9c6d8f1d72e10000000a1553f6/frameset.htm

With this Portal Theme Editor you can change and control the look and feel of all your web applications, like BI 7.0 and CRM, including ones using the older rendering engine. Look at this SAP note for more information: 839873

So, basically, if you do implement the Netweaver Portal you get an option to control the look and feel of the complete IT end user foot print.

But…

Let’s look at some common questions that may decide the fate of the Portal.

1 I have BI 7.0 running and I want to use 7.0 web templates for reporting. Do I really need EP?

Yes, you do need to use the Netweaver Portal (Enterprise Portal) with your BI implementation. It is now a prerequisite, especially if you plan to use BI 7.0 Web Templates. These templates have shifted to a Java runtime and are now rendered in the Java Engine. These are new and improved versions of the templates with added features (like bookmark integration into KM etc.). Plus, you can use the Portal Theme to control the look and feel of BI 7.0 Web Templates. For more information look at my earlier blog:

Altering Colour Themes for BI 7.0 Web Templates

2. I have very complicated and data sensitive applications. I think the Portal cannot and should not handle that.

The Portal can provide you a different UI and platform independence from your existing applications.If your project can invest in some development time, then the application/user relevant UI can be ported into the Portal through either Web Services/JCO connections etc. This way you can ensure that the use of your “complicated application” is not dependent on a client software. Wait… I think I can hear some of you saying, “But that’s what I want!” Well, you can configure that in the Portal itself.

The Portal supports many different levels of authentication built in. For example, if you need two extra levels of authentication in an iview then it is possible to have that. So the scenario after enabling this would look like this:

End User logs into the Portal.
End User navigates to the iview in concern and is asked for two more levels of authentication (maybe an RSA code, etc) to gain access to that application.
If the out of the box options do not fit the bill (maybe you want to restrict it to a host), then you can develop any solution you need and deploy and use it in the Portal. More on this in a different blog coming soon.

This solution gives you the option of maintaining a central point of access for your end users even for a complex application, and hence a central point for security and monitoring usage.

3. Should I add access to all the roles through my Portal? I have roles with over 300 users attached and some with only about 30 users attached. OR Should my users only use the SAP ERP backend systems?

The question you should be asking is, “Do I really want tomaintain security, role authorisations, front-end UI clients, company IT experience, system/application messages, user help and feedback differently for different sets of users in my company through different applications?”

You can take EP as a single point of entry for end users in your landscape. You can provide them with access to all the applications they need and also a central way to monitor their usage, provide them help and other knowledge/documents. Many can think of EP only as ‘another’ SAP access tool but if you use all its functions then you can make it much more than that. EP can be utilised as an entry point for the user’s applications and all other information related to those applications, be it support/help documents, online help or support forums. It is not difficult to actually make these scenarios available to your users in the organisation.

Finally, if you include one transaction, there is nothing really stopping you from adding the others, in terms of technology, hardware requirements or security aspects.

4) Should I add only critical transactions to EP?Should I add heavy transactions to the Portal?

Why? Do you really want your users to use EP only for some transactions and SAP GUI for all others? When you release access to some transactions through EP you are basically setting up a landscape for that. Once you have done that, then it is only a matter of adding another transaction/BSP iview, etc in the same setup. Refer to Point 3 above.

What’s weight got to do with it?

When it comes to heavy transaction codes, it is possible that they are more efficient with the SAP GUI. Take the transaction RSA1. This is a heavy transaction in the BI solution offered by SAP. Transactions like these can be more efficient if used with the SAP GUI itself. So that is one aspect you could take into consideration. But with the integrated ITS, you really should check if the Web GUI works for you or not. If it does, then go ahead and integrate it with your EP. After that you will use the Web GUI of the internal ITS itself and will not require any further development. Or for one more option you can actually call the SAP GUI installed on the user’s system from the Portal.

5) If we upload everything from our backend ABAP systems to the Portal, we will have a nightmare of a time managing user authorisations in the landscape, and what about the roles?

Well, initially one would have to set up the relationships between the content and authorisation, but, once done, the day-to-day operational processes are completely minimal. SDN has documents available which show how effortless it can be.

The Portal also has features of a navigation cache. It caches the role and its navigation points, so people with the same role(s) attached would get their navigation hierarchy points retrieved from the cache. There are different points to take care of when using the navigation cache. For more on this, look at this blog on SDN:

Be Careful When Combining Navigation Cache, PCD Filter

Consider this scenario:

ABAP roles are created in the backend system and assigned to users there.
In the Portal the ABAP roles and transactions are imported through the Upload Tool and this results in Portal objects corresponding to ABAP roles and transactions in the iview. The navigational hierarchy is decided by the hierarchy structure in the ABAP roles themselves.
The Portal Role Objects are then assigned to ABAP Groups (These are the same ABAP roles, viewed as ABAP Groups in the Portal. Hmm, isn’t that convenient.)
Now when a user is added to the ABAP Role, he/she will get the portal role and its transaction iviews assigned to them automatically (without doing anything in the Portal!)

This and many other options are available for use (including when EP defines authorisations for ABAP and vice versa). These are documented in SDN. Will feature them on one of my next blogs.

6) But if I add all my content on the Portal, then there will be too many Portal Roles. And what about multiple entries of the same navigation node in different roles?

If you replicate all your content in the Portal from your backend ABAP systems, then the number of roles and their entries are defined by your ABAP roles and their entries, so if you optimise those roles, this will improve. Nonetheless, there are many solutions available in the Portal to help you resolve this issue. One such concept is the Merge ID concept. It is explained very well in the following wiki link.

http://www.sdn.sap.com/irj/sdn/wiki?path=/display/ep/using%2bmerge%2bids

Finally, it can be said that EP offers no restrictions to add content there (In terms of non SAP applications, the following applies: your target application should be either web enabled or accessible from the EP APIs either through DBs, .net APIs, web services, XML etc).

Constraints

However, there can be some other constraints in terms of budgets, timelines or hardware availability, and these issues can really decidewhat content should be present in your EP installation and what should not. In these scenarios, you can consider these thumb rules:

1) Use standard Business Package Content whenever possible.

2) Upload your Roles and Transactions on a first come, first serve basis. You will need to make a list of content in the backend and prioritise.

3) If you need to expose something on the Web (internet/intranet) then give such content/application priority of inclusion.

4) Standard application like ESS/MSS and some X-Apps, BI 7 require or work better with a Portal solution present. So these applications/content automatically have inclusion priorities.

5) Really heavy transactions like RSA1 can have a lower priority of inclusion, unless point 3 is valid for them.

6) If your users need to access multiple applications, then give the application start points/iviews inclusion priority.

7) And remember, it’s a Portal. You can make it look like anything you want. Absolutely anything, be it Flash, animated images or the amazing SDN!

There is a wiki page in SDN WIKI, which also talks about when to and when not to use EP. This is a good document, and in my opinion is a good read if you have constraints as mentioned above.

WIKI Link: https://wiki.sdn.sap.com/wiki/display/profile/2007/05/22/When+to+When+Not+to+use+Enterprise+Portal