Dynamic Where-Used List Update for ERP Metadata
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing ERP software systems struggle to maintain metadata consistency and transparency of dependencies between data elements, especially in customizable software solutions where hard-programmed where-used listings are inadequate due to varying business processes.
Innovation Solution
A computer-implemented method that detects unindexed data elements and applies a set of rules to update the where-used list by identifying unidirectional dependency relationships, enabling dynamic calculation and periodic recalculation of dependencies using a meta-meta-model, which is applicable in multi-tenant software architectures.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If hard-programmed where-used listings are used, then metadata consistency can be maintained in static applications, but the system cannot support customized features and varying business processes
Solution Approach 1:
The patent transforms the static hard-programmed where-used listings into a dynamic system that automatically detects and indexes dependencies between data elements at runtime. The dependency detection mechanism continuously updates where-used information as the software solution executes, allowing the system to adapt to customizations while maintaining metadata consistency through automatic tracking rather than fixed programming
Solution Approach 2:
The system implements self-service by automatically detecting dependencies between data elements and populating where-used listings without requiring manual intervention or hard-coding. The dependency detection mechanism autonomously identifies relationships between business objects, data objects, and other software elements, enabling the system to support customizations while maintaining information integrity through self-updating metadata
2Adaptability or versatility
If a customizable software solution is implemented to support varying business processes, then adaptability improves, but maintaining accurate where-used listings becomes complex and inadequate
Solution Approach 1:
The patent replaces the mechanical approach of hard-programming dependency relationships with an automated detection mechanism that uses runtime analysis to identify dependencies between data elements. This substitution of automatic detection for manual configuration simplifies the system's ability to handle complex customizations, as the dependency tracking becomes an automated process rather than a complex manual maintenance task
Solution Approach 2:
The system implements feedback through its dependency detection mechanism, which continuously monitors and identifies relationships between data elements as the software executes. This feedback loop automatically updates where-used listings based on actual runtime behavior, enabling the system to adapt to business process variations without increasing complexity, as the feedback mechanism naturally tracks dependencies regardless of customization level
3Adaptability or versatility
If unindexed data elements are allowed in customizable solutions, then flexibility increases, but where-used listings become incomplete and inaccurate
Solution Approach 1:
The patent applies preliminary action by proactively detecting and indexing unindexed data elements as they are encountered during runtime execution. Rather than requiring all dependencies to be pre-defined, the system preemptively identifies unindexed elements and incorporates them into the where-used listings, maintaining both flexibility for customizations and accuracy in dependency tracking through this proactive approach
Data Source
AI summary
To enable automated updating of a where-used list for data elements in a software solution, an unindexed data element of a plurality of data elements included in the software solution can be detected. The unindexed data element can have a non-current or non-existent where-used listing in the current where-used list. A set of rules that can include a predefined dependency condition defining a unidirectional dependency relationship condition existing between instances of a first type of data structure and a second type of data structure in the software solution can be applied to the unindexed data element. The applying can include identifying the unindexed data element as including the second type of data structure and at least one other data element in the plurality of data elements as including the first type of data structure and therefore having at least one dependency on the unindexed data element. The current where-used list can be updated to create an updated where-used list that includes a listing of the at least one dependency for the unindexed data element.