Some rules, applications, and guidelines for multitenant application extension development:  

When multitenant application extensions are developed, there are a few best practices that can be called out. This article covers some of them.  

Some of the common pitfalls in multitenant application development include the following:  

1. Prefix/suffix missing. This is required to ensure a healthy app ecosystem that avoids name collisions.  

2. DataClassification missing or set incorrectly – There is a tool to detect these, and it is not hard to automate.  

3. Required translation files missing – These are required for specifying additional languages.  

4. Missing permission sets - The least privilege execution policy requires proper permission set to be granted.  

5. Permission errors – These must not be shown unless it entails a necessary action for the user.  

6. Missing application area tagging – tenant applications can only be categorized with tagging  

7. Usage category not set – This is required for search because the property helps to provide hints  

8. Business open/close for a tenant implies a common handler into the invocation of code for the tenant. These must be properly maintained.  

9. Upgrade procedures – An application can be upgraded properly if the standard operating procedure is followed.  

10. Use logic owning the artifacts – they should not be updated or maintained if there is no ownership  

11. Testing with elevated privileges hides the errors users might encounter.  

12. Testing does not cover a specific scenario because the documentation for the scenario is not proper.  

13. The configuration and environment settings can alter the behavior of the product and they must be set properly before testing.  

The tenant application extension lifecycle also differs significantly enough from mainstream single-tenant applications to be called out here: 

1. Migration – Data might need to be migrated between extensions. The process applies to both large- and small-scale data migrations. Upgrade can be treated as a large-scale data migration. Small scale data migrations are where a few objects are hand-picked between extensions. The migration’s direction is dependent on the dependency graph. 

2. Translations can be applied to multiple properties and these captions are scoped to their entities. They can be changed from multiple places and might live in different artifacts, but they are associated with the entities they are for. 

3. Tests can be isolated as database transactions in the tenant namespace. The difference between a normal run versus a test run is that a failure in the former means that it stops while a failure in the latter means that it can skip to the next. 

4. Publishing and installing an extension requires an external registry and installation in individual tenant namespaces. The extension then becomes available to the users in the client. 

5. Updating and upgrading differ in the behavior of the code before and after. Upgrade strives to maintain backward compatibility while update can replace wholesome. 

6. Deprecation best practices involve the use of conditional directives to surround the code to be obsoleted. 

 Some rules, applications and guidelines for multitenant application: 

When multitenant applications are developed, there are a few best practices that can be called out. This article covers some of them. 

When naming objects pertaining to a tenant such as tables, pages, artifacts, using a prefix/suffix helps to reduce name collisions with those defined in others. The prefix/suffix must be at least 3 characters. The object/field name must start or end with a prefix/suffix. If a conflict arises, the one who registered the prefix always wins. Setting the prefix/suffix at the top level of objects is sufficient for domain specific objects. A tool can be used to detect missing prefixes or suffixes. 

Instrumenting the application for telemetry.  This data can be collected and visualized for analyzing the application against the desired business goals, troubleshooting and more. 

One aspect of event logging is the data collection about the working and deployment infrastructure of an application to diagnose conditions and troubleshoot problems that affect its operation and performance. Application and database can both emit events. Metrics and logs can flow into a time-series database and used with read-only reporting stacks that render impressive visualizations. When these charts and graphs make it to a dashboard, the overall health of the system can be monitored. 

Telemetry can be divided into different categories that include those for engineering purposes, those for business and those for customers. Custom telemetry signals can also be emitted. By default, the signals emitted by the system can be sent to multiple destinations such as event logs and application insights. Custom signals can enable sending data from anywhere in the application code to one of these destinations. 

Testing the tenant specific extensions allows us to catch some of the basic errors that would otherwise be discovered only later. Install, uninstall, publish and unpublish are some of the actions that can guarantee proper testing in isolation. Sometimes a feature flag is sufficient and other times leveraging the application store workflow is preferable. Testing with the least required privileges is helpful to limit the impact to the system. 

Documentation is easily overlooked even for key scenarios but including all the necessary information in such as details, inexperienced users, screenshots, prerequisites and setups if any, functionality walkthroughs and such others. 

When writing code for web services, it is best to separate out the user interactivity. The web service must run independently of a user interface. Descriptive error messages can be propagated via the user interface. Building an advanced sample extension 

Leveraging as much declarations as possible also avoids reduce changes to the code. Configurations and settings help in this regard. 

Some of the common pitfalls in multitenant application development include the following: 

1. Prefix/suffix missing. This is required to ensure a healthy app ecosystem that avoids name collisions. 

2. DataClassification missing or set incorrectly – There is a tool to detect these, and it is not hard to automate. 

3. Required translation files missing – These are required for specifying additional languages. 

4. Missing permission sets - The least privilege execution policy requires proper permission set to be granted. 

