Bulk Metadata Service for ERP Interface Adaptation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current ERP software architectures face performance issues due to the inefficient access of dynamic and static metadata, leading to increased network data volume, memory consumption, and response time, particularly in user interfaces, as a result of limited metadata granularity and redundant requests during service adaptations.

Innovation Solution

A bulk metadata service is introduced that determines if a stored definition of metadata properties is available, instantiating a bulk service interface to access dynamic metadata for user interface generation, or initiates a default process to retrieve metadata from existing interfaces, with optional use-case specific services and fine metadata granularity, leveraging Service Adaption Language (SADL) for improved access efficiency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If frontend service adaptation is used to combine fields from different business object nodes, then user interface customization is improved, but network data volume increases and response time deteriorates

Engineering Contradiction:
Improveuser interface customizationVSAvoidresponse time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system performs service adaptation in advance during system initialization or caching phases, preparing adapted business object nodes before they are actually needed at runtime. This preliminary action stores pre-adapted configurations that can be quickly retrieved during user interface generation, eliminating the need for real-time adaptation and association path evaluation.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The invention introduces a service adaptation layer that acts as an intermediary between the backend business objects and the frontend user interfaces. This intermediary handles the complex service adaptation logic, field combination, and association path evaluation in a centralized manner, allowing the backend to remain simple while providing customized interfaces to the frontend without direct backend involvement in each adaptation request.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If all data on an associated path is transferred to the frontend server for service adaptation, then user interface flexibility is improved, but memory consumption increases

Engineering Contradiction:
Improveuser interface flexibilityVSAvoidmemory consumption
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The invention extracts only the necessary metadata and configuration information needed for service adaptation from the complete business object data, rather than transferring all data to the frontend. This extraction approach allows the system to work with lightweight representations of business objects, reducing memory consumption while maintaining the ability to perform service adaptation and generate flexible user interfaces.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system segments the data transfer process by separating metadata (structure, relationships, adaptation rules) from actual business data. Only the segmented metadata portions required for service adaptation are transferred to the frontend server, while the heavy business data remains on the backend. This segmentation enables user interface flexibility without the memory overhead of transferring complete business objects.

Inventive Principle:
Principle #1Segmentation

3Loss of information

If many association paths are evaluated on the frontend to access required business object fields, then data access completeness is improved, but processing time increases

Engineering Contradiction:
Improvedata access completenessVSAvoidprocessing speed
Core Design Contradiction:
Loss of informationVSProductivity

Solution Approach 1:

The system performs association path evaluation and metadata access planning in advance, determining all necessary association paths and required business object fields before actual data retrieval. This preliminary analysis creates an optimized access plan that minimizes the number of association paths that need to be evaluated at runtime, ensuring complete data access while reducing processing time during user interface generation.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS8612927B2Bulk access to metadata in a service-oriented business framework
Publication Date: 2013.12.17 SAP SE
  • US8612927B2 patent drawing
  • US8612927B2 patent drawing
  • US8612927B2 patent drawing

AI summary

A bulk service interface can be instantiated for each of at least one service provider providing a plurality of business objects using a stored definition of a plurality of metadata properties relating to generation of a user interface that incorporates content of a plurality of business objects. The bulk service interface can query the stored definition and access, in a bulk metadata access process, dynamic metadata required for instantiation of the plurality of business objects. If the stored definition has not previously been received, a default bulk services access process that queries an existing dynamic metadata access interface of each of the plurality of business objects can be initiated to retrieve the dynamic metadata from each of the plurality of business objects. An instance of the user interface can be generated using dynamic metadata accessed by the bulk service interface and/or the retrieved by the default bulk services access process.