AEM Publish to AEM Author Reverse Replication Scenario - AEM Cloud

[NageshRaja]

Hi All,

We have a use case where-in we are exposing a custom form on AEM Publish - This is sitting behind an IDP (Okta) so only authenticated users can fill the form.

The form is used to modify content fragments, create content fragments (if necessary) and so on - basically CRUD operations on Content Fragments.

AFAIK we will not do this on Publish because the cloud containers are dynamic and syncing to Publishers doesn't make sense. Also, reverse replication in AEMaaCS is not available to that's not an option either.

There is an approach to use Adobe IO runtime action to basically have a function pass the payload from the form to AEM Author and then have the servlet execute CRUD operations on CFs before replicating and publishing it to Publishers.

Query 1 - Is this approach the best possible way?

Query 2 - Setting up a runtime action is not exactly straight forward - I tried following Adobe's documentation on the same- 

Adobe I/O Runtime Action and AEM Events

Creating Actions

Do you have any reference? I am having trouble comfiguring workspace and projects - The config.json downloaded is not getting consumed via below command- 
aio config:set ims.contexts.devTest pathtoFileJSON

Thanks,

NR

[SantoshSai]

Hi @NageshRaja,

1. Approach to CRUD operations on Content Fragments from Publish

• Directly modifying CFs on Publish is not supported/recommended in AEMaaCS. Publish instances are transient, do not persist changes across restarts, and there’s no reverse replication.

• The recommended approach is exactly what you outlined:

  • Publish Form → Adobe I/O Runtime (serverless function) → Author → CRUD Servlet → Replication → Publish.

• This ensures:

  • Author remains the source of truth.

  • Content is properly versioned, replicated, and consistent across all Publish instances.

  • You don’t have to worry about content being lost on Publish node recycling.

Some teams also place a middleware service (Node.js/Java microservice) between Publish and Author instead of Adobe I/O Runtime, but the principle is the same: all content writes must go through Author.

So yes, your proposed architecture is the best practice for AEMaaCS.

2. Adobe I/O Runtime Action setup

This is usually where things get tricky. A couple of tips:

• Workspace setup:

  • First, make sure you have logged into the right org and project:

aio login
aio console:list
aio console:select <orgId> <projectId> <workspaceId>

• Config JSON issue:

  • The command format is:

aio config:set ims.contexts.<name> ./path/to/file.json --file

(note the --file flag, which is often missed).

• Example:

aio config:set ims.contexts.devTest ./config.json --file

• Double-check the JSON:

  • Ensure your downloaded config.json is from the correct Workspace → Service Account (JWT or OAuth) in Adobe Developer Console.

  • Sometimes the “All Services” JSON is downloaded instead of the one bound to your runtime action workspace.

• Docs & samples:

  • https://developer.adobe.com/app-builder/docs/get_started/runtime_getting_started/

  • GitHub sample repo (official): adobe/aio-cli

[NageshRaja]

Hi @SantoshSai, I am on aio version  11.0.0

Here's my command line logs -

nk@ACCNUGW0528 io runtime action % aio login
Visit this URL to log in:
https://aio-login.adobeioruntime.net/api/v1/web/default/applogin?id=0811016b&port=61177&redirect_uri...
✔ Login successful

nk@ACCNUGW0528 io runtime action % aio console:list
› Warning: console list is not a aio command.

[Rohan_Garg · Accepted solution]

Try "aio where" - This should give you Org, Project and Workspace.
If its empty then you need to run "aio login'" - Post authentication run the below - 
1. aio org:list -- view all organizations

2. aio org:select 

3. aio project:list

4. aio project:select

5. aio workspace:list

6. aio workspace:select

Post this you can view your config via "aio config:list"

Hope this helps!

Rohan Garg

[NageshRaja]

yes this works! thank you so much