Sap Se

Sap Ag

Nicolai Jordt

Volker Driesen

Steffen Meissner

Martin Mayer

Andrey Engelko

Wieland Hoprich

Levke Bentzien

Peter Schreiber

Dirk Wodtke

Vedran Lerenc

Stephan Klevenz

Matthias Kruse

Martin Hermes

Juergen Specht

Andreas Jahr

Barbara Freund

Oleg Koutyrine

Andre Klahre

Lars-Eric Biewald

Andre Haferkorn

Wolfgang Degenhardt

Markus Gebhard

Configuration setting management is facilitated by setting data in a multisystem environment. A system having a configuration setting, in a multisystem environment having a test system and a production system, may identify the type for the setting based on a type identifier. The system may maintain the setting based on the type. Maintaining the setting may include, for a first type, making a primary location for the setting the production system, where the setting is initialized and editable in the production system. Maintaining the setting may include, for a second type, making the setting independent between the test system and the production system, where the setting is not transferred between the two systems and is editable at each system. Maintaining the setting may include, for a third type, making a primary location for the setting the test system, where the setting is initialized and editable in the test system.

Configuration management in a multisystem environment

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

An upgrade procedure for an application system without downtime is presented. The upgrade procedure includes a mix of a rolling upgrade of application servers, shadow systems, and record and replay mechanisms that employ transformation and locking, for the upgrade of the applications on the application system. Application servers are upgraded one after another. A target version of the system is simultaneously added to the original system and a shadow, or target, system. Data changes are not only carried out in the original system, but are also carried out in the target system, so that a customer realizes no downtime for their data requests to the applications.

Multi-version systems for zero downtime upgrades

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

Techniques for migrating data in a database include identifying an update to one or more data entries of a source table; determining that a status of a trigger associated with the source table indicates to update a logging table, and in response: updating, in a first transaction, (i) the one or more data entries of the source table, and (ii) one or more data entries of the logging table based on the user input, and copying content of the source table to a target table; and determining that the status indicates to update the target table, and in response: updating, in a second transaction, (i) the one or more data entries of the source table and (ii) one or more data entries of the target table based on the user input, and updating the content of the target table based on the one or more data entries of the logging table.

Migrating data in tables in a database

Work items are collected from one or more work item providers for presentation to a workflow participant. A work item provider is typically a workflow management system ('WFMS'), but other providers of work items might exist that generate work items and may or may not have their own local worklist. Multiple independent WFMS's of multiple types might provide work items to a universal worklist ('UWL') service that integrates the work items from all of the providers. Additional integration might be provided between the UWL and work item providers, such as for controlling work item execution with a sub-workflow through an ad-hoc workflow engine. Additional integration provides for custom attributes. Each work item has a type that is used to determine handling for that work item. A universal work list service includes storage for work items, wherein a work item represents a task generated as part of a process flow. An engine supporting the UWL service might track item types for work items and might obtain attribute values for attributes of the work item according to the work item's type.

Universal worklist service and user interface

In a structured workflow system, a configurable workflow engine provides mechanisms for executing and scheduling the work items in a defined way. End users use their discretion and define their own 'local' processes and 'local' rules for processing work items, or deviate from predefined processes. The configurable workflow engine might be installed at a server to organize workflows and business processes where end users can define processing steps for incoming work items by setting up rules and defining workflows as part of a local workflow structure. By defining these rules and workflows, the further processing steps of future incoming work items can be automated. When an administrator directs the workflow engine to move from a current phase to a next phase, the workflow engine deals with the incomplete items by allowing the administrator to carry over work items (or might do it automatically). End-user consultation might be included in the carry-over decisions. The carried over work items are added as parallel activities to the next phase. The workflow engine handles imposing and executing control flow dependencies between tasks, thus providing a smooth transition from totally unstructured work to semi-structured or completely structured work. When the workflow engine encounters semantically correlated work items/tasks, the process engine assumes that these work items/tasks belong to the same process instance.

End user oriented workflow approach including structured processing of ad hoc workflows with a collaborative process engine

A system and method for accessing a document management system in a multi-environment processing system includes receiving a client call command from a web service proxy. The web service proxy, disposed on a client and running in conjunction with a client application. A web service end point, disposed in a web service framework receives the client call command. Through the web service end point and a class module, the client call command is converted for accessing the document management system. Retrieved data is temporarily stored in a memory location. The amount of data transfer allowed in a single data transfer is determined. Then, based on this information, multiple web services call are executed to incrementally transfer the data for the client application.

Data transfer in a multi-environment document management system access

A system and method for accessing a document management system in a multi-environment processing system includes receiving a client call command from a web service proxy. The web service proxy, disposed on a client and running in conjunction with a client application. A web service end point, disposed in a web service framework receives the client call command. In conjunction with a class module, the client call command is translated from the second processing environment that the application is executing within and the first processing environment providing the document management system. Through the web service end point and the class module, the client call command is converted for accessing the document management system.

Growing community of inventors

Bad Langbrücken, Germany

Nicolai Jordt