four approaches to integrate aem with external systems by jan kuzniak

Integrating AEMwith External SystemsReview of all

fourpossible scenarios Jan Kuźniak

Agenda

• Why would you want to do that?• Who takes a beating?• Designers’ heaven• External content’s lifecycle and caching• Let’s fuel apps!• Go Home IE6!• Performance heaven• Summary

Why would you want to do that?

Why?

• Dedicated systems• eSales• Media publishing

• Transactional systems• Banking• Insurance

• Legacy systems

Why?

• 3rd party content on AEM page• Prices• Stock• Geo targeting

• AEM content on third party apps• Transactional sites• Mobile apps

• Integrating various content sources

Who takesa beating?

DesignersHeaven

Let’s hit AEM – Pros

• Simple• Natural to AEM (per design)• Great authoring experience• Quick optimisation / short time to market• Easy to integrate with AEM features

Let’s hit AEM – Cons

• Performance challenges• Caching challenges

• Security challenges• Shared authorisation• Security audits

Use Case – Internet Banking

• Small, throttled traffic• External authorisation• Sealed inside secure network• Back-end being replaced during the project• Agile customer

• Focus on short time to market• Need to release early and optimise

Use Case – Store

• „Static” site about products• Only prices and stock is dynamic

• No authorisation• No customer-related data in CMS• Product data cacheable in AEM

• Short time to live

• Dispatcher invalidation on external content changes

External Content’sLifecycle & Caching

Content Added / Removed

• Can 3rd party notify AEM?• If not - comparing cached data

• Does it require approval?• Workflows for creation, publication, deactivation

• Will that impact author performance?

Content Changed

• Can 3rd party send invalidation to dispatcher?• If not - comparing cached data

• How long can the content be outdated?• Invalidate one page or whole site?• How often can that happen?• Will cache be effective at all?

Let’s fuel apps!

3rd Party Assembly – Pros

• Performance• No user management in CMS

• Users belong to third party system (eSales)• No authorisation in CMS

• Natural for systems that provide own flow• Natural for mobile apps

3rd Party Assembly – Cons

• How to deliver authoring via 3rd party?• Switching between author and publish• Parallel stack and synchronisation• Mocking live data

• Double rendering• HTML for author, PHP for publish

• Where are my static assets (css/js)?• General entanglement

Use Case – eSales checkout

• Existing eSales backend handles checkout• Non-cacheable, session-bound data• Checkout form not changing often

• When it changes – it’s a code release anyway

• AEM managing „furniture” around forms• One UX team driving all designs

Go HomeIE6!

Browser Assembly – Pros

• Performance• Easy to cache - AEM serves static content• 3rd party serves only data

• AEM implementation owns look and feel• 3rd party stays unaware of AEM• Simple to implement

Browser Assembly – Cons

• Exposing back-end “magic”• Delay in serving content• Content grabbing• Old / Exotic browser challenges• Extra requests (mobile)

Use Case – Forms + Web Service• Static form served by AEM

• JS POSTs to web service• JS displays response (or redirects)

Use Case – Share Price Ticker

• Visually small area on home page• Non-critical – loading could be delayed

• Could never be outdated (legal reasons)• Short time-to-live• Home page was heavy and had to be cached

PerformanceHeaven

Edge Assembly – Pros

• Performance• Caching as with JavaScript approach• 3rd party renders only snippets of HTML

• Scalability• Lightweight servers take the hit

• Safer than Browser assembly• API exposed only to the edge

• No iFrames

Edge Assembly – Cons

• Requires the edge to render at all• Edge for all DTAP environments?• Mocking possible but challenging

• Limited application• Feasible for visual blocks, not for values (prices)

Use Case – eSales User Profile

• Personalised content served outside AEM• Login / logout• My profile / history

• Brochureware managed by AEM• Some pages served directly from eSales app

• See: checkout

Summary

Summary

• No right or wrong – all depends on use case• Choose who takes a hit based on:

• Performance (server and client side)• Availability (DoS, TTL)• Content lifecycle

• Don’t re-invent the wheel• Remember “Sling Dynamic Includes” from adaptTo()?• Fight duplication – reuse (and include)• ... But avoid entanglement