four approaches to integrate aem with external systems by jan kuzniak
TRANSCRIPT
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