Hi Bryan.
The only way I know that you can see if a async workflow has been posted/executed is by checking the table BPA_ASYNC_SYS_TAB.
You can create a Quick Report that runs SQL query “SELECT * from BPA_ASYNC_SYS_TAB” to access that information easily from IFS Cloud.
Most probable situation is that your workflow is well designed to be run “AFTER” but it has some problems when run “ASYNC”. When it’s run “ASYNC” it is posted in the table BPA_ASYNC_SYS_TAB, then it’s executed by the workflow engine and it fails without leaving any trace. I had this experience before. You can check the status column and see that it gets stuck in status “IP” which stands for “In-progress” most likely.
To resolve this situation you can create a new version of the workflow, remove some of the sections, just create a simple workflow and try the execution. Check the table BPA_ASYNC_SYS_TAB and see if the status is “DONE”. Then that means it run correctly. Next, add more logic to the workflow and check again. Keep doing so until you detect the issue.
Most of the time I found that the problem is with a “Projection Delegate” activity where you try to update using a old ETag value. In such situations try passing “*” as ETag value.
OData Upsert and * ETag Support (ifs.com)
From the link above:
Working with * ETag
IFS OData Services provides optimistic concurrency control through the use of If-Match Http Header for a number of applicable scenarios. While it provides a valuable protection against Loss Updates in interactive clients, it may be an unnecessary complication for system to system integration.
- It is now possible to send the If-Match header with the value *, which is interpreted as to match against any value available in the particular resource.
- The Entity bound operations - Update, Delete, Upload (Streaming), State Event Actions; which previously required an exact ETag match now works with * ETag.
I hope this info helps you a bit.
Thank you much.
Best regards.
Gonzalo.
