Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

What's the best way to implement content/Experience as a service in AEM 6.3?

Avatar

Level 2

Hello there,

I was evaluating AEM 6.3 for content/experience as a service (CAAS) approach but am confused. Hope the experts here could help me.

AEM brought concept of Content fragments to reuse assets and I believe is being sought as a backbone for CAAS but I found the functionality really limited. Not only I am unable to define my own structured content (content types) but there is not an easy way to expose the same as a service mainly in JSON format.

On the other hand, AEM also has something called Content Services which helps define model and then export the data as well but it more part of AEM Mobile. It does have limitations like supporting complex models, extending existing CAAS service but looks better than Content Fragment to me from CAAS feature point of view. The only plus point with Content Fragment than this is to be able to define Variations.

Third option is leveraging Resource provider for a url which starts with /api  to expose the data in JSON format for example http://localhost:4502/api/assets.json. It has limitations on both management as well as exposure side.

As you see there are somehow 3 options available but all of them have their own limitations and most importantly not connected with each other. I would like to know Adobe's POV to support CAAS, which one from above should be used to be forward compatible with Adobe next release. Also is there any possibility for CAAS service to be integrated with Content Fragment?

Appreciate the response here.

1 Accepted Solution

Avatar

Correct answer by
Level 10

Here are thoughts of intrernal Adobe ppl --

> well but it more part of AEM Mobile

Its part of core

> It does have limitations like supporting complex models, extending existing CAAS service

You can build complex content structures by nesting entities of varying models or by using custom data types

Ie Create an shopping centre entity then create serveral store entities object shopping centre etc.

Model like pages can be constrained to where they can be placed (parent/child enforcement) to help maintain the data integrity of a complex structure

You can extend ContentServices via;

-creating your own data types for use in models

-creating your own renderers to override, augment, decorate, transform, aggregate JSON output as needed (variation of such renderings can be assembled as output configs to allow mixed use content delivery).

Alternatively you can provide your own sling renderers outright and render any entity as you see fit bypassing ContentServices for delivery.

View solution in original post

7 Replies

Avatar

Level 10

I am trying to see if AEM ppl have thoughts on this.

Avatar

Level 10

DOnig some research on this - here is a community article that suggests Content Fragments are lined up with CAAS:

AEM 6.2 Key Features & Thoughts on Content-As-A-Service | LinkedIn

Avatar

Level 10

Here is an article on Content Fragments - Adobe Experience Manager Help | Working with Adobe Experience Manager Content Fragments

As you can see in this artilce - you can define:

Elements

  • Self-contained pieces of editorial content that are meant to be authored in a page with their own design and layout, i.e. component, as opposed to "paragraphs" which are meant to be authored with a common component.

Default content

  • Content every user sees the first time a fragment is created.

Fragments themselves have a name/title value, like every AEM asset, and contain the following structural elements:Paragraphs

  • Groups of words separated by a vertical space (carriage return).
  • Can include a title, which has to be formaed as such (header). Otherwise titles are seen as
    paragraphs on their own.
  • Paragraphs are important as fragment components allow creating fragment instances in a page
    with just one paragraph or a sequence of paragraphs. We will see this later on when using a Content Fragment in a web page.

Variations

  • Copies of the content master that are optimized for a certain editorial purpose or channel. A mobile variation can for example be optimized for a mobile channel, by removing and/or rewriting certain parts of a master. Or an email variation can be optimized for using the same content in emails.

Associated Collections

  • Relevant media content that is added to the fragment. Purpose is to expose channel producers to only this curated media content during production rather than the entire repository.

Avatar

Correct answer by
Level 10

Here are thoughts of intrernal Adobe ppl --

> well but it more part of AEM Mobile

Its part of core

> It does have limitations like supporting complex models, extending existing CAAS service

You can build complex content structures by nesting entities of varying models or by using custom data types

Ie Create an shopping centre entity then create serveral store entities object shopping centre etc.

Model like pages can be constrained to where they can be placed (parent/child enforcement) to help maintain the data integrity of a complex structure

You can extend ContentServices via;

-creating your own data types for use in models

-creating your own renderers to override, augment, decorate, transform, aggregate JSON output as needed (variation of such renderings can be assembled as output configs to allow mixed use content delivery).

Alternatively you can provide your own sling renderers outright and render any entity as you see fit bypassing ContentServices for delivery.

Avatar

Level 1

Scott,

This is very useful. Thanks for sharing these details.

Sounds like Adobe is then committed to evolving CaaS and Content Services to enable the notion of a true API-first CMS model, exposing every underlying Sling resource type as a "service", together with transformation, aggregation and other services as well ?

A few key questions though based on what you provided above :

1. How much of this capability - especially things like custom data types, custom entity models, transformation and aggregation services - is available today in AEM 6.3 ? The AEM 6.3 documentation page for CaaS suggests that a number of these "extensibility" aspects are not available with this release, and will only come in AEM 6.3 SP1 ? What is available today, and what will come available in SP1 ? If all of this is really available today itself with AEM 6.3, can you point us to relevant documentation, code samples, etc. ?

2. There is still not as much clarity between how the two new resource types of "content fragment" and "experience fragment" deeply link into / connect with CaaS and Content Services. If we treat these two as Sling Resource Types, will they plug in seamlessly into Content Services / CaaS, or will this require the definition of custom / extended Entity Models in CaaS - to expose those two as services ?

3. Is the intent to build all of these services and the API layer within / inside AEM ? Is the intent to make AEM an API Engine ? Or is this where Adobe I/O fits in ? What is the role of Adobe I/O here ? Will the APIs, services, transformation and aggregation logic be better deployed within Adobe I/O and its API gateway, or within AEM ? Basically, should we start thinking about AEM as the API Engine in this scenario, or will Adobe I/O be the API engine on top of AEM ?

Avatar

Level 2

Hi Scott,

Thanks for sharing these details. From your last response, seems CAAS (or Content Services) will be more mature in coming days and will be used to construct complex content types (for example management of article, event etc. by marketer). If that is the case, how will Content Fragment fit into this or will this be deprecated?

Avatar

Level 2

Hi Scott,

regarding

We need to modify JSON output from ContentServices. Were can we find documentation on how to override, decorate and transform JSON output? It is extremely difficult to find any technical documentation on content services at all.

BR

Henrik Heiestad