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 logs out, the embedded application polls the MFP for activity completed by the user. 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, it is a requirement that the embedded application not loose information about tracked user activity. To mitigate power failure, the embedded application works closely with the Canon MFP device mechanism that tracks job output. The mechanism is protected against loss of information from power failure. The embedded application interacts with the MFP device mechanism at three events:

  • 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.
  • Logout. All user activity is reported as soon as the user logs out, or the device times out the current login session.
  • 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 polls the device for any new activity. This helps deliver transactions for delayed activity, such as retries on outbound faxes, in a timely fashion.

There is a concept known as Transaction Integrity which allows two tasks (on separate systems) to be treated as an atomic function. Basically, either both tasks succeed, or both fail, but not only one. The embedded application maintains transaction integrity between the MFP engine, 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. Duplicate billing is avoided by the server, which weeds out duplicate transactions before the billing process starts. The embedded application only considers information from the MFP engine to be consumed after it is known that the transaction is queued on the hard drive. If power is lost after queuing, but before the information is marked consumed, the information will again be converted to a transaction when the MFP reboots. 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 will remain queued on the disk. The application will make continued attempts to deliver the transaction until the server acknowledges receipt.

If the MFP 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 is presented 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 MFP.