Iwwcm 20 Syndication 0207081

IBM Software Group

IBM Workplace Web
Content Management
Syndication
David Rosenfeld
Consulting IT Specialist

It’s not magic!

© 2007 IBM Corporation

W PL
C
Credits
● The majority of this content was drawn from three documents:

 Understanding syndication in IBM Workplace Web Content Management
http://www.ibm.com/developerworks/workplace/library/wwcm-syndication

 Best Practices for using IBM Workplace Web Content Management V6.0 http://www.ibm.com/
developerworks/websphere/library/techarticles/0701_devos/0701_devos.html

 Advanced Training Course – David de Vos’ slide show on Syndication

● Thank you to Sander van Veluw, David De Vos and Melissa Howarth for their
publications.
● Also thank you to Roger Leuckie for proofing this
content, and providing a multitude of helpful suggestions.
● I take full responsibility for the silly pictures.

© 2007 IBM Corporation 2

W PL
C
Agenda

● What is Syndication
● How to Set up Syndication
● How Syndication Works
● Syndication Considerations
● Best Practices
● Syndication Performance
● Troubleshooting


W PL
C
Syndication - Definition

● Syndication is the mechanism used to replicate data from one instance of W eb
Content Management to another
● Syndication only replicates W CM data (site areas, components, content, etc.)
and not configuration (portal, subscriber, syndicator), allowing for the different
servers to be configured for different tasks.
● Syndication can either replicate all W CM items or only those that are published.
● Syndication is performed on a library by library basis
● A W CM server can be configured as a Syndicator
(send W CM items/content), a Subscriber (receive
W CM items/content), or both (“two-way” syndication)
● Syndication is not clustering.


W PL
C
The Need for Multiple WCM Servers

● Customers are always going to require multiple WCM Servers.
Even simple installations will use one ‘Authoring’ Server and one ‘Delivery’ Server,
in order to maximize performance and provide redundancy.
For large enterprise customers its also common to have a “Testing” Server and a
“Development” Server
Other WCM Servers might also be introduced to carry out specialized tasks, such
as a “Backup” Server or a “Pre-Rendering” Server

● While all these servers are used for different tasks, they all require
their own version of the WCM data, which must be kept up to date…
And that is what Syndication is for..


W PL
C
Syndication and Library Partitioning
Site 1
Delivery
Authoring WAS 6.0
WP 6.0
Syndicator for Site 1:
WAS 6.0
• Site 1 library WCM
WP 6.0
• Shared library 6.0

WCM
6.0

Site 2
JCR Repository
Delivery
WAS 6.0 Site 1 Shared
Syndicator for Site 2:
Library Library
WP 6.0
• Site 2 library
JCR Repository
• Shared library
Site 1 Site 2 WCM
Library Library 6.0
Shared
Library

JCR Repository
Site 2 Shared
Library Library


IBM Software Group

Setting Up Syndication


W PL
C
Setting up Syndication

● Syndication management portlets are located in
Portal Administration (W eb Content->Syndicator)
● A syndicator and subscriber must be defined:
The syndicator defines a connection to the subscriber
and indicates which libraries are to be replicated to the
subscriber
The subscriber defines a connection to the syndicator
and receives the data replicated from the libraries
specified by the syndicator

● The Syndicator designates which libraries are to be
syndicated


W PL
C
Setting up Syndication (Cont’)
● Syndication of multiple libraries on a server will all use the same interval setting
 NOTE: The interval setting is server-wide and applies to all syndicators defined on a particular server

● Library access control settings are not included as part of syndication
 Access permissions are not set on the subscriber's library when syndicating for the first time.

● W hen using multiple libraries with W orkplace W eb Content Management v6, if a
library contains references to another library then both libraries need to be
included in the one Syndicator. This is to avoid referential integrity problems.
● W hen setting up Syndication, you need to decide which items will be syndicated
to the other W CM instance by selecting an Item Gatherer. There are two Item
Gatherer’s available:
 All Items: Syndicates every object in the System (including version objects)
 All Live Items: Syndicates published content and non-workflowed content only (doesn’t include
versions)


