Developers must have it etched on their mind that Dynamics 365 Business Central is a multitenant environment that declares the following paradigms:
- Applications and data are decoupled and stored in different databases.
- A single application database, bound to an application service, could serve hundreds of tenants (customer data databases). This is the pillar of the one-to-many concept of multitenancy.
- In the application, the database is stored as the extension manifests (records that store the definition of the extension as it appears in the app.json file).
- Mounting and synchronizing tenants in a service bound to an application database would expose these extensions to the tenants.
- Tenant extensions could then be chosen for installation by users.
Whenever a minor update (typically monthly) or major update (typically every six months) happens, the extensions will be uninstalled. Subsequently, the tenant will be dismounted from the old application service and mounted to another application service that is bound to the new application version.
Even if the new application service has not published the PTE, the tenant structure and its data will be totally preserved.
Whenever this operation happens, developers just have to publish and install the extension once again, to resynchronize everything. This is valid, as mentioned, for all online sandboxes.
PTEs that are deployed in the production environment have a more global scope, and extensions are automatically ported into the new application service. Within this context, if an extension is chosen to be deployed with the next minor/major version, when the upgrade happens, the new extension will be triggered for installation.
To get a deeper overview of this topic, visit https://demiliani.com/2019/01/24/dynamics-365-business-central-tenant-upgrade-extensions-disappeared-in-sandbox-environment/.
PTEs must maintain their uniqueness across the ecosystem, and developers should not violate this principle. The uniqueness of a PTE, or any extension in general, is defined by the composition of the following values in the app.json file:
- Package ID: A new GUID assigned to the .app file every time the extension is built (Ctrl + Shift + B).
- Application ID: The unique GUID that defines the extension.
- Name
- Publisher
- Version: (in the form of x.x.x.x).
Whenever one of these values is changed, the extension is considered to be a new extension. If a developer is considering reusing a PTE for another customer tenant, then they have to deal with this uniqueness paradigm.
Trying to deploy the very same PTE in another tenant, or even redeploying the same after rebuilding the package, might lead to a failure with an error like the one shown here:
In this case, it might be necessary to simply increase (bump) the application version to make the deployment work smoothly.
If this happens in the tenant in which the PTE has never been installed before, then the root cause might be a duplicate within the same application service. To resolve the issue, the developer has to change the application ID and the name, and redeploy it in order to install the PTE successfully.
For a deeper overview of this issue, visit https://demiliani.com/2019/03/14/dynamics-365-business-central-online-sandbox-makes-you-crazy-maybe-remember-these-points/.
There are another two error messages that might typically arise when deploying extensions. These are:
-
Cannot install the extension <name> by <publisher> because the tenant <Tenant Id> already uses a different version of it.
-
The application extension with app id '<Extension Id>' is already configured for use by the global tenant.
The first error occurs because it has tried to publish a Per tenant extension with the same Application Id and Version parameters as another Per tenant extension which is present on the system, but with potentially different contents. The easiest solution to this error is to increase the version of the extension.
The second error occurs because it has tried to upload a Per tenant extension using the same Id as one assigned to an AppSource Extension or a standard Microsoft owned extension. In this case, the solution is quite straightforward: change the extension Id and republish.
In the next section, we'll see what happens under the hood when you deploy an extension.