Some weeks ago I received two emails from contacts where they submitted me two interesting “bad problems” that blocked them on Dynamics 365 Business central SaaS. Problems were the following:
- Field declared in a per-tenant extension that now has a conflict with a standard Microsoft Base Application field.
- Object IDs conflicts on AppSource apps.
Field conflicts between Base Application and your per-tenant extensions
The partner of this first scenario created a per-tenant extension (PTE) that adds a new field (here called MYFIELD, without a prefix) to a standard Microsoft’s table via a tableextension object. This extension was good for months and the customers was happy.
Then, a day X arrived 🙂 In a new Dynamics 365 Business Central update, Microsoft added the same field (with the same name MYFIELD) to the same base table extended by the partner’s PTE. This immediately created a conflict and the upgrade of the customer’s tenant failed with an error message saying that a field called MYFIELD is already defined in a table in the Base Application by Microsoft.
And now?
First test done was to obsolete the MYFIELD field in the per-tenant extension on version X (with ObsoleteState = Removed) and then physically remove it on version X+1, but this was not possible (this is a breaking change of a database schema) and the PTE update was rejected. Unfortunately, Dynamics 365 Business Central SaaS doesn’t permit you to alter the database schema implicitly (like renaming a field or a table or deleting a field or a table).
How can we remove the tenant upgrade lock then? Maybe with a support ticket to Microsoft?
Unfortunately, at the time of writing this post there’s no possibility to solve this problem with a support ticket to Microsoft.
If you’re on this situation and you want to unlock your tenant upgrade process (and remove your app conflict with the Base Application) the path that I suggest is the following:
Step 1: export all your per-tenant extension’s data (custom tables + extended tables) with RapidStart or other tools
Step 2: Uninstall your per-tenant extension by selecting the Delete Extension Data option. This will perform a full remove of all the extension data and objects on your tenant (data + schema update):
Step 3: Now you can create a new version of your per-tenant extension with the field that causes the conflict removed from the base tables.
Step 4: Install this new version of the extension. This will be a clean install, so you don’t have conflict with the Base Application
Step 5: Import the data in your tables again by using the same tool as Step 1.
I agree, this is not easy and quick but actually it’s the only possible way to recover from this problem.
NOTE: Please ALWAYS to remember to use app prefixes an ALL your apps. If you want to be safe and avoid conflicts, object prefixes must be use not only for AppSource apps but also for per-tenant extensions.
Object IDs conflicts between AppSource apps
The same “rescue path” is valid also for the other submitted case: object ID conflicts on AppSource apps.
This partner have 2 apps published on AppSource with the same range declared on the app.json file. The scenario in details was the following:
Step 1: App (here called MAIN) with no dependencies published on AppSource with range from X to Y with version 1.0.0.0
Step 2: App (here called DEPENDENT,that depends from MAIN) published on AppSource (version 1.0.0.0) with range from X to Y that declares a table object with object id = N
Step 3: App MAIN declares a new table with object id = N (same ID as declared in the app here called DEPENDEND) and it’s published on AppSource successfully with version 2.0.0.0 (Microsoft in this case validates only this single app because it has no dependencies from other apps)
Step 4: App MAIN on the tenant is updated from version 1.0.0.0 to version 2.0.0.0
Step 5: App DEPENDEND crashes (object conflict!)
Unfortunately, also for this path there’s no (at the time of writing) an easy way to solve the problem and for this I recommend the above explained path. The added trouble here is that (if you want to avoid overlapping ranges) you should submit a new app on AppSource and then delete the old DEPENDENT app.
Be always careful with object ranges on your apps too, expecially for AppSource apps!
What’s my final think on this? Obviously, that partners must double-check their apps before putting them on a cloud environment, that they must always to develop solutions with AppSource rules in mind, but also that something must be done from the Microsoft’s side 🙂 I think that with a support ticket Microsoft should be able to perform a “ForceSynch” or something similar in order to fix problems related to conflicts on object names and IDs, without creating pains and troubles on partners. Start thinking on this…
Stefano Demiliani 