Level 2

Custom Delete Workflow for XFS and CFS

Forum|Forum|9 months ago
May 6, 2025
2 replies
538 views

We have a requirement to implement a custom delete workflow to handle the deletion of multiple XFS and CFS instances. As part of this process, the workflow should generate a single, consolidated notification indicating whether each asset was either deleted or locked.

Additionally, in cases where an asset is locked, we would like to explore the possibility of automatically re-triggering the workflow once the asset becomes unlocked.

Has anyone implemented a similar solution, or are there any best practices you could share?

AmitVishwakarma

Community Advisor

Hi @harshak11490245 ,

Custom Delete Workflow for XFS and CFS (with Lock Handling & Retry Logic):

Try below steps:

1. Custom Workflow Step

Create a Process Step that receives a payload list of XFS/CFS paths (could be passed via workflow metadata or fetched from a list node):

@Override
public void execute(WorkItem workItem, WorkflowSession session, MetaDataMap args) throws WorkflowException {
    WorkflowData data = workItem.getWorkflowData();
    List<String> assetPaths = getPathsFromPayload(data);
    
    Map<String, String> resultMap = new HashMap<>();
    
    for (String path : assetPaths) {
        Resource res = resourceResolver.getResource(path);
        if (res == null) {
            resultMap.put(path, "NOT FOUND");
            continue;
        }
        Node node = res.adaptTo(Node.class);
        if (node != null) {
            if (!node.isLocked()) {
                node.remove(); // or use assetManager.removeAsset() if in /content/dam
                resultMap.put(path, "DELETED");
            } else {
                resultMap.put(path, "LOCKED");
                addToRetryQueue(path); // Your retry mechanism
            }
        }
    }

    storeResult(workItem.getWorkflowData().getPayload().toString(), resultMap);
}

2. Retry Mechanism for Locked Assets

Use one of these:

Option A: Sling Scheduler (recommended for AEMaaCS)
- Store locked paths in a custom node (e.g., /var/delete-retry-queue).

Run a Sling Scheduler job every few minutes:
- Re-check lock status.

- If unlocked, delete and update status.

Option B: JCR Event Listener
- Listen to unlock events (javax.jcr.lock.lock).
- If asset was previously locked and queued for deletion, re-run deletion logic.

3. Consolidated Notification
Create a summary like:

Deletion Summary:
- /content/dam/xf1 → DELETED
- /content/dam/cf2 → LOCKED (retry scheduled)
- /content/dam/xf3 → NOT FOUND

Then send using:
- AEM Email Service (MessageGatewayService)
- Or external system via webhook, Slack, etc.

4. Workflow Model

Input: List of paths (from workflow metadata or a folder).

Steps:

- Custom Step to check/delete

- Notification Step

- Optional: schedule retry if any locked

Note:
Ensure service user permissions to delete fragments.
Avoid long workflows — offload retry logic to scheduler.
Log each operation for audit/debug.
Use granular exception handling to isolate failures per asset.

Regards,
Amit

aanchal-sikka

Community Advisor

@harshak11490245 Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

Aanchal Sikka

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded