Framework and metadata artefacts for updating data artefacts

Techniques and solutions are described for defining metadata artefacts and, using a framework, which can be referred to as a decorator framework, updating data artefacts. The data artefacts can be artefacts in a virtual data model, such as data artefacts representing views that can correspond to a view, or one or more tables, of a relational database system. A metadata artefact can include semantic elements, such as annotations, that are processable by the decorator framework in updating data artefacts. Annotations can specify an operation type, such as to include, remove, replace, or synchronize, for content a metadata artefact, where the operation will be carried out on data artefacts to which the metadata artefact is applied and which contain specified content. Multiple metadata artefacts can be applied to a given data artefact, and a given metadata artefact can be applied to multiple data artefacts.

FIELD

The present disclosure generally relates to computer-implemented artefacts, such as data artefacts and metadata artefacts. Particular implementations provide a framework that allows data artefacts to be updated using metadata artefacts.

BACKGROUND

Database systems can be very complex, particularly for enterprise resource planning (ERP) systems. A database for an ERP system often includes thousands of tables. Each table can have many fields.

It is common for developers to work indirectly with database tables. While database systems often focus on efficiently storing, retrieving, and modifying information, it can be complicated to interact directly with the database, in part because of technical issues in accessing the database, such as through a query language (e.g., SQL), and in part because database systems typically lack significant semantic information for the relations and attributes included in the database system.

To help address these issues, it is common for developers to create applications that interact indirectly with the database. While the database can include a data dictionary or information schema that stores a data model that includes information about relations in the database, a virtual data model can be used to interface with the database. Artefacts in the virtual data model can specify entities (such as relations or views) from which they may obtain data, and can also specify operations to be carried out using data from a specified entity (e.g., calculations, which in some cases can be pushed down to the database, which may be able to perform the operations more efficiently than at the level of a framework or application outside of the database) and sematic information.

Semantic information can include associations with other virtual data model artefacts, annotations that can be used to drive application functionality without having to specifically program the application to include such functionality, and information that describes components of a particular virtual data model artefact. In particular, annotations can be beneficial, because functionality can be defined in a more human-readable format, rather than requiring programming in a more traditional programming language. Development can be facilitated, as a developer can accomplish many tasks by being familiar with a single notation used for defining the virtual data mode, rather than having to be familiar with the details of multiple applications and possibly multiple programming languages.

Although virtual data models can provide many advantages, they can have some drawbacks. Accordingly, room for improvement exists.

SUMMARY

Techniques and solutions are described for defining metadata artefacts and, using a framework, which can be referred to as a decorator framework, updating data artefacts. The data artefacts can be artefacts in a virtual data model, such as data artefacts representing views that can correspond to a view, or one or more tables, of a relational database system. A metadata artefact can include semantic elements, such as annotations, that are processable by the decorator framework in updating data artefacts. Annotations can specify an operation type, such as to include, remove, replace, or synchronize, for content a metadata artefact, where the operation will be carried out on data artefacts to which the metadata artefact is applied and which contain specified content. Multiple metadata artefacts can be applied to a given data artefact, and a given metadata artefact can be applied to multiple data artefacts.

In one aspect, the present disclosure provides a method for updating one or more data artefacts using one or more metadata artefacts. A command is received by a metadata decorator framework to update one or more data artefacts with one or more metadata artefacts. A given metadata artefact of the one or more metadata artefacts includes one or more syntax elements processable by the metadata decorator framework. The one or more data artefacts are retrieved. The one or more metadata artefacts are retrieved. The one or more data artefacts are updated according to one or more metadata indicators specified by the one or more metadata artefacts to provide one or more updated data artefacts. A metadata indicator includes at least a portion of the one or more syntax elements. The one or more updated data artefacts are stored.

The present disclosure also includes computing systems and tangible, non-transitory computer readable storage media configured to carry out, or including instructions for carrying out, an above-described method (or operations). As described herein, a variety of other features and advantages can be incorporated into the technologies as desired.

DETAILED DESCRIPTION

Database systems can be very complex, particularly for enterprise resource planning (ERP) systems. A database for an ERP system often includes thousands of tables. Each table can have many fields.

It is common for developers to work indirectly with database tables. While database systems often focus on efficiently storing, retrieving, and modifying information, it can be complicated to interact directly with the database, in part because of technical issues in accessing the database, such as through a query language (e.g., SQL), and in part because database systems typically lack significant semantic information for the relations and attributes included in the database system.

To help address these issues, it is common for developers to create applications that interact indirectly with the database. While the database can include a data dictionary or information schema that stores a data model that includes information about relations in the database, a virtual data model can be used to interface with the database. Artefacts in the virtual data model can specify entities (such as relations or views) from which they may obtain data, and can also specify operations to be carried out using data from a specified entity (e.g., calculations, which in some cases can be pushed down to the database, which may be able to perform the operations more efficiently than at the level of a framework or application outside of the database) and sematic information.

Semantic information can include associations with other virtual data model artefacts, annotations that can be used to drive application functionality without having to specifically program the application to include such functionality, and information that describes components of a particular virtual data model artefact. In particular, annotations can be beneficial, because functionality can be defined in a more human-readable format, rather than requiring programming in a more traditional programming language. Development can be facilitated, as a developer can accomplish many tasks by being familiar with a single notation used for defining the virtual data model, rather than having to be familiar with the details of multiple applications and possibly multiple programming languages.

Although virtual data models can provide many advantages, they can have some drawbacks. For example, an element of a data dictionary, which can correspond to a semantically enriched representation of a database field, may be used in many different artefacts of a virtual data model. If a representation of the element, or metadata describing the element, such as how it can be used, changes, it can be challenging to ensure that all artefacts that use that element are correspondingly updated. Similarly, artefacts of a virtual data model can be reused in multiple other data artefacts. It may be desirable to harmonize the various uses of a given data artefact, but, as with elements, it can be difficult to accomplish this in practice. Accordingly, room for improvement exists.

The present disclosure provides techniques for defining artefacts of a virtual data model that can be used to modify other artefacts in the virtual data model. For example, a virtual data model artefact can be defined to include particular types of components, such as metadata, where the metadata can describe another component of the artefact or define how the artefact or component should be used or processed. This virtual data model artefact can then be used to modify other virtual data model artefacts, such as to add, remove, or modify components in such other artefacts.

The disclosed technologies thus provide for metadata decoration of objects in a virtual data model. In a particular implementation, disclosed technologies can be applied to software available from SAP SE, of Walldorf, Germany SAP provides a virtual data model implemented by CDS (Core Data Services). Data artefacts in CDS can be written in Core Schema Notation (CSN), which is similar to a JavaScript Object Notation (JSON) schema. For ease of presentation, disclosed technologies are sometimes described in the specific embodiment of CDS technologies. However, it should be appreciated that the disclosed techniques can be used with other types of virtual data models, and can be used with schemas that are not part of a virtual data model.

In a particular implementation, data artefacts called CMD (CDS metadata decorator) artefacts can be used to modify other artefacts of the virtual data model, such as CDS views. A metadata decorator framework can implement operations for creating, modifying, and using CMD artefacts, including applying CMD artefacts to other CDS artefacts. More generally, CMD artefacts can be referred to as metadata decorator artefacts, and CDS artefacts can be referred to as data artefacts, which can be virtual data model (VDM) artefacts. As will be explained, CDS views can also be modified (e.g., using a metadata indicator, such as an annotation, that is to be read by the metadata decorator framework) so they can act as CMD artefacts.

Example 2—Example Computing Environment Having Decorator Framework

FIG. 1illustrates an example computing environment100in which disclosed technologies can be implemented. At a high level, the computing environment100includes a database system104that can communicate with an application or framework layer108. The database system104includes data that can be used by the application/framework layer108, or applications that communicates with the application/framework layer. The data can be stored in one or more tables112of the database108. The data can be referenced by one or more views116, which can be view definitions or materialized views (which can then also correspond to tables112). A data dictionary120can store information regarding the tables112and the views116.

The application/framework layer108includes a virtual data model130. The virtual data model130can include entities134and views138, which can at least generally correspond to the tables112and the views116of the database108. However, as will be described, as compared with the tables112and views116, artefacts in the virtual data model130are typically associated with additional information, such as semantic information or information that can be used to manipulate data in one or more artefacts of the database108that corresponds to a given artefact in the virtual data model. The virtual data model130can include information regarding elements142, which can correspond to attributes or fields used in the entities134and views138. At least some of the elements142can correspond to fields used in the database104, but are enriched with additional information. Information regarding the entities134, views138, and elements142can be stored in a data dictionary146of the virtual data model130.

The application/framework108includes a decorator framework150that can be used to implement disclosed technologies. A particular example of components that can be included in the decorator framework150is provided inFIG. 21. Generally, the decorator framework150can be used to create and manage metadata artefacts, including applying metadata artefacts to data artefacts.

Generally, as used in the present disclosure, a data artefact refers to an artefact in the virtual data model130that is intended for direct use by a user or application. A data artefact can include data elements, including those that refer to data stored in the database104. However, a data artefact can also include metadata elements, which can describe data elements, or how the data artefact can be used or how it may be processed. Data elements and metadata elements can be collectively referred to as components of an artefact.

A metadata artefact refers to an artefact in the virtual data model130that is intended to be used to modify other artefacts using the decorator framework150. In some cases, a title or other identifier can be used to distinguish metadata artefacts and data artefacts. In addition, or alternatively, data artefacts which can be used as metadata artefacts contain tokens or syntax or semantic elements that indicate, such as to the decorator framework, that the artefact is a metadata artefact. Similarly, actions that are to be taken by a decorator framework can be associated with particular tokens or syntax elements in a data artefact or a metadata artefact indicating that the tokens or syntax elements, or related content (e.g., content following the tokens or syntax elements that act as a flag to the decorator framework), are to be processed by the decorator framework. Generally, these tokens or syntax elements can be referred to as metadata indicators. The present disclosure generally describes disclosed technologies as being implemented using metadata indicators in the form of annotations, however, other types of metadata indicators can be used in an analogous manner. In disclosed examples, annotations intended for use by the decorator framework150can be prefaced by “@MetadataDecorator”. Syntax elements, such as brackets, braces, or parentheses, can be used to indicate a beginning and end of an annotation for the decorator framework150.

So, some data artefacts can also be metadata artefacts, but not all data artefacts are metadata artefacts. All metadata artefacts are useable, at least in appropriate circumstances, to modify other artefacts. While the term artefact is generally used in the present disclosure, the terms “object” or “model” can also be used in place of artefact (e.g., metadata models or metadata objects).

Example 3—Example Table Elements Including Semantic Identifiers

Database systems typically include an information repository that stores information regarding a database schema. For instance, PostgreSQL includes an INFORMATION_SCHEMA that includes information regarding tables in a database system, and certain table components, such as attributes (or fields) and their associated datatypes (e.g., varchar, int, float). Other database systems, or query languages, include similar concepts. However, as described above, these types of repositories typically only store technical information regarding database components, not semantic information.

Other database systems, or applications or frameworks that operate using a database layer, may include repositories that store semantic information for data. For instance, SAP SE of Walldorf, Germany, provides the ABAP programming language which can be used in conjunction with database systems. ABAP provides the ability to develop database applications that are agnostic to the nature, including vendor, of the underlying relational database management system. In part, this ability is enabled using a data dictionary. The data dictionary can include at least some information that is similar to information that is maintained in an information schema. However, the data dictionary can include semantic information regarding data, and optionally additional technical information.

In addition, the data dictionary can include textual information regarding fields in a table, such as human-readable descriptions (sometimes in different languages, such as English, French, or German) of the purpose or use of the field. In at least some cases, the textual information can serve as semantic information to a computer. However, other types of semantic information need not necessarily be (at least easily) human-understandable, but can be easier for a computer to process than parsing textual information primary intended for human use. Data dictionaries can also contain or express relations between data dictionary objects through various properties (which can be reflected in metadata), such as having the data dictionary reflect that dictionary objects are assigned to packages, and thus having a relationship to one another through a package assignment.

As used herein, “technical information” (or technical metadata) relates to information that describes data as data, which is information such as a type that can be used to interpret a value of the data, and which can influence how the data is processed. For instance, the value “6453” could be interpreted (or cast) as an integer, a float, a string, or an array of characters, among various possibilities. A value may be processed differently, in some cases, depending on whether it is a number, such as an integer or a float, or whether it is treated as a collection of characters. Similarly, technical information can specify acceptable values for data, such as a length or a number of decimal places that are allowed. The technical information can specify properties of the data without concern regarding what the data represents or “means.” Of course, however, a designer of a database system can select particular technical properties for particular data knowing themselves the semantic properties of the data—e.g., “If I intend to have a value representing a person's name, I should use a string or array of characters rather than a float.” On the other hand, in at least some cases, data types might be a type that would not be expected by a database administrator or user. For instance, rather than using a person's name to identify data associated with the person, a separate numerical or alphanumerical identifier might be used, which might be counter intuitive based on the “meaning” of the data (e.g., “I do not consider myself to be a number”).

As used herein, “semantic information” (or semantic metadata) relates to information that describes the meaning or purpose of data, which meaning or purpose can be to a human or to a computer process. As an example, technical data information may specify that data is obtained having a value in the format “XXX-XX-XXXX,” where X is an integer between 0 and 9. That technical information can be used to determine how the data should be processed, or whether a particular value is valid (e.g., “111-11-1111” is, but “1111-11-1111” is not), but does not indicate what the value represents. Semantic information associated with the data can indicate whether the value is a social security number, a telephone number, a routing address, etc.

Semantic information can also describe how data is to be processed or displayed. For instance, “knowing” that data is a telephone number may cause the value to be displayed in one part of a GUI as opposed to another part of a GUI, or may invoke or not invoke particular processing rules depending on if the rule is active for “telephone number.” In at least some cases, “semantic information” can include other types of information that can be used to describe data, or how it should be used or processed. In a particular case, data can be associated with one or more of a label, such as a human understandable description of the data (e.g., “telephone number”), documentation, such as a description of what information should be included in a field having the label (e.g., “enter an 11 digit phone number including area code”), or information that can be used in a help screen (e.g., “enter your home phone number here”).

Typically, technical information must be provided for data. In the case of a field of a database table, for example, it is typically necessary to provide a name or identifier for a field and a datatype. The name or identifier for a field might, or might not, serve to provide semantic information. That is, a database designer might choose a name of “Employee_Name,” “EMPN,” or “3152.” However, as the name or identifier is used to locate/differentiate the field from another field, in the context of the present disclosure, it is considered to be technical information, rather than semantic information, even if it may readily convey meaning to a human. In at least some implementations, the use of semantic information is optional. For instance, even using the data dictionary, some fields used in database objects (such as tables, but potentially other objects too, where such other objects are typically associated with one or more tables in an underlying relational database system) can be specified without the use of semantic information, while other fields are associated with semantic information.

FIG. 2is an example entity-relation (ER) type diagram illustrating a data schema200, or metadata model, related to a driver's accident history. The schema200(which can be part of a larger schema, the other components not being shown inFIG. 2) can include a table208associated with a license holder (e.g., an individual having a driver's license), a table212associated with a license, a table216representing an accident history, and a table204representing cars (or other vehicles).

Each of the tables204,208,212,216has a plurality of attributes220(although, a table may only have one attribute in some circumstances). For a particular table204,208,212,216, one or more of the attributes220can serve as a primary key—uniquely identifying particular records in the tuple and being designated as the main method of accessing tuples in the table. For example, in the table204, the Car_Serial_No attribute220aserves as the primary key. In the table216, the combination of attributes220band220ctogether serve as the primary key.

A table can reference records associated with the primary key of another table through the use of a foreign key. For example, the license number table216has an attribute220dfor a Car_Serial_No in table216that is a foreign key and is associated with the corresponding attribute220aof table204. The use of a foreign key can serve various purposes. The foreign key can link particular tuples in different tables. For example, a foreign key value of 8888 for the attribute220dwould be associated with a particular tuple in table204having that value for attribute220a. Foreign keys can also act as constraints, where a record cannot be created having (or altered to have) a foreign key value that does not exist as a primary key value in the referenced table. Foreign keys can also be used to maintain database consistency, where a change to a primary key value can be propagated to a table where the attribute is a foreign key.

A table can have other attributes, or combinations of attributes, that can serve to uniquely identify tuples, but which are not primary keys. Table216, for instance, has an alternate key that is formed from attribute220cand attribute220d. Thus, a unique tuple can be accessed in the table216using either the primary key (e.g., being a foreign key in another table) or through an association to the alternate key.

Schema information is typically maintained in a database layer, such as a software layer associated with where table values are maintained (e.g., in a RDBMS), and typically includes identifiers for the tables204,208,212,216, and the name226and datatype228of their associated attributes220. Schema information may also include at least some of the information conveyable using the flag230, such as whether a field is associated with a primary key, or indicating a foreign key relationship. However, other relationships, including more informal associations, may not be included in a schema associated with a database layer (e.g., the INFORMATION_SCHEMA of PostgreSQL).

Example 4—Example Table Elements Including Semantic Identifiers

FIG. 3is a diagram illustrating elements of a database schema300and how they can be interrelated. In at least some cases, the database schema300can be maintained other than at the database layer of a database system. That is, for example, the database schema300can be independent of the underlying database, including a schema used for the underlying database. Typically, the database schema300is mapped to a schema of the database layer (e.g., schema200ofFIG. 2), such that records, or portions thereof (e.g., particular values of particular fields) can be retrieved through the database schema300.

The database schema300can include one or more packages310. A package310can represent an organizational component used to categorize or classify other elements of the schema300. For example, the package310can be replicated or deployed to various database systems. The package310can also be used to enforce security restrictions, such as by restricting access of particular users or particular applications to particular schema elements.

A package310can be associated with one or more domains314(i.e., a particular type of semantic identifier or semantic information). In turn, a domain314can be associated with one or more packages310. For instance, domain1,314a, is associated only with package310a, while domain2,314b, is associated with package310aand package310b. In at least some cases, a domain314can specify which packages310may use the domain. For instance, it may be that a domain314associated with materials used in a manufacturing process can be used by a process-control application, but not by a human resources application.

In at least some implementations, although multiple packages310can access a domain314(and database objects that incorporate the domain), a domain (and optionally other database objects, such as tables318, data elements322, and fields326, described in more detail below) is primarily assigned to one package. Assigning a domain314, and other database objects, to a unique package can help create logical (or semantic) relationships between database objects. InFIG. 3, an assignment of a domain314to a package310is shown as a solid line, while an access permission is shown as a dashed line. So, domain314ais assigned to package310a, and domain314bis assigned to package310b. Package310acan access domain314b, but package310bcannot access domain314a.

Note that at least certain database objects, such as tables318, can include database objects that are associated with multiple packages. For example, a table318, Table 1, may be assigned to package A, and have fields that are assigned to package A, package B, and package C. The use of fields assigned to packages A, B, and C in Table 1 creates a semantic relationship between package A and packages B and C, which semantic relationship can be further explained if the fields are associated with particular domains314(that is, the domains can provide further semantic context for database objects that are associated with an object of another package, rather than being assigned to a common package).

As will be explained in more detail, a domain314can represent the most granular unit from which database tables318or other schema elements or objects can be constructed. For instance, a domain314may at least be associated with a datatype. Each domain314is associated with a unique name or identifier, and is typically associated with a description, such as a human readable textual description (or an identifier than can be correlated with a human readable textual description) providing the semantic meaning of the domain. For instance, one domain314can be an integer value representing a phone number, while another domain can be an integer value representing a part number, while yet another integer domain may represent a social security number. The domain314thus can help provide common and consistent use (e.g., semantic meaning) across the schema300. That is, for example, whenever a domain representing a social security number is used, the corresponding fields can be recognized as having this meaning even if the fields or data elements have different identifiers or other characteristics for different tables.

