DE102013215529B4 - Remapping jobs to check data quality - Google Patents

Abstract

Method executed by a computer to check the data quality of data of an application program (366) by a data quality management system (310), the method comprising:- executing (102) at least one job of a plurality of jobs (332) by the data quality management system, wherein the at least one job is designed to evaluate the data for compliance with one or more quality criteria,• wherein each of the jobs belongs to a job set of a plurality of job sets (334, 336, 338), the plurality the job sets comprises at least a first job set (334) and a second job set (336);• wherein each job set of the job sets represents a category of run-time behavior, the jobs contained in each job set corresponding their respective runtime behavior have been divided into the runtime behavior categories;• the execution of the jobs contained in the first job set being triggered by a message (MS), which the data quality management system receives from the application program;• wherein the execution of the jobs contained in the second job set is triggered by a scheduler (314) of the data quality management system;- the data quality management system monitors the runtime behavior of the at least one executed job in order to obtain a current runtime behavior of the job;- reclassifying the at least one monitored job by reassigning the job to the job set that represents the detected current runtime behavior.

Description

scope of the invention

The invention relates to the field of data processing and more specifically to the field of data quality testing.

background

Enterprise resource planning (ERP) systems and associated data management systems are critical to organizations across a wide range of industries and technology verticals. A significant amount of money and time is invested in preventing and eliminating erroneous data in ERP systems, since erroneous data can lead to faulty manufacturing processes and data loss, rendering extremely important data sets unusable.

Some ERP systems already come with some built-in modules to ensure data quality. External systems are often used as an alternative or in addition to the integrated modules to ensure and maintain data quality. A problem associated with using external systems to check data quality is that additional time is required to adapt the external system to the semantic structure of the business objects of the ERP system or even to the data structures used to store the business objects so that it is possible for the external system to carry out the quality checks. As a result, both performing and preparing for data quality checks associated with an ERP system can be time-consuming.

Another problem is that data quality reviews, particularly global data quality reviews that involve processing multiple business objects from one data source or from multiple distributed data sources, can be extremely time consuming. An ongoing data quality check can therefore represent a bottleneck for the performance of an ERP system. Another problem is that the runtime behavior of the quality checks can vary greatly and unpredictably depending on the evaluated data and/or the response time of external resources which contain certain parts of the ERP system data to be evaluated.

Summary of the Invention

It is an object of embodiments of the invention to provide an improved computer-implemented method, computer-readable data carrier and computer system for measuring the data quality of data of an application program, for example an ERP system, by a data quality management system (data quality management system (DQMS)). The object is solved by the features of the independent claims. Preferred embodiments are given in the dependent claims. Unless expressly stated otherwise, embodiments of the invention can be freely combined with one another.

As used herein, an "application program" is any functionally coherent piece of program logic capable of manipulating, i.e., creating, modifying and/or deleting, one or more business objects. As used herein, a "business object" (BO) refers to a data object, such as an Idoc object, specified according to a "business object schema". As used herein, the term "business object" is used to refer to instances of a business object that are specified in the business object schema. A business object schema is a description of the semantic structure of business objects and, optionally, their interrelationship. For example, a business object schema may have a description of the business object types "analysis entity" and "biological sample", where the "analysis entity" has attributes according to the schema such as "sample capacity", "status", "unit type" or the like and the business object type " "biological pattern" may have attributes such as "pattern type", "age", "patient identifier" or the like. Each instance of a BO is created according to a respective BO definition given in the BO schema.

As used herein, a "job" is a unit of work performed by a data processing system. Depending on the embodiment, a job may be a kom compiled, executable binary code, e.g. a byte code, or program code that can be evaluated. As used herein, "run-time behavior" refers to characteristics of the behavior of an executed job. As used herein, a "rule" is any piece of software code that specifies a job and can be modified by a programmer. A rule can be, for example, a Java or C++ class, functional parts of the Java or C++ class, or a PHP script or the like.

As used herein, a "data quality management system" (DQMS) is an application program, e.g. an ERP system, designed to manage data and has built-in or additional functionality to perform some quality checks on the managed data. As used herein, ensuring and maintaining "data quality" refers to the task of ensuring and maintaining the consistency of data, avoiding or removing redundant data entries, ensuring that data values are stored in a consistent data format (e.g. that all dates are stored in a consistent data format), to ensuring that the data stored is semantically or syntactically correct, or the like.

As used herein, a "transaction" is a unit of work performed by an application program on a database that is contiguously executed independently of other transactions. A transaction may include, for example, the submission of a command to a database operably linked to the application program to store or change a BO or any of its attribute values in the database, or to delete the BO or attributes from the database. Preferably, a transaction follows an "all or nothing" principle according to the ACID concept (atomic, consistent, isolated and durable).

As used herein, a "proactive check" is a data quality check performed before a transaction is committed to ensure that the transaction will not commit if the data to be transferred in the transaction is that evaluated by the proactive check quality criteria not met.

As used herein, a "reactive check" is a data quality check performed after a transaction has been committed by the application program to ensure that in the event the data transferred in the transaction does not meet the quality criteria, which were evaluated by the reactive check, this data is marked. Depending on the reactive check and the detected quality defect, the erroneous or low-quality data can be automatically removed, corrected or reported.

As used here, an 'external resource' is any data resource that is outside of the data quality management system and has some data that needs to be evaluated in addition to the data of an application program BO to check the data quality of at least some of the BOs. The external resource can be a computer system or database connected to the data quality management system over a network, e.g., the Internet or an intranet.

As used herein, a "database" refers to any type of data store, e.g., a set of file directories, XML files, or preferably a relational or columnar database.

As used herein, an extract-transfer-load (ETL) job is any job capable of delivering BO instances or portions of BO instances to the application program from one or more BOs, transforming the data into a data format that can be processed by the data quality management system, and storing the transformed data in a database operably connected to the data quality management system. In the manner used here, an ETL job that performs operations at a "BO level" is an ETL job that does not transfer the data to be transferred via an interface of the database in which the BOs are physically stored, but via a Application API queries which corresponds to BOs and corresponding attributes specified in the application program's BO schema. Consequently, an ETL job that performs operations at a "BO level" operates on the basis of the semantic and not the syntactic structure of a data object.

As used here, a "legacy" interface is an already existing interface of a software application, eg an ERP system. A legacy interface may not have been developed for the purpose of exchanging data with a DQMS, but rather, for example, for purposes unrelated to data quality checks, e.g. for the purpose of exchanging data with other applications or for the application program to perform database transactions .

An "attribute," also known as a "parameter," is a characteristic that defines or describes a particular entity. Examples of a parameter are "color", "height", "address" or the like.

