Fixing browser URL length problems : WP7

By default WebSphere Portal includes navigational state information along with other information in browser URL in encoded form. Sometimes the length of the URL’s will exceed browser URL max chars limit. This may happen because navigating many pages and portlets on these pages and this even can apply if long render parameters are swapped to the session..

With latest fix (WP 7.0.0.1 CF002) , we can resolve this issue with following configurations. These can be set in the resource environment provider "WP StateManagerService":

1 - Go to the WebSphere Application Server administrative console.
2 - Resources > Resource Environment > Resource Environment Providers
3 - Click on "WP StateManagerService" and "Custom properties"
4 - Add the properties as needed
5 - Save the changes to the master configuration
6 - Restart the portal server

The following properties are available:

historymanager.enabled	The HistoryManager allows to cleanup state for pages visited some time ago. Allowed values are "true" or "false". Default value is "true". Example: historymanager.enabled = true
hstorymanager.threshold	The threshold meaning the number of pages whose portlets and shared state should be kept. Must be a positive integer. Default value is "10" Example: historymanager.threshold = 10
historymanager.prp.removalstrategy	Defines a strategy how the shared state is cleaned up. Possible values are a). no_removal : public render parameters will not be removed, i. e. only portlet specific state will be removed. b). wcm_id  :  Public render parameters will be removed if the expired page has an explicit shared state bucket assigned that starts with the String "ibm.wcm." c). explicit_bucket_assignment : Public render parameters will be removed if the expired page has an explicit shared state bucket assigned  regardless of a prefix. This is a more general strategy than "wcm_id" Default value is "explicit_bucket_assignment" Example: historymanager.prp.removalstrategy = explicit_bucket_assignment

Websphere Portal Theme Evaluation

WebSphere portal themes have evolved continuously over time to provide a better end user experience and address issues like performance, complexity of development, maintenance etc. This section gives an overview of the different types of themes that are available in WebSphere Portal.

Portal

This theme is available since WebSphere Portal 6.0 and is applied by default for the administration pages in WebSphere Portal 7.0, it supports Server Side Aggregation (SSA). In SSA the entire page rendering happens at the server side, the server sends the complete markup to the client during every interaction. The Portal/IBM theme is developed using JSPs, scriptlets and JSP tags are used to introduce dynamic elements. This theme has a few disadvantages that have been addressed in the succeeding themes:

• Files are not easily readable for web developers as logic and presentation are combined together.
• Interactions result in a full page refresh resulting in longer loading time for users.

PortalWeb2

The PortalWeb2 theme was introduced in WebSphere Portal 6.1, it supports Client Side Aggregation (CSA). CSA is a technique of rendering a WebSphere Portal page that moves the rendering workload from the server to the client. The initial markup download contains the HTML skeleton of the page and a number of markup placeholders. These placeholders are replaced with HTML markup by subsequent AJAX requests. Data is obtained from the server by invoking the Representational State Transfer (REST) services provided by WebSphere Portal. Extensible Stylesheet Language Transformations (XSLTs), XML Path Language (XPath) and JavaScript are used at the client side to format and present the data.
The PortalWeb2 theme also supports SSA rendering mode as a fallback in case the page/portlets are not supported. This theme is not supported from WebSphere Portal 7.0, but existing themes developed by customers will continue to work in WebSphere Portal 7.0.

Page Builder

A hybrid theme to incorporate the advantages of SSA and CSA modes resulted in the Page Builder theme, this theme was introduced in WebSphere Portal 6.1.5. As in the Portal theme, page aggregation happens at the server side, inline customizations like creation of a new page, drag and drop of pages & portlets etc are loaded asynchronously on a demand basis, thus providing a more interactive and better user experience. The Page Builder theme provides options to create/customize pages inline rather than having to use administration portlets. It lets you bring in content from a variety of content sources like IBM Mashup Center, Lotus Connections, and other custom sources.

In WebSphere Portal 7.0, existing Page Builder features have been enhanced to support the latest Client Side Aggregation architecture. It provides a well comprehendible programming model, and a user interface that is consistent across other lotus products. It supports both portlets & widgets, and enables portlets to be exposed as iWidgets. Latest CSS3 & HTML5 features have been exploited for better performance and easier customization. WebDAV for WebSphere Portal can be used to administer portal themes and skins, users can create new themes & update existing ones using standard operating system tools.

Which theme to choose?

The decision matrix provided below gives a comparison between the themes available in WebSphere Portal:

