Modified by AlexLang
When ever you deploy a new WebSphere Portal instance you must tune the Portal appropriate to the environment. For example, out of the box, Portal is NOT tuned for production.
The IBM Portal Performance team has produced several documents that contain the tuning that should be done after installation and before deploying a Portal to production. This is the document for V7 and this is the one for V8. This document should be considered a prerequisite for the beginning of performance testing and certainly a prerequiste for production.
There are several components that should be tuned. These include the Portal itself, the LDAP, the database, the OS and the web server.
Mike White and I have written a ConfigEngine script that will apply the tunings for the Portal automatically. The script is included in Portal V220.127.116.11 CF22 and Portal V8 CF05. Use of this script will improve the accuracy of applying the tuning changes as well as reduce the time needed to do the task.
The changes are driven by a properties file (tuning.properties) along with several resource environment providers files. Since the tuning.properties file assume you are a WCM rendering server that is only a subscriber (and NOT a syndicator), you may need to adjust some of the setting to match your environment. You can easily do this by copying the read-only tuning.properties to a local directory, updating the name/value pairs that need updating and point to the new copy when you run the task.
Note for zOS users: This task does run on zOS. Note however, that there were significant fixes put into the code to resolve zOS issues in March, 2014. These fixes wil be included in 8001, CF10 as well as the initial release of V8.5. If you are on zOS and not running at least 8001 CF10 level, please download the linked code immediately following.
The latest README file is linked here. It provides the details on using this new task. I have also included the (current) latest version of the code here. The latest version can be untarred in the PortalServer/installer/wp.config/config subdirectory as is. Note that the default the subdirectory just mentioned does NOT have write permission. The permission must be changed before trying to untar this file.
Note: It has been discovered that if you are on Portal 8.0.0.x CF06 (or earlier) and also have installed the tuning task from the tar file (linked just above) that the installation of a Portal CF may fail. The failure reason is that the files installed by the above linked tar file are not supposed to exist according to the CF installer. To resolve this issue (and thus to be able to proceed with CF installation) just remove the files that were installed for the tuning task. This list can be obtained by just listing the files in the tar file. After removal, just install the CF as per instructions.
Modified by Thomas_Hurek
In today's blog post we will explain a few lessons around WebSphere Portal and Web Content Manager Administration:
1. How to exclude the friendly name of a page in the path:
When building the friendly URL for a page, WebSphere Portal will add the friendly names of all pages in the hierarchy to the final URL. For example in a content structure Content Root -> Home -> MyPage the URL for the page MyPage would look like /wps/portal/Home/MyPage (or /wps/myportal/Home/MyPage for an authenticated user) -
note that it is possible to configure a different context root if needed.
Now if one wants to exclude a page in the hierarchy it is possible to set the friendly name of the page to the following value: com.ibm.portal.friendly.wildcard
In our sample above by setting the friendly name com.ibm.portal.friendly.wildcard for the label Home the resulting URL for the page MyPage would be /wps/portal/MyPage (or /wps/myportal/MyPage for an authenticated user).
This is documented in more detail here:
2. How to exclude a page / hierarchy from being managed by managed pages:
If you do not want parts of your page hierarchy to be managed pages - meaning stored in WCM in the Portal Site library and syndicated if syndication is configured - it is possible to exclude pages / page hierarchies by setting a configuration flag for the page. Reasons for excluding pages from being managed could be the need to not syndicate certain pages to production since they are not needed there or a desire for moving those pages manually via XMLAccess.
Note: There is no indication in the UI if a page is managed in WCM or not. Thus excluding parts of a site may lead to a very confusing end user experience. Ideally all pages that can be edited by non admin users should be managed pages.
To exclude a page from being managed, use XMLAccess to configure the setting has-system-mapping = false as a property of the content-mapping-info tag for the page in question.
Our recommendation is to create a root page with the has-system-mapping = false setting via XMLAccess and have all the "un-managed" pages below.
3. Configuring Syndication via command line:
With Version 8 we allow to configure Syndication from the subscriber via command line. That can be particular helpful in an empty Portal that does not have a user interface.
See the following documentation for details on configuring this:
4. Is it possible to install 18.104.22.168 fix pack and the latest cumulative fix in one step?
Yes - we support installing both via the IBM Installation Manager in one step. Note that when using the command line to install the maintenance packages you will need to download both repositories.
5. Issues with maintenance installs if the basic authentication TAI is disabled
Among other things the basic authentication Trust Association Interceptor is used to authenticate requests for the theme resources stored in webdav. As part of maintenance we sometimes update the default theme
files in webdav. If the TAI has been disabled for the mycontenthandler URLs the authentication will fail and the webdav update will not take place. That can lead to issues later on.
Before installing maintenance the TAI should be re-activated.
6. How to prevent duplicated default pages after syndication
If using the Portal 8 Managed Pages feature and triggering the initial syndication of the "Portal Content" WCM library without first emptying the target system, the target system will contain some Out of the Box pages from both the Syndicator and the Subscriber. To prevent this issue, follow the documented Staging to Production approach that contains a step to first empty the default virtual Portal or creating a virtual Portal empty via the command line.
See the following article for more information on Initial Staging to Production:
7. Issue with Firefox and Managed Pages page creation
WebSphere Portal 22.214.171.124 CF6 or higher address an issue with Firefox when creating a managed page.
8. Create a javacore, heapdump, system core from the WAS Console
With WebSphere Application Server 8 and higher it is now possible to trigger the creation of a heapdump, javacore or system dump from within the Websphere Application Server Admin Console for any process in the currently managed cell or standalone server.
The feature is available under Troubleshooting -> Java dumps and cores.
9. Modifying contenthandler / mycontenthandler URLs via ConfigService setting
If you would like the contenthandler / mycontenthandler URLs to change to e.g. trigger a reload of certain theme resources from the server you can trigger that by modifying the WP ConfigService and setting a key "digest.seed" to any string, which will then be used on next portal restart to seed the digest used in the URLs.
You can find more information here: http://www-01.ibm.com/support/docview.wss?uid=swg21647572
Modified by AlexLang
In order to improve the performance of the personalization (PzN) function in WebSphere Portal, the PzN results can be cached. Otherwise the LDAP and the Portal database is accessed excessively. There are different forms of caching within PZN - resource collection caches, visibility rule caches, and others. However, most are surprised to find that Portal disables the PzN visbility cache by default.
If your production (or performance sensative) Portal uses PzN, then you should definitely enable the PzN cache. If not, both the LDAP and the database are excessively accessed. Note that visability rules in the theme use PzN.
The cache is enabled via a file. There is one of these files per node. Therefore, you must update one file on every node and then restart the cluster for the change to take effect.
The file is /opt/IBM/WebSphere/wp_profile/PortalServer/config/config/services/PersonalizationService.properties.
Set the property "rulesEngine.attributeBasedAdmin.enableCaching" equal to "true". This will enable the Portal PzN caching in Portal.
In addition, there is an undocumented property "rulesEngine.user.nestedGroupLookup" which can be set to false to speed up PzN. However, this should only be done if (and only if) nested groups are NOT used in the authorization ACL lists in Portal.
Modified by AlexLang
This entry is really a paper that I have maintained on another wiki. However, that Wiki is disappearing so I have copied and updated that paper.
The paper discribes how to configure WebSphere Portal 7 or 8 security to use an attribute other than the Portal default to login.
For example, in IBM we have an enterprise LDAP known as Bluepages. On of the attributes in Bluepages is our external e-mail ID. This e-mail ID is also known as our intranet ID inside IBM. Most all the sites and applications we log onto inside IBM require the use of our intranet ID. However, this is NOT the Portal default.
By default, Portal uses the first element of your LDAP Distinguished Name (DN) as your login ID. This first element is known as the Relative Distinguished Name (RDN). Many times, like inside IBM, Portal needs to be configured to use an attritbute in the LDAP record as the login ID.
This paper describes the process for WebSphere Portal to use an attribute other than the RDN (of the DN) for login.
The paper is attached here.
This blog post outlines a few development tips and tricks for a WebSphere Portal / WCM 8 project.
Rendering of a site area via site area rendering template:
With version 8 it is possible to render a site area that has no default content associated with it. To use this feature create a rendering template for your site area, create a new site area authoring template, associate the rendering template with the site area authoring template in the rendering behavior section and start creating site areas with the according template. You can then also change the rendering template for the site area. This process can help you to avoid having to create some default content that would render a certain component.
The following screenshot shows a sample of such a site area:
Clean WebSphere Portal URLs without state information:
The following article explains how to implement state-free URLs:Implementing friendly URLs in IBM WebSphere Portal 8-based WCM rendering
While the vast majority of WCM URLs were without state, page navigator links still contained state information since the information which page to navigate to needs to be stored in the URL.Order of Theme and Rendering Plugins
WCM Rendering Plugins can be very useful to influence the rendered content of a WCM Rendering Portlet. Note that the Rendering Plugin gets called before the theme starts to render. So if code should be executed before the Rendering Plugin a different place has to be used - e.g. a custom SessionValidatorFilter.Dynamic Content Spot jsp's are called without Render Parameters:
The Portal 126.96.36.199 and 8.0.x themes introduced the concept of dynamic content spots - layers to hold dynamic logic separated from the static html/css/... files that are by default stored in webdav. Note that the dynamic content spots do not have access to render parameters passed in the URL. In case render parameters need to be accessed before portlet rendering starts, the logic needs to implemented somewhere else - for instance as part of Default.jsp or in a custom SessionValidatorFilter.Location when importing items with WCI as components or content:
Web Content Integrator is a powerful and easy to use tool to import existing data into WCM. WCI allows to not only create content but also components. Note that it is currently not possible to specify the location of components - so it is not possible to organize them into folders when running WCI - after the import with WCI the location can be changed (e.g. via API or UI). Content on the other hand allows to specify the location during the WCI import. Nested Navigator Designs:
Out of the box WebSphere Portal is enabled to showcase many product features. To enable that, authenticated users / anonymous users have been granted access to various pages, portlets, URL Mappings and other artifacts. When building your custom solution you typically create your own set of WebSphere Portal artifacts, leveraging some of the out of the box features like for instance the Web Content Manager Rendering portlet. Before going live we recommend to clean up the default permissions we set out of the box to limit the pages and portlets available to your users. Even though the pages might not show up since you might have coded your theme to not display them or the pages having a lower ordinal than your custom pages it is still possible to reach them by using friendly URLs or possibly search.
The easiest way to clean up the permissions is by using XMLAccess using the following steps:
1. Perform a full XMLAccess export using the ExportRelease.xml (located in PortalServer\doc\xml-samples) as input.
For example the command could look like this:
c:\ibm\wp_profile\PortalServer\bin>xmlaccess.bat -user wpsadmin -password wpsadmin -url http://localhost:10039/wps/config -in C:\ibm\PortalServer\doc\xml-samples\ExportRelease.xml -out ExportRelease_Result.xml
2. Take a copy of the exported file and keep it as a backup. In case your change has unexpected consequences you can re-import the original file to undo your changes.
3. Modify the exported file.
Search for the strings "all authenticated portal users", "anonymous portal user", and "all portal user groups".
You will see a structure like this:
<role actionset="User" update="set">
<mapping subjectid="anonymous portal user" subjecttype="user" update="set"/>
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set"/>
<mapping subjectid="all portal user groups" subjecttype="user_group" update="set"/>
In this structure you can see in the role tag in the actionset attribute which role type is assigned.
The anonymous portal user group represents all users before they login.
The all authenticated portal users user group represents all users when they are logged in.
The all portal user groups user group represents all groups of users - it is only assigned to a user if the user is member of at least one other group. My recommendation is to not use all portal user groups user group but only leverage all authenticated portal users user group unless there is a very special use case.
The role types Portal assigns out of the box are either User or Privileged User role. While User on a page or portlet only grants the user the permission to see the resource, Privileged User also grants the user the ability to customize his own instance or create a private instance. For pages this means the user can create a private page below the parent page he has access on or create a private copy of the page he has access on. For portlets if the user has Privileged User on the page and the portlet he can modify the configuration of the portlet on his private copy of the page.
Unless there is a use case to allow end users to customize pages and / or portlets or create private pages you should remove the Privileged User role assignments for all authenticated portal users user group. In case you require the user to have access to view the page or portlet you could replace the access with the User role.
As a sample check the permissions for the page Web Content Management that is used for authoring - by default Privileged User is assigned. In the sample below we show the xmlaccess snippet before and after the change to remove the assignment of the role to all authenticated and assigning the role to a certain new group that represents the users that can author content.
<role actionset="Privileged User" update="set">
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set"/>
<role actionset="User" update="set">
<mapping subjectid="cn=authors,ou=users,dc=com" subjecttype="user_group" update="set"/>
<role actionset="Privileged User" update="set">
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="remove"/>
Caution: There are a few assignments that you likely do not want to remove: The login page (unique name is wps.Login) and login portlet (unique name is login.war) and in case you are allowing signup or edit my profile, the edit my profile page (unique name is wps.Selfcare) and portlet (unique name is selfcare.war).
4. After modifying the file reimport the modified file with XMLAccess.
For example the command could look like this:
-user wpsadmin -password wpsadmin -url
Web Content Manager performance can be improved by enabling caching. In fact we
recommend to enable caching for WCM for production sites. There are multiple
caching options with WCM.
Fragment caching allows to cache data for a single user or
across all users for a WCM rendering portlet.
WCM Advanced caching caches WCM data at the WCM core level -
below the WCM portlets. It is flexible - 5 different cache configurations are
possible. The most common used option typically is Secured caching in which the
cache key is computed based on the group membership of the user.
By default the cache key will contain all groups the user is member of in the configured user registry (typically a LDAP). If only a small subset of those groups is used for assigning permissions in WCM and users are typically member of many other different groups the cache efficiency can be very low. To increase the efficiency of the cache it is possible to configure WCM to use a subset of groups.
Two new properties are defined for WCMConfigService to allow one to define the set of groups used to secure WCM content. If the property connect.moduleconfig.ajpe.contentcache.secured.cache.group.subset is set then the cache keys used for Secured/Personalized cache will only contains these groups. For a given user the groups used in the cachekey is defined as the intersection of the subset groups defined in the new property and the user full group memberships as defined in the user management system. If the property connect.moduleconfig.ajpe.contentcache.secured.cache.group.subset is NOT defined then the groups used in the cachekey is the user's full group memberships as defined in the user management system.
The second new property connect.moduleconfig.ajpe.contentcache.secured.cache.group.subset.separator is used to define the separator charactor use to separate the groups listed in connect.moduleconfig.ajpe.contentcache.secured.cache.group.subset. The default value is a semi-colon.
This functionality was added with CF15 for Portal 188.8.131.52 and 184.108.40.206 and is part of Portal 8.0 and future versions.
Web Content Manager performance can be improved by enabling caching. In fact we recommend to enable caching for WCM for production sites. There are multiple caching options with WCM.
Fragment caching allows to cache data for a single user or across all users for a WCM rendering portlet.
WCM Advanced caching caches WCM data at the WCM core level - below the WCM portlets. It is flexible - 5 different cache configurations are possible. The most common used option typically is Secured caching in which the cache key is computed based on the group membership of the user.
The downside of WCM Advanced caching is that you can not control that for certain WCM rendering portlets no cache is being used since the caching happens below the portlets. The reason why you might want to disable Advanced caching for certain WCM rendering portlets could be that some data in them has to be immediately visible or that the portlet displays WCM content that uses PZN rules (PZN rule results would be cached and the rule not executed any more).
Using fragment caching in the WCM portlets can be an alternative to
Advanced caching but it does not allow to use Secured caching or the
other caching options of WCM Advanced caching - it only allows to have a
shared cache across all users or a personal cache for each user.
I have implemented a preprocessor that can be configured per WCM rendering portlet to disable the WCM data in this portlet from being cached in the Advanced cache. The attachment below points to a zip file containing a war file. To use the preprocessor deploy the war file with an arbitrary context root via the WebSphere Application Server Admin Console and start the Application. The source code is attached in the war and can be modified. Then edit the WCM rendering portlet configuration and select the now visible preprocessor "NoCachePreProcessor" - save the portlet.
See the usual DISCLAIMER OF WARRANTIES:
The enclosed code is sample code created by IBM Corporation.
This sample code is provided to you solely for the purpose of assisting you in the development of your applications. The code is provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample code, even if they have been advised of the possibility of such damages.
Stay tuned for another blog entry about how to customize the cache key of the Advanced WCM Cache.
Modified by AlexLang
When I am helping customers with performance, there are 3 things that I tell them they must do relative to IHS:
1. Set the "Expires" and "cache-control" headers properly. Note that Portal does NOT set these headers on some types of content
2. Set IHS to compress (gzip) content so that it travels the network efficiently
3. Use mod_disk_cache to cache statics and off-load the Portal servers of this work.
Their next question is usually "how do I do this"!
So, I've attached a copy of my httpd.conf that I use in my cluster to do all three. If you use my copy, you still need to adapt it to your specific setup, but it should get your started.
Keep in mind that this httpd.conf file is matched to use in Portal 7. In Portal 8, all the context roots of all the URLs start with "/wps". So, for correct caching (reverse proxy caching), you need to use fiddler or firebug to introspect all the URLs that the browser requests from Portal and then insure you have a "CacheEnable disk" stanza for that URL.
Note also that when using the reverse proxy cache (like I have done here), that you would normally use htcacheclean to insure that your cache doesn't get too large or that stale entries are periodically removed from the disk. I have put the following in a cron job to do just that:
0 1 * * * /opt/IBM/HTTPServer/bin/htcacheclean -n -t -p/opt/IBM/HTTPServer/cache -l10M >/dev/null 2>&1 # Clean up the IHS cache, to a max of 10Meg
This runs every night to force the cache to occupy no more than 10Meg of space.
More and more customer are taking advantage of virtualization to deploy their Portal infrastructures. While AIX LPARs and zLinux are are fairly mature virtualization platforms for Portal, VMWare is relatively immature but usage is accelerating rapidly.
The principles that that guide best practice on VMWare are not that different than the same rules on stand alone OSes. However, because the emphasis on a virtualized platform is resource sharing, the principles get overlooked.
There are 2 critical rules:
1. The memory used by Portal can never be swapped; either at the guest or at the hypervisor level.
2. CPUs must be allocated to the guest based on peak utilization needs; not based on average utilization.
One characteristic of a JVM is the garbage collection of the Java heap. This involves two phases known as "mark" and "sweep". These two phases are generally required to touch the memory top to bottom. However, if any portion of that memory is ever swapped out, severe performance problems will arise. Therefore, you must assign sufficient physical memory to the guest and insure that VMWare never swaps it or shares it with other guests.
In a VMWare (or any virtual hosted environment), there is a belief that by sharing resources like CPUs and memory, you get better financial returns. However, because Portals are generally operating under committed SLAs (Service Level Agreements) that guarantee peak response time and load metrics, you have to size the guest resources assuming that they are dedicated. VMWare administrators will typically look at coarse grained usages statistics which average out these peak demands and under-size the dedicated CPU requirements. In VMWare, you need to allocate dedicated, non-sharable CPUs and physical memory to each Portal guest.
Note that in AIX DLPARs, you can relax the CPU constraint. AIX allows you to specify a min (also known as an "entitled) amount of CPU to the guest along with a maximum number of CPUs taken from a shared pool. As long as the max CPU matches the peak needs of the guest and as long as the Portals are the highest priority LPAR in the shared CPU region, this is OK. In AIX, memory still need to be dedicated to the LPAR. On the mainframe, z/VM z/Linux guests can share both memory and CPUs as z's hypervisor is very sophisticated at managing both these resources.
1. Set the Javaheap MinHeap equal to the MaxHeap. When you do this, you force the guest and the hypervisor to fully allocate all the memory. There are inefficiencies in setting the minHeap < maxHeap because malloc() calls can suffer latencies in a virtual environment that are much worse than in a non-virtual environment. In the past, there was heap fragmentation concerns when setting the minHeap = maxHeap. However, in the Java 6 world with "gencon" as the GC policy, the concerns are no longer valid.
2. Prefer only 1 cluster member per Node (i.e. VMWare guest OS). Because of both virtual context switching in the guest along with real context switching in the hypervisor, there are efficiencies in only have 1 active JVM in a VMWare guest. Traditionally, in a 32bit JVM, vertical clustering was a common technique to get more working set memory in the system. In 64bit environment, vertical clustering is much less relevant for managing memory issues. So, cluster becomes much more about capacity and horizontal clustering manages both CPU and memory resources in VMWare better.
3. Two virtual CPUs on a production VMWare guest serving any sizeable load is likely insufficient. Because of multi-threaded garbage collection along with multithreaded
workers in Java (a.k.a. WebContainer threads), two CPU are generally
insufficient to meet most production load requirements. In practice,
we've found that a minimum of 4 CPUs per guest with a single cluster
member in the guest a requirement.
This article will advocate that one should NOT use SSL between the web servers and the Portal servers due to high cost in CPU cycles and the relatively low level of security it ultimately provides.
By default, there are two paths that a request can be forwarded from a web Server (Apache, IHS, etc) to the Portal servers. One is unencrypted (http) and one is encrypted (ssl, https). By default, if a request from a browser arrives at IHS via SSL, it will be forwarded to the Portal server via an https,ssl transport as well.
SSL serves two main purposes. One is to authenticate that the target server is who it is expected to be. The other is to encrypt the data that flows between the two servers.
Unfortunately, you do not get something (SSL) for nothing. Encryption is CPU intensive. Ever HTTPS packet that arrives from the browser has to be decrypted at the IHS server and then re-encrypted as it flows out the IHS server, thru the plugin and on to the Portal server. It is then decrypted again at the Portal server. If you compare the CPU utilization of the IHS and Portal servers during a stress run in a pure HTTP versus an HTTPS run, the results are often dramatic.
However, if you consider the value that using SSL between Portal and IHS provides, I'd assert that it is low. In the "best or breed" topology, IHS sits in a DMZ and Portal sits inside your company firewall. Further, firewall rules insure that only the IHS server(s) have access to the Portal inbound transports. Therefore, the value in SSL insuring the authenticity of the two servers is limited; they are who they say they are by default (since no other server can access their ports).
Likewise, the value of encryption in this scenario is dubious as well. Without physical login access to the serves, a "man in the middle" attack would be one of the few viable attacks to snoop the packets between the servers. If someone can stage a man in the middle attack from within your corporate network topology, you have bigger problems than someone snooping your Portal packets!
So, I recommend you terminate SSL between the browser and the Portal at the web server. All traffic between IHS and the browser will be SSL if using the HTTPS URL on the browser. However, traffic between IHS and Portal can be HTTP; i.e. no SSL.
This is easily done by disabling the "HttpQueueInboundDefaultSecure" transport for each application server. There is a checkbox labeled "enabled" on the panel "Application servers > WebSphere_Portal > Web container transport chains > HttpQueueInboundDefaultSecure". Uncheck the box, regenerate your web server plugin and propagate the plugin. This removes the HTTPS transports from the plugin-cfg.xml file for each server.
Note: Do not disable the "InboundAdmin" transports.
Portal makes extensive use of group membership relationships to determine what content you are allowed access. Group membership hierarchies are stored in the LDAP. Usually, an individual person is a member of several groups. However, those groups are also members of groups. This is known as "group nesting".
When you initially log into Portal, Portal, thru the VMM (WIM) component, requests all the groups for which you are a member. As initially configured, VMM will execute a query against the LDAP which will scan all the groups in the system to see if your DN is in that group. Once at initial set of groups are returned to VMM, it will recursively find all the groups that those initial groups are members of until it exhausts the tree.
The searching in the LDAP can consume a great deal of LDAP compute time as both the width and depth of the group membership tree.
A much more efficient way to do this in the LDAP is to use the "membership" attribute that most all modern LDAP has. Whenever you are made a member of a group, in additional to adding your DN to the group's LDAP record, an attribute is added to your LDAP record to indicate membership in that group. The attribute, called "ibm-allGroups" in the Tivoli Directory Server (TDS) is also used when a group is made a member of another group.
Therefore, it is much more efficient to determine group membership based on the value of this attribute in the person or group object than actually searching all the groups in the system.
To use this more efficient group lookup technique, you must modify the wimconfig.xml file for the server or cell. I'll should the changes needed to TDS below. The changes for other LDAP types are similar.
The wimconfig.xml file, when initially configured to the LDAP, likely has a stanza that looks like this:
<config:memberAttributes dummyMember="uid=dummy" name="uniqueMember" objectClass="groupOfUniqueNames" scope="direct"/>
To configure ibm-allGroups, it should look like this:
<config:memberAttributes dummyMember="uid=dummy" name="uniqueMember" objectClass="groupOfUniqueNames" scope="direct"/>
<config:membershipAttribute name="ibm-allGroups" scope="direct"/>
The "scope" should reflect the depth of the results coming back from the LDAP. If ibm-allGroups only returns the immediately groups that this person or group belongs to, then use scope=direct.
I've spent the last couple of months helping a customer migrate a large Portal 220.127.116.11 environment to Portal 18.104.22.168.
This customer was somewhat unique in that they made extensive use of the WMM lookaside database in 6.0. All this lookaside data needed to correctly migrated to VMM (a.k.a WIM) in Portal/WAS 6.1.
The volume of data in the WMM lookaside database was rather large and the customer knew, going in, that this would like be a source of risk during the migration.
As it turns out, the volume of data in the lookaside combined with the fact that the database was Oracle (10g) exposed several issues in the code designed to copy the WMM data to VMM during the migration.
Prior to the migration, the customer upgraded the 22.214.171.124 Portal to 126.96.36.199. This was required to pick up the Portal/WAS migration prereq APARs required for migration.
The target environment was installed and upgrade to Portal 188.8.131.52 running on WAS 184.108.40.206. Again this took us to the known and required levels of Portal and WAS for a migration.
Before it was all over, we required the following Portal and WAS APARs in order to successfully migrate the WMM to VMM data:
The first 4 are WAS APARs, the last on is a Portal APAR
A little known fact of Portal (and WAS, for that matter), is that when Portal serves up theme files, there is no default cache-control headers in the HTTP response. As a result, these files is not saved in the browser's local cache. Therefore, theme components that are scripts (.js), CSS files and images (served up as HREFs in "secondary GET requests" after the initial
portal page GET request is parsed by the browser) are returned to the browser with no directive to tell the browser to cache these for future renders. This means that all of
these components are fetched on each and every page render.
Use a tool like "fiddler" or "firebug" to observe this behavior.
This problem could induce long render times for your portal. Users with poor bandwidth, no local
edge caching and/or long latency back to the main Portal servers could see
dramatically longer render times than users who are local to the portal
servers with excellent broadband service.
The solution is to use IHS (Apache) and force these components to
have cache-control headers via the httpd.conf IHS configuration file. Then, these theme elements are cached in the
browser's cache for a period of time. Here is an portion of an IHS httpd.conf to use as an example to force cache-control headers for static theme elements:
### Force Caching of statics
<LoadModule expires_module modules/mod_expires.so
ExpiresByType text/css "access plus 20 days"
ExpiresByType image/jpeg "access plus 20 days"
ExpiresByType image/jpg "access plus 20 days"
ExpiresByType image/gif "access plus 20 days"
ExpiresByType image/png "access plus 20 days"
ExpiresByType image/bmp "access plus 20 days"
ExpiresByType image/x-icon "access plus 20 days"
# The following will modify the Cache Control Header on the WAS content be have the Public attribute and to become stale in intermediate caches after 36001 seconds
# Further, it will force IE to check the server after 18002 seconds (5 hours) to see if an update is available.
# Also, note that if you are using HTTPS (SSL), only "public" content (content with the cache-control header public) is cachable on the browser.
Header append Cache-Control "public, s-maxage=36001, post-check=18002"
As an aside, note that for some reason, WAS currently does not set the mime type correctly for .png files. To resolve this, add ".png" to the virtual host via the WAS Admin Console.
Note: Apache "Expires" will not overwrite an already existing Expires header. So, if you write a custom WebSphere "FileServingServlet", for example, that places an "Expires: 0" header on all the content, regardless of type, then Apache can't really help you. You should take care in WebSphere code to place an appropriate cache control header on your response to insure that content stays in the browser cache as long as appropriate. Setting a cache-control that will allow content to be refreshed from the browser cache will greatly improve overall system performance on highly utilized sites.
I'm afraid the following decision tree slightly over-simplifies the process of determining what application integration technique should be chosen for WebSphere Portal. It is not meant to be the "gospel" by which all integration techniques are decided. Instead, it should serve as a guide for the types of information that needs to be factored into the decision making process. (This blog post is a continuation of the previous post, where the integration techniques are described in detail.)
The questions below are posited in order. If I believe the answer to a question leads to a certain integration technique, I will say so. Otherwise, I'll direct you to the next question.
After reading through the questions, it may seem odd at first that I lead with NOT starting with portlets, but I found it easier to eliminate the lower fidelity, less elegant solutions first than to try to arrive at the decision to run everyting as a portlet first. There are just too many advantages to using portlets to enumerate as a series of discrete questions, where as there are very few questions that can help you eliminate portlets outright. Hopefully this will make sense to you as you work your way through the list below. Let's get started:
- Will the application remain as an external Web application using some technology that does not easily lend itself to being projected as a remote portlet (via WSRP), or is an application made of several parts that would be very difficult to decompose into portlets (remote or local) and reassembled on the Portal back into the application itself? (The answer can be different based on tactical versus strategic needs, as the decisions made here are not necessarily permanent ones. Also consider that just because the existing technology may not be portlet based, this does not mean that the technology cannot be projected as a remote portlet. Several competitors and IBM business partners offer techniques and technologies for either fronting existing Web applications with or converting them to portlets or WSRP producers.) If so, then proceed to the next question. If no, proceed to question #5.
- Do you have control over the application, to the extent that you can alter aspects of its presentation (such as removing navigational elements, banners, footers, etc)? If so, proceed to the next question. If not, proceed to question #4.
- Will the end user's browser have access to ("see") the application? If so, then IFRAMEs may be the way to go, since you can alter the application to render without redundant navigational or site-level decorations. If not, then Web Clipping, or similar technology, is probably the way to go, since WebSphere Portal must act as the reverse proxy, granting access to the backend web application through requests to the Portal itself.
- You don't have the ability to refactor the site, so site level federation is probably the best way to go. This is manifested as a combination of similar styling (hopefully) between the Portal and the backend app, as well as proper single sign-on linkage between the sites, such that the user's experience of moving from Portal to this external site is as smooth as possible. Tools such as Web Application Integrator (see Portal Catalog) can make this better, as elements of WebSphere Portal itself can be projected into the other application, further making it appear as if it belongs with, or appears to be part of, WebSphere Portal.
- Will this application provide data or services to other applications besides WebSphere Portal? Or are you only after the data from this existing Web application, and not so much its user interface? If so, on either account, then refactoring the application into a Web Service is probably in order. Both RAD and Portlet Factory can quickly and easily help you build a portlet that consumes and renders the Web Service. If not, then proceed to the next question.
- If you are at this point, then the application is most likely destined to become a portlet application. Now we just need to decide if you are going to run it locally or remotely. If you are concerned about the stability or weight (higher than usual CPU or memory requirements) of the portlet, then you are better off running it remotely in a light weight WSRP producer where it can be isolated and scaled independently from the consuming Portal. If you are not so concerned about the portlet, then proceed to the next question.
- If the owner of the portlet is concerned about governance and process issues related to having to distribute the portlet through a central portal management team, then allowing the portlet owner to have their own WSRP producer, where they can own the portlet's entire lifecycle, is probably the best approach. If there are no such concerns, then proceed to the next question.
- Is this portlet application a part of a series of portlets that together make up a composite application, where the user's application is actually a series of portlets and pages that act in concert to provide a unified application experience, AND will it be likely that this composite application will be used in several different portal contexts, OR do you have concerns that this composite application may put high demands on memory and CPU? If so, then you may want to consider dedicating a portal instance, or cluster, to host this composite application and federate this portal with the main portal. This is similar in concept to site-level federation described in question #4, except that we are talking multiple portal's here, so there is great potential for reuse of themes, skins, CSS, and other portal and J2EE artifacts that make the transition between portals much more seamless. If this is not the case, the move on to the next question.
- Well, this one isn't really a question as much as a conclusion. With all other options eliminated, we are left with a portlet, or series of portlets in a composite application, that is running in the local portal. Congratulations, since this is the easiest route by far.