In one aspect, the invention relates to a computer-executed method for checking the data quality of data from an application program using a data quality management system (DQMS). The method includes the DQMS executing at least one of a plurality of jobs. The at least one job is designed to evaluate the data for compliance with one or more quality criteria. Each of the jobs belongs to one of a plurality of job sets, the plurality of job sets including at least a first job set and a second job set. Each of the job sets represents a category of run-time behavior. The jobs contained in each job set have been classified into the run-time behavior categories according to their respective run-time behavior. The execution of the jobs contained in the first job set is triggered by a message that the data quality management system receives from the application program. The execution of the jobs contained in the second job record is triggered by a scheduling program (scheduler) of the DQMS. The method further includes the data quality management system monitoring the runtime behavior of the at least one executed job to determine a current runtime behavior of the job; and reclassifying the at least one monitored job by reassigning the job to the job set that represents the determined current runtime behavior. Preferably, the reclassification is performed automatically. According to some embodiments, the reclassification may be performed semi-automatically and may include prompting a user to consent to an automatically proposed reclassification. The features can be beneficial because, depending on the runtime behavior of a data quality checking job, the triggering mechanism that initiates execution of the job can be changed. Jobs that have been determined to be able to run in a relatively short period of time can be run in response to a message, i.e. event-driven, jobs that have different runtime behavior, e.g. a longer run time, can be run tied to a schedule will. This can be particularly advantageous in the context of a DQMS, since the scheduling of a certain type of data quality check, e.g. checks with a long execution time, checks that require external data resources, checks that evaluate a data log, etc., are then triggered by a scheduler when the processing load is light, when network traffic to the external resources is light, and/or when only a few events cause messages to be submitted that trigger the execution of the jobs in the first job set. The application program can also be considered as an external resource, e.g. if one or more BOs of the application program have to be evaluated that have not yet been imported into the data quality management system. The classification of the jobs depending on a monitored rather than a previously determined and estimated runtime behavior can be advantageous in connection with a DQMS, since the actual runtime behavior of a data quality check can depend on the type of data stored and may therefore not be predictable. Consequently, the features can provide a highly flexible DQMS capable of reclassifying data checks depending on their actual run-time behavior while also reducing operator time and effort in managing the DQMS and managing job execution because both the message-controlled jobs and the jobs controlled by the scheduler can be executed fully automatically.

According to embodiments, the message is received by the DQMS from the application program after the application program has performed a database transaction for storing the data in a first database operably connected to the application program. The message includes at least part of the data whose quality is to be evaluated, eg certain data indicating which of the attributes of a BO are to be changed in connection with the changed attribute value. The transaction is suspended until the application program receives a response from the DQMS indicating that the data meets the quality criteria evaluated by one or more of the jobs. If the response indicates that the criteria are not met, the transaction is aborted or a user is prompted to decide whether to proceed with the transaction anyway. Alternatively, the user may be provided with a means to change the Trans Re-execute action with changed transaction data. The features can be advantageous because they can enable the DQMS to trigger the execution of jobs contained in certain job sets, eg in the first job set, in a transaction-controlled and proactive manner. This means that the transaction stalls until the transaction-driven data quality checks specified in some jobs of the first job set have completed and returned a response indicating that the data meets the evaluated quality criteria. Other data quality checks, such as checks performed by the jobs in the second job set and triggered by a scheduler, are not performed in response to the transaction. Thus, the application program does not have to wait for the jobs to complete, and bottlenecks that slow down the execution of the application program can be avoided.

According to embodiments, the job sets further include a third job set. Execution of jobs included in the third job set is periodically and additionally triggered by the scheduler upon receipt of a message sent by the application program after a transaction-based change of one of the business objects assigned to the job becomes. The execution of the jobs of the second job set is regularly triggered solely by the scheduler. The scheduler can trigger the execution of the jobs in the third job set according to a different scheme (e.g. more frequently) than in the second job set. However, using a third job set is optional. Any of the jobs whose monitored execution time is less than or equal to a first time threshold is classified as a job belonging to the first job set or the third job set. Any of the jobs whose monitored execution time exceeds the first time threshold is classified as a job belonging to the second job set. The features can be beneficial as they provide highly granular management of jobs that inspect data. If a particular job that performs a data quality check and has previously been executed as a proactive job with a short execution time due to belonging to the first job set is monitored and determined as a job with a long execution time, e.g. due to a change in the underlying datasets or due to a change in the response time of some additional internal or external data resources, its triggering mechanism is inevitably changed by reclassifying the job and reassigning the job to, for example, the second job set. As a result of the remapping, the job is now not a transaction-triggered, proactive, data-checking job, but rather a scheduled, reactive, data-checking job. Consequently, the operator does not need to consider any contingencies that may affect the runtime of a job in order to specify whether the job should be run as a proactive or reactive job. Using embodiments of the invention, the operator may be more likely to rely on the automatic reclassification of jobs based on monitored runtime behavior, which may also affect the triggering mechanism (transactional or scheduled) for retrieving each job. This can be particularly beneficial in a DQMS, where a transaction-driven, proactive job that takes longer than expected can significantly slow down the application as the transaction stalls until a response is received. Depending on the embodiment, the first time threshold may be in the range of one or more minutes, preferably under 30 seconds, and preferably even under 10 seconds to avoid degrading the performance of a user interaction.

According to embodiments, all jobs included in the same job set of job sets have one or more classification features in common. Reclassifying the at least one job comprises setting a value for one or more of the classifiers and reclassifying the job according to the set values of the classifiers. The one or more classification characteristics may be a recurrence parameter indicating whether the job assigned a corresponding parameter value can be run regularly; or a total execution time of the job; or an ability of the job to access one or more external resources to evaluate the quality of the data; or any combination of two or more of the classification features. This can be advantageous since a very fine-grained classification of jobs and consequently a fine-grained control over the job-triggering mechanism can be provided. For example, the scheduler can have different job release schemes for different job sets. For example, an operator may be involved if a particular job is to be repeated or not repeated, by means of a recurrence parameter assigned to each job or by means of a corresponding rule encoding the job. Furthermore, by considering whether a job evaluates data from two or more BOs and/or evaluates data from one BO in conjunction with data to be retrieved from an external resource, a classification of jobs on the Based on "knowing" that the job could be at least potentially time consuming, for example because there is a possibility that a network connection to the external resource is slow. Consequently, any job that may run slowly, e.g. due to the evaluation of external data, can be classified in e.g. the second job set to ensure that the job is not run as a proactive data quality checking job that could slow down the application program by halting a transaction.

Depending on the embodiment, the values of the classification features can be defined by the DQMS by evaluating the program code on which the job is based, by evaluating a comment, e.g. a classification parameter, of the job and/or by evaluating the runtime behavior of the job in Is monitored in relation to the classification feature. The fact that a job accesses an external resource can be added to the job as a comment, for example, or can be determined by evaluating the job's source code. If accessing the external resource increases the execution time of the job, the job can subsequently be reclassified and, for example, moved to the second job set. According to embodiments, each of the jobs is encoded by a corresponding rule. A reclassification of the at least one job includes a reclassification of the rule encoding the job into a rule set that represents the runtime behavior category of the job set with which the job is associated. The features can be advantageous because an operator of the DQMS can easily recognize and understand which type of rule and which corresponding job are currently classified as belonging to a certain job set. The operator can also be allowed to change the rules, for example via a graphical user interface (GUI), adding or changing a few classification parameters that can be used by the DQMS as classification characteristics in addition to the monitored run-time behavior to create a job and a corresponding rule to classify.

