h3. Introduction In my last blog (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 I))), I demonstrated how to use the new advanced WebDynpro Java iView to integrate remote WebDynpro Java pages (tightly-coupled). You may still remember that the demo WebDynpro Java (WDJ) application I used has three buttons on it: 
When accessing the WDJ application from the remote portal directly, after clicking the "Google Search" button, the end user will navigate to the following URL iView (Note this triggers a portal navigation event to a PCD target, instead of a simple URL link): +pcd://portal_content/TestApps/Google+ This is achieved by the WDJ Portal navigation feature, one of the features brought by the tightly-coupled WDJ-Portal integration technique. Behind the "Google Search" button is the following Java code: +WDPortalNavigation.navigateAbsolute("ROLES://portal_content/TestApps/Google", WDPortalNavigationMode.SHOW_INPLACE, null, null, WDPortalNavigationHistoryMode.ALLOW_DUPLICATIONS, null, null, null);+ The navigation API +WDPortalNavigation.navigateAbsolute()+ is built upon EP Client Framework (EPCF); in other words, during runtime the Java code will be translated into EPCF Javascript API invocation of +EPCM.doNavigate()+. h3. The Problem It all works fine when you access the WDJ application directly in the remote portal. However, when the tightly-coupled WDJ page is integrated into the central portal, the navigation step will fail because the EPCF objects in the web browser belong to the central portal, not the remote portal. As a result, the browser will try to access the target PCD object in the central portal, which is not there. The same issue applies to other WDPortalNavigation APIs as well: - Relative Navigation: +WDPortalNavigation.navigateRelative()+ - Object-based Navigation (OBN): +WDPortalNavigation.navigateToObject()+ and +WDPortalNavigation.navigateToObjectWithSpecificOperation()+ The only way to resolve this issue is to build corresponding local navigation targets in the central portal. But before we do that, how do we find out what navigation targets are referenced by the WDJ applications in the first place, especially when the WDJ applications are not developed by yourself? Well, if you are a Java developer, of course you can de-compile the WDJ code and search for the occurrences of the WDPortalNavigation API usage. However if you are not that crazy:), you can still find it out by performing simple runtime analysis. h3. Runtime Analysis - finding the referenced targets There are two ways to conduct the runtime analysis: h6. 1. HTTP Trace analysis Use a client-side HTTP tracing tool, such as HTTPWatch, you can find the details of the navigation targets in the POST parameters and query strings of the *second* POST request after you click the button. 
As shown in the above screenshot, the POST parameter +NavigationTarget+ contains the navigation target information in the case of Absolute Navigation. In case of Relative Navigation, the navigation details are contained in: 1) POST parameter: - +RelativeNavBase+ 2) Query Strings: - +RelativeLevelsUp+ - +RelativePathList+ For Object-based Navigation, the navigation details are contained in the POST parameters: - +businessObjName+ - +objValue+ - +operation+ - +systemAlias+ h6. 2. Portal Tracing Analysis By using the *LogWatch* tool in the portal (http:///irj/servlet/prt/portal/prteventname/HtmlbEvent/prtroot/com.sap.tc~ep~common~logWatch.LogWatc...), you can change the trace level of specific trace locations for a short period of time and record what happened. Here we will change the trace level of trace location +com.sap.portal.navigation+ to +DEBUG+: 
Click the Record button in the LogWatch tool, and then click the "Weather" button in the demo WDJ application (in another user session). Stop the recording, and you will find the following trace:
When accessing the WDJ application from the remote portal directly, after clicking the "Google Search" button, the end user will navigate to the following URL iView (Note this triggers a portal navigation event to a PCD target, instead of a simple URL link): +pcd://portal_content/TestApps/Google+ This is achieved by the WDJ Portal navigation feature, one of the features brought by the tightly-coupled WDJ-Portal integration technique. Behind the "Google Search" button is the following Java code: +WDPortalNavigation.navigateAbsolute("ROLES://portal_content/TestApps/Google", WDPortalNavigationMode.SHOW_INPLACE, null, null, WDPortalNavigationHistoryMode.ALLOW_DUPLICATIONS, null, null, null);+ The navigation API +WDPortalNavigation.navigateAbsolute()+ is built upon EP Client Framework (EPCF); in other words, during runtime the Java code will be translated into EPCF Javascript API invocation of +EPCM.doNavigate()+. h3. The Problem It all works fine when you access the WDJ application directly in the remote portal. However, when the tightly-coupled WDJ page is integrated into the central portal, the navigation step will fail because the EPCF objects in the web browser belong to the central portal, not the remote portal. As a result, the browser will try to access the target PCD object in the central portal, which is not there. The same issue applies to other WDPortalNavigation APIs as well: - Relative Navigation: +WDPortalNavigation.navigateRelative()+ - Object-based Navigation (OBN): +WDPortalNavigation.navigateToObject()+ and +WDPortalNavigation.navigateToObjectWithSpecificOperation()+ The only way to resolve this issue is to build corresponding local navigation targets in the central portal. But before we do that, how do we find out what navigation targets are referenced by the WDJ applications in the first place, especially when the WDJ applications are not developed by yourself? Well, if you are a Java developer, of course you can de-compile the WDJ code and search for the occurrences of the WDPortalNavigation API usage. However if you are not that crazy:), you can still find it out by performing simple runtime analysis. h3. Runtime Analysis - finding the referenced targets There are two ways to conduct the runtime analysis: h6. 1. HTTP Trace analysis Use a client-side HTTP tracing tool, such as HTTPWatch, you can find the details of the navigation targets in the POST parameters and query strings of the *second* POST request after you click the button. As shown in the above screenshot, the POST parameter +NavigationTarget+ contains the navigation target information in the case of Absolute Navigation. In case of Relative Navigation, the navigation details are contained in: 1) POST parameter: - +RelativeNavBase+ 2) Query Strings: - +RelativeLevelsUp+ - +RelativePathList+ For Object-based Navigation, the navigation details are contained in the POST parameters: - +businessObjName+ - +objValue+ - +operation+ - +systemAlias+ h6. 2. Portal Tracing Analysis By using the *LogWatch* tool in the portal (http:///irj/servlet/prt/portal/prteventname/HtmlbEvent/prtroot/com.sap.tc~ep~common~logWatch.LogWatc...), you can change the trace level of specific trace locations for a short period of time and record what happened. Here we will change the trace level of trace location +com.sap.portal.navigation+ to +DEBUG+: Click the Record button in the LogWatch tool, and then click the "Weather" button in the demo WDJ application (in another user session). Stop the recording, and you will find the following trace:- SAP Managed Tags:
