Sunday, April 20, 2014

Building a Responsive WebCenter Portal Application - Technical Paper Published


In this article I reviewed the essentials of responsive web design, walked through how to design and develop a responsive WebCenter Portal application, and reviewed the essential development considerations. The article covers technical aspects of building a responsive WebCenter Portal as well as the business decision points behind each scenario. It is intended for software architects, developers, and business users who regularly work with Oracle WebCenter Portal.

Monday, April 7, 2014

Build Your Responsive & Mobilized Enterprise Portal



Let’s collaborate at Collaborate14!
Location: Las Vegas, NV – Venetian & Sands Expo Center
Dates: April 7th – April 11th
Build Your Responsive & Mobilized Enterprise Portal, by JayJay Zheng

Date: 04/10/2014
Time: 11:00 AM – 12:00 PM
Location: Level 3, San Polo 3502
Abstract: Mobilizing emerges as a "must-have" feature for modern web experience. Oracle WebCenter Portal 11.1.1.8 introduces multi-channel portal experience to support mobilized web for smart devices. This session reveals the essential secret sauce of the new mobilizing support – responsive web design, and teaches how to extend the responsive template to support your custom needs. The session helps to determine your mobile enterprise portal strategy and teaches how to build the responsive from scratch to create your own mobilized enterprise portal on WebCenter Portal Framework applications. Further, the session analyzes real world customer cases to help you avoid the pitfalls and exploit first hand best practices.

Objective 1: Discover fundamentals utilized in the Oracle WebCenter 11.1.1.8 mobile support.

Objective 2: Describe and explain how to build a responsive template from scratch.

Objective 3: Discuss mobile enterprise portal strategy for various organizations' needs and analyzes the real world customer cases for mobile support.

Monday, February 24, 2014

Bypass the IE Compatibility Mode (IE8/9) in ADF/WebCenter App

Some times the IE compatibility mode is enforced to be used by your system admin at an enterprise level, especially for the intranet sites. Since Jdeveloper 11.1.1.6, a popup warning is shown to the user when ADF/WebCenter application is running on compat mode. The issues seen in compat mode is not supported by Oracle.

The solution to bypass the compat mode has been documented via Oracle Doc 1555476.1. I'd like to extract the key information of the such solution here:

A new feature has been introduced in JDeveloper/ADF 11.1.1.7.0 and 11.1.2.4.0 and backported to 11.1.1.6.0, 11.1.2.0.0, 11.1.2.2.0 and 11.1.2.3.0 through patch 14400317.
It consists of bypassing Compatibility Mode in IE browsers. The ADF framework will force the target document to the maximum document mode supported by the browser using the X-UA-Compatible META tag. This applies to desktop browsers in compatibility view mode and also applications that use the IE WebBrowser component to host content within desktop applications. For more information see 11.1.2.4.0 ADF Faces Release Notes at http://jdevadf.oracle.com/adf-richclient-demo/docs/release-notes.html

To set this feature, apply the following:

1. For 11.1.1.6.0, 11.1.2.0.0, 1. 11.1.2.2.0 and 11.1.2.3.0, download and apply patch 14400317 in your JDeveloper/ADF environment.

2. For all the above mentioned versions, add, in the web.xml file of your ViewController project, the following context-param to enabled agent version detection using the Trident version over the browser version:

<context-param>
<param-name>org.apache.myfaces.trinidad.Agent#OVERRIDE_IE_COMPATIBILITY_MODE</param-name>
<param-value>true</param-value>

</context-param>

3. Finally, apply the patch to all environments where the application will also be deployed.

Sunday, February 23, 2014

Inline Style Isn't Just for CSS Styles

Inline styles are CSS styles applied to an user interface element. Multiple properties can be applied to an element and they are separated by semi-colon. Inline styles take highest precedence. Styling rules defined by inlineStyle in ADF are added directly to the JSF page source as part of the component markup. Any styles defined in CSS style class will be overridden by the inline styles on the element. This is an advantage as well as disadvantage. Element styles can be overridden unintentionally. For re-usability and maintenance, extensive use of inline styles should be avoided.

In this post I will discuss another use of inline style which is an uncommon use case in WebCenter Portal. It isn't just for CSS styles as I found in my recent practice. The inline style can set the selected state of a navigation node in WebCenter portal application. This is a very unique use case. It has to satisfy the following scenario:

1. Go link is used to implement the navigation model links. There are a few reasons golink is favored vs. command link in WebCenter Portal application. A team has a blogpost discussing this.

