Skip to Content

A New Approach to Integrate WebDynpro Java Applications into NetWeaver Portal (Part III)

This is the third blog in this blog series. Before you proceed into this advanced topic, I would recommend that you read the previous two blogs first:

A New Approach to Integrate WebDynpro Java Applications into NetWeaver Portal (Part I)

A New Approach to Integrate WebDynpro Java Applications into NetWeaver Portal (Part II)


While I was writing the last two blogs of this blog series, I received a lot of questions around how to choose the best way to integrate WebDynpro Java-based business suite applications, such as ESS/MSS, from a remote portal into the central portal; in particular, whether the new advanced WebDynpro Java iView is preferrable over the Federated Portal Network (FPN) approaches, i.e. Remote Role Assignment (RRA) and Remote Delta Link (RDL).


Well, the new advanced WDJ iView has pretty much covered the functionalities of RDL, without the need to setup an FPN. Therefore normally I would not consider RDL unless there are special reasons to do so.


As we have seen the powerful feature of the new advanced WDJ iView in the first blog, can we draw a quick conclusion that the new iView is also preferrable over RRA for integrating WDJ-based business suite applications? To answer that question, we need to look into the implication of the way those WDJ applications make use of the portal navigation service, and to what scale you plan to integrate those remote WDJ pages.


A Deeper Look into the ESS Business Package (ver. 1.41)

Let’s first walk through the integration steps to make sure that internal links on a remote ESS WDJ page work properly, and then look into the pros and cons with different integration approaches.  In the following example, the initial WDJ page that contains internal links is the page “Who’s Who”:


On this page, there is a link to another WDJ page “Change Own Data”. This link triggers an Absolute Navigation to the following PCD object:



Note that the navigation target is a WDJ page delta-linked to the workset which is in turn delta-linked to workset which is then in turn delta-linked to role As you may have already foreseen, building the corresponding navigation target in the central portal would require a lot of steps, as you need to build the corresponding PCD folders, roles, worksets and iViews. Therefore the recommended approach here is that you deploy the ESS business package to the central portal as well (but not deploy the WDJ applications to the central portal), and make minor modifications to the business package. This way we can save a lot of efforts in building the basic PCD objects required.


One important thing that we need to note here is that the navigation target is a WDJ page. However on the central portal, we need to make it point to the remote WDJ page, which can only be achieved by the new advanced WDJ iView (not a page!). So what we need to do is to replace the WDJ page in workset in the central portal with the new advanced WDJ iView (with the same ID as the WDJ page Change Own Data) that points to the remote WDJ page Change Own Data. Here are the detailed steps:


1. Open the workset in the central portal, and remove the WDJ page


2. In the central portal, create an advanced WDJ iView that integrates the remote WDJ page of Make sure the ID of the iView is


3. Add the newly-created iView to the workset


4. Open the permission editor of the role in the central portal, and assign End User permission to the end user (in this case, dongpan). Note that normally you should not assign the role to the end user.


5. Open the permission editor of the WDJ page in the remote portal, and assigne End User permission to the end user (dongpan).


After performing the above steps, the internal link “Change Own Data” should work now in the central portal.


A thorough look into the ESS business package reveals that most internal links in the ESS applications are Absolute Navigation links to pages embedded in the ESS role, so the above steps can be considered as general implementation steps to make sure that internal links in the remote ESS WDJ pages work in the central portal.


Now let me try to address the question about choosing the best approach to integrate remote ESS/MSS WDJ pages. I would like to categorize the use cases into the following scenarios:


1. Scenario 1: you want to integrate just a few remote ESS/MSS WDJ pages here and there and incorporate them into your central portal’s role structure

In this case, the new advanced WDJ iView is usually the best choice, as you don’t need to setup FPN for this. The effort to create the iViews and to modify (and maintain) the existing role content is minor. You can enjoy the benefit of incorporating those iViews into your central portal’s navigation structure flexibly.


Note: it is recommended to deploy the business package to the central portal as well (not including the WDJ applications) to reduce the efforts in building local navigation targets. 


2. Scenario 2: you want to integrate a large number of ESS/MSS pages (within one or a few roles) from the remote portal, or you simply want to integrate the entire ESS/MSS navigation structure from the remote portal to the central portal.