W PL
C
Syndication – Creation of Syndicator/Subscriber Pair
1. Open two browser windows, one
each for new Syndicator and new
Subscriber from their respective
servers (Portal Administration).
2. Copy Syndicator name, ID and URL
to Subscriber, and vice-versa.
3. Save Syndicator first, before saving
Subscriber.


W PL
C
Syndication Scheduling
● By default, syndication is automatic and will be initiated every 30 seconds
● The syndication interval can be adjusted
 Unlike previous versions of Workplace Web Content Management, changing this setting to
a large value will not cause Syndication to never occur.
 Syndication interval settings apply to all syndicators on the server
 Syndication cannot be scheduled at particular times of day, but can be initiated manually

Update Rebuil
d


W PL
C
Syndication Scheduling (cont’)
● The frequency of syndication can be controlled via the ‘ItemChangedTaskDelay’
setting in <WPS_ROOT>wcmsharedappconfigwcmservicesWCMConfigServices.properties.

● Recommended syndication interval settings (from InfoCenter):
Interval setting Recommended environments

30 seconds – 10 minutes Any environment that requires frequent replication, such as an authoring server to a staging server, a test server, or
distributed authoring server. When increasing the syndication interval for environments where authoring servers are
involved, be mindful that timely replication is often essential, particularly in collaborative authoring environments
where multiple authors on different servers might be working on the same content.
10 minutes – 2 hours Staging servers to delivery servers.

● If only manual syndication is desired, then set ‘connect.moduleconfig.syndication.inittasks’
to false in the above mentioned properties file.
 Syndication is then only possible by manually initiating it from the Syndicator and
Subscriber Administration Portlets.
 NOTE: This manual syndication setting will apply at a server-wide level. So ALL
syndicators on that server will need to be initiated manually.


W PL
C
Monitoring Syndication Progress
● Determining when Syndication will start next:
 To determine when Syndication will next start, add the value of the
‘deployment.itemChangedTaskDelay’ setting in WCMConfigService.properties (default 30
secs) to the ‘Finish Date’ of the last syndication
 To check whether a Syndicator has changed since its last syndication with the Subscriber,
check the ‘State’ field in both the Syndicator and Subscriber. If the Syndicator’s ‘state’ field is
higher than the Subscriber, then it indicates that the Syndicator has changed and that
Syndication will occur soon

● Once Syndication has started:
 Once Syndication has started, you can monitor its progress by looking at the <WPS_ROOT>
wcmilwwcmsystemsubscriber<SUBSCRIBER-ICE-ID> directory on the subscriber machine
 As items are being retrieved from the Syndicator, this directory will grow (to the size indicated
by the ‘Updates Sent’ field on the Syndicator/Subscriber form)
 Once all items are retrieved, they will start to be saved within the subscriber’s repository. As
each item is saved, its removed from the above directory
 Once the directory reaches zero items, any item deletions are processed before the final
cleanup routines are run


IBM Software Group

How it Works

JCR


W PL
C
ICE Protocol
● IW WCM Syndication is based on the Information and Content Exchange (ICE)
protocol, an XML-based protocol using HTTP as its transport mechanism.
 The supplier, or syndicator, acts as a master.
 Changes in the syndicator dataset are packaged and sent to the consumer, or subscriber.
 The subscriber receives the package, and after validation, applies the changes to its own dataset.

● The syndicator assembles the XML Document (payload) that is consumed by the
subscriber

● The administrator, authors or users can not modify or tune how the payloads or packages are managed


W PL
C
ICE Protocol (cont’)
● The actual Transfer of data is handled through packages
 Packages are a kind of wrapper around the actual data containing identifiers and instructions.
● The subscriber maintains a collection that
contains the packages received over time
 Packages are then processed in the order
specified by the syndicator.
● The state of the subscriber’s collection is described by an identifier.
 Packages received from the syndicator contain two sequence identifiers.
– The first describes collection state before applying a package (old state).
– The second describes the collection state after applying a package (new state).

