Exception widget in BPM prevents Show Message widget from showing

Epicor ERP 10
1

While testing a BPM, I added a Show Message Widget to show me some debugging info.

But the message never shows when an Exception widget is reached later in the execution path.

image

If the condition block results in true, then ONLY the exception message (2) shows.

If the Exception block results in false, then ONLY the Show Message (1) shows.

I’d expect the Show message (1) to show every time.

Changing the exception to a second Show Message, and it preforms as expected.

image

First message always shows. Second message only when condition is true.

Is this normal?

2

Adding another Show Message between the Condition and the Exception, like:

image

Still only shows the exception message.

It’s like the compiler optimizes out the show Messages, when it is going to result in an exception.

If I had other widgets in there, like Invoke BO, or send email, prior to the exception, would they be skipped too?

Edit

An email widget placed before the condition, always executes.

But the show messages don’t when the execution results in the exception.

3

It is my understanding that the messages are merely queued and delivered after execution is done. So when you see 10 message-boxes in a row, the code already is done executing, you are not stopping execution.

Thats why I never use MessageBoxes to debug but instead

Ice.Diagnostics.Log.WriteEntry("");
3 Likes
4

Yes because the exception is rolling back everything that is queued up to fire otherwise. Remember that the sequence of events is fixed and it doesn’t ping pong back and forth between UI and back end. BPM forms are the only exception, but when you review the BPM sources they have special conditions for handling that interruption.

1 Like
5

Also a Messagebox in PRE could be stopped by POST. I think it waits until the entire BPM is done completing before they are delivered to the UI.

6

Not exactly. The email widget still executed.

image

7

Sure but that’s not UI dependent now is it lol. Everything happens sequentially back on the server but it only “reports back” to the UI once.

8

So if you look at the BPM Code the Email is sent during execution…

The MessageBox is Published to the stack… actually if you do it through Reflection it is added to the Context and the client probably reads the callContext and says “Oh I got stuff to show”.

protected void PublishInfoMessage(
	string message,
	BusinessObjectMessageType severity,
	InfoMessageDisplayMode displayMode,
	string bo,
	string method)
{
	this.BpmContext.InfoMessages.Add(
		new InfoMessageRow {
			MessageText = message,
			Severity = (int)severity,
			DisplayMode = (int)displayMode,
			Company = this.Session.CompanyID,
			UserIdent = this.Session.UserID,
			Plant = this.Session.PlantID,
			BO = bo,
			Method = method
		});
}
9

I just did a test with multiple Pre-Procs enabled.

The first one (with a lower order number) is just a BPM that always shows a message.
The second has the exception.

When the second one results in the Exception, the first one’s message doesn’t show. I assume any actions in the first one (like: email, autoprint, invoke BO, etc…) would have processed.

Or does the result in an exception in ANY enabled pre-proc prevent the execution of other Pre-procs on that BO method?

10

emphasis mine. :wink:

Or are Show Messages the only things that are queued up?

11

So in a nutshell … Don’t look at the BPM workflow designer as the actual path of execution.

Would code in the Exec Custom Code widget shown below actually be executed?

image

12

It wont… if you do the exception that way, it does a throw (immediate). The other way you can do exceptions via code is AddBLException which adds it to a stack to be shown at end – but the widget does a throw.

13

Anything returned to the UI that is not a BPM form is queued and shown all at once. This is what happens when an adapter runs a method (90% of the time, but you’ll find weird adapters no doubt.)

Below includes everything that handles writing trace messages firing pre, base, and post. Because you are sequential on this side from a single call injecting a show message mid run of all of this would take some pretty significant restructure of their framework.

image
image661×664 14 KB

It’s assumable that on kinetic because of async calls available and the nature of promises the sequential behaviour you’re expecting is possible, however the framework won’t support it as far as i’m aware. Maybe someday.

1 Like
14

In any c# program if you throw an exception the subsequent code in that scope will not run… Are you new here lol?

15

That should be

Ice.Diagnostics.Log.WriteEntry("");
16

@ckrusen here is another one for you… if you call a UBAQ and the UBAQ BPM throws an exception or MessageBox and the parent BPM throws an exception – it also will not show. The MessageBox is the exception here – its is unique, special.

17

Even better instead of MessageBox or WriteEntry use traces How to write your own trace logs - #3 by Bart_Elia

3 Likes
18

I always use:

// Delete original UD03 records
if (ud03Rows.Count > 0)
{
	using (var txScope = IceContext.CreateDefaultTransactionScope())
	{
		foreach (var row in ud03Rows)
		{
			Ice.Diagnostics.Log.WriteEntry($"Deleting UD03: Key1: {row.Key1} - Key2: {row.Key2} - Key3: {row.Key3} - Key4: {row.Key4} - Key5: {row.Key5}");
			Db.UD03.Delete(row);
		}

		Ice.Diagnostics.Log.WriteEntry("Committing Transaction");
		Db.Validate();
		txScope.Complete();
	}
}

But plan to switch to traces, because apparently WriteEntry is also flooding my Event Log in Windows! Argh. But it does show up in ServerLog

1 Like
19

The other issue with WriteEntry using Ice is you can’t categorize. We wrote a dll aptly named “BetterLog” that uses the System logging methods, it makes the event viewer palatable

image
image1008×598 61.5 KB

1 Like
20

I get that. But why does the Raise an Exception Widget let you connect other blocks to it?