According to embodiments, at least one other job of the plurality of jobs is designed to evaluate the quality criteria on a copy of one of the BOs in conjunction with other data, the other data being a copy of at least one other BO and/or is data derived from an external resource. The first database from which a few missing BOs or missing attribute values of BOs have to be imported in order to create or update a copy of a corresponding BO can also be considered as an external resource according to embodiments. According to embodiments, the type of jobs that perform operations on a BO in connection with other data can be automatically determined and classified into the second job set. The features can be advantageous because jobs that are at high risk of possibly becoming long-running jobs, for example because they operate on multiple BOs or external data, are considered to belong to the second job set from the start Jobs can be classified.

According to embodiments, the data whose quality is evaluated is application data and comprises one or more copies of BOs correspondingly specified by a BO schema of the application program. The application program is operably linked to a first database in which the BOs are stored. Performing the data quality checks on copies of the data rather than on the data itself can be advantageous as it increases the performance of the application program, especially when the application program and the DQMS are hosted on different computing machines.

According to embodiments, the BOs are stored in the first database. The data content of the first database is preferably copied to the second database of the DQMS via an interface at BO level. This can be advantageous as the level abstracts from the structural details of the first database, thus making the data transfer process more general and more easily adaptable to different application systems. If the internal structures of the first database should change, the DQMS and the interface used to copy the BOs to the second database are therefore not affected by the changes.

According to embodiments, the DQMS is operably connected to a second database, the second database having a copy of the application data and corresponding copies of the BOs in the second database. The copies of the BOs are stored in the second database according to a mapping, the mapping assigning attributes of the BOs of the BO schema to structure elements of the second database. The features can be beneficial because an association is a simple data structure consisting primarily of assignment. It can be based on a text file or a database table containing user-readable and editable text points. The features can be advantageous because a user can easily understand and change the nature of the mapping structure, thereby adapting the way in which the copies of the BOs are stored in the second database according to the needs of the data quality checks and the constraints imposed by the second database get saved. For example, it can speed up data quality checks if the structure of the tables and indexes of the second database used to store the copies of the BOs is adapted to the corresponding provider of the second database.

According to embodiments, the method further comprises accessing and mapping the BO schema by the DQMS to determine attributes of BOs specified in the BO schema which structural elements are mapped to the second database; and the DQMS creating one or more of the jobs as ETL jobs using the BO schema and/or the mapping. The features can be advantageous because in the event that changes should be made to the BO schema and/or the structure of the second database, only minor adjustments would have to be made by an operator of the DQMS in order to adapt the DQMS to the new situation to adjust. In essence, only the mapping may need to be changed and new ETL jobs adapted to the changes may need to be created to reload the data from the first database to the second database. Because the ETL jobs are automatically generated using the mapping and BO schema as input, the effort that the operator has to put into managing the DQMS may be very small.

According to embodiments, the plurality of jobs includes one or more ETL jobs. The ETL jobs include first ETL jobs and/or second ETL jobs and/or third ETL jobs. The method further includes: executing the first ETL jobs to initially create the second database; wherein the step may include creating a database table adapted to store copies of BOs; and/or executing the second ETL jobs to populate the second database with copies of the BOs of the first database; and/or periodically running the third ETL jobs to update the copies of the BOs. Preferably, at least some of the third ETL jobs that regularly update the second database, based on the comment attached to them that they can be executed regularly, and / or based on their monitored runtime behavior in the second job set or in the third job set filed. Because the jobs in the second job set and in the third job set are triggered by the scheduler, the ETL jobs used to update the second database can be run regularly, increasing the time required for managing the DQMS Saving time and effort and keeping the second database up to date. In some embodiments, a third ETL job may also be classified as a job belonging to the first job set, thereby ensuring that a transaction-based change to a BO triggers an update of the corresponding copy of the BO.

According to embodiments, the method comprises: receiving the message from the application program, the message indicating one of the BOs stored in the first database and changes to be made to the BO; modifying a copy of the BO, the copy being stored in the second database using the specified modifications as input; if the modified copy of the BO does not have all the data of the BO, setting a completeness parameter assigned to the modified copy to a value indicating that the copy has one or more missing attributes that the data quality management system has not yet received from the application program. For example, the message can be sent by the application program after initiating an update transaction (UPDATE) or a create transaction (CREATE) in relation to the BO.

According to embodiments, storing the copy of the BO in the second database includes marking the BO as incomplete, thereby preventing any of the quality checking jobs in the second job set from evaluating the copy of the BO.

According to preferred embodiments, the jobs in the first job set are triggered solely by receipt of a message sent following a transaction-based change of a BO assigned to the job, the jobs in the second job set are triggered solely by scheduled by the scheduler and the jobs in the third job set are scheduled by receiving a message sent after a transaction-based change of a BO assigned to the job and scheduled by the scheduler. Thus, depending on the actual triggering mechanism used, the quality checking jobs in the third job set can be used as Jobs can act proactively, thereby preventing erroneous data from being entered into the first database, or they can act reactively, thereby reporting any errors introduced into the first and second databases. This "dual use" of the same job and possibly the same rule can be advantageous since no duplicate jobs or rules need to be created in order to provide for both proactive and reactive jobs. Both functions can be provided by the same job, triggered once by the scheduler and once by a transaction. Consequently, code duplication is avoided and management of the DQMS is simplified.

According to embodiments, a reclassification of a job currently contained in the second job set to become a job of the first or third job set comprises accessing a transaction-based mapping, the transaction-based mapping including assignments of first BO attributes to for comprises BO-type specific transactions supported by a transaction-level interface of the application program; wherein an association of one or more attributes with one of the transactions in the transaction-based association indicates that values of the attributes are mandatorily transmitted in a message following a transaction-based change of a BO from a BO type having the attributes via the interface is handed over; determining whether the quality criteria evaluated by the job on attributes of a BO assigned to the job operate exclusively on one or more attributes that are mandatorily received as part of a message by the application program according to the transaction-based mapping; if the execution time of the job falls below the first processing time threshold and if the quality criteria of the job only operate on attributes whose values are obligatorily received as part of a message that triggers the execution of the job, reordering the job from the second to the first or the third job set; if the job's quality criteria also operate on attributes whose values are not received as part of a message that triggers the job's execution, failing to reclassify the job from the second to the first or third job set, even if the execution time of the job falls below the first processing time threshold. The features can be advantageous because they ensure that in the event that a job is determined to be executed quickly, the job is only classified into the first job set or the third job set if it is assured , that the message, which can trigger the execution of the job in the future, provides the job with all the data required to carry out the quality checks. Jobs that check the quality and are included in the first and/or the third job set are activated to evaluate their respective quality criteria on the copy of the BO regardless of the value of the completeness parameter, since they are only classified as jobs that belong to belong to the first or the third job set if, according to the transaction-based mapping, it is ensured that any message which triggers the execution of the job provides the job with all BO attributes evaluated by the job's quality criteria.

