Retrieving external URL parameters in WebSphere portal environment (using com.ibm.wps.pb.utils.portlet. PortletUtils)

PortletUtils is a utility class which is provided by websphere portal server. With help of JSR286, it provides some method which really useful. 

PortletUtils.getHttpServletRequest(javax.portlet.PortletRequest portletrequest)

http://localhost:10039/wps/myportal/MYPAGE?test=sample

HttpServletRequest req=PortletUtils.getHttpServletRequest(request);

System.out.println("req.getParameter('test'):"+req.getParameter("test"));  // sample is printed

PortletUtils.getPortletDefinitionId(PortletConfig portletconfig)

String portletUniqueName = "";

ObjectID objID = PortletUtils.getPortletDefinitionId(getPortletConfig());

if(null != objID) {

portletUniqueName = objID.getUniqueName();

}

PortletUtils.getPortletDefinitionId(javax.portlet.PortletRequest portletrequest)

String portletUniqueName = "";

ObjectID objID = PortletUtils.getPortletDefinitionId(request)

if(null != objID) {

portletUniqueName = objID.getUniqueName();

}

PortletUtils.getHttpServletResponse(javax.portlet.PortletResponse portletresponse)

HttpServletResponse req=PortletUtils.getHttpServletRequest(response);

PortletUtils.getUser(javax.portlet.PortletRequest portletrequest)

     User user= PortletUtils. getUser (request);

PortletUtils.getPageId(HttpServletRequest httpservletrequest)

String pageuniquename = "";

ObjectID objID = PortletUtils.getPageId(req);

if(null != objID) {

pageuniquename = objID.getUniqueName();

}.

Setting the default authenticated or unauthenticated page.

Here is a very useful article from IBM tech note which explains how WebSphere Portal serves the page with the lowest ordinal number under a given context for which the user (authenticated or unauthenticated) has access. Therefore, you can control which page is served by changing order and access control through the Manage Pages portlet. 

Find out the details here.

Approach for customizing IBM WebSphere Portal login-logout mechanism

WebSphere Portal server comes with its own default login/logout procedure but sometimes it's required to extend this default behavior to meet our own requirements. For example, it could be necessary that a user needs to be registered and De-registered at a local security system upon login and logout. 

The following articles describes you how the portal's login procedure works, how it can be configured, and what programming interfaces can be used to extend it. 

• Understanding WebSphere Portal login procedure.
• Extending the WebSphere Portal login/logout procedure.
• Customizing the post login/logout redirect targets.
• Changing the login and logout pages.
• How to change the default login class.

Understanding WebSphere Portal login procedure

WebSphere portal executes certain login / logout command whenever any portal user logs in out of the portal. The classes for login/logout mechanism are specified in the below property file

/AppServer/lib/app/config/services/ConfigService.properties

Default values for these command are: 

command.login = LoginUserAuth
command.logout = LogoutUserAuth

The default login command executes the following sequence:

• WebSphere Application Server login
• WebSphere Portal JAAS login
• WebSphere Portal user login
• Resume session
• Browsers redirect (302)

The default logout command executes following sequence:

• Suspend User Session
• Portlet user logout
• WebSphere Application Server logout
• Browser redirect (302)

How to customize WebSphere Portal Default Login Screen?

WebSphere Portal comes with a default login screen with parameters like user ID, password, first name, last name, etc. Based on your architectural requirements, you may want to change the look and feel of this default login screen to better meet your needs. 

To change the look and feel, change the following jsp

WebSphere\AppServer\installedApps\nodename

\wps.ear\wps.war\screens\html\login.jsp

Or, you can change the login page in 

WebSphere\AppServer

\config\cells\nodename\applications\wps.ear\deployments\wps\wps.war\WEB-INF\web.xml

where you can define where to redirect when a protected page is accessed. 

To change the login mechanism, look for the subclass LoginUserAuth, put the classfile in the classpath, and change it in the ConfigService.properties command.login = LoginUserNoAuth to your package name. This change should reflect the changes in the login mechanism based on your code.

Steps for extending the Websphere Portal login/logout procedure

As mentioned in my previous post, WebSphere portal executes certain login / logout commands when users login /logout to the portal server.

So the question here is can we extend or modify these default command classes to meet our business requirements and the answer is "Yes" we can.

The command classes define several methods that are called during execution of the command. So we need to simply override these default methods to extend this mechanism. These commands works as below: 

LoginUser.execute()
{
Step1: doPreLogin() // Empty in default command
Step2: doAuthenticate() // Step 1-3 of the login sequence (See previous post)
Step3: doPostLogin() // Step 4 of the login sequence 
Step4: Redirection // Step 5 of the login sequence 
Step5: onAuthenticationError() // only in case of an authentication error
}

LogutUser.execute()
{
Step1: doPreLogout() // Step 1 of the logout sequence (See previous post)
Step2: PortletLogout // Step 2 of the logout sequence
Step3: doPostLogout() // Step 3 of the logout sequence
Step4: Redirection // Step 4 of the logout sequence
Step5: onUserSessionTimeOut() // only in case of an user session timeout
}

In order to modify or extend these sequences, derive a child command (class) from com.ibm.wps.engine.LoginUserAuth (or com.ibm.wps.engine.LogoutUserAuth) and overwrite the respective methods.

Relation between WebSphere Portal Server and WebSphere Application Server?

Both WebSphere Portal Server and WebSphere Application Server are commonly used terms in Portal world. Following are some of key points that helps you understand the difference between the two commonly used terms.

 WebSphere Portal Server 

• It is nothing but an preloaded enterprise application (wps.ear) in integrated WAS.
• This application is dependent on database for storing application related information.
• It provides the all the features of portal i.e. personalization, customization, security etc.
• It's configuration and other personalization data is stored in form of database, XML and property files.
• It supports authorization of users.
• Performance measurement about pages / portlets is not measured in WebSphere Portal server.
• It only supports deployment of .war files.
• Only portlet applications can be deployed on WebSphere Portal server.

WAS(WebSphere Application Server) 

• It provides platform for WebSphere Portal Server.
• It doesn't depends on any database.
• Personalization is limited to each application deployed on the server.
• Configuration and related data is stored in form of XML and property files.
• Portal authentication is done in WAS.
• Performance measurement about pages / portlets can be measured in WAS.
• It supports deployment of both types of files (.war and .ear).
• One can develop either basic / advanced J2EE applications or using portlet container in WAS, one  can also develop and deploy portlet applications.

Difference between Custom WAR files and Pre Deployed EAR files of Portal

Whenever you do a portal server installation, you might have noticed that there are lot of applications which are pre deployed as part of the installation process. On top of that we develop and deploy our custom applications.

Here are the few points that differentiate between the user deployed WAR file and Pre Deployed EAR files of a Portal application. These differences are captured based on the few impacted portal areas.

Portlet application

WAR: The portlet application is provided as WAR file. The portal configuration is read directly from the file stream. The WAR file is deployed into the application server by the portal.

EAR: The portlet application is already extracted and deployed into the application server as part of the EAR file. The portal server reads the available portal configuration information (portlet.xml, etc.) from the location where the contained WAR file was extracted to.

Context Root

WAR: The context root is assigned by the portal during WAR deployment.

EAR: The context root is assigned by the EAR developer and stored in the file application.xml. You must ensure that the context root that you specify when you register the portlet matches the one specified in the EAR application.xml.

Display name

WAR: The display name is assigned by Portal during WAR deployment.

EAR: The display name is assigned by the EAR developer and stored in the file application.xml.


WebSphere Application Server policy for portlet applications

WAR: The policy is stored in the WAR file and promoted to the EAR file by the portal during WAR deployment.

EAR: The policy is stored in the EAR file.


Portlet administration

WAR: You administer WAR files using the XML configuration interface and the administration portlets.

EAR: You can register EAR files only by using an XML script with pre deployed mode. You can remove EAR files by using either the administration portlet or an XML script.

