Key Versioning for Business Objects via Logical Key Conversion
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Changes to key fields in business object systems cause disruptions and errors in interactions between multiple systems, particularly when extending key fields, leading to compatibility issues between systems with different key domain versions.
Innovation Solution
The implementation of logical and technical keys, along with a key conversion component, allows for the adaptation and conversion of object keys between different versions, ensuring compatibility by reserving space for a version identifier within the object key and using a Globally Unique Identifier (GUID) when key fields exceed size limits, enabling seamless communication between systems with varying key versions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If key fields are extended to accommodate additional business objects, then the adaptability of the system increases, but compatibility between systems with different key versions deteriorates
Solution Approach 1:
The object key is segmented into multiple components: a version identifier field and the actual key fields. This segmentation allows the system to distinguish between different versions of key fields, enabling legacy systems to interact with extended systems without disruption. The version identifier acts as a separator that allows each system to interpret the key structure appropriate to its version.
Solution Approach 2:
The legacy key structure is nested within the extended key structure. The extended system can contain the legacy key format as a subset, with additional fields added in a nested manner. This allows the extended system to process both legacy and extended keys, maintaining backward compatibility while providing enhanced functionality.
2Adaptability or versatility
If key field extensions are implemented to enhance business object functionality, then the versatility of the business object domain increases, but errors and disruptions in system interactions increase
Solution Approach 1:
The version identifier is incorporated into the key structure in advance, before any key field extensions occur. This preliminary action ensures that when extensions are made, the version identifier is already present to distinguish the extended key from legacy keys, preventing errors in system interactions.
Solution Approach 2:
The version identifier acts as an intermediary element between legacy systems and extended systems. It provides a mechanism for systems to identify and handle different key versions appropriately, mediating the interaction between systems with different key domain versions and preventing errors.
3Reliability
If a version identifier is reserved within the object key, then compatibility between different key versions is maintained, but the complexity of key management increases
Solution Approach 1:
The version identifier enables keys to self-identify their version, allowing systems to automatically determine how to process and interpret the key without requiring external version management logic. Each key carries its own version information, making the system self-managing and reducing overall complexity.
Solution Approach 2:
The version identifier provides a clear parameter that can be changed to reflect different key formats. This parameter-based approach allows for systematic management of key versions, where changing the version identifier parameter signals a change in key structure, making version management more organized and less complex.
4Ease of operation
If conversion between legacy and extended key formats is implemented, then seamless communication between systems is achieved, but the processing time and complexity increase
Solution Approach 1:
The version identifier is established in advance, allowing systems to pre-determine the conversion requirements. This preliminary identification of key version enables systems to prepare appropriate conversion logic ahead of time, reducing the actual conversion time when keys need to be exchanged between systems.
Solution Approach 2:
Instead of complex real-time conversion, the system creates and maintains copies of keys in the appropriate format for each system. The extended system maintains both extended keys and legacy key format copies, allowing for rapid exchange without complex real-time conversion, thus reducing processing time.
Data Source
AI summary
A computerized method, system and medium for providing compatibility between systems associated with incompatible object key domains, where a first system is associated with a legacy key domain and a second system is associated with an extended key domain relative to the first system. The method includes transmitting, to the first system, a request associated with a business object instance, the request including a first logical object key in a legacy format. Prior to sending the request, the second system converts a second object key in the extended format into the first logical object key from the legacy format. A response to the request is received which includes responsive content and the first logical object key. The first logical object key is converted from the legacy format into the second object key in the extended format, and the responsive content is processed in association with the converted second object key.