● The subscriber will apply a package only if the state of it’s collection matches the old state id
● The subscriber applies the new state ID if all instructions specified in the package succeed.
 If one of these fails, all instructions that have already been carried out are reversed.
● There are two “special” states:
 ICE-INITIAL: The null state of the subscriber before any ICE operations have occurred
 ICE-ANY: Old state of a package, which may be applied regardless of the state of the subscriber’s
collection. ICE-ANY updates the subscriber’s entire collection to the newest state, regardless of the
subscriber’s current state.


W PL
C
How Syndication Works

JCR
2
User creates/
updates 1
content or design
3

Event
Authoring Server
Log DB
(Syndicator)

W hen an item is updated or saved (1),
the item is saved in the JCR repository
AND it is logged in(2) Event Log database
the
(3)


W PL
C

Authoring Server (Syndicator)

4
Event
5
Log DB
ItemChangedTask

PackageGenerator

Periodically, the ItemChangedTask queries the EventLog for any updates (4).
If changes are detected, it initiates a Syndication via the Package Generator
(5)


W PL
C

Publishing Server (Subscriber) Authoring Server (Syndicator)

Event
Log DB
ItemChangedTask

7 6
PackageProcessor PackageGenerator

The PackageGenerator then generates a new package using the EventLog
database (6) and sends it to the Subscriber (7)


W PL
C

Publishing Server (Subscriber) Authoring Server (Syndicator)

Event
Log DB
ItemChangedTask

PackageProcessor PackageGenerator
JCR
10
8
ItemDispatcher

JCR
9

Once the PackageProcessor receives a package, it starts making requests to
the Syndicator’s ItemDispatcher to obtain the updated documents (8). As each
item is requested, its fetched from the JCR database (9) and sent back to the
PackageProcessor which stores it in its repository (10)


W PL
C
How it works: Rebuild Vs Update

● Automatic syndication always does an ‘Update’
● W hen syndicating manually you can choose between ‘Rebuild’ or
‘Update’:

Rebuild: Performs a “Full Update” which involves sending all

documents that currently exist in the Syndicator to the Subscriber. The
Subscriber will then store all documents that are sent, and if any
documents remain that were not sent through from the Syndicator,
then they are removed.

Update: Performs a “Partial Update” which involves querying the state

of the Subscriber and then state of the Syndicator. It will then
determine what documents need to be sent and deletion notices
issued to update the Subscriber so that it is in the same state as the
Syndicator


W PL
C
How it works: Handling References
● The JCR does not allow invalid references to be added on a save.
● This is a problem if an item contains a reference to something that’s coming
later in the package.
● Before adding a document, the Syndication engine will iterate through all of
the document’s references. If a reference is not found in the repository, the
reference is either cleared or replaced with a dummy node reference so that
the document can be saved.
● In a second pass (after adding all the items in the repository), the references
are restored to their original values.

My Menu
Sample reference
case:
Selected Site
Area

My Site Area


W PL
C
How it works: Handling Versions
● Unlike previous versions of W CM, versions in the JCR are not part of
a document in the repository. They are entirely separate documents.
● Syndication handles versions in the case when ALL items are
syndicated from one place to another.
● For any given item (even deleted ones) with versions, the syndication
engine “replays” the creation of versions on the subscriber side.
For example, document A contains versions 1, 2, 3. When the document
is processed, version 1 is retrieved first and placed in the list of documents
to ADD. Then versions 2 and 3 are placed in the list of documents to
UPDATE. At the end of the process, the net result should be that
document A also exists on the subscriber with versions 1, 2 and 3.
● Versions of items are retrieved individually as separate documents.
The URL that the Syndication engine uses to retrieve a document
includes the version number.


W PL
C
How it works: Handling Item Failures

● W henever an update fails on the subscriber for any
reason, the Syndication engine sends a request to
the ItemDispatcher to mark an item as failed.

● Marking an item as failed means updating the item’s state in the
event log so that it’s included in the next package that gets
syndicated.

● As long as an item fails to update, syndication will continue to
attempt updating it.


W PL
C
How it works: Syndication between Clusters

Load balance / sprayer


Rendering cluster

