In numerous pages on my website I refer to something called a "user transaction", but what exactly does this mean? In my early days in computing I worked on a UNIVAC mainframe where everything was done in batch jobs, and the work carried out by each job was known as a transaction. This was later renamed to user transaction in order to differentiate it from a database transaction which appeared later. A user transaction is also part of a Transaction Processing System where it is described as follows:
In computer science, transaction processing is information processing that is divided into individual, indivisible operations called transactions. Each transaction must succeed or fail as a complete unit; it can never be only partially complete.
This is the description provided in User transactions from microblink.com:
User transactions are actions performed by individuals within a computer system or transactional platform. These actions involve a user interacting with a system to perform specific operations such as making a purchase, accessing or modifying data, or initiating a transfer. User transactions typically involve a series of steps and can vary in complexity depending on the nature of the system and the desired outcome.
Other terminology may be used, such as use case or unit of work, or, in the case of the RADICORE framework, a task. Note that in the RADICORE framework a transaction is not limited to an operation that updates the database as sometimes the user wishes to perform a task which does nothing but read from the database and present the information in a particular format.
In an application built using the RADICORE framework every user transaction (task) has the following properties:
Note that there are only 45 reusable page controllers, one for each Transaction Pattern. These can be used multiple times with different Models and Views to produce different results. Note also that there is only one reusable View component which produces HTML output, one for CSV output, and another for PDF output.
While most transactions have a single View, which may take the form of either an HTML document, a CSV file or a PDF file, a small number do not have any visible output at all. This may be because they update the database and leave other tasks to display the result, or they may read the database and output the data to a disk file which may or may not be emailed to someone. Note that no user transaction has more that one View, so it not necessary for a user to choose a transaction and a view separately.
A user transaction may or may not involve a database transaction, but once a database transaction has started, usually when the user presses a SUBMIT button, no further dialog with the user is permitted until that database transaction has ended with either a ROLLBACK or COMMIT. This allows any database locks to be held for the shortest possible time.
During the operation of any task, if a menu button or navigation button is pressed then the current task will be closed without performing any database updates and the new task will be opened. If there are other buttons in the data area, such as a popup button, this will cause the current task to be suspended before the new task is run. When that new task terminates the current task will be reactivated.
It has been suggested that my assertion that a User Transaction is the same as a Use Case is incorrect as a Use Case may be defined as a high-level activity which involves several steps each of which is a separate user transaction. This wikipedia article states the following:
Use cases are a technique for capturing, modeling, and specifying the requirements of a system. A use case corresponds to a set of behaviors that the system may perform in interaction with its actors, and which produces an observable result that contributes to its goals. Actors represent the role that human users or other systems have in the interaction.
Some people say that my grouping of several tasks into a forms family constitutes a single use case, but I disagree. That group can be divided into six separate tasks by virtue of the fact that each task requires its own set of software components and performs different actions of different database tables. Each those those tasks is self-contained and may be run independently of the others, so that group is not indivisible. It is also possible for a low-level task to appear in more that one high-level use case, but that is irrelevant. The task performs exactly the same set of operations regardless of the context in which it is being run.
For another example, when creating a document which requires entries on several database tables, such as a sales order, it is necessary to run the Create Order Header task first, followed by the Create Order Item task separately for each order line. Each of those tasks performs its own database transaction as it would be very bad practice to keep a database lock in place while the user processed several screens.
In a large enterprise application the concept of a Sales Order may be more complicated as it may require a large number of related database tables, as shown in Object Associations: Figure 5. While the minimum requirement is for a ORDER_HEADER entry and one or more ORDER_ITEM entries, entries on the other 9 tables are entirely optional. More complicated than this would be the concept of Order Fulfillment which involves multiple tasks raging from Order Entry to Generate Picklist to Pick from Inventory to Assemble Shipment and then Delivery and perhaps Returns. These may require transactions in different subsystems and different databases.
I ignore these multi-part use cases as they do not exist as separate entities within the RADICORE software. These use cases may be documented outside of the system so that the users know what steps are required and how to complete each one, but none of these use cases have their own entries on the MNU_TASK table and therefore cannot be selected from an option on a menu.