◷ Reading Time: 6 minutes
Debugging puts the FlexRule Designer in break mode, meaning you will be able to view detailed information regarding logic execution and it allows you to navigate to different parts of logic.
Break mode, is when you have an option of “Step In” or “Step Over” a logic. Meaning, you can navigate to more details, or you can skip details of execution and straight go to the next step.
While in break mode, debugging allows you to inspect all the parameters and values of every model in the execution context. Or, you can also change the values on the fly if needed.
You can debug all types of logics using the FlexRule Designer debugger:
- Decision Graph (e.g. Decision Requirements Diagram)
- Natural Language
- Tree and Subtree
- Boxed Expressions
and so on…
In FlexRule Designer, there are different ways you can start debugging and put a model into a break mode:
- Debug Menu
On the main toolbar of FlexRule Designer, have a look at the Debug toolbar as below:
Each command on the toolbar from left to right are explained below:
- Run: This runs the currently opened logic
- Run with JSON Composer: This allows running the project with debugging capabilities
- Start Debugging: This allows you to debug the currently opened logic and go through it step-by-step by using options on Data Feed Provider
- Debug with JSON Composer: Starts debugging by visually building a structure as input (No need to configure Data Feed Provider)
- Stop: This stops the debugging process
- Next Step: Goes to the next step of logic
- Next Breakpoint: Go to the next breakpoint
- Logic Run Template: Opens the screen to Run/Debug a run a re-defined template with the input values of a specific project
- Interactive Shell: Opens up a shell to try expressions
This has the same options mentioned in the above toolbar.
In FlexRule Designer you need to put a model in Break mode to start the debugging process.
When you are trying to debug particular logic, it is mandatory to provide the values to all the input parameters. If logic has input parameters, then you have to pass those input values to the logic to start the debugging i.e. putting FlexRule Designer in break mode.
When a Model is successfully put into a Break Mode, you can see the yellow highlight and arrow on the screen as below:
When logic is in break mode, you can navigate through different steps of execution one by one. You can tell when to go to the next steps by using “Next Step (F11)” in the Toolbar, or Debug Menu.
When the “Next step” is selected, the yellow highlighting and yellow will be moving to the next step of execution and waiting for the user to take the next action.
Control of going to the next step is available across all the models. This includes steps in orchestration such as Flow, Workflow, IRD as well as in decision level such as Decision Requirement Diagram, Decision Table, and in Rules and Data flow (IRD) models.
FlexRule allows multi-level and composite models to be created for business logics. Therefore a step of execution might be linked to other models and documents. In this scenario, FlexRule Designer will display a question, allowing you to drill down to the linked model with the continuation of break mode. Or skip execute the lined model without break mode, and go to the next step at the current model.
When the above dialog is displayed you have two options:
- Step In: By pressing “Yes” you can open the linked model and put it in the Break Mode.
- Step Over: By pressing “No” you execution the current step (entire linked model) without break mode and then the debugger goes to the next step and will be put in break mode again.
When you put a model in a break mode, before and after executing a step the Designer goes to a pause mode and waits for your instruction.
But you can in some scenarios you need to run the logic normally without break mode, and in certain steps or areas put the FlexRule Designer in break mode. This can be accomplished by using Breakpoint.
Once FlexRule Designer is put in break mode, you will be able to inspect values, understand the model’s behaviours, view execution context, change values on the flow, evaluate custom expressions, and more.
These requirements are addressed using inspection windows such as:
- Parameter window
- Watch window
Some models require input values because they have defined Input Parameters. In order to pass the input values you can use either of: