Ad Code

Wednesday, April 22, 2020

AEM Workflow: Request for Deletion Workflow in AEM

Hello Everyone,

Request for Deletion is an AEM OOTB Workflow. In this blog, we will talk about,
1. What is a request for deletion workflow?
2. How it works?
3. What are challenges with this workflow?

Request for Deletion Workflow: This workflow gets initiated when the content-authors don’t have replicate permissions and try to delete a page.

Request for Deletion OOTB workflow has four steps:

Fig1: OOTB Request for Deletion Workflow 

Step1: When an author delete a page, "Request for Deletion" step gets executed and it initiates a notification to the administrators by default (you can change it to approver group).
Step2: When the approver approves the request, the page gets deactivated from the publisher.
Step3: Again a request goes to the administrator or content-approvers to take the approval to delete the page in the author instance.
Step4: When the request gets approved, the page gets deleted from the author server.

Product Bug: When the author deletes the page, a request for deletion notification is visible to the approver inbox, but after the approver approves the request and workflow completes deactivation of page step, the workflow itself aborted after step2.

Because of this issue, the page is getting deactivated from publish but the page is not getting deleted from author CRXDE and because of that all the pages authors deleted in author instance are not visible in Sites console but still sitting in CRXDE.
Fig2: Request for Deletion workflow history to show aborted scenario
I raised it as a day care and this is what they replied.
Solution: “I looked at the code that gets triggered in this event (an event handler). What it actually does is, trigger a Request for deletion workflow with system user wcm-workflow-service, when the user deleting the page does not have enough permission.
Now if you provide delete and replicate permission to that user "wcm-workflow-service" at the /content level the workflow is getting completed successfully.
Always remember that Request for deletion workflow has two participant steps, so you need to approve twice, once for deactivating the page, then for the deletion of the resource step.”

And the above mentioned solution worked for me.
Fig2: Request for Deletion workflow history after fixing permissions
Note: I face the above issue in AEM 6.5.2, so I am not sure what all AEM version has this
issue.So check accordingly.

Client Concern:
Deletion is a very crucial activity which can lead to loss of content/pages if done unintentionally.
That’s why AEM provided approvals at two levels. But in our project, client concern was
that it’s quite annoying for the content-authors, when they just delete a unpublished page
from the author, for this also it asks for two level approvals.

So here we removed the second level approval by considering that if approver approved
at the first step, it means that he really doesn't want that page/content in author as well as
publish.
And i think it really make sense too as it is very difficult to manage so many approvals also.

Fig4:  Workflow model after removing the approval step
Note: Always remember, before you hand over the production server to content-authors, always decide the workflow for request for deletion, make the authors aware about it and test it once because after authors start authoring, and you face this kind of product bug, where pages still exist in author after deletion, you have to fix them by going to the crx and this is hectic task also for a developer and authors.

I hope you find it a good read.Thanks and Happy Learning.

Tuesday, April 21, 2020

Troubleshooting in AEM with real time use cases


Hello Everyone,

In this blog, I will talk about some of the real time issues, I faced while working on a project.
Here we will talk about the problem statement and how to tackle these problems.

1. The multiple PDFs were not able to move to a specific location:  In AEM, ideally you can select multiple PDF’s and move to a specific location. While working on a project in AEM 6.5.2, The authors in this project were able to move a PDF to a certain location but they were not able to move multiple PDFs in one go.

When I found the issue, I checked the console and realized that the OOTB JS
(/libs/dam/gui/coral/components/admin/moveassetwizard/clientlibs.js) is breaking.

I raised this as a Product Bug to Day Care and below is the solution which they provide me.
“This is an issue with 6.5.1 and 6.5.2 which should be fixed in 6.5.3 release”.

Workaround:
The present workaround is to replace line 251 at
/libs/dam/gui/coral/components/admin/moveassetwizard/clientlibs/js/wizard.js
with the below code.
Old code snippet:
var newName = $(".rename-item-name").val().toLowerCase();

New code Snippet:
var newName = $(".rename-item-name").val();

you can create an overlay for the above mentioned JS file and later uninstall it when you plan to install 6.5.3.

2. While using reference components, the authors are not able to decide which component they need to refer in the pathbrowser.

There is a real time scenario where we need to use the same component in several pages and for that particular use case reference component is very helpful. 

Let's suppose we are having some tables which are being shown in many pages. Now suppose the author created a page "P" to put all the tables and try to reference the tables in actual pages from that centralized page.

Now as the page "P" is having so many table components, so while using reference
components to point to a specific table, it is difficult to identify by the content-authors which table they need to point, because in the pathbrowser, the component node name is being shown.