According to embodiments, at least some of the jobs in the second job set perform a data quality check on a copy of a BO stored in the second database in conjunction with other data. The other data can be a copy of at least one other BO and/or data derived from an external resource. The features may be advantageous because execution of any type of quality checking job contained in the second job set, which preferably includes all globally executed data quality checking jobs, can be prevented until all evaluated copies of the BOs updated and marked as complete.

According to embodiments, executing the third ETL jobs comprises: evaluating each copy of a corresponding one of the BOs, the copies being stored in the second database, to determine whether the copy has been assigned a value of a completeness parameter indicating that a or several attributes of the BO from which the copy is derived are missing attributes that the DQMS has not yet received from the application program; if a copy of a BO assigned the third ETL job has been assigned a parameter value indicating incompleteness, retrieving the one or more missing attributes from the application program; Updating the copy of the BO, thereby completing the copy with the retrieved attributes and changing the value of the copy's completeness parameter to indicate the completeness of the copy. The features can be advantageous because the execution of the third type of ETL jobs ensures that the copies of the BOs stored in the second database, in particular the copies that have undergone transaction-triggered changes, have all the data to activate specific jobs that perform global data checks (ie data checks that evaluate the quality of data from a specific copy of a BO in combination with other data). If not, the missing data, in particular missing attribute values retrieved from the first database using the third ETL jobs. For example, a transaction could trigger a change of a particular BO and subsequently a changed copy of the BO can be stored in the second database. In order to carry out certain data quality checks, it may be necessary to evaluate other attributes of the BO that have not been changed and have not been transferred to the DQMS as part of the message. Some changes may have been made to data in the first database without triggering a message submission. So to ensure that all data evaluated by a given job is also contained and up to date in the second database, the third ETL jobs can retrieve selected data from the first database, complete the copy of the BO with the retrieved data and thereby activating a few data quality checking jobs of the second job set, which are thus executed reactively to perform operations on up-to-date copies of BOs that have all the data to be evaluated.

According to embodiments, each of the jobs has been assigned a definition of a BO schema from corresponding ones of the BOs. If there is no copy of the BO specified in the message yet, the copy can be created using the assigned definition of an application BO schema of the specified BO, where the copy of the BO according to the one specified in the message (and in the transaction which triggered the delivery of the message) specified change can be changed. The method further comprises: changing a copy of a BO specified in the message according to data contained in the message; identifying the one or more jobs associated with the schema definition of the BO identified in the message, the identified jobs being included in one of the first and third job sets; performing the one or more identified jobs on the modified copy of the BO to evaluate whether the quality criteria evaluated by the jobs are met by the modified copy; and sending a response to the application program, the response indicating whether the modified copy of the first data object meets the evaluated quality criteria. The fact that the jobs perform operations at the BO level and not at the level of the transaction data received in the message can be advantageous since the DQMS is detached from the specifics of the structure of the first database; it is bound only to the semantic structure of BOs specified in the application's BO schema. This can simplify the administration of the DQMS. The jobs can be assigned by corresponding BOs, for example by means of an identifier (ID) assignment of job type IDs and BO type IDs. The message may have an ID of a BO type.

According to embodiments, the message is received via a first legacy interface of the application program, the first legacy interface being developed or used for data quality checks to be performed on transaction data, a transaction being a change or a storage of one of the BOs is in the first database, the message having transaction data of the BO. The first interface may have been used for proactive, in-application quality checks. The method further includes using a second legacy interface of the application program to retrieve data stored in the first database, to initially populate the second database via one or more of the jobs that are ETL jobs, and /or to update them. The second legacy interface may have been developed for data exchange purposes at a BO level. The ETL jobs perform operations at a BO level. The features can be advantageous because legacy interfaces that already exist in many applications and ERP systems can be used and code in the application program may not need to be rewritten. In addition, the features may allow for the provision of a DQMS capable of integrating transaction-based, proactive data quality checks as well as checks performed at BO level. For example, checks at BO level may be necessary to evaluate the data quality and consistency of a large number of BOs. Consequently, embodiments of the invention may be able to receive transaction-level data via the message containing data for creating and/or modifying a corresponding copy of a BO and for performing a transaction-driven and proactive quality check using the data quality checking jobs in the first and in the third job set as well as the scheduled, reactive, data quality checking jobs of the second and third job set within one and the same DQMS. This overcomes a problem of prior art data quality management systems, which were often limited to either purely transaction-based, proactive data quality management systems or BO-level based, global and reactive data quality management systems. Preferably, all data quality checking jobs included in any of the job sets perform operations on copies of the BOs and not directly on transactional data, which does not have the semantic structure of the corresponding BOs. For example, the copies of the BOs stored in the second database can be made using be generated by one of the ETL jobs generated depending on the semantic structure of the BOs specified in the application's BO schema, or they may be generated by the DQMS from the transaction data contained in the received message by using the application's BO schema in conjunction with the mapping. After the copy of the BO has been created or read for which a data quality checking job is to be performed, the job is performed on the copy of the BO and not on the mere transactional data in the message.

In a further aspect, the invention relates to a computer-readable data carrier which has a computer-readable program code implemented therewith which, when it is executed by a processor, causes the processor to carry out a method according to one of the preceding claims.

In a further aspect, the invention relates to a computer system which has a DQMS. The DQMS has a processing engine, a monitoring module, a classification module and a scheduler. The DQMS is designed to check the data quality of data from an application program. The processing engine is configured to perform at least one of a plurality of jobs, wherein the at least one performed job is configured to evaluate the data for compliance with one or more quality criteria. Each of the jobs belongs to one of a plurality of job sets, the plurality of job sets including at least a first job set and a second job set. Each of the job sets represents a category of run-time behavior, and the jobs contained in each job set have been classified into the run-time behavior categories according to their respective run-time behavior. The execution of the jobs contained in the first job set is triggered by a message that the data quality management system receives from the application program. The execution of the jobs contained in the second job set and in the third job set is triggered by a scheduler of the data quality management system. The monitoring module is designed to monitor the run-time behavior of at least one of the jobs being executed in order to determine a current run-time behavior of the job. The classification module is configured to automatically or semi-automatically reclassify the at least one monitored job by reassigning the job to the job set that represents the observed current runtime behavior.

According to some embodiments, the data is application data of the application program. The application data has a large number of BOs. The computer system also has the application program, a first database and a second database. The application program is operatively connected to the first database in which the BOs are stored. The second database is operably connected to the DQMS and has a copy of the application data and the BOs in the second database according to a mapping. The assignment assigns attributes of the BOs of the BO schema to structure elements of the second database. The data quality management system is designed to: access the BO schema and mapping to determine attributes of BOs specified in the BO schema which structural elements map to the second database; one or more of the jobs are generated as ETL jobs using the BO scheme and/or the assignment.

