Many of us just create an AL project and start building the applications/extensions. But do we really know what exactly each property of Launch.json means, let's see
Normally a launch.json which is targeting your own server, either it can be a local host, or a container etc, will look like the following properties
Launch.json is essentially required to publish the extension to a server.
The two properties that you can see in the above image are version and configurations. The configurations contains sub properties such as name, request, type etc.
In JSON files, each json file will have some properties and values for that properties like key-value pair.
If we look into the sub properties of configurations:
name:
This property has a value i,e the name of the server that you are targeting, this can be your own server when you are using local host or container for your development activities.
request:
This property can either have the value launch or attach.
When we want to publish the app and start debugging the application by setting up the breakpoints and executing the Business Central functionality we can use request property.
If you don't want to publish and invoke functionality to debug it, you can instead attach a session to a specified server, and await a process to trigger the breakpoint you've set. Then debugging starts when the code that the breakpoint is set on is hit.
For launching the application and to debug you can use launch, for attaching to a session and start debugging you can use attach.
type:
The type needs to be al, because we are building al applications.
environmentType:
This property can have either of the values OnPrem, Sandbox or Production. When you are using your local host or local container for development of the applications you can use OnPrem.
If you are using SaaS environment it could be either Sandbox or Production. Production environment is basically the environment which customers use, Sandbox environment can be used for Development and testing.
server:
This property represents the server which you are using for your development. The server can be your local host, or a local container or a server which is on Azure.
If you are using SaaS environment for your development then you need to have the URL of the sandbox env here.
serverInstance:
The instance name of your server, each server can have multiple instances. For example the value of this property can be "BC"
authentication:
The authentication can be of type Windows, UserPassword or AAD. Depending on the type of the server that you are targeting you need to have the value for this property.
Windows value can be used to authenticate Business Central with the use of windows credentials. With this credential type, users are authenticated using their Windows credentials. You can only specify Windows as the credential type if the corresponding user exists in Windows (Active Directory, local workgroup, or the local computer’s users). Because they're authenticated through Windows, Windows users aren't prompted for credentials when they access Business Central.
When we use UserPassword we will be prompted to give username and password when we are publishing the app the server. This credentials can be defined while creating a container for the development.
AAD value can be used when the server is on Azure, AAD is defined as Azure Active Directory.
startupObjectId:
Usually when we are building applications of type al, which is object based, these objects can be Tables, Pages, Queries, Reports etc.
For this property we have to give the value of object, when we publish the app to the server the app will start by showing this object.
startupObjectType:
As we mentioned in the above property about ID's we have to give the respective type of the ID in this property. The type can be of Page, Table, Report or Query.
breakOnError:
This property will have a value which is useful for us if we want break the process on the error, it can have values "All", "none", "ExcludeTry"
All : this means anywhere in the code if the error occurs the debugger will stop at that particular line of code
none: this means the debugger won't stop at any error
ExcludeTry: Usually in coding we use try function by considering that this particular code can give run time error, depending on that we write rest of the code.
If we use this property then debugger will skip the errors which occur Try block/function.
launchBrowser:
If the value is set to true, the browser tab is launched, if false, the browser tab is not launched. If publishing with debugging enabled, the browser tab is launched and this setting is ignored. The default value is true.
enableLongRunningSqlStatements:
Traditionally, debugging AL has been about examining the behavior of the language runtime, for example, looking into the content of local variables at a breakpoint. As of Business Central April 2019, the AL debugger also offers the capability to examine your AL code's effect on the Business Central database. The enableSQLInformationDebugger setting enables this functionality.
enableSqlInformationDebugger:
Specifies whether the debugger enables long running SQL statements in the debugger window.
Tenant:
Each server will have it's own tenants, you need to specify the tenant that you are targeting here.
For more information: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/deployment/multitenant-deployment-architecture
Comments
Post a Comment