We have a middle tier that is processing the file stream and is waiting for the files to be proceesed through a loader program.File Streams are inherently error prone especially if the size exceeds 2 MB.
This capability will make it easier for the middleware to transform the payload back from Zuora into our internal systems.
@lukasz it's not about the 2GB limit, many of our daily stateless requests result in files having less than 5 rows, we now have to store the file in a file location and then write a CSV parser to get the data parsed and inserted into our DB. If the response was a JSON, our middleware can parse it and call a DB adapter to put the data directly in our database.
It's a much simpler interface. From your end, is there a CSV to JSON conversion that can be provided?
Ah, I see what you mean now. So, no, today, we don't have another format for the results from AQuA to be provided other than either CSV or Zip CSV. I believe we chose this format because it was ultimately meant for large extracts, and the idea that all responses would be consistent. Obviously, we have provisions for supporting other formats. I'll let the community here upvote the request. Thank you for getting back to me with the details of the issue.
I am in agreement with the need for JSON responses. These would be usefult to me as well.
A JSON reponse does increase the size of the response. However, the data gains structure which makes it better suited for automated handling, which I do as well. Advantages to JSON over CSV:
- JSON is definitely encoded in UTF8, CSV may have varied character encodings
- JSON has well-defined means of handling special characters in values, CSV does not
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