The schema300can include one or more data elements322. Each data element322is typically associated with a single domain314. However, multiple data elements322can be associated with a particular domain314. Although not shown, multiple elements of a table318can be associated with the same data element322, or can be associated with different data elements having the same domain314. Data elements322can serve, among other things, to allow a domain314to be customized for a particular table318. Thus, the data elements322can provide additional semantic information for an element of a table318.

Tables318include one or more fields326, at least a portion of which are mapped to data elements322. The fields326can be mapped to a schema of a database layer, or the tables318can be mapped to a database layer in another manner. In any case, in some embodiments, the fields326are mapped to a database layer in some manner Or, a database schema can include semantic information equivalent to elements of the schema300, including the domains314.

In some embodiments, one or more of the fields326are not mapped to a domain314. For example, the fields326can be associated with primitive data components (e.g., primitive datatypes, such as integers, strings, Boolean values, character arrays, etc.), where the primitive data components do not include semantic information. Or, a database system can include one or more tables318that do not include any fields326that are associated with a domain314. However, the disclosed technologies can include a schema300(which can be separate from, or incorporated into, a database schema) that includes a plurality of tables318having at least one field326that is associated with a domain314, directly or through a data element322.

Example 5—Example Data Dictionary Components

Schema information, such as information associated with the schema200ofFIG. 2or the schema300ofFIG. 3, can be stored in a repository, such as a data dictionary. In at least some cases the data dictionary is independent of, but mapped to, an underlying relational database. Such independence can allow the same database schema200,300to be mapped to different underlying databases (e.g., databases using software from different vendors, or different software versions or products from the same vendor). The data dictionary can be persisted, such as being maintained in stored tables, and can be maintained in memory, either in whole or part. An in-memory version of a data dictionary can be referred to as a dictionary buffer.

FIG. 4illustrates a database environment400having a data dictionary404that can access, such as through a mapping, a database layer408. The database layer408can include a schema412(e.g., an INFORMATION_SCHEMA as in PostgreSQL) and data416, such as data associated with tables418. The schema412includes various technical data items/components422, which can be associated with a field420, such as a field name422a(which may or may not correspond to a readily human-understandable description of the purpose of the field, or otherwise explicitly describe the semantic meaning of values for that field), a field data type422b(e.g., integer, varchar, string, Boolean), a length422c(e.g., the size of a number, the length of a string, etc., allowed for values in the field), a number of decimal places422d(optionally, for suitable datatypes, such as, for a float with length6, specifying whether the values represent XX.XXXX or XXX.XXX), a position422e(e.g., a position in the table where the field should be displayed, such as being the first displayed field, the second displayed field, etc.), optionally, a default value422f(e.g., “NULL,” “0,” or some other value), a NULL flag422gindicating whether NULL values are allowed for the field, a primary key flag422hindicating whether the field is, or is used in, a primary key for the table, and a foreign key element422i, which can indicate whether the field420is associated with a primary key of another table, and, optionally, an identifier of the table/field referenced by the foreign key element. A particular schema412can include more, fewer, or different technical data items422than shown inFIG. 4.

The tables418are associated with one or more values426. The values426are typically associated with a field420defined using one or more of the technical data elements422. That is, each row428typically represents a unique tuple or record, and each column430is typically associated with a definition of a particular field420. A table418typically is defined as a collection of the fields420, and is given a unique identifier.

The data dictionary404includes one or more packages434, one or more domains438, one or more data elements442, and one or more tables446, which can at least generally correspond to the similarly titled components310,314,322,318, respectively, ofFIG. 3. As explained in the discussion ofFIG. 3, a package434includes one or more (typically a plurality) of domains438. Each domain438is defined by a plurality of domain elements440. The domain elements440can include one or more names440a. The names440aserve to identify, in some cases uniquely, a particular domain438. A domain438includes at least one unique name440a, and may include one or more names that may or may not be unique. Names which may or may not be unique can include versions of a name, or a description, of the domain438at various lengths or levels of detail. For instance, names440acan include text that can be used as a label for the domain438, and can include short, medium, and long versions, as well as text that can be specified as a heading. Or, the names440acan include a primary name or identifier and a short description or field label that provides human understandable semantics for the domain438.

In at least some cases, the data dictionary404can store at least a portion of the names440ain multiple languages, such as having domain labels available for multiple languages. In embodiments of the disclosed technologies, when domain information is used for identifying relationships between tables or other database elements or objects, including searching for particular values, information, such as names440a, in multiple languages can be searched. For instance, if “customer” is specified, the German and French portion of the names440acan be searched as well as an English version.

The domain elements440can also include information that is at least similar to information that can be included in the schema412. For example, the domain elements440can include a data type440b, a length440c, and a number of decimal places440dassociated with relevant data types, which can correspond to the technical data elements422b,422c,422d, respectively. The domain elements440can include conversion information440e. The conversion information440ecan be used to convert (or interconvert) values entered for the domain438(including, optionally, as modified by a data element442). For instance, conversion information440ecan specify that a number having the form XXXXXXXXX should be converted to XXX-XX-XXXX, or that a number should have decimals or comma separating various groups of numbers (e.g., formatting 1234567 as 1,234,567.00). In some cases, field conversion information for multiple domains438can be stored in a repository, such as a field catalog.

The domain elements440can include one or more value restrictions440f. A value restriction440fcan specify, for example, that negative values are or are not allowed, or particular ranges or threshold of values that are acceptable for a domain438. In some cases, an error message or similar indication can be provided as a value is attempted to be used with a domain438that does not comply with a value restriction440f. A domain element440gcan specify one or more packages434that are allowed to use the domain438.

A domain element440hcan specify metadata that records creation or modification events associated with a domain element438. For instance, the domain element440hcan record the identity of a user or application that last modified the domain element440h, and a time that the modification occurred. In some cases, the domain element440hstores a larger history, including a complete history, of creation and modification of a domain438.

A domain element440ican specify an original language associated with a domain438, including the names440a. The domain element440ican be useful, for example, when it is to be determined whether the names440ashould be converted to another language, or how such conversion should be accomplished.

Data elements442can include data element fields444, at least some of which can be at least generally similar to domain elements440. For example, a data element field444acan correspond to at least a portion of the name domain element440a, such as being (or including) a unique identifier of a particular data element442. The field label information described with respect to the name domain element440ais shown as separated into a short description label444b, a medium description label444c, a long description label444d, and a header description444e. As described for the name domain element440a, the labels and header444b-444ecan be maintained in one language or in multiple languages.

A data element field444fcan specify a domain438that is used with the data element442, thus incorporating the features of the domain elements440into the data element. Data element field444gcan represent a default value for the data element442, and can be at least analogous to the default value422fof the schema412. A created/modified data element field444hcan be at least generally similar to the domain element440h.

Tables446can include one or more table elements448. At least a portion of the table elements448can be at least similar to domain elements440, such as table element448abeing at least generally similar to domain element440a, or data element field444a. A description table element448bcan be analogous to the description and header labels described in conjunction with the domain element440a, or the labels and header data element fields444b-444e. A table446can be associated with a type using table element448c. Example table types include transparent tables, cluster tables, and pooled tables, such as used as in database products available from SAP SE of Walldorf, Germany.

Tables446can include one or more field table elements448d. A field table element448dcan define a particular field of a particular database table. Each field table element448dcan include an identifier450aof a particular data element442used for the field. Identifiers450b-450d, can specify whether the field is, or is part of, a primary key for the table (identifier450b), or has a relationship with one or more fields of another database table, such as being a foreign key (identifier450c) or an association (identifier450d).

A created/modified table element448ecan be at least generally similar to the domain element440h.

Example 6—Example Metadata Model

FIG. 5illustrates a definition of a metadata model500. The metadata model500, in particular, represents a view, such as a Core Data Services view of SAP SE, of Walldorf, Germany. The metadata model500can include a variety of different components, at least some of which can be considered to be metadata models. That is, the metadata model500can be a model that is based at least in part on multiple sub-models. The sub-models can specify particular aspects of the overall metadata model500.

The metadata model500can optionally include one or more annotations504. An annotation can be a metadata component that can be added to a metadata model. For example, a provider may supply a base model, and individual users or customers may wish to add metadata that is specific to their operating environment and use cases. The ability to add annotations can thus enhance usability by allowing for custom metadata elements, without impacting other users of a base metadata model. Annotations can be specified for different software layers or frameworks.

In the example shown, annotations504can be indicated as annotations using particular syntax elements, such as by preceding an annotation with the “@” symbol. In at least some cases, annotations504can also be indicated by placing them in the appropriate portion of a metadata model, such as in a header section or another section designated for annotations. In some cases, annotations504can reference other metadata models, such as a metadata model of a data source, or can reference a data source that is associated with a metadata model. In either event, such an association504can create a dependency between the metadata model500and the other metadata model/data source.

The metadata model500can include instructions508, in this case a SQL statement510, defining a core metadata model/object having an identifier512(which can be used, for example to later access or activate, such as to instantiate, the metadata model). In particular, the instructions508shown define a view. The annotations504further specify properties of the view, as do other portions of the metadata model500that will be further described.

The instructions508can specify one or more data sources516. Data sources516can define data to which at least a portion of the metadata of the metadata model500will apply, and can also supply additional metadata for the metadata model500. Note that the metadata model500can be, in at least a sense, dependent on referenced data sources516. For example, if the metadata model500relies on particular expected data or metadata of a data source516, the metadata model may be unusable, have performance issues, or provide incorrect results if the referenced data sources do not include expected data or metadata, or are otherwise inconsistent with how the data source is used in the metadata model. As shown, the data sources516includes two tables, “vbak” and “vbkd.” These tables will typically include metadata features such as one or more fields, where each field is associated with a data type, designations of a primary key, and optionally associations with other database components, such as association or foreign key relationships with other database tables.

The metadata model500can optionally include specifications of one or more associations520. An association520can define a relationship to another entity. An association520can be processed during the use of the metadata model500, such as being converted to a SQL expression such as a JOIN. Unlike other conditions or elements that are included in the metadata model500, associations can define a relationship that can at least in some cases be optional, such as being selectively activated depending upon how the metadata model is accessed. For example, an association520can be converted to a JOIN condition that uses a table provided in a SELECT statement that references the metadata model500.

