Skip to Content
Author's profile photo Siarhei Pisarenka

HTTP Cookies in Portal WebDynpro application, [part1]: Overview

In the article I’ll try to give an overview of the methods how you can enable operations with HTTP Cookies in WebDynpro applications running within the Portal.

Short digression: Cookie and WebDynpro

Questions about HTTP Cookies appear periodically when new developers begin to study WebDynpro Java and design more or less complex web-applications. If you run SDN search with the phrase like “cookies in WebDynpro” you very likely get hundreds of forum threads, blogs and articles related to the topic. In most cases tasks appearing before a developer when he/she remembers about cookies include reading some NetWeaver application server’s system properties transferred within cookies (a) or use cookies for a personalization based on users’ preferences (b).

The main conceptual problem which causes lots of questions around is the following. Most of developers threat WebDynpro as one more framework for building RIA, but in fact the framework just follows MVC pattern and doesn’t expect to be running especially in a browser environment. For example, standalone or mobile clients do not deal with HTTP, JS or Cookies. That’s why from the initial version WebDynpro have not ever officially supported Cookies and haven’t provided API for that. And that’s why questions like “how to read/write cookies?” appear again and again in WebDynpro forums.

“I know all this, but how to read/write cookies?..”

Approach 1 (not recommended): Using holes in WebDynpro API

In web-applications WebDynpro framework behaves like a wrapper oevr the standard Java Servlet request/response cycle. This makes still possible to retrieve the original servlet session objects – HTTPServletRequest & HTTPServletResponse instances, and use them for reading/writing cookies as you do in usual JSP applications. This could be achieved via such undesirable means as down-class-casting and not public API usage.

For example, the following forum thread shows the example of such code: Java webdypro : how to create /read  cookie with NW 7.0 ?

Potential risks: In a next WebDynpro release your application could become not compilable or even worse, – compilable, but not working properly at runtime.

Restrictions: The solution can work in case of standalone WebDynpro web-application, but quite predictably does not work if the application running as iView in the Portal. The Portal page builder invokes WebDynpro application indirectly and the original servlet’s session simply do not reach it.

The next two methods explained below are only applicable if an application is running within the Portal. But in this case we can realize completely legal solution and avoid the mentioned risks.

WebDynpro application running within the Portal

Article Integrating Web Dynpro Java and SAP NetWeaver Portal: How to use extended features of the SAP Application Integrator explains very well how a WebDynpro application is integrated in the Portal iView. In two words, there is SAP Application Integrator which is responsible (excepting all other functions) for launching a WebDynpro application running as a WebDynpro iView. Initially the integrator is requested by a client browser and then performs a HTTP redirect to the target WebDynpro application. It computes the target WebDynpro application URL based on the settings of the launched iView. The next things that happen depend on iView type…

  • For NW04 WebDynpro iView (based on WebDynpro iView template) the computed URL points directly to the target WebDynpro application. The URL is finally invoked via HTTP Redirect, so it’s still possible to extract HTTP Cookie from a servlet session as described in Approach 1.

  • For NW04s WebDynpro iView (based on WebDynpro page builder) the computed URL points to a proxy application – WebDynpro page builder, which in turn is responsible for invoking the target application. In the case a servlet session is almost empty; extracting HTTP Cookies is not possible. That’s why Approach 1 does not work here.

Approach 2 (cookie reading): Using SAP Application Integrator + Custom Parameter Provider

The idea is proposed in forum thread Web Dynpro cookie read: Servlet workaround, but session problems… and also based on the mentioned above article. Here I’m just explain it in details.

When SAP Application Integrator computes the target WebDynpro application URL it’s possible to extend the URL with custom parameters. This allows us to put HTTP Cookies coming from the client’s request to the URL as parameters. Then the URL parameters will reach the target WebDynpro application. With the approach we can only read cookies, but we cannot send them back to the client.

Below is a short step-by-step guide how to proceed with the method. Read section “Using customer-specific parameter providers” in the article for further details.

  1. Enable support for customer-specific parameter providers in EP System Administration.
  2. Create a new Portal DC or reuse an existing one if there are any in your application development.
  3. Create a new Portal service which is nothing but customer-specific parameter provider. Configure it as required.
  4. Extend the service implementation (see the code below).
  5. To get it compiled at build-time you need to add a reference to classes of EP service By analogy the similar reference shall be added to portalapp.xml for runtime:
  6. Connect the implemented service to the iView: setup iView’s properties Custom Exits for ‘ParameteProvider’ and Application Parameters.

Here I’m providing the code of such a portal service which is responsible for Cookie reading. It takes the cookie from servlet’s request and returns it as URL parameter.

public class UserPrefsSrv implements ICustomerParameterProvider {   

   private static final String PARAM_NAME = "Cookie.UserPref";

   public String getParameter(IPortalComponentRequest request, String paramName) throws Throwable {

      if (PARAM_NAME.equals(paramName)) {

         String cookie = readCookie(request, getUserCookieKey(request, "com.epam.xapp.UserPref"));

         return (cookie != null) ? (PARAM_NAME + "=" + cookie) : null;


      return null;


   private String readCookie(IPortalComponentRequest request, String key) {

      String value = null;

      Cookie[] cookies = request.getServletRequest().getCookies();

      for (int i = 0; i<cookies.length; i++) {

         if (key.equals(cookies[i].getName())) {

            value = cookies[i].getValue();




      return value;


   public String getParameterDefault(IPortalComponentRequest request, String paramName) throws Throwable {

       return null;


   public Enumeration getAllParameterNames() {

      return new StringTokenizer(PARAM_NAME);


   private String getUserCookieKey(IPortalComponentRequest request, String baseKey) {

      return baseKey + "_" + request.getUser().getLogonUid();



Approach 3 (universal): Using additional hidden iView with client JavaScript

The idea of the method is based on a small JavaScript code which is responsible for reading/writing Cookies… [Enhance your Portal WebDynpro application with HTTP Cookies, [part2]: JavaScript based solution]

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Well this is a nice blog but part 2 doesn't seems to be there in the link. Can you please update it?
      Author's profile photo Siarhei Pisarenka
      Siarhei Pisarenka
      Blog Post Author
      Hi Gourav

      Please, try the link now. The second part have been just released.

      BR, Siarhei

      Author's profile photo Former Member
      Former Member
      IResponse responseObj = ((IProtocolAdapter) WDProtocolAdapter.getProtocolAdapter()).getResponseObjectInternal();
                     HttpServletResponse response = (HttpServletResponse)responseObj.getProtocolResponse();     

      here could you please tell me why the response object is coming null

      Author's profile photo Siarhei Pisarenka
      Siarhei Pisarenka
      Blog Post Author
      If your application works under Portal such situation very likely might happen. Behavior of WebDynpro framework when the application works separately is different from the case when it works under Portal.
      See my explanation here: