Constraining data changes during transaction processing by a computer system

Data changes during transaction processing by a computer system are constrained. An outbound processing sub-component of a first processing component is enabled to change a value of a status variable relating to processing performed on a data object instance by the first processing component. The data object instance includes values for variables and methods capable of being performed by the data object instance. The outbound processing sub-component is configured to trigger subsequent processing steps in a second processing component. The outbound processing sub-component is permitted to change only the status variable and is not permitted to change any other variable.

TECHNICAL FIELD

This description relates to techniques for constraining data changes during transaction processing by a computer system.

BACKGROUND

Enterprise information technology (IT) systems often are used to manage and process business data. To do so, a business enterprise may use various application programs running on one or more enterprise IT systems. Application programs may be used to process business transactions, such as taking and fulfilling customer orders, providing supply chain and inventory management, performing human resource management functions, and performing financial management functions. Application programs also may be used for analyzing data, including analyzing data obtained through transaction processing systems. Application programs may allow for users to see a list of tasks to which they are assigned.

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. The execution of a method may change attribute values of an object, which, in turn, may lead to a new state of the object.

SUMMARY

In one general aspect, data changes during transaction processing by a computer system are constrained. An outbound processing sub-component of a first processing component is enabled to change a value of a status variable relating to processing performed on a data object instance by the first processing component. The data object instance includes values for variables and methods capable of being performed by the data object instance. The outbound processing sub-component is configured to trigger subsequent processing steps in a second processing component. The outbound processing sub-component is permitted to change only the status variable and is not permitted to change any other variable.

Implementations may include one or more of the following features. For example, the outbound processing sub-component may include a first outbound processing sub-component of the first processing component. The value of the status variable relating to processing performed on a data object instance by the first processing component may include a first value of a first status variable. The first processing component may include a second outbound processing sub-component configured to trigger subsequent processing steps in a third processing component. The second outbound processing sub-component of the first processing component may be enabled to change a second value of a second status variable relating to processing performed on a data object instance by the first processing component. The second outbound processing sub-component may be permitted to change only the second status variable and may not permitted to change any other variable.

The first outbound processing sub-component may be configured to trigger subsequent processing steps in the second processing component by sending a first message having a first type to the second processing component. The second outbound processing sub-component i may be s configured to trigger subsequent processing steps in the third processing component by sending a message having a second type to the third processing component.

The first value of the first status variable relating to processing performed on a data object instance by the first processing component may include a first value indicating the sending of the first message. The first outbound processing sub-component may be prohibited of including the second value of the second variable in the message sent to the first processing component. The second outbound processing sub-component may be prohibited of including the first value of the second variable in the message sent to the second processing component.

The first outbound processing sub-component may be permitted to include the first value of the first variable in the message sent to the first processing component. The second outbound processing sub-component may be permitted to include the second value of the second variable in the message sent to the second processing component.

The first outbound processing sub-component may be permitted to use the first value of the first variable to determine processing to be triggered. The first outbound processing sub-component may not be permitted to use the second value of the second variable to determine processing to be triggered. The second outbound processing sub-component may be permitted to use the second value of the second variable to determine processing to be triggered. The second outbound processing sub-component may not be permitted to use the first value of the first variable to determine processing to be triggered.

A status schema model may be accessed where the status schema model may be defined at design-time, may be stored in a computer-readable medium and may include a precondition identifying how a status affects whether an action is to be allowed to be performed at runtime by a data object instance having the status. A status schema instance may be created for the data object instance, where the status schema instance corresponds to the status schema model. Based on the status of the data object instance, a determination may be made as to whether a particular action is allowed to be performed by the data object instance. In response to a determination that the particular action is allowed, the particular action may be enabled to be executed by the first processing component.

The status of the data object instance may include a status variable and a particular status value, where the particular status value being one of a set of possible status values for the status variable. The variables of the data object instance may include one or more status variables, where a status variable being 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.

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.

DETAILED DESCRIPTION

FIG. 1Adepicts a computer system100that constrains data changes during transaction processing. The computer system100includes processing components110and120configured to process data object instance112and124, respectively. A data object instance is a collection of data variables and methods that may be performed by the data object instance. A data object instance may correspond to a principal entity represented in the computer system100. For example, a data object instance may correspond to a document used in a business process—such as, for example, a data object instance may correspond to a document used in the business process of delivering and invoicing merchandise sold to a customer. Another example of a data object instance includes information about a customer, an employee, a product, or a business partner (such as a supplier, distributor or reseller). A data object instance may be stored, for example, 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, a data object instance may be related to other data object instances. In one example, a sales order data object instance may include multiple sales order object 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 object 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), as described more fully with reference toFIG. 1B. In another example, each of the sales order object instance, delivery object instance and invoice object instance may relate to a sale of merchandise to a customer. As such, each of those object node instances may be said to relate to one another.

