Expand my Community achievements bar.

SOLVED

Unable to unlock pages using workflow-process-service eventhough it is the lock owner

Avatar

Level 2

Hi,

 

In one of our workflows, we are using a "Lock Payload Process" to lock the page and the page is being locked by "workflow-process-service" service user. We are now trying to add multiple schedulers in the next Process Step. These schedulers will trigger at different time from the time the Process Step executes. As part of one of these schedulers, we have to unlock the page and then terminate the workflow.

 

When the scheduler triggers, as it is not possible to use the original workflow session anymore because the session is automatically being closed when the workflow step ends. So as suggested in Processing Events, Replication Preprocessors and Jobs, I tried creating a subservice that points to "workflow-process-service" and then obtain it's resource resolver from resource resolver factory. I am able to adapt resource resolver into workflow session and then terminate the workflow. But, when I try to unlock the page by adapting the payload's resource into Page API's and using it's unlock method, I am receiving "not an owner of the lock" error even though the session created is from the same service user that locked the page (jcr:lockOwner: "workflow-process-service"). even with page.unlock() I am getting a true.

 

Now, If I move that unlock code out of the scheduler and use it with the original unclosed session during that process step itself, I am able to unlock the page without any issue. What is the issue with the approach? What else can be done to unlock the page?

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

You may let your workflow which locks the page set to handler advance = true and let it run to completion.

Then in your scheduler code you may programmatically trigger another workflow with "Unlock payload process" in it.

View solution in original post

6 Replies

Avatar

Community Advisor

1. Check resourceResolver.getUserId() in your scheduler, wether it is "workflow-process-service" or "anonymous"
2. Check this code for reference


HashMap<String, Object> param = new HashMap<>();
param.put(ResourceResolverFactory.SUBSERVICE, "wfservice"); //service user workflow-process-service mapping
try(ResourceResolver resourceResolver = resourceResolverFactory.getServiceResourceResolver(param)){
Resource lockedResource = resourceResolver.getResource("pagepath");
Page page = lockedResource.adaptTo(Page.class);
try {
page.unlock();
} catch (WCMException e) {
log.error("Exception {}", e);
}
} catch (Exception e) {
log.error("Exception {}", e);
}


3. Alternatively, you may use "Unlock payload process" in WF to achieve page unlock

Avatar

Level 2

@shubhanshu_singhthe userid for the resource resolver I am using is "workflow-process-service".

 

About you 3rd point, is it possible to programmatically move to some process step / the last step (which would be "Unlock payload process") from anywhere in the workflow?

Avatar

Correct answer by
Community Advisor

You may let your workflow which locks the page set to handler advance = true and let it run to completion.

Then in your scheduler code you may programmatically trigger another workflow with "Unlock payload process" in it.

Avatar

Level 2

@shubhanshu_singhthe logic you suggested works fine for my problem. But I am still curious on why the WorkflowSession created from workflow-process-service is unable to unlock the page even though it is the actual owner of the page lock, but the page is unlock-able if I use the WorkflowSession from execture method? I have checked multiple times if I am using the correct service user.


workflowUserResourceResolver().getResource(workflowItem.getContentPath()).adaptTo(Page.class).getLockOwner().equals(workflowUserResourceResolver().getUserID()) //returns true

Avatar

Community Advisor

I tried to replicate it by creating a workflow and a scheduler that unlocks using the service user as you stated, I was able to get the page unlocked.

Avatar

Level 2

Then it looks like I am missing something in my implementation. thanks for confirming, and your logic of triggering a different workflow too unlock works fine for me. So, i am accepting your answer as correct reply.