Skip to Content
One of the real cornerstones of Web Dynpro is the compensation of an application. Splitting a whole application into several components gives you the chance to get reusable components, which could be implemented very easily in different teams or locations for example, and which could interact with a lot of advanced features (like context-mapping or server-side eventing for example).
Furthermore you can use component interfaces to abstract any component embedder from the concrete implementation of the embedded component. Doing this it is for example very easily possible to add a new, customer-specific component implementation at runtime to a running Web Dynpro application.

All in all you should think “in components” when implementing Web Dynpro applications.

Nevertheless you will probably create different Web Dynpro applications in the end and doing that it is sometimes necessary to provide some possibilities to navigate from one Web Dynpro application to another.

In general there are three different possibilities doing this depending on the environment, in which the Web Dynpro application is executed.

1) Run it as one single application

The easiest way to navigate between Web Dynpro applications is to put the two applications into one application by merging the related Web Dynpro components together under one common root component. In this scenario the navigation is a simple Web Dynpro navigation between the different interface views of the related components handled by the root component.

This scenario is of course not always possible, but it is worth to think about it. A lot of problems related to the navigation between different applications are not existing in this scenario because you can only one application. It is for example very easy and straightforward to define any kind of “state”, which should be forwarded from one application to another by defining the needed context for example in the component controller of the root component.

2) Running standalone applications

This scenario is well-described in the inter-application navigation article available here at SDN.
Therefore only some short remarks:

  • You have to define an exit plug for the interface view of the root component of your application.
  • You have to add a string parameter called url to the exit plug.
  • To compute the needed Web Dynpro application URL you have to use one of the WDURLGenerator.getApplicationURL(…) methods.
  • You have to trigger a navigation to the exit plug passing the computed Web Dynpro application URL.

3) Running the applications inside the SAP Enterprise Portal 6.0

When running inside the portal the only suggested way to navigation between different Web Dynpro applications is the (absolute or relative) portal page navigation or the object-based navigation. Only the usage of these technologies make sure, that the navigation is visible for the portal and all needed information is passed to the navigation target.

The approach offers the following advantages:

  • The navigation step is visible in the portal page history if needed.
  • To navigate back you can use the generic portal page back navigation functionality.
  • Both the starting application and the target application is executed in the exactly same environment (i.e. as an iView). If you would navigate to another Web Dynpro application using the mechanism described in chapter 2 (i.e. using the pure Web Dynpro application URL), you break this and the target application runs in an “mixed” and totally undefined environment. One consequence could be that the used portal theme is not longer valid.

Therefore we strongly recommend to use ONLY page navigation or object-based navigation when running inside the portal.

To trigger a portal navigation within a Web Dynpro application you should use the WDPortalNavigation service. To trigger an absolute page navigation you should use one of the navigateAbsolute methods. The relative page navigation is triggered by one of the navigateRelative methods. The object-based navigation is triggered using one of the navigateToObject .

There are several articles available here in SDN describing the portal navigation in detail.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Valery Silaev
    Jochen,

    I check API docs and see that navigate[Absolute|Relative] has boolean flag whether or not POST HTTP method should be used. However, navigateToObject has no such settings. Does it assumed that navigateToObject always uses POST?

    My concern about POST vs GET is a limit for allowed “businessParameters” argument length.
    Could you provide comments on this?

    The next thing is parameters sharing via HTTP Session-like mechanism. I know, WD has several non-public classes to perform this trick, but I’m interesting in “standard & approved” solution for this.

    Thanks in advance,
    VS

    (0) 
    1. Jochen Guertler Post author
      Hi Valery,
      this are good questions 😉

      Yes you are right – at the moment you could only choose for the page navigation whether you want POST or GET.
      If you choose GET we check the lenght of the business parameters string. If this is too long (> 1024 bytes) we automatically use a POST (only in the page navigation).

      The object-based navigation uses always a POST.

      YES, you are right – this is not a real consistent API. We will improve this in a further version.

      Regarding your question about the parametert sharing. I am not sure what do you mean by that? Could you explain this a little bit more in detail.

      Thanks in advance

      Jochen

      (0) 
      1. Valery Silaev
        I see nothing wrong with API — just rename parameter name to forceUsePost and document behavior. All the rest already fairly consistent.

        Regarding sessions. WD applications has no access to HttpSession object. And it is sometimes quite usefull way to share relatively complex data structures between applications. WD internally has notion of “scopes”, and one type of scope resembles almost identically to HttpSession. However all this stuff is not in public API 🙁

        So the only “standard” way I see is to serialize data structure in one WD application to BASE64 String and pass it as POST parameter to another application.

        VS

        (0) 
  2. The one thing I noticed with putting all components under one DC was that it increased the size of DC, large DCs were tending having large build times
    (0) 
    1. Jochen Guertler Post author
      Hi,

      I think this a missunderstanding. Putting different components together to one application instead of running them in different applications does not mean, that all of these components must be placed in on DC. You can of course separate them into different DCs.

      Best regards

      Jochen

      (0) 
  3. Hi Jochen,
    I am using mechanism as described in chapter2 for standalone application to navigate from one application to another application as well as in Portal6.0.It works fine.

    Whereas when I used in portal7.0, it gives an error “Exit-plug cannot triggered with an URL when running in portal. Use portal navigation instead to navigate in portal.” – So I used navigateAbsolute method (as described in chapter 3).It works fine now, Whereas when I want to run as standalone application , I need to change the code once again as described in chapter2): Is there any other way to navigate from WD application to another WD application both as standalone WD application as well as in portal without changing the code.
    Thanks in advance,
    Best regards,
    Lakshmanan.

    (0) 
    1. Jochen Guertler Post author
      Hi,

      there is not only one way to navigate here. If you want to run your WD app in both scenarios (i.e. standalone and inside the portal) you have to use the WDPortalUtils.isRunningInPortal() method to check which scenario is active. Based on the return value you have to use the portal navigation or the exit-plug.

      Best regards

      Jochen

      (0) 
      1. Nizamudeen SM
        Hi Jochen,

        I have a requirement like, my webdynpro application should log-off the portal. That is i have a button in my wd application which is embedded in portal, i just want to logoff the portal on click of that button. is this possible?

        I tried,
        forcedLogoffClientUser(), AbsoluteNavigation and RelativeNavigation. But still i am not able to find the solution.

        Can you suggest me out on this.

        Regards
        Nizamudeen SM

        (0) 

Leave a Reply