While syndication is a vital part of keeping the web content current, the same syndication strategy is not appropriate for every environment. Depending on how we have deployed Web Content Manager, use different syndication strategies to balance the currency of the content with the performance the environment requires.
There are several different means to manage how and when content is replicated to other servers. It is important to note that, as with any process, syndication entails a performance cost, and this should be taken into account when specifying not only the frequency of syndication but also the number of syndication relationships for any given server.
The syndication interval controls the frequency of syndication while automatic syndication is enabled and can be used by administrators to put a cap on how often syndication occurs. Because up-to-date information is important to any web content environment, automatic syndication is enabled by default when IBM WebSphere Portal is installed. While the default setting for the syndication interval ensures maximum currency, we can choose to adjust the value accordingly if the currency demands of the environment do not call for the shortest interval.
Here are some general guidelines for setting the syndication interval.
Interval setting Recommended environments 10 minutes - 2 hours Staging servers to delivery servers. 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.
- Live items:
- Live item syndication is mostly used when syndicating to a staging or delivery server. The following items are syndicated:
Draft items, projects and items in a project are not syndicated.
- Live and projects:
- The advantage of using "Live and projects" syndication is to gradually syndicate projects to a staging or delivery server rather that waiting to syndicate all the items in a project after they all achieve a published state. The following items are syndicated:
- Draft items in a project
Draft items outside of projects are not syndicated.
- All items:
- All item syndication is mostly used when syndicating between servers within an authoring environment. The following items are syndicated:
- Draft items in a project
- Other draft items
- Deleted items
It is not necessary to wait for the syndication interval to elapse in order to perform syndication. Manual syndication can be used at any time to cause syndication to occur immediately. There are different ways to take advantage of manual syndication:
- Use manual syndication in conjunction with the syndication interval to provide flexibility. For example, if we are using an increased syndication interval to optimize performance between servers, we can still perform manual syndication when we need to update content without waiting for the next syndication.
- If we require complete control of when syndication occurs, use manual syndication as the only means of performing syndication. For this approach, disable automatic syndication so the syndication interval setting is ignored.
Publish and expire dates
Because the syndication interval is not based on a scheduled time of the day, it is not suitable for setting up syndication to run during off-peak times. The publish date and expire date are the preferred methods for doing this.
The publish date for each content item specifies the date and time when the content should be published to a website. After a content item is approved and the publish date is reached, the content item is queued for syndication according to the next syndication interval. By using the publish date, we can delay the publishing of content, effectively delaying its syndication. For example, if we are using a short syndication interval to ensure timely replication of most content, we can delay the syndication of less urgent content through the publish date for that content.
The expire date specifies the date and time when the content item should be removed from a website. As with the publish date, use the expire date to cause the syndication activity associated with removing the content to occur at a time when other syndication activity is less intensive.
For more information on the publish and expire dates in the workflow process, refer to Item status.
Syndicating large librariesWhen syndicating large libraries, we may also need to adjust these timeout settings:
- Log in to the WAS console and click...
Servers | Server Types | WebSphere application servers | portal_server | Container Services | Transaction Service
- Change the total transaction lifetime timeout and the maximum transaction timeout settings to 2000 seconds.