To debug a Business Central sandbox environment, you typically use Visual Studio Code (VS Code) with the AL Language extension. The process involves connecting VS Code to your sandbox and starting a debug session, which often requires adding a specific configuration to your launch settings.
Understanding the Debugging Process
Debugging allows developers to step through their code (written in AL), inspect variables, and identify issues within the Business Central environment. For a sandbox, this process leverages the capabilities of VS Code connected to the specific cloud or on-premise instance.
Key Steps for Debugging
-
Install Prerequisites:
- Download and install Visual Studio Code.
- Install the AL Language extension from the VS Code Marketplace.
-
Download Symbols:
- Open your AL project in VS Code.
- Use the command palette (Ctrl+Shift+P) and search for "AL: Download Symbols". This connects to your Business Central environment (as defined in your
app.json
andlaunch.json
) and downloads the necessary symbol files.
-
Configure
launch.json
:- This file defines how VS Code should connect to and debug your Business Central instance.
- You will likely have an existing configuration. According to the reference provided, for debugging a sandbox, you might need to add a different kind of configuration.
- Inside the
launch.json
file, you'll find a list of configurations. There's often an "add configuration" option or button within the editor interface after an existing configuration block. Click this to add a new debug profile specifically suited for connecting to your sandbox environment for debugging.
-
Start Debugging:
- Go to the Run and Debug view in VS Code (Ctrl+Shift+D).
- Select the appropriate configuration from the dropdown that you configured in
launch.json
. - Click the Start Debugging button (the green triangle).
- This will open a new browser window or tab connected to your Business Central sandbox instance.
-
Trigger Breakpoints:
- Set breakpoints in your AL code by clicking in the margin next to the line numbers.
- Perform the action in the Business Central web client that executes the code where you set the breakpoint.
- VS Code should stop execution at the breakpoint, allowing you to step through the code, inspect variables, and analyze the call stack.
Example launch.json
Configuration Structure
While the specific "different kind of configuration" isn't fully detailed in the reference snippet, a typical launch.json
includes connection details like the server instance, tenant, and authentication method. Adding a new configuration provides flexibility for different scenarios (e.g., different sandboxes, different debugging modes).
{
"version": "0.2.0",
"configurations": [
{
"name": "Your Sandbox Debug Config",
"request": "launch",
"type": "al",
"environmentType": "Sandbox", // Or Production depending on setup
"environmentName": "<YourSandboxName>", // Specific name if applicable
"startupObjectId": 22, // e.g., Codeunit 22 for the main application object
"startupObjectType": "Codeunit",
"breakOnError": true,
"breakOnRecordWrite": false,
"enableLongRunningQueries": false,
"enableSqlInformationStack": false,
"schemaUpdateMode": "Synchronize",
"useCopyPasteUrls": true,
"authentication": "UserPassword" // Or appropriate method
// Add other specific properties as required by the "different kind of configuration"
},
// You would add another configuration here as mentioned in the reference
// using the "add configuration" option in VS Code or manually
{
"name": "Another Debug Config",
"request": "launch",
"type": "al",
// ... different properties ...
}
]
}
The reference specifically highlights the step of using "add configuration" after an existing configuration, suggesting that multiple debugging profiles are common, and a specific one is needed for sandbox debugging.
By following these steps and utilizing the configuration options in launch.json
, including potentially adding a new, specific configuration as indicated, you can effectively debug your Business Central sandbox environment.