Embed Size (px)
Citation preview
AEM & TRANSACTIONAL/PORTAL SYSTEMS
P R E S E N T E D B Y
Real World Approaches to integration AEM to Transactional and Portal Systems
2
Paul McMahon – Managing Director at Acquity
Group – Part of Accenture Interactive
North American AEM Practice Lead
• 12 years of experience with AEM/CQ platform
• First AEM/CQ integration to a transactional platform was in 2002 – CQ 3.5 and Blue Martini rendering a sporting goods manufacturers global digital presence.
INTRODUCTIONPaul McMahon
Agenda
Drivers for Integration
Approaches to
Integration
Transactional On Top
AEM On Top
AEM and
Transactional As
Peers
3
DRIVERS FOR INTEGRATION
Unified User Experience
4
Requirements to integrate AEM with portals, eCommerce
platforms, and other niche systems to create a single consistent user interface have become more and more common.
Traditionally organizations would create multiple web sites,
driven by technology choices. Each platform would manage it’s
own web sites and users would need to shift between web sites if
they wanted access to multiple functions.
DRIVERS TO INTEGRATE
5
The days of having separate web sites for different
functions, or even the appearance of separate web
sites are rapidly coming to end.
This trend is driven by a number of factors including:
Requirements for single unified user experience
across an enterprise’s entire digital experience
Requirements for user driven experiences that
place fewer steps and boundaries in the way of
users completing a transaction.
Rise new technologies to deliver user experiences
Typical Use Cases
Sites with eCommerce
capabilities – either
B2B or B2C.
Financial Services
sites with account
management or
transactional
capabilities.
Member Service sites
Employee Portals
DRIVERS TO INTEGRATEOne Web Site to Rule them All
APPROACHES TO INTEGRATIONThree Common Patterns for Integration
AEM Publish
(Informational)
Shared session
Visitors
Integrated User Experience
Internet
Commerce/Por
tal/Other
System
Commerce/Por
tal/Other
System
Option 3: Peer Architecture *
AEM Publish
Option 1: Other System On Top
AEM Publish
Commerce/Por
tal/Other
System
Option 2: AEM On Top
7
TRANSACTIONAL ON TOP
8
The requirements dictate dynamic page display based on capabilities of the transactional system
An existing web site/code base seeking to pull in content from a CQ repository.
Most commonly this approach is found in internally facing employee portals, or B2B transactional portals like dealer or distributor networks.
Normally this is a secondary use of AEM in the enterprise, and in other areas of the enterprise AEM is used in it’s traditional role.
Transactional On Top
TRANSACTIONAL ON TOPTypical Use Cases
Shared session
Visitors
Commerce/Por
tal/Other
System
AEM Publish
9
The most typically integration approaches involve the
transactional system consuming rendered HTML
snippets from AEM.
• A portlet makes a request to page and gets rendered HTML back and includes it into a page server side (/content/site/en/pagea.portal.html).
• A product detail page rendered by an ecommerce system makes a AJAX call to a component that renders the right rail of the page (/content/site/en/pagea/_jcr_content/rightpar.html).
The key to these and similar mechanics is that it keeps
control of the overall user experience with the
transactional system.
Transactional On Top
TRANSACTIONAL ON TOPIntegration Mechanics
Shared session
Portal
AEM Publish
REST call to
Component/Page
returns rendered
HTML Snippet
Portal returns a
consolidated HTML page
with AEM Content
embedded
Commerce
Commerce
Page returned
containing
AJAX call
AEM Publish
REST AJAX call to
Component/Page
returns rendered
HTML Snippet
10
An alternate approach is to have AEM render a text template that is used by the transactional system to generate a full page response.
• Authors create and manage a page in AEM that represents a template for a transactional page
• The template includes global content (header and footer) and any other relevant content – maybe a right rail.
• The authors also drop place holder components in the page representing the locations where transactional content is displayed.
• The transactional system pulls this template from AEM (and usually implements an internal cache of the template) and replaces these tokens at runtime with actual transactional content/HTML and then serves the page.
Key differentiator with this approach is that it grants a degree of control to authors over the user experience, but the transactional system still retains control of all page requests
Transactional On Top
TRANSACTIONAL ON TOPIntegration Mechanics
Shared session
11
TRANSACTIONAL ON TOPPros and Cons
Benefits
•Application flow control is left with transactional system. This may be important for systems with complex business logic and dynamic flow.
•No SSO is required – only a single system needs to maintain session and security
•Access to transactional system’s full API stack when rendering all pages – important for highly dynamic applications, or sites where the transactional system is also a personalization engine.
Potential Issues
•Preview is difficult – effective preview requires either a staging server and a staging publishing process.
•Understanding the relationship between the web site and the content structure in AEM may be difficult depending on the basis for the relationship.
• It is easy to create a brittle system where changes to the structure of content in AEM can break the web site.
•Link rewriting can be a challenge
12
AEM’s Portal Director is an example of portal on top. It provides more advanced integration mechanics which address some of the potential issues with the Transactional On Top Model
• Author and Preview – it is possible to author content from the
portal, as well as preview prior to publication with Portal
Director
• Allows for a shared security model where the portal users
identity and permissions are shared with AEM allowing
standard AEM permission models to be applied
• Provides features to reduce the danger of content structure
impacting the application (portal content map allowing keys
to be configured in the portlets so content references can be
safely updated).
• Link Rewriting
• Caching
Portal Director
TRANSACTIONAL ON TOPAEM Portal Director
Shared session
Visitors
Portal – End
User View
AEM Publish AEM Author
Portal
Admin
Portal – Admin
View
13
AEM ON TOP
14
The requirements call for a high degree of author
control over user experience.
Heavy integration to other parts of the Digital
Marketing Cloud
Site is more content than transactional
eCommerce sites with smaller product catalogs that
require richer content – Life Sciences for example.
AEM On Top
AEM ON TOPTypical Use Cases
Shared session
Visitors
Commerce/Por
tal/Other
System
AEM Publish
15
The most common integration approach is for AEM to render all pages and to access the transactional system using web services (either directly from the client browser via AJAX, or with Publish server functioning as a proxy).
In cases where the transactional system is the source of truth for a large amount of stable content (like a product catalog) this pattern will involve importing the content into the JCR to reduce the web service traffic.
The key to this approach is that AEM maintains control of the page flow and user experience.
AEM On Top
AEM ON TOPIntegration Mechanics
Shared session
AEM
Dispatcher
Publish
AEM Author
Import of stable
relatively long lived
content
AEM Delivers the page
with embedded AJAX for
dynamic data
Commerce
Catalog
Manager
Web Service Calls
Proxied from User
AJAX Calls Directly
From User
16
AEM ON TOPPros and Cons
Benefits
•Author control of the user experience across the full site.
•Access AEM – Digital Marketing Cloud integrations, keeps all relevant content (including product content) in the repository and available to DMC integrations.
•Maintain a single session and context for targeting and analytics
Potential Issues
•Potential performance penalty due to proxying of web service requests through AEM.
•Managing state across multi-step transactional processes in AEM requires additional frameworks that are native to most transactional systems.
• In use cases where data is imported into the JCR additional complexity is added to the solution and may require significant custom coding depending on the source system.
17
AEM AND TRANSACTIONAL AS PEERS
18
Mixed requirements where both authoring and transactional features carry equal weight.
Significant performance concerns for transactional functionality.
Retail eCommerce sites with large product catalogs and high product turnover.
Member/Partner portals where the transactional features have little or no content integrated and the primary connection between the two systems is the common header and footer.
Peers
AEM AND TRANSACTIONAL AS PEERSTypical Use Cases
Shared session
Visitors
AEM Publish
(Informational)
Commerce/Por
tal/Other
System
19
Use of a single web server tier through which all HTTP requests are accepted and then distributed to either AEM or the transactional system based on URL.
When a page rendered by the transactional system needs content from AEM it is typically pulled in via a HTTP call to AEM that returns rendered HTML or JSON. The variations are similar to the integration patterns mentioned for the Transactional on Top Pattern.
When AEM page requires transactional functionality it will typically access that functionality through a web service call as discussed in the AEM on Top Pattern, or an AJAX call from the client.
Sharing CSS/JavaScript/Static Images is a crucial integration mechanism to ensure a consistent user experience. At runtime this normally easy to achieve by deploying the required static files to the shared Apache server, however sharing these files between the applications adds significant dev ops complexity.
Peers
AEM AND TRANSACTIONAL AS PEERSIntegration Mechanics
Shared session
Visitors
AEM Publish
Commerce/
Portal/Other
System
Shared Web Server Farm
Common User Experience
Web Server routes
request to proper system
based on URL
Content Sharing as
needed via web services
between systems
Appropriate system
returns rendered HTML
page
Architecture also allows
for AJAX requests to
share content between
systems
20
AEM AND TRANSACTIONAL AS PEERSPros and Cons
Benefits
•Leverages both systems to perform their optimal roles.
•Normally easier to achieve required performance goals.
•Loosely couples the integration between the two systems
Potential Issues
•Add significant complexity to the architecture
•Triaging and troubleshooting are more complex.
•Development operations are more complex because of the coordination required in non-production environments.
•Development is more complex because the UI must be maintained consistently in two systems.
•Preview can still be challenging for content appearing on transactional pages.
21
Key to these architecture is splitting responsibility for responding to end user page requests among two or more systems for one web site in manner that is transparent to the end user.
The goal is to allow the most appropriate system render the page, hiding from the user that different systems are involved.
Every URL rendered by the web site is assigned to be rendered by one of the systems backing the web site.
Pages within the web site are broken down into content areas, and the source of each content area is defined.
Peers
AEM AND TRANSACTIONAL AS PEERSKey Points