5. Permission errors – These must not be shown unless it entails a necessary action for the user. 

6. Missing application area tagging – tenant applications can only be categorized with tagging 

7. Usage category not set – This is required for search because the property helps to provide hints 

8. Business open/close for a tenant implies a common handler into the invocation of code for the tenant. These must be properly maintained. 

9. Upgrade procedures – An application can be upgraded properly if the standard operating procedure is followed. 

10. Use logic owning the artifacts – they should not be updated or maintained if there is no ownership 

11. Testing with elevated privileges hides the errors users might encounter. 

12. Testing does not cover a specific scenario because the documentation for the scenario is not proper. 

13. The configuration and environment settings can alter the behavior of the product and they must be set properly before testing. 

Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN   

 

Some rules, applications and guidelines for multitenant application:

When multitenant applications are developed, there are a few best practices that can be called out. This article covers some of them.

When naming objects pertaining to a tenant such as tables, pages, artifacts, using a prefix/suffix helps to reduce name collisions with those defined in others. The prefix/suffix must be at least 3 characters. The object/field name must start or end with a prefix/suffix. If a conflict arises, the one who registered the prefix always wins. Setting the prefix/suffix at the top level of objects is sufficient for domain specific objects. A tool can be used to detect missing prefixes or suffixes.

Instrumenting the application for telemetry.  This data can be collected and visualized for analyzing the application against the desired business goals, troubleshooting and more.

One aspect of event logging is the data collection about the working and deployment infrastructure of an application to diagnose conditions and troubleshoot problems that affect its operation and performance. Application and database can both emit events. Metrics and logs can flow into a time-series database and used with read-only reporting stacks that render impressive visualizations. When these charts and graphs make it to a dashboard, the overall health of the system can be monitored.

Telemetry can be divided into different categories that include those for engineering purposes, those for business and those for customers. Custom telemetry signals can also be emitted. By default, the signals emitted by the system can be sent to multiple destinations such as event logs and application insights. Custom signals can enable sending data from anywhere in the application code to one of these destinations.

Testing the tenant specific extensions allows us to catch some of the basic errors that would otherwise be discovered only later. Install, uninstall, publish and unpublish are some of the actions that can guarantee proper testing in isolation. Sometimes a feature flag is sufficient and other times leveraging the application store workflow is preferable. Testing with the least required privileges is helpful to limit the impact to the system.

Documentation is easily overlooked even for key scenarios but including all the necessary information in such as details, inexperienced users, screenshots, prerequisites and setups if any, functionality walkthroughs and such others.

When writing code for web services, it is best to separate out the user interactivity. The web service must run independently of a user interface. Descriptive error messages can be propagated via the user interface. Building an advanced sample extension

Leveraging as much declarations as possible also avoids reduce changes to the code. Configurations and settings help in this regard.

Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN      

  

 

Supportability features of databases:

This is a follow up to the previous article on the supportability features of databases:

There are dynamic management views available to query information on the following:

These dynamic management views include Always On availability groups, Change Data Capture, Change Tracking Related, Common Language Runtime, Database Mirroring, Database related, Execution related,  Extended events, Filestream and Filetable, Full-text search and semantic search, Geo replication, Index related, I/O related, PolyBase, Memory-Optimized, Object Related, Query Notifications related, Replication related, Resource Governor related, Security-related, Server-Related, Service Broker, Spatial Data, Azure Synapse analytics and Parallel data warehouse, SQL Server operating system related, stretch database and transaction related.

The DMV for always on availability groups describes threads, page repair, automatic seeding, availability group states, availability replica cluster nodes, availability replica cluster states, cluster members and networks, replica cluster states, node maps and listener states.

The DMV for change data capture contains one row for each error encountered during the change data capture log scan session.

The DMV for common language runtime provides information on clr appdomains, clr properties, loaded assemblies, and active tasks.

The DMV for mirroring related auto page repair returns a row for every automatic page-repair attempt on any mirrored database on the server instance.

The DMV for execution related information describes background queues, cached plan dependent objects, compute node errors, cursors, first result set for objects, distributed requests, function stats, query memory grants, query optimizer memory gateway, exec query parallel workers, exec query resource semaphores, exec query stats, exec requests, exec sessions, cached plans, distributed requests, dms workers and input buffer, query plans and query statistics.

The extended event DMVs provide information on map values, objects, packages, session event actions, targets and sessions.

The object related dynamic management views display stats properties and sql referencing entities, db_stats_histograms, and sql referenced entities.

The server related DMVs display information on memory dumps, server services, and registry.

The spatial data related DMVs provide information on the indexes and constraints containing UDT columns of spatial data types that will be disabled as a result of changing compatibility level in SQL Server

The transaction related DMVs provide information on current snapshots, database transactions, session transactions, current and active transactions and version stores.