1. Home
  2. FlexRule Designer
  3. Debugging
  4. Debugging in Visual Studio

Debugging in Visual Studio

◷ Reading Time: 4 minutes

Debugging refers to a capability that allows the examination of internal states on a running logic during execution while you are attaching the process to a debugger (e.g., running your application in Visual Studio).

Break Points

By putting a breakpoint in a specific element (line) of your logic, when execution reaches that specific element, it pauses and allows the examination of values in the debugger. When any of the Rule commands (Except Inference) is used to model logic, you can add a debug parameter to the element as a breakpoint.

debug = "true"

Watching Expression

If Visual Studio is used and you run your rule inside it, when execution pauses by reaching a break point you can add the following expression to the watch window in order to explore the internals of the execution:


This would provide the following information:

/// <summary>
/// Information on the current element that has debug="true" parameter
/// </summary>
public interface ICurrentDebuggingState
    /// <summary>
    /// The current element that is about to run
    /// </summary>
    ActiveElement ActiveElement { get; }
    /// <summary>
    /// The current logic that is running
    /// </summary>
    IActiveElementEngine Engine { get; }
    /// <summary>
    /// The current execution context
    /// </summary>
    IActiveElementExecutionContext Context { get; }
    /// <summary>
    /// The current parameters values
    /// </summary>
    IDictionary<string, object> Values { get; }

Decision Table

To enable debugging in a Decision Table, the debug parameter (attribute) must be added to the Data element.


For example, in the sample application called Airline Discount Program which comes with the Runtime installer, we added debug=”true” to its validation logic:

<Validation name="input check">
    <Define name="input" direction="in"/>
  <Logic name="main">
    <And processAll="true" debug="true">
      <Null negate="true" value="input.Birthday" message="Birthday cannot be null or empty"/>
      <Null negate="true" value="input.Departure" message="Departure cannot be null or empty"/>
      <Null negate="true" value="input.Return" message="Return cannot be null or empty"/>
      <Or negate="true" message="Destination cannot be null or empty">
        <Null value="input.Destination" />
        <Empty value="input.Destination" />
      <Check value="input.Return gt input.Departure" message="Retrun must happen after your Departure date"/>
      <And message="Return and Departure date must be after Birthday">
        <Check value="input.Departure gt input.Birthday"/>
        <Check value="input.Return gt input.Birthday"/>

When you run the application, once execution reaches the line that is running the validation logic inside the application’s controller, it calls to the engine and the validation logic gets executed:

You can add the expression to the watch window, and you will be able to check what is happening inside your rules as shown below:

Position in Source

While debugging or when an exception happens (ActiveElementException) the source information below can help you to locate the position back to the actual source:

  1. LineNumber
  2. LinePosition
  3. SourceLine

As you can see SourceInfo under the ActiveElement’s Model property provides the exact line and position (location (6,6) which matches the above XML line number) that validation logic is about to run.

In some complex scenarios, when rules are transforming into other types of logic at runtime for execution, the SourceLine property refers back to the original source of the rule. For example, when a Decision Table is transformed into validation logic for execution, the source will have the Data information line. When an exception (ActiveElementException) occurs, the ErrorLine property on the exception object has the corresponding validation logic line but SourceLine still has the original line from the Decision Table.

Exception Handling

When an error occurs during the creation of the execution plan or execution of rules, ActiveElementException will be thrown. This exception implements the ISourceInfo interface by which you can retrieve the specific information about where and why the exception has happened.

The code below gives you a pattern to use:

    // code for rule execution goes here
    // TODO: Run your rules here
catch (ActiveElementException aex)
    var info = (ISourceInfo)aex;
    // information on where the problem is 
    // in your rule can be retrieved here
    // TODO: do what you need to do...
Updated on February 11, 2020

Was this article helpful?

Related Articles