• Save
Iwwcm 20 Syndication 0207081
Upcoming SlideShare
Loading in...5

Iwwcm 20 Syndication 0207081






Total Views
Views on SlideShare
Embed Views



2 Embeds 9

http://www.slideshare.net 7
http://www.linkedin.com 2



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Iwwcm 20 Syndication 0207081 Iwwcm 20 Syndication 0207081 Presentation Transcript

  • 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 © 2007 IBM Corporation 3
  • 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. © 2007 IBM Corporation 4
  • 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.. © 2007 IBM Corporation 5
  • 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 © 2007 IBM Corporation 6
  • IBM Software Group Setting Up Syndication © 2007 IBM Corporation
  • 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 © 2007 IBM Corporation 8
  • 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) © 2007 IBM Corporation 9
  • 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. © 2007 IBM Corporation 10
  • 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 © 2007 IBM Corporation 11
  • 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. © 2007 IBM Corporation 12
  • 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 © 2007 IBM Corporation 13
  • IBM Software Group How it Works JCR © 2007 IBM Corporation
  • 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 © 2007 IBM Corporation 15
  • 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. © 2007 IBM Corporation 16
  • 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) © 2007 IBM Corporation 17
  • W PL C How Syndication Works 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) © 2007 IBM Corporation 18
  • W PL C How Syndication Works 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) © 2007 IBM Corporation 19
  • W PL C How Syndication Works 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) © 2007 IBM Corporation 20
  • 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 © 2007 IBM Corporation 21
  • 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 © 2007 IBM Corporation 22
  • 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. © 2007 IBM Corporation 23
  • 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. © 2007 IBM Corporation 24
  • W PL C How it works: Syndication between Clusters Load balance / sprayer 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) © 2007 IBM Corporation 25
  • W PL C How it works: Syndication between Clusters Load balance / sprayer Load balance / sprayer Rendering cluster Authoring cluster 3. Cluster member found updates, so it sends an JCR DB update package. JCR DB © 2007 IBM Corporation 26
  • W PL C How it works: Syndication between Clusters Load balance / sprayer Load balance / sprayer 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. © 2007 IBM Corporation 27
  • IBM Software Group Considerations and Best Practices © 2007 IBM Corporation
  • 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. © 2007 IBM Corporation 29
  • 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 © 2007 IBM Corporation 30
  • 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. © 2007 IBM Corporation 31
  • 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> © 2007 IBM Corporation 32
  • 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 © 2007 IBM Corporation 33
  • 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 ● 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. © 2007 IBM Corporation 34
  • 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 © 2007 IBM Corporation 35
  • 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. © 2007 IBM Corporation 36
  • 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. © 2007 IBM Corporation 37
  • 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 © 2007 IBM Corporation 38
  • 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 © 2007 IBM Corporation 39
  • IBM Software Group Troubleshooting © 2007 IBM Corporation
  • 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 © 2007 IBM Corporation 41
  • 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 © 2007 IBM Corporation 42
  • 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 © 2007 IBM Corporation 43
  • 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 © 2007 IBM Corporation 44
  • 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 © 2007 IBM Corporation 45
  • W PL C Thank You © 2007 IBM Corporation 46