Content-ID: <email@example.com> Content-type: text/plain I haven't heard from you, whether you are willing to grant an extension on the workshop paper deadline, so I am acting optimistically and sending you a copy of my position paper (attached). Regards, Tom Fahey (reply to firstname.lastname@example.org) Content-ID: <email@example.com> Content-type: text/plain; name="BUSTRA~1.HTM"
Business transaction processing systems have several common characteristics. I am familiar with several 'legacy' systems and one object/relational system. A 'typical' legacy business transaction processing system is built using a procedural language. Depending on the age of the system, data storage is primarily an RDBMS, with older systems using VSAM or other indexed data storage methods. Processing is done in 'batch' mode on MVS mainframes, with account inquiries performed using CICS / 3270 terminals.
Although various methods are used to enter transactions into the system, the common characteristics of data entry are batching and controls. Batching and controls are interrelated; transactions are grouped into collections, or batches, identified by a marker known as a 'header' and followed by another marker known as a 'trailer.' The header might contain common identifying properties of the batch, and the trailer usually contains similar identification along with totals of monetary and cardinal values of the transactions. These 'control' totals are common in manual accounting procedures. Originally the transactions were slips of paper, such as invoices or receipts. The 'control' totals were used to recheck hand calculations and also to verify that none of the paper transactions were missing. At issue were the accuracy of the calculation engine, the integrity of the transaction transport system, and the integrity of the persons tasked with processing the transactions. These issues are still very important in business transaction processing systems and some of the failure of object systems revolve around the inability of developers both to understand and address these issues to the satisfaction of accounting personnel familiar with legacy methods of control.
Another characteristic of business transaction processing systems is the inherent workflow model underlying each system. Each transaction progresses during its lifespan through various states and is subjected to various processes performed by a wide range of individuals in various departments. While atomic processes are often automated, forwarding the transaction from one person to another is often accomplished using a combination of automated and manual methods. Common tools include corporate email systems, interoffice courier, telephones, and fax machines. Recent introductions include floppy disks passed via sneaker-net and the use of file servers as a file copy location for documents, spreadsheets, and the like. At each processing point, there is usually a degree of cut-and-paste required in order for the person to perform the required process on the transaction and forward it to its next station. An object model representing this type of system should address the management of the transaction workflow. Most leagacy systems do not address workflow issues or do so in a cursory manner. Many systems are monolithic, assuming that everything of significance that happens to a transaction occurrs within the scope of the system and through its defined mechanisms. In order to change the behavior or outcome of a process, the change must either occur within the primary system, or in a secondary parallel system designed to perform the new process while ensuring consistency with the transaction's representation within the primary system. This highlights another characteristic of legacy business transaction processing systems: they are brittle. Because of the self-contained and controlled nature of the system, changes in transaction attributes or behavior can cause the system to fail. For example, allowing a transaction to be modified at a new station in the process, either in quantities or dollars, will often cause existing control procedures to trigger the change as an error.
Another aspect of business transaction processing systems is the cyclical nature of processing, and the large volume of transactions that typically are processed per 'cycle.' Some transactions are processed on a monthly cycle, such as preparing a billing statement or a paycheck. Other transactions are processed the same day they are entered into the system, such as items received in an inventory system or a customer payment received in a billing system. Still other transactions are entered into the system and held for processing on a particular date or awaiting an event trigger.
In every business transaction processing system, there are business objects which are affected by transactions but are not themselves transactions. These objects are known by various terms: accounts, customers, employees, products to name a few. For clarity I will refer to these objects as accounts. An account represents the current state of something important to the business. Business transactions which are successfully concluded cause state changes in one or more accounts. A deposit to a bank account increases the account's balance; an product shipped decreases the number on-hand. One useful object model could view transactions as state transforms on accounts, in other words objects whose primary purpose is to modify the state of another object.
Business transaction processing systems are fed by transactions but governed by business rules. These rules, using the initial state of the account and the attributes of the transaction, determine the outcome of each transaction, both in terms of the transaction itself, whether it completed successfully, is suspended, has been re-queued, and in terms of the account, what attributes have changed and what subsequent transactions are required or suggested. With regard to workflow one of the key issues in an object design for a business transaction processing system is whether accounts (generally defined above) or transactions, or both should traverse through a workflow network. One possible model is to define two networks. As a transaction proceeds through a workflow network, view the account making its way through a state transition network.
Send the author email:Thomas J. Fahey First Union National Bank Charlotte, NC