Guidance for Headless Content Management Design: Key Design Strategies for Headless Implementations of Oracle Content Management Cloud
By Courtney Dooley, Technical Architect
Oracle Content Management (OCM) is a robust tool that allows for content to be served to multiple third-party applications through publishing channels. This offers a single source content repository for all of your applications. When designing your content structure and architecture, there are very important things to keep in mind.
Architecture
Depending on the amount and types of content you need to store, and how it will support your applications, the number of OCM instances you will need may vary. For most headless implementations, OCM supports the application with business content. Two instances will suffice for that implementation: one instance for development and testing, and the second for production. In this architecture, the instances are independent and only development entities such as asset types, components, sites, or templates would be migrated from one instance to the other.
For headless implementations that serve most, if not all, of the content required by the application, three instances would be recommended. Independent instances for development, test/staging and production would move assets between the instances as well as development entities. To make the transfer of assets between instances simple, it is important to intelligently design the asset types and relations to allow flexibility while maintaining necessary dependencies.
Repository Structure
Each OCM instance can have multiple repositories. Contributors can have permissions to specific asset types or categorized assets within a single repository, but management permissions apply to all content within a repository. Multiple repositories allow different groups to manage different sets of content. When all content used to build an application is provided by OCM, there are assets used for UI design which would be managed by senior developers, and content provided by business users for news, blogs, events, or product information which is managed by marketing. As multiple repositories can publish content to a single channel, applications can access all content regardless of its repository.
A single asset once published to a channel, will provide the same content and data to all channels it has been published to. If asset changes need to be managed separately for each channel, multiple repositories should be used to keep assets independent for each application.
Asset Type Design
OCM offers many ways to link, categorize, tag, group and identify different sets of content with the same asset type. Developing multiple asset types with the same content structure does not offer any additional benefit and can negatively impact the implementation. Asset types should not be created to group assets, but to identify the type of data they contain.
When searching across asset types, content fields aren’t returned with the search results. If a single asset type is searched, content fields can be returned with the results. This reduces the number of API calls to get details for each asset being returned.
The fewer asset types you have, the easier maintenance and migration will be.
Related Assets
When creating a new asset type, it is easy to use the reference type field to link assets. This is typically used to link an image to a content item such as a news article.
These reference fields become a problem when any assets can be linked together using reference fields. Circular dependencies, where assets of the same type reference each other, can cause problems when migrating or changing content data. Indirect dependencies, where an asset is dependent on another asset that has dependencies to other assets, are difficult to manage.
Rather than using reference fields to link related assets, use taxonomy categorization to link the assets indirectly. AssetType field values as well as AssetTags can also be used to identify related assets. Reference fields should only be used if an asset type directly relies on a referenced asset for functional purposes. They should not be used for related content.
As you can see, OCM offers many ways to define, organize, categorize, and relate your content. Design decisions made early on can have a long-lasting impact on your maintenance and management of the environment. Contact us for more tips and tricks for Oracle Content Management Development: