What happens if a publishers write to repository in AEM as a cloud service?

[jerfreed]

As part of the migration steps from AEM on prem to AEM as a Cloud Service:

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/migration-journe...

It lists this item to check for:

Changes to Publish repository

Direct changes to the Publish repository are not allowed, except those changes under /home. It is always recommended that any changes made on author get distributed. All code and configuration changes must be deployed through the corresponding Cloud Manager pipeline.

Let's hypothetically say I've joined an AEM development team, and have noticed they have a sling job that runs on each of the publishers, which modifies data in the repository.  What are the potential issues that may occur doing writes to the repository from publishers running in AEM as a cloud service?

Thanks!

[Anudeep_Garnepudi]

@jerfreed 

First why you want to run update directly on publish? Is there a reverse replication in place to back sync content?

Suggested only User generated content should flow in reverse (publish > author) all other changes are suggested to flow from author to publish.

Meaning of "Direct changes to the Publish repository are not allowed" is, you cannot access publish repository in AEM as a Cloud Service to do any content changes at run time. Only content changes have to be done in author and need to replicate.

In your case the content is created from code, so there should be any issue while creating content, but as mentioned it is not good practice. 

[jerfreed]

It's an existing codebase, not something I wrote, so I'm not looking to do it on the publisher, I'm just looking at what already exists.

While I realize it isn't a recommended way of doing it, it does appear to work and the changes do persist on the publishers.

I was more curious if Adobe is advising not to take the approach due to the possibility of repository corruption or some other major negative affect on the publishers.

[Jagadeesh_Prakash]

Hi @jerfreed ,

In your use case are you saying that using sling job are you creating the pages or any kind of configurations directly done in publisher instance of AEMaaCS?

In that case how are you going to maintain it ? and if you want to change the values or page content how are you going to do it?

This is not a good recommend practise. The restriction to AEM publisher is given for a purpose

If you are talking about the reverse replication then it is directly not supported in AEMaaCS. 

[jerfreed]

It's an existing codebase, not something I wrote, so while I agree it isn't the recommended approach, it's how it's working today.

I was more curious if Adobe is advising not to take the approach due to the possibility of repository corruption or some other major negative affect on the publishers.

[EstebanBustamante]

Hi,

What happens is that there is no mechanism to sync among instances. Therefore, you may encounter inconsistencies across AEM instances (author, pub1, pub2, pubx). Keep in mind that AEM as a Cloud Service (AEMaaCS) autoscales and also "recreates" itself, so it is not safe to write on a publish instance.

Hope this helps.

[jerfreed]

Thanks Esteban, the inconsistences part makes sense.

For autoscaling, if a new publisher pod spins up, where is it getting all of it's mutable content from to install into the instance?

[arunpatidar]

Hi @jerfreed 

Were the user suggestions helpful? Let us know if more details are needed or mark the answer as correct. If you found a solution independently, please share it with the community.

[kautuk_sahni]

@jerfreed Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.