Publishing Personalization rules

Portal server supports the ability to author rules and campaigns on one system and publish them to other systems. System where rule is authored is called authoring system and system where rules are published is called run time system. When you author rules using Personalization Navigator + Personalization Editor portlets those rules get stored in the JCR database repository. At the time of executing these rules you need two things first is Java libraries to execute the rule as well as access to the JCR database where these rules are stored.

The process of publishing rules from authoring system to run-time system is a two step process, first you export the rules from authoring system into an xml file and then you import that xml file on the target system. Please note that the XML file that contains the personalization rules in not xmlaccess file instead it has different format. Take a look at the sample file on my machine


As you can see this file is not a regular .xml file instead it has some binary data. So it is not possible to create an xml file manually and import it on run-time system to create rules. Instead you will have to author the rules on one system and follow export + import system

Publishing rules

WebSphere Portal Personalization sends published objects across HTTP to a servlet which resides on each personalization server. This servlet can receive publishing data or initiate new publishing jobs. When a user begins a publishing job from the personalization authoring environment, the local servlet is provided with the set of information necessary to complete the job. The local servlet contacts the destination endpoint servlet (which could be the same servlet) and sends its data to it. The destination servlet reports success or failure.

To begin publishing personalization objects, you create an object in the authoring environment which describes the target endpoint.The server requires one field, which is the URL associated with the publish servlet for that endpoint. The publish server may also define which workspace will receive publishing data. Personalization operates in the default Content Manager run-time edition workspace after installation. If the target workspace field is empty, then the publish server uses the default workspace. (You need to set the workspace field if you are configuring scenario three described above.)

The last option is whether or not to delete remote objects that have been deleted on the local system. The default is Smart Delete, which simply removes items that are no longer present. If you do not have delete permission on the remote server you could select the Leave deleted resources on server option.

After you create a publish server, you can publish either the entire workspace or a set of objects within it. You specify either of these options by selecting the More Actions > Publish submenu




The Publish page displays what will be published. This page requires the user to choose a destination publish server and any necessary authentication information. If the remote system is secured and is not a member of the current server’s Single Sign-On domain you can enter a user name and password in the provided fields. The values for user and password are stored in the WebSphere Portal credential vault and are not accessible to any other user.Click Publish to launch the publish job.If the local system is able to locate and authenticate with the remote publish server, you are returned to the main navigator view, and you see the Personalization message EJPVP20001I at the top of the portlet. Then, the publish job runs as a background process on the local server. Click the View the details of this job link to open the publish status window to see information about the progress and success or failure of the publish job.