Difference between Friendly URL’s and URL mappings

In this article, I am going to talk about friendly URLs, URL mappings and difference between them.

Friendly URLs

Friendly URLs are human readable URL prefixes generated based on the content node hierarchy. The URL prefix for content sub node will contain the prefix assigned to the super and all other nodes above it. Friendly URLs are added to a page through page properties in Admin UI or we can add them through XML access too.



By default, Friendly URLs are disabled in websphere portal, to enable them

1. Open WAS admin console.
2. Navigate to Resources -> Resource environment -> Resource environment providers.
3. Search WP_ConfigService and click custom properties.
4. Click “NEW” and add “friendly.enabled” in name and “true ” for the value.
5. If it already exists change “friendly.enabled” to true

The URL assigned is stored in the page level metadata as com.ibm.portal.friendly.name.

URL Mappings

URL mappings are used to define the human readable URL prefixes to the content in the portal which will serve as entry points onto the portal. However, these URL mappings will not be preserved upon navigating to other content node. We can define URL mappings through Admin UI and XML access. Portal does not provide any API to construct URL mappings programatically. URL mappings are preferred when we need a URL to link up between two different portals. This will allow us to maintain a constant URL even with change in content node.



Few Important Points

1. We need to maintain URL mappings for each entry point and they will not be valid for the next navigation state.
2. We need to define friendly URLs for all the pages or nodes in the hierarchy before assigning it to sub pages. It cannot resolve a friendly URL unless and until all pages are properly defined with respective URLs.
3. For friendly URLs, URl assigned is stored in page level metadata as com.ibm.portal.friendly.name.

Different methods to deploy a portlet using RAD IDE and WebSphere Portal Server

If you are using RAD IDE for portlet development and WebSphere Portal as the deployment server then as a developer you need to know different methods to deploy a portlet on to the server. This will serve multiple purposes.

• First, if one deployment options fails for some reason then you can try the other one.
• Second, it will also help you when you move from DEV environment to upper environments.

Below are some of the popular methods to deploy a portlet.

1. Using Portal Admin Console

This is the option that most of the newbies prefer over other deployment options.

• Export your portlet application as .war file using RAD.
• Open the Portal admin console using the URL http://localhost:10039/wps/portal. The port number (10039) may vary from machine to machine.

Now, navigate to following section

Administration -> Portlet management -> Web Modules

Click on "Install" and select the .war file from your local drive and click next. This will install the portlet application and makes it available to portal. Now you need to add the portlet to the required portal page. Although this option is very straight forward and simple but after looking at other options you may feel that this is not the best one.

2. Using the Traditional way (using WAS admin console)

The most easiest way of deploying any application (either portlet or simple web application) is through WAS admin console.

Log on to WAS administration console using the URL https://localhost:9080/ibm/console.

Now, navigate to following section

Application -> New Application -> New Enterprise Application

• Select an EAR or WAR file from your file system.
• Choose the "Fast path" option and click next.
• Leave everything as is in "Select installation options" and click next.
• Select the deploy server for portal, the one which is ending with websphere_portal.
• Select the module you want to deploy and click apply.
• Enter the context root (/) for the selected application and click next.
• Verify the generated summary information and click finish.

It will display the "Deploy Successful" message. Click "save" to save the configuration.

At this point of time, the portlet application is still not available to the server. Next step is to make the portlets available to the portal server. For that , modify the DeployPortlet.xml located at

\IBM\WebSphere\PortalServer\doc\xml-samples 

to the portlet you need and then run it through "Portal Admin UI".

Administration -> Portal Settings -> import xml

This will install the portlet successfully and make available to portal page. You can use the same way for installing theme as .WAR file and then run the DeployTheme.xml.

3. Using RAD, Deploy Portlet Option

The most easy and simplest way of deploying a portlet is by using "Deploy Portlet" option in  RAD.  When you right click on the portlet application, you will see an option "Deploy Portlet". By selecting this option, RAD will automatically generate a xml script for portlet and deploys it on the server configured in the RAD. This way you can avoid the overhead of creating a .WAR file every time you make a change in your portlet application.

