Concepts: Multi-Tenancy
Feature flighting service is multi-tenant by default where a single instance can used by multiple applications.
Flag ID
Tenancy is implemented by appending the name of the tenant in the Feature Flag ID. This ensures that 2 tenants can have 2 flags by the same name without causing a conflict. Along with the tenant name the sub-environment is also added in the flag name to ensure that a tenant can create the same feature toggle for multiple environments.
So for a feature flag with following traits
- Flag name - EnableAdvancedTaxCalculation
- Tenant name - FinanceCore
- Sub-environment - SIT
The flag ID would be
FinanceCore_SIT_EnableAdvancedTaxCalculation.
The feature flighting system would take care of creating and maintaining the Flag ID, downstream tenants won't need to create or use the ID. If the tenant name and environment name is passed in the x-application and x-environment headers properly, all necessary processing will taken care by the Feature Flighting System.
Admin Team
If there is no need for multi-tenancy and you want to use the Feature Flighting System for a single application, then you will need to board only a single tenant. However, if you want to multiple applications or downstream tenants to use the same service then a separate Admin team is needed for maintaining the deployed artifacts. The admin team will also have the added responsibility to board any downstream partners.
Tenant Name
For a single instance tenant name must be unique. There are 2 tenant names allowed - Full Name and Short Name. The short name is user-friendly version of the full tenant name. Either of these values can be passed in the x-application header. We suggest passing the Full Name.
Tenant Configuration
For each tenant the following configurations are required
| Name | Type | Description | Config Path |
|---|---|---|---|
| Name | String | Full name of the tenant | Name |
| Short Name | String | Short name (moniker) of the tenant | ShortName |
| Auth Type | String | Type of authorization allowed. Currently only 'Configuration' type is allowed | Authorization:Type |
| Cache - Feature Flag Names | String | Cache type to cache names of Feature flags | Cache:FeatureFlagNames |
| Cache - Feature Flags | String | Cache type to cache feature flag results | Cache:FeatureFlags |
| Cache - Graph | String | Cache type to cache data from graph (User list from Group) | Cache:Graph |
| Cache - Operator Mapping | String | Cache type to cache the filter-operator mapping | Cache:OperatorMapping |
| Cache - Rules Engine | String | Cache type to cache the Rules engine JSON | Cache:RulesEngine |
| Cache - URP | URP Config | Feature flighting system is integrated with Unified Redis Platform. Provide App, Cluster and Secret Location. | Cache:URP |
| Enhancements - Disabled Context | bool | Enables or disabled the disabled context | Evaluation:AddDisabledContext |
| Enhancements - Add Enabled Context | bool | Enables or disabled the enabled context | Evaluation:AddEnabledContext |
| Enhancements - Ignore Exception | bool | Will evaluate the feature toggle to false for any unhandled exception during execution |
Evaluation:IgnoreException |
| BRE Enable | bool | Rules Engine filter is enabled when set to true |
BusinessRuleEngine:Enabled |
| BRE Storage Connection String Location | String | Secret key in Key Vault containing the connection string of the Storage Account having Rule Engine JSON files | BusinessRuleEngine:Storage:StorageConnectionStringKey |
| BRE Container Name | String | Name of the blob container with the Rule Engine JSON files | BusinessRuleEngine:Storage:StorageConnectionStringKey |
| BRE Cache Duration | Number | Duration (in mins) to cache the Rule Engine JSON files | BusinessRuleEngine:CacheDuration |