Patent Application
20070156752
The present invention generally relates to the field of database management. More specifically, the invention relates to methods, systems, and computer program products for the realization of a generic data handling for an arbitrary number of business (sub)objects that keep data in their respective database tables.
In general, a database is a set of related data stored in a computer in an organized way. In this context, the term organized means that the data is stored in some sort of structure which simplifies access to, and maintenance of, the data. In addition, the data within a database may be further organized through the use of tables, which closely correspond to the original, logical, data definition. Further, one database table may contain the data of a certain type of business (sub)object. The business (sub)object represents a central business object in the real world, such as a purchase order. And normally, one database table contains the data of a certain business (sub)object, for example, administrative data of a sales order header, a sales order item, or a product.
To read or maintain (i.e., create/change/delete) data, the business (sub)object provides a set of Application Programming Interfaces (APIs) which represent the interface of the business (sub)object to other objects and applications. An API is the software interface to system services or software libraries. Further, an API may comprise classes, function calls, subroutine calls, descriptive tags, etc. The APIs may, for example, be used by a User Interface (UI) for the maintenance transaction for the respective business (sub)object. The APIs may also be used from any other program, such as a report to maintain data in a batch process, programs of other business objects to maintain or retrieve data within an online background process, or Business Application Programming Interfaces (BAPIs).
The following are an exemplary standard set of the APIs that a (sub)object needs and provides:
Internally, these APIs may call function modules of the following business (sub)object-specific layers:
Normally, a set of these six layers must be programmed for each business (sub)object and the database tables that store the data that comprises the (sub)object. This results in a significant increase in the required programming time.
Accordingly, there is a need for a solution that reduces the necessary number of APIs that are needed to read and maintain a database. This may be accomplished through the implementation of a set of generic APIs provided to read and maintain data sets of different database tables which are related to various business (sub)objects. Retrieved and maintained data may be kept in one generic object buffer and one generic database buffer. Further, all database specific operations and actions, such as database access, database update, data mapping and field checks, and data consistency checks may be implemented as class methods being derived from one generic abstract object services class. As a result, the object work area layer, object buffer layer, and database buffer layer may be programmed only once.
In one aspect of the present invention, a system is provided for the generic handling for an arbitrary number of business (sub)objects that keep data in their respective database tables. The system comprises a set of application program interfaces which interfaces the business (sub)object to other objects and applications; a set of (sub)object specific layers comprising function modules; one generic object buffer layer and one generic database buffer layer capable of storing and handling data sets of different data type at the same time; a registry of the (sub)objects comprising (sub)objects utilized in the implementation of the applications; and a object service class that abstractly defines all database-specific actions.
In another aspect of the present invention, a method is provided for performing a generic handling for an arbitrary number of business (sub)objects that keep data in their respective database tables. The method comprises creating a set of application program interfaces which interfaces the business (sub)object to other objects and applications; creating a set of (sub)object specific layers comprising function modules; creating one generic object buffer layer and one generic database buffer layer capable of storing and handling data sets of different data type at the same time; creating a registry of the (sub)objects comprising (sub)objects utilized in the implementation of the applications; and creating an object service class that abstractly defines all database-specific actions.
In a further aspect of the present invention, a computer-readable medium including program instructions for performing, when executed by a processor, a method for performing a generic handling for an arbitrary number of business (sub)objects that keep data in their respective database tables. The method comprises creating a set of application program interfaces which interfaces the business (sub)object to other objects and applications; creating a set of (sub)object specific layers comprising function modules; creating one generic object buffer layer and one generic database buffer layer capable of storing and handling data sets of different data type at the same time; creating a registry of the (sub)objects comprising (sub)objects utilized in the implementation of the application; and creating an object service class that abstractly defines all database-specific actions.
Additional objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and together with the description, serve to explain the principles of the invention.
Reference will now be made in detail to the invention, an examples of which are illustrated in the accompanying drawings. The implementations set forth in the following description do not represent all implementations consistent with the claimed invention. Instead, they are merely some examples consistent with certain aspects related to the invention. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
Systems and methods that provide the realization of a generic data handling for an arbitrary number of business (sub)objects that keep data in their respective database tables are described herein. An object buffer and database buffer are not implemented for each involved database table separately. Instead, only one single generic object buffer and one single generic database buffer are implemented and thus allow the storing of entries of different database tables generically.
Database table-specific operations such as data retrieval or database update are realized as methods of a singly instantiated class derived from an abstract object services class. As used herein, the term instantiated means, in an object oriented programming environment, an object of a particular class, and, more generally, includes creating an object of a specific class. As used herein, the term class means, in an object oriented programming environment, a user-defined data type that defines a collection of (sub)objects that share the same characteristics. A (sub)object is one instance of the class. The abstract object services class administers the creation of objects and ensures that each implemented class is at most instantiated one time.
An object registry is also created, which is utilized as a central repository to store all (sub)objects necessary for the implementation of the applications 110 (step 230). Subsequently, a generic object service class may be created (step 240). All database table-specific operations and actions, such as database access, database update, data mapping and field checks, and data consistency checks are implemented as class methods being derived from this generic abstract service class.
However, by utilizing the feature of generic data handling with the help of data references available in most object oriented programming languages capable of database access, such as the ABAP programming language, it is possible to build up one generic object buffer layer 322 and one generic database buffer layer 323, capable of storing and handling data sets of completely different data types at the same time. An information line within these generic buffer tables 322 and 323 comprises at first some fixed administrative fields comprising information, such as the name of the underlying database table, the name of the respective data dictionary structure and the key field(s) of the stored record(s). The key fields are utilized to access the related buffer table record. The information line may also contain a field for a generic data type, which is created at runtime with a table type data having the same database-specific structure as the information line type data. For example, the read API 311 has an input data table to specify the key fields of the needed database table entries and the maintain API 312 has an input data table to pass the key fields of records together with the related data sets to be maintained.
All database-specific actions 331 are realized as an implementation of an abstractly defined object services class 340. The methods of this abstract class are themselves defined as abstract, except for a class constructor and a method used for retrieving a specific (sub)object service instance, which for exemplary purposes, may be referred to as a ‘get_instance’ method. The ‘get_instance’ method of the object services class 340 is the only public static method of the class and must be called if the single instance of the class of a given business (sub)object's database table is needed. The class constructor may not be called outside the object services class 340, but only by the ‘get_instance’ method.
The object services class 340 has an internal table 341 containing the already instantiated object classes. If the requested object reference 330 is already contained in the internal table 341, it is retrieved and given back to the calling program. If it is not yet contained in this internal table 341, the requested object 330 is created by calling the object services class constructor method, then entered into the internal buffer table 341 of instantiated objects and given back to the calling program. Further, whenever (sub)object specific logic is needed in one of the layers 320, the abstract object services class is called to provide a buffered instance of the (sub)object specific implementation.
The foregoing description has been presented for purposes of illustration. It is not exhaustive and does not limit the invention to the precise forms or embodiments disclosed. Modifications and adaptations of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed embodiments of the invention.
Moreover, while illustrative embodiments of the invention have been described herein, the scope of the invention includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations and/or alterations as would be appreciated by those in the art based on the present disclosure. The limitations in the claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification or during the prosecution of the application, which examples are to be construed as non-exclusive. Further, the steps of the disclosed methods may be modified in any manner, including by reordering steps and/or inserting or deleting steps, without departing from the principles of the invention. It is intended, therefore, that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims and their full scope of equivalents.
