BPM Tip: Add the BPM Name to your Messages

In order to help you trace out error messages in the future, please add the BPM Name to the bottom of any displayed messages or Exception messages. This will help you next month/year when you have a user say “The computer says I cant do xyz”. You will then know which of your custom BPMs is causing the message, and you won’t accidently call Epicor to ask them why.

The way I have done this for years is to put the full name at the bottom of the message… something like this:

Product Group is required to save a part.

BPM: Part.Update / Pre / RequiredFields


I do exactly the same (but at the top of the message) when using the Show Message Widget for debugging. I wish you could right click and choose:

Insert -> "BO.Method / Type / Name"

1 Like

Submit this as an Epicor Idea! https://epicor-manufacturing.ideas.aha.io/ideas

1 Like

Better yet, have a company/site config option to automatically insert that into any message/error widget.

I’d vote for any of the 3.

1 Like

Better yet, actually show the BPM name in the trace log and server log instead of an undecipherable hexadecimal key that does’t correspond to the BPM’s GUID or anything else…

In the Custom Code widget, I use the following to get my BPM details to show you can add line breaks too

//Data Directive
var bpmName = "Data Directive BPM Name: " + this.Name.ToString() + " BPM Type: " + this.TypeName.ToString();

//Method Directive
var bpmName = "BPM Name: " + this.Name.ToString() + " BPM Type: " + this.TypeName.ToString() + " Module: " + this.callContextClient.AssemblyName.ToString(); 


Thanks @LBARKER for this. I knew there was probably a way… this would make things standard. In fact you could make a standard widget that you simply copy in that would do this every time for you.

By the way, did you know you can simplify your c# code like this? With String interpolation you can now embed the variables into the string by preceding the quote with a dollar sign, and then put the variables into curly brackets. This also replaces the string.format command if you ever use that. (read more here: https://www.dotnetperls.com/string-interpolation)

//Data Directive
var bpmName = $"Data Directive BPM Name: {this.Name.ToString()} BPM Type: {this.TypeName.ToString()}";

//Method Directive
var bpmName = $"BPM Name: {this.Name.ToString()} BPM Type: {this.TypeName.ToString()} Module: {this.callContextClient.AssemblyName.ToString()}";

This works in BPMs, but for some reason not in UI customizations, there I still have to use the string.Format function

Correct. String interpolation is not available in the ancient .NET version they use on the fat client.

This will only work for server-run code (BPM/Configurator/Functions/Interfaces).


String interpolation is also not supported in Product Configurator. But you can use the String.Format option. My reason for using either interpolation or string.format is because it is easier to see where the spaces and symbols will show. I actually believe that there is no significant performance reasons why to choose any of these over the other. Resulting value is the same.
OH… there is one reason… the first two options will auto format your dates and numbers for you without needing to specifically say “convert”…

//below is interpolation method:
string x = $"test: {variable1} test2: {variable2}";
//below is string.format method
string y = string.format("test: {0} test2: {1}",variable1,variable2);
//below is old school:
string z = "test: " + variable1 + " test2: " + variable2;
// And for old-old school
sprintf(z,"test: %s test2: %s", variable1, variable2);


But seriously …

Do variable1 and variable2 need to be a strings in any of your three examples?

not for examples 1 and 2 that i provided… my “old school” example DOES require them to be strings in order to append them.

bool myBoolValue = true;
string x = "the value is {myBoolValue}";
//x is now equal to "the value is True"

The new application tracing stuff works really nice for this too. You can create your own custom traces and enable or disable them at will on the appserver.

Is there consistency in how {myBoolValue} is converted?

Is it always spelled out (and in english), with just the first letter capitalized?

And never "true" or "1"?

Does the server-sided code of Epicor use the same compiler for the client-run option in Configurator?

The ToString value of a given object.

1 Like

I believe it is always “True”… but you could always do something different like:

bool myBoolValue = true;
string x = "the value is {((myBoolValue) ? "T" : "F")}";
//x is now equal to "the value is T"
string Y = "the value is {((myBoolValue) ? "1" : "0")}";
//Y is now equal to "the value is 1"
string Z = "the value is {((myBoolValue) ? "yes" : "no")}";
//Z is now equal to "the value is yes"
1 Like