Sidepanels with NetWeaver Business Client: Knowled...

former_member182046 · ‎03-08-2013

I am currently working with a customer who is running HANA, and who wants to benefit from HANA not only in the context of analytical applications but use it to add value to transactional applications, too.

Therefore, I am currently implementing a number of scenarios for this customer:

accelerate a long-running batch report from 48 hours to something hopefully much shorter
accelerate an online search dialog (select certain business documents by complex search criteria)
add an analytical sidepanel to a transactional dialog.

The latter is the scenario I’ll tell you a little about. If you’ve been following SAP recently, you will have come across this. It’s frequently called “Insight to Action”, meaning that analytical data from HANA is used in a transactional context where concrete, often low-level but many business decision are being made. By adding information that is normally not available (in real-time) and thus improving the quality of many small business decisions per day, we can add great overall value.

The analytical information is displayed in a so-called Sidepanel, which is a new region on the user’s screen that sits to the right of your typical application canvas (fig. 1).

Fig. 1: NWBC with Sidepanel

Prerequisites

Sidepanels can be added to any application screen, regardless of the UI technology it uses. They can be added to Web Dynpro ABAP, ABAP Dynpro, and browser-based UIs.
The Sidepanels themselves are usually built in Web Dynpro ABAP but can also be built with any browser-based UI technology.
Sidepanels for ABAP Dynpro screens can only be displayed in NetWeaver Business Client (NWBC) for Windows, Desktop Edition, release 3.5 or 4.0. Sidepanels will not be visible if you run the same transaction in SAPGUI, or in the Enterprise Portal, or in NWBC Web Client.
There might be a way to add Sidepanels to Web Dynpro ABAP applications using the Page Builder that doesn’t involve NWBC – I’m not sure here as that was not within the scope of my use case.
Even in NWBC Desktop Edition, the Sidepanels will only be visible if you have configured NWBC to consume user roles from the PFCG roles in an ABAP system, and not to consume pcd roles from an Enterprise Portal.

Client footprint

Installation of NWBC on the users’ desktop computers
NWBC doesn’t use SAPLOGON.INI, so a separate file needs to be created and distributed for the same purpose
Configuration XML files need to be created and distributed
Internet Explorer security settings, trusted zones, etc. need to be configured and distributed
NWBC is rather tolerant with respect to the IE version but the .NET framework must be installed

Accessing the application context

If you’re adding Sidepanels to ABAP Dynpro (SAPGUI) screens, you can do so without changing or modifying those screens. NWBC Desktop Edition takes care of the screen scraping; it extracts the relevant values from the screen as it displays it, and passes the information on to the Sidepanel.
If you want the ABAP Dynpro application to public some information that is not on the screen, and thus not available for scraping, there is an API you can call to make this information available to NWBC and thus to your Sidepanels.
If you’re adding Sidepanels to Web Dynpro ABAP (WDA) screens, you have to make sure there’s a small API call in your WDA component that publishes the relevant information to any Sidepanels that might be listening.

Programming Model

Each Sidepanel can contain a number of CHIPs. CHIPs are Web Dynpro ABAP components that implement a certain interface that enables them to behave in a standardized way in several regards:
to receive and send parameters (“CHIP wiring”)
to be used as blocks in the Web Dynpro ABAP Page Builder
to be found in a CHIP catalog when building or adapting Page Builder pages
to provide a screen for configuration, customization, and personalization
CHIPs don’t have to be built with Floorplan Manager (FPM) – any old Web Dynpro ABAP component that implements IF_CHIP_API will do.
The easiest setup: one Page Builder Page that contains one CHIP.

Controlling the Sidepanel State

If a Sidepanel is available for the current screen this is signified via a small (and easily overlooked) arrow symbol, which, when clicked, will expand the Sidepanel.
There is currently no way to programmatically open a Sidepanel, or configure them to be always expanded. Every Sidepanel must be manually clicked to expand.
There is no easy way to programmatically determine which CHIPs, or which Sidepanel (thus, which Page from the Page Builder) should be displayed. This has to be configured.

Sidepanels in a Side-by-Side Scenario

If your application system (that is the system in which the ABAP Dynpro screens you want to enhance reside) has a NetWeaver release smaller than 7.31 (that is, if you’re not on ERP 6.0 EhP 6 or CRM 7.0 EhP 2), then you’ll need a separate ABAP NW 7.31 system that is called the “role system.” If you’re already on ERP 6.0 EhP 6 or CRM 7.0 EhP 2, then your application system will also serve as the role system.

For the following bullet points, I will assume that you have to run a separate role system because your application systems aren’t yet on NW 7.31.

