Database Object Delivery Infrastructure for Zero-Downtime Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In the context of software development, managing cross-schema dependencies in a development phase and later in a deployment phase is challenging, especially with the rapid evolution of in-memory databases that introduce new features and data formats, making it impractical to redesign Advanced Business Application Programming (ABAP) to natively support each new version.
Innovation Solution
A database object delivery infrastructure is introduced that defines a dependency model between objects managed by different infrastructures, allowing for top-level management of cross-schema dependencies through logical and physical schema names, ensuring cycle-free dependencies and enabling zero-downtime upgrades by orchestrating the deployment of database objects across multiple schemas.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If ABAP is updated to support new features and data formats of each new in-memory database version, then compatibility with the latest database version is improved, but the complexity and effort of maintaining ABAP increase significantly
Solution Approach 1:
The patent introduces a schema mapping layer as an intermediary between ABAP and the in-memory database. This mapping layer handles the complexity of new database features and data formats, allowing ABAP to interact with the database through a stable, version-agnostic interface. The mapping layer translates ABAP operations into database-specific operations, isolating ABAP from direct exposure to database version changes.
Solution Approach 2:
The system segments the database interaction layer into distinct components: the ABAP layer, the schema mapping layer, and the physical database layer. This segmentation allows each layer to evolve independently, with the schema mapping layer absorbing the impact of database version changes while preserving ABAP stability.
2Ease of operation
If cross-schema dependencies are managed without a structured infrastructure, then development flexibility is maintained, but deployment reliability and correctness deteriorate due to cyclic dependencies and incorrect deployment orders
Solution Approach 1:
The patent performs preliminary analysis of cross-schema dependencies during the development phase, building a dependency graph that captures all relationships between database objects across schemas. This preliminary modeling enables the system to detect cyclic dependencies early and establish a valid deployment order before actual deployment occurs, preventing deployment failures.
Solution Approach 2:
The system implements feedback mechanisms that monitor dependency relationships during development and deployment. When cyclic dependencies are detected or deployment order conflicts arise, the system provides feedback to developers to resolve the issues, ensuring deployment reliability while maintaining development flexibility.
3Reliability
If database objects are deployed with downtime to ensure proper installation order and dependency resolution, then deployment reliability is improved, but service availability deteriorates during the deployment process
Solution Approach 1:
The patent performs preliminary dependency analysis and deployment order determination before actual deployment, creating a validated deployment plan that ensures correctness. This preliminary planning enables subsequent deployments to proceed with minimal or zero downtime, as the system can apply changes in the pre-determined safe order without requiring service interruption.
Solution Approach 2:
The system implements dynamic deployment strategies that can adapt to different scenarios, including zero-downtime deployment modes where possible. The deployment infrastructure can dynamically adjust the deployment process based on the dependency graph, allowing continuous service operation while maintaining deployment reliability.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
In an example embodiment, one or more changes to one or more objects in the software object database are received from a developer. A change list is generated based on the one or more changes. An object definition is exported for every object in the change list from a first schema in the database to a second schema in the software object database. A first object in the second schema is activated by mapping a logical schema name specified in the object definition for the first object to a corresponding physical schema name and creating or altering the first object in the second schema using the physical schema name.