AEM 6.4 Assets | DAM Update Workflow fails but shows as RUNNING

[kimonp]

As per default AEM behaviour, when uploading/updating an Asset, DAM Update Asset workflow is triggered - in our setup this includes a S7 upload step.

Problem:

In some cases we get an exception such as

• repository conflict exception for an asset,  or
• S7 timeout exception as shown below

com.adobe.granite.workflow.WorkflowException: --Dynamic Media asset process failed. Please contact your system administrator.-- /content/dam/myasset.jpg
	at com.day.cq.workflow.compatibility.CQWorkflowExtProcessProxy.handleResult(CQWorkflowExtProcessProxy.java:99)
	at com.adobe.granite.workflow.core.util.WEPProxyHolder.handleResult(WEPProxyHolder.java:50)
	at com.adobe.granite.workflow.core.job.ExternalProcessPollingHandler.process(ExternalProcessPollingHandler.java:129)
	at org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:502)
	at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:293)
	at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:60)
	at org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:229)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: com.day.cq.dam.scene7.api.model.IpsApiException: org.apache.http.NoHttpResponseException: s7sps3apissl.scene7.com:443 failed to respond
	at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.makeRequest(Scene7APIClientImpl.java:356)
	at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.searchAssets(Scene7APIClientImpl.java:1178)
	at com.day.cq.dam.scene7.impl.Scene7ServiceImpl.searchAssetsByFilename(Scene7ServiceImpl.java:489)
	at com.day.cq.dam.scene7.impl.process.Scene7UploadProcess.getAssetHandle(Scene7UploadProcess.java:871)
	at com.day.cq.dam.scene7.impl.process.Scene7UploadProcess.handleSingleAssetUploadResult(Scene7UploadProcess.java:1078)
	at com.day.cq.dam.scene7.impl.process.Scene7UploadProcess.handleResult(Scene7UploadProcess.java:1020)
	at com.day.cq.workflow.compatibility.CQWorkflowExtProcessProxy.handleResult(CQWorkflowExtProcessProxy.java:97)
	... 9 more
Caused by: org.apache.http.NoHttpResponseException: s7sps3apissl.scene7.com:443 failed to respond
	at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
	at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
	at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
	at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
	at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
	at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
	at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
	at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.getResponse(Scene7APIClientImpl.java:424)
	at com.day.cq.dam.scene7.impl.Scene7APIClientImpl.makeRequest(Scene7APIClientImpl.java:342)
	... 15 more

In such cases, the failure shows as an inbox notification (thus allowing us to manually identify such failures and retry the step).

However, the workflow instance itself shows as "Running" instead of "Failed", which 

• imho is a bit counter-intuitive
• we cannot effectively get such failed workflow instances via AEM Workflow REST API

The above can occur for a failure at any step, the repo conflict is the most common issue we get however.

Question(s):

• is there a workaround for this, to allow the aforementioned API usage?
• is there an effective (ideally OOTB) way to retry the failed step?

Thank you in advance for your help.

[Vinodthakur]

Hi @kimonp 

Did you get any solution to this problem?

Thx.

[kimonp]

Hi @Vinodthakur ,

Unfortunately no - eventually we just checked the WF instance node properties to get the failing status, so no direct indication of failure.

Kind regards

[kchaurasiya]

@kimonp I think you might be storing the assets in  S7 instead of DAM it seems this issue is related to the connectivity with S7 . You need to check the corresponding API properly. If you are using any java service in the S7 upload step then try to debug it through debugger to check code step by step your code.

Thank You.