A business can be modeled in terms of objects that make up the business and how the objects interact. Generally, business objects represent things, processes, or events that are meaningful to the conduct of the business. For example, a business object can represent inventory, invoices, customers, or sales people. A business object can also represent purchases, sales, or other types of transactions that occur when conducting business. The resultant model is usually called a business object model.
The conventional architecture of a business object model is one in which the data, business rules, and actions (operations) relating to each business object are logically and/or physically tightly coupled to the business object. For example, a business object and its associated data, business rules, and actions may be physically stored together in a file server, or logically treated as one unit. FIG. 1 illustrates one conventional way of tightly coupling business objects to their associated actions. In general, an action associated with a business object is a piece of metadata that describes how to represent an activity to a user, and how to execute the necessary logic to perform this activity. In the example illustrated in FIG. 1, business objects are stored in an enterprise data management system, such as SAP 102, SIEBEL 104, and SQL 106. Business objects may also be stored in other data management systems 108. Data management systems 102-108 provide adaptors 112, through which client applications 120 may access and use business objects and their associated actions.
The conventional way of storing business objects along with their associated data, rules, and actions has several limitations. For example, the tight coupling of business objects and their associated actions limits the expansion of functionalities associated with a business object. A user cannot conveniently associate new actions with a business object. Contrariwise, if the actions and the business objects are stored separately, a user may be able to associate actions with any business object at the user's preference. For example, actions A and B are associated with business object 1, and actions C and D are associated with business object 2. Conventionally, actions A and B are tied to with business object 1, and actions C and D are tied to business object 2. By severing the tie between actions and the business objects they are associated with, the functionalities associated with a business object can be dynamically adjusted, allowing a user to easily associate additional actions with a business object. For example, if actions A, B, C, and D are separated from business objects 1 and 2, a user may freely associate these actions with any of the business objects 1 and 2. This enables a business object to have a wider range of functionalities.
Further, in today's enterprise applications, there are many different factors that affect what a user can do with a business object. These factors include whom the user is, what kind of data the user is looking at, where the user is in the workflow, etc. These factors form the context in which the user operates the business object. Context thus is a piece of information that captures data about the environment in which the business object is used. It can be inferred from data, a user's role, application settings, etc.
Different actions may be associated with a business object in different contexts. For example, the role of a user who is using a business object affects what actions the user may perform on the business object. For a business object such as “customer,” if the user of the “customer” business object is an administrator, the actions associated with the “customer” business object may include “Edit actions,” and/or “Add actions.” These two actions give the administrator the ability to modify existing actions associated with a business object and to associate new actions with the business object. On the other hand, if a user of the “customer” business object is someone other than the administrator, the user may not be able to edit or add actions associated with the “customer” business object. Since different actions may be associated with a business object in different contexts, it is desirable to be able to inform users about the actions associated with the business object in the current context. This amounts to contextual publication of actions associated with a business object.
In summary, there is a need for a business object model that separates the business objects from their associated actions so as to enable dynamic association of the actions with the business objects. There is also a need to contextually publish actions associated with a business object. The present invention provides a computing system and a program directed to satisfying these needs.