Activity	Page Builder Theme	PortalWeb2	Portal
Basic type of rendering	SSA	CSA	SSA
How it works	HTML based template, Expression Language + Dojo	AJAX based, REST + XSLT	JSP based, used JSP tags & scriptlets
Control how the theme is rendered	Files	Theme Policy	Theme Policy
How to define color schemes	Alternate stylesheets	Color Palette	Color Palette
How to define layouts	Layout templates	Using Theme customizer portlet	Using Theme customizer portlet
Most suited for	Web developers. Customization by end users.	Theme customizer use cases	Pages with complete CSA support

Enable/Disable unused applications in WebSphere Portal 7 (Improve portal startup performance)

By default, installation of  Portal and WCM v7 includes around 117 applications (96 for base install) are installed. In many scenarios, we may not be using all applications simultaneously.

Following are three different ways we can improve the portal start up performance.

Method #1: Automatically disabling applications via developer mode

The "enable-develop-mode-startup-performance" configuration task will set all applications Auto Start parameter to 'No' except the applications listed in the file wp.base_TargetMapExclList.properties during a Portal server startup.

On a Portal 7.0.0.1 full and base content install, all applications EXCEPT the following will be disabled (82 applications will be disabled):

wps
wps_theme
wps_scheduler
isclite
Personalization_Lists
Personalization_Workspace
PA_Login_Portlet_App
PA_WebScanner
content_j2ee
JavaContentRepository
wcm
ilwwcm-wcmsearchseed
wci
EphoxEditLive
TemplateLibrary_Servlets
PA_Selfcare_Port_App
UserProfileRESTServlet
MashupMaker_Integration
MashupCommonComponent
Dojo_Resources
Quickr_Document_Picker
AJAX Proxy Configuration
Live_Object_Framework
Feed_Servlet
PageBuilder2_Theme
feedReader
eventExplorer
websiteDisplayer
lwp_peoplefinder_war
odc
PA_WCM_Authoring_UI
PA_WCMLRingPortJSR286
SpellChecker

Note: To add applications to the white list, modify the wp_profile_root\PortalServer\config\StartupPerformance\wp.base_TargetMapExclList.properties file. Add a line such as App_name, where App_name is the name of the application. This list can change between fixpack releases, so review the wp.base_TargetMapExclList.properties file

Run the ConfigEngine.bat enable-develop-mode-startup-performance -DWasPassword=password task, from the wp_profile_root\ConfigEngine directory

Run the ConfigEngine.bat disable-develop-mode-startup-performance -DWasPassword=password task, from the wp_profile_root\ConfigEngine directory, to revert back to a production server.

Method #2: Automatically disabling applications via Portal light mode

The "enable-portal-light-startup-performance" configuration task will set Auto Start to 'No' for all applications defined in the file wp.base_TargetMapInclList.properties to stop them from being auto started during Portal server startup.

On a Portal 7.0.0.1 full and base content install, the following 36 applications will be disabled:

PA_Blurb
PA_MPagesandFavorites
PA_Properties
PA_Eecontentandlayout
PA_appearance
PA_Set_Permissions
PA_portletWiring
PA_ThemesAndSkinsMgr
PA_Resource_Manager
PA_TCustomizerPortApp
PA_Portlet_Manager
PA_Manage_Webservices
PA_Web
PA_Principals_Manager
PA_ResourceView
PA_Credential_Admin
PA_PolicyExplorer
PA_PolicyEditor
PA_PolicyEditorCA
PA_Settings
PA_URL_mapping
PA_UniqueNames
PA_Markups_Manager
PA_Clients_Manager
PA_Import_XML
PA_WCM_Admin
PA_FrequentUsers
PA_Tracing
PA_WPS_Welcome
PA_MageVirtualPortals
PA_TateCatalogPortApp
PA_PropertiesPortApp
PA_ParamConfig
PA_Roles
PA_ApplicationCatalog
#lwp_peoplefinder_war
PA_Policy_Status
#PA_Selfcare_Port_App
#TemplateLibrary_Servlets

NOTE: This list can change between fixpack releases, so review the wp.base_TargetMapInclList.properties file.

Write down the names of the applications that you want to add to the list of lazy applications. Add only applications to the list that are not used by your usual scenarios and that are not required for portal start up.

Note: To add applications to the black list(stop loading by portal startup), modify the wp_profile_root\PortalServer\config\StartupPerformance\wp.base_TargetMapInclList.properties file. This file contains the list of applications that are not loaded when the server is started.  To remove the application , comment out the appropriate application name or delete it from the list. This list can change between fixpack releases, so review the wp.base_TargetMapInclList.properties file