The existence of a role system means a new SID in the landscape that users have to get acquainted with (even if they’re already using NWBC), because they’ll log on to this system in the future.
The application system (your existing system) needs a trust relationship with the role system – the application system trusts the role system (fig. 2).

Fig. 2: Trust relationship

You’ll need to provision the role system with user ids, for example by integrating it into your Central User Administration (CUA) and replicating users to it (fig. 3).

Fig. 3: User provisioning from CUA

If you want to give users the same menu (SAP Easy Access, or NWBC) they’re used to, you’ll have to import the PFCG roles from the application system into the role system. This will cause the menu to look the same in both systems (except that menus are of course rendered differently in NWBC than in SAPGUI). All transactions will be remote transactions, associated with the RFC destination of the application system.
If your users are accustomed to navigating from the Enterprise Portal, they’ll face some changes. You cannot navigate from the Portal to NWBC – only to SAPGUI, which doesn’t support the Sidepanels. So if you want to see the Sidepanel, you can’t use the Portal. You can import the pcd roles that constitute the users’ navigation menu in the Portal into PFCG roles of your ABAP system, or manually build similar roles, but this is an area I’ll have to examine more closely to find out what the possibilities and restrictions are. I expect that only a small subset of what can be in a Portal role can be imported into a PFCG role.
If users are accustomed to entering transaction codes directly, they’re out of luck. Entering a transaction code directly will cause the transaction code to be executed (or not found) in the role system, not in the application system. The role system doesn’t step into the background and delegate such calls to the application system.
No hub: For each role system, SAP supports only Sidepanels that enhance screens in one application system. So even though the PFCG roles in your role system may contain transactions in two different application systems, SAP will support you only if one of them is the dedicated application system to which all Sidepanels are implicitly assigned.
The reason is that the configuration table which NWBC uses to determine from which dynpros to scrape which values, for which context parameters, doesn’t have a “system” field, so the whole mechanism doesn’t care for in which system the dynpro actually resides. My personal impression from several conversations is that SAP doesn’t support this because they’re not exactly sure what can happen, and prefer a conservative approach.
According to hearsay, a significant number of customers are live with NWBC, but very few (if any at all – I didn’t get a definite answer here) are live with NWBC and Sidepanels in a side-by-side scenario with a separate role system.

Cross-system Navigation

Our customers use a lot of cross-system navigation. There are several ways this can be accomplished. Here are a few words on what changes with NWBC and Sidepanels in a side-by-side scenario.

Frequently, users navigate to a different system via CALL FUNCTION … DESTINATION, where the remote function calls an ABAP Dynpro screen, such as the Business Partner maintenance transaction. These work in NWBC like in SAPGUI, with absolutely no change as far as I can tell. This holds true also if the user jumped from the role system (let’s call it “R”) to the main application system (“A1”) , and via RFC from A1 to a second application System (“A2”). The trust relationship where A2 trusts A1 supports this – no additional trust relationship from A2 to R is required (fig. 4).

Fig. 4: A2 trusts A1

If, before NWBC came along, your users used to log on to A1 and click on an SAP Easy Access Menu entry that lead to a remote transaction in A2, you’ll have to make sure now that the (imported) menu entry in system R which the user will henceforth see points to A2 and not to A1. You will now need a trust relationship where A2 trusts R (fig. 5).

Fig. 5: A2 trusts R

In either case, Sidepanels that enhance screens in A2 are not supported by SAP.
Nobody at SAP seems to know what happens when you jump from a screen in A1 that has a Sidepanel to a screen in A2, and what happens when the configuration table in R has an entry for the REPID and DYNNR of the screen in A2. I expect that NWBC just won’t care about it being in A2 and not in A1 but the fact that NWBC sometimes calls conversion exists via an ICF service could cause a mess.
If your users have a Portal role in an Enterprise Portal system P which points to SAPGUI iViews in systems A1 and A2, then A1 and A2 both trust the Portal (fig. 6).

Fig. 6: A1 and A2 trust the Portal

The new role system R takes the role of the Portal here: You import the pcd role into R as a PFCG role (or create a similar PFCG role in R that links to A1 and A2) and both A1 and A2 must trust the role system R (fig. 7).

Fig. 7: Role import from the Portal

Look and feel

The role menus, workspaces, etc. in NWBC look nice but take some getting used to (fig. 8).

Fig. 8: NWBC's rendition of a PFCG role

