Saturday, December 29, 2012

Login into Websphere Portal directly – Auto Login url in WebSphere Portal



WebSphere Portal has its direct URL which you can call with user name and password as query parameter when you do that it will automatically login into portal for you and take you to the portal landing page.

wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=
PortalUserName&password= PortalPassword


Examples:

 http://localhost:10039/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=kameshwar&password=password123


This direct autologin url is very helpful during load testing of portal application or if you are performing any unit testing using any tool like JMeter.

How to monitor performance of portlets

There is a very common requirement where we have a need that how to monitor performance of portlets specially when the portlets are misbehaving.
We can use the concept of Global Filters to create a filter that will monitor all your portlets (render, resource, action and Event phase) and write a message in the log if one of the method takes more than the threshold time.

Below is the code of Performance Filter. Here we have created a java class name as PortletPerformanceFilter.java

package com.company.performance.filter;

import java.io.IOException;
import javax.portlet.PortletException;
import javax.portlet.PortletRequest;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.filter.FilterChain;
import javax.portlet.filter.FilterConfig;
import javax.portlet.filter.RenderFilter;

public class PortletPerformanceFilter implements RenderFilter {
            public void destroy() {
System.out.println("Inside PortletPerformanceFilter.destroy()");
            }
public void init(FilterConfig arg0) throws PortletException {
System.out.println("Inside PortletPerformanceFilter.init()");
            }
public void doFilter(RenderRequest request, RenderResponse response,
                                    FilterChain filterChain) throws IOException, PortletException {
                        try{
                        if (isPerformanceFilter(request)) {
System.out.println("Entering PortletPerformanceFilter.doFilter()");
            long beginTime = System.currentTimeMillis();
            filterChain.doFilter(request, response);
long endTime = System.currentTimeMillis();
            long executionTime = (endTime - beginTime) ;
System.out.println("Portlet Window ID " + request.getWindowID()
                                                            + " Time to execute render = "
                                                            + executionTime + " ms");
System.out.println("Exiting PortletPerformanceFilter.doFilter()");
                        } else {
// if not in maintenance, just call the normal chain
filterChain.doFilter(request, response);
                        }
                        }
            catch(Exception e){
System.err.println("PortletPerformanceFilter Error"+ e.getMessage());
            }
}
/*
 * Checks if the portlet addressed in the request has to be checked for  PerformanceFilter
 */
private boolean isPerformanceFilter(PortletRequest request) {
            boolean isPerformanceFilter = false;
isPerformanceFilter = Boolean.valueOf(request.getPreferences(). getValue ("PERFORMANCECHECK", "false")).booleanValue();
            return isPerformanceFilter;
            }
}

In the doFilter() method we are taking the time before and after forwarded control up the chain and using that time to calculate execution time which we are printing.


To use global portlet filters, add the following code to the root folder or in the WEB-INF directory of your web application and name it plugin.xml file:


<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin id="com.brocade.webportal.performance.filter" name="WS_Server" provider-name="IBM" version="2.0.0">
<extension point="com.ibm.ws.portletcontainer.portlet-filter-config">
            <portlet-filter-config class-name="com.brocade.webportal.performance.filter.PortletPerformanceFilter" order="100">
<description> Portlet Performance Filter, order = 101 </description>
            <lifecycle>RENDER_PHASE</lifecycle>
            </portlet-filter-config>
    </extension>
</plugin>

The above implementation is for RenderFilter interface, for example, which has been added as  <lifecycle>RENDER_PHASE</lifecycle> code in plugin.xml. This addition is analogous to the other filter interfaces. The following values are valid for the <lifecycle> parameter:
  • RESOURCE_PHASE
  • EVENT_PHASE
  • ACTION_PHASE
Once the PortletPerformanceFilter is developed we have to copy it in the shared library so that it can be accessed by portal across application.

These global filters apply to all portlets that are running within the portlet container, including both plain portlets and console modules.

The portlet in which we want to check the performance, we need to set portlet preferences as :PERFORMANCECHECK and its value should be true
 

Thursday, December 20, 2012

Differences between WAR files and predeployed EAR files of Portal Application



Affected portal area
WAR file
  Predeployed EAR file
Portlet application
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.
  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
The context root is assigned by the portal during WAR deployment.
  The context root is assigned by the EAR developer and stored in the fileapplication.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
The display name is assigned by Portal during WAR deployment.
  The display name is assigned by the EAR developer and stored in the fileapplication.xml.
WebSphere Application Server policy for portlet applications
The policy is stored in the WAR file and promoted to the EAR file by the portal during WAR deployment
The policy is stored in the EAR file.
Portlet administration
You administer WAR files using the XML configuration interface and the administration portlets.
  You can register EAR files only by using an XML script with predeployed mode. You can remove EAR files by using either the administration portlet or an XML script.
 

Differences between WAS and WPS



WAS(Websphere Application Server)
WPS(Websphere Portal Server)
WAS provides platform of WPS.
WPS is one of enterprise Application in WAS (wps.ear).
WAS is not depend on database.
WPS  is depend on database.
Personalization   is limited to each application.
Provides very good  personalization.
WPS Authentication is done in WAS.
WPS can do only authorization.
Configuration data’s are stored in XML and property files.
Configuration / personalization data’s are stored in database , XML and property files.
Performance Measurement about page/portlet is measured in WAS.
Performance Measurement about page/portlet is not measured  in WPS
Both war/ear files can be deployed
Only war files can be deployed
We can develop portlet application.
Can develop Plain J2EE application, advanced J2EE Application. Using portlet container in WAS6.1, we can develop portlet application.
Portlet is directly accessible using URL.
In WebSphere Portal, you cannot directly access a portlet through a URL.
Security role references are currently only supported by WebSphere Application Server.
Security role references are not maintained in WebSphere Portal Server.