Topology Manager mapping and relationships

Topology Manager maps logical publishing targets selected by the end user to physical publishing destinations on the presentation environments. Based on a based on a Publication's purpose and content, Topology Manager figures out the correct Content Delivery environment to publish to.

The following diagram illustrates the relationships between Topology Manager, Content Manager and Content Delivery entities:

Content Delivery

Web application and website

At the most basic level, each publishable Publication in Content Manager maps in Topology Manager to a web application. (1) In the example, there are two mapped publications, A and B, which map to two separate web applications.

Each web application is part of a website and is represented by an ID and a context URL (relative to the website's base URL).

It is possible to map multiple Publications to the same web application. Each website can contain one or more web applications.

Content Delivery environment

Each Content Delivery environment represents a number of Content Delivery capabilities and a collection of one or more websites, hosted on one or more Presentation Servers.

A web application points to the Discovery Service Endpoint URL(2) of a specific Content Delivery environment. The URL and a set of credentials provides access to the Content Delivery environment.

In a Topology (as defined in Topology Manager), there is also a Content Delivery environment entity, which points to the same Discovery Service Endpoint URL. (3)

Topology Manager

Purpose

Every Content Delivery environment entity in Topology Manager has a property to identify its to a Purpose (4). This is simply a label that defines the end purpose or use of the environment. For example, an environment two Purposes, one called "Staging" and another called "Live".

Topology Type

A Topology Type is simply a collection of Purposes. Content may pass through a number of environments before going live, depending on the publishing workflows your organization supports.

For example, for legally sensitive content, your organization may require one staging environment for editorial review, and another for legal review. This would result in a Topology Type with three Purposes: "Staging Editorial", "Staging Legal" and "Live".

At the same time, content that requires no legal review may require only one staging environment, which would entail another Topology Type, with only two Purposes: "Staging" and "Live".

Topology

A Topology is a concrete instance of a Topology Type (5) and represents of a set of Content Delivery environments, each with a distinct Purpose.

For example, given a Topology Type that defines two Purposes "Live" and "Staging", a Topology defines what the words "Live" and "Staging" actually stand for. The Topology must specify one Content Delivery environment for each of the Purposes defined in its Topology Type.

If your organization has multiple publishing environments, it will also have multiple Topologies. For example:
  • Your implementation supports different definitions for "Live" and "Staging" that depend on what is being published. For example, in some situations you may want to define "Staging" and "Live" as Content Delivery environments in the cloud, while in other situations "Staging" and "Live" might refer to on-premises Content Delivery environments. In this scenario, you would define one Topology Type that defines the Purposes "Staging" and "Live", and two Topologies, one used for on-premises publishing and another for cloud publishing.
  • Another example might be that, depending on regulatory concerns or to optimize performance, you want the servers associated with "Staging" and "Live" environments to reside in a specific geographic location. In this case, you would again have one Topology Type defining "Staging" and "Live", and any number of Topologies, one for each geographic location.

If you have multiple Topologies defined for a Topology Type, the mapping from the Publication to the web application determines which of the Topologies content gets published to.

Content Manager

Business Process Type

In Content Manager, a Business Process Type represents a number of settings that together define a certain type of business process in your organization. Simply put, it defines how content is allowed to flow through your organization, both while it is being managed and when it gets published.

In the context of publishing, a Business Process Type refers to a Topology Type (6) and contains a number of Target Types (as many as the Topology Type has Purposes).

Each Publication must have one and exactly one Business Process Type associated with it.

Target Type

Target Types are the items that the end user selects when publishing (or unpublishing) content. Each Target Type is associated with a Purpose (7) and are typically named after their Purpose, such as "Live" and "Staging".

Note that the physical location where the content will end up depends not only on the Target Type(s) selected, but also on the Publication from which the publish action takes place.

In the Business Process Type, Target Types can be given a Minimal Approval Status, meaning that publishing to that Target Type is impossible until it has reached at least the Approval Status specified; and they can be given higher or lower priority than the default, to accelerate publishing to a live environment when possible, or delay publishing to a staging environment when necessary. You can also restrict the ability to publish to a Target Type to a certain subset of your users.