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:
Prefix/suffix missing. This is required to ensure a healthy app ecosystem that avoids name collisions.
DataClassification missing or set incorrectly – There is a tool to detect these, and it is not hard to automate.
Required translation files missing – These are required for specifying additional languages.
Missing permission sets - The least privilege execution policy requires proper permission set to be granted.
Permission errors – These must not be shown unless it entails a necessary action for the user.
Missing application area tagging – tenant applications can only be categorized with tagging
Usage category not set – This is required for search because the property helps to provide hints
Business open/close for a tenant implies a common handler into the invocation of code for the tenant. These must be properly maintained.
Upgrade procedures – An application can be upgraded properly if the standard operating procedure is followed.
Use logic owning the artifacts – they should not be updated or maintained if there is no ownership
Testing with elevated privileges hides the errors users might encounter.
Testing does not cover a specific scenario because the documentation for the scenario is not proper.
The configuration and environment settings can alter the behavior of the product and they must be set properly before testing.
No comments:
Post a Comment