Highlighted

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

kimonp31365843

17-02-2020

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.

AEM AEM 6.4 API Assets S7 workflow