The metadata model500can include one or more components522that specify how data retrieved using the metadata model should be processed, including to generate values that are associated with other metadata elements of the metadata model. Processing can include calculating values, such as using a formula specified in, or referenced by, the metadata model500. In particular, a processing component522can specify that a particular field value should be treated as an element524, where an element can be as described in Examples 4 and 5. Thus, the metadata model500can include dependencies on how elements are defined, and the metadata model500may not be accurate, or useable, if the element definition does not match how it is used, and intended to be used, in the metadata model500.

The metadata model500can optionally include additional components, such as one or more conditions528, or other operations, such as aggregations, unions, etc., including such operations that are typically supported by a database query language. In addition to instantiated artefacts, information about the artefacts can be stored in a persistency model, such as one or more database tables. An example persistency model that can be used with artefacts is disclosed in U.S. patent application Ser. No. 16/387,983, filed Apr. 18, 2019, and incorporated by reference herein.

Example 7—Example Metadata Model, Including Relationships with Other Metadata Models

FIG. 6illustrates how metadata models may have dependencies on other metadata models. In particular,FIG. 6shows a view metadata model604, which can be the metadata model500ofFIG. 5.FIG. 6also illustrates a metadata model608for an access control object (such as a DCLS, or data control language source), a metadata model612for a metadata extension object (such as a DDLX, or metadata extension), and a metadata model616for an extension element object (such as a DDLS, or data definition language source).

The access control object metadata model608can be used for restricting access to data that can be retrieved using the view metadata model604. For example, the view metadata model604and the access control object metadata model608can be processed together when the view metadata model604is activated, such as to generate SQL commands that retrieve data for the view metadata model, but which are filtered or restricted based on the access control object metadata model. As the access control object metadata model608references the view metadata model604, the access control object metadata model depends on the view existing, and on the view containing elements specified in the access control object metadata model. For example, the access control object metadata model references the “SalesOrderType” element of the view “I_SampleSalesOrder” and the authorization object “V_VBAK_AAT” with its authorization field “AUART”. Thus, the first element would be undefined or unusable if the corresponding element did not exist in the view metadata model604.

The metadata extension object metadata model612(which adds annotations to the view metadata model604) has similar dependencies on the view metadata model, as does the extension element object metadata model616(which adds additional elements to the view metadata model).

Example 8—Example Metadata Artefact Components

FIG. 7summarizes annotations that can be included in a metadata artefact700(including a data artefact which includes annotations for a metadata decorator framework such that it also can serve as a metadata artefact). An annotation704can indicate a scope for a metadata artefact, which can indicate a type of data artefact to which it can be applied. A scope can be, in some cases, an element (e.g., a field definition), a parameter (e.g., an input that is expected when a data artefact is used or called), or an entity type (for example, a view). In some cases, the annotation704can be omitted, and a type can be inferred from other aspects of the metadata artefact700, such as if the metadata artefact includes a data selection clause or other definitional statement.

An annotation706can indicate how or whether a metadata artefact can be used or changed, such as with respect to a compatibility contract. Values for the annotation706can specify whether the metadata artefact is available for use for a given compatibility contract, whether particular annotations may or may not be changed, and whether any changes to annotations are limited to particular values.

Annotations to be applied to specific components of a data artefact are typically associated with a scope, such as an entity, role (e.g., a data artefact in the form of an authorization object defining access controls, such as implemented in products available from SAP SE, of Walldorf, Germany), parameter, element, association, or annotation. This scope can be indicated by annotations714for various sub-annotations (or annotation types) of a metadata annotation710.

A sub-annotation718can be used to indicate that a given metadata artefact includes other metadata artefacts, such as described in Example 17. In some cases, names for data elements used in a metadata artefact can be mapped to names, or aliases, used in data artefacts to which the metadata artefact will be applied, or to metadata artefacts that may be incorporated by, or may incorporate, the metadata artefact. A mapping between a local name and alias can be specified in name.map annotation722.

For metadata artefact annotations that are used to modify other artefacts, an option element726of an annotation can be used to indicate how a given component of the metadata artefact700should be applied to another artefact, such as whether the associated content should be added to the artefact, removed from the artefact, used to replace content in the artefact, or to synchronize the artefact. These operations will be explained in further detail in Examples 9-17.

When an operation is a replacement operation, a definition of components to be replaced can be included in a replacement definition element730of an annotation. In particular examples, definitions can be specified on the level of strings, annotations, data types, or elements.

A used model sub-annotation734can be added to artefacts modified by a given metadata artefact700. The sub-annotation734can be useful when it is desired to track or identify relationships between artefacts, including to ensure that artefacts that are derived (or use) a given metadata artefact700are updated when the given metadata artefact is updated.

Example 9—Example Addition of Annotations to Data Artefacts

FIG. 8Aillustrates how a metadata decorator artefact808may be applied to a data artefact812to add a metadata element816to the data artefact. Line820of the metadata decorator artefact808indicates that it has a type of “view,” and therefore would be applied to other views. That is, at least in some cases, metadata decorator artefacts have a scope, which can be a particular type of data artefact, and therefore are to be applied to data artefacts having the same scope.

The metadata artefact808is also assigned a name or identifier824that serves to uniquely identify the metadata artefact808in a given virtual data model. In some cases, a metadata artefact is implemented using the same or similar syntax as a data artefact. In this case, it may be necessary for the metadata data artefact808to comply with any rules/syntax requirements that are required for data artefacts. For instance, the metadata artefact808includes a select statement at line828. However, the select statement828can reference a table that does not exist, or that exists but does not include any data. The implementation of a metadata artefact can thus change depending on a given operating environment. If a given environment does not require particular elements, such as the select statement828, such elements can be omitted from the metadata artefact.

The metadata artefact808includes an annotation832that can indicate, such as to a processing framework (e.g., a metadata decorator framework), how the metadata artefact808(or at least content associated with the annotation832) should be processed. For example, line836indicates a scope for the annotation832, which can be a specific type of metadata associated with the annotation (in this case, it applies to metadata elements having the type of “annotation”). Line838indicates that annotation816should be added to data artefacts to which the metadata artefact808is applied. The annotation816in this case adds an annotation indicating that the Trans actionCurrency field of the data element is a currency code.

Note that the metadata artefact808includes a cast statement at line844. In this case, the cast statement844is not applied to a target data artefact. A further example will describe how the cast statement844can be specified to be applied to a target data artefact. The cast statement844does, however, indicate the field (TransactionCurrency) to which the annotation816should be applied.

FIG. 8Aalso provides code for the data artefact812, which is a particular data artefact to which the metadata artefact808can be applied. Note that the data artefact812includes a line854that indicates that the data artefact is a view, which is the same type of artefact as the metadata artefact808. The data artefact812includes a line856that incorporates the TransactionCurrency field into the data artefact. Note that the data artefact812does not include an annotation corresponding to the annotation816.

A data artefact860corresponds to the data artefact812after an operation applying the metadata artefact808to the data artefact812. The data artefacts812and860are identical, except that the data artefact860includes the annotations816and870.

Typically, an operation to modify a data artefact using a metadata artefact requires the data artefact to have a common scope with the metadata artefact, and in some cases a corresponding component. For example, if an attempt was made to use the metadata artefact808to modify a data artefact that did not include the TransactionCurrency field, the operation attempt would fail (e.g., no action would be taken, or an error message could be returned).

In another scenario, an attempt could be made to use the metadata artefact808to modify a data artefact that already included a “Semantics.currencyCode” annotation. The result of this scenario can depend on a particular implementation used. In some cases, if a data artefact already contains a component corresponding to a component in a metadata artefact and an “include” operation is specified, no action is taken or an error message is returned (which, in some cases, particularly if the values associated with the component differ, such as having a metadata artefact specifying TRUE and a data artefact specifying FALSE, can include identifying differences between the components/component values). In other cases, the include operation can be treated as an update or synchronization operation, and existing components in a data artefact can be replaced with components from the metadata artefact.

It may be desirable to indicate that a data artefact was modified using a metadata artefact, or to establish a link between a data artefact and metadata artefact used to modify the data artefact. The data artefact860includes an annotation870that indicates that the data artefact was modified by the metadata artefact808. The annotation870indicates that the data artefact860was modified by (or uses) a metadata artefact, but also specifically identifies the metadata artefact808. In some cases, data artefacts, such as definitions of data artefacts in a data dictionary can be queried to find data artefacts modified by any metadata artefact, or by a specific metadata artefact. These annotations can be useful, for example, when it is desired to update all data artefacts that have been modified by a given metadata artefact.

In at least some implementations, notation870is optional. That is, the annotation870can be omitted when the data artefact812is modified, or the annotation can be removed (including manually) from the data artefact860.

If it desired to add multiple components to appropriate data artefacts, a separate metadata artefact can be created for each component to be added. For example, metadata artefact874can be used to add the “currencyCode:true” annotation876to the CompanyCodeCurrency field of the data artefact812, where the metadata artefact is otherwise defined in a similar manner to the metadata artefact808. In another implementation, shown inFIG. 8B, a single metadata artefact878can be defined that adds the “currencyCode:true” annotation for both TransactionCurrency and CompanyCodeCurrency.

A more streamlined technique for updating multiple fields with the same annotation is illustrated in the metadata artefact910ofFIG. 9. The metadata artefact910includes a “map” operation914that associates a local field name916with an alias field name918that may be used in data artefacts to which the metadata artefact910may be applied (e.g., the data artefact850ofFIG. 8). Thus, applying the metadata artefact910to a data artefact will result in the annotation914being applied to any of the fields TransactionCurrency, CompanyCodeCurrency, or DisplayCurrency that might be included in such data artefact. Applying the metadata artefact910to the data artefact812provides an updated data artefact920.

Example 10—Example Removal of Components from Data Artefacts

FIG. 10Aprovides an example of how a metadata artefact1004can be used to remove a component from a data artefact1008. The data artefact1008corresponds to the data artefact812ofFIG. 8. In this scenario, assume that it is desired to remove the “EndUserText.label” annotation1012from the data artefact1008. This change could be because this use of applying labels directly to fields may be undesirable (instead having such labels applied as part of an element, corresponding to the field, in a data dictionary, such as using an element in a data dictionary as described in Examples 4 and 5).

