Sap Se

Sap Ag

Martin Mayer

Volker Driesen

Steffen Meissner

Arne Harren

Juergen Specht

Andrey Engelko

Wieland Hoprich

Ulrich Auer

Nicolai Jordt

Christoph Luettge

Levke Bentzien

Peter Schreiber

Martin Hartig

Heiko Konrad

Thomas Ullrich

Erwin Burkhardt

Matthias Mittelstein

Wulf Kruempelmann

Kerstin Hoeft

Tobias Karpstein

Lars-Eric Biewald

Matthias Jensen

Zoltan Albrecht

Andre Haferkorn

Christian Lutter

Ralph Radermacher

Thomas Saelinger

Stephan Heidel

Juergen Quentel

Dirk Rosenkranz

Implementations of the present disclosure include methods, systems, and computer-readable storage mediums for upgrading applications. Actions include receiving an upgrading request for an original table of an application, generating an upgraded table including a structure matching the original table, setting a session variable to initiate an application upgrade, and adding a set of triggers to the original table to selectively control read operations and write operations for the original table and the upgraded table based on the session variable.

Fencing execution of external tools during software changes

Implementations include a first application server interacting with a first infrastructure table of a first version through a first access schema, providing, during an upgrade, a second application server to execute a portion of the upgrade by interacting with data schema through the first access schema, adjusting a structure of a second infrastructure table to provide an adjusted structure, the structure of the first version and the adjusted structure of the second version, the second infrastructure table including a copy of the first infrastructure table, providing a second access schema of the second version, providing a third application server configured to interact with data schema through the second access schema, and activating, by the third application server using an activator of the second version, objects of the second version, the activator including features that are different than an activator of the first version.

Zero downtime upgrade through delta deployment procedure using target software stack

Implementations include providing, by a deploy tool, clone data components in the first database system, each clone data component being a copy of a data component, defining, by the deploy tool, a source-side green access schema in the first database system, the green access schema providing views to the clone data components, providing, by a replication system and based on statements received from the deploy tool, consumer-side clone data components in the first database system, each consumer-side clone data component being a copy of a respective data component, defining, by a replication system and based on statements received from the deploy tool, a consumer-side green access schema in the first database system, the green access schema providing views to the source-side clone data components, and, during execution of the upgrade, replicating, by a handler of the replication system, data from at least one source-side data component to a consumer-side component.

Zero downtime upgrade of systems with database-side replication

In an example embodiment, a proxy object is delivered to a first schema having a first logical name and stored in the software object database, the proxy object referencing an object in a second schema having a second logical name. Any dependencies from the object in the second schema to the proxy object in the first schema are removed a cycle-free graph of dependencies between objects the software object database is generated. Objects are delivered the software object database using the cycle-free graph. A definition for the proxy object is created including the logical name for the first schema. The proxy object is delivered by replacing, at a time subsequent to the proxy object being delivered to the software object database, the logical name for the first schema stored in the definition with a physical name for the first schema.

Database proxy object delivery infrastructure

In an example embodiment, software objects of a first database type are delivered to a first schema having a first physical name and stored in the software object database. A definition is created for the first schema including a logical name for the first schema. The first schema is activated by replacing, at a time subsequent to the first schema being delivered to the software object database, the logical name for the first schema stored in the definition with a physical name for the first schema.

Database container delivery infrastructure

Methods, systems, and computer-readable storage media for deploying upgrade packages during zero downtime upgrade of production systems include actions of receiving an upgrade package, the upgrade package defining one or more changes to be deployed to a system that has already undergone partial deployment during a zero downtime upgrade, and including one or more objects having respective object types, receiving a deployment configuration, the deployment configuration providing a plurality of lists of object types for respective constraints and, for each list of object types, specifying a deployment option for object types in the respective list of object types, determining a set of object types included in the upgrade package, the set of object types comprising one or more object types, and selectively permitting deployment of the upgrade package to execute the one or more changes based on the set of object types and the plurality of lists of object types.

Zero downtime maintenance in constrained systems

