jExperience architecture overview

Personalizing the customer experience is in every marketer’s mind and has a strong impact on customer data integration, across channels and applications. This overview helps developers and architects understand how they can use and extend jExperience and jCustomer to integrate customer data.

Overview

At a high level, a typical environment is composed of the following:

Jahia
An extensible customer digital experience platform that contains CMS, WCM, and portal features.
jExperience
An A/B testing and personalization solution that leverages the Jahia platform and integrates with jCustomer.
jCustomer
The core Customer Data Platform (CDP) engine. jCustomer stores and indexes customer data and events generated by visitors.
Elasticsearch
The backend storage, indexation and query server system that stores data in jCustomer. It is also highly scalable and offers high-availability mechanisms.

In a typical use case, when a visitor first opens a site, jExperience serves a Javascript tracker initialized with a context object. Once loaded in a page, the Javascript tracker provided by jExperience (called wem.js), will react to various user interactions and will send events to jCustomer via its REST API.

System Architecture

Although the diagram above provides a good overview of the data flow, the actual environment deployed for production is slightly more complex.

An install typically includes the following layers:

A reverse proxy
Deployed as a single node or a cluster, the reverse proxy faces the internet and exposes HTTPS endpoints proxying the requests to the internal Jahia and jCustomer nodes over HTTP(s
Jahia nodes
These are instances of the CMS with the jExperience modules deployed on them. These instances are deployed in clusters and constantly communicate with each other. Jahia communicates with jCustomer over HTTP(s).
jCustomer nodes
These are instances of the CDP, are deployed in clusters and constantly communicate with each other. jCustomer communicates with Elasticsearch over HTTP(s).
Elasticsearch nodes
The Elasticsearch nodes use the custom networking protocol specific to Elasticsearch to communicate between them.

Note: In the schema, arrows between groups of nodes indicate a relationship to each node. Arrows are not repeated to make the diagram easier to understand.

Ports and protocols

As shown in the above diagram, a collection of TCP ports is used by a typical jExperience installation. The following summary table lists the ports that need to be made available to ensure that jExperience and jCustomer works as expected.

Default Ports	Service	Reachable by	Description
8080	Jahia Public interface	Reverse Proxy	Jahia’s interface used to provide access to the website(s) and access to jExperience.
5700-5800	jCustomer Hazelcast	jCustomer nodes	Used by Apache Karaf Cellar to keep track of cluster nodes and exchange configuration information
8181	jCustomer Public interface	Reverse Proxy	jCustomer Public endpoint (exposed to the Internet) for event collection and context serving (for example profile, session, and segments)
9443	jCustomer Private interface	Jahia nodes	jCustomer Administration endpoint, used to manage all jCustomer objects (for example segments and profile editing), also the jCustomer secure address (Endpoint used in a secure environment)
8102	jCustomer Karaf console	Developers, Sys-Admins	SSH access to Karaf console, useful during development and to debug deployment issues. Although password protected, this should not be publicly exposed.
9200	Elasticsearch	jCustomer, Kibana	Elasticsearch HTTP interface, used by jCustomer to talk to ElasticSearch and also used by other clients such as Kibana or other applications
5601	Kibana	Jahia	Access to the Kibana platform, providing a user interface over the data in the Elasticsearch cluster