Efficiency of method vs data directive for logging changes

Epicor ERP 10
1

I would like to email myself when a part gets activated / inactivated(happens very infrequently), so I just did a trace and it looks like if I use a method directive I’d have to put a bpm on the Part.Update() method. I’d hate to have custom code running every time we change a part(not sure exactly what the performance penalty is), but it’s got me thinking if a data directive would be more efficient…?

Is the performance of a bpm “in the noise” and not worth worrying about or is this a valid concern(the more we customize the system by adding bpms the slower the system gets) and if so is a method or a data directive(or some other approach) most efficient.

Please note we have a relatively slow system so I’m pretty sensitive to performance issues(it takes 2 seconds to get a response from a simple BAQ via REST)…

2

It’s a valid concern, however for a task like sending an email, you can have your code run asynchronously, so that the BPM returns immediately and your email is sent in the background on a separate thread. This will have minimal performance impact. Depending on which version of Epicor you are using, asynchronous BPMs can be finnicky and in some situations may not run at all, for obscure reasons… However I posted a solution to this recently here: Async. BPM execution; still broken 10.2.200.3 - #38 by HLalumiere . As long as you are comfortable writing code to send your email rather than using the Epicor widgets, this will work for you.

2 Likes
3

Have you tried using a condition widget looking to see if the ttPart.InActive field has changed, then run your custom code.

4

I created functionally identical method and data directives that looked up a record in another table, and compared their performance by updating thousands of records using DMT. Run times were identical to the second. I considered the possibility that DMT imposes an artificial delay between updates that could conceal performance differences in the BPMs. If there is an artificial delay, I reason that it’s based on a fixed interval, not a fixed rate, because BPMs that do different things do show performance differences. Therefore, this method should detect differences between method and data directives that do the same thing. Apparently there is none.

1 Like
5

The fact that the email is asynchronous should prevent any UI performance penalties.

Also, I really like @krum idea for benchmarking I’ll have to remember that :slight_smile:

6

In-Trans and Standard Data BPMs can either be good or bad depending on what you are doing INSIDE the BPMs…
If your data BPM simply does a calculation and updates a UD Field while it is In-trans, then you probably will never notice the BPM…
BUT if your BPM looks up data, updates other tables, etc etc… you can see a bad hit on speed… But this also depends on WHICH TABLE and HOW OFTEN that table is updated… example:

  1. a BPM on the ABC code table can be written inefficiently, because you rarely update that.
  2. a BPM on OrderRel is VERY IMPORTANT to get right… because OrderRel is updated many times by multiple processes… Order Entry, Scheduling, Job completion, Fulfillment Workbench, Shipping… they all update the OrderRel table, and when it is updated, the DataBPM is triggered.
    That said, the following list is SOME of the tables you need be careful with, and do time trials with and without your BPMs to make sure that they are not causing problems:
  • OrderHed, OrderDtl, OrderRel
  • Part, PartPlant,
  • PartTran (ouch!)
  • JobHead, JobMtl, JobOpr, JobAssy (if doing Change logs… make sure you only do change logs for FIRM jobs… otherwise MRP triggers LOTS OF DATA)
  • PO Files
  • AP files
  • AR Files
2 Likes
7

One other comment fact:
there is No Difference in speed between Data and Method BPMs… BUT, there is a difference in FREQUENCY of hits to the BPM
METHOD BPMs are only called when that METHOD is used.
DATA BPMs are called EVERY TIME the data to that table are written.
Does that mean a Data BPM is called more frequently than Method? Not always… For example:

  • SalesOrder.Update Method BPM is used to update the Header, Detail, and Release records from Order Entry and other processes. Therefore as you are entering a 10 line item order, the Sales Order Update BO will be called at LEAST 10 times, triggering your BPM
  • If during the same 10 line item order, you have a Data BPM on OrderHed, it might only get triggered one time, when you create the order header.

So… the story gets detailed depending on What you are doing, and how you do it.

2 Likes