Epicor BPM InfoMessage, Message Box, Throw Exception and Hold

How to give feedback or stop a transaction from a BPM

1. 1Open BPM Method Directive Maintenance (or Data Directive Maintenance for table-level rules) and create or open the directive on the right business object and method, for example SalesOrder.Update in the Post-Processing or Pre-Processing section.
2. 2Decide the intent: a warning the user can ignore (InfoMessage), or a hard stop that rolls back the save (exception). Pre-Processing is where you stop things; Post-Processing is where you inform.
3. 3Open the Designer and add a Condition widget first so the message only fires when your rule is true, for example a changed field, a credit limit comparison or a missing value on the ttTable row.
4. 4For a non-blocking message add a Show Message widget on the true branch, set the message type (Information, Warning), and type or build the text with variables.
5. 5For a blocking message add a Raise Exception widget on the true branch with the text the user must read. The method stops and the transaction is rolled back.
6. 6For a hold, add a Set Field widget (or custom code) that updates the hold field on the row being saved, such as the order hold flag, then add a Show Message widget explaining it.
7. 7Save, set the directive to Enabled, and in Directive Group Maintenance make sure the group is active. Test as a real user in the right company and site.
8. 8If it does not fire or errors, turn on tracing (Tracing Options in the client) and read the BPM section of the server trace log.

Doing the same in custom code

// Non-blocking message
this.PublishInfoMessage("Order is over the customer credit limit.",
  Ice.Common.BusinessObjectMessageType.Warning,
  Ice.Bpm.InfoMessageDisplayMode.Individual,
  "OrderHed", "OrderNum");

// Blocking: rolls back the save
throw new Ice.BLException("Ship via is required before the order can be saved.");

Debugging a BPM runtime error

Common pitfalls

• !Using Raise Exception in Post-Processing: the data is already committed in many flows, so the user sees an error but the change may have been applied.
• !Showing a message from a Data Directive and expecting the user to see it: Data Directives run at table level, so use a Method Directive for user-facing text.
• !Forgetting to enable the directive and its Directive Group, so the rule silently never runs.
• !Reading ttTable fields without checking a row exists, which throws a runtime error on empty calls.
• !Hardcoding a company or site in the condition when the directive is shared across several plants.