Patent Publication Number: US-8122063-B2

Title: Using status models in a computer system

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation-in-part of U.S. application Ser. No. 11/477,787, filed Jun. 30, 2006 and titled SYSTEM AND METHOD FOR OBJECT STATE MANAGEMENT. 
    
    
     TECHNICAL FIELD 
     This description relates to techniques for controlling transaction processing that is performed by computer systems. 
     BACKGROUND 
     Software systems and components may be developed using object technology, and the operation of these systems and components may occur through methods that are performed on and/or by objects. An object&#39;s state may be said to include the combination of current attribute values of the object at a particular point in time. The execution of a method may change attribute values of an object, which, in turn, may lead to a new state of the object. Sometimes the current state of the object or computing environment may be an important factor in determining whether a particular action is allowed to be performed or not. 
     One approach to ensuring that an object performs an action only when allowed by a particular state of the object is programming such requirements into the object itself. Another approach is to rely on the programming of other unrelated objects—that are called by the object to implement all or part of the action—to enforce such requirements. 
     For example, software that controls an assembly line in a manufacturing plant should be programmed so that a “stop” action should not be performed on the assembly line if the assembly line current is not moving (e.g., as represented by the state of an object representing the assembly line). 
     Under the first scenario described above, a programmer of the object may directly code this requirement into the object itself, so that when the object receives a “stop” action request, the object checks its own status attributes to make sure that the assembly line is currently moving before allowing the “stop” action to be processed. However, as software projects become larger and more complex, it may become increasingly burdensome for programmers to understand, identify and account for all constraints that are based on the state of an object. 
     Under the second scenario described above, the programmer of the object may rely on other programming to enforce this requirement. In this example, the assembly line object (which may or may not have its own status attributes regarding the movement of the assembly line) would receive the “stop” active request, and call another unrelated object to implement all or part of the “stop” action. The other object would then check its own status attributes to make sure that the assembly line is currently moving before allowing the “stop” action to be processed, but its determination would be independent of the state of the assembly line object. 
     SUMMARY 
     In one general aspect, actions in a computer-based process are controlled. A status schema model is defined at design-time, stored in computer-readable medium and includes preconditions for performing actions. Each precondition identifies how a status affects whether an action is to be allowed to be performed at runtime by a data object node instance having the status. A status schema instance is created for a particular data object node instance that is used in a computer-based process. The status schema instance corresponds to the status schema model. The data object node instance includes values for variables and methods capable of being performed by the data object node instance. Based on the status schema instance, status of the data object node instance is monitored to determine whether a particular action is allowed to be performed by the data object node instance. In response to a determination that the particular action is allowed, the particular action is enabled to be executed. 
     Implementations may include one or more of the following features. For example, the status schema model may correspond to a data object node, and the data object node instance may correspond to the data object node. The status of the data object node instance may include a status variable and a particular status value where the particular status value is one of a set of possible status values for the status variable. The variables of the data object node instance may include one or more status variables where a status variable is associated with a set of possible status values for the status variable. The status may represent a stage in the computer-based process. 
     The particular action may correspond to a method of the data object node instance. The particular action may correspond to at least one status value in the set of possible status values for the status variable. Creating the status schema instance for the particular data object node instance may include setting the status variable of the status schema instance to a corresponding value of the status variable for the data object node instance. Enabling the particular action may include initiating execution of the particular action. 
     A runtime processing component may monitor, based on the status schema instance, the status of the data object node instance to determine whether the particular action is allowed to be performed by the data object node instance. A runtime status management component may create the status schema instance for the particular data object node instance being used in the computer-based process. The runtime processing component may enable the particular action to be executed conditioned upon a determination that the particular action is allowed. 
     In another general aspect, actions in a computer-based process are controlled by using a status schema model repository for status schema models, stored in a computer-readable medium. Each status schema model corresponds to a data object node and includes preconditions for performing actions. A precondition identifies how a status affects whether an action is to be allowed to be performed at runtime by a data object node instance having the status. 
     Implementations may include one or more of the features noted above. 
     Implementations of any of the techniques described above may include a method or process, an apparatus or system, or computer software on a computer-accessible medium. The details of particular implementations are set forth in the accompanying drawings and description below. Other features will be apparent from the following description, including the drawings, and the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIGS. 1 and 3  are block diagrams of computer systems that use a constraint-based model to control data processing. 
         FIG. 2  is a block diagram of runtime sales order nodes instances. 
         FIG. 4  is a block diagram of a status and action model architecture. 
         FIGS. 5A and 5B  are block diagrams that depict examples of an approval status schema. 
         FIG. 6  is a block diagram of an example status schema model for a sales order object node. 
         FIG. 7  is a block diagram of an architecture that includes a status and action model and a business object model. 
         FIG. 8  is a block diagram of a conceptualized data structure of a status schema model. 
         FIG. 9  is a flow chart of an example process for designing and using a status schema model. 
         FIG. 10  is a flow chart of an example process for modeling a process in a status and action modeling computer system. 
         FIG. 11  is a flow chart of an example process for transforming a status schema model for application to runtime instances of a data object node. 
         FIG. 12  is a flow chart of an example process for applying a status schema model to an instance of a corresponding data object node instance. 
         FIG. 13  is a block diagram of an example runtime architecture for status management. 
         FIG. 14  is a block diagram of a computer system. 
     
    
    
     Like reference symbols in the various drawings indicate like elements. 
     DETAILED DESCRIPTION 
     Techniques are provided that allow for the management of the state of an object node in a less burdensome and more coherent manner. There are various ways of implementing objects in software applications. The term “object node” is used in this description to refer to either an overall object or particular elements of an object (e.g., particular methods and/or attributes associated with the object). When an object node is used in a business software application, the object node may be referred to as a business object node or an application object node. The term “data object node” also may be used to refer to an object node. A data object node may refer to a business object node, for example, that includes variables and methods related to a business entity, such as a document (e.g., a sales order, a purchase order or an invoice), an organization (e.g., such as a business partner, supplier or customer) or a person (e.g., such as an employee or a customer). A data object node also may refer to a processing object node, such as an object node that processing information for an entity being processed in a workflow. 
       FIG. 1  shows a system  100  of networked computers that uses a constraint-based model to control data processing. In general, the system  100  uses a status schema instance of a status schema model to determine whether an action is permitted to be performed by a data object node. 
     More particularly, the system  100  of networked computers includes a computer system  10  having a runtime processing component  120 , a runtime status management component  130  and a runtime status repository  140 . The computer system  110  may be a general-purpose computer or a special-purpose computer. 
     The runtime processing component  120  includes various data object nodes (here, sales order object node instance  120 A, a delivery object node instance  120 B and an invoice object node instance  120 C). Each of the object node instances  120 A,  120 B and  120 C is a collection of data variables and methods that may be performed by the data object node instance. In this example, each instance  120 A- 120 C has standard variables, each of which corresponds to a characteristic or attribute of the object node instance. For example, a sales order object node instance  120 A may include, for example, standard variables identifying a customer to whom the sale was made and the date of the sale. Each instance  120 A- 120 C also has one or more status variables. A status variable indicates a status of the data object node instance. For example, a status variable may indicate the status of a data object node instance relative to a stage of processing. In a more particular example, a status variable may indicate whether a sales order object node instance  120  has been approved. Each instance  120 A- 120 C also has methods that may be executed by the object node instance. As shown, the sales order object node instance  120 A has standard variables  121 A, status variables  122 A and methods  123 A. The object node instances  120 B and  120 C also have standard variables, status variables and methods (not shown). 
     As shown here, the object node instances  120 A,  120 B and  120 C each correspond to a principal entity represented in the computer system  110 . Each of the example object node instances  120 A- 120 C relate to a document used in a business process—here, respectively, the instances correspond to documents used in the business process of delivering and invoicing merchandise sold to a customer. Another example of a data object node instance include information about a customer, an employee, a product, and a business partner (such as a supplier). A data object node instance may be stored as one or more rows in a relational database table (or tables), a persistent object instance in an object-oriented database, data in one or more extensible mark-up language (XML) files, or one or more records in a data file. 
     In some implementations, an object node instance may be related to other object node instances. In one example, a sales order may include multiple sales order nodes, such as a root node identifying information that applies to the sales order (such as information that identifies the customer and the date the sales order was placed) and one or more item nodes identifying information related to each type of item ordered (such as an item number, quantity ordered, price of each item and cost of items ordered). In another example, each of the sales order object node instance  120 A, delivery object node instance  120 B and invoice object node instance  120 C may relate to a sale of merchandise to a customer. As such, each of object node instances  120 A- 120 C may be said to relate to one another. 
       FIG. 2  illustrates an example of runtime sales order node instances  200 , which collectively represent a sales order by a customer (i.e., “ABC Bicycle Store”) for products (i.e., bicycles). In this example, a sales order root instance  210  is related to sales order item instances  220 A- 220 D. The sales order root instance  210  may be referred to as the parent node of each of the sales order item instances  220 A- 220 D. In turn, each of the sales order item instances  220 A- 220 D may be said to be a child node of the sales order root instance  210 . Each of the sales order item instances  220 A- 220 D also may be referred to as a sibling node of the other sales order item instances  220 A- 220 D. 
     More particularly, the sales order root instance  210  has a customer  211  variable with a value “ABC Bicycle Store” and an order date  212  variable with a value of “May 1, 2006.” Each variable  211  and  212  may be referred to as a standard variable or characteristic of the sales order root. The sales order root  210  has an availability status variable  215  having a value  216  of NOT CONFIRMED. As described more fully later, the availability status value of  216  is a reflection of the available status values of the sales order item instances  220 A- 220 D. 
     Each of the sales order item instances  220 A- 220 D have a standard variable  222 A- 222 D with a value describing a type of bicycle and a corresponding quantity purchased. For example, sales order item instance  220 A has a standard variable  222 A identifying “6 adult blue bicycles” as the type and quantity of a bicycle purchased. 
     Each of the sales order item instances  220 A- 220 D also has an availability status variable  225 A- 225 D having a value  226 A- 226 D that identifies the availability status of the bicycles identified in the standard variable  225 A- 225 D. For example, the sales order item  220 A has an availability status value  226 A of UNKNOWN for six adult blue bicycles; the sales order item  220 B has an availability status value  226 B of PARTIALLY CONFIRMED for five child red bicycles; the sales order item  220 C has an availability status value  226 C of CONFIRMED for ten child blue bicycles; and the sales order item  220 D has an availability status value of NOT CONFIRMED for two child green bicycles. 
     Referring again to  FIG. 1 , the status management runtime  130  tracks status information associated with object node instances  120 A- 120 C in the status repository  140  and makes determinations, on behalf of the object node instances, as to whether actions are allowed to be performed based at least in part on the status information associated with the object nodes in the status repository. 
     When one of the object node instances  120 A,  120 B or  120 C of the runtime processing component  120  receives a request to perform an action, the object node instance  120 A,  120 B or  120 C sends a request to the status management runtime component  130  to determine whether the action is allowed to be performed. The status management runtime component  130  checks the runtime status repository  140  to determine whether the status information associated with the object node instance  120 A,  120 B or  120 C permits the action to be performed. The status information associated with the object node instance may include the values of one or more status variables associated with the object node instance and one or more constraints identifying what actions may be allowed to be performed based at least in part on the values of the one or more status variables. The status information also may include one or more constraints identifying what status variable values may be allowed to be set following the performance of an action. The status information may include one or more constraints identifying what status variable values may be changed based on a change in one or more other status variable values. 
     When the outcome of the determination specifies that the action is not allowed, the status management runtime component  130  sends a response to the object node instance  120 A,  120 B or  120 C indicating that the action is not allowed to be performed, and the object node instance  120 A,  120 B or  120 C processes the negative response by inhibiting the action from being performed. One example of inhibiting the action is to send an error message to the source that requested the action to be performed. Another example is to simply ignore the action request and continue on as if the action had never been requested. Yet another example is forwarding the negative response to another application for processing. 
     On the other hand, when the outcome of the determination specifies that the action is allowed, the status management runtime component  130  sends a response to the object node instance  120 A,  120 B or  120 C indicating that the action is allowed to be performed, and the object node instance  120 A,  120 B or  120 C processes the positive response. One example of processing a positive response is performing the action. Another example of processing the possible response is by forwarding the response to another application for processing. 
     In some implementations, a list of requested actions may be sent to an object node instance  120 A,  120 B or  120 C for determinations of the requested actions and subsequently returns the positive and/or negative responses to the client application for further processing. 
     Status variable value information associated with an object node instance may be previously stored in the status repository  140  or passed by the object node instance along with the check action request. 
     The status information also may be based on a status schema instance derived from a design-time model. The status schema instance may include relevant status variables and associated status values, actions and conditions modeled for corresponding object nodes and stored in the status repository  140 . For example, at design-time, the status schema for an object node, may define constraints for actions by describing which actions are allowed for which status values, and define which status values may be or are set after the completion of the action. At runtime, a status schema instance may be loaded from the status repository  140  by the status management runtime  130  with the current values of the status variables for object node instances. 
     The runtime processing component  120  illustrates a service-based approach in which services are provided by object node instances  120 A- 120 C to other computing entities over the network  125 . Examples of the network  125  include the Internet, wide area networks (WANs), local area networks (LANs), or any other wired or wireless network. As illustrated in this example, services are offered to an online client system  125 A and a mobile client system  125 B, which each may be a general-purpose computer that is capable of operating as a client of the runtime processing component (such as a desktop personal computer, a workstation, or a laptop computer running an application program), or a more special-purpose computer (such as a device specifically programmed to operate as a client of a particular application program). For brevity,  FIG. 1  illustrates only a single online client system  125 A and a single mobile client system  125 B. However, actual implementations may include many such computer systems. 
     The architecture of system  100  illustrates a service-oriented architecture, which defines objects and relationships of objects to provide services usable by other computing systems or components. The service-oriented architecture (or portions thereof) may be developed and licensed (or sold) by a commercial software developer. The service-oriented architecture  100  is one example of a computing environment in which the described principles, concepts and techniques may be implemented. The techniques apply to other architectures and system designs, as would be understood by a person skilled in the art. The service-oriented architecture is being described to illustrate an example to help articulate the described techniques. 
     In another example, the described techniques may be implemented in a software application or software components that are developed and licensed (or sold) by a commercial software developer. Examples of commercial software applications include customer relationship management or sales applications, supply chain management applications, financial management applications, or human resources management applications. The applications may work in conjunction with one or more other types of computer applications to form an integrated enterprise information technology (IT) solution for a business enterprise. In some architectures, for example, a service-oriented architecture, the described techniques may be implemented in data objects and as software service components. 
     The architecture shown in  FIG. 1  may allow for a less burdensome and more coherent state management of an object node instance by providing a status management runtime component  130 . The runtime processing component  120  in some implementations may correspond to an application runtime component. Although the status management runtime component  130  is depicted as a separate runtime component from the runtime processing component  120 , the status management runtime component  130  need not necessarily be a separate component. In one example, the status management runtime component  130  may be part of the runtime processing component  120 . In another example, some or all of the functions described with respect to the status management runtime component  130  may be performed by the runtime processing component  120 . 
     As a result of the architecture shown in  FIG. 1 , object node programmers need only to code calls to the status management runtime  130  to make sure an action is allowed to be performed, instead of having to understand, identify and account for all constraints that are based on the status of an object node instance. Additionally, by having object node status information represented in the status repository  140 , the status management runtime  130  is able to use this information in a coherent manner as to not make any determination independent of an object node instance&#39;s state. 
     As described previously, a data object node at design-time may have multiple status variables, each status variable has a predetermined, mutually exclusive set of possible status values. At runtime, each status variable of a data object node instance has one of the possible status values, which may be referred to as the current value of the status variable. The current value of all status variables of a data object node instance may be referred to as the “current status” of the data object node instance. Alternatively, in some implementations, the current value of all status variables of a data object node instance may be referred to as the “state” of the data object node instance. In this description, the term “state” of the data object node instance generally is used to refer to the current value of all variables (both status variables and standard variables), whereas the term “current status” of the data object node instance generally is used to refer to the current value of all status variables (and not including the current value of standard variables). 
       FIG. 3  shows another example of a system  300  of networked computers that uses a constraint-based model to control processing of data object node instances. The system  300 , like the system  100  of  FIG. 1 , includes a computer system  10  having a runtime processing component  120 , a status management runtime component  130 , and a status repository  140 . In this example, the computer system  110  may be referred to as a processing computer system  110 . 
     The system  300  also includes a modeling computer system  350  capable of generating and presenting on a display device (or devices) a modeling user interface  355  for defining status schema models  360  for data object nodes. A data object node corresponds to one or more data object node instances, each of which is capable of being processed by the processing computer system  110 . In general, once the status schema models  360  have been defined and, perhaps, simulated on the modeling computer system, the status schema models  360  are transformed into a format usable by the status management runtime component  130  and stored in the runtime status repository  140 . As described previously, the status management runtime component  130  uses information in the runtime status repository  140  to determine whether the status information associated with a data object node instance permits a particular action to be performed by the data object node instance. As such, the status schema models are created in the modeling environment (here, represented by the modeling computer system) and used without modification by the runtime environment (here, represented by the processing computer system). 
     More particularly, the modeling user interface  355  enables a user at design-time to define a status schema model for a data object node. A data object node also is associated with a data model defining standard variables, status variables and methods for the data object node, and, therefore, for data object node instances generated for the data object node. 
     In general, a status schema model identifies constraints for performing an action of a data object node. More particularly, the status schema models  360  include a status schema model  360 A for data object node A, a status schema model  360 B for data object node B, and a status schema model  360 C for data object node C. As illustrated by the status schema model  360 A, each status schema model  360 A,  360 B or  360 C, includes status variables  362 A (and for each status variable, a set of predefined permissible values) and actions  363 A. As shown, each status schema model includes preconditions (such as preconditions  364 A for status schema model  360 A). A precondition identifies how a status affects whether an action is to be performed at runtime by a data object node instance having the status. For example, a precondition may identify a condition that must be fulfilled for an action to be performed by a data object node instance corresponding to the data object node to which the status schema model corresponds. An action (such as one of actions  363 A) represents a process step that can be performed on an instance of a data object node for which the status schema model corresponds. A precondition (such as one of preconditions  364 A) is a type of constraint that generally relates an action with a status value of one of the status variables  362 A. A precondition may enable or inhibit an action. At runtime, the preconditions of an action are evaluated to determine whether the action is permitted to be performed on or by the data object node instance to which the status schema model relates. 
     Another type of constraint which may be used in some status schema models is a status transition. A status transition represents a status value of a status variable that is permitted to be set when a particular action is performed on a data object node instance corresponding to the status schema model of the data object node. The architecture  300  optionally includes status transitions  365 A for status schema model  360 A for object node A. 
     Each of status schema models  360 B and  360 C also include status variables, actions, and preconditions for actions (not shown). Each of status schema models  360 B and  360 C may include status transitions and derivations, described below (not shown). 
     The modeling user interface  355  also may support inter-schema modeling. For example, a status schema model for a data object node may include inter-schema modeling elements (such as derivations  366 A associated with status schema model  360 A). In another example, inter-schema modeling elements may be stored in a separate inter-schema model  370 . Inter-schema modeling, for example, may model how a status variable in a status schema model of one data object node may influence a status variable in a status schema model of another data object node. 
     Two examples of such inter-schema processes are population and aggregation derivations, as described more fully later. In general, a population derivation “pushes” or copies a status value of a status variable from a parent data object node to corresponding status variables in one or more child data object nodes of the parent data object node. An aggregation derivation determines an appropriate status value of a status variable for a parent data object node based on status values of the corresponding status variable in one or more child data object nodes. The architecture  300  optionally includes derivations  366 A, which may include population derivations and aggregation derivations, for status schema model  360 A for object node A. 
     The derivations  366 A in the status schema model  360 A for object node A also may include one or more lifecycle (or overall) status derivations for object node A. For example, when there are several status variables in the status schema model for object node A, the model may include a status variable that reflects an overall processing status of object node A. Such an overall status variable generally is not used to determine whether a particular action is permitted to be performed on an instance of the object node, although some implementations may use the status value of the lifecycle status variable to do so. 
     In many cases, the modeling computer system  350  is used by software developers or programmers who are designing and implementing status schema models which correspond to data object nodes. The status schema models and data object nodes may be used, for example, to enable a service-oriented architecture for processing data that is applicable to many business enterprises. In such a case, data object nodes along with the runtime status repository that corresponds to status schema models for the data object nodes may be sold (or licensed) to many business enterprises. Thus, the processing computer system  110  may be operated and used by a different business enterprise than the business enterprise that operates and uses the modeling computer system  350 . 
     In some implementations, the modeling computer system  350  may be used to extend, enhance or otherwise add to the status schema models corresponding to the data object nodes used in the processing computer system  110 . In such a context, the modeling computer system  350  may be used by a business enterprise other than the commercial software developer who designed and implemented data object nodes or the runtime status repository. The modeling computer system  350 , for example, may be operated by a software integrator or consulting organization that is implementing or enhancing the runtime processing component for a particular, or group of, business enterprises. In a more particular example, an initial runtime status repository may be generated from a first modeling computer system based on status schema models provided by the commercial software development organization that designed, implemented and sold the data object nodes used by the runtime processing component. A consulting organization may use a second modeling computer system to extend the status schema models in permitted ways for use in a particular industry or by a particular business enterprise. 
     Because status schema models are defined for a data object node, the models enable the definitions of business processing with a fine granularity, which may help enable or improve process flexibility and reuse of the status schema models. Also, because the status schema models reflect business logic used in runtime processes, the status schema models promote visibility and transparency of business processes, which, in turn, may reduce application development errors and programming side-effects. Also, the status schema models may result in computer-supported business processes that more accurately reflect real-world business processes, which, in turn, may help to promote the development and proper use of more accurate and easier-to-understand computer systems. 
       FIG. 4  depicts an example architecture  400  for a status and action model. The architecture  400  illustrates the components of one example of a status and action model in relationship to other computer system components, such as data object nodes. The component architecture  400  includes data object components  410  and status and action model components  430 . In general, the component architecture  400  illustrates how a data object is transformed over time, and how the data object transformation is reflected in the status and action model. 
     The status and action model is an abstraction and a simplified image of real-world processes. The status and action model uses graphical representations as a means of presenting relevant aspects of the corresponding real-world processes. Here, the status and action model components  430  illustrate data objects and the execution of methods performed on the data objects during the operation of the computer system using the data objects. Stated differently, the status and action model components  430  illustrate the processing of a data object by a computer system, which generally corresponds to a real-world business process. 
     More particularly, while executing on a computer system, methods (or other types of computer-executable processes) change attribute values of data object nodes. The state of a data object node may be viewed as the combination of current attribute values of a data object node at a particular point in time. When an attribute value of a data object node is changed, the changing of the attribute value leads to a new state of the data object node. An attribute may be referred to as a variable, and an attribute value may be referred to as a value of a variable. 
     As shown in the component architecture  400 , a data object node includes standard variables  418  and status variables  435 . In this example, standard variables  418  relate to the data object itself and do not include status information, which is reflected in status variables  435 . The standard variables are shown as part of the data object model  410  that corresponds to the status and action model component  430 , whereas the status variables  435  of the data object node  415  are shown as part of the status and action model  430 . 
     The component architecture  400  represents the transformation of a particular data object node from one state (here, called the first state  415 ) to another state (here, called the second state)  420 , as shown in the data object model component  410 . The status and action model component  430  depicts that business process step associated with the transformation of the data object node from the first state  415  to the second state  420 . 
     As shown in the status and action model component  430 , a particular action  450  results in the transformation of the status variables  435  to the transformed status variables  440 . The current values of status variables (such as depicted in status variables  435  and  440 ) represents the state or stage of a process related to the data object node. More particularly, the current values of status variables  435  indicate that the data object node that is the subject of the component architecture model  400  represents the data object node being in the ORDER CONFIRMATION stage of processing, as indicated by stage of processing  455 . Similarly, the current values of the status variables  440  of the data object node indicate that the data object node the data object node being in the GOODS PACKED stage of processing, as indicated by stage of processing  460 . The transformation of the data object node from the ORDER CONFIRMATION status to the GOODS PACKED status is reflected in the transformation of the current values of the status variables  435  to the transformed values of the status variables  440 , which results from the action  450 . In this example, the action  450  represents a process step  465  of PACK GOODS. 
     As shown in this example, a status management model for a data object node illustrates the transformation of the data object node from one state to another state, as reflected in a value change to the variables of the data object node. The transformation reflects an action being performed on the data object node, which results in the change of one or more status variable values for the data object node. The action represents or corresponds to a process step performed on the data object node, and the state reflected by the values of the status variables represents or corresponds to a stage of processing. As shown, it may be said that the process step results in a change of the current stage of that the processing of the data object node. The status and action model component may be said to represent or make visible business logic and rules describing how a data object node is transformed from one state to another state, as illustrated by the business logic and rules representation  432 . 
       FIG. 5A  depicts an example of an approval status schema  500 A, which also may be referred to as an approval status schema model. The approval status schema model  500 A may be defined and modified, using, for example, the modeling computer system  350  described previously with respect to  FIG. 3 . The approval status schema model  500 A is a design-time model. Design-time status schema models may be used to show relations between an object&#39;s state and actions, which may define constraints for the actions by describing which actions are allowed for which status values, and define which status values are to be set after the completion of an action. At runtime, an approval status schema instance may be loaded, for example, from the runtime status repository  140  described previously with respect to  FIG. 3 , by the status management runtime component  130  with the current values of the status variables. 
     As illustrated, the approval status schema model  500 A includes a single status variable  510  (shown as “Approval”) with four possible status values  510 A- 510 D (shown as “Not Started,” “In Approval,” “Approved” and “Rejected,” respectively), and three actions  520 ,  525  and  530  (shown as “Start Approval,” “Reject” and “Approve,” respectively). The approval status schema model  500 A may be instantiated with the initial value NOT STARTED  510 A, as indicted by the dotted-line border. Approval of the action  520  (i.e., “Start Approval”), for example, causes the status value IN APPROVAL  510 B to be set, which is a precondition of the REJECT action  525  and APPROVE action  530 —that is, in this example, a “Reject” or an “Approve” action is not allowed unless the IN APPROVAL status value is currently set in the approval status variable  510 . 
     As illustrated in this example, the modeled status variables and their status values represent the state of the object node. The status values represent the possible values a status variable is allowed to take up, while the status variable lists all possible allowed status values. At runtime, the status variable then specifics information about the currently valid value. The modeled actions represent the methods that may be performed on or by the object node. Whether they are allowed or not is dependent on the currently set status value associated with the object node&#39;s state. The modeled preconditions are identified by the connections (lines or edges) from status values to actions, and they represent the status value constraints allowing or permitting the actions. The modeled transitions are identified by the edges (or lines) that come out of an action and connect to a resulting status value, and they represent constraints allowing or permitting the setting of a status value following the performance of an action (for example, as triggered by an updating process). The model may also identify edges (or lines) drawn from one status value of one variable to another status value of another variable (not shown), indicating that one status change directly triggers another one. The status management runtime component  130  may adjust such other status information in the status repository  140  during application runtime when the data objects are processed. 
       FIG. 5B  is another example of an approval status schema model  500 B for a data object node. In one example, the approval status schema model  500 B may correspond to a sales order node, such as sales order root  210  as described previously with respect to  FIG. 2 . In another example, the approval status schema model  500 B may correspond to a sales order item, such as items  220 A- 220 D as described previously with respect to  FIG. 2 . Associating the status schema model  500 B with each item node (rather than the root node) provides a finer granularity of approval such that each item is approved separately (rather than the approval of the sales order as a whole). 
     The approval status schema model  500 B (like the status schema model  500 A) includes a single status variable  550  (shown as “Approval”). In contrast with model  500 A, the approval status schema model  500 B includes seven possible status values  550 A- 550 G (shown as “Not Started,” “Approval Not Necessary,” “In Approval,” “Approved,” “Rejected,” “In Revision” and “Withdrawn”), and seven possible actions  560 ,  565 ,  570 ,  575  and  580  (shown as “Submit For Approval,” “Reject,” “Approve,” “Send Back For Revision,” and “Withdraw From Approval,” respectively). As illustrated, the approval status schema model  500 B is instantiated with the initial value NOT STARTED  550 A, as indicted by the dotted-line border. As illustrated, if the submit-for-approval action  560  is performed, the status value of the approval status variable  550  changes from a NOT STARTED value  550 A to the IN APPROVAL value  550 C, as illustrated by the edge  582  leading from the submit-for-approval action  560 . The status value IN APPROVAL  550 C must be set for any of the reject action  565 , the approval action  570 , the send-back-for-revision action  575  or the withdraw-from-approval action  580  to be performed. These preconditions for the actions  565 ,  570 ,  575  and  580  are shown by the edges  584 ,  586 ,  587  and  588  leading from the status value IN APPROVAL  550 C to each of the actions  565 ,  570 ,  575  and  580 . Performing any one of the reject action  565 , the approve action  570 , the send-back-for-revision action  575  or the withdraw-from-approval action  580  changes the status value of the approval status variable  550 , which, in turn, makes the these actions  565 ,  570 ,  575  and  580  unavailable to be performed. 
     As illustrated, the edges (or lines) that lead into an action are preconditions that define which status values enable an action to be performed. One example of a precondition edge is edge  584  leading from the value IN APPROVAL  550 C to the reject action  565 . The edges (or lines) that lead from an action reflect a status transition—that is, a transformation of a status value of a status variable to another status value of the status variable. An example of a status transition is edge  589  leading from the withdraw-from-approval action  580  to the value WITHDRAWN  550 G of the approval status variable  550 . An edge (or line) may be drawn from a status value of one status variable to a status value of another status variable, which illustrates a status change that triggers another status change. A status change that triggers another status change may be referred to a “synchronizer.” 
     In this example of status schema model  550 , performing the submit-for-approval action  560  causes the value IN APPROVAL  550 C to be set, which is a precondition of the reject action  565 , approve action  570 , the send-back-for-revision action  575  and the withdraw-from-approval action  580 . 
     In comparison with status schema model  500 A, status schema model  500 B provides additional options during an approval process—for example, the send-back-for-revision action  575  and withdraw-from-approval action  580 . The additional status value IN REVISION  550 F and status value WITHDRAWN  550 G of the approval status variable  550  support the more robust approval process. As would be understood by a person skilled in the art, the inclusion of more actions and predetermined status values for the approval status variable  550  in status schema model  550 B does not intrinsically make this status schema model  550 B preferred over the status schema model  550 A. Rather, the ability to more accurately model a “real-world” business process is important—whether the “real-world” business process is more accurately represented by status schema model  500 A or more accurately represented by status schema model  500 B. The ability to model a business process by adding actions and status values for a status variable representing a step in business process is beneficial. 
       FIG. 6  illustrates an example status schema model  600  for a sales order object node. The status schema model  600  includes a check-availability action  610  (shown as “CheckATP”), an accept action  620 , a reject action  630  and a confirm-invoicing action  640 . The status schema model  600  also includes an availability-confirmation status variable  615  (shown as “ATPConfirmation”) having an initial status value  615 A of NOT CONFIRMED and a CONFIRMED status value  615 B. The status schema model  600  also has an acceptance status variable  625  having an initial value  625 A of NONE, a status value  625 B of REJECTED, and a status value of ACCEPTED  625 C. The status schema model  600  further includes an invoicing status variable  645  having an initial status value  645 A of NOT INVOICED and a status value  645 B of invoiced. 
     In the example of status schema model  600 , the confirm-invoicing action  640  should be performed only if an associated order has been accepted and an invoice has not been yet sent out. That is, the confirm-invoicing action  640  is permitted to be performed only if the current value of the invoicing status variable  645  is the status value NOT INVOICED  645 A and the current value of the acceptance status variable  625  is the status value ACCEPTED  625 C. The model  600  reflects these preconditions of the confirm-invoicing action  640 , as shown by the edge  642  leading from the status value ACCEPTED  625 C of the acceptance status variable  625  to the confirm-invoicing action  640  and by the edge  643  leading from the value NOT INVOICED  645 A of the invoicing status variable  645  to the confirm-invoicing action  640 . 
       FIG. 7  shows an architecture  700  that includes a status and action model  710  and a business object model  720 , which may be a type of a data object model. In this example, the business object model  720  represents a design-time sales order object model. The business object model  720  is another example of how a sales order object may be modeled. Like the sales order modeled in  FIG. 2 , the sales order business object model  720  includes a business object node  725  (called “SalesOrder” and may also be referred to as a sales object node or a sales object root node). The sales object node  725  also includes a header status node  730  (called “SalesOrder HeaderStatusNode” and may be referred to as a sales status node), and, like the sales order of  FIG. 2 , an item node  735  (called “SalesOrderItem”). The sales object node  725  is the root node of a sales order object and includes identifying information, such as an identifier variable  725 A (called “ID”), a customer identifier  725 B (called “BuyerParty”) as well as other variables. The sales object node  725  provides a set of core services  726 , including access methods  726 A, a query method  726 B, and actions  726 C. The actions  726 C of the sales object node  725  include an availability-check action  726 D (called “ATPCheck”) and an confirm-invoice action  726 E. 
     As shown through line  740 A, the sales object node  725  is related to the sales status node  730 , which includes an availability status variable  730 A (called “ATPConfirmation”) and an invoice status variable  730 B (called “InvoiceStatus”). 
     As shown through line  740 B, the sales object node  725  also is related to one or more sales order item nodes  735 , each of which include an identifier variable  735 A, a product identifier variable  735 B as well as other variables related to a sales item (not shown). The sales object node  725  may be one example of a design-time data object node model for the runtime sales item instances  220 A- 220 D, which have been described previously with respect to  FIG. 2 . 
     The status and action model  710  may be an implementation of the status and action model  600  described previously with respect to  FIG. 6 . The status and action model  710  and the business object model  720  are related through actions and status variables. More particularly, in this example, the availability-check action  726 D of the sales order node  725  corresponds to the check-availability action  712  in the status and action model  710 , as shown through arrow  745 A. The confirm-invoice action  726 E of the sales order node  725  corresponds to the confirm-invoicing action  714  of the status and action model  710 , as shown through arrow  745 B. The availability-confirmation status variable  730 A of the sales status node  730  corresponds to the availability-confirmation status variable  716  of the status and action model  710 , as shown through dotted arrow  745 C. The confirm-invoice status variable  730 B of the sales status node  730  corresponds to the invoicing status variable  718  of the status and action model  710 , as shown through dotted arrow  745 D. 
       FIG. 8  shows a conceptualized data structure  800 , in simplified form, for a status schema model that relates status variables  810  to constraints  820 ,  830  and  840  for actions that may be performed on a sales order node. The data structure  800  includes three status variables: approval  810 A, release  810 B and consistency check  810 C. The data structure  800  also identifies the status values that may be set for each status variable, as shown by values  812  for the status variable approval  810 A. 
     In the example data structure  800 , each status variable for the sales order node is related to one or more constraints for an action that may be performed by the sales order node. More particularly, constraints  820  for actions  820 A,  820 B and  820 C are based on the current value of the approval status variable, as shown by line  850 A. In particular, constraints for approve action  820 A identifies a precondition  825 A for the approval action (here, IN APPROVAL status value) to be permitted and a status transition  825 B (to APPROVED status value) that results from occurrence of the approve action  820 A. Constraints for the reject action  820 B and constraints for the send-back-for-revision action  820 C identify one or more preconditions (based on the approval status variable) for the action to occur and optionally may identify a status transition resulting from the action. Stylized constraints  830  identify constraints for actions based on the release status variable  810 B, as represented by line  850 B, whereas stylized constraints  840  identify constraints for actions based on the consistent-check status variable  810 C, as represented by line  850 C. The data structures of constraints  830  and  840  are structured in a similar way to the constraints  820 . 
       FIG. 9  shows an example process  900  for designing and using a status schema model. The process  900  may be performed, for example, using the modeling computer system  350  and the processing computer system  110 , both as described previously with respect to  FIG. 3 . 
     The process  900  includes designing a status schema model for a data object node (step  910 ). This step may be performed, for example, by a user of the modeling computer system  350  executing a computer program presenting graphical user interface to create and modify a status schema model. For example, a user in one or more sessions may use a graphical user interface to design, simulate and refine a status management model for a data object node, such as status and action schema models  500 A,  500 B and  600  of  FIGS. 5A ,  5 B and  6 , respectively. 
     Once designed, the status schema model is transformed such that the status schema can be applied to instances of the data object node at runtime (step  920 ). For example, the status schema model may be reformatted for efficient runtime access by an application runtime component or status management runtime component, as described previously with respect to  FIGS. 1 and 3 . The status schema model may be persistently stored, such as in a runtime status repository  140  of  FIG. 1  or  3 . 
     During runtime, the status schema instance is applied to instances of the data object node to enforce the status and action constraints specified by the status schema model. One of the advantages of this process is that the status schema model created (and refined) in step  910  is used to enforce the status and action constraints in step  930 . As such, a visible status-driven process may be defined and consistently applied to data objects. While the model is transformed for use at runtime, the semantic information of the status schema model is not changed in the transformation. The status and action constraints specified by the status schema model for a data object node are applied without deviation at runtime to instances of the data object node. 
     In some implementations, multiple status schema models may be created for a data object node. In such a case, at runtime, one of the multiple status schema models is applied without deviation to instances of the data object node, as described more fully later. 
       FIG. 10  illustrates an example process  1000  for modeling a process in a status and action modeling computer system. In one example, the process may be implemented by the modeling computer system  350  described previously with respect to  FIG. 3 . For example, computer-readable medium may be configured to perform the process  1000  when executing on a processor (or processors) of a modeling computer system. 
     The process  1000  begins with the receipt of an indication of the process steps to be included in a process to be modeled (step  1010 ). In one example, processing a sales order includes three processing steps: (1) availability check for items in the sales order to determine whether the sales order can be fulfilled, (2) communication to the buyer of acceptance (or rejection) of the sales order by the seller, and (3) creating an invoice to send to the buyer for accepted an sales order. 
     An indication of actions and status values that are important to, or represent, the process steps are received (step  1020 ). Continuing the example, the availability process step includes a check-availability action; the acceptance process step includes an accept action and a reject action; and the invoicing process step includes a confirm-invoicing action. The progress of the process steps is reflected in a status variable. In this simplified example, the availability process step includes a confirm-availability status variable having NOT-CONFIRMED and CONFIRMED status values; the acceptance process step includes an acceptance variable having NONE, REJECTED and ACCEPTED status values, and the invoicing process step includes an invoicing status variable with NOT-INVOICED and INVOICED status values. As illustrated in this example, each action associated with a process step is represented by a status value corresponding to the action. In particular, the acceptance process step has a reject action and an accept action, each of which are reflected in permitted status values for the acceptance status variable. 
     Information of dependencies between process steps is received (step  1030 ). Sometimes process steps cannot occur in parallel, and information related to the constraints between the process steps is received to be modeled. Continuing the example, a sales order can only be accepted if the availability check was successful; invoicing only occurs if the sales order was accepted; and checking availability should not be performed after the order was accepted or rejected. Stated differently, information is received that defines the preconditions and status transitions depicted model  600  described previously with respect to  FIG. 6 . 
     In some implementations, model information for a life cycle (or overall) status for the process may be received (step  1040 ). For example, an overall status variable that reflects the overall process stage may be defined. Continuing this example, information may be received that indicates that the process should have a life cycle status variable with possible status values of IN PREPARATION, IN ACCEPTANCE, IN EXECUTION, COMPLETED and REJECTED. 
     As such, the process  1000  represent an example implementation of defining a status schema model for a sales order object node. The status schema model for the data object node generally is stored in the modeling computer system for review and refinement. 
     In some implementations, the process  900  may include receipt of information of dependencies between status schema models (step  1050 ). For example, information may be received that is related to inter-schema processes, such as population and aggregation derivations, described previously with respect to  FIG. 3 . 
       FIG. 11  shows an example process  1100  for transforming a status schema model for application to runtime instances of a data object node, which corresponds to a status schema model. The example process  1100  may be an implementation of the transformation step  920  described previously with respect to  FIG. 9 . The process  1100  may be implemented by the modeling computer system  350  described previously with respect to  FIG. 3 . 
     The process  1100  begins with the receipt of an indication of a status schema model for a data object node (step  1110 ). The status schema model transformed by performing the process  1100  to a runtime representation of the status schema model. In one example, a user of a modeling computer system may select one of previously defined status schema models from a displayed list. In another example, the user may enter an identifier of a particular status schema model. In yet another example, the transformation process  1100  may be performed sequentially to, or as part of, a process to design a status schema model for a data object node. In such a case, for example, the indication may be programmatically received by the processor executing the process  1100 . 
     The status schema model for the data object node is transformed (step  1120 ) and stored for runtime use (step  1130 ). For example, the status schema model may be transformed from a modeling format to a format usable by a runtime component, such as the runtime processing component  120  or the status management runtime component  130 , described previously with respect to  FIG. 1 . The transformed status schema model may be stored, for example, in a runtime status repository, which may be an implementation of repository  140  described previously with respect to  FIG. 1  or  3 . In some implementations, additional status schema models may be identified for transformation and storage (step  1140 ). 
       FIG. 12  illustrates an example process  1200  for applying a status schema model to an instance of a corresponding data object node instance. The example process  1200  may be an implementation of the application step  930  described previously with respect to  FIG. 9 . The process may be implemented in computer-readable medium that is executed by, for example, a processor of the processing computer system  110  described previously with respect to  FIG. 3 . 
     The process  1200  begins when the processor implementing the process  1200  detects creation of a data object node instance or detects loading of a previously created data object node instance (step  1210 ). The processor instantiates (or creates) a status schema instance corresponding to the status schema model for the data object node of the same type as the detected data object node instance (step  1220 ). For example, a sales order node instance is created by a processing computer system in response to a sales order being placed by a customer. A status schema model for a sales order node is accessed, for example, from the runtime status repository  140  described previously with respect to  FIGS. 1 and 3 . The status schema model for a sales order node is used to create an instance of the sales order node status schema. 
     The processor loads the status schema instance with the current status value of each of the status variables of the data object node instance (step  1230 ). Continuing the example, the status variables in the instance sales order status schema are set to the same status values of corresponding status variables in the sales order node instance. When the creation of sales order node instance is detected in step  1210 , the instance of the sales order node status schema includes the default status values for the status variables. 
     The processor permits an action to be performed by the data object node instance conditioned upon compliance with the status schema instance for the data object node (step  1240 ). For example, the processor may determine whether an action may be performed by the sales object node instance by evaluating preconditions included in the sales order node status schema instance. 
       FIG. 13  depicts an example of a runtime architecture  1300  for status management within an enterprise services implementation. In general, the runtime architecture  1300  includes an enterprise services layer, an application layer, and a status management runtime layer. The entities in the status schemas correspond to external representations in the enterprise services layer. The application layer implements the services modeled in the enterprise services layer. To perform tasks related to status information (such as checking whether an action is allowed and setting a status value as a result of performing an action), the application layer uses the status and action management (S&amp;AM) runtime component. The application layer also provides services to the status and action management runtime component, such as performing a process to determine status derivations or other inter-schema processes. 
     More particularly, a client  1310  accesses enterprise services externally provided to clients, which communicate with the enterprise services framework backend  1320 , which, in turn, interfaces with the enterprise services provider interface  1330 . The enterprise services provider interface  1330  addresses an application through application/business object  1340 . The application layer also includes a repository of persisted business object instances  1345  and optionally a status instance data repository  1350 . In some implementations, the business object instances include status variables, which are used to set status values in corresponding variables of status schema instances. Additionally or alternatively, an application layer may store status variables for business objects separately, for example, in a status instance data repository  1350 . At runtime, the status schema instance is instantiated and status values set based on the current status values of status variables, whether the status variables are persistently stored with business objects or in a separate status repository. In some implementations, a status schema instance for a data node instance may be persistently stored and loaded into memory at runtime. 
     The application/business object  1340  accesses the status and action management runtime component  1360 , which includes the status and action management runtime model  1361  having status schema models usable at runtime. The status and action management runtime component  1360  includes a buffer interface  1362  to a buffer implementation  1365 , which is a runtime representation of status schema instances. The status and action management runtime component  1360  also includes a persistence interface  1372  to a persistence implementation  1375  of status schema instances. The persistence implementation  1375 , for example, may map status tables (such as name-value pair tables) of the status and action management runtime component  1360  to the database tables of the application data. The status and action management runtime component  1360  optionally may include a derivation interface  1382  to a derivation implementation  1385 . The derivation interface  1382  provides a standardized manner for the runtime to access derivation processes, or other types of inter-schema processes. 
       FIG. 14  is a block diagram of a computer system  1400  that can be used in the operations described above, according to one implementation. The system  1400  includes a processor  1410 , a memory  1420 , a storage device  1430  and an input/output device  1440 . Each of the components  1410 ,  1420 ,  1430  and  1440  are interconnected using a system bus  1450 . The processor  1410  is capable of processing instructions for execution within the system  1400 . In some implementations, the processor  1410  is a single-threaded processor. In another implementation, the processor  1410  is a multi-threaded processor. The processor  1410  is capable of processing instructions stored in the memory  1420  or on the storage device  1430  to display graphical information for a user interface on the input/output device  1440 . 
     The memory  1420  stores information within the system  1400 . In one implementation, the memory  1420  is a computer-readable medium. In another implementation, the memory  1420  is a volatile memory unit. In still another embodiment, the memory  1420  is a non-volatile memory unit. 
     The storage device  1430  is capable of providing mass storage for the system  1400 . In one embodiment, the storage device  1430  is a computer-readable medium. In various different embodiments, the storage device  1430  may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. 
     For example, the runtime processing component  120  discussed previously with respect to  FIGS. 1 and 3  may include the processor  1410  executing computer instructions that are stored in one of memory  1420  and storage device  1430 . In another example, the implementation of modeling computer system  350  described above with respect to  FIG. 3  may include the computer system  1400 . 
     The input/output device  1440  provides input/output operations for the system  1400 . In one implementation, the input/output device  1440  includes a keyboard and/or pointing device. In another implementation, the input/output device  1440  includes a display unit for displaying graphical user interface as discussed above. 
     The techniques can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The techniques can be implemented as a computer program product, i.e., a computer program tangibly embodied, e.g., in a machine-readable storage device, in machine-readable storage medium, in a computer-readable storage device, or in computer-readable storage medium, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. 
     Method steps of the techniques can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the techniques can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). 
     Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, such as, magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as, EPROM, EEPROM, and flash memory devices; magnetic disks, such as, internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry. 
     The techniques can be implemented in a distributed manner. For example, the functions of the input/output device  1440  may be performed by one or more computing systems, and the functions of the processor  1410  may be performed by one or more computing systems. 
     The techniques can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the invention, or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet. 
     The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. 
     A number of implementations of the techniques have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the claims. For example, useful results still could be achieved if steps of the disclosed techniques were performed in a different order and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components. Accordingly, other implementations are within the scope of the following claims.