Publishing considerations | HCL Digital Experience

Clusters

Publishing to or from a clustered environment requires no special configuration. The specific cluster member that does 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 is as current as possible.

When you first used the Personalization authoring portlets on a cluster to publish objects, the Publish Status dialog shows information only about the publish jobs initiated on that cluster member. The Publish Status dialog is accessed through More Actions > Publish > View Status. To make all publishing jobs visible, set the pzn.publishServlet.url parameter 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 10039, and the default port number for HTTPS is 10042.

IPv6 hosts

The IPv6 protocol stack must be installed and available in the server that initiates the publish command. When publishing from the command line by using pznload to an IPv6 host, you might 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

You use resource collections in Personalization to access SQL Server, LDAP, IBM Content Manager, the Portal user object, or other custom sources of data.

The DB2 Content Manager runtime edition and the HCL 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 SQL and LDAP resources, Rational Application Developer provides a wizard to generate classes that 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 that belong to the collection. If the resource collection classes are not found by the rule editor, you might see the following message in a JavaScript alert.

The resource collection classes must also exist on the class path of the application to start the Personalization rules. The Personalization rules engine finds the resource collection classes by using the class path of the application, which starts the rules. If you 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 must be accessible to both the rule editor and the personalized application. An application server shared library is the easiest way to provide this access. You can configure the shared library by 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.