Topology Manager forms the bridge between the Content Manager and Content Delivery environments. By decoupling the two environments, it becomes easy to swap out environments on either side, and to separate concerns by specific roles in your organization.
Topology Manager maps logical publishing targets selected by the end user to physical publishing destinations on the presentation environments. Because Topology Manager is a separate software component from Content Manager, it makes it easy for you to extend the delivery environment to include mode endpoints, or to move your delivery environment into the Cloud.
Topology Manager has no clients or APIs, only a database. The user interface consists of a number of PowerShell cmdlets.
Topology Manager concepts
Use Topology Manager to communicate information between a Content Manager environment on the one hand, and one or more Content Delivery environments on the other hand.
At the most basic level, each publishable Publication in Content Manager maps to a Web application. Multiple Publications can map to the same Web application. Each Web application is part of a Web site, and is represented by an ID and a context URL (relative to the Web site’s base URL).
A Web site has an ID and a base URL. One Web site contains one or more Web applications.
Content Delivery environment
A Content Delivery environment, identified by an ID, and accessible through a Discovery Endpoint URL and a set of credentials, represents a number of Content Delivery Capabilities and a collection of one or more Web sites, hosted on one or more Presentation Servers.
Every Content Delivery environment has a Purpose. A Content Delivery environment’s Purpose makes clear to what end the environment is being used.
For example, an environment with a Purpose called “Staging” is intended to be used as a staging environment; an environment with a Purpose called “Live” is intended to be used as a live environment.
A Topology defines a complete publishing environment: it consists of a set of Content Delivery environments, each with a distinct Purpose. A Topology is a concrete instance of a Topology Type. 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.
A Topology Type is a list of Purposes, that is, a list of the types of environment you can publish to. 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”.
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. Put simply, 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 and contains a number of Target Types (as many as the Topology Type has Purposes). Each publishable Publication must have one and exactly one Business Process Type associated with it.
Target Types are the items that the end user selects when publishing (or unpublishing) content. Each Target Type has a Purpose. Target Types would typically be named after their Purpose, so they would be “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.
# Create Topology Type EnvironmentPurposes : Define Staging and Live Target. Add-TtmCdTopologyType -ID DemoTopologyType -Name "Demo Topology Type" -EnvironmentPurposes @("Staging", "Live") # Create Content Delivery Environment ( Staging ) Add-TtmCdEnvironment -ID DemoStagingCdEnvironment -DiscoveryEndpointUrl https://localhost:8082/discovery.svc -EnvironmentPurpose Staging -AuthenticationType OAuth -ClientId cmuser -ClientSecret '******' # Create Content Delivery Environment ( Live ) Please make sure the dicovery port is different if you are running on the same machine Add-TtmCdEnvironment -ID DemoLiveCdEnvironment -DiscoveryEndpointUrl https://localhost:8082/discovery.svc -EnvironmentPurpose Live -AuthenticationType OAuth -ClientId cmuser -ClientSecret '*****' # Create Topology Add-TtmCdTopology -Id DemoTopologyType -Name "Demo Topology" -CdTopologyTypeId DemoTopologyType -CdEnvironmentIds @("DemoStagingCdEnvironment", "DemoLiveCdEnvironment") # Create Website Add-TtmWebsite -Id Staging_Website -CdEnvironmentId DemoStagingCdEnvironment-Baseurls @("https://demo.staging.com") Add-TtmWebsite -Id Live_Website -CdEnvironmentId DemoLiveCdEnvironment-Baseurls @("https://demo.live.com") # Create Mapping Add-TtmMapping -Id EN_STAGING_Mapping -PublicationID "tcm:0-40-1" -WebApplicationId DemoStaging_Website_RootWebApp -RelativeUrl /en; Add-TtmMapping -Id ES_STAGING_Mapping -PublicationID "tcm:0-41-1" -WebApplicationId DemoStaging_Website_RootWebApp -RelativeUrl /es;