Transactions, Power Failure and Offline

The Equitrac server tracks user activity on the device using information sent from the embedded application. At a high level, each time the user completes a task, the embedded application uses information about the user’s activity. For any tracked activity, the application converts the information into a transaction and sends it to the server. At a low level, the process is more complicated. The application must mitigate power loss, network disconnection, and other factors that might impact proper billing.

To maintain proper billing, the embedded application must maintain information about tracked user activity. To mitigate power failure, the embedded application works closely with the Lexmark device mechanism that tracks job output. The embedded application attempts to send transaction information to the server at 4 events:

1. Power up. If the power is lost before a job is finished, a complete accounting of the job is recorded in the user’s billing statement once power to the device is restored.
2. Log out. All user activity is reported as soon as the user logs out, or the device times out the current login session.
3. Regular console timeout events. While the login application is idle, a timeout counter is running. When a timeout occurs, the console is refreshed. In the background the application looks for updated information about job activity. This helps deliver transactions for delayed activity, such as retries on outbound faxes, in a timely fashion.
4. Job completion events.

Transaction Integrity is a process which allows two tasks (on separate systems) to be treated as an atomic function, that is, either both tasks succeed, or both fail. The embedded application maintains transaction integrity between the device, and the server using a hard drive queue. All transactions are queued to the hard drive first, then queued from the hard drive to the server. This protects against power failure and network disconnection.

To guarantee transaction integrity, the application favors accidental duplicate transactions versus accidental lost transactions. The server avoids duplicate billing, which weeds out duplicate transactions before the billing process starts. The embedded application only considers information from the device to be consumed after it is known that the transaction is queued on the hard drive. Also, the embedded application only considers a transaction queued from the hard drive after the server has acknowledged the reception of the transaction. If power or network is lost before the server acknowledges the transaction, the transaction remains queued on the disk. The application then makes continued attempts to deliver the transaction until the server acknowledges receipt.

If the device remains disconnected from the server for a prolonged period, unbilled transactions may accumulate. To mitigate this risk, the embedded application presents warnings on the front console which advise the administrator that unsent transactions have accumulated. The warnings are presented to all users during the login cycle. The warning appears in the following cases:

• When the number of accumulated transactions has reached or exceeds 50.
• When the number of days since last successful transaction deliver reaches or exceeds 30 days.

Transactions should not be allowed to accumulate indefinitely. It defeats the purpose of billing, and in extreme cases may eventually fill the hard drive of the device.