Part 2 – Accessing multiple systems in NWBC

Introduction

This is the second in a series of posts I hope to write on the topic of NetWeaver Business Client. I am writing these posts from my own view point as a long time NetWeaver Portal consultant and I am trying to compare concepts that I am familiar with from the Portal with similar concepts in the NWBC. You can find out more about my motivation for writing this series of post by reading The NetWeaver Business Client (NWBC) – A Portal Consultants Guide. My goal is to show the way things are done in NWBC to other people already familiar with the Portal.

Multiple Systems… why?

One of the key features of the Portal is the ability to connect to multiple SAP systems. A typical SAP customer landscape may consist of ERP, SRM, CRM, GRC, Solution Manager etc.. etc.. the list goes on. From a user perspective it is nice not to have to logon to each of these systems separately but rather have a single place to access everything. It turns out you can do this with NWBC too, and the process is very similar to how it is done in the portal. The main difference is that with NWBC you generally have the NWBC connecting to one of these systems directly (lets say that is your ERP system). So in this scenario the ERP system is playing the parts of a back-end system and of a portal (with some help from NWBC). The next few sections will describe how to go about adding content from other systems into your NWBC role.

Trust

Trust is an important thing, hard to build but easily lost 😀 … but when it comes to SAP systems it’s not that hard to build (you might want to smile nicely at your friends in the Basis team). I’m not going to go into details here but you can start by checking out the help documentation. Just as the portal has a private certificate that needs to be imported into any other system you want to be able to single-sign-on to, your ERP system has a private certificate too. You need to make sure that all systems you want to access via NWBC trusts the ERP system certificate.

Systems

In the portal you have the System Landscape configuration that is usually taken care of by your portal administrator. In the system landscape you can define which systems the portal can connect to and also ensure that there is the necessary trust established between the portal and those systems to enable single-sign-on (SSO). The equivalent for NWBC is transaction SM59 in your ABAP system. In transaction SM59 you define your destinations, but unlike the portal for NWBC you will need to create two destinations for each back-end system you want to connect to (one for RFC – type 3 and one for HTTP access – type H). This is so that the NWBC can open both web-based and SAPGUI based content. These systems are generally given the suffixes _RFC and _HTTP, for example you might have ERPCLNT123_RFC and ERPCLNT123_HTTP.

Define your system destinations in transaction SM59

In the portal there is the concept of system aliases… and you know what?… NWBC has the same thing. You need to go into transaction SM30_SSM_RFC, in there you can define aliases for the destinations you created in SM59. Why bother with an alias? Well it makes transporting from Dev to Test to QA to Production etc… much easier as you can use the same alias, but in each tier of your landscape you can map it to the appropriate system.

Example of setting up RFC destination variables (aliases) in transaction SM30_SSM_RFC

Once you have your systems (and variables/aliases) defined you can proceed to adding some content from another system into your NWBC role.

Roles

I talked a bit about roles in my first post Part 1 – Portal roles vs NWBC roles. In NWBC go to transaction PFCG and open an existing or create a new role. Now you want to add some content from another system. Add your transaction or Web Dynpro or BSP etc… to your role and then go to the additional node details where you can see the target system will be empty. Here you can insert the name of your SM59 destination or the alias you created earlier. And that is pretty much it, save your role and give it a go.

In transaction PFCG add your application to the role menu and see “Other Node Details” to provide the Target System

One small gotcha here is that the target transaction/app/bsp must exist in the NWBC system to be able to add it as I describe above, but in lots of cases that won’t be the case. For example SRM has Web Dynpro applications and transactions that don’t exist in ERP. In this case you import these from the external system. To do this go to “Copy Menus” –> “From Another Role” –> “Target System”. Then find the role in the target system that contains the transaction or application you want and copy it across into the ERP system. This will automatically fill in the target system parameter for everything that is copied.

Example of how to copy a menu from a role in another system

Wrap up

So that’s about it. Simple right? There are some interesting things we can still discuss like Object Based Navigation (OBN) and how this works in the context of multiple remote systems, but I will leave that for another post. I think you will agree that just like the portal, NWBC can quite easily connect to multiple systems to provide users with a seamless experience across a potentially complex SAP landscape.

*** UPDATE: I would highly recommend you also read Julie Plummer series of posts on this topic. You can find the first one here Connecting 2 Backend Systems, Part One: RFC Connections ***

As always I really like to get your feedback, so please add your comments and thoughts below. Thanks!