Every digital content you provide it’s going to be presented in certain context. In eCommerce world it’s usually a product or categories, campaigns, personalized pages etc. Once a page/view is called the main application should be able to call the CMS with the specific context. On the other side the content system needs to be able to reference the right content based on the given context. A very simple way of getting the content is shown in the following image. Everything that is needed is contained in the CMS and the query criteria is fully satisfied.
In many cases to provide the right content the content system requires additional data which resides in other systems. In this case we have to provide new integration services. Additional calls can be made to get the needed data.
The external API must be available during authoring time and render time. Because of the different user needs these services have specific capabilities depending of the user.
Integration challenges
Authoring Services
On CMS side the author would like to search, query and reference data coming from the eCommerce platform for example the prices, product information, categories… It’s recommended to keep the references to the external data “with” the created content. Always try to use as less references as possible. The references should be reliable and in best case without need to be maintained and synchronized. The services need to offer search functionality and be responsive for user friendlier UI. Here are the recommended characteristics for the services offering information from PIM, pricing … to the content system during author process:
| Speed | Scalability | Real-time data | Rich data service | Searchable |
|---|---|---|---|---|
Please note that the scalability value is relative to the runtime services. In any case you should be able to support all your authors and editors. Looking at the numbers during the author process you have extremely less users comparing to the number of public users. The point here is to provide all the necessary data (rich data) in short time (search) to the author. It makes the authoring process easier and less error prone.
Rendertime Services
During render time the referenced data gets called and rendered with the provided content. So you’ll need to plan how the services will be consumed and combined with the internal content data.
These services are helpful also when you need to have more logic on the content selection. Like relations between products, categories … should not be saved in the CMS. Using this data, you can provide delivery of content based on rules. For example: Show the complementary promotions related to the current product category.
| Speed | Scalability | Real-time data | Rich data service | Searchable |
|---|---|---|---|---|
As you can see the main characteristics that are required are speed and scalability. We can trade off the “real time” data for cached data and gain more speed.
Two in one
To cut the effort and serve all cases it’s logical to look for a way to have one service used in render and authoring time. When we need simple set of data based on single reference then we can concentrate more on the application layer for the speed and scalability.
In cases where we need to serve rich data with complex search criteria then you have to go deeper in the use cases and be good in making the right decisions on the infrastructure, deployment, data structures, storage system, messaging, API exposition and many more. It doesn’t sound easy and it should not. This kind of services are the core of the system integration effort. If you get them right you can soon concentrate on the business features.