Fig1: Reference Component dialog for choosing a table component

While debugging out the pathbrowser behavior, I figured out that in
“/libs/granite/ui/components/foundation/form/pathbrowser/render.jsp”, line No 42,
the pathbrowser shows the “jcr:title” of the resource value and if not available then shows
resource name.
Fig2: PathBrowser component render.jsp logic
So to solve this issue;  We can provided a title field with name property “jcr;title”
in table component so that if the authors can provide a “title” to the table to define what this
table is about, then in the pathbrowser, the title will be visible and authors are able to
point to the correct component while using reference component.

You can do it for all the components by making a generic tab, so that whenever authors
face this issue, they can immediately provide a “jcr:title” to the component.
Fig3: After providing jcr:title the view in pathbrowser in reference component


3. While login via a user which is part of "content-authrs" group, the “Modified By”

for Asset is visible as “External User” but not as the actual person name:
Usually to set up content-authors permission for a specific project, we take reference
from OOTB content-authors and then add more permissions based on the additional
hierarchies for the specific project.

But there can be some permissions which AEM OOTB content-authors don’t have but you need to provide them.
For the assets, content authors are not able to see who modified the image last, but can
see “External User” as ” Modified By”  for all the images.
Fig4: The "Modified By" as "Extenal User"  while logging from content-authors


Solution: I go through the code and found out that the column preview ‘s HTML is
getting rendered from here:
/libs/dam/gui/coral/components/admin/contentrenderer/column/columnpreview/columnpreview.jsp
Fig5: The logic from where modified by is visible in Assets columnnview


So basically to fetch the value of "Modified by" the code is trying to get the formatted Name which can only be accessible when the author has "/home/users" permission.
To solve this issue, you need to give read permission to “/home/users” hierarchy to content-authors and it will start showing the actual user who modified the assets last.
Fig6: After fixing the permission, the "Modified By" is showing "Actual User"

I hope you find it a good read.Thanks and Happy Learning.

Saturday, April 18, 2020

Issues in sorting the results based on Published Date in AEM

Hello Everyone,

Problem Statement:
Need to sort a page hierarchy based on the last published date. So the page which is
being published last, should be visible first.

The problem looks very simple but it was not that simple. Using an AEM query, pages can be sorted based on "cq:lastReplicated" and it works perfectly fine for the author. But when the code is being deployed in the publish server, the query was not giving same results as author.

Here is the query to sort pages based on cq:lastReplicated:
path=/content/we-retail
type=cq:Page
orderBy=@jcr:content/cq:lastRelicated
orderby.sort=dec

Why the query was not providing the same results in Publish as author?
The publish server doesn't have "cq:lastReplicated" property and that’s how the logic is getting failed.

What I tried?
Approach 1: After a bit research, I found out that "cq:lastReplicationAction, cq:lastReplicated, cq:lastReplicatedBy properties are not carried over the publish by OOTB AEM design". In order to carry these properties, disable this component "com.day.cq.replication.impl.ReplicationPropertiesFilterFactory" in the author instance.
Fig1: com.day.cq.replication.impl.replicationPropertiesFactory Component
The components gets enabled when the server restarts.To make it not getting enabled on server restart, Use "ACS AEM Commons -OSGi Component disabler" OSGi configuration to disable it permanently.
Fig2: ACS AEM Commons-OSGiComponent Disabler COnfiguration
After this, when a page gets activated, all the replication properties started to be carried over to the publishing server and it seems that the problem is solved now, but still the results were not same as expected.

Why this approach didn't work out?

1. If a new page gets created in the author at 2:00 AM and publish the page then there is no cq:lastreplicated in the publish server for the first time.

2. If you have a page being published at 2:00 AM and now you are again publishing it at 3:00, the lastReplicated Date in the publish server will be 2:00 AM because when a node gets replicated from author, first it goes it to publish and then it update the date in author. So by this, publishers were not having the replicated date matched by the author but one step behind the author.
cq:lastReplicated Date in author ≠  cq:lastReplicated Date in publish

So making "cq:lastReplicated" property available to publish didn’t solve the problem.

Approach 2: Then I realized that the "cq:lastReplicated" date in the author is the same as "cq:lastModified" date in publish. Because for publish when it gets the data, it consider that as last modified for the node.Ideally these values will be the same (ignoring seconds), if a page gets published and it immediately goes to the publish server.

Note: publish server don't take the cq:lastModified date from author, but it updates it's own date based on when it gets the data.
It means cq:lastModified date is not carried over to publish from author.

So then how we can conclude this:
cq:lastReplicated Date in author   cq: lastModified date in publish

