How to get the most out of content commerce
Integrating a shop system with an enterprise CMS
Content marketing and storytelling are becoming increasingly important in e-commerce. However, the CMS capabilities of a shop system don’t always allow you to offer a true customer experience. And what’s more, implementation with the shop's own CMS functionalities often proves to be complex and inflexible. Considering this, it makes perfect sense to integrate the e-commerce capabilities of a shop system with the content capabilities of an effective enterprise CMS for a convergent shop solution. Sebastian Haftmann and Benjamin Fiebig from the Berlin-based IT company Neofonie describe the necessary steps by taking the example of an integration of Magnolia CMS and SAP Hybris.
Vertically integrating Magnolia CMS and SAP Hybris in 3 steps
Export/import is passé
Shop systems usually expand their software through horizontal integration via export/import and reproduction of data structures of the Product Information Management (PIM) in the CMS. Later changes in the e-commerce system often need to be transferred afterwards. Modern vertical architectures offer good solutions to avoid this effort and to achieve greater independence and flexibility. E-commerce giants like Amazon, Otto, and Zalando rely on a vertical system section for their complex online shops. As an example, Neofonie’s developers have realized this type of integration with Magnolia CMS (Magnolia) and SAP Hybris Commerce (Hybris).
From horizontal to vertical
In order to implement this, the entire system is divided into verticals according to identified functionalities. Each vertical represents an independent application that possesses its own front end (if necessary) and data storage. For the integration, data is exchanged via REST interfaces.
The “publishing” vertical, with Magnolia as its core, provides the shop’s web content (stages, imprint, terms and conditions, etc.). At the same time, the front end for the shop’s delivery is integrated, and layout and style as well as the shop website’s information structure are defined at this point. A web publishing team is usually responsible for managing this vertical in reality.
In the “commerce” vertical, product content management takes place with Hybris. The product data model, product catalog with all product attributes, and product media are entered into Hybris. Moreover, Hybris provides availability, shopping cart, and checkout functionalities. Commercially relevant data (product, price, and user data) can flow into Hybris from preceding CRM or ERP systems. In the ordering process too, Hybris is often just the first step of the process within more complex fulfillment systems outside of this prototypical view. This vertical is managed by a product management team.
Further shop functionalities outside of both of the core functionalities, such as a product search or an email service to handle the shop's email communication can be realized through additional verticals.
The verticals are packed into containers
In order to efficiently manage vertical services in both development and operation, especially with increasing complexity, setting up a container-supported infrastructure is recommended. The currently popular container technology Docker provides a versatile and flexible tool set for this, which allows the close interlocking of development and operation as well as a high degree of automation of the different processes involved.
For the vertical approach, all verticals of the entire system are “dockerized”, i.e.they are allocated to one or more Docker containers. The dockerization enables every application to own an individual and firmly defined runtime environment independent of the deployment environment. The dockerization of the monolithic architectures of Magnolia and Hybris also allows both applications to be used as services in a distributed microservice architecture. The individual vertical apps are technically integrated into the entire system with Docker Compose. This procedure and the content of all Docker containers is identical in every development step. It can therefore be developed and tested in live“ circumstances.
An additional advantage of Docker is the quick setup of automatized infrastructure processes with existing tools. Continuous integration and deployment of a staging or production environment can take place with GoCD, for example. Build and deployment pipelines can be designated for all components, which are then via commit hook on the master branch of the relevant component or manually activated. Agile procedures in software development are thereby optimally supported.
Functional integration creates usability
To provide a rudimentary shop,the verticals “commerce“ and “publishing“ in particular need to be functionally integrated with each other. Technically, this happens as follows:
Product contents including product media are managed by the product management in Hybris, meaning the vertical “commerce“. Shopping cart functionalities and order management fall under the technical responsibility of these verticals too. In order to make the named functions available to other services, REST interfaces were implemented in Hybris for shop functionalities such as product teasers, product detail pages, and shopping cart as well as checkout pages, which produce semantic (unstyled) HTML – if you will, as front end of the vertical “commerce“. This HTML is integrated into a generic frame of header and footer by Magnolia when rendering the relevant page, and thereby given a style according to shop design. On a page, the contents and functionalities of the vertical “commerce“ can then be combined as desired with editorial content from Magnolia.
The advantage of the integration of semantic HTML lies in the fact that Magnolia is completely agnostic concerning the resources delivered by Hybris. The vertical “commerce“, meaning the fictitious product management team, solely determines the content and structure of product content and “commerce“ functions without technical dependencies on the vertical “publishing“. Changes to the attributes of a product category or order of its presentation can be realized in Hybris and rolled out without Magnolia's involvement.
Aside from this visual REST integration with HTML as data format, further classic shop functionalities are realized through pure data exchange via REST/JSON integration. This includes shop functions such as the “Add to shopping cart“ button, the retrieval of the number of products in the shopping cart for the navigation display, and changing the number of products in the shopping cart. Here, Hybris is asked by AJAX directly from the front end. The data exchange format is JSON.
Editorial product teaser as a practical example
A practical example of a loose technical linking of different functionalities is the editorial addition of product teasers. In Magnolia's editorial system, meaning in the area of the vertical “publishing“, product teasers can be placed on any shop page. The web publishing team determines how many product teasers will be shown and how many products will receive teasers. The latter can be decided for every product teaser in a two-step selection dialog. The selection fields for product category and product in the dialog are asked about in the runtime via REST/JSON with Hybris. This guarantees that the web publishing team can always work on the current state of product data without having to wait for delivery (e.g. product data imports from Hybris in Magnolia) from the vertical “commerce“. After the selection in the dialog has been made, the appropriate product ID is stored. When the page is called up, the vertical “commerce“ then delivers the completed product tile to match the product ID.
An approach to separation of concerns
With the chosen approach of vertical integration, development, further development, and regular professional support, particularly the verticals „commerce“ and „publishing“ can easily be decoupled from one another, as well as the technical and organizational dependencies in terms of “separation of concerns“ which can be strongly reduced. The vertical “publishing“ takes over the front end integration of the different components from the verticals and thereby the delivery of the completed page.
All in all, higher independence and flexibility can be realized with the presented approach.
- Expandability: New aspects of an eCommerce solution (e.g. payment processing, tracking, etc.) can be independently developed as individual verticals, and modularly and agilely integrated via REST interfaces and the respective development tools (Mocks etc.).
- Adaptability: Changes to the product data model (e.g. new types, attributes) can be realized solely through development of the vertical “commerce“. Reversely, a front end makeover, in which layout and styling of the product presentation is changed, can only be realized in the vertical “publishing“. Adaptations to the entire system can be realized faster and at lower risk due to the extensive technical decoupling of the verticals.
- Flexibility: Due to the decoupling of the verticals and their integration with common standards, the suitable technology and approach can be selected for each vertical. The strong modularity of the system of a whole simplifies ”make or buy“ decisions and reduces the likelihood of vendor lock-ins. In connection with the aspect of high adaptability of the system, technological decisions can also be made or revised at a later point in the life cycle of the system as a whole.