Additionally, according to some embodiments, manual or semi-manual reclassification of a portion of the jobs may be supported. According to embodiments, the reclassification follows a scheme given in the following table: To the first set of rules To the second set of rules To the third set of rules From the first ruleset not applicable Processing time >= first time threshold (automatically or manually) setting the retry parameter to a value indicating that retry is necessary From the second set of rules Processing time < first time threshold + Message triggered by a transaction has all BO attributes evaluated by the job + the job does not access an external resource not applicable Processing time < first time threshold + message triggered by a transaction has all BO attributes evaluated by the job + the job accesses an external resource From the third rule set Retry parameter has been set (manually or automatically) to a value that indicates that the job no longer needs to be run repeatedly Processing time >= first time threshold not applicable

As will be appreciated by those skilled in the art, aspects of the present invention may be implemented as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which are generic herein may be referred to as a "circuit", a "module" or a "system". Furthermore, aspects of the present invention may take the form of a computer program product residing on one or more computer readable media having the computer readable program code resident thereon. Any combination of one or more computer-readable media can be used. The computer-readable data carrier can be a computer-readable signal data carrier or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device or any suitable combination of the above. More specific examples (and the list is not exhaustive) of the computer-readable storage medium would include: an electrical connection with one or more wires, a portable computer floppy disk, a hard disk, a random access memory (RAM), a Nur Read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage unit, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by an instruction execution system, apparatus, or unit, or for use in connection with an instruction execution system, apparatus, or unit . A computer-readable signal carrier may include a transmitted data signal having computer-readable program code embodied therein, for example in baseband or as part of a carrier wave. Such a transmitted signal may take any of a variety of forms including, but not limited to, electromagnetic, optical, or any suitable combination of these forms. A computer-readable signal medium may be any computer-readable medium, other than a computer-readable storage medium, containing a program for use by, or in connection with, an instruction execution system, apparatus or device Instruction execution system, an instruction execution device or unit can transmit, forward or transport. Program code embodied on a computer readable medium may be transmitted by any suitable medium, including but not limited to wireless medium, wired medium, fiber optic cable, radio frequency (RF), etc., or any suitable combination of the foregoing .

character list

• 1 einen Ablaufplan eines Verfahrens zeigt, das eine Neuklassifizierung von Jobs aufweist,
• 2 einen Ablaufplan eines Verfahrens zeigt, das die Erzeugung von ETL-Jobs aufweist,
• 3 ein Anwendungsprogramm, z.B. ein ERP-System, und ein DQMS zeigt; und
• 4 ein paar Komponenten des DQMS ausführlicher darstellt.

In the following, preferred embodiments of the invention are described in more detail by way of example, reference only being made to the drawings, in which:

• 1 shows a flowchart of a method involving reclassification of jobs,
• 2 shows a flowchart of a method that includes the creation of ETL jobs,
• 3 shows an application program, eg an ERP system, and a DQMS; and
• 4 presents a few components of the DQMS in more detail.

Detailed description

1 shows a flowchart of a process that is used to control data quality using a data quality management system (DQMS), such as that used in 2 has been shown to flexibly and effectively evaluate. The DQMS ensures the integrity and the quality of the data of an application program, eg an ERP system, which has business objects such as "customer", "order", "department" or "employee". This is done through proactive data quality checks that avoid erroneous data being added from the start and/or reactive data quality checks that automatically identify and optionally eliminate erroneous data after most of the data is in the ERP's database system has been saved. For example, the DQMS can automatically ensure that customer address data, eg e-mail addresses, dates of birth and the like, is entered in a data format that is consistent and valid. Furthermore, data quality checks that perform operations on multiple BOs could ensure that the semantic content of different BOs does not contradict one another. For example, two different customers should not be allowed to be associated with a particular order. If more employees are assigned to a certain department of a company than the entire company employs, this is also an indication that the database of the ERP system is inconsistent. By integrating proactive and reactive data quality checks, each triggered by different mechanisms, and by adapting the respective triggering mechanism to the monitored runtime behavior of the data quality checking jobs, the DQMS is able to perform data quality checks on copies of business objects extremely effectively and without disruption the performance of the ERP system. By automatically generating ETL jobs, both the total cost of ownership of the DQMS and the lead time required to create such a DQMS are reduced.

In step 102, which is in 1 As shown, a DQMS performs at least one of a plurality of jobs. At least some of the jobs are designed to evaluate data from an application program for compliance with one or more quality criteria. The large number of jobs can also have one or more ETL jobs in order to create, initially fill and/or update a database of the DQMS that has copies of BOs of the application program. In step 104, a monitoring module of the DQMS monitors the runtime behavior of the one or more executed jobs in order to determine the current runtime behavior of the jobs in each case. The information is used by a classification module in step 106 to reclassify the one or more monitored jobs by reassigning the jobs to a job set that represents the observed run-time behavior of the job.

2 FIG. 12 shows a flowchart of a method that includes the automatic creation of ETL jobs. A portion of the ETL jobs can be reclassified depending on the monitored run-time behavior of the jobs and optionally also depending on certain classification characteristics that a user has assigned to the jobs or that have been assigned automatically and optionally also depending on a transaction-based mapping 323 are reclassified . In step 202, a job factory module of the DQMS automatically generates one or more ETL jobs in order to create, initially fill and/or update a DQMS database, with the DQMS database, also referred to here as the "second database" to which the DQMS is operatively connected and used to store copies of BOs of the application program. The generation includes an evaluation of a BO schema of the application program and an evaluation of an assignment. The assignment assigns BO types and their corresponding attributes to structure elements of the second database. The assignment can be changed by a user of the DQMS, for example via a graphical user interface. Consequently, by manually adjusting the mapping to meet constraints imposed by the second database or other factors, it is possible to easily adapt the DQMS and ETL jobs to the constraints conditions without having to manually change existing ETL jobs and without having to manually create new ETL jobs in a time-consuming manner. In step 204, the one or more ETL jobs are executed, which serve to initially create and fill the second database. This automatically creates the second database and fills it with automatically generated copies of the application program's BOs. In step 206, the DQMS can receive a message from the application program. The message is sent after the application program has performed a database transaction on a BO to be created, modified, or deleted. The message includes an indication of the BO and may also include the changes to be made to the BO, eg one or more changed attribute values or the like. The receipt of the message triggers, in step 208, the execution of quality checking jobs assigned to the BO specified in the message and included in a first or in the third job set, the first job set being transaction-initiated jobs with short execution time, which are executed only once after a transaction. The third job set includes short-running message-triggered jobs and short-running scheduler-triggered jobs that run on attributes of only a single BO (i.e., data associated with a transaction-driven message from the application program running performs a transaction-based change of the BO, must be received). The jobs checking data quality, which are executed as jobs belonging to the first job set, and message-driven jobs of the third job set are executed as proactive checks. This means that the respective quality checks are triggered by the transaction (i.e. by the receipt of the message) and that the transaction is suspended until the application program receives a response that has an evaluation result from the data quality checking jobs, which are carried out in the first and /or included in the third job set and assigned to the BO.

