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.
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.
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.
Article Integrating Web Dynpro Java and SAP NetWeaver Portal: How to use extended features of the SAP Applic... 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.
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.
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();
break;
}
}
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();
}
}
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]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
37 | |
10 | |
6 | |
4 | |
3 | |
3 | |
3 | |
2 | |
2 | |
2 |