Method Directive BPMs called multiple times

We us popups to inform users of atypical situations, where the popups are generally method directives. The issue we’re having is the popup shows multiple times in some situations(popup, click ok, popup …). I assume that means the same method is being called multiple times. As an example we have a post processing method directive on Erp.SalesOrder.ChangePartNumMaster. The ideas is to notify at the order entry screen of certain situations, but it consistently pops up twice(on other screens the number of times the popup fires varies). I assume that means the method we attach to is is being called multiple times.

In E9 we would run a trace to figure out what method calls were being called and based on the name of the method calls pick one that seemed most appropriate to attach a bpm to(documentation was pretty much non-existant), to achieve what we wanted. Is anything different in E10 we should be aware of(e.g. documentation on the method calls, an explanation why our code is getting called multiple times, some cool tool we should be using, etc)?

That is normally what this means. if you see a popup display hit twice, the BPM hit twice.

1 Like

@timeshuwy would you run a trace and just look for another method to trigger the bpm on. If so any suggestions on which method to pick beyond the name of that other method seems like what we want(a bit of a guessing game)?

my one problem with “ChangePart” method is that it is NOT always triggered with every possible way to add a line item to an order… Consider the following:

  • Manual Entry - will trigger when you enter the part
  • Get Line from Quote - I dont believe it is triggered
  • Push Quote to create new order - Not triggered
  • Epicor Commerce Connect - When it creates orders, it does not trigger this method
  • Copy Order - Not triggered

The only way to guarantee that the BPM is triggered is to do it as a Data BPM.
SalesOrder.Update is also pretty foolproof, but it is run when you update the Header, Detail, or Release, so you need ot make sure you are selective when you do anything so that it doesn’t run every time something happens.

@timshuwy thank you for “giving me a fish” this helps solve my immediate problem, but how do you know this about the ChangePart method(“how can I learn to fish”)? Is it just experience…?

I learned the hard way (experience)… created a BPM that did something based on changing of a part number… then imported a quote and found that it was not triggering…
Sometimes it is simply trial and error. Create a BPM, and then discover that it doesnt work, and do some research as to the difference between THIS time and LAST time.
Personally, I program based on what I call the “Bulldog method”… I bulldog it until it works, and test with every possible variation to make sure you cannot break it.

1 Like

A trick I learned here to stop things firing multiple times is; at the end of a bpm I set a callContextBpmData field to 1 or 2 min from now, and at the start of the BPM I have a condition that checks that the now date is equal or less than the callContextBpmData field ( I also have a “OR null” condition on the callContextBpmData field so it fires the first time)

image

3 Likes

This seems to be working great for me in both cases, but it’s unclear to me how long the callContextBpmData is supposed to be hanging around. In my initial testing, I found that it seemed to go away after the current initiated UI event - for instance, if I went to the action mention and selected to print something that happened to call my BPM multiple times, the data I set in the first invocation remained there for the subsequent calls, but once the dialog was open if I immediately closed it and initiated the event (to open the print dialog again) it forgot about the previous values, even if it hadn’t been a minute since the previous invocation.

But today in testing another BPM I was tracing the call and I noticed a date field set on the initial call which was unexpected. In this case I was reloading a record, so I don’t know if that is expected to retain the previous callContextBpmData from the latest invocation or not.

Is there some definitive answer on exactly how long the data should persist and be passed to subsequent invocations?

Not 100% sure of the answer but there are a lot of posts on this forum regarding the topic

It seems to vary depending on what screen you have open

https://www.epiusers.help/t/callcontextbpmdata-hack/54893/5?u=lbarker

https://www.epiusers.help/search?q=callContextBpmData%20category%3A5