Debugger (Magic xpi 4.7)
The Magic xpi Debugger is a part of the Magic xpi Studio that lets you test your integration project during the development stage. The Debugger runs your project or attaches to a running project and gives you the ability to control the way the project is executed. You can control and view execution sequences, flow variables, Magic xpi services, and breakpoints. The Debugger's Context Tree gives you a full and complete picture of how the Server executes the flows in your project.
A debug session can be started in one of the following ways:
-
Open mode: Opening a project on a local machine. You do this by selecting Start Debugging from the Debug xpi menu, pressing F5 or by clicking 
in the toolbar. When you run the Debugger in Open mode, the following process occurs:
-
-
Check connectivity to Space
-
Run Checker
-
Save all
-
Build
-
Run
-
Attach to Project mode: Attaching to a project. This option lets the Studio debug running projects. You do this by selecting Attach to Project from the Debug xpi menu. Changes made to the project in Attach to Project mode, will not take effect until the project will be stopped and removed from Space, rebuilt and run again, whether in debug or serve mode. Also, please highlight the terms “Server mode” and “Debug mode”, combine the following sentences in and set them bold: “After a Debug session and before trying to run the project in Server mode, make sure to execute the Build or Re-Build All procedure again. The executable file created curing the Debug process cannot be used for deployment (add: i.e. Server mode).”
The Debugger may be controlled either by using the Debug xpi menu (Run, Stop, Break, Step, Continue/Run, Restart) or by predefined settings (suspended flows, set next step, breakpoints, steps, branches). These commands will cause the server to be either in Stopped or Running modes. This will be indicated at the top of the Magic xpi Studio. Stopped mode means that the Server will not execute and waits for a command. All running contexts will not execute the next step until the Server is in Running mode.
|
|
-
When running the Debugger, it is recommended not to open up any of the folders where Magic xpi is installed. This might interfere with the debug process.
-
The Debugger always builds the project before the debugging process commences, even if you have already executed the Rebuild Solution procedure. Because of the long duration of this process, if you only want to debug a specific flow it is highly recommended that you use that flow's Debug option. This is accessed from the flow's context menu in the Navigation pane. Alternatively, you can set as inactive any flows that you do not want to debug.
|
When you execute the Debugger, the Checker checks all active flows. Flows with errors will be marked as Inactive and will not be able to run during the Debug session. If the Checker finds errors, an error message will appear and the project will not be built. You can click the View Errors button to open the Checker Results dialog box. If you click this button, the Debugger will not continue.
When the Checker has finished, the project is built and a project ibp file and a mappergenerate folder is created. You cannot run this project in the Server, since the project ibp file was created by the Debugger. If you want to run this project in the Server, you will need to select the Rebuild Solution option.
The mappergenerate folder contains the generate process's outcome files. If the ibp file or mappergenerate folder already exists in the project's folder, the existing files are copied into the DebuggerSave folder and the new files are saved in the project's root folder.
After this build process, the Debugger searches the space for a running project with that name:
-
If the project is not found, the project is deployed in Space using the new ibp and mappergenerate.
-
If an existing project is found, the new ibp and mappergenerate are deleted and the files from the DebuggerSave folder are copied to the project's root folder (a copy remains in the DebuggerSave folder). Then, an Attach to Process dialog box is displayed to the user in the Studio. If you select to attach, the Studio then tells the server when to break, because of a breakpoint, for example, according to the Debug_Info.xml file. Otherwise the debug session will terminate.
When a project is running in Debug mode and the studio is terminated, after the Studio stops publishing that it is alive, the running project will terminate internally. This prevents projects in Debug mode running without having a Studio controlling them. In addition, when attaching to a running project and moving it into Debug mode, if the Studio stops publishing that it is alive, the project will move back to production mode. Since version: 4.5
Every operation or action that fails in the debugging session is logged to the MagicXPI.Log file, which is created in the <Magic xpi>\Studio\Log folder. A message box will appear indicating that an error occurred in the requested process. View the log to see what error occurred and where it occurred. Since version: 4.5
|
|
You may see the following message in the Output view after running the Debugger. This message has no effect on the Debug process and should be ignored.
'DummyDebuggerConsole.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'DummyDebuggerConsole.exe' (Managed (v4.0.30319)): Loaded 'C:\Magic xpi 4.4\Studio\Extensions\Application\DummyDebuggerConsole.exe', Symbols loaded.
The program '[8920] DummyDebuggerConsole.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).
|
The Debugger’s Navigation pane lets you navigate through your project in the same way as you do in the Magic xpi Studio regular mode. You can navigate through the flows and business processes in your project, and view the flow and step properties. However, you will not be able to make any changes, such as adding flows or components, or modifying properties.
The Studio will try to reconnect when there are connectivity problems between the Debugger and the runtime project, according to a number rules, such as several retries and timeouts (Since version: 4.5). For other problems that are not connectivity problems, such as runtime exceptions, the Debugger terminates immediately.
In the project's folder there is a file called Debug_Info. If you upgraded your project or changed machines, delete this file and start the Debugger again. A new Debug_Info file will be created with the current installation's details.
In Debug mode, if one of the repositories or a mapper document has a dirty indication (*), you need to be aware that there may be a mismatch between the context data retrieved by the server and the context definition in the Studio.
You might encounter a mismatch, for example, if you added a field to an XML file that the mapper document is using.
You might also encounter a mismatch between a variable defined in the Studio and the server. In this scenario:
-
The variable's value will become read-only in the Context View.
-
A UDS model that is changed will not be displayed correctly when zooming into a UDS Flow variable that is based on the changed model.
-
Variables deleted from the Studio but exist on the server will not appear in the Context View.
-
Variables that were added while the Studio was in Debug mode will appear in the Context View. You can modify the variable's runtime value. Then, when you select Step or Continue, the new values will be sent to the space and the server running context.
-
Changes to the PSS/UDS/ODS/Converter names or data will not take affect at all for the running project.
|
|
In Debug mode, you cannot modify BLOB type variables.
|
In cases like this you need to have two Magic xpi installations. You also cannot use the same internal database for both installations, since both environments (development and production) will write to the same place and you will not know which messages are relevant to which environment.
|
|
-
The flow's Timeout property is not executed in Debug mode. This is relevant only when the Debugger starts the project execution. If the Debugger attaches to a running project, the Timeout property behaves as defined in the flow properties.
-
A temporary .ini file called DebugSRV.ini is created under the project directory when you start the Debugger. It is deleted when the Debugger is stopped.
-
The last Studio instance updates the Space with its debugging info, such as breakpoints and set next step. Therefore, you need to be aware that if more than one Studio instance is running, unexpected behavior may occur with the Studio instances that were not the last. Since version: 4.5
|
The Debug Menu
Context Tree
Debugger Settings
Debugger Timeout Configuration
Attach to Project
Setting a Breakpoint
Suspending a Flow, Branch, or Step
Breakpoints and Suspends Pane
Context View
Debugging a Project
