Dynamic View Abstraction for Business Object Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for defining views on business object types are static and limited, often losing business context and requiring significant effort, and fail to accommodate varying technical implementations and data scopes across different systems.
Innovation Solution
A dynamic approach where a request containing data characterizing a view on business object types allows for hierarchical element association, enabling operations on multiple business object types with join conditions, and generating results in a compatible structure, decoupling consumer and provider systems through an abstraction layer.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If views on business object types are defined statically and implemented individually, then the view structure is fixed and simple to implement, but the system lacks flexibility to accommodate varying business needs and requires significant effort to realize different views
Solution Approach 1:
The patent transforms static view definitions into dynamic ones by allowing view characteristics to be specified at runtime through requests. The view on a business object type is no longer fixed but can be dynamically adjusted based on the specific operation and business needs, enabling the system to adapt flexibly without requiring complex pre-definition of all possible views
Solution Approach 2:
The patent creates a universal mechanism for defining views that can serve multiple purposes. The same request-based approach can define views for different business object types, different operations, and different consumers, replacing the need for individual static view implementations with a single multi-functional framework
2Ease of operation
If views are built on the database level, then data access is simplified, but business context is lost and business validations are no longer applicable
Solution Approach 1:
The patent introduces an intermediary layer between the database and the consumer. Instead of accessing data directly at the database level or requiring complex business object transformations, the request-based view definition acts as a mediator that preserves business context while enabling straightforward data access. The view characteristics specified in the request maintain the connection to business semantics and validations
3Adaptability or versatility
If different systems use different technical implementations of business object types, then each system can optimize for its specific needs, but integration between systems becomes complex and requires mapping different formats
Solution Approach 1:
The patent uses parameter changes to resolve integration complexity. Instead of requiring structural changes or complex mapping between different technical implementations, the system changes the parameters of the request to specify the desired view characteristics. The consumer can request data in its needed format by specifying view characteristics in the request, while the provider maintains its own technical implementation, with the transformation handled dynamically based on request parameters
Data Source
AI summary
A request is received to initiate an operation (e.g., a query, etc.) on a view on a business object type. Such a request contains data characterizing the view which in turn characterizes a plurality of hierarchically arranged elements. Such elements characterized are associated with elements characterized by one or more business objects types. Thereafter, the operation is performed on the elements of the two or more business objects types. Responsive results of the operation responsive are mapped to the elements of the virtual business object type. After such mapping occurs, a message is generated that contains the results of the request in a structure compatible with the view.