In this example, each of the data object instances112and124have standard variables112A and124A, each of which corresponds to a characteristic or attribute of the data object instance. For example, a sales order object node instance may include, for example, standard variables identifying a customer to whom the sale was made and the date of the sale. Each of the data object instances112and124have one or more status variables112B and124B, respectively. A status variable indicates a status of the data object instance. For example, a status variable may indicate the status of a data object instance relative to a stage of processing. In a more particular example, a status variable may indicate whether a sales order object instance has been approved. Each of the data object instances112and124also have methods112C and124C that may be executed by the data object instance. The computer system100is configured to process other data object instances (not shown) and includes other processing component (also not shown).

FIG. 1Billustrates an example of a data object instance150having multiple components or nodes. As shown, the example data object instance150includes multiple sales order node instances160and170A-170D, 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 instance160is related to sales order item instances170A-170D. The sales order root instance160may be referred to as the parent node of each of the sales order item instances170A-170D. In turn, each of the sales order item instances170A-170D may be said to be a child node of the sales order root instance160. Each of the sales order item instances170A-170D also may be referred to as a sibling node of the other sales order item instances170A-170D.

More particularly, the sales order root instance160has a customer161variable with a value “ABC Bicycle Store” and an order date162variable with a value of “May 1, 2006.” Each variable161and162may be referred to as a standard variable, attribute or characteristic of the sales order root. The sales order root160has an availability status variable165having a value of NOT CONFIRMED. The value of the availability status variable165is a reflection of the available status values176A-176D of the sales order item instances170A-170D.

Each of the sales order item instances170A-170D has a standard variable172A-172D with a value describing a type of bicycle and a corresponding quantity purchased. For example, sales order item instance170A has a standard variable172A identifying “6 adult blue bicycles” as the type and quantity of a bicycle purchased.

Each of the sales order item instances170A-170D also has an availability status variable175A-175D having a value176A-176D that identifies the availability status of the bicycles identified in the standard variable170A-170D. For example, the sales order item170A has an availability status value176A of UNKNOWN for six adult blue bicycles; the sales order item170B has an availability status value176B of PARTIALLY CONFIRMED for five child red bicycles; the sales order item170C has an availability status value176C of CONFIRMED for ten child blue bicycles; and the sales order item170D has an availability status value of NOT CONFIRMED for two child green bicycles.

Referring again toFIG. 1A, the processing component110is configured to execute to create and/or manipulate data object instance112. The processing component110, for example, may execute methods112C to generate or modify a sales order object instance or another type of data object instance in response to programmatic or user input. The processing component110may modify values of standard variables112A, values related to status variables112B and may initiate execution of one or methods112C by data object instance110. The processing component110also is configured to initiate execution of outbound processing sub-component instructions114that send, directly or indirectly, a message130to the processing component120. The outbound processing sub-component also is enabled to change a value of one or more status variables112B to reflect processing performed on the data object instance112by the processing component110, such as reflecting the status that the message130as ready to be sent, being sent, or has been sent to processing component120. This information can be used in the constraint processing for the data object instance112. The processing component120may be, for example, a delivery processing component or a component operated by a customer of the entity operating processing component110.

The processing component120is configured to execute instructions of inbound processing sub-component122in response to receiving the message130. The inbound processing sub-component122, for example, may update a value of a status variable of status variables124B to indicate receipt of the message130by the processing component120, or perform other functions based on receipt of the message130. The processing component120is configured to execute methods124C on, or related to, the data object instance124. The methods124C, for example, may generate or modify an accounting record related to a message related to the received sales order object instance or another type of data object instance in response to programmatic or user input.

In operation, for example, the processing component110may execute a method of methods112C to create a sales order instance112corresponding to a real-world sales order and set values of standard variables112A to reflect the real-world sales order. The processing component110may execute outbound processing sub-component instructions114to set a value of one of the status variables112B to reflect processing performed by the processing component110, such as indicating a message was sent (e.g., to a delivery processing component or a customer). The outbound processing sub-component114sends the message130to processing component120, which, in turn, receives, the message130. The processing component120may execute inbound processing sub-component instructions122. The processing component120executes one or more of the methods124C to create delivery record124related to the sales order112and updates a value of a status variable (of status variables124B) accordingly.