In this case, RRA/FPN would be a better choice. Using the new advanced WDJ iView would suffer from the following drawbacks:

1) High amount of effort to modify the role content in order for internal links to work.

2) As the ESS/MSS WDJ applications mainly use Absolute Navigation, the ESS/MSS business packages need to be deployed on the central portal as well, and the modification must be performed on the business packages on the central portal. Therefore when deploying newer versions of the business packages to the central portal, the modification (and permission setup) must be re-done.


In case of business packages whose corresponding WDJ applications do not make use of portal navigation services, you may consider using the advanced WDJ iView even when you want to integrate a large number of remote WDJ pages, as you don’t need to deploy and maintain the business package on the central portal.


3. Special scenario: an ESS/MSS business package is already deployed on the central portal for other purposes, such as for the employees in a different subsidiary.

In this rare case, it is impossible to use the new advanced WDJ iView if you want to make sure that the internal links work. You would have to rely on FPN to integrate remote ESS/MSS WDJ applications.


Off-Topic but Important

Now you have understood the implication of ESS/MSS using Absolute Navigation on choosing the integration approach for remote ESS/MSS applications. You might have started to wonder why we would have ESS/MSS on a remote portal in the first place? We wouldn’t have to go through such a long journey if we deployed the ESS/MSS applications on the central portal directly. Well, this is a portal deployment question in nature which is beyond the scope of this blog. But in short, if your central portal serves as an application-centric portal, then the general recommendation is to deploy the ESS/MSS WDJ applications to the central portal directly (without using a seperate remote portal); while if your central portal serves as your corporate portal, you should generally deploy the WDJ applications such as ESS/MSS to a seperate portal (treated more like an application runtime than a real “portal”).


For details about the current portal deployment recommendations, see FEATURED EVENTS.



In this blog I have described how typical WDJ-based business suite applications (such as ESS/MSS) make use of the portal navigation service, and elaborated the implication of Absolute Navigation links on the selection of integration techniques for remote WDJ pages. In most cases, if all you want to do is to integrate a few remote WDJ pages and incorporate them into your central portal’s navigation structure, the new advanced WDJ iView would be the best fit; if you would like to integrate the entire navigation structure of the remote business package, or you want to integrate a large number of remote WDJ pages that reside in one or a few roles, RRA may become a better choice, especially when those WDJ applications make use of Absolute Navigation.


With this I would like to conclude the blog series. Thank you for your patience in reading all the three blogs, and I hope it is useful for you when designing your portal landscape and integrating WebDynpro Java applications. If you have got any question about this topic, please feel free to add your comments below.

You must be Logged on to comment or reply to a post.
  • Hi,
    Your blog was very useful. I have some question regarding that
    When we create webdynpro iview it has two option 1. Basic 2. Advanced. Using advanced we can see remote PCD folder and select page from that.
    Using Basic we have to enter application name space and application name.
    is there any difference between Basic & Advanced?

    please let me know.


  • Scenario - BP on central Portal/ only WD4J on Remote Portal

    SAP supports above scenario so that from iviews of ESS/MSS BP connect to remote application code?
    How to acheive the above if supported as code-link in i-views points to local.

    • Hi Rajesh,

      The scenario you described is not supported. The supported scenarios are:
      1) BP on both the central portal and the remote portal, while the WDJ apps are on the remote portal only.
      Suitable to integrate a few remote WDJ pages into the central portal here and there (i.e. ad-hoc integration). The technique used is the new AI iView discussed here (without relying on FPN). Note that the BP on the central portal needs to be modified using the new AI iView.

      2)BP and WDJ apps on the remote portal only
      Suitable for incorporating the entire role structure to the central portal. You have to use RRA (FPN) here.

      The detailed knowhow and pros and cons about the two scenarios can be found by reading all three parts of the blog series.


  • Please advice the option in which there's no need to have users setup in Remote Portal and Roles to Users Assignement managed only on central portal.
    If above is acheivable still we need all users on remote portal for SSO?
    • Hi Rajesh,

      Since the question is going into the implementation direction, can we take this offline and discuss it by email? I remember working with you 1 or 2 years ago.