Recent changes to callout processing and history have caused us a few issues, most of which have now been resolved, at least one of which (display of the HTTP response code) will be addressed in the December patch. We use callouts to provision our services; that is, the licenses we provide to our customers for our server based software are created and maintained by callouts from Zuora. This makes callout functionality critical to us. In the past, we've had some issues with callouts that have caused us to monitor them on a daily basis, which in some ways may make our use of them different from most customers. With that in mind, here are some ideas we think might be helpful in improving callout functionality. Timeouts and retries are an issue in our environment. In the history display, it would be useful to be able to group attempts under each transaction, to see quickly and easily how many times a transaction was attempted and whether it finally succeeded. After a timeout occurs, it would be useful to "stagger" the retries, for example 2 minutes before the second attempt, 5 more minutes before the third, 15 minutes before the 4th, and an hour before the 5th. This is in case other processes are consuming bandwidth or server resources. 15 seconds is rarely enough time for our callouts to complete if the service being called has been idle for some time. Being able to configure the first attempt at a transaction to allow longer would be helpful. If the planned custom action by result type could be configured by HTTP response code and attempt number, we could perform custom actions only when a 5th response 408 was received (or whatever number we've set as the retry limit). The parse flag shouldn't determine whether a 408 response is correctly detected as a timeout. Our environment may encounter issues if sync processing is delayed or encounters an error. A manual re-attempt button from the callout history, perhaps only shown when the transaction has not succeeded on any attempt, would be useful. The ability to see the parameters and the responses as tooltips by hovering would be helpful to us. Our study of daily callout results could be more efficient. If callout history were a valid data source for reporting, we could construct custom reports to scan quickly for problems, and make those reports part of admin dashboards. With a report, attempts could be grouped under transactions (this could also be provided at the API level). Using a report, we could filter out multiple callout types and display multiple types, allowing, for example, a report featuring all subscription event caused callouts, but no others. 201 is a successful HTTP response code. Although we've programmed around this issue, it would be preferable if Zuora could recognize 200 or 201, possibly even 202, as a success, and display the response codes for Pass as well as those for Fail. Even better, allow selection at run time between showing Pass/Fail, actual HTTP response code, or HTTP response short description.
... View more
