AVON Magnolia

Architecture Overview

Products, Badges, Trainings, and other types of content like blog posts, process explanations, and segmented content have to be put in a data storage repository. The analysis of current applications determined that Magnolia would be a good application to centralize all the content creation and exposed it through its API.
Multisite??
MySQL is a pretty good alternative to use as database server with Magnolia instances, since it doesn’t require licenses costs and actually no real data will be consumed by anonymous users (it will be served by a caching layer).

No business logic will live in Magnolia CMS. The main goal for this content repository strategy is to unify all the content loading in a well-known tool and use it only to feed other systems.
Although Magnolia will store products information, different instances of Magnolia will be used on different markets, this will allow not only to organize better, which products are available on each market, but to reduce the risk of conflicts and errors across markets.
Translation native features.
Magnolia is proposed to replace all content repositories and across different markets.
A Proxy layer (ESB??) will be necessary to provide the same content structure to the service layer while the migrations into Magnolia are being made in markets that do not use Magnolia yet.

The proposed stack for this system would be: Node.js with an Oracle database to store the training results. The user interface to create training flows could be build using Angular.js and Boostrap. The training information is stored in Magnolia and will be retrieved using its API.

The proposed stack for this system would be: Node.js with an Oracle database to store the training results. The user interface to create training flows could be build using Angular.js and Boostrap. The training information is stored in Magnolia and will be retrieved using its API.

By Helbert Rico