Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

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

Avatar

Level 4

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.

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

0 Replies

Avatar

Level 4

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

Avatar

Level 6

@kimonp31365843 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.