QuickBooks Ruby Newsletter
|
I don't have all the details from last Thursday's major outage but my clients were saying that QBO transactions were showing up some 4 hours later (if at all). Those app's background job's would have failed well before that point so Intuit must have been queuing up the requests and then were replaying them as the services came back online.
This means there was a potential for duplicate transactions to have been made. Hopefully this wasn't the case for your app and its users but be prepared next time and make sure to leverage the requestid parameter.
- In the qbo_api gem you set
QboApi.request_id = true in your initializer. This setting will be true by default in version 2.0. This is a global setting and will apply to all POST requests, which mean it covers all API create, update, and delete actions.
- For quickbooks-ruby do this. You can call something like
SecureRandom.uuid to create the actual requestid and really it can just be implemented for transaction resource create requests (keep reading).
- From the article comments and other reports it seems requestid doesn't work with name list resources. I have never confirmed this one way or the other because it doesn't matter. Name list entities will not dup on a replay because the "DisplayName" ("Name" for Item, etc.) will be the same on the next replay and will get punted by the API as a duplicate. Transaction resources like Invoice, Journal Entries, Estimate, etc. don't have these uniqueness guards.
- The only real advantage I see of requestid is to not create duplicates in case of an outage, therefore, it is only really needed on create requests.
- Good article by Intuit's Peter Lavelle on Designing for Downtime.
|
|
|
|