FIG. 2depicts an example process200for constraining data changes during transaction processing by a computer system. For example, the computer system executing the process200may be an implementation of computer system100described previously with respect toFIG. 1Aand the process200may be executed on data object instance112ofFIG. 1Aor sales order object instance150ofFIG. 1B.

A first processing component triggers (or otherwise initiates) processing by an outbound processing sub-component of the first processing component (210). For example, a processor executing a computer program, such as a method in a data object instance, may trigger execution of an outbound processing sub-component. The outbound processing sub-component assembles a message to be sent to a second processing component (220). In some implementations, the message may include variables of a data object instance processed by the first processing component. The outbound processing sub-component sends the message to the second processing component and sets the status variable to reflect outbound processing (230). The second processing component receives the message and takes appropriate action based on receipt of the message (240).

FIG. 3depicts an example computer system300that constrains data changes during transaction processing. In contrast to computer system100described previously with respect toFIG. 1A, the computer system300uses a constraint-based model to control data processing. In general, the computer system300, like the computer system100, is configured to enable an outbound processing sub-component (here, an outbound agent314which is one implementation of an outbound processing sub-component) to change values for variables in a data object instance (here, the data object instance312) to reflect processing performed by the processing component associated with the outbound process agent314. Here, processing component310is associated with the agent314. The computer system300is configured to prohibit the outbound processing agent314to change status variables312B. This prohibition need not necessarily be constrained by the status constraint mechanism. In contrast to the computer system100, the computer system300includes constraint-based models (e.g., status and action schemas317and327) to control processing performed by service layer business logic316and326, respectively, on the data object instances312and324. Each of data object instances312and324include standard variables312A and324A, status variables312B and324B, and methods312C and324C, respectively.

More particularly, the processing component310is configured to perform processing on a data object instance312by applying a status and action schema317of the service layer business logic316. The status and action schema317may include relevant status variables and associated status values, actions and conditions modeled for corresponding types of data objects. For example, at design-time, the status and action schema for a type of data object 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, the service layer business logic316only executes actions that are permitted by the status and action schema317based on current values of the status variables312B for the data object instance312to which business logic is being applied.

Also, in contrast with the computer system100, the computer system300uses inbound and outbound process agents314,318,322and328. Process agents are system components that trigger subsequent processing steps. For example, an outbound process agent may be called by an event handler to trigger sending a message to another processing component. In the example of computer system300, the outbound process agent314of the processing component310sends the message319to the processing component320and, in particular, to the inbound process agent322of the processing component320. The inbound process agent322receives the message319and, in response, the processing component320applies the service layer business logic326(including the status and action schema327) to determine whether an action is permitted to be performed on the data object instance324based on the values of one or more status variables324B. The processing component320is permitted to change standard variables324A and status variables324B in data object instance324but is not permitted to change any variables in a data object instance312.

The outbound process agent328of the processing component320is configured to perform outbound processing when the message329is sent to another processing component. In this example, the message329is sent to the processing component310, though the message329need not necessarily be sent to the processing component310and may be sent to another processing component.

FIG. 4depicts another example computer system400that constrains data changes during transaction processing. In general, the computer system400is configured to restrict the variables which an outbound processing sub-component can change.

More particularly, the computer system400includes processing components410,440and450. The process component410is configured to process data object instance412. As illustrated, processing component410includes outbound processing agents414A and414B. An outbound process agent may be an example implementation of an outbound processing sub-component. Outbound processing agent414A is permitted to change only the first status variable413A, and is not permitted to change standard variables412A or any status variables (such as second status variable413B) other than the first status variable413A. The outbound processing agent414B is permitted to change the second status variable413B and is not permitted to change the first status variable413A or any of the standard variables412A.

The outbound processing agent414A is configured to send a message430A to processing component440to trigger subsequent processing by the processing component440. In some implementations, the message430A may include the current value of the first status variable413A. The message430A may not include the second status variable413B. The outbound processing agent414A may use the current value of the first status variable413A to determine processing to be triggered and is not permitted to use the current value of the second status variable413B to determine processing to be triggered.

