Trigger Detail

The following information describes the triggers and how they are working when implemented.

Triggers

On RecordQueues table:

• CheckFailedOrderTrigger

• CheckStuckInProcessingTrigger

On QueuedEmail table:

• FailedOrderMarkConnectionErrorAsSent

How the triggers work

CheckFailedOrderTrigger – This trigger flags orders for reprocessing that fail due to certain connectivity reasons. It sets the order back to “Ready” status and increments the “Attempts” column to track the number of attempts. It will re-flag an order for re-processing 2 times. After 2 failed re-tries, the trigger will leave the order in a Failed state and send a notification email.

• These retries happen immediately after such a failure. All reprocessing will typically happen in less than 60 seconds.

• It can be determined that this trigger reprocessed an order if you see an “Attempts” of 1 or 2 in the Order Queue.

• The error messages that activate this trigger are in the trigger itself and can be modified if new connectivity errors are discovered.

CheckStuckinProcessingTrigger – If an order is ever “stuck” in a Processing status, this trigger will set it to “Ready” to attempt to send it through. This trigger only attempts a single time to reprocess such an order. It sets the “Attempts” to 99 in order to know that this trigger was used to reprocess such an order.

FailedOrderMarkConnectionErrorAsSent trigger – This works in conjunction with the CheckFailedOrderTrigger. It prevents failed order emails from being sent until the order has failed to reprocess 2 times and is now in a permanent “Failed” status.

Note: These triggers were tested internally for quality and load and passed testing.