The metadata artefact1004includes an annotation1016indicating that the metadata artefact has a change whose scope is for annotations (reference1018) and where the operation is to exclude (reference1020), or remove, such annotations if found in a data artefact to which the metadata artefact1004is applied. The metadata artefact1004includes an annotation1024, which is therefore governed by the preceding semantic elements1018,1020of the annotation1016. Accordingly, the content of the annotation1024, “EndUserText.label”, will be removed, if present, from any data artefacts to which the metadata artefact1004is applied. Note that the annotation1024includes a specification of “ANY” (reference1026), which acts as a wildcard such that EndUserText.label annotations are removed regardless of their content. If it was desired to only remove text labels having particular content, that content could be specified in the annotation1024instead of ANY, and therefore annotations would only be removed from data artefacts if they contained the text specified in the annotation1024.

This Example 10 also illustrates that a metadata artefact can be used to carry out different types of operations. While the metadata artefact1004includes an operation to remove a particular annotation, the annotation1016has another component whose scope is a data type (reference1032) and provides that a component1036(the cast statement) should be added (reference1034) to relevant data artefacts to which the metadata artefact is applied.

A data artefact1040corresponds to the data artefact1008after the metadata artefact1004is applied to the data artefact1008. Since the data artefact1008includes the annotation1012, and that is responsive to the annotation1024, the annotation1012is removed in the data artefact1040. The TransactionCurrency field1010of the data artefact1008corresponds to the annotation1016for the metadata element1036, and so the cast statement of the annotation1016has been added to the data artefact1040.

In a similar manner as described in Example 9 for adding components (particularly, annotations), a framework used to implement metadata artefacts can be designed to take particular actions in the event a data artefact being modified by a metadata artefact does not include components specified in the metadata artefact, if the data artefact includes conflicting components, or to take different actions depending on the type of component being added, removed, or modified. As when adding components, if a metadata artefact specifies that a component should be removed, and the component is not present in a specified data artefact, no action can be taken, or an error message can be provided.

As an example of how a framework can be designed to process commands to add, remove, or modify metadata elements differently depending on the nature of a given metadata element, in some cases the cast statement associated with the metadata element1036is only added to a data element if an existing typing of the field (either explicitly in the data artefact or as defined in a data dictionary) differs from the typing used in the cast statement. Cast statements, in some programming languages (such as ABAP), can be used to change one or both of technical properties of a data type or semantic properties of the data type. If a data type of a metadata element in a data artefact corresponds to a data type for a metadata element in a metadata artefact, but the desired semantic properties are not associated with the data type in the data artefact (for example, by associating the data type with an element in a data dictionary, where the definition of the element specifies semantic properties for the element), a framework can automatically add a “preserving type” statement1044to the cast statement1042in the data artefact1040. In this example, the use of the “preserving type” statement1044can help avoid unnecessary data type conversion, or processing to determine that data type conversion is not required. “Preserving type” can provide that the technical type interpreted by the database system remains unchanged, even if the semantics of the field in the virtual data model are changed.

In some cases, it may be desired to set the value of a component of a data artefact to a default or null value, rather than removing the component. Providing a default or null value, can, for example, be more informative to a developer than completely removing the associated component. With reference toFIG. 10B, a metadata artefact1050is similar to the metadata artefact1004. However, rather than the command to remove the EndUserText.label annotation, the metadata artefact1050includes an annotation1054indicating that an annotation1058is to be added (references1060,1062). The annotation1054provides that an EndUserText.label element will be included, but with a value set to null.

Note that this scenario may require that the implementing framework treat a request to add a component to a data artefact that already includes a different version of the component as a request to modify an existing component (which can include modifying the component in the data artefact or deleting the conflicting component and adding the desired version of the component).

Data artefact1070represents the result of applying the metadata artefact1050to the data artefact1008.

Example 11—Example Annotation of Data Artefact Parameters

FIG. 11describes how metadata artefacts can be used to add annotations to parameters of a data artefact. In some cases, parameters can represent expected input when an associated data artefact is used (e.g., invoked, called, or instantiated). In the example ofFIG. 11, a metadata artefact1104can be used to provide a default value for a parameter, such as using a current date (provided by a computing system) for a parameter intended to be supplied with a date. The metadata artefact1104is defined as a view (reference1108) and includes an annotation1112specifying an include operation for an annotation (references1116and1118) and an include operation for a data type (references1120,1122). An annotation1126corresponds to the references1116,1118, and indicates that a system supplied date should be used as a default value for P_KeyDate field.

Metadata element1130corresponds to the references1120,1122, and can provide that data artefacts to which the metadata artefact1104is applied use the DATA_ELEMENT_KEY_DATE datatype with the P_KeyDate parameter.

Example 12—Example Annotation of Data Artefact Definitions

FIG. 12illustrates an example metadata artefact1204that can be used to add annotations to a base definition of a data artefact (e.g., rather than to components of the data artefact, such as annotations, elements, or parameters). The metadata artefact1204includes an annotation1208that indicates that it applies to annotations (reference1212) and will add annotations to data members to which the metadata artefact is applied (reference1214).

The metadata artefact1204includes three annotations1220,1222,1224that will be applied to data artefacts. Annotations1220,1222are instructions that influence how the affected data artefact will be stored in, or processed by, a data dictionary. For example, the annotation1220can be used to provide that equally modelled filter conditions in the virtual data model result in equal joins being performed by the database system/in the data artefact (e.g., whether multiple joins or a single join should be defined/evaluated for multiple instances of the same filter condition).

The annotation1222can be used to mandate that keys specified in virtual database artefacts will be used as keys for a database artefact corresponding to the data artefact, rather than default behavior, which can be to use keys that are associated with underlying database artefacts, such as tables from which a view was created, for the database artefact corresponding to the data artefact. Annotation1224can be used to indicate whether data sources for the data artefact should be client dependent or client independent (e.g., whether the data selection is to be filtered by a current client of a current user session).

Note that the metadata artefact1204can be used to decorate (or annotate) any data artefact. Unlike other example decoration examples, the annotation1208does not require a particular scope or a particular component (e.g., annotation, element, or parameter) to match in a data artefact in order for the contents of the metadata element1204to be applied to a data artefact.

Example 13—Example Addition of Fields to Data Artefacts

A metadata artefact can be used to add other types of components to a data artefact, in addition to, or in place of, adding annotations to the data artefact.FIG. 13illustrates a metadata artefact1304that includes an annotation1308that can be used to add a component (reference1310), in the form of a field associated with an element (e.g., as described in Examples 4 and 5), and a component (reference1312) that which annotates the field.

As discussed in Example 9, if a metadata artefact adds components to a data artefact, or modifies components that may already be in a data artefact, the metadata artefact need not define any data to be used with the metadata artefact. The metadata artefact may include data-related features in order to comply with programming requirements or formatting requirements, such as a dummy data selection clause.

If a metadata artefact adds data elements to a data artefact, the metadata artefact can include an actual (non-dummy) data selection clause. As shown, the metadata artefact1304contains a selection clause1320that reference a particular field1322of a specified table1324, and incorporates the field1322as a new field1326of the metadata artefact. The annotation1330specifies that the field1326will be hidden (for example not available to applications or other at least certain other artefacts, which can be useful, when it is desired not to make the field available to client applications, including through data services such as OData).

In addition to adding comparatively simple components, as with the metadata artefact1404, metadata artefacts can include more complex expressions that can be applied to data artefacts.FIG. 14provides a metadata artefact1404that incudes includes a calculation1408that can be applied to data artefacts, as indicated by the annotation1412. In this example, the calculation1408calculates a customer name from a business partner name.

In some cases, components that may be desired to be included in a data artefact using a metadata artefact may already be present in the data artefact. For example, the calculation1408may be included in an existing data artefact. If desired, rather than repeating the calculation, the existing data artefact can be made available for use as a metadata artefact, as illustrated inFIG. 15.

FIG. 15illustrates a data artefact1504modified to serve as a metadata artefact. Note that the definition statement1508, unlike previously described metadata artefacts, does not contain “CMD.” The definition statement1508and a calculation1512(corresponding to the calculation1408) can represent the “original” version of the data artefact1504, prior to being modified to serve as a metadata artefact. Annotation1516allows the data artefact1504to serve as a metadata artefact, as it includes a semantic element (@MetadataDecorator) that triggers application of the decorator framework and defines a scope (element, reference1520) and an operation (include, reference1522) for the calculation1512.

The data artefact1504also includes an annotation1530that maps the local field names “name1” and “name2” to aliases “OrganizationBPName1” and “OrganizationBPName2” that are expected to be in data artefacts to which the data artefact1504is to be applied. The annotation1530accounts for these otherwise minor differences between the calculation1512and the calculation1408.

Example 14—Example Additions of Associations to Data Artefacts

Metadata artefacts can be used to create associations between virtual data model artefacts. Associations can be a way of linking two virtual data model artefacts, and can be thought of as a lazy JOIN or JOIN on demand. In a particular implementation, association functionality can be implemented as in the Core Data Services technologies of SAP SE, of Walldorf, Germany.

FIG. 16illustrates a metadata artefact1604that exposes an association_Product (line1620). A metadata decorator annotation1618indicates that the association1620will be added to data artefacts to which the metadata artefact1604is applied, where the annotation1622(added in response to metadata decorator annotation1614) specifies that the association_Product serves as a foreign key (on the field Product). In addition, the association definition1630will be incorporated into any data artefacts to which the metadata artefact1604is applied, given that metadata decorator annotation1618adds the association1620to such data artefacts.

As with other metadata artefacts described in the present disclosure, a metadata artefact that adds associations to data artefacts can include a mapping statement that maps local names used in the metadata artefacts to various aliases that may be used in data artefacts to which the metadata artefact may be applied.FIG. 17Aillustrates an example metadata artefact1704that includes a mapping statement1708that maps multiple local names to aliases. Note that a single local name may be mapped to multiple aliases.