4. Using RAD, Run As Option

The last option, not the cleanest way to do deployment is through "Run As" option in RAD.

By right clicking the project select Run As -> Run on server will install the portlet on the portal home under "Rational Components" page. This way it will create multiple sub pages under this page for each portlet you deploy.

What is the best way to deploy portlets within Portal environment?

This article lists down different ways of deploying portlets within Portal environment listing advantages and disadvantages of each.

Portlet Deployment

One Portlet per war

In this approach, each portlet is bundled as one war file.

Advantages:

• Abstraction to the lowest level
• Independent development and testing of portlets
• Change to single portlet will not impact other portlets within portal

Disadvantages:

• Messy deployment as the number of portlets grow
• Sharing of portlet session is an issue

All portlets in a single War file

In this approach, we pack all the portlets in one war file.

Advantages:

• Clean deployment, easy to manage
• Easy to share portlet session

Disadvantages:

• Parallel development is a challenge
• The size of the deploying war becomes extremely large and takes a long time to deploy
• Single change in one portlet will cause a redeploy of all portlets, adding re-testing overheads and making portal unavailable

Grouping portlets in one war

This approach refer to portlets grouped together based on function/ same functionality into single WAR files. 

Advantages:

• Small changes to a functionality will not affect the overall portal
• Clean and easy to manage
• Portlets which need to share session will be grouped into one
• Parallel development at functionality level is possible

Disadvantages: 

• Maintenance at individual Portlet level might affect other packaged portlet of the application

Shared library management in ext of Portal server

Shared library in ext of Portlets

Shared Libraries

Apart from portlet applications, there are certain shared libraries used by most of the portlet applications (WAR's). This lead to challenge of how to deploy these shared applications. Here are few options:

Single Portlet application and shared libraries packed into one EAR 
This approach suggests having single portlet application, along with shared libraries and resource files, packed as one EAR file.

Advantages:

• Each EAR will be truly independent
• Common functionality could be extended based on the need of the portlet application
• Changes to shared libraries will not impact all the other independent EAR's

Disadvantages: 

• Each EAR would be large and will take longer deployment time
• Each individual EAR would contain copy of the framework classes and maintainability of different versions of framework classes in different columns will be a challenge
• More complex deployment process
• Changes to shared libraries will require redeployment of all the EARs
• Complex deployment
• Class loading strategy of the application server would have to be restricted to PARENT LAST

Multiple Portlet applications and shared libraries packed into one EAR file 

This approach suggests that multiple portlet applications along with shared libraries and resources files, such as properties, packed into one single EAR.

Advantages:

• All portlet applications share same common libraries

Disadvantages:

• Big size and will take a long time for deployment
• Change to single portlet application will require redeployment of whole EAR and thus unavailability of the application
• Complex deployment

Shared library in ext of Portal server

This approach suggests that the shared library to be placed within the ext library directory of the portal server. This approach is suggested when there is are framework libraries which need to be shared across the organization (Organization level frameworks for logging/exception handling etc.) and each application hosted in the environment should follow those standards.

Advantages:

• One of the most common way of sharing the files among the multiple applications
• In portal world, all the common files pertaining to theme, portlets and third party application are stored in shared library
• No need to use Dyna Cache or JSR 286 events to  save and share values across portlets
• Library would be available across applications
• Individual applications would be lighter since they won’t contain the code for framework classes

Disadvantages:

• Change management for the shared libraries would be very risky

Steps for Creating a Shared library on Portal Server

• Logon to Websphere Application server console
• Navigate to Environment -> Shared Libraries
• Click apply and save it

Assigning to a server 

• Go to servers -> Application servers -> websphere portal -> Java and Process management -> classloader.
• Click Shared library references
• Add the library that you want to share
• Save the configuration and restart the Portal server.

Note: Restart of server is mandatory for the class loader to load all the newly added class files. Now, you can add the shared jars to build path for proper compilation and deployment.