Publish considerations
If we are publishing personalization rules in a clustered server configuration, to an IPv6 host, or using Web Content resource collection classes, there are unique considerations that you should be familiar with.Clusters
Publish to or from a clustered environment requires no special configuration. The specific cluster member that will perform the publishing task is chosen by the same rules that apply to incoming Web requests (because the publishing mechanism uses HTTP messages). At the end of a successful publishing job, Personalization flushes its caches for that workspace to ensure that any subsequent personalized content will be as current as possible.
When you first used the Personalization authoring portlets on a cluster to publish objects, the Publish Status dialog (accessed through More Actions > Publish > View Status) only shows information about the publish jobs initiated on that cluster member. To make all publishing jobs visible, set the pzn.publishServlet.url parameter described previously to be a specific cluster member. Set the URL to point to a single machine at the internal HTTP port: The default port number for HTTP is 10040, and the default port number for HTTPS is 10035.
For example, supposed the cluster head is visible at http://intranet.yourco.com, and the cluster members are accessible at http://intranet01.yourco.com and http://intranet02.yourco.com. If set the publish servlet URL parameter to http://intranet01.yourco.com:10040/wps/pznpublish/pznpublishservlet you force all publishing requests to run on this single machine.
Publish to a single node in the cluster as opposed to the cluster head, making sure you do not pass through a Web server.
IPv6 hosts
The server which initiates the publish command must have the IPv6 protocol stack installed and available. When publishing from the command line using pznload to an IPv6 host, you may need to set the system environment variable IBM_JAVA_OPTIONS to a value of -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true on the system where pznload is run.
Resource collection classes
We use resource collections in Personalization to access LDAP, IBM Content Manager, the Portal user object, or other custom sources of data.
The DB2 Content Manager run-time edition and the WebSphere Portal user resource collection classes are installed in the Personalization shared library. Therefore, you do not need to move these classes between systems because they are already installed with Personalization.
For LDAP resources, Rational Application Developer provides a wizard to generate classes which implement the resource collection interfaces.
To use the authoring portlet, all resource collection classes must be in the class path of the Personalization authoring portlet. The rule editor uses these classes to display the list of attributes belonging to the collection. If the resource collection classes are not found by the rule editor, we could see the following message in a JavaScript alert.
Figure 1. Message displayed when resource classes cannot be found
The resource collection classes must also exist on the class path of the application invoking the Personalization rules. The Personalization rules engine finds the resource collection classes using the class path of the application which invokes the rules. If we use the Personalized List portlet to display rule results, this application is the Personalized List application pznruleportlet.war in the Personalization Lists.ear.
So, the classes should be accessible to both the rule editor and the personalized application. An application server shared library is the easiest way to accomplish this. We can configure the shared library using the WebSphere Integrated Solutions Console. For more information, see the sections on the shared library in the WebSphere Application Server Information Center.
You handle updates and additions to the resource collection classes just as you would handle updates to any application binary or JSP. These classes are not affected by Personalization publishing. The definition of the resource collection which Personalization uses to associate a resource collection with its classes is stored in the Content Manager repository. Initially represented by the .hrf file, this definition is published along with the rules and campaigns.
Parent: Publish personalization rules overview
Next topic: Publish personalization rules