Run the ConfigEngine.bat enable-portal-light-startup-performance

 -DWasPassword=password task, from the wp_profile_root\ConfigEngine directory

Run the ConfigEngine.bat disable-portal-light-startup-performance -DWasPassword=password task, from the wp_profile_root\ConfigEngine directory, to revert back to a production server.

Method #3: Disabling applications manually
 

If it is not desirable to automatically disable 82 or 36 applications from auto-starting by using developer or light mode, it is possible to perform this task manually and disable each application one at a time. To perform this task of preventing the applications from auto-starting:

1. Start the WebSphere Application Server associated with WebSphere Portal(startServer.sh server1).

2. Log into the WebSphere Application Server administration console
(https:/ /hostname.company.com:<WC_adminhost_secure>/ibm/console).

3. Go to Applications --> Application Types -> WebSphere Enterprise Applications --> Select individual application such as PA_Search_Center.

4. Click "Target specific application status" --> Check the checkbox and select the Disable Auto Start button. Save changes.

5. Optional: Go back to the application listing and click Stop to stop the application that is currently running on the Portal server.

Note : Its recommend to disable applications instead of completely uninstalling applications.

Ephox WebRadar Tool for the Lotus Web Content Management

WebRadar tool provides dashboard where you can analyze your web content processes (which content is expiring, which content will be publishing…etc) and generates the different out of box Lotus WCM reports.

WebRadar is designed for a wide variety of users including content administrators, authors, reviewers, approvers and marketers

WebRadar is Tightly integrated with IBM Lotus Web Content Management and WebSphere Portal to pull all required data. Using WebRadar, Content administrators and marketers can monitor web projects at every stage of development through powerful reporting capabilities and metrics that focus on the content. In addition, WebRadar can determine which author is assigned to content, find outdated content, and expose publishing bottlenecks.

Ephox WebRadar Vs WebAnalytics tool

1. WebAnalytics (core metrics, web treands):  To identify external site performance and activity
2. WebRadar : For content analysis (can analyze the process of content managent.)

While there are many tools in the market that are focused on producing external web performance metrics, WebRadar provide insight into the state of the content.

WebRadar improves the productivity of content authors and administrators by providing them insight into the state of their content.

Out-of-the-box and customized reports can be easily produced to find information based on content. In addition, WebRadar can determine which author is assigned to content, find outdated content, and expose publishing bottlenecks. WebRadar is designed for a wide variety of users including content administrators, authors, reviewers, approvers and marketers

Some major advantages of WebRadar

a). Out of box reports (like find content that gets publish /expire in next month …)

b). Filter reports based on metadata of content

c). Editing multiple contents directly from the WebRadar

d). Easy to find out the content and identify problems (why content is not published …etc)

WebRadar 2.1 Demos on youtube

Licensing model :

Requires separate license from Ephox and it is based on PVU(processor value unit). Generally only authoring systems requires license (you mayn’t required in production). And it costs about around 100$ / PVU and support cost 25$ / PVU per year.

Configuring and Integrating the Standalone Tivoli Directory Server with Websphere Portal : wp7

Step 1: Configuring the Tivoli Directory Server

a). Adding Suffixes

• Go to Tivoli Web Admin Console --> ServerAdministration --> Manage Server Properties--> Suffixes --> Enter the Base DN name for the suffix (Like dc=yourcompany,dc=com)--> click add
• Stop and Start the LDAP server from LDAP admin console

b). Importing the portaluser.ldif

• copy the portalusers.ldif file , and change the dc=yourcompany,dc=com with your sepecific details.
• stop the ldap server , go to LDAP admin console-->manage-->LDIF Tasks-->import LDIF data-->browse for the portalusers.ldif
  

LDAP suffix="dc=yourco,dc=com"
user prefix="uid"
user suffix="cn=users"
group prefix="cn"
group suffix="cn=groups"
Portal administrator DN ="uid=wpsadmin,cn=users, dc=yourco,dc=com"
Portal administrator group ="cn=wpsadmins,cn=groups, dc=yourco,dc=com"






Step 2: Integrating the Tivoli Directory Server with Portal (replacing the default filebasedrepository to TDS)

a). Update C:\IBM\WebSphere\wp_profile\ConfigEngine\config\helpers\wp_security_ids.properties file with corresponding values like below (Instead of modifying the wkplc.properties file, you can update this properties file)

