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:
pcd://portal_content/com.sap.pct/every_user/com.sap.pct.erp.ess.bp_folder/com.sap.pct.erp.ess.roles/com.sap.pct.erp.ess.employee_self_service/
com.sap.pct.erp.ess.employee_self_service/com.sap.pct.erp.ess.area_employee_search/com.sap.pct.erp.ess.changeowndata
Note that the navigation target is a WDJ page delta-linked to the workset com.sap.pct.erp.ess.area_employee_search which is in turn delta-linked to workset com.sap.pct.erp.ess.employee_self_service which is then in turn delta-linked to role com.sap.pct.erp.ess.employee_self_service. 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 com.sap.pct.erp.ess.changeowndata 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 com.sap.pct.erp.ess.area_employee_search 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 com.sap.pct.erp.ess.area_employee_search in the central portal, and remove the WDJ page com.sap.pct.erp.ess.changeowndata.
2. In the central portal, create an advanced WDJ iView that integrates the remote WDJ page of com.sap.pct.erp.ess.changeowndata. Make sure the ID of the iView is com.sap.pct.erp.ess.changeowndata.
3. Add the newly-created iView to the workset com.sap.pct.erp.ess.area_employee_search.
4. Open the permission editor of the role com.sap.pct.erp.ess.employee_self_service 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 com.sap.pct.erp.ess.changeowndata 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.
Conclusion
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.
- SAP Managed Tags:
6 Comments