The metadata artefact1704includes multiple decorator annotations1712,1716,1720,1724. Annotations1720,1724are similar to annotation1622, in that the associations defined in the metadata artefact1704will be added as components to data artefacts to which the metadata artefact is applied. Annotations1712,1716are generally similar to the annotation1614, in that they indicate that the annotations for the association will be added to data artefacts. However, the annotations1712,1716also indicate (references1730,1732) that the typing of the fields will match the data type specified by the cast statements (1736,1738).

FIG. 17Bprovides a definition for a data artefact1740to which the metadata artefact1704can be applied.FIG. 17Balso provides a definition for a data artefact1750, which corresponds to the data artefact1740after the metadata artefact1704has been applied to the data artefact1740.

Example 15—Example Replacement of Components in Data Artefacts

In addition to adding components to, or removing components from, a data artefact, metadata artefacts can be used to replace components in a data artefact. In at least some cases, equivalent functionality can be carried out by removing existing components and then adding new components. However, having an explicit “replace” function can make it easier to accomplish replacements, and make it easier to understand the intent of a metadata artefact.

FIG. 18illustrates a data artefact1804having an annotation1808that is to be replaced. A metadata artefact1812includes an annotation1816specifying that its scope is an annotation (reference1820) and that it defines a replacement operation (reference1822). In order to help identify what is being replaced, the annotation1816includes a replacement definition1826, which indicates that the “NewTotalNetAmount” is the component whose annotation is being added to a modified data artefact.

The metadata artefact1812includes a component of the annotation1808, indicating that this is the component to be removed from a modified data artefact. The metadata artefact1812includes an updated annotation1830to be added to the data artefact1804, as well as a new component1834.

Data artefact1850represents the result of applying the metadata artefact1812to the data artefact1804. Note that the annotation1808has been replaced with the annotation1830. However, an element1810of the data artefact1804was not replaced with the element1834, since the annotation1816did not specify a scope of “ELEMENT,” only “ANNOTATION.”

The replacement technique used for the metadata artefact1812can be broadened such that a broader range of components can be updated to include a replacement annotation (or, more generally, other types of updated components). For example, the metadata artefact1812will only be applied to aggregations of the type “#SUM.” Metadata artefact1860is similar to metadata artefact1812, but includes a mapping statement1864that maps the local component name “TotalNetAmount” to any aggregation statement, of any type. That is, as long as a component has the “#” token, a replacement annotation1868of the metadata artefact1860will be applied. Line1872specifies that the aggregation type originally specified in the data artefact (e.g.,1808) will be preserved after the data artefact is updated using the metadata artefact1860.

Example 16—Example Synchronization of Data Artefact Components

Example 15 described how a replace operation can be used to remove a particular component and add a different or revised component. However, in at least some implementations, a replace operation may only operate on a specified component. Consider a scenario where a developer wishes to synchronize data artefacts so that a particular component only includes specified annotations, and no others. A replace operation may provide that a version of a particular annotation is consistent, but may not remove additional annotations that might be present in a data artefact. This Example 16 describes a synchronize operation, which results in the removal of components that are present in a data artefact and are not specified in a metadata element used for the synchronization (at least, for any components specified in the metadata artefact).

FIG. 19presents a data artefact1904to which a metadata artefact1920will be applied. The data artefact1904includes an element1906(“Product”) having an annotation1908. The metadata artefact1920includes an annotation1922specifying that it applies to annotations (its scope, reference1924) and that a synchronization operation is to be carried out (reference1926). A body of the annotation1920specifies an annotation1930.

A data artefact1940represents the result of applying the metadata artefact1920to the data artefact1904. Note that the annotation1930has been added to the data artefact1940. Since the metadata artefact1920did not include the annotation1908, the annotation1908has been removed from the data artefact1904in producing the data artefact1940. Note also that the metadata artefact1920includes an element1950, but that this element was not inserted into the data artefact1904, and the element1906was not removed. This is because the annotation1920had a scope of “annotation,” not “element” or “data type.”

Example 17—Example Merged Metadata Artefacts

Just as it can be useful to have modularized code, it can be useful to have modularized metadata artefacts. In this way, metadata artefacts can be made progressively more complex by including functionality from other metadata artefacts. This functionality can be similar to programming concepts such as the #include directive of C++. Typically, the functionality of a given metadata artefact and any incorporated metadata artefacts are logically merged when the given metadata artefact is applied to a data artefact. Or, the metadata artefacts can be merged after a metadata artefact is defined.

FIG. 20illustrates a metadata artefact2030that incorporates metadata artefacts2010and2020using an “includedModel” statement2032. Metadata artefact2050represents the effective, logically merged metadata artefact, produced from the metadata artefact2030and its incorporated metadata objects2010,2020.

It can be possible that multiple metadata artefacts modify the same component, including in inconsistent ways, or contain conflicting operations for a component (e.g., one metadata artefact adds an annotation that is then removed by another metadata artefact). A framework that implements metadata artefacts can check for such possible inconsistencies and can either return an error or can include rules for resolving at least certain kinds of conflicts (e.g., having operations in an explicitly defined metadata artefact taking precedence over possibly conflicting operations in an incorporated metadata artefact).

Also note that multiple levels of nesting or incorporation can be used. That is, for example, the metadata artefact2030could itself be incorporated into other metadata artefacts.

Example 18—Example Decorator Framework

FIG. 21illustrates a metadata annotation, or decorator, framework2100that can be used to implement metadata artefacts that are useable to annotate data artefacts, such as described in Examples 1, 2, and 9-17. The framework2100includes a metadata decorator controller2104. The metadata decorator controller2104can orchestrate processes involving metadata artefacts, including providing an interface (e.g., an application program interface, or “API”) that can be called by various consumers to take actions such as querying, creating, and editing metadata artefacts or applying metadata artefacts to data artefacts. For example, a metadata decorator user interface2108can allow users to call such functionality.

It can be useful to check metadata artefacts prior to their use. For example, it may be desirable to confirm that a metadata artefact is syntactically and semantically correct. If a metadata artefact incorporates other metadata artefacts, it may be desirable to confirm that the collection of metadata artefacts does not contain inconsistencies. Similarly, if multiple metadata artefacts are to be applied, it can be useful to confirm that the collective operations of the metadata artefacts do not conflict, including considering an order in which the metadata artefacts are to be applied.

In some cases, functionality for carrying out these actions can be directly included in the framework2100. In other cases, suitable functionality may exist elsewhere in a software application or application suite, and can be leveraged by the framework2100. The framework2100can include a metadata decorator test framework adapter2112that can allow the framework to access existing test functionality. In a particular implementation, the test framework can be the ABAP Test Cockpit software available from SAP SE, of Walldorf, Germany. In particular, the ABAP Test Cockpit includes functionality for analyzing CDS views. As described, in an implementation, metadata artefacts can be CDS Metadata Decorator (CMD) models (or artefacts) that can be a particular type of CDS view, and thus test and analysis features of the ABAP Test Cockpit can be applied to CDM models. The metadata decorator controller2104can call functions of the test framework adapter2112, and can also expose APIs that can be called by the test framework adapter (e.g., to carry out operations specific to metadata artefacts, which operations are carried out by other components of the framework2100).

The framework2100can include a batch report component2116. The batch report component2116can communicate with the metadata decorator controller2104to perform functions such as analyzing multiple metadata artefacts. The batch report component2116can also be used to synchronize data artefacts using specified metadata artefacts. Actions carried out using the batch report component2116can be executed on an ad-hoc basis (e.g., in response to a user request) or can be carried out according to a schedule or upon various triggers.

Other applications may be permitted to access functionality of the framework2100though a consumer API2120. The consumer API2120can include similar functionality as the metadata decorator user interface2108, but the API methods can be called by other applications, rather than using the internal user interface component. In addition, while the commands sent to the consumer API2120can be from a user interface of another application, they need not be (or at least need not be directly triggered or requested by an end user, but rather can be called by processes of such other application).

It can be useful to maintain summary information regarding metadata artefacts to facilitate the process of searching, comparing, analyzing, or updating metadata artefacts. In some cases, this information can be stored in a persistency model, such as in tables of a relational database system, including as described in U.S. patent application Ser. No. 16/387,983. A metadata artefact selection manager component2124can be responsible for selecting appropriate metadata artefacts, such as by issuing commands to store, retrieve, modify, or delete metadata artefacts to a metadata artefact persistency manager2128, which stores the metadata artefacts, or their summary information, in a metadata artefact persistency layer2132. The metadata artefact selection manager2124can include queries, and functionality for executing such queries, to carry out requested operations. Query results can be stored as metadata artefact lists2134(e.g., table2850ofFIG. 28B).

A metadata artefact manager2138can manage metadata artefacts2142, including having functionality for checking the consistency and functionality of metadata artefacts. These checks can be carried out using the metadata decorator controller2104and the test framework adapter2112, in some cases. In other cases, the checks can be carried out by a metadata artefact analyzer2146(e.g., functions, which can be accessed through an API, for providing various checks). The metadata artefact analyzer2142can also include functionality for analyzing data artefacts2150, such as to determine whether a metadata artefact can be applied to a data artefact, or determining whether a data artefact is inconsistent with a specified metadata artefact. In the event a data artefact is inconsistent with a specified metadata artefact, the metadata artefact analyzer2146can trigger synchronization using a metadata artefact synchronizer component2154.

The metadata artefact manager2138can also include functionality for creating, deleting, or modifying metadata artefacts. Modifications can be communicated to the selection manager2124or the persistency manager2128, such as to update artefact lists2134or add, remove, or update summaries of metadata artefacts in the persistency layer2132.

Example 19—Example Decorator Framework Processes

FIGS. 22-27are timing diagrams illustrating various operations that can be carried using metadata artefacts and data artefacts, including using components of the framework2100ofFIG. 21.

FIG. 22is a timing diagram of a process2200for creating selection criteria for artefacts, such as data artefacts or metadata artefacts, in a repository. The selection criteria can represent a saved query (or query components) that can be used as part of other processes, such as a process to apply metadata artefacts to data artefacts (including as part of a synchronization request) or a process to update or edit metadata artefacts.FIG. 28Aprovides an example of a data model that can be used to store selection criteria.

