Controller Generic Data Lock Management for Legacy Integration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Integrating the locking behavior of legacy applications with new applications is challenging, as the legacy applications' locking mechanisms may not be sufficient for the temporal needs of the new applications, leading to potential data inconsistencies and access issues.

Innovation Solution

A computer-implemented method manages a generic data lock for a data object through a controller that reads a log file to track and update locks, ensuring continuous locking control independent of the legacy application's state, and communicates with the user interface to manage access rights.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If the legacy application's locking mechanism is used, then the locking behavior is simple and straightforward, but the locking duration is insufficient and loses effectiveness after the legacy application terminates

Engineering Contradiction:
Improvelocking mechanism simplicityVSAvoidlocking duration
Core Design Contradiction:
Ease of operationVSDuration of action of stationary object

Solution Approach 1:

A controller is introduced as an intermediary component between the legacy application and the new application. The controller maintains a log file that records lock information from the legacy application and enforces locking behavior in the new application, thereby extending the locking duration beyond the legacy application's execution lifetime while keeping the original simple locking mechanism intact

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The lock information from the legacy application is copied into a log file maintained by the controller. This copy of the lock information persists independently of the legacy application's execution state, allowing the locking behavior to continue effectively even after the legacy application terminates

Inventive Principle:
Principle #26Copying

2Duration of action of stationary object

If a new locking behavior is implemented in the new application, then the locking duration and control are improved, but the system complexity increases due to integrating two different locking mechanisms

Engineering Contradiction:
Improvelocking durationVSAvoidlocking mechanism complexity
Core Design Contradiction:
Duration of action of stationary objectVSDevice complexity

Solution Approach 1:

The controller serves as a mediating layer that translates and coordinates between the legacy application's simple locking mechanism and the new application's requirements for extended locking duration. This intermediary handles the complexity of integrating both mechanisms, presenting a unified locking behavior to the new application without requiring direct implementation of dual locking systems

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The controller implements feedback by continuously monitoring the log file for lock information and using this information to control access in the new application. The log file acts as a feedback mechanism that provides persistent lock state information, allowing the controller to enforce appropriate locking behavior based on the legacy application's original lock decisions

Inventive Principle:
Principle #23Feedback

3Loss of energy

If the legacy application terminates, then the legacy application's memory is freed and resources are released, but the lock information is lost and cannot be accessed by the new application

Engineering Contradiction:
Improvememory resource releaseVSAvoidlock information loss
Core Design Contradiction:
Loss of energyVSLoss of information

Solution Approach 1:

The critical lock information from the legacy application's memory is copied to a persistent log file before the legacy application terminates. This copying ensures that the lock information survives the termination of the legacy application and remains accessible to the controller and new application, while the legacy application's memory resources can be freely released

Inventive Principle:
Principle #26Copying

Data Source

PatentEP2357560B1Method and system for managing by a controller a generic data lock to a data object
Publication Date: 2015.03.04 SAP SE
  • EP2357560B1 patent drawingFigure 1~2
  • EP2357560B1 patent drawingFigure 3
  • EP2357560B1 patent drawingFigure 4

AI summary

The invention relates to computer implemented method of managing by a controller a generic data lock to a data object, the data object being accessible by a service of a second application, the method comprising: - receiving a data input by a current operation of a user interface of a first application, the data input being related to the data object, the data object being related to the service, - reading a log file, the log file comprising a generic data lock associated with the data object, - depending on the generic data lock, calling the service or sending a message to the user interface, - in response to calling the service, receiving an updated data lock associated with the data object from the second application, and - updating the log file with the received updated data lock.