From a technical perspective, a Transaction Processing System (or Transaction Processing Monitor) monitors transaction programs, a special kind of programs. The essence of a transaction program is that it manages data that must be left in a consistent state. E.g. if an electronic payment is made, the amount must be either both withdrawn from one account and added to the other, or none at all. In case of a failure preventing transaction completion, the partially executed transaction must be 'rolled back' by the TPS. While this type of integrity must be provided also for batch transaction processing, it is particularly important for online processing: if e.g. an airline seat reservation system is accessed by multiple operators, after an empty seat inquiry, the seat reservation data must be locked until the reservation is made, otherwise another user may get the impression a seat is still free while it is actually being booked at the time. Without proper transaction monitoring, double bookings may occur. Other transaction monitor functions include deadlock detection and resolution (deadlocks may be inevitable in certain cases of cross-dependence on data), and transaction logging (in 'journals') for 'forward recovery' in case of massive failures.
The success of commercial enterprises depends on the reliable processing of transactions to ensure that customer orders are met on time, and that partners and suppliers are paid and can make payment. The field of transaction processing, therefore, has become a vital part of effective business management, led by such organizations as the Association for Work Process Improvement and the Transaction Processing Performance Council.
Transaction processing systems offer enterprises the means to rapidly process transactions to ensure the smooth flow of data and the progression of processes throughout the enterprise. Typically, a TPS will exhibit the following characteristics:
The rapid processing of transactions is vital to the success of any enterprise – now more than ever, in the face of advancing technology and customer demand for immediate action. TPS systems are designed to process transactions virtually instantly to ensure that customer data is available to the processes that require it.
Similarly, customers will not tolerate mistakes. TPS systems must be designed to ensure that not only do transactions never slip past the net, but that the systems themselves remain operational permanently. TPS systems are therefore designed to incorporate comprehensive safeguards and disaster recovery systems. These measures keep the failure rate well within tolerance levels.
Transactions must be processed in the same way each time to maximise efficiency. To ensure this, TPS interfaces are designed to acquire identical data for each transaction, regardless of the customer.
Since TPS systems can be such a powerful business tool, access must be restricted to only those employees who require their use. Restricted access to the system ensures that employees who lack the skills and ability to control it cannot influence the transaction process.
Transactions Processing Qualifiers
In order to qualify as a TPS, transactions made by the system must pass the ACID test. The ACID tests refers to the following four prerequisites:
Atomicity means that a transaction is either completed in full or not at all. For example, if funds are transferred from one account to another, this only counts as a bone fide transaction if both the withdrawal and deposit take place. If one account is debited and the other is not credited, it does not qualify as a transaction. TPS systems ensure that transactions take place in their entirety.
TPS systems exist within a set of operating rules (or integrity constraints). If an integrity constraint states that all transactions in a database must have a positive value, any transaction with a negative value would be refused.
Transactions must appear to take place in isolation. For example, when a fund transfer is made between two accounts the debiting of one and the crediting of another must appear to take place simultaneously. The funds cannot be credited to an account before they are debited from another.
Once transactions are completed they cannot be undone. To ensure that this is the case even if the TPS suffers failure, a log will be created to document all completed transactions.
These four conditions ensure that TPS systems carry out their transactions in a methodical, standardised and reliable manner.
Types of Transactions
While the transaction process must be standardised to maximise efficiency, every enterprise requires a tailored transaction process that aligns with its business strategies and processes. For this reason, there are two broad types of transaction:
Batch processing is a resource-saving transaction type that stores data for processing at pre-defined times. Batch processing is useful for enterprises that need to process large amounts of data using limited resources.
Examples of batch processing include credit card transactions, for which the transactions are processed monthly rather than in real time. Credit card transactions need only be processed once a month in order to produce a statement for the customer, so batch processing saves IT resources from having to process each transaction individually.
Real Time Processing
In many circumstances the primary factor is speed. For example, when a bank customer withdraws a sum of money from his or her account it is vital that the transaction be processed and the account balance updated as soon as possible, allowing both the bank and customer to keep track of funds.