Publishing subprocesses and flow

Publishing involves a number of subprocesses, each of which performs a specific task. Publishing is multi-threaded and facilitates distribution to multiple destinations, such as data centers, webservers and so on.

The following diagram shows the various stages of a publish action, from the moment a user selects the Publish button to the moment the visitor sees the published content:

  1. Initiating the publish flow— A user or an automated event triggers the publishing of an item. This action involves selecting items to publish and a Target Type. A Target Type represents a logical publishing target. Each Target Type corresponds to a Purpose in Topology Manager.
  2. Publish EngineThe Publish Engine interacts with Topology Manager to obtain mappings for the Publication, which includes instructions for where and how to send the content. It then generates Publish Transactions based on the selected Target Type and associated Purpose and puts them in the Publish Queue.
  3. Publish Queue—The Publish Queue holds Publish Transactions waiting to be picked up by the Publisher Service.
  4. Publisher ServiceThe Publisher Service performs the actual publishing of content in Tridion Sites. The Publisher performs the following steps when preparing an item for the Transport Service:
    Resolving
    After picking up a publish transaction from the Publisher Queue, the Publisher Service's Resolve Engine assembles the items to be published. Any item that is requested to be published may trigger the publishing of other items.
    Any item that is requested to be published may trigger the publishing of other items. For example, republishing a Component may trigger the republish of another Component that is referenced by the first one. Both regular Components and Multimedia Components can include links to other Components or Multimedia Components, and these links can be implemented using any of the following field types:
    • Component Link
    • Multimedia Link
    • Text, when defined to allow Rich Text Formatting (both component and multimedia)

    These fields can be part of the Component content (on the Design tab) or in metadata fields (on the Metadata Design tab).

    The Link Resolver Recursion Depth option enables you to set a system-wide recursion depth for resolving linked content items whenever you publish a Page, Component, Multimedia Component or Structure Group. For information on how you can configure this setting or even customize the resolving process, refer to the related topic.

    The resolving phase results in a list of resolved items, that is, items that are to be offered to the Transport Service together with the item(s) originally submitted for publishing. In Content Manager Explorer, you can see the list of resolved items in the list that appears when you select Show Items to Publish in the Publish dialog.

    Rendering

    With the legacy template-based publishing framework, the Publisher additionally renders the content. Rendering is the process of combining a content item and a template from Content Manager to produce rendered, publishable content. For example, combining a Component and a Component Template results in a Component Presentation, a rendered, publishable item.

    You can customize rendering by creating a .NET class that manipulates the publishable content. Typically, you would modify the rendering process itself by modifying your template, but a modification that should be made to all publishable content is easier done through a custom renderer.

    With the templateless, data-only publishing model, there is no rendering performed. The look and feel of content is removed from the template and done instead by the application that uses the published content, such as a website, mobile app or a kiosk display screen.
    Next, the Render Engine further processes the items, but the transformation depends on the publishing model.
    • With the legacy template-based publishing framework, the Render Engine combines the individual content items with the associated template to produce rendered, publishable content.
    • With the templateless, data-only publishing model, the items pass through the Render Engine, but no actual rendering occurs. The look and feel of content is removed from the template and done instead by the application that uses the published content, such as a website, mobile app or a kiosk display screen.

    Lastly, the Publisher Service interacts with Topology Manager to retrieve information about where and how to send the content and passes on the resulting Transport Package to the Transport Service.

  5. Transport ServiceThe Transport Service assembles items to be published (and any dependencies) into a Transport Package, which it then transports from Content Manager to the Content Deployer in the Content Delivery environment.
    Transport Service Senders are responsible for sending the Transport Package to one or more physical destinations. Senders must be configured in both of the following places:
    • In the cd_transport_conf.xml file as Sender elements
    • In Content Manager Explorer as Destinations of Publication Targets

    Before sending the package, the Transport Service requests the URL of Content Deployer from the Discovery Service and uses this URL to send Transport Packages to the Content Deployer Queue over an HTTP or HTTPS protocol.

  6. Content Deployer On the Content Delivery system, a Content Deployer receives and processes the Transport Package and then passes the processed content to the Storage Layer. The Content Deployer Queue holds the Transport Packages in a place where Content Deployer can pick them up (either a file system location or a JMS queue).
  7. Storage Layer—The publishing process is completed when the content arrives at the Storage Layer. The Storage Layer handles the storing and retrieving of data to and from the Content Data Store (a file system, relational database, or both). The Storage Layer is configurable so that you can store individual types of incoming items to different databases.
  8. Presentation Server—Content is made available to web applications users through Presentation Server. The process from this point depends on your specific implementation of Content Delivery and a Presentation Environment. In a typical website implementation, a visitor requests a URL of the website and the Presentation Server hosting the website starts the process of retrieving the content from storage. Refer to the Content Deployer implementation section for information on the various options for working with the published content.