Force to activate page set as scheduled activation and pass arguments to QA environment

[mohammadm377380]

Hi guys,

We have some scenario here where we have 2 authoring (Author and QA) to handle our content before it will be pushed to live (Publisher).

Our problem is how to push the page that is scheduled for activation to QA but we want it to be pushed to QA automatically and include the schedule data as part of the page properties. And when QA person approve the page, it will be treated as scheduled activation on the QA instance.

My initial solution is:

Author instance:
Author => schedule a page to be activated => listen to the workflow instances => capture it then process if it is scheduled page => force to activate the payload path with the schedule details to QA.

QA instance:
Then QA receive the payload with the schedule details => QA person check the page and approves it => Then before publishing it, I think I need some listener again to check if the page has schedule details, then it will be treated as scheduled for activation rather than immediate.

Do you have any experience regarding this setup?

Thanks!

[kautuk_sahni]

Joerg Hoh Can you share your experience here?

[smacdonald2008]

You are using workflows for this use case? What AEM Version are you using?

[Jörg_Hoh]

Hi,

this process is highly unusual for AEM deployments and contradicts best practices. Content creation, review and approval workflow should happen on the PROD authoring instance. Then you don't need to cross system borders which makes the whole setup much easier. And looking at your process itself I don't see any imminent reason why you cannot implement it in the way I outlined.

Can you elaborate a bit?

regards,
Jörg

[mohammadm377380]

Yes we are going to use workflow. But that part will take effect only on the QA side after the reviewer published it.

We are using AEM 6.3.

[mohammadm377380]

Hi Jörg,

I understand that it contradicts the best practices of AEM.

The story behind this setup is we want the reviewer to see the actual page as same as the production site. So we made QA as publisher instance then reviewer can only publish from there nothing else (this breaks the best practices of AEM). Reviewer does not have any access to our authoring instance. Actually what happened why we didn't use the workflow approach is it became broken after we migrated from 6.1 to 6.3. And Adobe support team were unable to help us at all. So we did the necessary things to fulfill our goal to have reviewing part of pushing of our pages.

For this problem aside from my flow above, another way that the author can achieve the scheduling part from QA side is to email the reviewer (separate users/entities) separately that their pages should go live on certain date and time. Which is not ideal too as they are going out from the system.

[Jörg_Hoh · Accepted solution]

Hi,

in your approach you either have a change of channels (AEM workflow -> email to QA -> QA checks -> QA sends back feedback -> continue workflow) or you implement everything on your own. I would still question the need to have a dedicated preview publish instance and why the preview of the authoring instance is not sufficient.

In the end it's a trade-off:

* Either you implement everything on your own and build the dedicated preview environment and connect it somehow to your PROD authoring instance and embedd into a process. The problem is that you need quite some development to make it work flawlessly.

* Or you build a minimal version of it, and do the workflow via email, chat and phone. The problem is here that this workflow will break quite often because mails got lost, people are on PTO, distracted, or simply forget.

* Or you go back to best practice and live with the fact, that there's a chance that you cannot preview everything to 100%.

I think that this should be a deliberate decision, which is not technical in the first place. You should definitely document that best practices do not match your usecase, and for why reasons you choose a different approach. And when you have the decision and documented it, it's time to discuss technical details about the implementation.

(I learned some lessons about customizations; the most important one is, that such customizations are never a one-off task, but you need to maintain it over time and potentially different AEM versions. Over the course of the years, the amount of investment into such a custom thing can be significant.)

regards,

Jörg

[mohammadm377380]

Hi Jörg,

Thank you for laying out things for me. I really appreciate it.

This one was due to licensing. We have already purchased the publisher's license instead of authoring. If it was an authoring instance, I wouldn't have gone in to this kind of problem.

Having dispatcher on PROD authoring instance to serve as preview environment will help too but you were right that I need some development time on this.

My initial plan is to intercept workflow schedule then include it in the email that the page needs to be scheduled on that date and time. Then publish the page to go to QA and force to complete that workflow. But it is considered breaking the best practices offered by AEM.

I totally agree with this. I wished that we can go back to the best practices offered by AEM. If it wasn't about the broken Workflow functionality after migrating from 6.1 to 6.3, we don't need this kind of customization.

I'll speak to my team again about your answers. I truly appreciate your input here.

Best,

Mohammad

[Jörg_Hoh]

Hi,

well, I still don't get it :-) A single author should be sufficient for content production and preview, and no dedicated other AEM instance (neither author nor publish) should be needed for it. And the dispatcher itself does not help you in that discussion, that's just a caching layer and cannot be used for preview.

Regarding that broken workflow functionality, can you raise a dedicated topic here? I am quite interested in it.

Jörg