1. Integrating AEM
with External Systems
Review of all four
possible scenarios
Jan Kuźniak

2. 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

3. Why would you
want to do that?

4. Why?
• Dedicated systems
• eSales
• Media publishing
• Transactional systems
• Banking
• Insurance
• Legacy systems

5. 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

6. Who takes
a beating?

8. Designers
Heaven

10. 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

11. Let’s hit AEM – Cons
• Performance challenges
• Caching challenges
• Security challenges
• Shared authorisation
• Security audits

12. 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

13. 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

14. External Content’s
Lifecycle & Caching

15. 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?

16. 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?

17. Let’s fuel apps!

19. 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

20. 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

21. 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

22. Go Home
IE6!

25. 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

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

27. Use Case – Forms + Web Service
• Static form served by AEM
• JS POSTs to web service
• JS displays response (or redirects)

28. 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

29. Performance
Heaven

32. 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

33. 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)

34. 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

35. Summary

36. 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