Skip to Content

Part 2 – Accessing multiple systems in NWBC


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 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.


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.


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!

You must be Logged on to comment or reply to a post.
    • Thanks Sandra, I look forward to reading that blog!

      I have to say that I really feel like we will see lots of companies move from classic SAPGUI to using NWBC in the next year or so and I think there will be opportunities for people with SAP Portal skills to cross over. I hope this series of posts helps those people get up to speed with NWBC.

  • Hi Simon

    I'm enjoying the blog series so far.

    Just wondering if you'd share your thoughts on the best system to use to consolidate the NWBC roles?

    NWBC can consume portal roles, right? So I suppose that if a customer has a SAP portal system already then it might make sense to consolidate the NWBC roles there? If not, does it make sense to consolidate roles in the most used system (ECC?) or look at a more centralised, technical system like Solution Manager or a dedicated ABAP system in which to create the NWBC roles?

    I hope this comment isn't too far off track for this blog post... Feel free to reply with a whole new blog post if you want. 😉



    • Hi Glen,

      Glad you're enjoying reading them, I'm quite enjoying writing them - have wanted to for a while.

      But to your question. Yes NWBC can be connected to a portal, but I would question the value of doing that. I have to say that I see NWBC as a way of potentially removing the Portal from your system landscape (that might provoke some reaction 😈 for the portal folk) and simplifying it. Of course if you are using portal specific features like KM, Web Page Composer, Wiki, Forums, Federation etc... then that's not going to work, but I know a lot of places that don't do that so NWBC could simplify their setup IMO.

      So far I think ERP is the best system to be the main NWBC system, all users probably already exist in ERP (e.g. for HR) and ERP tends to already be connected/trusted to/by most of the other systems in your landscape, thereby making it easy to provide remote content from these systems too. Of course technically you could use Solution Manager or even a dedicated ABAP system (maybe a Gateway system).



  • Hi Simon,

    Concerning your ". Of course technically you could use Solution Manager or even a dedicated ABAP system (maybe a Gateway system)."...

    Do you know of any customers who provision NWBC on their HUB Gateway?  I've been thinking about this now and was wanting to continue the beautiful "UI" layer that we've setup for Gateway/UI5 development.

    I would then proceed to create the "Content/Menu NWBC" Roles in the gateway for users only.  My big issue with NWBC so far is that we are on EHP4 7.02 unfortunately in our ECC6 ERP Backend...  I've got our gateway client up on 7.41 🙂 .  The "SIDEPANELS" I'm thinking out loud here, could they be provisioned from my more up to date GW system?  (Sidepanels are only available to those lucky companies who are up with EHP6 and better - so I'm thinking we'd still not have them unless the sidepanels were written to consume odata.)

    Thanks for any insight to my thoughts...


  • Hi Simon, hi everyone,

    @Simon  - Thanks for this blog series - really interesting for me, since I'm no Portal expert.

    Connecting 2 Backend Systems, Part Three: Single Sign-On

    @everyone: "Yes NWBC can be connected to a portal, but I would question the value of doing that". I would definitely agree with Simon. I hope to blog on this soon, but just for now:

    The rule of thumb is Portal stack -> Portal client; Business Suite (ABAP on-Premise) -> Business Client. Otherwise, you are creating an unnecessary level of complexity in your system. Note: The Portal is a better integration hub for Cloud / Mobile support, so if you have eg Success Factors or Ariba,or have mobilized your workforce, then you should stick with the Portal.

    Also roles:  ABAP on-premise systems store roles in the PFCG repository; the Portal stores roles in its own PCD repository. So if you have all your roles stored in an ERP system already, then you cant "consolidate" them with the Portal. This also means that PFCG role-dependent features - primarily Side Panel, also some Page Builder chips - cannot be used if you use Portal as the hub. NWBC *can* consume both PCD and PFCG roles, but the use case is: If you work 80-90% on an ERP system, and need access, eg to a Portal-based Intranet, then you can consume the Portal content via NWBC. If, conversely, you work 80-90% with Portal content, then you should use the Portal client.

    I don't actually see NWBC eliminating the Portal (sorry, Simon, can't endorse you there); rather I see 2 distinct products with 2 distinct use cases. However, I suppose in that scenario you describe, where you aren't using any Portal features - or Java, or third-party, or Cloud, or Mobile, then you could simplify the landscape by using an ERP system as your main system. (As I say, wait for the blog 😉 ).

    Best wishes;

  • Hi Simon,

    quick question...   right now my NWBC users authenticate through SAP when they log in (i don't want SSO to AD yet...)  but once they have authenticated within NWBC i want them to be able to access BI content via infoview or through documentIDs without having to authenticate again on the BI server.    

    How do we go about doing that?

  • Hi Simon,

    We have an exact similar situation with one of our client where we want to have a central MDG instance for vendor which will manage the general/basic data and then the purchase org/ comp code data will be managed in the BA/BU (Business Area/ Business Unit) specific MDG instances. We need to use MDG 7.0 during this implementation and also have NWBC as the UI. What we want is to have a single sign on for both the systems and then user is able to access both the different instances ie Corp MDG and BA/BU MDG Vendor UI screen from one place, where user will enter vendor data related to Corp MDG (Basic/General Data) and also BA/BU (Purch Org/ Comp Code) data.

    Once submitted the General Basic data will go to the Corp MDG and Purch Org/Comp Code will go to the BA/BU MDG instance.

    Please let me know if you consider this as a feasible scenario and if yes then some more input or steps or a much detailed blog is really appreciated 🙂



  • Hello Simon,

    First of all thanks for this blog.

    I have a question here. We have a scenario where we want to launch the Webdynpro application of system B when I access from the menu item in the menu role of system A.

    So in this case, my understanding is that

    1. We create RFC destination of type "H" in system A which holds the details of the target system B
    2. Add the node type Webdynpro Application in the menu role of system A and provide the details of the application in system B.
    3. Choose other node details and in the target system provide the RFC destination type "H" created.

    Is my understanding correct?

    Thanks and Regards

    • Hi Aurn,

      Yes that is basically correct. You might not be able to add the Webdynpro app in System A if the same app doesn't exist in System A. You might have to create a dummy role in System B and import the Webdynpro app from that role (import from remote system).