The DQMS sends a response to the message to the application program, the response indicating whether the one or more executed quality checking jobs of the first and/or third job set have determined that the transaction-based change, the transaction-based creation or the transaction-based deletion of this BO copy (CBO) did not meet quality requirements. Since the second database contains copies of the application program's BOs, the result of the quality checking jobs calculated for the copies of the BO's also applies to the corresponding application program's BOs.

If, at step 208, it is determined that the transaction does not violate the quality requirements evaluated by the quality checking jobs in the first and/or the third job set, the called agent initiates the application program to complete the suspended transaction to commit. In step 210, the DQMS marks the copy of the BO as incomplete if the message did not have all the attribute values that make up the copy of the BO and if the second database also does not have the missing attribute values. Missing attribute values can be determined by the DQMS by evaluating the BO schema in connection with the mapping and the second database in which the corresponding attribute values are stored in the structure elements specified in the mapping. In step 212, a scheduler of the DQMS triggers the execution of jobs that are contained in a second job set that contains long-running jobs, e.g. reactive, long-running data quality checking jobs and/or ETL jobs that Update BOs. The scheduler can also trigger the execution of jobs contained in a third job set that includes reactive, short-running data quality checking jobs. Each of the reactive data quality checking jobs and/or each of the BO update ETL jobs may be assigned to one or more of the BOs specified in the application's BO schema. If any of the BO copies are marked as incomplete, a scheduler-triggered BO update ETL job assigned to the BO determines the missing attributes and retrieves the attribute values automatically via a business object-level interface of the application program completes the copy of the BO with the retrieved attribute values and sets a value of the completeness parameter of the copy to "complete". The data quality checking jobs contained in the second job set are prevented from evaluating a copy of a BO marked as "incomplete". If the assigned BO copies are marked as "complete", the reactive jobs checking the data quality evaluate the copy of the BO and optionally other data, e.g. the data contained in other BOs or in external resources, to determine whether the Data quality of the BO violates certain quality requirements. The result of at least the quality checks performed by the quality checking jobs included in the second job set can be stored in the form of a report that can be stored in the DQMS, displayed to a user and/or sent to the application program can be handed over.

3 FIG. 3 shows a block diagram of a distributed computer system 300 having a first computer system 358 and a second computer system 302. FIG. The first computer system has a memory 360, a processor 262 and a storage medium 364. The first computer system hosts an application program 366 having a plurality of BOs BO1 through BO4 specified according to a BO schema 368 of the application. The application program has a transaction level interface 372 to perform transactions on a first database 374 operably connected to the application program. The first application program can be hosted on the first computer or on another computer system. The first computer system has one or more database tables 376 in which the BOs BO1 to BO4 and their corresponding attributes are stored. In addition, the application program 366 has an interface 370 at the business object level, also referred to here as an "application API", which is used by the ETL jobs in the DQMS 310 to retrieve data in order to retrieve the BO copies CBO1 contained in the second database to be filled and updated by CBO4 for the first time. The source code of the application program may have several commands in command blocks, each of which specifies a transaction, causes the transaction to be suspended, and causes a message to be sent to the DQMS 310 . The transaction is only committed in the first database if a response R is received from the DQMS to this message MS, which indicates that the data quality of the transaction is OK. The message may include an indication of the BO to be created, changed or deleted in the transaction and optionally also the data to be used for the change. According to other implementation variants, an intercepting module, cooperable with the application program and the first database, can intercept any transaction to be executed by the application program on the first database and stall the transaction until the response is received. The second computer system 302 has a memory 304, a processor 306 and a storage medium 308. FIG. The second computer system hosts a DQMS 310 capable of receiving BO data from the application program 366 via an interface 370 at BO level and receiving a message MS and a response R via the application program after a transaction has been executed by the application program a transaction level interface 372 to return. The DQMS 310 has a large number of modules, e.g. a job factory module 316 to automatically generate one or more ETL jobs, a monitoring module 322 to monitor the runtime behavior of a large number of jobs 332, which are processed by a processing engine 319 to be executed. The DQMS has a mapping 318, e.g. a file or a database table, which has text readable by a user, the mapping containing structural elements (e.g. tables 326, 328 and columns) of the second database 324 BOs (which have the same semantic structure and the same definition of the BO schemas like the copies of the BOs have) and assigns their attributes. A transaction-based map 323, such as a file or database entry, maps transactions supported by the transaction-level interface 372 to BO attributes, indicating whether all attributes evaluated by a job after a transaction-based Change of a BO having the attributes is triggered received from the DQMS as part of the message MS. Transaction-based mapping can also be used in conjunction with mapping 318 to instantiate a copy of the BO upon receipt of a message that includes at least a few attribute values of the BO. Furthermore, the DQMS has a copy 312 of the IO schema used by the application program 366 or is arranged to access the IO schema 312 of the application program stored in the first computer system. The BOs BO1 to BO4 are stored in the first database 374 . Corresponding copies CBO1 to CBO4 of BOs BO1 to BO4 are stored in the second database after one or more ETL jobs have been executed to create and populate the second database 324 . The tabular structure of the second database can be identical to the first database, but this is not essential. If the structures of the first database and the second database differ, the ETL jobs have to adjust the routines that store data accordingly. A combination of the application's BO schema 312, the mapping 318 and the data contained in the second database 324 provides the job factory 316 with all the information needed to automatically generate the ETL jobs and provides the processing engine 319 with sufficient information , so that it can determine whether a specific copy of a BO is complete. The jobs 332 are combined in groups into a large number of different job sets, each of which is characterized by at least one particular runtime behavior. The first job set 334 and the third job set 338 each include jobs with short execution times, eg data quality checking jobs and/or ETL jobs updating the BOs. Execution of jobs included in the first and third job sets is initiated by a transaction (ie by receiving the message). Jobs in the first job set are only executed in response to the transaction. The jobs in the second and third job sets are regularly executed and triggered by the scheduler 314. The second job set 336 includes long-running jobs, such as data quality checking jobs and/or BO update ETL jobs. A fourth job set (not shown) may have jobs, eg job 330, which are to be executed only once in order to create and/or fill the second database for the first time. The runtime behavior of any of the jobs 332 is monitored by the monitor module 322 . The classification module 320 is arranged to reclassify the jobs depending on at least the monitored runtime behavior. The data quality checking jobs contained in the first job set and, in the case where they are message driven, also the jobs in the third job set are executed proactively. That is, the transaction is suspended until the checks have finished running and a response is received indicating that the data quality is OK. If the response indicates that the data quality does not meet the evaluated quality criteria, the transaction is aborted or only executed after a user manually verifies the transaction, preventing the entry of erroneous or low-quality data into the first database. Because the data quality checking jobs contained in the first and third job sets can be executed quickly, pausing the transaction until a response is received ensures that low quality data is not stored without sacrificing performance of the application program. The jobs included in the second job set, and in the case where they are scheduled by the scheduler, also the jobs in the third job set, are executed as reactive data quality checks. This means that the jobs are executed after the application program has performed a transaction on appropriately modified copies of BOs contained in the second database. Consequently, the reactively executed jobs cannot prevent erroneous data from being saved, but they can detect errors and then report them. Since it was found that the jobs contained in the second job set are very time-consuming, e.g. because they evaluate the data of a BO in connection with one or more other BOs and/or in connection with data contained in an external resource 354 are. The external resource 354 can be connected to the second computer system via a network 356 . Because the data to be evaluated must travel across a network, data quality checks that involve data from external resources can be particularly slow, and pausing a transaction until these types of "cross-BO" or "cross-data-resource" checks are complete could do so Significantly slow down the application program. Since the data quality checks are scheduled as reactive quality checks on copies of the BOs (and not on the original BOs of the first database), the performance of the application program is not negatively affected by the execution of the jobs in the second job set.

