There is a variation of the work-in-progress problem that is the cause of much programming in a large, complex application, which is the long-business-transaction problem. Basically, the issue here is to support the creation/update of a large set of data across multiple user interactions, after which the user is allowed to either “accept” that group of changes, or “cancel” them. The group of changes is called a long business transaction.

There are two parts of the problem that require so much programming when using traditional application development languages and techniques:

1. Defining and Storing the Data in Its Intermediate State – With traditional programming, the solution almost always involves creating temporary database table entries to store the intermediate data. One might ask, why not just update the data in the regular tables as the long transaction progresses? But, intermediate data are often in an invalid state (ie., They violate data integrity.) and can create havoc when other users access the data in that state. Thus, the programmer is forced into defining those intermediate tables and supporting their temporary maintenance through the series of iterations making up the long business transaction.
2. Updating the Production Data at the Transaction End – If the user cancels the long transaction, processing only involves deleting the temporary data. However, if the transaction is “accepted” or “saved”, then the programmer must “transform” the temporary data into production data by comparing and inserting/updating table values. This is usually a large, complex, error-prone process.

In AOA, both problems above are avoided, as any “activated” object is automatically a work-in-progress object and a long business transaction. Thus the steps in processing a long business transaction in AOA are as follows:

1. The object (LOD instance) is activated, with a single Activate statement as explained earlier.
2. The object is updated through either the execution of rules or through user interface functionality across multiple iterations.
3. At the end of these iterations, the operator takes an action (ex., strikes a button) that either “drops” the object, canceling any create/update/delete activity or “commits” the object to the database, which causes the generation of all the SQL needed to perform the necessary database create/update/delete activity. Either action is triggered from a single VML statement (either DropObjectInstance or Commit).

The latter is possible because the object keeps a record of all the create/update/delete activity on any of its components. In the example shown to the right, part of an instance of the mCourse object is displayed using the AOA Object Browser. On the left side of the diagram, the radio button “Markings” is chosen to display the modification flags for the selected entity, CourseTopic, which indicates that the entity has been created and updated, activity that would cause a corresponding table entry to be inserted to the database when the object is committed.

The meta information carried with the object keeps enough information that an object could even be:

1. Activated at one location,
2. Transferred to a second location to be updated,
3. Transferred to a third location to be further updated.
4. Transferred back to the original location to be written to the database.

There is a further option for more complex cases where the long business transaction can include several objects. Those objects are defined as a part of a “cluster” and then the cluster is committed, as opposed to the individual objects, which treats the commit of all objects in the cluster as a single transaction to the database.

It should be noted that only “changed” data is written back to the database. Thus, if only a single entity and its attributes have been created, then only one table insert statement occurs during the commit process.

The end result is the processing of very complex long business transactions with minimal effort.