Our Editor Cloud defines a clear separation of concerns in order to ensure conceptual consistency.
AEM remains responsible for the information architecture and is responsible for the technical publication of all articles. This ensures consistency in the content architecture and allows to keep concepts that are implemented in AEM such as Tagging. Since the articles are delivered through AEM Author and Publisher we guarantee consistency towards other system layers such as the caching solution.
Livingdocs is responsible for all content that is written in the Livingdocs Editor and all content related workflows such as reviews, proofreading and orchestration of collaboration with document history (time machine) and track changes. Optionally, the Livingdocs DAM can be used to manage images. This setup ensures consistency of content states, i.e. articles from AEM Author can not conflict with their counterparts in Livingdocs.
In order to realize this separation of concerns, certain functions are turned off in AEM Author, e.g. the ability to copy, delete or create articles can be disabled in AEM using standard ACL configurations. This guarantees that articles are only copied, deleted and created in Livingdocs and no conflicts arise.
This section is a bit technical and oriented towards AEM implementers. Feel free to skip to the final section.
All data flows are based on a JSON format. Both Livingdocs and AEM support JSON natively and JSON nicely integrates into the AEM underlying JCR data storage. Communication between Livingdocs and AEM Author is orchestrated via a service bus (Apache Kafka is our weapon of choice here) and ensures nothing is ever lost in transit as well as providing traceability and replicability.
The JSON that Livingdocs sends to AEM Author exactly matches the target JCR structure. Metadata is mapped to the respective JCR nodes of your existing AEM installation and the article itself is rendered in Livingdocs to HTML and provided to JCR as an html node. The example below visualizes a possible JCR structure exported from Livingdocs.
This minimizes dependencies between the two systems as AEM doesn’t need to have any knowledge of the Livingdocs specific data format.
Another topic are the URIs of articles. They are generated in Livingdocs and passed to AEM just like the rendered HTML article. The form of the URI follows a mutual pattern, usually the existing URI pattern used in AEM.
Authentication is solved using SSO enabling editors to have one login for both systems and easily navigate between Livingdocs and AEM without the need to re-authenticate.
1+1 makes 3
Using AEM together with Livingdocs gives you a whole new level of possibilities. Rather than just sticking to the abilities of one system you combine strengths and get a publishing solution on par with what large publishing houses are using.
Corporate communication is becoming ever more crucial as brands enter the information landscape and not only inform sales decisions but also public opinion and discussion, a realm previously assigned to the traditional mass media.
With great potentials, new challenges arise. Livingdocs and AEM give you the tools you need to tackle those challenges and enter the future of corporate communication.