The process2200can be implemented using a user interface component2204, a controller2206, a selection manager2208, an artefact list2210, a persistency manager2212, and a persistency layer2214, which components can have functions analogous to those described for the similarly titled components of the framework2100. The process2200can also use an artefact repository2216, which can store data artefacts and metadata artefacts, and an enqueue server2218, which can be used to help avoid concurrency problems that could otherwise occur if multiple users were maintaining the same artefacts in parallel. Such task management can include locking objects upon the request of one process so that they cannot be changed by other processes, and releasing such locks. In some cases, an enqueue server2218can include multi-version concurrency control (“MVCC”) functionality, which can generally be implemented in a similar manner as MVCC database systems. In a particular example, the enqueue server2218can be the enqueue server used in ABAP-based technologies (including NetWeaver) available from SAP SE, of Walldorf, Germany.

At2220, a user enters artefact selection criteria. Artefact selection criteria can include identifiers or partial identifiers for a name of an artefact, or for particular properties of desired artefacts. For example, search criteria can include fields/elements used in an artefact, annotations or annotation values used in an artefact, relationships between artefacts (for example, finding metadata artefacts that incorporate other metadata artefacts), artefacts associated with particular software applications or components or particular developers, other factors, or combinations of thereof. The selection criteria can be saved and then sent from the user interface2204to the controller2206, which can save the selection criteria at2222.

The controller2206can request that the selection manager2208lock the selection criteria (e.g., so that it cannot be changed during the process2200). The selection manager2208issues a lock request at2224to the enqueue server2218, which locks the selection at2226, and can return a lock indicator (e.g., success or failure) to the selection manager2208.

At2228, the selection manager can check the selection criteria, such as for security (e.g., to check for SQL injections) or validity purposes (e.g., confirm that specified fields are valid in a data dictionary). In some cases, it may be desired to save selection criteria, while in other cases, it may be desired to save an object or artefact list that indicates artefacts responsive to selection criteria. If it is desired to save a list of artefacts responsive to a query, the selection manager2208can apply selection criteria at2230, creating an artefact list2210(which can be an instance of an abstract data type or a data structure, or an abstract data type that includes a data structure as a data member, or can be a table, such as table2850ofFIG. 28B) that at2232requests a selection of appropriate artefacts2234from the artefact repository2216. The responsive artefacts, or identifiers for such artefacts, are stored in the artefact list at2236.

At2238, if requested, the selection manager2208converts the list into the selection criteria. That is, an artefact list can be a list of artefacts, and the representation in table2850can be a representation of the artefact list using a selection criteria notation/persistency model. At2238, the selection manager2208saves the selection criteria by issuing a command to the persistency manager2212, which initiates a save operation at2240, causing artefacts2242to be stored in the persistency layer2214. The persistency manager2212can then return a result of the save operation (e.g., success or failure) to the selection manager2208at2244.

The selection manager2208, at2246, can issue a request to the enqueue server2218to unlock the selection criteria. The enqueue server2218can unlock the selection criteria at2248and return a result of the operation to the selection manager2208. The selection manager2208and controller2206return control, and optionally a success or failure indication, to the user interface2204at2250,2252.

FIG. 23is a timing diagram of a process2300for selecting artefacts, such as data artefacts or metadata artefacts, in a repository. In some cases, the selection can be carried out using previously saved selection criteria (e.g., by providing an identifier for selection criteria saved using the process2200ofFIG. 22). In other cases, the selection criteria are provided as part of the process2300. The process2300can be implemented using a user interface component2304, a controller2306, a selection manager2308, an artefact list2310, a persistency manager2312, a persistency layer2314, and an artefact repository2316which components can have functions analogous to those described for the similarly titled components2204-2216of the process2200.

At2320, selection criteria, either explicitly or by reference to a selection identifier for previously defined selection criteria, are received through the user interface2304. The selection request is sent to the controller2306by the user interface2304. At2324, if the request is based on an identifier for previously defined selection criteria, the selection manager2308can fetch the saved selection criteria by issuing a request to the persistency manager2312. The persistency manager2312processes the request at2326by fetching the requested selection criteria2328from the persistency manager2314and returning the saved criteria to the selection manager2308at2330.

At2332, the selection criteria, as retrieved at2324or supplied at2320, are applied by the selection manager2308. The request creates at artefact list2310at2334, which selects the artefacts2336from the artefact repository2316and stores the artefacts (either the artefacts or their identifiers) in the artefact list. The artefact list2310can be returned to the selection manager2308at2338, and then in turn to the controller2306and the user interface2304at2340,2342.

FIG. 24is a timing diagram of a process2400for creating a metadata artefact. The process2400is shown as implemented by a user interface component2404, a controller2406, a repository2416, and an enqueue server2418, which can be implemented as described for the correspondingly titled components2204,2206,2216,2218ofFIG. 22. The process2400is also implemented using a model manager2408, an analyzer2410, and a synchronizer2412, which can be implemented as described for the corresponding components2138,2146,2154ofFIG. 21.

At2420, a user enters a definition for a metadata artefact using the user interface2404. The user interface2404issues a request at2422to the controller2408to save the metadata artefact. The controller2408initiates the save process at2424by instructing the model manager2408to lock the identified metadata artefact. At2426, model manager2408issues a lock request to the enqueue server2418, which locks the metadata artefact at2428and returns a response (e.g., indicating success or failure) to the model manager. The model manager2408determines whether the metadata artefact has been defined as including any other metadata artefacts. If so, the model manager2408selects the included artefacts2432from the repository2416at2430. The metadata artefacts can then be merged by the model manager2408at2434, and checked for consistency at2436. If no error was detected, the model manager2408saves the metadata artefacts2444in the repository2416at2438.

After the metadata artefact has been saved, the model manager2408, at2442, issues a command to the enqueue server2418to unlock the metadata artefact, which the enqueue server does at2444, along with returning an operation indicator to the model manager. The result of the save operation can then be returned by the model manager2408to the controller2406, and then by the controller2406to the user interface2404, at2446,2448.

FIG. 25is a timing diagram of a process2500for checking the consistency of metadata artefacts. The process2500is shown as implemented by a test framework adapter2504, which can be the test framework adapter2112ofFIG. 21. The process2500is further implemented by a controller2506, a model manager2508, an analyzer2510, a synchronizer2512, and a repository2516, which correspond to the similarly titled components2406,2408,2410,2412,2416ofFIG. 24.

At2520, a request is sent by the test framework adapter2504to check the consistency of two or more metadata artefacts and data artefacts, which can include passing their keys (identifiers) to the controller2506. The controller2506requests delta information (e.g., differences between the metadata artefacts and the data artefacts on which the metadata artefacts were applied) at2522by issuing a request to the analyzer2510. The analyzer2510selects the appropriate metadata artefacts2526from the repository at2524. At2528, the analyzer2510calls the model manager2508to trigger a process for merging metadata artefact definitions, if required, and checking the consistency of any merged definitions (e.g., for any composite metadata artefacts). The metadata artefacts and the data artefacts, or information regarding such artefacts, is sent to the model manager2508by the analyzer2510at2528.

At2530, the model manager2508selects the definitions2532of the metadata artefacts from the repository2516at2530. At2534, the model manager2508merges metadata artefact definitions, if appropriate. The model manager2508also checks the consistency of the merged definitions at2534. At2536, the analyzer2510checks the definitions for the selected metadata artefacts to determine if any differences are detected. This delta information is sent from the analyzer2510to the controller2506.

The controller2506, at2538, converts the delta information into messages in a metadata artefact message format by sending a request to the analyzer2510, which carries out the conversion at2540and returns results to the controller. The metadata artefact message format can describe operations to make one metadata artefact consistent with another. Or, the metadata artefact message format can simply summarize differences between two (or more) metadata artefacts. The controller2506can return the metadata artefact messages to the test framework adapter2504at2542, which can convert the metadata artefact messages into a format used by a test framework at2544.

FIG. 26is a timing diagram of a process2600for applying one or more metadata artefacts to one or more data artefacts. The process2600is shown as implemented by a user interface2604, a controller2606, a model manager2608, an analyzer2610, a synchronizer2612, a repository2616, and an enqueue server2618. The components2606,2608,2610,2612,2616,2618can be implemented as described for the corresponding components2506,2508,2510,2512,2516, and2518ofFIG. 25. The user interface component2604can be the user interface component2204ofFIG. 22.

At2620, a user can use the user interface2604to select one or more metadata artefacts to apply to one or more data artefacts. The selection process can occur as described for the process2300ofFIG. 23. A request to apply the metadata data artefacts to the data artefacts is received by the user interface2604at2622and is sent to the controller2606. At2624, the controller2606begins a process to update the data artefacts as requested. The controller2606sends a command to the synchronizer2612to synchronize the selected data artefacts with the relevant metadata artefacts. At2626, the synchronizer2612sends a command to the enqueue server2618to lock the relevant data artefacts. The enqueue server2618locks the data artefacts at2628.

At2630, the synchronizer2612selects the data artefacts2630from the repository2616. The synchronizer2612, at2634, gets delta information2636to determine if/how data artefacts should be updated as compared with the metadata artefacts to be applied to them. The delta information process can be carried out using the process2500ofFIG. 25. At2638, the synchronizer2612checks if any delta is detected, which would indicate that one or more data artefacts should be updated. Any such data artefacts can then be updated by the synchronizer2612at2640. The technical consistency of changed data artefacts is previously checked by the synchronizer2612at2638. At2642, the synchronizer2612instructs the enqueue server2618to unlock the data artefacts, which the enqueue server does as2644. The results of the update request are returned by the synchronizer2612to the controller2606at2646, and by the controller to the user interface2604at2648.

FIG. 27is a timing diagram of a process2700of synchronizing data artefacts, which can include determining whether any changes are needed and, if so, carrying out such changes. The process2700is shown as implemented by a batch report2704, a controller2706, a model manager2708, an analyzer2710, a synchronizer2712, a repository2716, and an enqueue server2718. The components2706,2708,2710,2712,2716,2718can be implemented as described for the corresponding components2506,2508,2510,2512,2516, and2518ofFIG. 25. The batch report2704can correspond to the batch report component2116ofFIG. 21.

