Skip to Content

Recently I was assigned a problem that involved accessing a web dynpro application via portal. This initially sounded easy, however, the difficulty lied in the fact that the web dynpro application and the portal were deployed on different servers and we had to use the user’s portal login id in the web dynpro application. Since the users were already created for the portal, the client did not intend creating the users all over again for the web dynpro application.

This sure was a Herculean task!

I tried a number of alternatives one of which involved user mapping. However, in our scenario the user was not to be created on the web dynpro machine and hence mapping the portal user id to any other id did not provide a solution to us.

Another solution was to use UME APIs in web dynpro and have the application deployed on to the portal server. These APIs in turn would retrieve the portal login id. However, this too did not work well for us since we were not allowed to deploy any web dynpro development on to the portal server.

So the only way would be to provide a link on the portal which when clicked would lead us to the web dynpro application and in turn pass the portal user id as a dynamic parameter appended to the url string.

Here is how I managed to achieve it.

The web dynpro application already exists on the respective server. We can create a JspDynpage component on the portal server (since this would involve deploying a pure portal component on the portal server and not any web dynpro component).

Now, in the Jspdynpage application we must provide an IsolatedHtmlContainer using htmlb and assign the url of web dynpro to it. This will directly open the application in an html container (in turn in the iview).

Here is the code,



This will create a container for the web dynpro application and the parameter name is a dynamic parameter whose value is the login id of the portal’s logged in user.

Its great that these two fragments of code when added to the .jsp file make it possible to access the application with the portal user captured and passed dynamically.

Now the task is to capture this login id in the web dynpro application.

This we do using the startup plug.

All the views in a web dynpro application are contained within a window. Any parameter that must be passed to the view from an external application must be through this startup plug.

Step 1:

In the Interface View of the web dynpro application, we declare a parameter for the startup plug called name with type as String.

In the onPlugDefault method of this plug we capture the name and pass it over to the initializeContext method of the component controller.

Here is the code,

String uname = name;

Step 2:

Now in the component controller we have a method called initializeContext with a string parameter name. This in turn can be used to set the context value of uname.


Step 3:

Now we can get the value of uname in the view and in turn use it for further validation purpose.

In this way we can use the portal login information in web dynpro.

To report this post you need to login first.


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

  1. Michael Nicholls
    I’m surprised that there wasn’t a common user source, such as an LDAP or ABAP system, that could have acted as the UME source for both of the Java instances.

    Most sites who use the SAP portal don’t want to maintain users in the portal, so they point the UME to an existing LDAP, such as Microsoft AD, or an SAP ABAP instance that already has all the users…

  2. Hi,
    I am facing the same problem in diferent ladnscape but I do not think that this is a correct solution. Lets imagine that I copy the link into new browser and change the name in url string. With this way I can login to WD App as another person absolutly without problems. Is that right?


    1. Preksha Malhotra Post author
      I realised the problem infact and had been working on it myself. You can try the Isolated HtmlContainer approach instead on the link. This should work fine.
      Do let me know.
  3. During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.

Leave a Reply