Docs for what causes which BPM methods to fire?

Epicor ERP 10
1

Are their any docs that explain what actions cause what methods to fire?

Most of the method names are obvious. But there are many that appear to overlap, and i generally do a lot of trial and error to figure out which one(s) I need.

For example, the Part BO has several that like like they might do for something like enforcing the PartNum to be all uppercase, or match a specific mask. There’s Update, GetNew, ChangePartnum, to name a few.

And some BO’s have an Update and a UpdateMaster (or is it MasterUpdate? ) when to use one over the other?

2

Trace is your friend, if you want to see what the method does or changes use that Trace tool i shared a few days ago it shows you what the BO Changes on the method call (or look at it manually)

1 Like
3

That’s great for when I know all the ways (and I test them all) that can initiate it.

But other than the Part Maint form, what else might trigger Part.Update?

Typically a when a new part is being created, the description is supplied by the user. But if you go to make a new part, and someone had already used that PartNum as an On The Fly part in order entry, the info from the order (Description, ProdGrp, UOM, etc…) will be used to create the Part table entry. Another example is updates to the Part via the configurator.

Just seems too easy to miss something, if trial and error, or trial and examination (via trace) is the way to find out where your customization won’t work.

4

well I mean if you put something at a Data Directive Level it will get fired any time from any where. It depends on what you are modifying or customizing.
UI Customization only fire on the Screen
Method Directives only fire if and only if those methods are called. Threre’s no way to know all the places those methods are called but the assumption is that if that method is called from ANYWHERE the BPM Will fire
Data Directives fire any time and anywhere the particular table is added to or updated. This is the safest place to put restrictions and constraints in to ensure they are ALWAYS applied. However they add overhead so ensure your conditions are as restrictive as possible and if you throw an exception from here know that the UI / Web App / or Mobile interface may not know how to handle it. But that’s not on you.

So it really depends on what the customization you are doing does and how important it is the source of the change

2 Likes
5

This is something I struggle with too.

It ought not to be a problem, because part of the essence of object-oriented development is that you’re not MEANT to know how things might be used, you just have to deal with the possibilities. But dealing with Epicor isn’t quite like normal development and you never know quite when the vast machine you’re tinkering with might find a way of biting you that you hadn’t thought of.

So far the only way I’ve found of dealing with it is to be unreasonably dogmatic about having users test things even if they think it’s overkill (at least when it’s anything significant), but if you do uncover any better ways then I’d love to know.

2 Likes