Conclusive Points: So now there are two ways:
1. Either you can make your query based on the "cq:lastModified" date for both author/publish  but you need to make the author aware that in author, results are based on last modified but in publish, it will be based on like the last Published date.
2. Or you can make your query based on the run modes. If run mode is author make the query based on "cq:lastreplicated" date. But in case of publish, make the query based on the "cq:last Modified" date.

So that's how Approach 2 solved the issue.

I hope you find it a good read.Thanks and Happy Learning.

Thursday, April 16, 2020

Request to Complete Move Operation Workflow in AEM

Hello Everyone,

Today I will talk about an OOTB workflow provided by AEM which is “Request to Complete Move Operation” Workflow.


A little Background:
Usually to maintain a website from the content-authoring point of view, we maintain two
groups one is content-authors and other is content-approvers.

Content-authors: This group is used to do content authoring and don’t
have replication access. which means they can not publish the pages and make them live.
Content-approvers: The people in this group review the content and publish the pages.
Ideally they used to have all the permission which content-authors are having with
additional permission of replicating the pages.

How Move operation work and it’s behavior:
If  approver (or anybody having replication access) is doing the move operation-
1. If the page is not published anytime before,then the move operation will only happen in author and page will not be get published until approver really publishes it.

2. If the page is already published then the move operation happens in author and publish both. Ex: If page P, in A hierarchy is already published and approver is moving it to B hierarchy, then the Page P  from A hierarchy will get deleted from the author as well as publish and the page P will start appearing in B hierarchy in the live site .

When the workflow (request to move operation) gets triggered??
If the move operation is done by content-authors (not having replication permission) then the
OOTB workflow “request to move operation” gets triggered. Now approver
has to approve the workflow to make it function like the above mentioned move operation.

Client Concern:
There are so many content-authors, which are constantly moving pages from one place
to another and there are a lot of “request to move operation” inbox notification for approvers.
Clients don't want this workflow to be there, because there are hundreds of pages for which they are doing content pop and not living soon. They are still deciding hierarchy and in this process they keep on moving pages. In such scenarios, there are always so many workflows running.

What will happen If we remove the workflow :
If content-author moves the published pages, then this movement will happen in author
only and then how i will make this move operation available in publish server.
Ex: If page P, in A hierarchy is already published and author is moving it to B hierarchy,
then the Page from A hierarchy will get deleted and will start showing in B hierarchy in author.
If they ask the approver to publish the page P from B Hierarchy, then the old page “P” is
still available in A hierarchy in the publish server  and will never get deleted so we suggested
the client not to remove this workflow.

How we can solve client issue:
What we suggested is, We will add one step in the workflow which will check if the page
is published/unpublished. If the page is unpublished, we will end the workflow, else the request
will go to content-approver and the workflow will be executed like it is happening right now.

Product Bug:
We are having author/approve groups in place for our AEM servers.Ideally content authors
don't have replication permission and because of this when the author moves a page the
"Request to Complete Move Operation" workflow is triggered. 

Now take an example if the Page "P(Considering that the page is already being published and visible on live site)" is under "A" Hierarchy and an author trying to move it under "B" hierarchy Then the workflow triggers.

If without completing the workflow, approver publishes the "P" page sitting under "B" hierarchy,
then the workflow “request to move operation” workflow instance is also getting aborted and
now on the live site "P" page can be seen under A and B both hierarchies and there is no
other way to delete the "P" page from "A" hierarchy,

Note: Because the page is already being moved to B hierarchy, so in author "A" hierarchy don’t have a "P" page anymore.So approver can’t unpublish the old page.
The issue is when an approver publishes the page, they don't even check if the "Request to Complete Move Operation" is running for that particular page and if they publish the pages,then there is no way to delete the old page (P under Hierarchy A) in publish server.

I raised it as a Day Care ticket and will update here if Adobe comes up with any solution.

Workaround Solution by providing guidelines:
1. We can make a guideline for content-authors not to move the page but to ask content-approvers to do that to avoid so many notifications for move operation or to avoid the workflow enhancement.

2. We can ask content-approvers that before publishing a published page, at least check if there is any move operation workflow for that page  running or not. If it is running, Complete that in place of publishing the page.
Once an approver opens the page during workflow execution, they may see a blue bar on the page with the following message:

But again guidelines can’t stop human error, So if
  • If content-authors are moving the pages then Be ready by completing so many workflows or make the workflow enhancement to solve this issue.
  • if content-approvers are publishing the page for which move operation is already running, be ready to delete the pages in prod publish servers by going in CRXDE.

I know this is a long and very theoretical but i hope it is a good and interesting
read for you.Thanks and Happy Learning