2. Redirect option is set to true for the navigation links.WebCenter by default uses PPR for navigation. The URL in the browser isn't to reflect the current page. Your heaven can be someone else's hell. I have seen this is specifically required by business users. To enable the browser to display the URL of the current page, you will need to set the redirect option to true. There are two ways to do this.
a): set the context parameter oracle.webcenter.navigationframework.REDIRECT_OPTIONS in the web.xml to toPrettyURL.

The following snippet should be added to web.xml
<context-param>
 <param-name>oracle.webcenter.navigationframework.REDIRECT_OPTIONS</param-name>
 <param-value>toPrettyURL</param-value>
</context-param>

b). You can also set the individual navigation link redirect option. This is configured in the navigation model xml file. Each navigation link defined in the navigation model has two options "Redirect to URL" and "Render URL in page template". Selecting "Redirect to URL" will also enforce the URL to be displayed in the actual URL of current page. Selecting "Redirect to URL" will add the following in the navigation model xml file:

<attribute value="true" isKey="false" attributeId="Redirect"/>

Setting the oracle.webcenter.navigationframework.REDIRECT_OPTIONS context parameter affects performance by adding an extra request/response for every navigation.

In my example, I used an ADF breadcrumb task flow (either the OOTB one or custom one) to map a navigation model in a WebCenter portal framework application.

We have a home page and it's the default home page for the portal application. After application starts, the breadcrumb works fine and will reflect the landed page correctly if we navigate from one link to another in the navigation. But it breaks when you copy one of the page URL and directly access it from your browser. This time, the breadcrumb will only display the last accessed landed page (not the current one). If the page isn't accessed yet, it will default to the home page node in the breadcrumb. Therefore the deep linked page failed in this case.

To illustrate the issue, I am attaching some images.

Step 1: run the application and the home page renders with "home" breadcrumb.


Step 2:Navigate to a child link



Step 3: The breadcrumb is reflected correctly. Note down the URL of this child link.



Step 4:  Navigate back to home page.



Step 5: Paste the child link (from step3) to a second tab and hit enter.


You will find the breadcrumb is still showing the home tab, which is incorrect. In this case, the breadcrumb is not "notified" of the current selected navigation node (page 3, in this case) and still think "home" node (last visited) is the current state of the breadcrumb.

The solution to the above issue is to define the following in the inline style of the each go link navigation implementation to enforce the selected state to be updated.

inlineStyle="#{node.selected ? '' : ''}"

In the above, both the expression for the inline style is empty no matter the node is selected or not, this is because I do not need to define any css styling for this element.

You can download the example application here.

Sunday, November 3, 2013

Reentrantlock Caused Content Presenter Performance Issues for > 1000 Concurrent Users

Thanks Martin Deh from A-Team for identifying it is a recently reported bug.

To summarize the problem: during a load testing (>1000 users attempt) on a WebCenter framework application developed with content presenter task flows, the performance (page response time) was greatly impacted by a series of parked threads. The issue was not produced in the 1000 users test. The parked threads took from >30 seconds to minutes to resume. By investigating the stack trace, the culprit is pointed to java.util.concurrent.locks.ReentrantLock.lock() which is called by UCMBridge.getAccessLevel(IdcContext, DataObject, ITrace).

This issue has been filed as a bug (Bug 17330713) and the patch/fix is to be provided soon (Update: the patch is available as of date 11/4/2013 for 11.1.1.7.1)

The following shows a graphic indication of the parked threads (gray) through the tests. As you can see, the gray areas took the majority of the timeline.

Here is the stack track of one particular parked thread:


Look further down the stack trace, you will find the issue was from a call on ContentPresenterBackingBean. So it's obvious enough to tell it's caused by content presenter task flow. There is so far no evidence that other document task flow would cause the same issue.


Sunday, October 27, 2013

WebCenter Portal HA and Performance Tuning Checklist

Performance is a broad topic which is never out of date. I'd like to itemize a checklist with specific topics, links and references. Some topic may be more generic and some may be more specific. But this list mainly focuses on WebCenter Portal applications and its relevant products.

This is not intended to be a complete list and there will never be.

WebCenter Performance Tuning Guide

HA for WebCenter Portal and ADF application

Configure JOC for WebCenter Portal services

Configure Coherence Caching for Content Presenting

WebCenter Performance Study (Including Enable Client Caching and Compression)

Tuning JVM

Weblogic Capacity Planning

Middleware Performance Tuning Roadmap

