Agile PX and ACS Event Processing Order

Hello all,

I’m trying to identify the order of operations when it comes to events in Agile.

Upon the release of a change order, do process extensions (PXs) execute and complete before ACS events fire? We want to set a field value that will be used as criteria by the ACS subscriber to determine if a change order PDX should be exported.  The field must be set before ASC is triggered.

Thanks in advance,
Drew

Agile User Asked on July 7, 2021 in Product Collaboration.
Add Comment
2 Answer(s)

Hi Drew

For your use case, both PXes and ACS will get triggered in parallel. So, there is no guarantee that ACS will have the right data before it gets triggered

One option is to move the PX code to a Pre event and make it synchronous. In that way, the change won’t get released until it sets the field that ACS will be looking at

Hope this helps

– Raj

Agile Angel Answered on July 8, 2021.

Thanks for the advice Raj!

I was looking at this from a custom PX and not Java PX perspective.  We’ll proceed with using the Pre event Trigger Type and setting the execution to Synchronous.

Thanks again!

Drew

on July 8, 2021.

A Java PX has been created which sets a change order’s List field value to “Yes” when moving from Pending to Submitted status; however, the change order will not advance to Submitted (stays in Pending).  The message returned is “ECO 69390 has been modified. Please cancel this action, refresh the page and try again.”

Do you know how to get around this issue?

Thanks,
Drew

on July 12, 2021.

Didn’t see this comment until now

Can you please try to make this event subscriber as POST and Synchronous? I think it is set as Pre and hence it isn’t giving this error

on July 15, 2021.

Hi Raj,

This does work (setting from “Pre” to “Post” trigger); however, does this present a race condition?  Will the JavaPX always execute and complete before the ACS tool generates its ATO?

on July 19, 2021.

Hi Drew,

Was going through this thread, so two cents from my side.

I believe anyhow you won’t be able to control whether the event sets the flag value first and then the ACS event gets triggered because both of them are triggered in two async threads by the system.

You can give this a try, not sure if this will be 100% full proof: keep the event subscriber as Pre, spawn a new Thread, set the flag attribute’s value from that new Thread, and let it complete. You might see some messages like “Someone was working on this object, please try again later” or “Please cancel this action, refresh the page and try again” in the History of the object, but in spite of that the value should get set from the Pre subscriber itself.

on July 28, 2021.
Add Comment

I don’t think so. Are you seeing any issues during your testing?

Agile Angel Answered on July 21, 2021.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.