The outbound processing agent414B is configured to send a message430B to processing component450to trigger subsequent processing by the processing component450. In some implementations, the message430B may include the current value of the second status variable413B. The message430B may not include the first status variable413A. The outbound processing agent414B may use the current value of the second status variable413B to determine processing to be triggered and is not permitted to use the current value of the first status variable413A to determine processing to be triggered.

FIG. 5is an example of a system500of networked computers configured to constrain data changes during transaction processing.FIG. 5shows a computer system510configured to use a constraint-based model to control data processing. In general, the system500uses a status schema instance of a status schema model to determine whether an action is permitted to be performed by a data object instance.

More particularly, the system500of networked computers includes a computer system510having a runtime processing component520, a runtime status management component530and a runtime status repository540. The computer system510may be a general-purpose computer or a special-purpose computer.

The runtime processing component520includes various data object instances (here, sales order object instance520A, a delivery object instance520B and an invoice object instance520C) and an outbound processing agent522. Each of the object instances520A,520B and520C is a collection of data variables and methods that may be performed by the data object instance. In this example, each instance520A-520C has standard variables, each of which corresponds to a characteristic or attribute of the object instance. For example, a sales order object instance520A may include, for example, standard variables identifying a customer to whom the sale was made and the date of the sale. Each instance520A-520C also has one or more status variables that indicate the status of a data object instance relative to a stage of processing. In a more particular example, a status variable may indicate whether a sales order object instance520has been approved. Each instance520A-520C also has methods that may be executed by the object instance. As shown, the sales order object instance520A has standard variables521A, status variables522A and methods523A. The object instances520B and520C also have standard variables, status variables and methods (not shown).

As shown here, the object instances520A,520B and520C each correspond to a principal entity represented in the computer system510. Each of the example object instances520A-520C relate to a document used in a business process of delivering and invoicing merchandise sold to a customer. In another example, each of the sales order object instance520A, delivery object instance520B and invoice object instance520C may relate to a sale of merchandise to a customer. As such, each of object instances520A-520C may be said to relate to one another.

The status management runtime530tracks status information associated with object instances520A-520C in the runtime status repository540and makes determinations, on behalf of the object instances, as to whether actions are allowed to be performed based at least in part on the status information associated with the objects in the status repository (including the status variable manipulated by the outbound processing agent).

When one of the object instances520A,520B or520C of the runtime processing component520receives a request to perform an action, the object instance520A,520B or520C sends a request to the status management runtime component530to determine whether the action is allowed to be performed. The status management runtime component530checks the runtime status repository540to determine whether the status information associated with the object instance520A,520B or520C permits the action to be performed. The status information associated with the object instance may include the values of one or more status variables associated with the object 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 component530sends a response to the object instance520A,520B or520C indicating that the action is not allowed to be performed, and the object instance520A,520B or520C 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 component530sends a response to the object instance520A,520B or520C indicating that the action is allowed to be performed, and the object instance520A,520B or520C 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 instance520A,520B or520C 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 instance may be previously stored in the runtime status repository540or passed by the object 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 objects and stored in the runtime status repository540. For example, at design-time, the status schema for an object type, 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. For example, the status schema may indicate the status variable can be changed. Data change rules535(which in this implementation is a separate component than the status schema) is used to specify that outbound processing agent522is permitted to change only a particular status variable. In some implementations, a status variable that may be changed by the outbound processing agent522may be modeled as an agent status variable indicating that the status variable can be changed by the outbound processing agent522. The agent status variable may be set by calling an action, which may be referred to as an agent action.

In some implementations, the data change rules535may be implemented more generally in the status schema instance of a status schema model to determine whether an action is permitted to be performed by a data object instance. In such a case, for example, the status schema indicates the conditions under which the outbound processing agent522is permitted to change the particular status variable.

At runtime, a status schema instance may be loaded from the status repository540by the status management runtime530with the current values of the status variables for object instances.

The runtime processing component520illustrates a service-based approach in which services are provided by object instances520A-520C to other computing entities over the network525. Examples of the network525include 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 system525A and a mobile client system525B, 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. 5illustrates only a single online client system525A and a single mobile client system525B. However, actual implementations may include many such computer systems.

The architecture of system500illustrates 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 architecture500is 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 inFIG. 5may allow for a less burdensome and more coherent state management of an object instance by providing a status management runtime component530. The runtime processing component520in some implementations may correspond to an application runtime component. Although the status management runtime component530is depicted as a separate runtime component from the runtime processing component520, the status management runtime component530need not necessarily be a separate component. In one example, the status management runtime component530may be part of the runtime processing component520. In another example, some or all of the functions described with respect to the status management runtime component530may be performed by the runtime processing component520.

