Sap Se

Peter Schreiber

Volker Driesen

Martin Mayer

Andrey Engelko

Wieland Hoprich

Steffen Meissner

Nicolai Jordt

Levke Bentzien

Ulrich Auer

Michael Wirtz

Anton Golubev

Peter Datsichin

Mathias Klein

Hans-Juergen Lattrell

Downtime resulting from converting a software program from a source system to a target system, is forecast, explored, and optimized. A benchmark for a practice conversion test run (including a downtime component) is received as a first input and displayed for exploration. A second input is received comprising a statistic stored in a conversion database and reflecting a prior actual software conversion process run. The benchmark and the statistic are processed with reference to an expert rule set, to generate an optimized result comprising an updated benchmark having a changed downtime component. The updated benchmark including the changed downtime component, is displayed. Processing may occur in conjunction with further input comprising an acceptance of a generated recommendation, and/or changing a data volume of the practice conversion test run. Embodiments may feed back to the conversion database, statistics resulting from a formal software conversion run conducted according to the optimized result.

Software conversion downtime prediction tool

Simulated software conversion offers advance warning of possible issues that may arise during a full conversion process. An engine interposed between a planner and an upgrade module interacts with the planner and an upgrade module to simulate compliance checks, and to reference a data model to simulate conversion tasks (e.g., simplification items, add-ons, custom code). The engine instructs the planner to continue (rather than halt/suspend) iterative interrogation of the existing production landscape to create an un-truncated stack.xml file, even when the planner encounters an unknown/unfamiliar software element. The upgrade module expects an incoming modified stack.xml file as input, that modified stack.xml file including additional information (such as a flag) referenced by the upgrade module to perform conversion compliance checks and other conversion tasks. The engine enriches the full stack.xml file received from the planner, creating the modified stack.xml file including additional information sent to the upgrade module.

Software conversion simulation mode

Continuous access to an application and associated data is provided during a modification (for example, an upgrade) of the application. Shared tables are used to perform parallel changes in databases associated with an original database schema, a temporary database schema, and an upgraded database schema. Aliases are used to access shared tables from some database schemas. The use of shared tables obviates a separate merging of data written by different tools and/or systems during an upgrade of the application. Related methods, apparatuses, systems, techniques and articles are also described.

Aliases for accessing shared tables during provision of continuous access during application upgrade

A temporary system is described to provide, during an upgrade of an application implemented using an original system, a continuous access to the application. A copy of a first data-set characterizing a first version of the application is generated on the temporary system when the upgrade becomes available. A selective access to the copy on the temporary system is enabled while preventing access to the first data-set on an original system. The first data-set on the original system is upgraded to form a second data-set characterizing a second version of the application, and a testing of the second data-set is performed. When a result of the testing indicates that the second data-set should be implemented, an access to the second data-set on the original system is enabled while preventing access to the copy on the temporary system. Related methods, apparatus, systems, techniques and articles are also described.

Using temporary system to provide continuous access during application upgrade

The subject matter described herein relates to providing a continuous access to a database at times, including when the database is being modified or upgraded. Initially, access to an old version of a table is enabled and provided to a user. A copy of the old version is generated. Access is asynchronously redirected from the old version to the copy of the old version. A new version of the table is generated by modifying the structure of the first version of the table. The copy of the old version is accessible when the database is being modified or upgraded. When the structure is being modified, access is asynchronously redirected from the copy of the old version to the new version.

Providing continuous database access during database modification

In an embodiment, a method is provided for updating a computer program. In this method, a record related to a data structure being effected in the updating of the computer program is identified. Here, the data structure is accessible by the computer program. Additionally, a request is received during the update of the computer program to access a further record related to the data structure. The further record in the request is identified to match the record effected in the updating of the computer program. The request is thereby prevented from accessing the further record related to the data structure based on the further record matching the record related to the data structure

Growing community of inventors

Wiesloch, Germany

Peter Schreiber