I was approached by a colleague about configurations necessary to get BPMs with custom code execution firing “Asynchronously” to work after they started to experience failures on previously working async BPM code.
I have avoided any async. BPM custom code for this reason, but I’d really like to know more about what’s going on under the hood for the custom action to be executed asynchronously versus synchronously.
Perhaps someone with more knowledge can speak to this!
The test I performed was to create a pre-processing BPM on UserProcessWrapper. In the BPM I simply execute a for loop and write numbers 0-99 in a file.
If I set the custom code to execute Asynchronously and then invoke the method, nothing happens.
I can see in the System Monitor that my process was indeed invoked and did not fail.
In the BpActionQueue/Data tables, there are zero records. I would assume that the BPM would have written out to these tables and the Task Agent would process them as threads become available.
From the Help, the Async. tag on a custom code block indicates the what I described above and that the System Task Runner is responsible for polling those tables every 20 seconds and executing the actions in the queue asynchronously. I’m not sure what the Task Runner is, but I assume its a component of the Task Agent.
The Task Agent in that environment is running correctly and I even restarted the service, but the same behavior persists.
Obviously, you’re not interested in writing numbers to a file. What is the business case? This matters as to what information will be available to your code when it is running. In async, you have to pass everything necessary because the context might, er, probably will change before your process completes.
I see your point, but the question of “why is this not working” is still independent of the business case.
An integration design that writes to a table with all the data necessary and a separate process to consume the data might call for the consuming of the data to be run asynchronously. In this case, the design is still broken as async. does not work
I can’t answer the important part of your question, but I can talk about System Task Runner. It is basically a BO method that Task Agent calls every 20 seconds. You can turn on server side logging to make sure that the method is actually being called, but that doesn’t sound like your issue. Another tidbit is that even though it is called every 20 seconds, execution will be skipped if it is already processing. This doesn’t sound like your issue either since eventually it would get processed.
So in your case the BPM runs as the app account running the Epicor App Server instance so writing to a network drive is gonna be tricky.
It should work, however you are correct Async BPMs are broken to hell and back in all versions of e10.
They mostly ish sometimes work, but they fail silently and accumulate for ever. I have it on good authority this is being addressed we’ve reported these bugs many times, but as of right now, async is a no go. IMO
However I’m guessing your issue is a permissions one, try writing to a local file in th C:\ drive of the Epicor server.
I had one running for a month and it made something like 100K entries in the AsycBPM tables because 1 of them failed. As soon as ANYTHING fails everything else just stops processing.
I have also tried this test writing to a file on that server, but same results. At the very least I would have expected a record to be written to the BpActionQueue/data tables, so I wonder if this might be a point of failure
Also depending on your version you may have to run a process (async BPM process) look in your menu. They got rid o that in some version but I can’t remember if its 10.1, 10.2 or what.
Regarding it writing a record to the BPAction queue that it should do, I’m wondering if your Condition is not being met?
Also since this is the Custom user Process scheduler they may not necessarily play by all Epicor’s Standard rules. Try it on say ABCCode
Not going to disagree with you there. The reason I asked about the business case is maybe there are alternate ways to do what you want to do depending on what is doing the consuming. There may be better ways of setting up a queue than passing data through the file system.
Agreed. Like I said, I design my integrations to be independent of this tool, but I think it’s a valuable discussion to figure out why this isn’t working as designed for those who do want to utilize what is presented as base functionality.
In all seriousness, the implementation of the async feature is quite old and is almost an anti-pattern - to me anyway. I cannot think of a good SOLID design case for it - specifically the Single Responsibility Principle. Maybe others can chip in with one.
I have a process that reports labor for an integration with our laser software. It can take 30 minutes to run. Using sync, Epicor is locked up until the process is done. If I could do it async, I could let the user go back to whatever he needs to do. (like close Epicor and leave)
Describe the process. Epicor sends something to the laser machine? At what command in Epicor? After thirty minutes, what are you reporting back to Epicor? Qty? Machine time? Labor? Quality info?
I run a BAQ, then I have BPM’s process through the list that is returned to do the labor and material reporting. The information is static at the time the BAQ is run.