Authoring cluster

2. Some cluster member
wakes up and checks for
JCR DB
pending changes to
syndicate

(Note: any number of JCR DB
cluster nodes might do this
at the same time, but some
locks are set to ensure only
one server ever actually
tries to publish at once)


W PL
C



Rendering cluster

Authoring cluster

3. Cluster member found
updates, so it sends an
JCR DB
update package.

JCR DB


W PL
C



Rendering cluster

Authoring cluster 4. Some cluster member
receives the update
package. It retrieves each
item via the authoring
JCR DB
cluster and persists it.
Dynacache invalidation
notices are sent to other
JCR DB cluster members through
dynamic replication
services (DRS).

FAILOVER: If a rendering node is in the middle of syndicating some changes and it goes down, then
the syndication will be considered failed and will be re-tried by the next rendering node. If an authoring
node goes down during syndication, then the syndication will continue using the next available authoring
node.


IBM Software Group

Considerations and
Best Practices


W PL
C
Syndication Considerations
● You cannot syndicate to a pre-existing library with the same name as the
source library.
 “Web Content” library is created in each server by default. Although the libraries have the same
name on different servers, they have different UUIDs. That means that in order to syndicate the
“Web Content” library from one server to another, the library must be either deleted or renamed on
the subscriber server.

● An item will fail to syndicate if an item it references has been deleted (but not
purged) on the subscriber machine
 Solution: Purge the deletion and rebuild the subscription so that the deleted item is resent

● An item will fail to syndicate if an item with the same name and same site path
has been created on the subscriber machine (the items will have different ids)
 Solution: Delete or rename the duplicate item on the subscriber machine

● You can’t syndicate between different versions of W CM nor use it to upgrade
from one version/build of W CM to another
● W hen performing two-way Syndication, both Syndicator’s must syndicate all
Libraries using the ‘All Items’ scope or else Syndication will not work
correctly.


W PL
C
Syndication Considerations (cont’)
● Ensure that items are not locked on the subscriber as this will cause items to not
update
● JSPs must be moved separately
 Syndication will not move the JSP page referred to in a JSP Component. Only the JSP Component
itself is moved. You will need to store a JSP page on both the Subscribing and Syndicating servers.
● Search Collections are not syndicated
 Solution: search collections must be created on both servers first before syndication.

● Do not enable workflow on W orkflows, W orkflow Stages or W orkflow Actions.
 Workflow enabled on workflows, stages, and actions will cause problems in syndication.

● Inline editing should only be used in authoring environments
 For traditional projects with both authoring and rendering environments, it’s recommended that Inline
Authoring be only used on the authoring server. If Inline editing is used on the rendering server then it
will require two-way syndication back to the authoring server and can result in syndication conflicts.

● Portal Document Manager and Personalization are not syndicated by W CM
 See next slide


W PL
C
Syndication of PDM Documents & PZN Rules
● Syndication does not extend to documents and rules that may be referenced in
W eb Content Management Document Manager and Personalization
components. These documents and/or rules must be transferred or published
before syndicating the content.
● One way of ensuring PDM documents and PZN rules are published first is:
 1. Create all PDM and PZN Components in a separate Library called quot;External Componentsquot; Library.
 Note: If you are already using ‘All Live Items’ to syndicate the library that contains the rest of your
components, then a separate library isn’t necessary
 2. Enable workflow on all components (see “Authoring Options” section of InfoCenter)
 3. Use a Web Content Management workflow with a workflow stage that enables your components to
be created in a Draft state initially.
 4. Create a Syndicator/Subscriber pair. Select your quot;External Componentsquot; library in the Syndicator
 Select All Live Item as your Item gatherer in your Syndicator.
 5. Refer to the InfoCenter topics 'Staging a document library to Production‘ and/or “Staging
Personalization rules to Production” to transfer your PDM documents and/or PZN rules.
 6. Approve your WCM components in the draft stage, as the transfer/publish process of the PDM
documents and/or PZN rules complete successfully.


