Fail Queues (FQ) and how they work

Sometimes things go wrong. You might have set something up wrong, there may have been a platform (NetSuite or Salesforce) outage or there may have been a fatal bug. This is where Fail Queues come in to play. Fail Queues are a sophisticated mechanism that consists of transactions that are stored locally (on the device) when an error has been encountered. The premise here is to introduce automatic fault tolerance once the issues are corrected. 

The Fail Queue Process

If a transaction fails to write, a copy is made locally (in background) and appended to Fail Queue. Another attempt is made on the next sync (after displaying a notification). Syncs can be as a result of the first login that happens on a given day, a manual sync or as a result of a "forced quit" of the App.

Each record is processed (in background) one at a time and if SUCCESS it is removed from the queue and if FAILED it remains in the queue.  Only when this record is processed does it move on to the next one; thereby avoiding overloading the system with concurrent requests all at once.

Transaction Failure

Transaction failures appear as "Red" in the search screen.

Processing the Fail Queue:

Troubleshooting Fail Queue Errors

In a lot of instances, failed transactions will simply get processed on the next sync. For the most part, the clerk will not notice anything and business is as usual. In some instances, the errors can be a bit more serious and requires further investigation.

Transactions failed to write (from Fail Queue):

If processing of the Fail Queue fails, clerk is then presented some options:

Retry - Process the Fail Queue again
Skip - Ignore the errors and continue
Send Log and Clear - This is not recommended (unless ALL troubleshooting is exhausted). This will send the log files via email and CLEAR the transactions
Send Log - Sends the log file to someone for further investigation

Send Log and Clear removes the transaction entirely. This means it will never be written to the platform and therefore has to be manually re-created (or journaled) from the log files (otherwise you could end up with credit card payments (or cash in the drawer) that has no corresponding transaction.

Investigating the log file

The log file is an Excel (xls) file that can be viewed. In this file there are summary columns of the transaction, the reported error and the JSON that was to be posted. 

Send Log File:

Example Log File:

The log file can give valuable insight in to what has caused the error and where to look. In the example above, we can see this was a NetSuite Script error.

A substantial amount of errors are caused by script errors at the platform level (NetSuite or Salesforce). It is always a good idea to have your admin look at the platform log files so that these errors can be investigated and corrected.

Fail Queue Audit Fields

The number of transactions in the fail queue when a Shift is OPENED or CLOSED is now stored both on the POS Shift record and also the POS Terminal record.  This allows you to monitor records that are stuck in the Fail Queues for specific Shifts or Terminals by creating a Saved Search or Report.

 

Correcting the Errors

In most instances the errors can be readily corrected and the Fail Queues can be processed again without issue. However, there may be situations whereby the errors are unknown and/or cannot be easily corrected. These needs to be reported to SuiteRetail Support.

As a reminder, the Fail Queue is processed synchronously (to avoid concurrency issues) - the system will allow you to continue to ring up sales however since this is performed in background.

Fail Queues are integral for our system to process transactions offline so that you can keep ringing up sales even though the internet (or the platform) may be down. They are not designed, however, for prolonged (multi-day) outages.

• Related Articles

• SuitePOS App notifications for the Failed Queues

  In some cases the transaction write (to NetSuite or Salesforce) will fail. These failed transactions are stored locally in the "Failed Queue" for processing again at a later time. Not only do we show this in the Settings screen, but we also display ...

• Socket Mobile scanner does not work correctly after pairing

  Even though the socket scanner may show as paired in bluetooth settings for the Apple iOS device, it may not properly scan in the POS. The scanner may read text and put data into the search bar of the POS, but, will not scan items directly into the ...

• NetSuite Script Error: Missing required field for index 0: custbody_spos_s4token

  This is a somewhat misleading (and very rare) error that primarily occurs in the SPOS_Sale script. It occurs when the integration to NetSuite has something wrong with the format that it is expecting. This is around field validation for required ...

• Customer and Item Sync's Revealed!

  SuitePOS is a very high performing POS App (running natively on an Apple device) that is well suited for retail environments with large transaction volumes. One of the cornerstones of speed is the development of sophisticated caching mechanisms. This ...

• Missing Transactions in NetSuite or Salesforce OR duplicate transactions in the merchant account

  From time to time credit card payments have been processed but the underlaying transaction has failed to write to NetSuite or Salesforce; or it is simply missing. The solution will depend on the underlaying cause. This may include: The transaction(s) ...