Sap Se

Sap Ag

Timm Falter

Stefan A Baeuerle

Daniel Hutzel

Alexander Zubev

Vladimir Savchenko

Daniel Buchmann

Volker Wiechers

Vladislav Bezrukov

Martin Huvar

Hans Ruediger Bachmann

Claus Von Riegen

Ralf Dentzer

Joachim Bender

Peter Eberlein

Arne Harren

Martin Hartig

Thomas Kunz

Harish Mehta

Otto Boehrer

Fabian Fellhauer

Lior Schejter

Christian Rabetge

Mike Hirsch

Frank Brunswig

Di Wu

Uwe Schlarb

Ki Hong Kim

Hartwig Seifert

Helmut Prestel

Johannes Viegener

Daniel Zoch

Rene Dehn

Stefan Rossmanith

Georg Wilhelm

Andreas Balzar

Gregor Tielsch

Rolf Hammer

Torsten Ziegler

Kai Baumgarten

Daniel Wachs

Dimitrina Stoyanova

Frank-Martin Haas

Christiane Kettschau

Matthias Becker

Achim Braemer

Igor Schukovets

Simon Heimler

Matthias Buehl

Christian Fuhlbruegge

Karsten Schaser

Erich Schulzke

Nils Hartmann

Michael Schmitt

Zhi Qiao

Steffen Weinstock

Christian Holzer

Cornelia Haase

Roland Lucius

Tobias Melcher

Thomas Henn

Matthias Herchenroether

Kilian Kilger

Thierry Tung

Andreas Gruenhagen

Florian Scheid

Andreas Bader

Bernd Krannich

Voker Wiechers

Vladimir Sachenko

Sindambiwe Eugene

Fee Grauf

Kolja Gross

Boyan Boychev

Victoria Kosten

Marco Haupt

Diego Sebastian Will

Minh-Khanh Do

Florian Stallman

Craig Chaplin

Valdimir Savchenko

Techniques and solutions are described for storing and retrieving metadata for database artefacts. A client request is received that includes a relevancy identifier. The relevancy identifier is useable to determine a subset of metadata that should be provided in response to the request. Metadata, including in metadata objects or database artefacts, can be reviewed to determine whether it is relevant to the request, such as if the metadata is associated with the relevancy identifier. Different requests from the same client can specify different relevancy identifiers, as, for example, a first set of metadata may be relevant to one client process and another set may be relevant to another client process. While some metadata can be specific to a particular client, at least some of the metadata can be accessed by multiple clients, and at least in some cases different clients can specify the same relevancy identifier.

Centralized metadata repository with relevancy identifiers

Techniques and solutions are described for retaining names for metadata elements, such as when metadata is imported, converted to a different format, or used with a system that may have restrictions on naming different than a system on which the metadata is created. Metadata includes a plurality of metadata elements, including a first metadata element associated with a first name. A second name is received for the first metadata element. The second name is assigned to the first metadata element. An association is created between the renamed first metadata element and the first name.

Metadata elements with persistent identifiers

The present disclosure relates to computer-implemented methods, software, and systems for automatic database configuration. One example method includes receiving, at a database associated with a data warehouse application, a request to generate a configuration to acquire data objects based on executing calls to corresponding programming interfaces provided by a source application, wherein the programming interfaces are identified in the received instructions and are associated with acquiring the data objects associated with metadata entities defined at the database; in response to the received instructions, configuring the database to automatically execute one or more calls to acquire relevant data for a metadata entity defined at the database, wherein the metadata entity is associated with a section of a first programming interface; and invoking the first programming interface at the source application, wherein invoking the first programming interface results in acquiring the relevant data.

Automatic configuration of data invocation from one or more sources based on metadata mappings

The present disclosure relates to computer-implemented methods, software, and systems for importing metadata between applications. One example method includes obtaining, at a data warehouse application, metadata for relevant entities in response to a query defined for querying metadata from a metadata source associated with a source application. A service at the source application is queried to identify a set of programming interfaces associated with the relevant entities for acquiring data objects corresponding to the obtained metadata from the source application. Instructions are generated that can be used to configure the database associated with the data warehouse application to acquire a data object based on executing a call to a corresponding programming interface. The generated instructions are provided to the database to configure the database to automatically execute the call to acquire the data object from the source application.

Importing data objects metadata based on application interface to service entity mappings

Methods for using SQL statements to access an application-server-managed database are disclosed herein. In some embodiments, a user sends, either directly or indirectly (i.e., remotely) a SQL statement from an ODBC application or server, respectively, to an application server that preprocesses SQL statements for accessing data from a centralized database. The application server may have a SQL endpoint, and access to the SQL endpoint may be determined by a user's logon credentials, a user's presentation of a SAML token, or a user's presentation of a valid certificate. The application server may then parse the SQL statement and determine the user's authorization to access certain objects in the centralized database based on a SQL handler design-time configuration. A result from the statement may be sent back to the user either directly or indirectly and exposed.

Dedicated SQL services for cross-system SQL access to an application-server-managed database

