Code Management via Transfer Templates for Provider Object Identification

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In a computer system implementing an object-oriented program environment, custom objects and provider objects often provide similar functionality, leading to duplication and increased costs in creation and maintenance, with users and providers being unaware of each other's objects, resulting in inefficiencies.

Innovation Solution

A method is introduced to manage program code by using a transfer template information definition structure that identifies managed code objects, includes provider code attributes, similarity measures, and results attributes, allowing for the association of provider code objects with custom code objects and transferring similarity and results information between systems to inform users of available provider objects.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If custom objects are created to provide specific functionality, then the functionality requirements are met, but creation and maintenance costs increase

Engineering Contradiction:

ImprovefunctionalityVSAvoidcreation and maintenance costs

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The system creates copies of provider objects as custom objects, allowing organizations to replicate proven functionality from external providers without developing from scratch. The transfer instance mechanism enables copying object definitions, attributes, and relationships while maintaining the ability to customize local instances.

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The system merges provider objects with custom objects by establishing associations between them through transfer instances. This allows combining the benefits of external provider functionality with local customization needs, reducing duplicate development while maintaining adaptability.

Inventive Principle:

Principle #5Merging (Combining)

2Ease of manufacture

If provider objects are used instead of custom objects, then creation and maintenance costs are reduced, but users are unaware of available provider objects

Engineering Contradiction:

Improvecreation and maintenance costsVSAvoidawareness of provider objects

Core Design Contradiction:

Ease of manufactureVSLoss of information

Solution Approach 1:

The system implements feedback mechanisms where transfer instances track and report on the usage and availability of provider objects. The system monitors which provider objects are available, which custom objects exist, and provides feedback information to users about substitution opportunities, ensuring awareness without forcing adoption.

Inventive Principle:

Principle #23Feedback

3Adaptability or versatility

If both custom objects and provider objects are maintained separately, then functionality requirements are met, but system complexity increases

Engineering Contradiction:

ImprovefunctionalityVSAvoidsystem complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The transfer instance acts as an intermediary between provider objects and custom objects, managing the associations and substitutions. This intermediary layer handles the complexity of tracking relationships, similarity measures, and substitution eligibility, shielding users from the underlying system complexity while maintaining functionality.

Inventive Principle:

Principle #24Intermediary (Mediator)

4Adaptability or versatility

If custom objects are developed independently, then specific organizational needs are met, but duplication of existing provider functionality occurs

Engineering Contradiction:

Improveorganizational customizationVSAvoidcode duplication

Core Design Contradiction:

Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The system performs preliminary analysis to identify when custom objects duplicate existing provider functionality before full development occurs. By evaluating similarity measures and checking provider object availability in advance, the system prevents unnecessary duplication while still allowing legitimate customization needs to proceed.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS8966442B2Custom code innovation management

Publication Date: 2015.02.24 SAP SE

AI summary

A method to manage program code that runs in a computer system comprising: producing a transfer template information definition structure in a computer readable storage device that includes a provider code attribute a similarity measure attribute and at least one results attribute; producing a transfer instance of the transfer template information definition structure that associates a provider code object identified as corresponding to the respective managed code object with the provider object code attribute and that associates the determined measure of similarity with the similarity measure attribute; using the transfer instance to obtain results information from a provider system that includes information about the provider code object.