Some end user training seems inevitable
The CORBU theme looks good but I find it very hard to work with in practice. The contrast is low, there’s a lot of gray in way, which makes the screen looks as if it were inactive and I had to look for some other window which is currently in the foreground.
The font size is too small, and somehow rough and scrawly, and cannot be changed.
Icons look differently, and frequently used buttons or icons are sometimes hard to find.
Keyboard shortcuts don’t work the same way.
The small arrow that signifies that a Sidepanel is available is easily overlooked.

CRM Specialties

If you read the OSS notes carefully, you will notice that the application system is only ever referred to as the ERP system. So even though I can see no technical argument speaking against the CRM system or other system types being the application system, it is unclear whether this would be supported by SAP.
As is often the case where SAP CRM is concerned, there seems to be no concept for integrating SAP CRM with NWBC. There are a number of questions for which I couldn’t find any answers:
CRM has its own role concept. NWBC cannot consume these roles.
The CRM Web Client L-shape and its content cannot in any meaningful way be consumed by NWBC except that it can display the CRM web page you usually see in the browser in a tab in NWBC.
There is a solution for embedding CRM Web Client without its L-shape into the Enterprise Portal (so that only the L-shape of the Portal is active, but contains the function from the CRM L-shape), but a similar solution doesn’t seem to be available for NWBC.
NWBC cannot screen-scrape CRM Web Client UIs, so if at all, you could publish the application context via API calls. However, it is unclear whether there is an API that can be called from within CRM Web Client, or whether the existing APIs work only for Web Dynpro ABAP and ABAP Dynpro. (Similar questions arise for BSP pages.)
In some cases, NWBC can take care of floating windows in web browser by “catching” such windows into NWBC tabs – however, when I just tried to launch CRM Web Client UI from NWBC, a floating Internet Explorer window was launched, just like without NWBC.
It’s a crying shame that NWBC doesn’t help much in terms of integrating Web Client UI Framework, ABAP Dynpro, and Web Dynpro ABAP, because bridging these UI technology gaps would appear to me to be one of the best uses and raisons d´être for NWBC.

How disruptive is it?

In theory, and probably also in some real-world cases, NWBC can enable the adding of functionality and value to existing applications in a non-disruptive way. I love it that you can add context to existing dynpros without having to change them, or having to wait for SAP to change them. This concept of enhancing existing screens in a modification-free fashion is truly great.
On the minus side, we have a significant client and server footprint, admins are needed to configure the systems and distribute the software, and a new ABAP system is required for applications systems with older releases.
It would be nice if the end user training wasn’t required, for example if one could opt to keep the old SAP Easy Access Menu for a while even after moving from SAPGUI to NWBC.
I don’t see any smooth transitions: There is no clear solution for NWBC to solve integration problems that were previously solved by the Enterprise Portal, so migrating from the Portal to NWBC is not an option.
Even migrating from SAPGUI to NWBC is not an option if you’re jumping from the Portal to SAPGUI.

Summary and Outlook

I see the biggest question marks are in the fields of cross-system navigation, and CRM integration.
If you live in a complex scenarios with a lot of cross-system, cross-application navigation, I doubt you would currently be very happy with NWBC – which is a shame because such scenarios have the very pain points that NWBC could resolve. To put it very bluntly: Anybody can create a nice client for a silo. But to create a client that overarches a siloed landscape and turns it into a whole, with a seamless navigation experience, is the big challenge.
I’m not thrilled about the implications of the side-by-side scenario, especially the fact that users have to get acquainted with a new system, which will be gone after a transitory phase, and the fact that the handling of menus and transaction codes will confuse them. So my recommendation would be to wait for EhP 6 if you can.
If the Portal is an important integration hub for you, wait and see if SAP comes up with good concepts
- either for the Portal and NWBC to work together, i.e. Portal iViews launching NWBC or running it in-pace instead of SAPGUI,
- or for NWBC to take over more functionality from the Portal, especially with respect to
  - launching different kinds of iViews (gap between PCD roles and PFCG roles),
  - integrating CRM into the user’s workflow
  - Single Sign-On.
Currently, in my personal opinion, NWBC is not a good fit for integrated landscapes, which is a funny thing to say about a software that is primarily intended to improve the integration in such landscapes (forgive me if I’m mistaken here, but right here I have a vivid mental image of wolfgang.weiss nodding and chuckling in his signature “it hurts but you’re right” manner).
SAP should merge SAPGUI and NWBC to make things simpler. Take the complexity out. Just make the next release of NWBC available as SAPGUI 8.0 (to use existing software distribution paths in the companies) and fix a few inconveniences:
- separate configuration files,
- fix the obligatory replacement of the SAP Easy Access Menu with the NWBC menu (make that configurable), and
- make themes and font sizes more configurable.

Thanks for bearing with me, and please share your experiences with NWBC and sidepanels in the comment section.