CROSS REFERENCE TO RELATED APPLICATIONS
- Top of Page
1. Field of the Invention
The present invention relates to resource management, and in particular, to resource management using business object types.
2. Description of the Related Art
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Scheduling employees to work at a business location is often automated. When multiple employees are available to work at multiple locations, the scheduling system may perform load balancing to allocate similar coverage of employees to all the locations. An example of this type of system is described in U.S. Application Pub. No. 2005/0137927.
Additionally, scheduling the time of individual employees is often automated. When an employee is available within a larger time period, the employee's time may be scheduled into shorter time periods. The scheduling system may receive a first request providing the availability within the larger time period, may receive a second request providing a desired availability within a shorter time period, and may then perform scheduling to take both these requests into account when scheduling the employee's time. An example of this type of system is described in U.S. Application Pub. No. 2005/0222884.
- Top of Page
Given the above background, there is a need to assign resources to projects in ways other than when the projects are all stored by the same homogeneous computing environment.
One embodiment includes a method of relating resources and business objects. The method includes storing business objects by a first application server and a second application server, where the first application server is configured to access a business object of a first business object type and the second application server is configured not to access the business object of the first business object type. The method further includes storing resources, and relationships between the business objects and the resources. The method further includes generating an object view in which, for a selected business object, a first relationship is editable according to a first user input, where the first relationship relates the selected business object to one of the resources. The method further includes generating a resource view in which, for a selected resource, at least one associated business object and at least one associated relationship are viewable, where the at least one associated relationship relates the selected resource and the at least one associated business object. In this manner, resources may be scheduled despite the underlying applications not being able to access all the types of business objects.
The user input may add (or remove) resources (from a selected business object) or business objects (from a selected resource) by editing the relationships. The relationships may be edited by editing their relationship attributes. The application servers may be heterogeneous.
A system may perform the above method. The system may include a number of application servers that are configured to perform steps of the method, e.g., as one or more hardware servers executing one or more computer programs.
A non-transitory computer readable medium may store instructions that correspond to the above method. The instructions may be arranged as subprograms or components that may be executed by one or more application servers (which may be implemented by one or more hardware servers).
An embodiment may have one or more of the following features. First, it allows for resource assignment in a heterogeneous environment. (Otherwise the heterogeneous components would each need to be modified to work with each other heterogeneous component.)
Second, it allows for resource scheduling for newly-added applications. When a new type of business object is added, the tools used to create the new application may be the same tools used to access that new business object type in the scheduling program. (Otherwise the newly-added application may have a new type of business object that requires reprogramming of the scheduling application before the scheduling application can access the new type of business object; or reports from both applications must be generated and then combined together.) For example, Company X has a project management system (for tracking projects) and a customer relationship management system (for tracking sales orders) that are staffed from the same set of employees; an embodiment may be used to generate a consistent view of the assigned employees to both sales orders and projects.
Third, it allows for one consistent view on resources in a heterogeneous environment. (Otherwise each heterogeneous application would need to be modified according to each other heterogeneous application in order to pull the resource data from the other heterogeneous applications.)
Fourth it easily allows extension to new entities to assign (“schedule”) resource against. The benefit of this is greater flexibility for workforce dominated companies (usually service providers) working in heterogeneous lines of business.
The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
- Top of Page
FIG. 1 is a block diagram of a system for relating resources and business objects, according to an embodiment.
FIG. 2 is a block diagram of a three tier architecture system that may be used to implement an embodiment.
FIG. 3 is flowchart of a method of relating resources and business objects, according to an embodiment.
FIG. 4 shows an example of an object view, according to an embodiment.
FIG. 5 shows an example of a resource view, according to an embodiment.
FIG. 6 is a block diagram of an example computer system and network for implementing embodiments.
- Top of Page
Described herein are techniques for relating resources and business objects in an enterprise data processing environment. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
In this document, various methods, processes and procedures are detailed. Although particular steps may be described in a certain order, such order is mainly for convenience and clarity. A particular step may be repeated more than once, may occur before or after other steps (even if those steps are otherwise described in another order), and may occur in parallel with other steps. A second step is required to follow a first step only when the first step must be completed before the second step is begun. Such a situation will be specifically pointed out when not clear from the context. A particular step may be omitted; a particular step is required only when its omission would materially impact another step.
In this document, the terms “and”, “or” and “and/or” are used. Such terms are to be read as having the same meaning; that is, inclusively. For example, “A and B” may mean at least the following: “both A and B”, “only A”, “only B”, “at least both A and B”. As another example, “A or B” may mean at least the following: “only A”, “only B”, “both A and B”, “at least both A and B”. When an exclusive-or is intended, such will be specifically noted (e.g., “either A or B”, “at most one of A and B”).
In this document, various computer-implemented methods, processes and procedures are described. It is to be understood that the various actions (receiving, storing, sending, communicating, displaying, etc.) are performed by a hardware device, even if the action may be authorized, initiated or triggered by a user, or even if the hardware device is controlled by a computer program, software, firmware, etc. Further, it is to be understood that the hardware device is operating on data, even if the data may represent concepts or real-world objects, thus the explicit labeling as “data” as such is omitted. For example, when the hardware device is described as “storing a record”, it is to be understood that the hardware device is storing data that represents the record.