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
BedrockMission!

Learn More

View all

Sign in to view all badges

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

Avatar

Avatar
Validate 1
Level 2
kimonp31365843
Level 2

Likes

9 likes

Total Posts

31 posts

Correct Reply

2 solutions
Top badges earned
Validate 1
Ignite 3
Ignite 1
Give Back 3
Give Back
View profile

Avatar
Validate 1
Level 2
kimonp31365843
Level 2

Likes

9 likes

Total Posts

31 posts

Correct Reply

2 solutions
Top badges earned
Validate 1
Ignite 3
Ignite 1
Give Back 3
Give Back
View profile
kimonp31365843
Level 2

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