Patent Application
20090138621
Embodiments of the invention generally relate to the field of data processing system, more particularly to a way of providing centralized access to a business object of an enterprise software application.
A business object is a representation of a type of uniquely identifiable business entities described by a structural model, an internal process model, and one or more service interfaces. A business entity operates on the business objects. Examples of such business objects are “Sales Order” or “Purchase Order”. The development for the business objects is subdivided in the three phases; a design phase, a modeling phase and an implementation phase. During the design phase, the business objects are identified and named. During the modeling phase, a model editor is used to determine the structure of the business object. During the implementation phase, the service provider class uses generated proxy elements for inter business object communication. The different business objects are stores in the business object repository.
A business object typically contains one or more nodes. The nodes of the business object may be accessed by a service provider class. The service provider class provides basic functions such as create, retrieve, update, and delete on the business object and business object nodes. Typically, there would be only one service provider class that would provide access to the business object and all the business object nodes. Such a service provider class typically contains a significantly large amount of code since the service provider class has the code to access all the nodes in the business object.
For example, consider a business object that has ten nodes, and a service provider class that provides operations such as create, retrieve, update, and delete for all the ten nodes in the business object. Considering each of the operations would take at least 25 lines of code, and then the service provider class would typically have 100 lines of code for one node in the business object. For ten nodes, the service provider class would have 1000 lines of code. Maintaining a single service provider class for all the business object nodes is typically tedious and not efficient. It would be very time consuming for the developers of the service provider class to debug a problem in the service provider class with so many lines of code and if the problem is not debugged properly, the chances of a programming error being left out in the code may increase. Also, having a single service provider class that performs different operations on different nodes in different ways may not be a good object oriented design. Object oriented design recommends a modular approach in designing a solution to a problem. A modular approach such as breaking up one large service provider class into smaller service provider classes would typically decrease the problems faced in debugging. A modular approach would make it easier for the developers to debug a problem in the service provider class which is relatively smaller than one single service provider class for the business object.
The structure of a business object is defined by its nodes, their associations, their actions and the metadata. A service provider class for business object supports various consumers, such as the User Interface (UI), service interfaces and cross-business object communication.
A dependent object is a business object that becomes only viable through another business object. A dependent object represents a part of a business object that is reused by other business objects, but also provides an associated, reusable UI screen. Dependent objects are marked as such in the repository. Examples of dependent objects are business address, pricing document.
During modelling time, a dependent object association is simple to realise at the business object. At implementation time, a dependent object association results in an extensive and error-prone implementation of the business object service provider class. All requests regarding the dependent business object are passed to the business object service provider class and the business object service provider class has to delegate all the calls via the Local Client Proxy (LCP) delegation interface to the dependent object service provider class. The known method of LCP delegation is expensive and error-prone and hence this extensive LCP delegation work must be implemented in a generic way.
Disclosed is a system and a method for delegating the object requests to a service provider class. For each request received at an object, the node identity of a node of the object is retrieved from the request. Based on this retrieved node identity, an instance of an object from the service provider class factory is fetched. If the retrieved node identity is regarding a dependent object then the request is delegated to a dependent business object service provider class. An instance of a service provider class of a node is fetched from a service provider class factory based on the node identity. The request is processed at the dependent business object by accessing a method in the service provider class of the object.
Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.
Disclosed is a system and a method for delegating the object requests to a service provider class. For each request received at an object, the node identity of a node of the object is retrieved from the request. Based on this retrieved node identity, an instance of an object from the service provider class factory is fetched. If the retrieved node identity is regarding a dependent object then the request is delegated to a dependent business object service provider class. An instance of a service provider class of a node is fetched from a service provider class factory based on the node identity. The request is processed at the dependent business object by accessing a method in the service provider class of the object.
The node sales order ID 110 includes queries such as query_1115 and query_2120. Similarly, in customer business object 140, the node customer ID 150 includes query_cusid 155 and the node address 160 includes query_add 175. A query fetches data of a particular node based on a condition specified in the query. For example, in customer business object 140, query_add 175 on the node address 160 may fetch an address of a customer whose customer_ID 150 is specified in query_add 175.
The node customer ID 130 has an association 135 with customer business object 140. In a sales scenario, a sales order cannot exist without any customer assigned to the sales order. Thus, sales order business object 100 is associated with customer business object 140 and in particular, node customer ID 130 in sales order business object 100 has an association 135 with node customer ID 150 in customer business object 140.
A dependent object is a business object which can be used when embedded in another business object. For example, node address 160 in customer business object 140 is a dependent business object. An instance of the dependent business object cannot be created separately. The instance of the dependent business object can be created when the instance of the business object it is embedded in is created. The dependent business object may have zero or more embedded dependent business objects.
Query interface pattern 240 includes core service method query 240. Access interface pattern 245 includes core service methods such as create 210, modify 215, retrieve 220, retrieve by association 225, retrieve root node ID 230, and retrieve properties 235. A description of the methods of the service provider class 200 is given below:
The methods of the service provider class 200 described above contain one or more input parameters and zero or more output parameters. Service provider class 200 may be registered for a node in the business object. In one embodiment, there may be one service provider class registered for every node, query, and association in the business object. In another embodiment, a service provider class may be registered for only few nodes in the business object. The rest of the nodes in the business object may be accessed via a default service provider class.
Service provider class registry 520 has a table 525 that contains registrations of service provider classes for the nodes. Table 525 contains a list of node IDs 530 and corresponding service provider class ID 535 of the service provider classes registered for the node IDs 530. The node which does not have a service provider class 200 registered may be accessed by a default service provider class. The default service provider class provides methods to access the node of the business object which does not have the service provider class registered in the service provider class registry 520.
Factory framework 515 receives node ID from business object 510 and checks service provider class registry 520 if service provider class 200 is registered for node ID. If service provider class 200 is registered for node ID, then factory framework 515 fetches the service provider class ID of the service provider class 200 from service provider class registry 520. Factory framework 515 then fetches an instance of the service provider class 550 from service provider class factory 540 based on service provider class ID. If there is no service provider class 200 registered for node ID, then factory framework 515 fetches an instance of a default service provider class 550 from the service provider class factory 540. The service provider class factory 540 fetches the instance of service provider class from an instance pool 545 where an instance of service provider class is stored. If the instance of the service provider class 550 does not exist in instance pool 545, then service provider class factory 540 creates an instance of the service provider class 550 in instance pool 545. The instance of the service provider class 550 has methods that include query 205, create 210, modify 215, retrieve 220, retrieve by association 225, retrieve root node ID 230 and retrieve properties 235 as shown in
Other embodiments of the invention may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
Elements of the invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, Flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions.
Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. The underlying principles of the invention may be employed using a virtually unlimited number of different types of input data and associated actions.
Accordingly, the scope and spirit of the invention should be judged in terms of the claims and equivalents which follow.
