Syndication overview

Syndication is the method used by IBM® Web Content Manager to replicate data from a web content library on one server to a web content library on another server.

To enable syndication, a syndicator and a 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.
Note: Before running syndication, you must ensure that your subscriber has sufficient disc space to receive the data being syndicated from the syndicator. For example, if you are going to syndicate all libraries, then you will need at least as much space on your subscriber as the database used by your syndicator.

Syndication Relationships

The relationship between a syndicator and a subscriber can be either a one-way or two-way relationship.

Example: One-way syndication
Application 1 syndicates one or more libraries to Application 2, and Application 2 subscribes from Application 1.
Application 1 syndicates one or more libraries to Application 2, and Application 2 subscribes from Application 1.
Example: Two-way syndication
Both applications syndicate to each other, and both applications subscribe from each other.
Note:
  • When enabling two-way syndication, you must first establish the syndication relationship from Application 1 to Application 2. Once the libraries have been replicated to Application 2, you can set up the syndication relationship between Application 2 and Application 1.
  • When using two-way syndication, all-item syndication must be enabled for each library that exists on both servers.
  • Although it is possible to set up more than one syndication relationship between the same two applications, there is no reason to do so. The additional syndication relationships are not required because once a syndication relationship has been established between two applications, no further relationships are established.

Syndicators can syndicate libraries to multiple subscribers, and subscribers can subscribe to libraries from multiple syndicators.

Example: Multiple syndication relationships
Application 1 and Application 2 both syndicate to Application 3, and Application 3 subscribes from both Application 1 and Application 2.

Syndication methods

There are three syndication methods available when configuring a syndication relationship:
Live items:
Live item syndication is mostly used when syndicating to a staging or delivery server. The following items are syndicated:
  • Published
  • Expired
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:
  • Published
  • Expired
  • Projects
  • 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:
  • Published
  • Expired
  • Projects
  • Draft items in a project
  • Other draft items
  • Versions
  • Deleted items
Switching from "all item" syndication to "live item" syndication: When you switch from "all item" syndication to "live and projects" syndication or "live item" syndication, any drafts previously syndicated to the subscriber are not removed.
Moving draft items between libraries: If you move a draft item from a library using "all item" syndication to a library using "live item" syndication, the draft item will also be moved on the subscriber because the action occurred on the library using "all item" syndication. This behavior allows for some draft items to be included in a subscriber library even though "live item" syndication is being used.

Release and version consistency

All servers participating in syndication must be of the same release for syndication to work as expected and to be in a supported state. Syndication is supported from earlier versions to newer versions of the same release. Syndication is not supported between different releases.

For example:
  • Server A with version 8.0.0.0 can be syndicated to Server B with version 8.0.0.1 installed.
  • Server A with version 8.0.0.0 can be syndicated to Server B with version 8.0.1 installed.
  • Syndicating Server A with version 6.1.5 to Server B with version 8.0.0.0 installed is not supported.
  • Syndicating Server A with version 8.0.0.0 to Server B with version 7.0.0.1 installed is not supported.
  • Syndicating Server A with version 8.0.0.1 to Server B with version 8.0.0.0 installed is not supported.

It is also recommended to keep your environments consistent across all servers in your system. For example, the same version of WebSphere® Application Server must be used on all servers in your system to ensure successful syndication.

Web content libraries and syndication relationships

All the items you work with as part of your Web Content Manager authoring environment (templates, components, content items, and so on) are stored in web content libraries. When you syndicate data between applications, you do so on a library by library basis. As part of the definition of a syndicator or subscriber, you specify which web content libraries are to be included during syndication.

Because syndication is performed by library, it is important to consider how to organize your content between libraries to support your Web Content Manager environment. For example, suppose you are using a single authoring server to develop content for two delivery servers, an intranet site providing Human Resources information intended for internal employees of a company and an external Internet site providing marketing material intended for customers and others outside the company. A basic approach to support this environment would be to use two web content libraries, one for content specific to each site. You would then set up two syndication relationships with each going from the authoring server to the appropriate delivery server.

For easier management, you might divide your content further into three libraries, where one library contains data common to both the intranet and Internet sites and the other two libraries contain site-specific content. The following example demonstrates this configuration, with the addition of two other authoring portlets so that the content of each library is maintained by a different authoring portlet.
Example diagram showing syndication of multiple libraries
In this case you might set up several syndication relationships between the authoring server and the delivery servers:
  • The Common Library syndicates to the intranet site (Human Resources Portal).
  • The Common Library syndicates to the Internet site (Marketing Portal).
  • The HR Library syndicates to the intranet site (Human Resources Portal).
  • The Marketing Library syndicates to the Internet site (Marketing Portal).
Note: Web Content Manager provides flexibility in how you set up your syndication relationships. If you need to syndicate multiple libraries from one server to another, you can choose to use one syndication relationship that includes all the libraries, or you can choose to use separate syndication relationships for each library, or even a combination of both approaches, depending on how many libraries you are syndicating. The best approach for your situation depends not only on how many libraries are involved but also on how the libraries are related to one another. For example, you use a single syndication relationship for libraries that reference each other, as when one library contains design items like templates that are used by content in the other library. However, if the libraries are independent of one another and you think you might want to suspend syndication of one library but not the other, separate syndication relationships for each library can provide that.
Important:
  • First-time syndication to an existing library is not supported. If you attempt to syndicate a library to a subscriber that already has a library with the same name, an error results.
  • Information about a Library is only syndicated the first time syndication occurs and not on subsequent updates and rebuilds. If a library is renamed or library user access is changed, this information is not syndicated to the Subscriber. If you change the name of a library or change user access to a library, you must manually make the same changes to any subscriber libraries if you want the same settings on all your syndicated libraries.
  • If content from one library (Library A) uses an item from another library (Library B), you must include both libraries in the syndicator to ensure that all items are syndicated successfully. If you only include Library A in the syndicator, any items in Library A that reference items in Library B are not syndicated, and syndication errors are generated.
  • If you add a new library to a syndicator after the initial syndication, you click Update to force the new library to be syndicated immediately.

Access control when syndicating

Although syndication can be used to keep data current between libraries on different servers, access control settings for the libraries are not included as part of syndication. Depending on how your environment is set up and what policies you have in place for library access, there are additional considerations for access control when using syndication.
User consistency
For user level access to remain consistent between the syndicator and subscriber, both servers must be configured to use the same user repository. If different user repositories are used, syndication will occur but there will be errors in the subscriber log indicating missing users. If access controls are determined by only using virtual users and groups, such as "All authenticated" and "Anonymous Users", then there is no need to use the same user repository on the syndicator and subscriber.
First time syndication on a new library
Because library access control settings are not syndicated, you must manually set access permissions on the subscriber's library when syndicating for the first time. If the library does not exist on the subscriber, it will be created during syndication. By default, no access control settings are specified on the new library, so you must set them manually before users can access content in the new library. The settings on the subscriber library do not have to match those on the syndicator library. This allows you to specify different levels of access for users and groups on the subscriber.