1
ARCHITECTURE OVERVIEW MARKETING
FACTORY MODULES
MODULES : MARKETING FACTORY ANGULAR MODULE, MARKETING
FACTORY CORE, MARKETING FACTORY DATA GENERATOR
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 2 / 28
SUMMARY
1 ADMINISTRATION (INTERFACES, APP, COMMUNICATION CXS) ...................................................... 4
1.1 Concepts .............................................................................................................. 5
1.1.1 Goals .................................................................................................................... 5
1.1.2 Campaign ............................................................................................................. 6
1.1.3 Segments ............................................................................................................. 7
1.1.4 Static lists ............................................................................................................. 7
1.1.5 Profiles ................................................................................................................. 7
1.1.6 Persona ................................................................................................................ 7
1.1.7 Form mapping ...................................................................................................... 7
1.1.8 Variant.................................................................................................................. 8
1.1.9 Optimization test ................................................................................................. 8
1.1.10 Personalization .................................................................................................... 8
1.2 Site settings, angularjs app .................................................................................. 9
1.2.1 The contextual information injected into apps ................................................... 9
1.2.2 Routes & Templates ........................................................................................... 10
1.3 The AngularJS applications architecture in detail: ............................................ 11
1.3.1 The applications ................................................................................................. 11
1.3.2 i18n .................................................................................................................... 13
1.3.3 Pickers ................................................................................................................ 14
1.3.4 Condition builder ............................................................................................... 15
1.1.1 Directives ........................................................................................................... 15
1.3.5 ManagerUtils ..................................................................................................... 16
1.4 List views and tables: ......................................................................................... 16
1.5 Personalization and Optimization tests: ............................................................ 16
1.6 Persona panel: ................................................................................................... 20
1.7 Credentials settings: .......................................................................................... 20
1.8 Proxy to cxs: ....................................................................................................... 20
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 3 / 28
1.9 Additional plugins, frameworks: ........................................................................ 22
2 LIVE (COMMUNICATION CXS)......................................................................................................... 23
2.1 WEM.js ............................................................................................................... 23
2.2 Context.js requested from CXS .......................................................................... 24
2.3 Login and file download events ......................................................................... 25
2.4 Optimization test ............................................................................................... 26
2.5 Personalization .................................................................................................. 26
2.6 Optimization and personalization rules ............................................................ 27
2.7 Sequence diagrams: ........................................................................................... 27
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 4 / 28
1 ADMINISTRATION (INTERFACES, APP,
COMMUNICATION CXS)
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 5 / 28
1.1 CONCEPTS
Most of the concepts are detailed in the Unomi architecture overview documentation, this document
adds a few more information on the usages made of these concepts in the Marketing Factory modules.
1.1.1 Goals
A goal is an object stored in CXS (not in Jahia), composed of one or two conditions the user’s actions
need to match to fulfil it.
EXAMPLES:
a page view (one condition).
The user should have seen the page.
The form goal (two conditions)
the user should have seen the page,
then
the user should have submitted the target form.
The module part for the goals only uses the Goals service’s endpoint from CXS to display reports on
them. The module displays the data from CXS using three directives:
A directive displays a small goal card with basic information (goal widget), visible in the site
dash oard for ea h goals. More i for atio is a aila le o the goal’s report page.
A specific directive manages the report table (goal report table)
The last directive handles the timeline on top of list of goals and in the goal report view, this
reusable directive gets the data from CXS and displays them in a charted timeline.
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 6 / 28
1.1.2 Campaign
A campaign is a set, delimited in time, of one or many goals. Campaign CXS endpoints are used to
manage campaigns reate, edit, get reports, et … . Part of the goals controllers’ ode has been reused
in the campaign interface to avoid duplicated code.
REUSE
Campaign reuses goal application parts by using angular.extend that enable a goal controller to extent a
campaign controller.
.controller('ManageCampaignGoalsListCtrl', ['$scope', '$route', '$location', '$modal', 'goalService',
'queryService', 'definitionService', 'i18nService', 'campaignService', 'campaignDetailed', '_',
'$controller', '$q', 'DTOptionsBuilder', 'DTColumnBuilder', '$compile', 'genericModal',
function ($scope, $route, $location, $modal, goalService, queryService, definitionService,
i18nService, campaignService, campaignDetailed, _, $controller, $q, DTOptionsBuilder, DTColumnBuilder,
$compile, genericModal) {
angular.extend(this, $controller('ManageGoalsListCtrl', {
$scope: $scope,
$route: $route,
$location: $location,
$modal: $modal,
goalService: goalService,
queryService: queryService,
definitionService: definitionService,
i18nService: i18nService,
currentCampaign: campaignDetailed.campaign,
_: _
}));
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 7 / 28
This definition of a ManageCampaignGoalsListCtrl extends a ManageGoalsListCtrl . By doing this the
ManageCampaignGoalsListCtrl inherits of all the goal controller ManageGoalsListCtrl functions and
behaviors unless the campaign controller overrides some by re-declaring them in its own controller.
1.1.3 Segments
A segment is a set of profiles that match a given condition. The segment’s interface enables to create,
edit and remove segments.
The segment is recalculated each time a profile is updated in CXS. The modules allow you to manage
them using CXS segments endpoints.
The condition builder is the directive used to create segment condition (see below).
1.1.4 Static lists
Static lists are lists of profiles. A service and end point, provided by CXS are used to manage static lists
from the modules.
1.1.5 Profiles
Profile is the default o tai er here all isitor’s data are stored regardless of a y seg e tatio .
Services are used to call CXS end points to manage profiles.
1.1.6 Persona
The persona panel uses the CXS end points to manage this container.
1.1.7 Form mapping
Form mapping are rules stored in CXS. When a form mapping is called, the corresponding rule from CXS
is requested and transformed into an easier item to handle and display by the angularjs app. When the
form mapping needs to be saved, the reverse operation can be done: the form mapping is transformed
into a rule then pushed into CXS using rules end point.
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 8 / 28
1.1.8 Variant
A variant is the designation of a content inside an optimization test or a personalization. Optimization
test and personalization can contain multiple variants and displays at least one to the end user.
1.1.9 Optimization test
An optimization is equivalent to an AB testing on contents. The interface allows to build an optimization
test directly on the content. The configuration of an optimization is done in the edit engine, where a
goal can be created for this optimization test.
An optimization test goal is a normal goal where the first condition has been replaced by the user
should have seen the optimized content
When the goal is created and the optimization test published, a goal report table is displayed in the edit
engine.
REUSE.
Like the campaign the optimization test angular app reuses part of the goal code, using extends, and
reusing the goal report table directive.
1.1.10 Personalization
A personalization affects the display of a content based on the history and behavior of the user who is
accessing it. Its configuration is done in the edit mode by creating conditions for all variants with the
condition builder.
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 9 / 28
1.2 SITE SETTINGS, ANGULARJS APP
Marketing Factory administration uses the site settings, each administration content is a simple empty
jsp that declares the entry point for a given angular application.
Example:
<%@ taglib prefix="template" uri="http://www.jahia.org/tags/templateLib" %>
<jsp:include page="../../commons/adminBaseImports.jsp"/>
<template:addResources type="javascript" resources="manage-profiles.js,manage-profiles-app.js"/>
<div ng-app="manageProfilesApp">
<div ng-view></div>
</div>
All the JavaScripts needed for the applications, like moment, underscore or the angularjs plugins, are
imported by the adminBaseImports.jsp.
Each application that contains a flow of execution uses angular-routes to navigate between steps.
EXAMPLE
Multiple view is composed of the following features : list, detail, creation view.
Please note that Base Settings has only one view.
1.2.1 The contextual information injected into apps
A Jahia render filter is used to declare some JavaScript context information, directly usable by the client
side applications to create links to use the JCRRest API or to get the current locales, etc.
baseEdit: "/cms/edit/default/fr" baseLive: "/cms/render/live/fr" basePreview: "/cms/render/default/fr"
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 10 / 28
contextServerAdminUrl: "/modules/marketing-factory-core/proxy/ACMESPACE" currentModuleURL: "/modules/marketing-factory-core" currentSiteHomePagePath: "/sites/ACMESPACE/home" currentSiteKey: "ACMESPACE" currentSitePath: "/sites/ACMESPACE" dmfScope: "ACMESPACE" googleAPIKey: "" i18nLabels: Object jahiaUILocale: "en" jcrRestAPIBase: "/modules/api/jcr/v1" jcrRestAPIVersion: "v1" localTemplatesPath: "/modules/marketing-factory-core/javascript/templates"
This filter also adds the good i18n version for angular and moment lib based on user locale.
1.2.2 Routes & Templates
The rest of the application is made using angularjs routes and static html templates. Each app has two
associated JavaScript files.
EXAMPLE,
the profile app used for Marketing visitors and Marketing personas , declares two JavaScript files:
manage-profiles-app.js: the one dedicated to the routes definitions, map a given URL to a specific
template and a specific angularjs controller
manage-profiles.js: the one dedicated to the app it self, controllers, directives, only related to manage
profiles app
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 11 / 28
1.3 THE ANGULARJS APPLICATIONS ARCHITECTURE IN DETAIL:
1.3.1 The applications
Each interface is a dedicated app
An app can be routed, by angular-route
Each app has some dedicated controllers, directives, or even services
The wem-services
The file wem-services, centralize all the service that communicate with the CXS
angular.module('wemServices', ['underscore', 'ui-notification', 'i18n'])
.config(['$httpProvider', 'NotificationProvider', function ($httpProvider, NotificationProvider) {
/* Config $http service to handle errors only here */
}])
.service('notificationService', ['Notification', function (Notification) {
/* Notification service to display, errors, info in the bottom right corner of the screen,
inject notificationService to use */
}])
.service('loadingSpinnerService', function () {
/* service to call to display a spinner loaded overlay in the page, the directive <loading-
spinner></loading-spinner> need to in the page */
})
.service('filteringService', function (_) {
/* service used for filter element in list view, when an element is deleted, used because of
the server delay to know that an element has just been removed */
})
.service('goalService', ['$http', function ($http) {
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 12 / 28
/* provides API to call Goal end points from ctx server, each function return HttpPromise,
.success() or .error() are the common usage on the HttpPromise to get the results */
}])
.service('ruleService', ['$http', function ($http) {
/* provides API to call Rules end points from ctx server */
}])
.service('segmentService', ['$http', 'jcrService', function ($http, jcrService) {
/* provides API to call Segment end points from ctx server */
}])
.service('listService', ['$http', function ($http) {
/* provides API to call Static list end points from ctx server */
}])
.service('queryService', ['$http', 'i18nService', 'notificationService', function ($http,
i18nService, notificationService) {
/* provides API to Query end points from ctx server */
}])
.service('definitionService', ['$http', function ($http) {
/* provides API to call Definition end points from ctx server */
}])
.service('profileService', ['$http', function ($http) {
/* provides API to call Profile end points from ctx server */
}])
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 13 / 28
.service('jcrService', ['$http', function ($http) {
/* provides API to JCR rest API on current digital factory*/
}])
.service('campaignService', ['$http', 'i18nService', function ($http, i18nService) {
/* provides API to call campaign end points from ctx server */
}])
.service('formMappingService', ['$http', 'i18nService', 'loadingSpinnerService', function ($http,
i18nService, loadingSpinnerService) {
/* provides API to create, edit form mapping using using ctx server end points */
}])
.service('internalSearchService', ['$http', 'i18nService', 'queryService', function ($http,
i18nService, queryService) {
/* provides API to manage internal searches using using ctx server end points */
}])
.service('geonamesService', ['$http', function ($http) {
/* provides API to query geonames DB stored in CXS, using CXS end points */
}]);
If customized development is needed, the usage of external calls, or reusable service should be part of
the wem-services angularjs module because we configure the $http service in the wem-services
odule’s o fig lo k.
1.3.2 i18n
A service and a directive are provided to support i18n messages in angularjs templates. The service
i18nService is available for injection or the directive message-key can be used to append the translation
to the given html element. This code is available in the file i18n.js
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 14 / 28
Some attributes are optional to format the message. The translation can also be stored in an attribute
of the element instead of the body of the html element.
We are using a tool that create the javascript lib corresponding to the resources bundles of the module,
this is done at compilation by:
<build>
<plugins>
<plugin>
<artifactId>jahia-maven-plugin</artifactId>
<groupId>org.jahia.server</groupId>
<executions>
<execution>
<id>i18n2js</id>
<goals>
<goal>javascript-dictionary</goal>
</goals>
<configuration>
<dictionaryName>wemi18n</dictionaryName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
This allows the i18n to read directly this library to get translation.
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 15 / 28
1.3.3 Pickers
Directives allow a user to pick item from different sources, node picker or html tag picker. the pickers
are in the file picker.js
node picker: allows a user to pick jcr node base on allowed types
html tag picker: allows a user to select the html tag from a Jahia live page. Rendering is a select
box (dropdown list) presenting all the tags found on the page.
html tag visual picker: allows the user to select the html element from a Jahia live page, the page
is rendered and the user can click on the element he wants to select directly
site language picker: allows a user to select a language
The most complicated one, the visual html picker, loads an iframe of the targeted page and allows the
user to click on the desired element.
1.3.4 Condition builder
The condition builder enables the creation of marketing conditions based on event, session or profiles
properties. Its directive, defined in condition.js, is recursive, all the template of the conditions types’
templates are stored in the /templates/condition/conditions folder.
This directive is used:
To create segment
For profiles advanced search
To create personalization
A hack has been used in the compile hook of the directive to be able to use it also in his own templates.
the solution name is RecursionHelper in condition.js
1.1.1 Directives
Some simple directives are declared in wem-directives.js:
auto focus: auto focus the given element after page load
page head: fix scroll and page header
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 16 / 28
foldable input: is the inputs used on MF interfaces, detect the type of the input, date, text,
number. Handle validation.
lettersOrNumbersOnly: the input may contain only letters or numbers
lowerThanNumber: the input number must be lower that the given limit
loadingSpinner: directive that come with the loading spinner service, to display/hide the spinner
overlay
prefixModelByProperties: directive to fix the model, prefix the model by properties. to avoid
issue of property not found on cxs side.
1.3.5 ManagerUtils
Static objects and utils functions are declared in a ManagerUtils namespace included in the file
manager-utils.js
1.4 LIST VIEWS AND TABLES:
The tables in Marketing Factory administration use datatable as well as server side paging, sorting and
filtering.
1.5 PERSONALIZATION AND OPTIMIZATION TESTS:
The content personalization is made on content in edit mode using action item. When created, the
original content displayed is replaced by an optimization node that wraps the content. Then you can
add more sub contents. This is handled by the action AddVariantsNode.java
A custom edit engine is used to display the interface related to the optimization, and declare a custom
edit engine:
- first is to declare the javascript that will handle the operations for the engine tab
<bean class="org.jahia.ajax.gwt.helper.ModuleGWTResources">
<property name="javascriptResources">
<list>
<value>/modules/marketing-factory-core/javascript/wem-edit-i18n.js</value>
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 17 / 28
<value>/modules/marketing-factory-core/javascript/wem-edit-personalization.js</value>
<value>/modules/marketing-factory-core/javascript/wem-edit-optimization.js</value>
</list>
</property>
</bean>
At this stage, the wem-edit-personalization.js and wem-edit-optimizations.js will be loaded at the same
time as the GWT in edit mode.
The wem-edit-optimizations.js contains the functions that handle the optimization custom engine
operations like validation, save, etc:
function optimizationInit(data) {
return $.parseHTML("<iframe id=\"optimizationFrame\" width=\"100%\" height=\"100%\" frameborder='0'
src=\""+jahiaGWTParameters.contextPath + jahiaGWTParameters.servletPath + "/editframe/default/" +
jahiaGWTParameters.lang + data.getPath() + ".wem-edit-engine-opti.html\"/>")[0];
}
function optimizationDoValidate(validation) {
var angularScope = customEditEngineGetAngularScope();
if(angularScope) {
angularScope.validate(validation)
}
}
function optimizationDoSave(node) {
var angularScope = customEditEngineGetAngularScope();
if(angularScope) {
angularScope.save(node)
}
}
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 18 / 28
function optimizationLanguageChange(data) {
// nothing to do
}
The optimizationInit appends an iframe on the current render (further called by GWT custom edit
engine), using the template wem-edit-engine-opti. This template contains the angularjs application. This
ifra e’s eha ior is si ilar to the arketi g factory site settings.
The optimizationDoSave, called by GWT, retrieves the current angularjs controller to call a save()
function in it. OptimizationDoValidate() operating patterns are similar. If the validation process returns
an error, the save() function is not operated.
WARNING: the validation has to be synchronous since the save function will be called by GWT.
both save and validation are passing GWT objects to be used directly.
Finally, the custom engine bean declaration is needed for the mapping between the js functions and the
custom engine tab :
<bean class="org.jahia.services.uicomponents.bean.editmode.EngineConfiguration">
<property name="key" value="wemnt:personalizedContent"/>
<property name="engineTabs">
<list>
<ref bean="Engine.Tab.Content"/>
<ref bean="Engine.Tab.ListOrdering"/>
<bean class="org.jahia.services.uicomponents.bean.editmode.EngineTab">
<property name="id" value="dmfconditions"/>
<property name="titleKey" value="[email protected]
factory-core"/>
<property name="tabItem">
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 19 / 28
<bean
class="org.jahia.ajax.gwt.client.widget.contentengine.CustomEditEngineTabItem">
<property name="onInitMethodName" value="personalizationConditionsInit"/>
<property name="onLanguageChangeMethodName"
value="personalizationConditionsLanguageChange"/>
<property name="doSaveMethodName" value="personalizationConditionsDoSave"/>
<property name="doValidateMethodName"
value="personalizationConditionsDoValidate"/>
<property name="handleCreate" value="true"/>
<property name="handleMultipleSelection" value="false"/>
</bean>
</property>
</bean>
</list>
</property>
…
Above is the definition of a type EngineConfiguration bean, that reuses the tabs Content and
ListOrdering but declare a new EngineTab. This new engineTab declares a new TabItem of type
CustomEditEngineTabItem.
The binding between the functions and the tabs’ a tio s is do e as follo s.
onInitMethodName -> personalizationConditionsInit
onLanguageChangeMethodName -> personalizationConditionsLanguageChange
doSaveMethodName -> personalizationConditionsDoSave
doValidateMethodName -> personalizationConditionsDoValidate
For more information about the mechanism behind, please refer to
org.jahia.ajax.gwt.client.widget.contentengine.CustomEditEngineTabItem in DF core.
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 20 / 28
This allows the creation of a custom edit engine tab which then displays an iframe using a template.
Communication between GWT and the inner application is done by javascript functions.
Optimization and personalization function in a similar way, each having a dedicated template, an
embedded angularjs app and a js that connects GWT and the angular app.
1.6 PERSONA PANEL:
Persona are stored on CXS side, they are managed using the persona admin panel in the Marketing
Factory admin.
The persona panel displayed in preview mode is added by a render filter ContextServerScriptFilter. It
appends an iframe in the left panel that uses a persona template on the site in preview mode. Html
customization and iframe display are done by the render filter using the wemPersonaPanel.groovy
script.
The persona template contains an angularjs app. This app can be found in wem-persona-panel.js
Using the selected persona, this application directly interacts with wem.js from the parent window to
mimic a user browsing the site by calling a dedicated function, loadPersonaContext , to init a persona
session.
If the persona is modified in the persona panel in preview mode, the changes are not saved within CXS
but in the browser session Storage. Their persistence only last the user session.
1.7 CREDENTIALS SETTINGS:
Communication setting with CXS are stored in a dedicated node context-server-settings. Password is
hidden by a Node Decorator designed to avoid the password to be easily read.
1.8 PROXY TO CXS:
All the Marketing Factory administration app have to go through a secured by proxy call the CXS to get
information. There is no direct call to CXS from the client.
This allow us to secure the calls:
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 21 / 28
<bean id="proxyServlet" class="org.jahia.modules.marketingfactory.admin.ProxyServlet">
<property name="contextServerSettingsService" ref="contextServerSettingsService"/>
<property name="permissionMapping">
<map>
<entry key="[GET]/cxs/segments/**" value="jcr:read_default"/>
<entry key="[GET]/cxs/geonames/**" value="jcr:read_default"/>
<entry key="[GET]/cxs/profiles/properties/**" value="jcr:read_default"/>
<entry key="[GET]/cxs/profiles/personas/**" value="jcr:read_default"/>
<entry key="[POST]/cxs/profiles/personas/search"
value="canPersonalizeWithMarketingFactory"/>
<entry key="[GET]/cxs/definitions/**" value="jcr:read_default"/>
<entry key="[GET]/cxs/goals/**" value="jcr:read_default"/>
<entry key="[POST]/cxs/goals/**/report" value="jcr:read_default"/>
<entry key="[POST]/cxs/goals/**" value="jcr:write_default"/>
<entry key="/**" value="canAccessMarketingFactory"/>
</map>
</property>
</bean>
For example, the bean definition of the proxy allows us to define some end points that need some
permissions to be called.
If customized development is needed, all the client side built URLs should use this JavaScript variable
(accessible from every where in MF interfaces and angularjs apps):
ManagersContext.contextServerAdminUrl
equals to "/modules/marketing-factory-core/proxy/ACMESPACE" in case of ACMESPACE used as
context server scope.
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 22 / 28
1.9 ADDITIONAL PLUGINS, FRAMEWORKS:
The Angularjs application use some plugins or external JavaScript libs. All these libs are part of the
module marketing-factory-angular.
angular 1.4.1
angular-chart & chart.js: used for the timelines and all the charts
angular-cookies: used to manage cookies, used by the persona panel
angular-datatables: used for all the tables in the applications
o we use server side pagination, sorting and filtering
o a custom pager has been developed for datatables:
ManagersUtils.initPagerProperties = function (DataTable, $scope, i18nService) {
o can be call from serverData fn
o Almost all datatables use a serverData fn to get the data and handle sortering and
filtering
.withFnServerData(serverData);
angular-google-maps: used to draw and use google map API in angular app, used by persona
panel and personalization (condition on geographical zone)
angular-md5: used to create MD5 hash, used by gravatar directive to build hash from mail
angular-moment & moment.js: used to manipulate dates, the usage of new Date() in JavaScript
should be reduce as possible and replace by usage to moment() API
angular-resource: API to build rest client
angular-route: API to build routes based on urls, used for every app in site settings of MF
angular-simple-logger: dependency of angular-google-maps
angular-ui-notification: used to create bottom right notification, the notificationService is used
in wem-services.
angular-underscore & underscore.js: provide many utils functions, to manipulate arrays, lists,
json objects, doing map reduce, sorting, filtering, etc.
angular-ui & datepicker ui: used to build components based on bootstrap, like modals, date
pickers, etc.
jquery 1.11.2: used only to be able to use datatables, it’s also used y a gularjs i ter ally
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 23 / 28
2 LIVE (COMMUNICATION CXS)
2.1 WEM.JS
This javascript is included in the page by the ContextServerScriptFilter like the persona panel in preview.
The wemContextServer.groovy includes the js in the html content, and generates the javascript that
calls the init() function from the wem JavaScript object.
The init() function requests the context.js from the CXS by sending to it events and filters, if wem.js
needs to resolve personalization. Else, the init() function sends events related to the current page view
to CXS.
The wem object allows to register callbacks executed after the context.js is loaded from CXS. Thus
listener is attached to a submitted form or a viewed video. This attachment is made possible by the
storage of information on the page containing the form or the video within the context.
The wemContextServer.groovy also generates a JavaScript object named digitalData . This object
contains information on the displayed resource. This information is reused to send the page view event
into CXS.
digitalData:
contextServerPublicUrl: "http://172.16.13.23:8181" events: Array[1]
0: Object eventType: "view" scope: "ACMESPACE" source: Object
itemId: "72fcc615-4581-46bf-83bd-68dc1e0221fd" itemType: "site" scope: "ACMESPACE" __proto__: Object
target: Object itemId: "7cdf8885-a3e1-4b39-a310-a203ce004056" itemType: "page" properties: Object
attributes: Object category: Object
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 24 / 28
pageInfo: Object destinationURL:
"http://localhost:8080/fr/sites/ACMESPACE/home.html" language: "fr" pageID: "7cdf8885-a3e1-4b39-a310-a203ce004056" pageName: "Accueil" pagePath: "/sites/ACMESPACE/home" referringURL:
"http://localhost:8080/gwt/edit/27165459DD1E78D717BE51D2AA5
A8D91.cache.html" __proto__: Object
__proto__: Object scope: "ACMESPACE" __proto__: Object
__proto__: Object length: 1 __proto__: Array[0]
loadCallbacks: Array[1] page: Object scope: "ACMESPACE" site: Object
siteInfo: Object siteID: "72fcc615-4581-46bf-83bd-68dc1e0221fd"
2.2 CONTEXT.JS REQUESTED FROM CXS
The context.js is the JavaScript part coming from CXS, it contains the CXS JavaScript object present on a
loaded page.
The CXS object contains trackedConditions, rules stored in CXS that are related to a specific source.
EXAMPLE
A user submits a form mapped with form mapping. This form is also target of a trackedConditions rule.
The form submission sends data into CXS before they are sent to their main target.
CXS object contains also information on current user profile.
Functions are also provided by context.js and collect events. They are actually used by the wem.js in the
context loaded callbacks to register listener that will send events to CXS on specific user operations. You
can see that in the init() function of wem.js
cxs:
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 25 / 28
collectEvent: (event, successCallBack, errorCallback) collectEvents: (events, successCallBack, errorCallback) createCORSRequest: (method, url) createCookie: (name, value, days) eraseCookie: (name) filteringResults: null loadXMLDoc: (url, successCallBack) merge: (obj1, obj2) profileId: "278da1b4-87dd-44e8-9b2a-44f6e8a6250f" profileProperties: null profileSegments: null readCookie: (name) sessionId: "b80c5ebe-97dd-4e29-9eab-d7198fd29452" sessionProperties: null trackedConditions: Array[2]
0: Object parameterValues: Object
formId: "searchForm" __proto__: Object
type: "formEventCondition" __proto__: Object
1: Object parameterValues: Object
formId: "advancedSearchForm" __proto__: Object
type: "formEventCondition"
2.3 LOGIN AND FILE DOWNLOAD EVENTS
A specific Event listener has been created in the modules to react on user login and file download.
The java class ContextServerApplicationListener handles those events and sends the correct event to
the context server when it is needed:
if (applicationEvent instanceof LoginEngineAuthValveImpl.LoginEvent) {
handleLoginEvent((LoginEngineAuthValveImpl.LoginEvent) applicationEvent);
} else if (applicationEvent instanceof FileServlet.FileDownloadEvent) {
handleDownloadEvent((FileServlet.FileDownloadEvent) applicationEvent);
}
The login event is always sent to CXS, but the download event is sent only when the downloaded file has
a specific mixin related to MF that tells us that this file needs to be watched.
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 26 / 28
2.4 OPTIMIZATION TEST
The live view of optimization test calls a JavaScript function that uses the context loaded callbacks to
send to CXS the content displayed to the user after the loading of the context.js.
In live a random content is displayed to the user, then the displayed content ID is stored in the
sessionStorage and an event is sent to the CXS using the register callback. This allow us to build the
report table for the given optimization based on the events sent to CXS.
In details:
There is a Rule stored in CXS that is triggered each time an optimization test is viewed for the first time
by a visitor.
This rule will store the ID of the content viewed by the user in its profile properties.
That way we can build the report table based on the content see by the user.
For each session, users see the content displayed at the first time this feature is enabled by the storage
of the content’s ID in the sessionStorage of the browser.
The optimization goal is similar to a typical goal except for the start condition replaced by a condition on
the fact that the optimized content has been displayed – or not – to a profile.
2.5 PERSONALIZATION
In live mode the personalization needs to resolve the filters to adapt the content’s display to the user.
The registerfilter function from wem.js is used for this purpose.
The filters are resolved by the CXS when the context.js is requested. Filters’ results are part of the
context.js response. Results are then sent to registerCallback that load the needed content that
matches the results.
2.6 OPTIMIZATION AND PERSONALIZATION RULES
Personalization and optimization operations depend on start date, end date, and specific rules.
We have some rules and jobs that run to detect if the optimization should end or not. This job asks CXS
for the report to see if the maximum number of hits has been reached for example. If it is the case, an
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 27 / 28
action is triggered to resolve the strategy of the optimization test, if the winner should be promoted or
if we keep the default variant.
And to avoid orphaned jobs, we have rules on optimization deletion to remove the associated jobs
2.7 SEQUENCE DIAGRAMS:
The user sees a page that contains:
- An optimization test
- A contact form that have a form mapping
- A personalized content
ARCHITECTURE OVERVIEW
MARKETING FACTORY MODULES
© 2002 – 2016 Jahia Solutions Group SA Page 28 / 28
The user logs in the application:
MF_handler is the event listener in the module: ContextServerApplicationListener