I have some custom code element in a BPM that marks a pack as ready to invoice. The code that works well in a method directive.
BPM Call to UpdateMaster on Shipment
But when I copy it to a data directive so I can schedule it using this method,
creating-a-custom-scheduled-task-within-epicor
it no longer creates the PackOut and relieves inventory. Any idea why the different behavior when moved to a different kind of directive?
Thanks
What I’ve found is that a method directive by definition contains a temporary table related to the method being used as a trigger. For example, a post-processing directive based on SalesOrder.Update() has to have a copy of the OrderHed table (I think it’s called ttOrderHed).
A data directive, if I understand correctly, acts on changes to a given table. Those changes could come from any number of possible methods, so there would be no reason (and no opportunity) to load default data.
So in a data directive where custom code is used, you trigger based on a table, refine your trigger based on criteria (with a condition widget, for example), and then your code can act on any method or table you want.
It’s easy to call data (use Db.[TableName]) but it’s also easy to mess up the database. I’ve learned the hard way and thanks to advice on here to rely on method calls and not database manipulation.
I would not recommend this method at all. You can still do a scheduled task using a BAQ at 500 (which it appears you are on from your user card) by just adding the code you need to the GetList method of a UBAQ and scheduling it. Don’t mess with system task tables. Once you are on 600 you can schedule an Epicor Function and take the BAQ part out of it too and truly write your own process. I don’t recall that might even be available on 500 (but not likely)
Oh, that’s interesting. I saw the same GingerHelp article a bit ago and have used this a few times to schedule things. I’m on 10.2.100 and figured seeing I was reading only it was ok.
What do you figure are the downsides?
Write some bad logic and you bring down printing, mrp, the whole sheebang vs one BAQ. When troubleshooting isolation is your friend. You’re on an older version would be relegated to this method or a custom program to fire off BAQs from windows task scheduling using BOs (this is how we did it back then a lot of which have not been converted yet)
Get to 200 and you can then trip them off with the REST API. Chop Chop!
indeed. Well, by the time we upgrade it’ll be to whatever is latest for on-prem, so as a minimum we’ll have functions.
Also Data Directives heavily impact performance. They are a sledge hammer for almost everything and to quote @Bart_Elia should be used as a last ressort.
Go with the UBAQ GetList or Functions as suggested.
I am going to give it a try. Even if it does not solve the issue of the code acting differently , it sounds like a step in the right direction.
I updated everything to a scheduled UBAQ using the GetList directive as suggested, and now it all works as desired. Thanks for the help!