An enterprise database server may store enterprise information. An application layer server, coupled to the enterprise database server, may use an application programming language (e.g., ABAP) to access the enterprise information. The application layer server may execute a plurality of domain runtimes, each associated with a domain service (e.g., transactional, SQL, analytical, search, etc.). The application layer server may also access, by a first domain runtime, a first data service entity in an infrastructure for data modelling (e.g., CDS) that enables data models to be defined and consumed on the enterprise database server. Similarly, the application layer server may access, by a second domain runtime, a second data service entity in the infrastructure for data modelling. According to some embodiments, the first data service entity includes a first provider contract and the second data service entity includes a second provider contract (different than the first provider contract).

Domain specific provider contracts for core data services

Implementations of the present disclosure include receiving, by a parser, a view source file and an extension source file, the view source file defining a view on data stored in a database, the extension source file defining an extension to the view, parsing, by the parser, the view source file to provide a view abstract syntax tree (AST) and the extension source file to provide an extension AST, providing, by the parser, a merged AST based on the view AST and the extension AST, generating a mixed runtime data object using the merged AST, and providing the mixed runtime data object for consumption by at least one runtime component.

Lightweight extension of core data services

Disclosed herein are system, method, and device embodiments for consuming application-owned database objects via an API schema. An embodiment operates by determining that an application-owned database object is classified as API exposable, creating an API schema for proxy access to database objects that have been identified as API exposable, generating an API object within the API schema based on assigning the database object to the API schema, and providing, via the API schema and independent of the application, access to the API object by a privileged consumer.

Consuming application-owned database objects via SQL

Implementations of the present disclosure include receiving a query, the query including an expression macro (EM), processing the query to provide a raw parse tree, the raw parse tree including an initial node representative of the EM, retrieving metadata corresponding to the EM, the metadata including a definition string, replacing the initial node with a node based on the definition string to provide a consumable parse tree, and executing the query within the database system using the consumable parse tree to provide a query result.

Dynamic query expressions

A system, method, and computer-readable medium, to receive a query specifying a result set of data from at least one database table; determine whether at least one column of the at least one database table is subject to a column-based authorization restriction; modify the query, in an instance it is determined that at least one column of the at least one database table is subject to a column-based authorization restriction, to restrict the result set of data in accordance with the column-based authorization restriction; and execute, in response to the modifying of the query, the modified query.

Column based data access controls

The subject matter disclosed herein provides methods and apparatus, including computer program products, for providing a classification service. The method may receive a request to access a UDDI registry. The classification service may access metadata representing a classification system for the data stored in the UDDI registry. The classification service may provide the data stored in the UDDI registry in a format based on the access metadata. Related apparatus, systems, methods, and articles are also described.

UDDI based classification system

A database language (e.g. SQL) is extended to define a transient field whose value is derived from data stored in a database. The value of the transient field is calculated by the database engine for consumption as needed by the application layer, for example as part of a particular data model. The value of the transient field may not be materialized as a persistent field in the underlying database table, or may be selectively materialized based upon a heuristic or hint. Certain embodiments may implement the transient field as a basic elaboration on standard SQL utilizing an identifier. Some embodiments may implement the transient field as an entity where SQL has been extended to accommodate concepts of a higher-level Entity Relationship Model (ERM). The use of constants and/or floating values (e.g. a current time) in connection with transient fields, is also disclosed.

SQL extended with transient fields for calculation expressions in enhanced data models

Disclosed are techniques employed alone or in combination, to further enhance a database language and improve conciseness and comprehensiveness of query statements in application code. Embodiments may build upon an initial extension of database language to accommodate concepts of entity-relationship models (ERMs). That initial extension may include entities with structured types, and named associations. One technique modifies SQL to allow the SELECT command to specify element path expressions based upon a relationship (e.g. named associations between ERM elements). Another technique modifies SQL to introduce filter expressions suffixed to associations within path expressions, thus improving adherence to the principle of locality within query statements. Yet another technique allows a shorthand to 'factor out' association path prefixes, thereby avoiding lengthy lists of path expressions in order to read several elements from the same nested structure or a same target entity behind a single association. Other techniques simplifying database querying are also disclosed.

SQL enhancements simplifying database querying

Embodiments extend the relational model and query language to recognize features of tables and higher level entity-relationship models (ERMs). Extension language is implemented in the data design language (DDL) to incorporate tables, entities (and views) having custom-defined/semantic structure, rather than being limited to primitive types (e.g. flat tables as in standard SQL). The extension language includes an indication that a query is to include all active elements for each table extension or entity extension that is active. The extension language can be chained to extend a table or entity that has been extended.

Core data services extensibility for entity-relationship models

A technique is described for generating error buffer that includes errors from both a program and event handlers called by the program. A program in an event-driven environment triggers an event. In response to the triggered event, the program calls event handlers related to the event. The event handlers are executed and error messages generated during the execution are stored in a local error buffer. Upon completion of the event handlers, the local error buffers are returned to the program and the program merges the local error buffers with an error buffer associated with the program.

Local buffers for event handlers

Growing community of inventors

Sinsheim, Germany

Timm Falter