1. Developing with Oracle Content Management As a Headless CMS
  2. Get Started
  3. Key Concepts
  4. Publishing and Channels

Publishing and Channels

Publishing content is the act of making that content available to clients. It means that the content is accessible from delivery APIs in read-only form. Publishing is a copy operation—that is, users can freely change an asset after publishing without affecting the client.

A channel is a logical entity to which a publishing operation is initiated.

The act of publishing involves three key elements:

  1. The actual assets that are being published
  2. The channel to which the assets are being published
  3. The policies that govern the publishing operation

Publishing

Any asset that’s managed in an asset repository can be published to one or more channels. Once published, content is available to the delivery API in read-only form.

It’s important to note that even though published content retains the same identifier as managed content, a published asset is essentially a copy (or snapshot) of the managed asset. This means that after a piece of content has been published, it can continue to change in the management context, but those changes are not reflected in the published entity until the content is republished.

Publishing assets involves dependency management at its core. One of the key tenets of publishing is to never cause broken links in the published content. Say there is a blog asset that’s published. If that asset has references to an image or other assets, then these must also be published along with the blog asset. This ensures that the published content is always self-contained and complete.

Publishing always carries delta data only since the last publishing operation to the same channel. If a referenced asset is already published to the same channel, then only the originating asset is published. This is the case even if the referenced asset has changed since the last publishing operation. This way each asset can have its own change management life cycle, while referential integrity is maintained at the same time.

Channels

Channels are logical entities to which content can be published. Channels can be thought of as containers for configuration and policies related to publishing content.

Channels can be public or secure. Public channels allow access to published content by any user. They are intended primarily for use in applications such as public websites and apps.

Secure channels allow content access only to users who are logged in. Secure channels are intended for use in more closed contexts, such as intranets, employee portals, and secure applications.

Each channel has a channel token that a client must present to get access to published content. The token can show up either as a query parameter or as an http header. This token is not an encrypted entity (that is, it does not represent secure or shared knowledge between a client and server); it’s merely an identifier of the channel.

Policies

Policies control the nature of the validation process that happens before assets are published.

There are two kinds of policies:

  • Workflow policies—A channel can be configured to accept any published content or only approved published content. In some situations, it might be necessary to safeguard against inadvertent publishing of content that might not be ready. A workflow policy helps ensure that each asset that ultimately gets published, either directly or indirectly (through a reference), is explicitly approved by an approving authority.
  • Language policies—There might be situations where the publishing of content requires translations of that content to be published at the same time. For example, there might be legal requirements to publish content in a set of languages and ensure that each translation is up to date and published together with the other translations. A language policy ensures that such constraints can be met and safeguards against accidental publication of content without the required language translations. Language policies are managed as a separate configuration set and assigned to a channel. See Multilingual Content for further details.

Publishing Process

Publishing involves a number of steps. It’s useful to look at this from a flow perspective to understand how and when policies come into play.

Publishing starts with the user initiating a publish operation, either for a single asset or a set of assets. The first step in the publishing process is to gather all necessary assets for publication. This involves recursively walking through the content relationships to gather all unpublished related content.

Once all content to be published is gathered, a verification step happens to ensure that workflow policies, language policies, user rights, and so on are all validated.

After the content and the required publication permissions have been validated, the content is actually published, which basically creates a copy of the content. All published content is stored safely so that no broken links exist in published content. Once the publishing process is complete, the delivery API would be able to serve clients with the newly published content.

Learn More...