4 put a few in 3 Illustrated components of the DQMS 310 in more detail. Certain arrows 1a) to 5) are used to illustrate dynamic aspects of the components of the DQMS. The DQMS can receive a message MS from an application program via an interface 372 on the transaction level. The message may indicate that the business object BO2 is to be changed by setting a second attribute A2 of the business object to a specific attribute value 'XY'. Based on the mapping 318 and the application schema 312, the processing engine 319 determines a corresponding copy CBO2 of the business object BO2. The processing engine can change the copy CBO2 by setting its attribute A2 to "XY". Furthermore, the processing engine may find that not all attributes of this copy CBO2 have already been received and stored in the second database. Therefore, the processing engine can mark copy CBO2 as incomplete by setting a completeness flag to the value "incomplete" 402 . As indicated by arrow 1a), the processing engine 319 may trigger short-running jobs contained in the first job set. The jobs can be short-running data quality checks 340, 342 that evaluate the data quality of the data contained in the message and/or in the pre-existing attributes of the copy CBO2 of the data object. In parallel with 1a), the processing engine 319, upon receipt of the message, can trigger the execution of jobs included in the third job set 338, which includes jobs with short execution times, as indicated by arrow 1c). In response to 1a) and 1c), the jobs 340, 342, 350 and/or 352 can be performed on the data contained in the received message and on the data already contained in the copy CBO2, as indicated by arrows 2a) and 2c). Regardless of whether the MS message has been received, the scheduler 314 regularly triggers the execution of all jobs in the first and in the third job set. For example, if A2 represents the attribute "email address" and XY is a specific customer email address, job 340 can check whether the attribute value XY contains a symbol '@' and a valid domain separated by a '.' top level of a domain range according to the pattern 'prefix@domain.topleveldomain'. Job 350 or job 352 may be responsible for determining whether the e-mail address is included in a black list of e-mail addresses. Since the blacklist can be continuously updated, regular execution of the job to determine whether any email address assigned to attribute A2 is blacklisted can ensure that no blacklisted email address in the second database is stored or managed therein and consequently not in the first database of the application program either. The execution of the jobs contained in the second job set 336 is not triggered by the receipt of the message but rather by the scheduler 314 . If the scheduler should initiate the execution of the jobs in the second set of jobs, the second jobs will not perform their respective data quality checks on the copy CBO2 since it has been marked as incomplete (see 2b: NO check!). However, the scheduler can initiate the execution of an ETL update job 348, which can be executed to retrieve the missing attribute values from the application program via the BO-level interface 370 and to complete the copy CBO2. Depending on the particular execution type and the particular run-time behavior of each ETL update job, an ETL update job can be used to retrieve missing attribute values in any of the job sets, i.e. the first job set, the second job set or the third job set to be included. Thus, retrieval of the missing attribute values and/or retrieval of BOs newly added to the first database may be from ETL jobs 341 contained in the first job set or from ETL job 348 that contained in the second job set are executed. The ETL update jobs 341 or 348 retrieve any missing data of copy CBO2 via a BO level interface 370 as indicated by arrow 3). After the missing data is retrieved, the copy CBO2 is updated with the additional data, creating the full copy CBO2'. The completeness parameter of the copy CBO2' is set to the value "complete" 404 . The next time execution of a data quality checking job included in the second job set and assigned to BO2 (and hence correspondingly CBO2') is triggered by the scheduler, the job 344, 346 will be executed as indicated by the Arrow 4) is also performed on CBO2' since the completeness parameter of CBO2' indicates completeness. Finally a report is generated as indicated by arrow 5). The report includes at least the results of the data quality checking jobs included in the second job set, but optionally also the results of the data quality checking jobs included in the first and/or the third job set. The report can be output to a user via a graphical user interface, sent back to the application program and/or stored in the storage medium 308, for example.

Claims (15)

A method executed by a computer to check the data quality of data of an application program (366) by a data quality management system (310), the method comprising: - Execution (102) of at least one job of a plurality of jobs (332) by the data quality management system, wherein the at least one job is designed to evaluate the data for compliance with one or more quality criteria, • each of the jobs belonging to a job set of a plurality of job sets (334, 336, 338), the plurality of job sets including at least a first job set (334) and a second job set (336) having; • wherein each job set of the job sets represents a category of run-time behavior, the jobs contained in each job set having been classified into the run-time behavior categories according to their respective run-time behavior; • wherein the execution of the jobs contained in the first job set is triggered by a message (MS) that the data quality management system receives from the application program; • wherein the execution of the jobs contained in the second job set is triggered by a scheduler (314) of the data quality management system; - monitoring of the runtime behavior of the at least one executed job by the data quality management system in order to determine a current runtime behavior of the job; - Reclassifying the at least one monitored job by reassigning the job to the job set that represents the current run-time behavior detected. Procedure performed by a computer claim 1 , wherein the message is received by the data quality management system from the application program after the application program has performed a database transaction for storing the data in a first database (374), the first database being operably connected to the application program, the message at least a portion of the has data whose quality is to be evaluated; wherein the transaction is suspended until the application program receives a response (R) from the data quality management system, the response indicating that the data meets the quality criteria evaluated by one or more of the jobs. A computer-executed method according to any one of Claims 1 until 2 , - the job sets further comprising a third job set (338), the execution of jobs included in the third job set being periodically triggered by the scheduler and further upon receipt of a message that is sent by the application program after a transaction-based change of one of the business objects assigned to the job, - the execution of the jobs of the second job set being periodically triggered solely by the scheduler; - wherein any one of the jobs whose execution time is less than or equal to a first time threshold is classified as a job belonging to the first job set or to the third job set; - wherein any of the jobs whose execution time exceeds the first time threshold is classified as a job belonging to the second job set. A computer-executed method according to any one of Claims 1 until 3 , wherein all jobs contained in the same one of the job sets have one or more classification features in common, wherein the reclassification of the at least one job comprises determining a value for one or more of the classification features and reclassifying the job according to the determined values of the classifiers, the one or more classifiers being selected in any combination from a group comprising: • a recurrence parameter indicating whether the job assigned a corresponding parameter value is run regularly; • a total execution time of the job; • A job's ability to access one or more external resources to evaluate the quality of the data. A computer-executed method according to any one of Claims 1 until 4 , wherein at least one other job of the plurality of jobs is designed in such a way that it evaluates quality criteria on a copy (CBO2) of one of the business objects (BO2) in connection with further data, the further data being a copy of at least one another business object and/or data derived from an external resource (354), the method comprising. - Establishing that the further job evaluates quality criteria on a copy (CBO2) of one of the business objects (BO2) in connection with further data; - as a result of the determination, classifying the job as a job belonging to the second job set. A computer-executed method according to any one of the preceding claims, wherein the data whose quality is to be checked is application data comprising one or more business objects (BO1 to BO4) specified by a business object schema (312) of the application program; the application program being operably connected to a first database (374) in which the business objects (BO1 to BO4) are stored; wherein the data quality management system is operably connected to a second database (324), the second database having a copy of the application data and corresponding copies (CBO1 to CBO4) of the business objects (BO1 to BO4) according to a mapping (318), the mapping being structural elements ( 326, 328) assigning attributes of the business objects of the business object schema (312) to the second database; the method further comprising: - Accessing the business object schema (312) and mapping (318) through the data quality management system to determine attributes (A1, A2, ..., An) of business objects specified in the business object schema, the attributes corresponding to the structure elements of the second be assigned to the database; - creation of one or more of the jobs (341, 348, 330) as ETL jobs by the data quality management system using the business object schema and/or the mapping. A computer-implemented method as claimed in any preceding claim, wherein the plurality of jobs comprises one or more ETL jobs (341, 348, 330), the ETL jobs being first ETL jobs and/or second ETL jobs and/or have third ETL jobs, the method further comprising: - executing the first ETL jobs (330) to first create the second database (324); and/or - executing the second ETL jobs to populate the second database with copies of the business objects of the first database; and or - periodically executing the third ETL jobs (348) to update one or more copies (CB01 to CBO4) of the business objects. A computer-executed method according to any one of Claims 1 until 7 , the method comprising: - receiving the message (MS) from the application program, the message specifying a business object (BO2) of the business objects (BO1 to BO4) stored in the first database and changes to be made to the business object; - modifying a copy (CBO2) of the specified business object (BO2), the copy being stored in the second database (324) using the specified modifications as input; - if the changed copy of the business object does not have all the data of the business object, setting a completeness parameter assigned to the changed copy to a value (402) indicating that the copy has one or more missing attributes that the data quality management system has not yet received from the application program Has. Procedure performed by a computer claim 8 , wherein changing the copy of the business object in the second database comprises setting a completeness parameter assigned to the copy to a value (402) indicating incompleteness, thereby preventing any of the quality criteria on the copy (CBO2) of data quality checking jobs , which are contained in the second job set (336), are evaluated, the data quality checking jobs contained in the first job set (334) and/or in the third job set (338) being contained in the Are able to evaluate their respective quality criteria on the copy of the business object, regardless of the value of the completeness parameter. A computer-executed method according to any one of Claims 7 until 9 wherein periodically executing the third ETL jobs (348) comprises: • evaluating each copy of a corresponding one of the business objects, the copies being stored in the second database, to determine whether the copy has been assigned a value (402) of a completeness parameter indicating that one or more attributes of the business object from which the copy is derived are missing attributes that the data quality management system has not yet received from the application program; • retrieving the one or more missing attributes from the application program; • Updating the copy of the business object, thereby completing the copy with the retrieved missing attributes, and changing the value (404) of the copy's completeness parameter to indicate the completeness of the copy. A computer-executed method according to any one of Claims 1 until 10 wherein each of the jobs has been assigned a definition of a business object schema of respective ones of the business objects, the method comprising: - modifying a copy (CB02) of a business object (B02) specified in the message according to data contained in the message; - identifying one or more jobs contained in the first or in the third job set and associated with the schema definition of the business object specified in the message; - executing the one or more identified jobs on the modified copy of the business object to assess whether the quality criteria evaluated by the jobs are met by the updated copy; - Sending a response (R) to the application program, the response indicating whether the modified copy (CBO2) of the first data object meets the evaluated quality criteria. A computer-executed method according to any one of Claims 1 until 11 , wherein the message is received via a first legacy interface (372) of the application program, the first legacy interface being developed or used for data quality checks to be performed on transaction data, a transaction being a modification or a storage is about one of the business objects in the first database (374), the message comprising transaction data of a business object; and further comprising: - using a second legacy interface (370) of the application program to retrieve data stored in the first database to access the second database (324) for the first time via one or more of Populate and/or update jobs that are ETL jobs, which ETL jobs perform operations at a business object level. A computer-readable data carrier (308) having computer-readable program code implemented thereon which, when executed by a processor (306), causes the processor to perform a method according to any one of the preceding claims. Computer system (300) comprising: - a data quality management system (310) having a processing engine (319), a monitoring module (322), a classification module (320) and a scheduler (314), the quality management system being designed to monitor the data quality of data of an application program (366 ) checks; - wherein the processing engine is designed to execute at least one of a plurality of jobs (332), wherein the at least one job executed is designed to evaluate the data (CBO2) for compliance with one or more quality criteria, • each of the jobs belonging to a job set of a plurality of job sets (334, 336, 338), the plurality of job sets including at least a first job set (334) and a second job set (336) having; • wherein each job set of the job sets represents a category of run-time behavior, the jobs contained in each job set having been classified into the run-time behavior categories according to their respective run-time behavior; • wherein the execution of the jobs contained in the first job set is triggered by a message (MS) that the data quality management system receives from the application program; • the execution of the jobs contained in the second job set being triggered by the scheduler; - wherein the monitoring module is designed such that it monitors the runtime behavior of at least one of the executed jobs in order to determine a current runtime behavior of the job; - wherein the classification module is arranged to reclassify the at least one monitored job by reassigning the job to the job set that represents the determined current runtime behavior. computer system after Claim 14 , the data being application data of the application program, the application data having a multiplicity of business objects (BO1 to BO4), the computer system further having: - the application program; - a first database (374), the application program being operatively connected to the first database (374) in which the business objects are stored; - a second database (324) operably connected to the data quality management system, the second database having a copy of the application data and copies (CBO1 to CBO4) of the corresponding business objects in the second database according to a mapping (318), the mapping being structural elements assigning attributes of the business objects of the business object schema to the second database; wherein the data quality management system is arranged to: - access the business object schema (312) and the mapping to determine attributes of business objects specified in the business object schema which structural elements (326, 328) are mapped to the second database; - Generates one or more of the jobs as ETL jobs using the business object schema and/or mapping.

Images