W PL
C
Servlet Rendering (Dynacache) Consideration
An additional ‘Component’ section should be included in every cachespec.xml to
disable caching for W CM Utility modules and Syndication. Failure to do this will re-
sult in Syndication and various W CM Utility modules not functioning as expected:
<cache-id>
…Normal ‘component’ sections describing what to cache…

<component id=quot;M ODquot; type=quot;parameterquot;>
<required>false</required>
<not-value>Subs</not-value>
<not-value>Synd</not-value>
<not-value>ItemDispatcher</not-value>
<not-value>Syndication</not-value>
<not-value>M emberFixer</not-value>
<not-value>VersioningEnablement</not-value>
<not-value>WorkflowEnablement</not-value>
<not-value>PlutoUploadFile</not-value>
<not-value>PlutoDownloadFile</not-value>
<not-value>AJPECatSelect</not-value>
<not-value>RefreshAllItems</not-value>
<not-value>Template</not-value>
</component>
</cache-id>


W PL
C
Strategies for handling large initial syndications
● After migrating from a previous release OR as part of rolling a new
site into production, you could have a large initial syndication on
your hands
One way of handling this is do a backup of the JCR database (at
●
the database level) on the Syndicator and restore it to the
Subscriber.
Once the W CM library(s) have been transferred in this matter
●
than the initial syndication will be much quicker

NOTE: It is recommended that you re-tune the WCM database after importing
libraries. See the WCM v6 Best Practices guide for details


W PL
C
Best Practices – General – Related to Syndication
● Split content across multiple delivery servers using library syndication
Sites may be authored in one place, and then deployed to multiple delivery
environments
It is also best practice to create a separate library for design components used
across sites
● Virtual Portals hosted on the same Portal Server – there is no need for
syndication. Note that multiple realms are supported by W CM as of Version
6.0.1.2.
● Check the users on the production LDAP
 Ensure that no test users have been left on the production LDAP that someone
could hack into the system with. This includes user and password combinations that
are common or easy to guess like Mickey Mouse/password and wpsadmin/
wpsadmin or wpsadmin/password.


W PL
C
Reminders/Best Practices
● Manually set library access control settings after first time syndication or
subsequent changes
 Library access permissions are not syndicated. If the library does not exist on the subscriber, it will be
created during syndication but no access control settings are specified on the new library
 On rendering servers you might want to specify different access control settings, to say disallow content
entry for all users

● Syndicate just the Live Items when syndicating to the production server
 Unless there is a specific need to have all objects on the production environment (eg circular syndication
scenario where content may be authored directly in production), All Item syndication should not be
required.

● Syndicate all required libraries
 If content in library A references a component in library B then both library A and B need to included in
the one syndicator.

● Syndicator and subscriber should always be the same version. Also, check
fixpacks and interim fixes. See the ‘Recommended Fixes’ Technote for W CM:
 http://www-1.ibm.com/support/docview.wss?rs=1041&uid=swg21260790


W PL
C
Reminders/Best Practices (cont’)
● Ensure that the W CM database is tuned before and after the initial syndication
 See WCM Best Practices Guide, p. 44

● Consider using host names for syndication between non-cluster members
 Although the documentation says to use IP addresses in the subscriber/syndicator dialogs, host names
might be more useful because you can you add host aliases to redirect the traffic. Be sure though that
whatever you use matches what has been used in the configuration file.

● W hen Syndicating between clusters, utilize the web server address of each cluster
in the Syndicator and Subscriber dialogs to ensure that proper failover occurs
● Avoid editing items in multiple environments
 As Syndication uses the last modified date to determine whether an item should be overridden and
doesn’t have the ability to merge different changes to the one item, if an item is edited in multiple
environments, then the last change will take effect, causing the previous change to be lost.


W PL
C
Reminders/Best Practices (cont’)
● W hen performing two-way Syndication, don’t configure any of the Syndicator’s to
syndicate any W eb Content Management Libraries using the ‘Live Items’ scope
 For two-way Syndication, both Syndicator’s must syndicate all Libraries using the ‘All Items’ scope or
else Syndication will not work correctly.
 For example, the following scenario will fail unless both servers use ‘All Items’ for all Libraries:
– Draft doc on server1 is sent to server2 via ‘All Items’ syndication. Draft doc is published on
server2. Attempt to send Published doc on server2 to server1 via ‘Live Items’ syndication fails
because the existing draft isn't being removed first.


W PL
C
Syndication performance
● Increase the default syndication frequency of 30 seconds
for servers that don’t require frequent syndication.
 Take care not to space the intervals TOO far apart,
10 to 30 minutes is a good range.

● Don’t enable a syndicator on the production server
 Set the subscriber.only property to “true” in WCMConfigServices.properties
 This stops the monitoring task from running on the IWWCM instance that tracks object changes for later
syndication to another server.
 Whenever the subscriber.only setting is changed, also reset the EventLog (<WPS_ROOT>config
WPSConfig wcm-reset-event-log) before restarting the server

● Avoid having too many Subscribers (>5) linked to the one Syndicator
 Create a tiered syndication structure, e.g. the first syndicator syndicates to two servers and those
servers further syndicate onto the rest.
 This improves performance because you are decreasing the load on the syndicator server.

● Consider disabling ‘Versioning’ for all items on both authoring and rendering
servers
 If storing previous versions of items isn’t required, then disabling this feature can improve performance
of saving and syndication


W PL
C
Different LDAP servers across environments (for reference)
● While a single LDAP server that all Portal/ WCM servers access is recommended, if that single LDAP server
becomes overworked OR if the customer’s security policies dictate, then multiple LDAP servers may be
necessary.
● By default, each instance of Portal allocates each LDAP user a unique Member ID (WMM ID) when security is
enabled.
● As WCM references users both by distinguished name and the WMM ID (from the server that the content was
originally created on), care must be taken when using multiple LDAPs or else WCM authentication will break
when data is syndicated from one server to another.
● The following additional scenarios highlight cases where Web Content Management security will fail:
 If you have two or more WCM instances pointing to two different LDAP servers, even if these LDAP servers have the same users
within
 If you have two or more WCM instances without security enabled trying to syndicate between each other
 It must be noted that the above two configurations are neither expected nor supported by WebSphere Portal. Portal expects sharing of
a central LDAP repository across instances. However, there are several solutions that may alleviate or remedy these and similar
problems.
● Possible Solutions:
 1. Use the same LDAP for all environments that Web Content Management is syndicating over.
 2. Remap the WMM External ID to an unique LDAP attribute (such as the distinguished name of a user or another unique attribute on
each user record)
 3. Set up ser access on the server with Web Content Management/WPS virtual groups like All Users, Anonymous, All Authenticated
Portal Users. What this means is that for all environments, the customer can set access on objects using the [All Users] group and
Anonymous access or any other virtual group as the entry is not stored in WMM / LDAP. So, if you want to have user A, B and C
develop in one WCM instance, but not have access to objects in the second instance, you could give access to the virtual group and
then the security would be retained. If you adopt this solution, you may still want to run the WCM Member Fixer to clean up the data as
you will see a lot of warning in the logs. The limitation to this solution is that it will ONLY work for Virtual Users/Groups as these are not
stored in WMM. Any user/group definition stored in WMM/LDAP will not work.
 4. Ensure that all user/groups and their unique id's are synced across all the LDAP servers that are a part of the Web Content
Management syndication scenario.
 This can be achieved by exporting LDAP ldif files and/or maintaining some kind of LDAP replication across servers
 5. Run the Web Content Management Member Fixer on the Subscriber server at regular intervals or after each syndication event.
 Not recommended, as it introduces a mandatory manual process


IBM Software Group

Troubleshooting


W PL
C
Syndication Status/Troubleshooting
● The detailed view in the syndication session displays the details on the subscriber and
syndicator (Name, ID, and URL).
● The partners in the subscription are in sync if the new state of the subscriber matches the
new state of the syndicator.
 If syndication fails (can be checked in the Result field), the two state fields indicate the values that they
should have been, not the actual value.

● Other messages can be found in the system.out log files in <portal_server_root>/log folder
● Solutions for some error conditions are listed in the infocenter: http://publib.boulder.ibm.com/infocenter/wpdoc/
v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wcm/wcm_syndication_troubleshooting.html


W PL
C
Troubleshooting Tips
● Verify that syndicator / subscriber pair are created properly.
● The subscriber URL should be accessible from the syndicator machine, and
vice versa.
● Ensure that network communication is not blocked by firewalls, VPN’s, etc.
Ensure that W CM server parameters are correctly designated in
●
W ebSphere.
WCMConfigServices.properties includes parameters which are satisfied by the WebSphere

server to locate the actual address of a WCM server
● In the case where syndication is not happening automatically:
1. Check whether syndication tasks are running. This is easy to do from the command line using
the WAS EJBTimer command:
 ./findEJBTimers.sh WebSphere_Portal –all –username
<uname> -password <password>
 Look for a task called ‘ItemChangedTask’
2. Enable tracing of the ItemChangedTask:
 com.aptrix.deployment.itemgatherer.*=all


W PL
C
Troubleshooting Tips (Cont’)
● In case items are not getting updated correctly on the subscriber:
 Look at the logs. Syndication errors on the subscriber will usually be generated by
the PackageProcessor. The easiest way to find if there are any of those is to do a
grep for ‘PackageProcessor’
 Enable tracing on the PackageProcessor
 Enable tracing on the ItemDispatcher (syndicator side)
 Also verify that the items aren’t locked on the subscriber, as this can cause them
to be not updated

● To compare a Syndicator and
Subscriber:
 Utilize the WCM API to write a jsp page
that produces a report showing the names
and counts of each type of WCM object
(Authoring Template, Content etc)
 Run the jsp page on both the Syndicator
and Subscriber and compare the results


W PL
C
Troubleshooting Tips (Cont’)
● To enable tracing just for the current WebSphere Portal session, do the following:
 Go to Administration > WebSphere Portal > Portal Analysis > Enable Tracing >
 Enter any of the following in the Append these trace settings field:
 com.ibm.workplace.wcm.*
 com.aptrix.*
 com.presence.*
● For example, to trace all events, enter the following:
 com.ibm.workplace.wcm.*=all:com.aptrix.*=all:com.presence.*=all
● To enable tracing permanently, or to find a list of all the specific traceable attributes, refer to
the infocenter: http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wcm/wcm_logs.html
● In order of importance, here are the most common trace strings you’ll need for syndication
 PackageProcessor
 com.aptrix.deployment.subscriber.PackageProcessor=all
 ItemDispatcher
 com.aptrix.deployment.syndicator.ItemDispatcher=all
 PackageGenerator
 com.aptrix.deployment.syndicator.PackageGenerator=all
 EventLog Database
 com.ibm.workplace.wcm.services.eventlog.*=all


W PL
C
Resources
● IBM WebSphere Portal Version 6.x Information Center
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp

● Understanding syndication in IBM Workplace Web Content Management
http://www.ibm.com/developerworks/workplace/library/wwcm-syndication/

● Best Practices for using IBM Workplace Web Content Management V6.0 http://www.ibm.com/developerworks/
websphere/library/techarticles/0701_devos/0701_devos.html

● Using WebSphere Dynamic Cache Service with IBM Workplace Web Content Management
http://www.ibm.com/developerworks/workplace/library/dynamic-cache-wcm/

● Web Content Management resources page
http://www.ibm.com/developerworks/workplace/products/webcontentmanagement/

● IDEAlliance Inc. ICE specification Web site
http://www.icestandard.org/specification/

● World Wide Web Consortium's NOTE-ice-19981026 page
http://www.w3.org/TR/1998/NOTE-ice-19981026

● IBM Technote #1242955, quot;Syndication does not work if WebSphere Application Server dynacache enabledquot;
http://www.ibm.com/support/docview.wss?rs=899&uid=swg21242955


W PL
C

Thank You


Iwwcm 20 Syndication 0207081

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Iwwcm 20 Syndication 0207081

Similaire à Iwwcm 20 Syndication 0207081 (20)

Iwwcm 20 Syndication 0207081