Flow Debugger User's Guide > Flow Debugger Operations > Using Flow Debugger in Configuration Testing Mode

Using Flow Debugger in Configuration Testing Mode

How to:

Run the Debugger in Configuration Testing Mode
Execute the First Run
Execute the Second Run

This tutorial demonstrates the Flow Debugger in configuration testing mode.

Procedure: How to Run the Debugger in Configuration Testing Mode

Start the debugger in configuration testing mode.
```
Enter Command:> tool Debugger -server
Command line process flow debugger [Server Mode]
Type help for more information
debug>
```
The process flows already being executed in the server are inaccessible, but every new instance of a process flow will be available to the debugger.

For this tutorial we assume the process flow called testflow from the first tutorial is still deployed to channel file1.
Verify file1 is active by executing an iSM command without leaving the debugger.
```
debug> shell info
```
You should see information similar to the following image:
If file1 is stopped, start the channel with the following command: shell start file1

Procedure: How to Execute the First Run

Change the default source to the flow in the default route of file1.
```
debug> set source file1:
Current source changed to file1:testflow
```

Set a watchpoint to trigger when the value of register reg1 changes.

debug> watchpoint reg1
Watchpoint created
w1: watchpoint -source file1:testflow -scope local reg1

With a text editor, create a file called default.xml with the following content: <default/>
Copy this file to the input directory of file1.
The channel picks up the file and runs the flow. The SetReg1 node assigns the name of the root element to the reg1 register.
```
Thread t1: W.file1.1~testflow suspended
by watchpoint at outedge of SetReg1
w1: watchpoint -source file1:testflow -scope local reg1
```
The event was detected and the execution stops after SetReg1 is processed, but before the returned edge is dispatched. The triggered watchpoint is displayed.

Show the reg1 register to confirm the new value.

debug> show register reg1
reg1 = [USR] 'default'

Resume execution, the flow terminates.
```
debug> resume
Thread t1: W.file1.1~testflow resumed
Thread t1: W.file1.1~testflow terminated normally with 1 document
```
Verify the presence of a file containing the output document of testflow, in the output directory of file1.

Procedure: How to Execute the Second Run

Multiple threads can be debugged at the same time. This run shows two threads from the same channel, but it could be multiple threads from multiple channels. This makes it possible to debug an entire iIA application.

With a text editor, create a file called test.xml with this content:
```
<test/>
```

Copy both default.xml and test.xml to the input directory of file1.

Since file1 has 3 workers, it will process both files concurrently. The watchpoint will trigger in both threads.

Thread t2: W.file1.1~testflow suspended
by watchpoint at outedge of SetReg1
w1: watchpoint -source file1:testflow -scope local reg1

Thread t3: W.file1.2~testflow suspended
by watchpoint at outedge of SetReg1
w1: watchpoint -source file1:testflow -scope local reg1

Show the threads.

debug> show threads
Threads
   t2: W.file1.1~testflow PAUSING at outedge of SetReg1
=> t3: W.file1.2~testflow PAUSING at outedge of SetReg1

Single step thread t3.

debug> step
Thread t3: W.file1.2~testflow suspended
at inedge of 'Is Default?'

Switch to the thread t2 and step.

debug> set thread t2
Current thread changed to t2: W.file1.1~testflow
debug> step
Thread t2: W.file1.1~testflow suspended
at inedge of 'Is Default?'

End the debugger session.
```
debug> end
Tool Debugger complete
```

This removes all breakpoints or watchpoints and resumes execution of all threads launched by the server. In this tutorial, t2 and t3 resume. Threads launched by the debugger are aborted. In this tutorial, there are no threads created by the debugger.

The flow continues until it terminates normally. The output document is handled by the outlet of file1. Verify the presence of two files containing the output document of the two threads in the output directory of file1.