Expand my Community achievements bar.

SOLVED

Review in Staging, then psuh directly to Production

Avatar

Level 1

We are looking for a way for internal marketing users to review AEM pages before they go live. 

In the past, we used a Staging environment to review pages then, once approved, those pages and all dependencies were pushed to production/live.

How can we mimic this in AEM by giving non AEM users a way to review pages or review a new section then, once approved, push that live?

Thanks.

-Kevin

1 Accepted Solution

Avatar

Correct answer by
Administrator

A workflow can be developed with following steps

Author Initiates workflow -> Replicates content to internal publish server. AEM provides ReplicationOptions API. This can help selecting the replication agent using public void setFilter(AgentFilter filter). Agent can be named as per requirement, regex can be used to match required agents as given in link reference. A workflow process can be created for this. The request would reside with approver (Using Participant Step). Approver can now verify the content on internal publish server.
Once approver approves content, on Approval another workflow process push the content to public publish server, here also we can use public void setFilter(AgentFilter filter)
If multiple pages/assets need to be published, Workflow Package feature can be used to bundle multiple pages/assets. This of-course needs adding the code in Workflow Processes created in step 1, 2 to publish pages/assets by iterating over payloads that are part of workflow package

Source :- http://stackoverflow.com/questions/35315967/cq-aem-staging-concept-with-workflows

You would have to implement several things to allow this work:

  • You need replication agents for all the production publish servers and the staging servers. To simply your life you will probably want to set up your dispatcher agents on your publish and staging servers so you don't have to deal with them during the workflow. 
  • You need to decide how you want the standard activation tools to behave (activate button, activate later, other possible workflows) behave. You have a couple of options:
    • Have the default activation behaviors publish to both environments
    • Have the default activation only publish to production publish
    • Have the default activation only publish to staging
    • Have the default activation do nothing
  • Based on that decision above you may have to check the Ignore Default option on the Triggers tab of the replication agents that shouldn't get anything on the standard publish.
  • Create a workflow process that will publish only to selected publish instances. Most likely this will be a step that only publishes to your Staging server, in which case you need some configuration mechansim which identifies which replication agents are staging agents.

Source :- https://forums.adobe.com/thread/1255002

~kautuk



Kautuk Sahni

View solution in original post

4 Replies

Avatar

Correct answer by
Administrator

A workflow can be developed with following steps

Author Initiates workflow -> Replicates content to internal publish server. AEM provides ReplicationOptions API. This can help selecting the replication agent using public void setFilter(AgentFilter filter). Agent can be named as per requirement, regex can be used to match required agents as given in link reference. A workflow process can be created for this. The request would reside with approver (Using Participant Step). Approver can now verify the content on internal publish server.
Once approver approves content, on Approval another workflow process push the content to public publish server, here also we can use public void setFilter(AgentFilter filter)
If multiple pages/assets need to be published, Workflow Package feature can be used to bundle multiple pages/assets. This of-course needs adding the code in Workflow Processes created in step 1, 2 to publish pages/assets by iterating over payloads that are part of workflow package

Source :- http://stackoverflow.com/questions/35315967/cq-aem-staging-concept-with-workflows

You would have to implement several things to allow this work:

  • You need replication agents for all the production publish servers and the staging servers. To simply your life you will probably want to set up your dispatcher agents on your publish and staging servers so you don't have to deal with them during the workflow. 
  • You need to decide how you want the standard activation tools to behave (activate button, activate later, other possible workflows) behave. You have a couple of options:
    • Have the default activation behaviors publish to both environments
    • Have the default activation only publish to production publish
    • Have the default activation only publish to staging
    • Have the default activation do nothing
  • Based on that decision above you may have to check the Ignore Default option on the Triggers tab of the replication agents that shouldn't get anything on the standard publish.
  • Create a workflow process that will publish only to selected publish instances. Most likely this will be a step that only publishes to your Staging server, in which case you need some configuration mechansim which identifies which replication agents are staging agents.

Source :- https://forums.adobe.com/thread/1255002

~kautuk



Kautuk Sahni

Avatar

Level 1

Thank you so very much for this! 

Question for you: does the Adobe Replication API cost additional subscription fees etc? 

Also, from an effort perspective, how long /much effort is required to executing this functionality?

Thank you, 

M

Avatar

Employee Advisor

Hi,

I would not use the staging environment for that, unless you think of "staging" as in "content staging" environment and you don't use this environment to run final validation on your application before you deploy it to PROD. And that "content staging" environment would then be a production environment as well, because without it you cannot update your content!

And then: What's the role of your production author then, if you don't use it for review and approval?

As described by kautuksahni, implement approval and validation processes on PROD authoring and don't develop a cross-environment content-promotion workflow. That's not in the philosophy of AEM.

Jörg

Avatar

Level 1

Thanks for this reply. Do you have any experience creating review workflows that really limit what a reviewer can do/see? My problem is that we are small, and I don't want to train people to use author who are just looking to review. What I do now is take the PROD author URL, delete the "editor.html" in the URL, send the direct link with a generic login. But they lose the ability to make notes, etc...

From what I'm seeing here and elsewhere, the best answer would be to do some limited Author training for all reviewers, use the workflow, and hope they don't screw anything up :-)

But I'm glad you confirmed that a cross-environment approach isn't good. Someone here recommended that to me, and I thought it counter-productive.