Handling a Dynamics 365 Business Central SaaS tenant in a cloud environment is not exactly like handling it on an on-premise installation. A SaaS tenant is fully managed by Microsoft under the hood, so you don’t care about infrastructure and all the cloud stuff that need to be provisioned for having an environment ready, secure, and always updated. But for having a customer happy in the cloud and for having a SaaS tenant that works well in a fully SaaS way, you also (as a partner) need to act and work accordingly.
In this article, I want to give you 15 tips that you should check (and adopt when possible) for providing a great SaaS tenant experience and service to your Dynamics 365 Business Central customers in the cloud. I’ve divided these tips into the following categories:
- Coding & deployment
Tip 1: check and configure your SaaS tenant’s Admin Center
Dynamics 365 Business Central Admin Center is the single point of administration for partners to administer their customers tenants and this is the first place where you need to go for doing at least the following things:
- Configure recipients: please configure at least one email address that will receive notifications from Microsoft. This is extremely important in order to be notified about upgrades and about possible problems during an upgrade (for example, if you have apps that break an upgrade process from Microsoft).
- Create at least a Sandbox environment: having a Sandbox in extremely important for testing apps and business flows before going to production.
- Configure the upgrade policy that fits your needs: please remember to set the upgrade window for your environments. This is extremely important to avoid automatic upgrades during business hours. You can also reschedule a planned upgrade if you’re not yet ready for it.
- Check for updated apps: from here you can check if there are available updates for Microsoft’s or AppSource apps and force them.
- Delete user’s blocking sessions: if you have user sessions that are blocking processes, you can kill them.
- Inspect errors on telemetry
Tip 2: remember that a Sandbox is different than a Production environment
Please always remember that Sandbox and Production are not the same environments under the hoods
Sandboxes run in a different performance tier on Azure than production environments. Production environments are protected by automatic backups that are retained for 30 days. The automatic backup that applies to production environments does not apply to sandbox environments.
If a sandbox is created with a copy of a production environment, several precautions are taken for that sandbox:
- The job queue is automatically stopped
- Any base application integration settings are cleared
- Outbound HTTP calls from extensions are blocked by default and must be approved for each extension
Also remember that If you publish an extension in a sandbox environment, this extension is published within the scope of the service node that is hosting the sandbox. When Microsoft upgrades the tenant to a new version (CU), the sandbox environment is “moved” to another service node running the new application version.
Please don’t do performance testing on the sandbox environment. If you need to do a reliable performance test, please create a new Production environment and do this test here.
Tip 3: Activate telemetry
Dynamics 365 Business Central comes with the possibility to send telemetry signals to Azure Application Insights, a service born for monitoring applications in the cloud. Please always connect your production environment to Azure Application Insights and monitor telemetry often.
Tip 4: When you perform tasks, remember the operational limits
Large-scale cloud services use shared resources to achieve the best possible use of resources (I/O, CPU, memory, etc.). To ensure that tenants run smoothly, limits are applied to various operations.
Without limits, one tenant could use many more resources than other tenants. Other tenants running on the same resources might experience slower performance.
Operational limits that you should be aware of are:
- Web service requests
- Report and query generation
- Client connections
- Background task execution
You can find more details about these limits at the following link.
Tip 5: use number series that allows gaps when possible
Number series in Dynamics 365 Business Central are shared resources that sometimes cause locking issues. Not all records that you create in Business Central are financial transactions that must use sequential numbering, and for such number series, you can select the Allow Gaps in Nos. checkbox on the No. Series Lines page:
This will permit you to avoid locks and increase performances when assigning number series.
Tip 6: don’t do these things on SaaS:
Please remember that in a SaaS environment, it is not recommended to:
- Set up a change log for everything.
- Run job queues too frequently.
- Adjust item costs automatically if you have many item entries. Run in the background instead.
- Postpone setting up global dimensions, because it can be a heavy operation when you have much data. Set up correct global dimensions to avoid changing them later on.
- Run the Copy company operation during business hours.
Tip 7: Use Data Compression if needed
Data compression is a SQL Server technique that permits you to compress data in a table (row-level compression or page-level compression). Data compression is supported from Dynamics 365 Business Central version 14, and it permits you to:
- Reduce the size of selected tables (so the size of the database)
- Improve I/O intensive workloads performances
To increase performances and decrease the size of your cloud database, you can use data compression on archive tables or tables like Posted Sales and Purchase documents.
For more details about data compression with Dynamics 365 Business Central, please refer to this link.
Tip 8: use Read-scale out
This is one of my preferred features.
Azure SQL supports the Read Scale-Out feature (read-only replica, enabled by default on Premium, Business Critical, and Hyperscale service tiers). In Dynamics 365 Business Central SaaS, the read scale-out feature is automatically enabled by default.
Reports, Queries, and API pages have a new property called DataAccessIntent that permits you to set whether to get data required by this object from a read-only replica of the database or the primary database:
You can also control the DataAccessIntent property for your objects directly via the user interface by going to the Database Access Intent List page. More information can be found here.
Coding and Deployment
Tip 9: Write efficient pages
For the end-user (your customer), having a slow page means that the entire application seems slow.
When you design pages, please don’t abuse showing FlowFields and avoid unnecessary recalculation (consider caching the data and refresh the cache on a regular basis).
Tip 10: use of Page Background Tasks for statistics
If you have pages that show large statistics, please do the calculations in a background task and not on the main UI thread. Page Background tasks permit you to offload the UI thread, and they have the following characteristics:
- Same Business Central Server instance as the parent session
- Performs read-only operations; it cannot write to or lock the database
- The parameters that are passed to and returned from page background task are in the form of a Dictionary<string,string>
- The callback triggers cannot execute UI operations, except notifications and control updates
- If the calling page or session closes or the current record is changed, the background task is canceled.
- It has a default and maximum timeout, which cancels the task automatically.
More information can be found at the following link.
Tip 11: check for web service performances
Dynamics 365 Business Central permits you to expose web services by simply publishing a page object.
If you work with web services in this way, please remember these things:
- Avoid using standard UI pages to expose as web service endpoints. Many things, like FactBoxes, aren’t exposed in OData but will use resources to compute.
- Things that cause performance issues on Page exposed as services:
- Logic in OnAfterGetCurrRecord or OnAfterGetRecord
- SIFT fields
- Don’t use temp tables as a source if you have a lot of records. Temp tables-based APIs are a performance hit. The server has to fetch and insert every record, and there is no caching on data in temp tables (if you have > 100 records, don’t use Temp tables)
Remember also that instead of exposing UI pages as web service endpoints, use the built-in API pages or your custom APIs because they’ve been optimized for this scenario.
Tip12: don’t abuse on table extension objects
When you create N separate apps (extensions), please always be careful about extending standard tables (and maybe heavily used tables) from different extensions. Remember that a tableextension object is joined with the base table on every query, and it’s currently not possible to define indexes that span base and extension fields.
Be careful about extending central tables, such as General Ledger Entry, because it can severely hurt performance. In many scenarios, it is better to create a new table linked to the GL Entry with your custom fields.
Tip 13: always activate code analyzers when developing AL extensions
The AL Language extension comes with the possibility to perform static code analysis (executed in the background) on your AL projects from within Visual Studio Code. The AL Language extension contains 4 analyzers (CodeCop, PerTenantExtensionCop, AppSourceCop, UICop), that you can activate when needed in the Visual Studio Code settings.
Code analysis is mandatory for AppSource apps (always enable AppSourceCop), but for per-tenant extensions (PTE), I recommend enabling code analysis when writing your code. It will help you on checking errors and warnings (and discover possible future problems) and having clean code.
More information can be found here: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-using-code-analysis-tool?WT.mc_id=BA-MVP-5003072.
Tip 14: Automate your extension’s deployment
When deploying extensions to your customer’s tenant, please avoid using the Visual Studio Code. Visual Studio code should be used only in real development environments, not on the customer’s site.
For deploying extensions on a SaaS tenant, you can use the Extension’s Management page (this is the manual way) or (much better) you can automate the deployment task.
For this automation, you can use Azure DevOps and the Dynamics 365 Business Central Automation APIs for creating release pipelines and centralizing the deployment of your apps. You can also create multi-stage pipelines for better control of the releases.
Tip 15: Use Admin Center APIs for centralizing administrative tasks
The Business Central Administration Center API enables administrators to programmatically do administrative tasks for a Business Central tenant. Please use these APIs in order automate administrative tasks remotely like creating environments, checking the database size for an environment (and act accordingly), copy environments, remove environments, checking extensions installed for a particular environment, setting the upgrade window or reschedule upgrades, setting notification recipients and so on.
With some simple custom scripts, you can fully monitor your customers.
Take this list of tips as a “to-do” list and, for every project you start, please give it a quick check. If you respect it, your SaaS experience could have a lot of benefits.