Implementations for data migration in a maintenance procedure executed on a software system include actions of providing a first access schema, through which a first version of an application accesses data in a database system, establishing an API-schema, through which at least one direct consumer accesses data in the database system, the API-schema including one or more proxy objects that are mapped to respective one or more objects of the first access schema based on metadata of the API-schema, the metadata providing a mapping and one or more object definitions, and in response to execution of a maintenance procedure: providing a second access schema, through which a second version of the application accesses data in the database system, switching to the second access schema, and revising the mapping of the API-schema, such that at least one proxy object of the API-schema maps to a respective object of the second access schema.

Management of database API schema

Methods, systems, and computer-readable storage media for data migration in a maintenance procedure executed on a software system include actions of initiating the maintenance procedure, and determining that an instance of a data migration object is included in a list of deployed transport objects, and in response: reading a migration class from the data migration object, determining at least one table of a database that is affected by the maintenance procedure based on one or more methods of a first interface of the migration class, receiving, using a second interface of the migration class, data migration logic including computer-executable instructions to migrate data, and executing the data migration logic to affect the at least one table.

Multi-procedure support in data migration

In order to perform relatively frequent, zero-downtime software updates, a bridge schema corresponding to an original schema of a database system may be generated. Within the bridge schema, a plurality of views corresponding to a plurality of database tables of an application executing on an application server may be generated. A connection from the application to the original schema may be changed to the bridge schema, to thereby continue executing the application using the plurality of views. When a change file defining update changes to at least one original database table of the plurality of database tables is received, content of the at least one original database table may be synchronized with a target table reflecting the update changes. Then, the connection may be changed back to the original database schema to continue executing the software application, using the plurality of database tables and including the target table.

Zero downtime for frequent software updates

In an example embodiment, one or more changes to one or more objects in the software object database are received from a developer. A change list is generated based on the one or more changes. An object definition is exported for every object in the change list from a first schema in the database to a second schema in the software object database. A first object in the second schema is activated by mapping a logical schema name specified in the object definition for the first object to a corresponding physical schema name and creating or altering the first object in the second schema using the physical schema name.

Database object delivery infrastructure

A zero downtime upgrade procedure is initiated that upgrades a first version of software executing on a source system comprising at least one source server to a second version of software executing on a target system comprising at least one target server. The source system initially starts operating in a read-write mode. Thereafter, concurrent with the operation of the source system, operation of the target system is initiated in a read-only mode. Operations of the source system are then ceased by ramping down activities of the source system. Upon cessation of operation of the source system, operation of the target system is initiated in a read-write mode.

Zero downtime software system upgrade

Implementations include actions of initiating a procedure on an application that interacts with a database system having a start schema, through which a first version of the application interacts with tables, providing a bridge schema including table views to each table of the start schema, switching a first version of the application to interact through the bridge schema, creating a shadow field in a table, the shadow field corresponding to a field of the table that is to undergo a change during an upgrade from the first version to a second version, providing a trigger in the start schema, the trigger executing a transformation between the field and the shadow field during the upgrade, modifying the table in the start schema to a target structure to change a parameter of the shadow field or the field of the table, and switching the second version to interact through the start schema.

In an example embodiment, relationships among a plurality of schemas are examined to remove any cyclic dependencies. Then a cycle-free graph of the cyclic dependencies is constructed. A first delivery mechanism is used to deliver software objects of a first database type to a first of the plurality of schemas in a software object database, using the cycle-free graph. A second delivery mechanism is used to deliver software objects of a second database type to a second of the plurality of schemas in the software object database, using the cycle-free graph.

Database object lifecycle management

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

The present disclosure describes methods, systems, and computer program products for providing multi-level user interface theming. One computer-implemented method includes instantiating a shadow system and database schema for a new version software application in a shared database, the shadow system database schema containing aliases pointing to tables instantiated in a production database schema, instantiating a bridge database schema containing aliases pointing to each database table within the production database schema, preparing a bridge sub-system connected to the bridge database schema aliases, replicating database tables within the production database schema, for use by the bridge sub-system and adjusting the original database tables for structure and content consistent with the new version software application, deploying an upgrade sub-system and tools to complete adjustment of structure and content of the original database tables, and connecting an instantiated instance of the new version software application to adjusted database tables.

Growing community of inventors

Heidelberg, Germany

Martin Mayer