Scaling out composition

A snapshot is a read-only copy of a published revision of all content in a project. Snapshots play a role in the content life cycle and allow instances to share a repository database which is useful when scaling out composition.

Communications Manager offers a number of operations on snapshots, such as:

• Creating a snapshot from a project.

  You can create a snapshot that contains the published revision of all content in the project at the moment of snapshot creation. Each newly created snapshot is identified by a new snapshot name and the name of the project from which it was created. For more information, refer to the CreateSnapshot.exe tool description.

• Viewing snapshot content.

  Communication Manager Designer displays snapshots in its repository next to projects. You can inspect the snapshot content, like you do a project, but you cannot edit a snapshot or assign a different status to its objects.

  Communication Manager Designer currently only supports viewing of snapshots. It does not support creation of snapshots, nor the registration of active snapshots, nor transferring snapshots. For these operations Communications Manager offers a number of server-side command line tools. For more information, refer to the following topic: Scaling out tools.

• Transferring a snapshot.

  You can export a snapshot from the repository database to disk and import a snapshot into the repository database from disk. This way you can move snapshots between different repository databases. Snapshots are always imported side-by-side: it is not possible to overwrite an existing snapshot in the repository database.

• Composing a snapshot template.

  The Contract Manager offers a dedicated CCMSnapshotComposition contract type for running compositions on a particular snapshot. This contract type offers similar functionality as the CCMInteractive contract type that operates on projects. For more information, refer to the CCMSnapshotComposition contract type topic in the Tungsten Communications Manager API Guide.

• Registering an active snapshot.

  Communications Manager allows to register one snapshot as the active snapshot within the set of available snapshots of each project. In combination with the CCMSnapshotComposition contract type, the active snapshot registration allows for transparent content updates in a number of advanced scenarios and helps to avoid any system downtime.

Secondary instances are special instances that can connect to a repository database that is already in use by other instances in order to provide an additional processing resource to perform compositions.

With snapshots you can handle different versions of the content in a way that is not possible with the publication workflow statuses.

• Each snapshot provides a consistent view of the entire published content of a project as it was at a certain point in time.

• The active snapshot registration offers a way to seamlessly switch to using newer content, but also to switch to a previous snapshot, should the need arise.

• By explicitly referring to a certain snapshots one can explicitly produce output of a certain snapshot version.

In order to make use of such features, you need to create a snapshot of a project when a particular milestone is reached. We recommend using meaningful snapshot names.

Traditionally, Communications Manager supports content life cycle management via the publication workflow statuses in the repository (in development, draft, accepted, published). This allows a single database to be used safely for both development, testing, and production.

Previously, if a customer wanted to have physically separated environments for development, test, acceptance, and publication, they would have to transfer complete projects between these environments. This would either involve downtime when overwriting existing projects, or it would require the application integration to be aware of side-by-side installation of new versions of a project.

Snapshots and the active snapshot registration offer a more streamlined solution. You can install new snapshots without any downtime in any environment, and the active snapshot registration allows an instantaneous switch without any involvement of the customer application.

Since a snapshot is read-only and only contains a single revision of an object, it is clear that each template in this snapshot always behaves the same for the same input, regardless on which environment it is run.

The introduction of snapshots and secondary instances simplifies the scaling out of your composition. If you have a basic installation with one instance per contract, you can follow these steps to scale your composition:

• Arrange as many extra servers as you need.

• Install a Contract Manager for the same contract on each server and configure them the same way that you configured your basic installation.

• Install a secondary instance on each server.

• Register each secondary instance on its local Contract Manager and connect it to the same repository database as the base installation.

Once you set this up, you need to make sure that a snapshot of the project that you needs to run compositions for is available. At that point you can request any of these servers to perform a composition on that snapshot. Note that all servers offer the same web service interface for the contract at hand and they all operate on the same content, so they are identical except for their machine address.

In order to make the most efficient use of multiple instances, you need to implement some form of load balancing. Communications Manager does not offer a load balancing component itself, but it supports 3rd party load balancing solutions.

For composition requests that do not build up any state in a session this is rather trivial. A load balancer can simply hand out such requests to any of the instances in the pool, based on its own metrics concerning machine load, since all servers offer the same web interface with the same functionality.

This already covers the important use case of running a large batch of non-interactive jobs, since each of these can be handled by a single independent composition request.

For requests that do build up state in a session, such as requests that prepare an interactive composition, it is important that related subsequent requests are handed out to the same server as the one that set up the session. For this purpose, any interface that returns a session id also returns a request handler id. This is a unique id that identifies the Contract Manager that handled a request. For more information, refer to the CCMSnapshotComposition contract type topic in the Tungsten Communications Manager API Guide.

If you use such session-bound functionality your application should take the returned request handler id and use it to add sufficient information to subsequent requests so that your load balancer knows where to send it. It depends on the chosen load balancing solution how to do this.