Policy Management Resolver for Software Testing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Software testing for policy management systems is resource-intensive and inefficient due to the need for reconfiguring multiple instances of the system for different testing scenarios, which can prolong development and testing times and require significant computing resources.

Innovation Solution

A system with multiple clusters of policy management systems configured differently for various scenarios, using a resolver with a lookup table to direct external services to the appropriate instance for accessing policy data, allowing services to interact without reconfiguration.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple instances of policy management system are created for different testing scenarios, then testing coverage and versatility are improved, but device complexity and resource consumption increase

Engineering Contradiction:

Improvetesting coverageVSAvoidsystem complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

A resolver component is introduced as an intermediary between external services and multiple policy management system instances. The resolver maintains a lookup table that maps service identifiers to appropriate instance identifiers, enabling services to interact with the correct instance without direct configuration. This mediator simplifies the overall system architecture by centralizing the routing logic.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

External services are designed to be universal and can interact with any policy management system instance through the resolver. Instead of creating specialized services for each testing scenario, a single service instance can dynamically route to different policy management instances based on the lookup table, reducing the number of services needed.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Reliability

If policy management system is reconfigured for each testing scenario, then testing accuracy and scenario-specific performance are improved, but time consumption and productivity decrease

Engineering Contradiction:

Improvetesting accuracyVSAvoidtesting speed

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The resolver is pre-configured with a lookup table that contains all the routing information needed for different testing scenarios. This preliminary setup eliminates the need for dynamic reconfiguration during testing, as the routing decisions are already determined and stored.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system enables dynamic instance selection without dynamic reconfiguration. The lookup table allows the resolver to dynamically route services to appropriate instances based on pre-stored mappings, combining the benefits of scenario-specific configuration with rapid switching capability.

Inventive Principle:

Principle #15Dynamics

3Productivity

If multiple instances of policy management system are maintained concurrently, then parallel testing capability is improved, but resource usage and energy consumption increase

Engineering Contradiction:

Improveparallel testing capabilityVSAvoidcomputing resource usage

Core Design Contradiction:

ProductivityVSUse of energy by moving object

Solution Approach 1:

Multiple policy management system instances are merged into a coordinated ecosystem managed by the resolver. Instead of running completely independent testing environments, the system combines multiple instances with a central routing mechanism, allowing shared infrastructure and reduced redundant resource consumption.

Inventive Principle:

Principle #5Merging (Combining)

4Reliability

If services are directly configured to communicate with specific policy management instances, then communication reliability is improved, but system flexibility and ease of operation decrease

Engineering Contradiction:

Improvecommunication reliabilityVSAvoidsystem flexibility

Core Design Contradiction:

ReliabilityVSEase of operation

Solution Approach 1:

The resolver serves as an intermediary layer that maintains reliable service-to-instance communication through the lookup table while preserving system flexibility. Services communicate with the resolver using standard protocols, and the resolver handles the instance-specific routing, decoupling service configuration from instance selection.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS20240378138A1Software testing with multiple instances of policy management system

Publication Date: 2024.11.14 STATE FARM MUTAL AUTOMOBILE INSURANCE COMPANY

AI summary

Different instances of a policy management system, in different clusters of a computing environment, can be configured differently for different purposes. Different policy databases, associated with the different instances of the policy management system, can store different sets of policy data that may be used or accessed during software testing or other operations via the different instances of the policy management system. A resolver can use a lookup table to track which instances of the policy management system are associated with corresponding instances of policy data. External services that access policy data during software tests and/or other operations can query the resolver to determine which instances of the policy management system to communicate with to access particular instances of policy data, such that the services can interact with differently-configured instances of the policy management system without the services themselves being reconfigured or changed.