I can stop any BPM at will by throwing an exception, but is there a way to do this silently with no user awareness?
Perhaps a special exception type? NinjaException nje = new NinjaException(“Shhhhh”);
is this a silent but deadly joke?
2 Likes
I am not aware of such exception, but what I did was setting a BPMData CheckBox01 field to true whenever I did not want to continue …
And add a check condition on that field if it was set from false to true…
If true, do nothing else continue…
Pierre
I was trying to do this last night, let me know if you figure it out
That seems like a situation in which a user is expecting something to happen, it doesn’t work, and they call into Support saying “it isn’t working!!! ! ahhHhhhhhHhhHH!”
I am against punishing Support as a rule, but, even without that, I would say it would be poor form to silently terminate execution.
If you wish to teach a user a lesson for an action they shouldn’t be doing, just throw some double digit number of exceptions at them saying:
“you know why this is happening right?” Click Ok.
“You won’t do this again, will you ?” Click OK.
“You have a few more to go(or not?)” Click Ok.
…
EDIT: er, maybe I misread the objective… ignore…
4 Likes
Bahaha to all the repsonses!
So the use case is probably a special one. It’s on the CorrectiveActionEntry screen. There seems to be some trouble with the startup logic that prevents one from opening a desired record. (by passing it args)
@josecgomez was tricky enough to give me a work around for that with some ingenious modifications of the whereclause on GetRows based on some criteria. The issue now, is that if I dont have a single record to open, it will call GetRows with no filter and return all the results. I dont want that. I figured I could just give it unreachable criteria (i.e. a record that does not exist) but now I get that error message. What I want is a blank screen or a specific record. So as you can see, a very special use case.
I may have to use reflection and clear that incoming LFO. I’ll see what that does.
I still think NinjaExceptions should be a thing.
1 Like
I want to follow this thread as well. We have Enhanced Quality and AMM. In our CRP testing, when we end-activity on an item requiring PDI, we send it to Inspection Processing by putting the quantity (usually 1) in Non-Conform Qty with a reason code of PDI, checking the Complete box, and the Current (completed) quantity remains at zero. And when this occurs two material queue request records are generated. One ASM-INS for 1 ea (that one’s normal) and one record ASM-OPR for zero ea (that one should not be created) so if Epicor doesn’t have a solution that prevents record creation for these “zero quantity” records, I thought of preventing their creation with a BPM that would quietly just skip over creating the record. But it would need to so without erroring-out, as in your use case. Our version is 10.1.600.16.
1 Like