At2720, execution of a batch report by the batch report component2704selects data objects to be synchronized. The selection process can occur as described for the process2300ofFIG. 23. A request to synchronize the data artefacts (e.g., make sure they are up to date) is sent at2720to the controller2706. At2722, the controller2706begins a process to synchronize the data artefacts as requested. The controller2706sends a command to the synchronizer2712to synchronize the selected data artefacts with the relevant metadata artefacts. At2724, the synchronizer2712sends a command to the enqueue server2718to lock the relevant data artefacts. The enqueue server2718locks the data artefacts at2726.

The synchronizer2712, at2728, gets delta information2730to determine if/how data artefacts should be updated as compared with the metadata artefacts to be applied to them. In some cases, this determination can be made using a summary of the metadata artefacts and metadata artefacts, including using the schema described in U.S. patent application Ser. No. 16/387,983. The delta information process can be carried out using the process2500ofFIG. 25.

At2732, the synchronizer2712checks if any delta is detected, which would indicate that one or more data artefacts should be updated. Any such data artefacts2734can then be selected from the repository2716by the synchronizer2712at2732. The synchronizer2712performs updates on the data artefacts at2736, as specified in the delta information. The technical consistency of changed data artefacts is also checked by the synchronizer2712at2736. The synchronizer2712saves the updated data artefacts2738to the repository2716at2736. At2740, the synchronizer2712instructs the enqueue server2718to unlock the data artefacts, which is carried out by the enqueue server at2742. The results of the update request are returned by the synchronizer2712to the controller2706at2744, and by the controller to the batch report component2704at2746.

Example 20—Example Selection Persistency Model

FIGS. 28A and 28Billustrates a persistency model that can be used to store representations of selection criteria, such as selection criteria defined using the process2300ofFIG. 23. With reference toFIG. 28A, a table2802stores information regarding selections, where each record2804of the table2802can represent a particular selection.

The table2804includes a selection identifier attribute2806, which can uniquely identify a particular selection. In some cases, the selection identifier attribute2806can be a primary key (which can be a technical key) for the table2804, can be a technical key (e.g., an artificially assigned value, such as an integer). A description attribute2808can provide a semantic (e.g., human understandable) description of a given selection, such as describing the selection criteria. An object type attribute2810can provide a type for the selection, such as indicating that the selection is associated with an object in a data dictionary (and thus may be associated with a DDLS statement, or otherwise being a DDLS object), or that the selected artefacts have the indicated type. Attributes2812,2814,2816,2818can describe, respectively, an identifier for a user or process that created a given selection, a date the selection was created, an identifier for a user or process that last changed a given selection, and a date that the selection was last changed.

A table2820can have records2822that correspond to particular selection conditions that are included in a selection of the table2802. The table2820includes a selection identifier attribute2824, which can correspond to the attribute2806. Note that a given selection can be associated with multiple records2822, and thus selection conditions, in the table2820. The table2820can include a selection condition number attribute2826, which can be used to distinguish between selection conditions when a given selection is associated with multiple records2822. Although not shown, in other implementations, the table2820can assign a unique identifier (e.g., using a technical primary key) to each record2822.

A criterion attribute2828lists particular selection criterion for a given selection condition of the table2820. The value of the attribute2828can include metadata associated with a metadata artefact or data artefact, such as an application component with which the artefact is associated, a release status, or an object name. The values of the attribute2828can also include particular components of a data artefact or metadata artefact, such as specifying a particular annotation, data type, element, parameter, etc. A sign attribute2830can specify whether responsive artefacts are those that do or not satisfy the criterion attribute2828.

An option attribute2832can specify an operator to apply to values for the criterion attribute2828, such as whether responsive artefacts are those having values that are equal to a given value, are greater than or less than a given value, or contain all or part of a given value (e.g., using fuzzy search logic, pattern matching, substrings, etc.). When a single value is associated with a given option attribute2832, the value can be specified in a low value attribute2834, which can also supply the lower boundary for range-based criteria. In the event range based criteria are used, an upper bound van be specified for a high value attribute2836.

A table2840can be used to define selection groups, where a selection group allows a selection of the table2804to be defined with respect to other selections. The table2840includes a selection identifier attribute2842, which can be the selection identifier attribute2806. An ordinal number attribute2844can be used to distinguish between different selections that may be used to define another selection, and in some cases can also be used to indicate an order in which selections should be applied in defining a given selection. An including operator attribute2846can indicate whether a given selection should or should not include results for a specified selection. The referenced, or specified, selection can be provided in an included selection identifier attribute2848. Note that, in the example shown, selection IDs4711and4712of table2804are defined in the table2820. However, selection identifier4713is defined in table2840based on selections IDs4711,4712. A given selection can be defined with respect to other selections (e.g., using table2840) in addition to additional selection conditions defined for that given selection in the table2820.

FIG. 28Billustrates a table2850that can be used to store object or artefact lists—lists of specific artefacts meeting selection criteria rather than (or in addition to) storing the selection criteria itself. A selection can thus be similar to a query, and an artefact list can be similar to a materialized view. The table2850is generally similar to the table2820, and includes attributes2852,2854,2856,2858,2860,2862,2864, which can be at least generally similar to the attributes2824-2836. The table2850is shown as having records2870that correspond to a specific metadata artefact or data artefact (identified in the field2862). A given selection ID, in this case4712, can be associated with multiple records2870, and thus multiple artefacts. Storing artefact lists, as in table2850can be useful, as it may be desirable to have a fixed list of artefacts that does not change over time, even if new artefacts are created that might satisfy the original selection criteria, or if existing artefacts are changed such that may no longer satisfy the selection criteria.

FIG. 28Balso illustrates example selection criteria2880that can be produced from the tables2804,2820,2840. Specifically, the selection criteria2880represents an executable selection for selection4713of table2840. In at least some implementations, when a single criterion includes multiple conditions, the conditions are separate by a logical OR operation. Conditions for different criteria are typically separated by a logical AND operation. Operators such as AND, OR, and NOT can be used within groups of nested selections.

Example 21—Example Implementations

FIG. 29is a flowchart of an example method2900for updating one or more data artefacts using one or more metadata artefacts. The method2900can be implemented using the computing environment100ofFIG. 1, including a computing environment that includes a metadata decorator framework as implemented in the metadata decorator framework2100ofFIG. 21.

At2910, a command is received by a metadata decorator framework to update one or more data artefacts with one or more metadata artefacts. A given metadata artefact of the one or more metadata artefacts includes one or more syntax elements processable by the metadata decorator framework. The one or more data artefacts are retrieved at2920. The one or more metadata artefacts are retrieved at2930. At2940, the one or more data artefacts are updated according to one or more metadata indicators (such as annotations readable by a metadata decorator framework) specified by the one or more metadata artefacts to provide one or more updated data artefacts. A metadata indicator includes at least a portion of the one or more syntax elements. The one or more updated data artefacts are stored at2950.

Example 22—Computing Systems

FIG. 30depicts a generalized example of a suitable computing system3000in which the described innovations may be implemented. The computing system3000is not intended to suggest any limitation as to scope of use or functionality of the present disclosure, as the innovations may be implemented in diverse general-purpose or special-purpose computing systems.

With reference toFIG. 30, the computing system3000includes one or more processing units3010,3015and memory3020,3025. InFIG. 30, this basic configuration3030is included within a dashed line. The processing units3010,3015execute computer-executable instructions, such as for implementing components of the environment100ofFIG. 1, including as described in Examples 1-21. A processing unit can be a general-purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC), or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example,FIG. 30shows a central processing unit3010as well as a graphics processing unit or co-processing unit3015. The tangible memory3020,3025may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing unit(s)3010,3015. The memory3020,3025stores software3080implementing one or more innovations described herein, in the form of computer-executable instructions suitable for execution by the processing unit(s)3010,3015.

A computing system3000may have additional features. For example, the computing system3000includes storage3040, one or more input devices3050, one or more output devices3060, and one or more communication connections3070. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system3000. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system3000, and coordinates activities of the components of the computing system3000.

The tangible storage3040may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information in a non-transitory way and which can be accessed within the computing system3000. The storage3040stores instructions for the software3080implementing one or more innovations described herein.

The input device(s)3050may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system3000. The output device(s)3060may be a display, printer, speaker, CD-writer, or another device that provides output from the computing system3000.

In various examples described herein, a module (e.g., component or engine) can be “coded” to perform certain operations or provide certain functionality, indicating that computer-executable instructions for the module can be executed to perform such operations, cause such operations to be performed, or to otherwise provide such functionality. Although functionality described with respect to a software component, module, or engine can be carried out as a discrete software unit (e.g., program, function, class method), it need not be implemented as a discrete unit. That is, the functionality can be incorporated into a larger or more general purpose program, such as one or more lines of code in a larger or general purpose program.

Example 23—Cloud Computing Environment

FIG. 31depicts an example cloud computing environment3100in which the described technologies can be implemented. The cloud computing environment3100comprises cloud computing services3110. The cloud computing services3110can comprise various types of cloud computing resources, such as computer servers, data storage repositories, networking resources, etc. The cloud computing services3110can be centrally located (e.g., provided by a data center of a business or organization) or distributed (e.g., provided by various computing resources located at different locations, such as different data centers and/or located in different cities or countries).

The cloud computing services3110are utilized by various types of computing devices (e.g., client computing devices), such as computing devices3120,3122, and3124. For example, the computing devices (e.g.,3120,3122, and3124) can be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablet computers or smart phones), or other types of computing devices. For example, the computing devices (e.g.,3120,3122, and3124) can utilize the cloud computing services3110to perform computing operators (e.g., data processing, data storage, and the like).

For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C, C++, C #, Java, Perl, JavaScript, Python, Ruby, ABAP, SQL, XCode, GO, Adobe Flash, or any other suitable programming language, or, in some examples, markup languages such as html or XML, or combinations of suitable programming languages and markup languages. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.