Where-Used Objects List for Enterprise Software Patch Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Standard enterprise applications struggle to identify and update customized customer applications after changes in the provider's software, as ascertaining which parts of the standard application have been changed and their applicability to customer applications is a complex task, especially when patches are applied.
Innovation Solution
A system and method for generating a where-used objects list by comparing contracts of provider's objects with their new versions, detecting changes, and providing a list of affected objects, which includes a repository unit, a development platform, and an import tool to manage and update customized programs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If standard enterprise applications are used to cover all possible customer environments, then the application platform provides comprehensive functionality, but it cannot accommodate all customizations and requirements
Solution Approach 1:
The system segments the application into standard provider objects and customer-specific customizations. The repository unit stores both standard objects and custom objects separately, allowing independent management and updating of standard components while preserving customer customizations.
Solution Approach 2:
The system creates copies of standard provider objects in the repository unit, allowing customers to customize these copies without affecting the original standard objects. This enables comprehensive customization while maintaining the base functionality of the standard application.
2Reliability
If the provider's application is changed via software patches, then bug fixing and new functionality are embedded, but ascertaining which parts need updating in customer applications becomes complex
Solution Approach 1:
The system provides feedback by automatically detecting changes in standard provider objects and generating a where-used objects list that shows which customer applications are affected. The import tool then provides feedback on what needs to be updated in customer applications based on the detected changes.
Solution Approach 2:
The system replaces manual inspection of code changes with automated comparison mechanisms. The import tool automatically compares the new version of provider objects with the stored contracts and detects changes, eliminating the need for manual code review.
3Reliability
If every customer application is tested after updates, then complete compatibility is ensured, but testing time and resources are consumed
Solution Approach 1:
Instead of testing every customer application thoroughly, the system performs a partial action by generating a where-used objects list that identifies only the affected applications. This allows targeted testing of only the necessary applications, reducing time while maintaining reliability.
Solution Approach 2:
The system performs self-service by automatically detecting changes and generating the where-used objects list without requiring manual intervention. The import tool automatically compares versions and identifies affected applications, reducing the time needed for compatibility checking.
4Difficulty of detecting and measuring
If source code lines are compared to detect copied programs, then copying is detected, but the complexity of comparing and analyzing code increases
Solution Approach 1:
The system extracts the comparison task from manual code analysis and places it in the import tool, which automatically compares the new version of provider objects with stored contracts. This extraction simplifies the complexity by automating the comparison process.
Solution Approach 2:
The system changes the parameter of comparison from line-by-line source code analysis to comparison of object contracts and metadata. This parameter change simplifies the detection process by focusing on structural and interface-level differences rather than detailed code lines.
Data Source
AI summary
Methods and systems are described that involve creating a where-used objects list that contains a set of provider's objects to be adjusted or tested in a customized program after an upgrade of a program, import of projects, patches, and so on. A set of contracts is created that corresponds to the set of provider's objects used in the customer system. Each contract contains information about the provider's object it is created for and assigned to. This information is used by a lifecycle tool to detect if a provider's object has been changed by comparing the contract information of the provider's object with a new imported version of the same provider's object. The provider's object is modified according to the detected change and the assigned contract is recreated to represent the latest data.