Hi. We have a BPM that when something in the order header is changed, it automatically changes the Need By Date to some custom value that is pulled from the Product Group table. The issue is that when our webservice creates a sales order header, it does not trigger the BPM. I’ve assumed that this is because the API skips the ERP and goes straight to the business object, so since the BPM is triggering based off changes in the ERP it misses it (I’m not 100% sure about the reason, but I’m open to being corrected even if it doesn’t solve the actual problem).
Is there any way to have the BPM trigger off of a REST call?
Sorry, I’m not sure exactly which details you’re looking for on what kind of BPM. It’s a method directive with both pre-processing and post-processing if that helps? The pre-processing basically checks if one of the Quantities or the Need By Date has been changed in ttOrderDtl or ttOrderRel and then enables the post-process which reads the product group table and calculates the new need by date for the whole order.
The Rest calls make a POST to SalesOrderSvc/SalesOrders and SalesOrderSvc/OrderDtls.
I don’t work with BPMs enough to know the differences but I do know there are different types like standard, in-transaction and method directives. Although how exactly they work under the hood is another topic.
To which method are you attaching the directive? It seems you are using the OData REST endpoints instead of the custom methods, so it must be using UpdateExt which could be bypassing whatever method you attached the BPM to.
Thank you! That makes sense, and at the very least gives me more things to try. I’m kind of having to parse out the different pieces of the BPM as I go along since it was created by an Epicor consultant as part of our transition (we just went live in Epicor this week and I was only brought into the company 2-3 months ago on top of that). So that definitely looks like something I can run with at least to try and get started. Thanks again!
Since UpdateExt calls Update, then directives on the Update method should work too.
Only exclusion - BPM Form Action. It should not be used on the “inner” method and will throw exception. But I doubt that BPM Forms are relevant for REST calls.
The way I’ve always approached REST is to first trace out what BO methods are called when you do something in the UI. For example, when changing PartNum on an OrderDtl, it doesn’t just set PartNum and call Update. First it calls ChangePartNum, which has side effects. Perhaps more importantly, there could be BPMs on ChangePartNum that will not run if you don’t call it. The huge number of BO methods potentially involved in any simple change is one of the reasons I’m converting my BPMs from method directives to data directives wherever possible.
When it comes to REST, Epicor Functions encapsulate all of the calls and keeps them off the wire which improves speed and reduces upgrade work since I don’t have to fix any client code.
And remember, a Data directive gets called for every read or write operation. If others follow Kevin’s advice and use Data Directives, be sure to put conditionals in there early or things can really slow down.
I should point out that my approach is old school. I’m stuck on 10.2.100 so don’t have access to Epicor Functions yet. And yes, the first thing in my data directives is usually a condition. Many of them read like, “if this checkbox is checked and one of these other fields changed, raise an exception…”