As described previously, a data object 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 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 instance may be referred to as the “current status” of the data object instance. Alternatively, in some implementations, the current value of all status variables of a data object instance may be referred to as the “state” of the data object instance. In this description, the term “state” of the data object 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 instance generally is used to refer to the current value of all status variables (and not including the current value of standard variables).

FIG. 6shows another example of a system600of networked computers that uses a constraint-based model to constrain data changes during transaction processing. The system600, like the system500ofFIG. 5, includes a computer system510having a runtime processing component520, a status management runtime component530, data change rules535and a status repository540. In this example, the computer system510may be referred to as a processing computer system510.

The system600also includes a modeling computer system650capable of generating and presenting on a display device (or devices) a modeling user interface655for defining status schema models660for data objects. A data object corresponds to one or more data object instances, each of which is capable of being processed by the processing computer system510. In general, once the status schema models660have been defined and, perhaps, simulated on the modeling computer system, the status schema models660are transformed into a format usable by the status management runtime component530and stored in the runtime status repository540. As described previously, the status management runtime component530uses information in the runtime status repository540to determine whether the status information associated with a data object instance permits a particular action to be performed by the data object 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 interface655enables a user at design-time to define a status schema model for a data object. A data object also is associated with a data model defining standard variables, status variables and methods for the data object, and, therefore, for data object instances generated for the data object.

In general, a status schema model identifies constraints for performing an action of a data object. More particularly, the status schema models660include a status schema model660A for data object type A, a status schema model660B for data object type B, and a status schema model660C for data object type C. As illustrated by the status schema model660A, each status schema model660A,660B or660C, includes status variables662A (and for each status variable, a set of predefined permissible values) and actions663A. As shown, each status schema model includes preconditions (such as preconditions664A for status schema model660A). A precondition identifies how a status affects whether an action is to be performed at runtime by a data object 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 instance corresponding to the data object to which the status schema model corresponds. An action (such as one of actions663A) represents a process step that can be performed on an instance of a data object for which the status schema model corresponds. A precondition (such as one of preconditions664A) is a type of constraint that generally relates an action with a status value of one of the status variables662A. 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 instance to which the status schema model relates. Each of status schema models660B and660C also include status variables, actions, and preconditions for actions (not shown).

In many cases, the modeling computer system650is used by software developers or programmers who are designing and implementing status schema models which correspond to data object types. The status schema models and data objects 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 types along with the runtime status repository that corresponds to status schema models for the data object types may be sold (or licensed) to many business enterprises. Thus, the processing computer system510may be operated and used by a different business enterprise than the business enterprise that operates and uses the modeling computer system650.

In some implementations, the modeling computer system650may be used to extend, enhance or otherwise add to the status schema models corresponding to the data objects used in the processing computer system510. In such a context, the modeling computer system650may be used by a business enterprise other than the commercial software developer who designed and implemented data objects or the runtime status repository. The modeling computer system650, 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 objects 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, 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. 7is a block diagram of a computer system700that can be used in the operations described above, according to one implementation. The system700includes a processor710, a memory720, a storage device730and an input/output device740. Each of the components710,720,730and740are interconnected using a system bus750. The processor710is capable of processing instructions for execution within the system700. In some implementations, the processor710is a single-threaded processor. In another implementation, the processor710is a multi-threaded processor. The processor710is capable of processing instructions stored in the memory720or on the storage device730to display graphical information for a user interface on the input/output device740.

The memory720stores information within the system700. In one implementation, the memory720is a computer-readable medium. In another implementation, the memory720is a volatile memory unit. In still another embodiment, the memory720is a non-volatile memory unit.

The storage device730is capable of providing mass storage for the system700. In one embodiment, the storage device730is a computer-readable medium. In various different embodiments, the storage device730may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device740provides input/output operations for the system700. In one implementation, the input/output device740includes a keyboard and/or pointing device. In another implementation, the input/output device740includes a display unit for displaying a graphical user interface.

The techniques can be implemented in a distributed manner. For example, the functions of the input/output device740may be performed by one or more computing systems, and the functions of the processor710may be performed by one or more computing systems.

Method steps of the techniques can be performed by one or more programmable processors executing a computer program to perform functions of the techniques 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).

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.