PERFORMANCE PERFORMANCE PERFORMANCE. That’s always my end goal.
With that in mind, what is the best way to go about determining if functionality should be in a method or data directive?
I understand the differences of both, just not to familiar on understanding the different real-world scenarios where one makes more sense over another?
As an example we have a nasty in-trans data directive on the orderRel table that sets warehouses on incoming EDI demand orders. Wouldn’t it make more sense to run this using a method directive on the demand BO objects?
I always hear data directives are heavy, and should only be used sparingly and concisely.
How does the community decide on where to place functionality?
My humble opinion is, unless absolutely impossible (or where the same functionality happens over multiple BOs/methods) always go with a Method Directive.
data directive for things happening implicitly(behind the scenes)…lets say, when you create a sales order line, 1st order release is automatically created. - this situation, use Data Directive to prepopulate information’s.
another example, when purchase order suggestions are generated , you would like to manipulate price based on delivery date or some factors. - this situation, use Data Directive.
Method Directive to manage and control over business objects/datasets.
The only Data Directives I do is conditional mandatory fields where all the necessary data is in the current record. I’ll never do look ups into other tables or any heavy lifting in a Data Directive. That KILLS performance.
I wonder if I use the Update method too much as it’s the next smaller sized hammer than the Data Directive. It does make sure that all bases are covered - usually.
I did an experiment where I wrote a method directive on SalesOrder.MasterUpdate and a data directive on OrderDtl that essentially do the same thing. When OrderDtl.PartNum changes, my test BPMs copy PartNum to another field. I tested with LineDesc as well as a custom field.
Our test environment is slow (which is good for detecting performance differences) and DMT itself may impose some kind of delay. But if DMT does add an intentional delay between updates, I believe it’s based on a fixed delay, not a fixed rate. We have a ton of complex BPMs on SalesOrder.MasterUpdate, and there’s a measurable performance difference (around 10%) when they’re all enabled vs. all disabled.
However, enabling only the BPMs I wrote for this experiment, there is no measurable difference between the method directive, the data directive, or neither. All consistently run 100 updates in 38s. There’s not even a measurable difference when running 1000 updates. Both BPMs finished in the same time to the second.
I then modified the two BPMs so they look up the Part record for ttOrderDtl.PartNum and copy one of its fields to an OrderDtl field. This takes a couple extra seconds for 100 updates, but nether BPM has a measurable advantage.
This satisfies me that any performance differences between method and data directives are so insignificant that they should never be a factor in deciding which to use. I lean strongly toward data directives in any situation where we want to make sure the same business rules are applied regardless of the source of the change (UI, DMT, REST, etc.)
I’ve run into another factor that may dictate the choice between a method directive and data directive. I needed to generate a value in a custom field when OrderDtl.PartNum changed. I first implemented it as a data directive, and it worked very well as far as the database is concerned, but this provided poor feedback in the UI. The user did not see the value in the custom field until they clicked save. Converting it into a data directive on SalesOrder.ChagePartNumMaster allowed the custom field to update immediately when the user changes the part number in the UI. But this required another method directive on SalesOrder.ChangePartNum to ensure the same logic is applied when adding or updating records with DMT. The data directive covered both the UI and DMT.
Kevin… good analysis, and good reasoning… There are more reasons why Data is more detailed than Method, especially in sales orders… not all business objects are called in all cases.
Converting a quote to an order may not call all the “normal” business objects
if you have Epicor Commerce Connect, it doesnt call all the BOs
DMT (as you noted).
EDI does some different processes.
So… My rule: if you are trying to fix/trap manually entered orders, and can do it via a Method, it is always better, because you can directly target the process, and don’t overrun your BPM
BUT otherwise, you may need to go to the Data BPM.
In ALL cases, but especially in Data BPMs, make sure that you have adequate filters to only do the BPM’s function when needed. Make sure that it doesn’t run the details EVERY time the record is written. Example, OrderRel table is touched MANY times throughout its life:
order entry (add)
Scheduling
Job Creation (if make direct)
Fulfillment Workbench
Shipping
Invoicing
Each of the above will cause an update to the OrderRel table. Your BPM WILL fire… it is your job to put a condition widget at the start to make sure that it NEEDS to run the rest of the logic one more time.