Plan for the Portal Personalization Server

Plan for the Personalization Server

You might want to use the Personalization rules engine in an environment outside of WebSphere Portal.
For example, we could use Personalization in a Web service that provides a personalized XML content stream. Alternatively, we could use it to generate an RSS feed. In these cases, Personalization is used as a service that is consumed by other software components on other servers.
When portlet rendering is not required, such as when the output of a service is an XML or RSS feed, deploying the Personalization rules engine in an environment outside of WebSphere Portal is an efficient alternative to administering an installation of the portal. The servlet that receives the publishing request can also run outside of WebSphere Portal. With the exception of pznwpsruntime.jar, which includes the WebSphere Portal user resource collection, all the Personalization runtime libraries can run separately from WebSphere Portal. Publishing to a server that does not have WebSphere Portal installed is no different than publishing to a server where WebSphere Portal is installed.
Personalization no longer has an independent administrative or authoring database. Personalization uses the IBM Java Content Repository for storage of rules, campaigns, and other objects both during the authoring phase and runtime phase. We can install the repository, which stores the rules and campaigns, outside of WebSphere Portal. In this configuration, the Java Content Repository does not use WebSphere Portal Access Control, nor does it use the federated LDAP service of the portal.
The only components that are not installed when running outside of a WebSphere Portal environment are the Personalization portlets, including the authoring portlets and the Personalized List portlet. As a consequence, once artifacts are published to a Personalization rules engine without WebSphere Portal installed, there is no way to view those artifacts directly on that system. You need a WebSphere Portal installation, either a test environment installation or a full WebSphere Portal installation, in order to author rules and campaigns.
Two optional functions of Personalization require the use of a database.

The Feedback function uses a database to store logged information. The amount of database space that is required for logging depends on the amount of traffic to the site. The amount of data logged per login-enabled page can vary.

The LikeMinds recommendation engine uses a database to store information gathered through the logging APIs. LikeMinds uses this information to make recommendations of user affinities and interests.

T deploy a Personalization Server, consider the following facts:
There should be a WebSphere Portal installation on the same machine as the Personalization Server, but the portal server does not have to be up and running. You update the Personalization Server by updating WebSphere Portal.
You do not need to install Personalization databases. When you install WebSphere Portal, an Apache Derby database is created. The Personalization Server should be installed before WebSphere Portal is switched to database management system other than Derby. When using the database-transfer task to switch to any other database management system, refer to the database transfer instructions of WebSphere Portal, but run the database-transfer task .
./ConfigPzn.sh -DparentProperties=WP_PROFILE/ConfigEngine/pzn.properties
               -DSaveParentProperties=false database-transfer 
               -DTransferDomainList=jcr,feedback,likeminds 
You do not need to configure the LikeMinds recommendation engine because it is configured by default when you install WebSphere Portal.

Because the stand-alone Personalization Server cannot use the federated LDAP services of WebSphere Portal, set up LDAP security for the Personalization Server in IBM WAS.
Parent: Set up a Personalization server on WAS
Next: Install a stand-alone Personalization Server