But is that really easier than just typing in a string that says where the BPM is? Cooler in nerdtastic kinda way, sure, but seems a little convoluted doesn’t it?
Not if you could have a template of a bpm that you use all the time as your starting point. Instead of just using it as an info message, set it as a variable as mentioned before then you can use it not only in custom errors, but in message widgets as well. Sorry if I’m pointing out the obvious.
There is a lot of stuff you have to redo all the time which would be great if you didn’t have to.
If/when they can get more reusable things in BPM I could see it being really helpful. The current copy/paste method leaves some to be desired I guess.
1 Like
Nice, thanks for the confirmation!
Your welcome Sir. 
You need more than just the name to fully find the bpm.
Example, depending on where you put the bpm, it could be hidden in one of several dozen locations on a sales order. Salesorder.update pre and post are just two of them. Then there are all the data BPMs, including orderhed, orderdtl, orderrel, and all the other obscure salesorder methods. Once you get several dozen BPMs throwing messages around, you really need them telling you where they came from.
Agreed.
You need the method and the group, and possible which type (Pre, Intran or Post)
I agree, but not really sure on how to find it at runtime @Chris_Conn??? . I am sure there is a way though.
Interesting, but I’m still in @Banderson here. I have a, I guess you could call, a template BPM too but it always needs enough tweaks that changing the error/warning message and BPM name isn’t really a huge issue.
1 Like
This was where I was hoping to go. I do agree that the name is only a start and that a fuller definition of the entity that is throwing the error/warning/info would be ideal.
I initially just wanted users to be able to give me a lead on what they were seeing and the neighborhood it was coning from in a customization-rich system without altering dozens of BPMs with custom text. BPM self reporting essentially… one Statement to name (rule) them all… Thanks so much for this discussion and ideas folks. I really appreciate you all in this community!
1 Like
How about this: 
var t = this.Type.ToString(); //pre, base, post
var an =this.callContextClient.AssemblyName; //the calling form
3 Likes
What? Cant include the specific method?
If I gave all of my work for free, nobody would ever hire me 
1 Like
Look at this: Code snippets intended to be reused throughout the Epicor 10 implementation. · GitHub
My previous colleague @dlockwood created this.
You basically have a few variables you can use in addition to the stack trace:
Client Assembly Name
Client Type
User Company
User Plant
User ID
Client Customization ID
I take no credit for this work and @dlockwood gets all the credit
Typically the stack trace should tell you exactly where to go if you are throwing an exception correctly. So use the show message widget in a BPM and set the level in the widget to “Error”. That gives you a stack trace with a method and BO.
Look for any BO.MethodName() hints in the stack trace.
Showing a message to a user Everytime they do something seems inefficient. Although you could maybe do a .PushDisposableStatus() to the status bar of the app? Hmmmm. Or using up a UD table to log Execution history of all your BPMs
1 Like
I mostly use putting the BO, method, and type(pre or post) in the message box for debugging. Especially since I still struggle with when to use a pre-proc vs a post-proc. So I usually make both so I can see the data values during each…
1 Like
The issue here is that this means halting execution. I thought the idea was to display a message, not necessarily kill the BPM.
I do like this idea. Perhaps return the message in the call context and display as needed.
1 Like
Operation.Current.Action
2 Likes
Chris is correct. I was looking for a way to use one line of standard code to yield info on any bpm as fires or errors, the user can know of the origin and relay it. But this also lends to all sorts of reporting options for proactive responses as well.
Got to tell you guys how freakin awesome you are to push Epicor in so many ways and so generously.
Best,
Henry Burke
Sent via phone, please excuse brevity and grammar
1 Like
@Henry_Burke That’s what e10 is all about, giving back, floating ideas and really making your company’s investment, in you, and Epicor worth their while.
Shameless Pateron plug next: 
If you think a small investment in the community is worth it, jump on board.
Hi,
Ice.Diagnostics.Log.WriteEntry() keep track the BPM details in windows Event Log instead of info-message,