Oracle HTTP Server Performance Tuning

MDS Performance Tuning

Using Cluster and HA Features


Some Useful A-Team Blog Posts:

High availability considerations for WebCenter Portal and ADF 
Improving ADF Page Rendering Time : Progressively Loading Taskflows
Configure Coherence for Oracle WebCenter Portal Framework Content Presenter Task Flow 

Non-programmatic Authentication Using Login Form in JSF (For WebCenter & ADF)

My previous post described a scenario that the OAM DCC programmatic authentication is not supported yet, and here I am presenting a nice alternative to do the DCC authentication non-programmatically.

You may have a read on Frank's book "Oracle Fusion Developer Guide" and there is a section in the ADF security talking about "Creating a login form in JSF" programmatically. This approach works for JEE contained security but would not work well with your WebCenter Portal or ADF app integrated with OAM authentication. I am introducing an approach that does not require any programmatic authentication and can be used safely with any type of authentications (contained security or OAM authentication).

Note: You can create HTML form in JSF but there are many limitations, such as only one form component can be allowed in a page. Due to this, it's impossible to support a complicated login page in JSF. It induced extra pitfalls and challenges on the skinning as well.

If you create a WebCenter Portal application in Jdeveloper, you will have a loginProxy.jspx page already created in your application. This loginProxy.jspx is our solution here. This pre-built page is coded in HTML form and I experienced in some cases it is not well supported for WebCenter portal applications, although it does seem ok with a pure ADF application (this page is not shipped with an ADF fusion application, so you have to create it for ADF app). I would recommend to re-code this page using ADF Faces component.

The process flow is simple:

1. Create an actual login page in JSF (.jspx) page. In this JSF page, it contains the input text for user name, password and a button for submit/login. All these components are coded with ADF faces components. In the value fields, specify a parameter in request scope so they can be passed onto the loginProxy page.



2. Re-code the loginProxy.jspx page using <f:verbatim> which will wrap the form post with the username/password parameters passed from login page. Depending on the authentication type, you may have different form post actions. This page uses the JavaScript to auto submit the form.

For JEE contained security:
 <?xml version='1.0' encoding='UTF-8'?>
 <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" xmlns:f="http://java.sun.com/jsf/core"
      xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
  <jsp:directive.page contentType="text/html;charset=UTF-8"/>
  <f:view>
   <af:document title="login" id="d1">
    <af:clientListener method="formSubmit" type="load"/>
    <af:resource type="javascript">
     function formSubmit(evt) {
       var form = document.getElementById("loginData");
       form.submit();
     }
    </af:resource>
    <f:verbatim>
     <form id="loginData" name="loginData" method="POST" action="j_security_check">
      <input id="userid" type="hidden" name="j_username" value="${requestScope.userid}"/>
      <input id="password" type="hidden" name="j_password" value="${requestScope.password}"/>
     </form>
    </f:verbatim>
   </af:document>
  </f:view>
 </jsp:root>

For OAM authentication:
 <?xml version='1.0' encoding='UTF-8'?>  
 <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" xmlns:f="http://java.sun.com/jsf/core"  
      xmlns:af="http://xmlns.oracle.com/adf/faces/rich">  
  <jsp:directive.page contentType="text/html;charset=UTF-8"/>  
  <f:view>  
   <af:document title="login" id="d1">  
    <af:clientListener method="formSubmit" type="load"/>  
    <af:resource type="javascript">  
     function formSubmit(evt) {  
       var form = document.getElementById("loginData");  
       form.submit();  
     }  
    </af:resource>  
    <f:verbatim>  
     <form id="loginData" name="loginData" method="POST" action="/oam/server/auth_cred_submit">  
      <input id="userid" type="hidden" name="userid" value="${requestScope.userid}"/>  
      <input id="password" type="hidden" name="password" value="${requestScope.password}"/>  
     </form>  
    </f:verbatim>  
   </af:document>  
  </f:view>  
 </jsp:root>  

3. Last step is to create a navigation rule from login page to loginProxy page. The navigation rule is specified in the "login" button on the login page.


This approach avoids the programmatic authentication and works great for having a custom login page developed in WebCenter Portal integrated with OAM authentication. It works for both ECC and DCC authentication. As of now, the programmatic authentication on OAM DCC is not supported, so this approach fits right in the gap.

Tuesday, October 15, 2013

Difference on Getting Error Code from OAM ECC and DCC

