Now let’s create the iView on the central portal. In this demo I added the End User permission to all Authenticated Users for simplicity reasons. Note that we need to add “End User” permission to the central portal users for this system object. Secondly, I created a system object in the central portal to represent the remote portal. Then I add a system alias for the remote portal as “RemotePortal”.
Unlike the FPN setup, here we don’t need bidirectional SSO. The following is a screenshot of the WDJ application inside the remote portal:įirst of all, I have setup unidirectional Single Sign-On (SSO) from the central portal to the remote portal. After that, I added the iView to a WebDynpro portal page. On the remote portal, I created a small Webdynpro Java application called Useful Web Sites additionally, I created a tightly-coupled Webdynpro Java iView to integrate the WebDynpro application. The trick is, the entire remote WDJ portal page is integrated to the central portal with an innovated Application Integrator mechanism. With the new advanced Application Integrator introduced by EP 7.01 SPS6 (and EP 7.02 SPS2), you do not have to setup FPN in order to integrate remote WDJ iViews (tightly-coupled) any more. However we need a simpler approach to avoid implementing and administering an FPN setup, especially when we just want to integrate a few remote WDJ applications. Traditionally, we had to rely on Federated Portal Network (FPN) features such as Remote Role Assignment (RRA) or Remote Delta Link (RDL) to do this. It is often a natural requirement to integrate those remotely-deployed WDJ applications (together with their corresponding tightly-coupled iViews) into the central portal. Furthermore, many of such WDJ applications are deployed onto seperate portal systems other than the central portal, due to various reasons such as maintenance/performance considerations. Over the years, people (customers and SAP) have developed a lot of WDJ applications that interacts with local portal runtime, such as ESS/MSS. the WDJ applications and the portal can reside on different AS Java engines, but it lacks of the advanced “interaction” between the WDJ application and the portal runtime. This option offers great deployment flexibility, i.e. In essence, it is a URL redirection mechanism enhanced by rich parameter passing/handling during the redirection. This technique is based on the widely-used Application Integrator iView in the portal. On the other hand, obviously, the drawback of this technique is its deployment limitations becuase the WDJ applications have to reside on the same AS Java engine as the portal. For details about how WDJ applications can interace with a local portal runtime, refer to Integrate Web Dynpro into your SAP NetWeaver Portal to create dynamic, flexible applications. This technique is used to integrate locally-deployed WDJ applications into the portal, which takes advantage of WDJ interaction with local portal runtime, thereby offering advanced integration features such as Split View, etc. Many business suite applications such as ESS/MSS heavily use this type of integration technique. In the past, we had two major WDJ-portal integration techniques:
#SAP NETWEAVER WEB DYNPRO JAVA DEPLOY SERIES#
This blog is the first part of my blog series on this topic.Ī recap of WebDynpro Java (WDJ) integration techniques in portal Before diving into the details about the iView, I would recommend you have a read of Aviad Rivlin’s blog of Best Practice for Integrating SAP Applications into the SAP NetWeaver Portal to get a big picture of all major use cases of application integration in NetWeaver Portal. In this blog, I would like to introduce to you the new Application Integrator-based WebDynpro Java iView which integrates remote WebDynpro Java portal pages into a central portal.