standalone.ldap.id=localtds
standalone.ldap.host=sivavaka.com
standalone.ldap.port=389
standalone.ldap.bindDN=cn=root
standalone.ldap.bindPassword=ldappwd
standalone.ldap.ldapServerType=IDS
standalone.ldap.userIdMap=*:uid
standalone.ldap.groupIdMap=*:cn
standalone.ldap.groupMemberIdMap=
standalone.ldap.userFilter=(&(uid=%v)(objectclass=inetOrgPerson))
standalone.ldap.groupFilter=(&(cn=%v)(objectclass=groupOfUniqueNames))
standalone.ldap.serverId=uid=root,cn=users,dc=sivavaka,dc=com
standalone.ldap.serverPassword=Passw0rd

standalone.ldap.realm=sivavaka_portal
standalone.ldap.primaryAdminId=uid=wpsadmin,cn=users,dc=sivavaka,dc=com
standalone.ldap.primaryAdminPassword=wpsadminpwd
standalone.ldap.primaryPortalAdminId=uid=wpsadmin,cn=users,dc=sivavaka,dc=com
standalone.ldap.primaryPortalAdminPassword=wpsadminpwd
standalone.ldap.primaryPortalAdminGroup=cn=wpsadmins,cn=groups,dc=sivavaka,dc=com
standalone.ldap.baseDN=dc=sivavaka,dc=com

standalone.ldap.et.group.searchFilter=
standalone.ldap.et.group.objectClasses=groupOfUniqueNames
standalone.ldap.et.group.objectClassesForCreate=
standalone.ldap.et.group.searchBases=
standalone.ldap.et.personaccount.searchFilter=
standalone.ldap.et.personaccount.objectClasses=inetOrgPerson
standalone.ldap.et.personaccount.objectClassesForCreate=
standalone.ldap.et.personaccount.searchBases=

standalone.ldap.gm.groupMemberName=uniqueMember
standalone.ldap.gm.objectClass=groupOfUniqueNames
standalone.ldap.gm.scope=direct
standalone.ldap.gm.dummyMember=uid=dummy
     
             
standalone.ldap.personAccountParent=cn=users,dc=sivavaka,dc=com
standalone.ldap.groupParent=cn=groups,dc=sivavaka,dc=com
standalone.ldap.personAccountRdnProperties=uid
standalone.ldap.groupRdnProperties=cn

standalone.ldap.gc.name=
standalone.ldap.gc.updateGroupMembership=
standalone.ldap.gc.scope=direct 
standalone.ldap.derefAliases=always
standalone.ldap.authentication=simple

standalone.ldap.referral=ignore
standalone.ldap.delimiter=/
standalone.ldap.ignoreCase=true

standalone.ldap.sslEnabled=false
standalone.ldap.sslConfiguration=
standalone.ldap.certificateMapMode=EXACT_DN
standalone.ldap.certificateFilter=
standalone.ldap.reuseConnection=true
standalone.ldap.searchTimeLimit=120000
standalone.ldap.connectionPool=false
standalone.ldap.supportSorting=false
standalone.ldap.supportPaging=false
standalone.ldap.supportTransactions=false
standalone.ldap.isExtIdUnique=true
standalone.ldap.supportExternalName=false
standalone.ldap.translateRDN=false
standalone.ldap.searchCountLimit=500
standalone.ldap.searchPageSize=
standalone.ldap.returnToPrimaryServer=
standalone.ldap.primaryServerQueryTimeInterval=
standalone.ldap.loginProperties=uid
standalone.ldap.cp.maxPoolSize=20

 b). Execute the following commands to validate and update

#Validates the updated properties
ConfigEngine.bat validate-standalone-ldap -DWasPassword=wpsadmin -DparentProperties=C:\IBM\WebSphere\wp_profile\ConfigEngine\config\helpers\wp_security_ids.properties

#Below command will change the portal filebased repository toTDS
ConfigEngine.bat wp-modify-ldap-security -DWasPassword=wpsadmin -DparentProperties=C:\IBM\WebSphere\wp_profile\ConfigEngine\config\helpers\wp_security_ids.properties

Note: If any problems while executing the above commands,
a) make sure above properties proper (like LDAP admin ID(bindDN), PWD).
b) check the C:\IBM\WebSphere\wp_profile\ConfigEngine\properties\wkplc.properties and file and make sure Stand alone LDAP properties are valid and same as entered above

Once the above commands executed successfully, restart the portal and application server if its already started.