Multi-tenant Rules Engine with Tenant-Specific Extensions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing multi-tenant database systems struggle to efficiently manage and execute rules-based logic across multiple tenants while maintaining data privacy and flexibility in business processes.
Innovation Solution
The implementation of a rules engine (RE) within a multi-tenant database environment that utilizes an industry-standard rule structure and syntax, allowing for tenant-specific rule extensions and metadata-aware business logic execution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a rules engine is implemented in a multi-tenant database environment with tenant-specific rule extensions, then adaptability and flexibility of business logic are improved, but system complexity and difficulty of managing rules across multiple tenants increase
Solution Approach 1:
The patent segments the rules engine into shared core functionality and tenant-specific extensions. The shared rules engine provides common business logic execution capabilities, while each tenant can define their own extension rules that build upon or modify the shared rules. This segmentation allows independent development and management of tenant-specific logic without affecting other tenants, resolving the contradiction between adaptability and system complexity.
Solution Approach 2:
The patent implements a universal rules engine framework that serves multiple tenants with different business requirements. The shared rules engine provides common functionality for all tenants, while the extension mechanism allows each tenant to customize the behavior. This multi-functional design enables a single system to handle diverse business logic needs without requiring separate systems for each tenant, thus improving adaptability while managing complexity through standardization.
2Ease of operation
If tenant-specific extension rules are allowed to modify shared rules, then ease of operation and customization are improved, but data privacy and security between tenants may be compromised
Solution Approach 1:
The patent applies local quality by allowing each tenant to have their own extension rules that modify or extend shared rules in a tenant-specific manner. The system evaluates rules with awareness of the tenant context, ensuring that each tenant's extensions only affect their own data and operations. This contextual isolation maintains data privacy while enabling easy customization, as each tenant's modifications are locally applied without exposing other tenants' data.
Solution Approach 2:
The patent introduces a context-aware rule evaluation mechanism that acts as an intermediary between the shared rules engine and tenant-specific extensions. This intermediary layer manages the interaction by injecting tenant context into the rule evaluation process, ensuring that extension rules operate within appropriate security boundaries. The mediator ensures that while tenants can easily customize their business logic, the underlying data privacy and security constraints are maintained through controlled access and contextual awareness.
3Productivity
If a shared rules engine is used across multiple tenants, then productivity and resource efficiency are improved, but the ability to handle tenant-specific business logic variations decreases
Solution Approach 1:
The patent implements dynamic rule evaluation that adapts to each tenant's specific context. The shared rules engine dynamically loads and applies tenant-specific extension rules based on the executing tenant's identity and requirements. This dynamic behavior allows the system to maintain the efficiency of a shared engine while adapting to diverse tenant-specific business logic, as the rule set is flexibly configured at runtime rather than being static.
Solution Approach 2:
The patent employs a nested structure where tenant-specific extension rules are embedded within the shared rules engine framework. The extension rules are nested as layers on top of the shared rules, allowing the system to execute a combination of common and customized logic in a unified manner. This nesting enables the shared engine to provide baseline productivity and resource efficiency, while the nested extension layers add tenant-specific adaptability without requiring separate execution environments.
Data Source
AI summary
A rules engine (RE) may operate in conjunction with a database providing functionality, such as transactional support in data access environments on behalf of tenants. The database may have a data repository accessible by multiple tenants, and tenants may have a private context. RE rules may be defined in the data repository having an extension point corresponding to an extension defined in the private context. Execution of database functionality may affect data defined in the database. Execution of RE rules corresponding to database functionality affects corresponding data associated with the RE. Various techniques, e.g., fact handles, event listeners, etc. may be used to coordinate tracking and synchronizing changes between RE data and/or the database. A flag or other indicator may signify state preservation between multiple calls to the database and/or the RE, e.g., to support analysis involving transactions having overlapping intermediary results such as results from performing data lookups.