In case of OAM authentication failures, the OAM server will send the error codes back to the client. It's up to the client to decide what actual error message needs to be displayed on different types of authentication failures. For the list of the standard error codes, you can refer to here. To getting the error code on the client side, they are different based on whether it's ECC or DCC authentication. I have not found this difference documented in anywhere yet. So I am putting it in this blog post.

DCC (Detached Credential Collector) is introduced in OAM 11gR2. ECC is embedded credential collector. My previous post has described its concept and advantages, so I will not repeat it here.

For ECC, the link above also shows a code snippet to get the error code parameter "p_error_code". The error code is returned back as one of the request parameters on the browser URL. So it can be accessed by calling request.getParameter("p_error_code").

 <%@page import="mytest.error.ExampleErrorMsg"%>  
  //initializing the messageBundle first  
  String defaultResourceBundle = "mytest.error.ExampleErrorMsg";  
  java.util.Locale myLocale = request.getLocale();  
  ResourceBundle msgBundle=  
  ResourceBundle.getBundle(defaultResourceBundle,myLocale);  
 String errCode = request.getParameter("p_error_code");  
 String secondaryErrMessage = request.getParameter("p_sec_error_msg");  
  <%  
     if(errCode != null && errCode.length() > 0) {  
      try {  
        simpleMessage = msgBundle.getString(errCode);  
      } catch(Exception e) {  
        //get the default authn failed message  
        simpleMessage = msgBundle.getString("OAM-8");  
      }  
  %>  
  <div class="message-row">   
    <p class="loginFailed"> <%=simpleMessage%> </p>   
  </div>  


For DCC, it's not returned on the request parameter but on the request header. Actually there is no request parameter returned at all for DCC, as the returned url is "http://host:port/oam/server/auth_cred_submit" with no actual parameters, in case of authentication failure. To get the error code from the request header, simply by:

 String errCode = request.getHeader("p_error_code");  

Sunday, October 13, 2013

Does OAM DCC Support Programmatic Authentication? - Maybe not yet!

Credential Collection is the process of collecting the end user's credentials through a login page. When OAM Webgate intercepts a requests and detects the user is not authenticated yet, it would redirect the user to the login page. In OAM, when the login page is hosted on the OAM server, it's called Embedded Credential Collector (ECC).

Another form - Detached Credential Collector (DCC) - is introduced in OAM 11gR2. As the name explains, DCC can be decoupled from the OAM server, which provides the flexibility of deploying the login page in either trusted internal network or DMZ. It uses a specific WebGate to collect he user credential and communicate to the OAM using secure Oracle Access Protocol (OAP). It offers a solution that isolates the OAM serve from any unauthenticated network connection, such as public access.

It is my interest to discuss on whether DCC supports programmatic authentication. Usually the login page for OAM authentication would be form based JSP page with the following snippet:

  <form id="loginData" name="loginData" method="POST" action="/oam/server/auth_cred_submit">  
      <table cellspacing="2" cellpadding="3" border="1">  
       <tr>  
        <th>Username:</th>  
        <td>  
         <input id="userid" type="text" name="userid" autocomplete="off"/>  
        </td>  
       </tr>  
       <tr>  
        <th>Password:</th>  
        <td>  
         <input id="password" type="password" name="password" autocomplete="off"/>  
        </td>  
       </tr>  
      </table>  
      <p>  
       <input type="submit" name="submit" value="Login"/>  
      </p>  
      <!--<input type="hidden" name="request_id" value="${param.request_id}" id="reqid1"/>-->  
      <!--<input type="hidden" name="OAM_REQ" value="${param.OAM_REQ}" id="oamreq1"/>-->  
     </form>   
Note the important thing in the snippet is the HTML form component with "POST" method and "/oam/server/auth_cred_submit" action. The user id input id and password input id have to match the settings on OAM server. You might notice the "request_id" and "OAM_REQ" parameter is commented out and they are not required by the DCC (but they are required by ECC authentication though).

Oracle documentation did talk about the programmatic authentication here - "Programmatic authentication using HTTP client APIs is supported for both OSSO 10g and 11g OAM Server". This is true for ECC authentication, but not for DCC. I will explain why.

In case of DCC, the user sends a request to access an OAM protected resource. The webgate will detect that and redirect to the login page with a DCCCtxCookie. The cookie looks like this:

Cookie: DCCCtxCookie_host:port=encdata%3DK1%2Fz6ZK1yVCemO56M9Zs9DfIY%2Fui4r%2BQaoWbA8rxRf%2FgJ68egTxUyOC4G%2F2Ufj8gQwEgL36wlEEevfNm5ETfaw4PwDVMVj3MRkHfvZSmBCPsFC6T4z9tS98ehpAxZjhx8cJN2ELvMycCrgqQFNEd23WbRzRq4YCLt9edz%2Ba1gekDhjIMKLYMZrNrlmv1krsIV4PYnQWydY5pmfpYfh%2BYPyumYWMt%2Bm6syK9nmruSM%2BOSKu39PxBV6TL1S3wWpWgXLFmpS6Jq5Xt6cBGWaMbCaVnfcQQdN%2BSIfFLz0kA8u8Fxq9Z4dB9MGQoWzE165KDHRKsVPgMN81M%2F84ju3Cximw%3D%3D;

This cookie is sitting on the path "/oam/server/auth_cred_submit" but not on the domain "/" like JSESSIONID. This makes the cookies not accessible from Http Client API. Without this DCCCtxCookie, submitting the login page with action "/oam/server/auth_cred_submit" would result in 404 - page not found.

Different from ECC, the cookies generated for ECC authentication are sitting on the domain path so it can be accessed from the Http Client API.

Due to this cookie path challenge, I am making a conclusion that the DCC is not supporting programmatic authentication yet. I hope others can correct me and show me an alternative or workaround for this matter.

Assuming DCCCtxCookie is present, OAM will authenticate the credentials on submitting the login form. If the credential passed the authentication, a cookie "OAMAuthnCookie" will be set and available on the response header.

Set-Cookie: OAMAuthnCookie_host:port=qLhahoJixOlOMO%2F9mCzrd80IPFoaswuOA%2F59re%2Bo%2FREiXuKMFfzicypCssemSZLLBwaGIZawYc6TnymVPUppQQKolyt015hJuas5xYIbK3rCT4SgI%2BMYdlsPpeyy1IFvpFEHWVbLJ%2Fkd94SYoiBwUWlNo7dEa7jVltmz8k8h2sJ4id%2FriGn2JCtxgUfPNGsF8FrIvO3xIkXCqo7c4LMPlZJrgxz5vW1Dt9FARC1eQ%2BzhNK4p9XYpogcuKEfGSwSEyzrQdiVPU82zx108uVKhNvlUvBPwwqhY38Dkpnecaouv6Gzo5XqEnac%2Bz8GB84UmVen6UXca8knu9lNzC2iRLi0356JSR27%2Fft4ESr%2Fpnlk%3D; 

Monday, October 7, 2013

FileNotFoundException after Recent Deployment on WebLogic Server

You might experience the FileNotFoundException (OracleJSP error:java.io.FileNotFoundException) error on rending your JEE app after a recent deployment on WebLogic server. You could also see errors in the log stating "unable to dispatch JSP page".

First thing to try is, clear your browser's cache and request the page again. If this is not helping, then the issue is from the server side.

When web application is activated and deployed, the new web application is exploded to a tmp directory under $DOMAIN_HOME, eg. $DOMAIN_HOME/servers/AdminServer/tmp/_WL_user...

These directories are used in subsequent server starts so the applications do not have to be deployed again. In this case, some of the files and directories are missing in the tmp directory, resulting in errors observed. It is unknown what caused the files/directories to be missing in this case.

To get rid of the error, simply need to either restart the manager server or force the re-deployment like below:

1. Shutdown AdminServer
2. Remove or rename $DOMAIN_HOME/servers/Adminserver/tmp directory.
3. Start Adminserver, this will cause all the applications to be deployed again.

There are others talks about the related weblogic behaviors:
http://stackoverflow.com/questions/12301976/temporary-directories-in-weblogic-10
http://stackoverflow.com/questions/6815330/weblogic-not-clearing-cache

Thursday, September 19, 2013

Mobilizing Your Portal Strategy @ OpenWorld 2013


Mobile portals must deliver much of the same capability available to desktop users and also provide unique capabilities pertinent to users on the move, all in a form that leverages mobile device capabilities and context signals. Although mobility raises new challenges for portal initiatives, it also brings a world of new opportunities to improve user engagement and business value. Attend this session to learn how Oracle WebCenter Portal is delivering mobile content creation, infrastructure, and collaboration to keep you connected on the go.
Additional Information

Oracle OpenWorld

MIDDLEWARE: Portal, Content Management, Web Experience Management, and Social Network

LOB Manager/Director, IT Manager

Conference Session


Venue / Room: Moscone West - 2016
Date and Time: 9/25/13, 13:15 - 14:15