I’m trying to build BPMs that identify themselves to the users… so that we know where a message or action is coming from. I just can’t find a post on this and have read a ton of posts that don’t mention this specifically. I’m guessing it might be something like the solution given for identifying the appserver …this.Session.AppServerURL
But I cannot find the way…
I’d welcome some guidance.
Typically I just put a heap of carriage returns in the message and at the bottom I put in the method, group and the bpm name.
Not a very technical solution, but it ensures that when the user comes to you with the message you can get them to scroll to the bottom to give you the information.
There may be a better way and there is another post relating to BPM versioning that this might well fit with
4 Likes
Information in the message boxes are the way to go. That is, if they are stymied by logic that was intended to stop them.
If you have BPM that’s are failing unintentionally though, that’s another problem.
My solution here… i ALWAYS (for the past 5+ years) put the name of the BPM inside my warning and error messages. In addition, if I want to display an error, and most of my BPM is a C# widget, I still use the regular Message/Error Widget to do the display work. How?
- I create a new BPM Variable called “ErrorMessage” and “WarningMessage”
- populate the message with the appropriate message
- CONDITION widget If ErrorMessage != “”
- Display error… Inside the error box, about 2 lines below the error, i put the line to notify the user where this came from. This is a life saver! Here is an example of what it looks like:
Error, Product Group is Required
InTrans Data BPM: Part - ValidatePartInputs
2 Likes
Just had another thought. I wonder what would be the C# to pull the name of the running BPM, group and it’s method?
You could pull that into variables at the beginning of the bpm as part of a template. Then you could use those variables in either a Message widget or c#.
What about this.Name?
Cant confirm, but it looks tasty.
PublishInfoMessage(this.Name,Ice.Common.BusinessObjectMessageType.Information, Ice.Bpm.InfoMessageDisplayMode.Individual, string.Empty, string.Empty)
Better yet one of those two empty strings at the end of that call is the Title of the box.
1 Like
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?
Thanks 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