Hello,
It seems that the JSON output from the stored procedure execute function (Custom/Execute) has changed again from Version 14.1 to version 15.0. This broke a bunch of custom stuff I had created here for MAP (yes, I failed to test some of this stuff during our testing phase of version 15, that is my bad).
To be more specific, it seems that the data is no longer being returned as an array within a tag label (called "Table"), but instead is being returned directly as a non-labeled array..
Here is an example of a multi-row result set from the call:
V14:
{"Table":[{"perf_no":"40048","perf_dt":"2019-05-01T13:30:00-05:00","perf_code":"TT17-BUS","perfname_desc":"Two Trains Running","facility_desc":"Rep QP"},{"perf_no":"43823","perf_dt":"2019-05-01T19:30:00-05:00","perf_code":"EB21","perfname_desc":"Every Brilliant Thing","facility_desc":"RP ST Arena"},{"perf_no":"39782","perf_dt":"2019-05-01T19:30:00-05:00","perf_code":"RF45*****","perfname_desc":"Ring of Fire","facility_desc":"Rep Stackner"},{"perf_no":"40049","perf_dt":"2019-05-01T19:30:00-05:00","perf_code":"TT18","perfname_desc":"Two Trains Running","facility_desc":"Rep QP"}]}
V15:
[{"perf_no":"40048","perf_dt":"2019-05-01T13:30:00-05:00","perf_code":"TT17-BUS","perfname_desc":"Two Trains Running","facility_desc":"Rep QP"},{"perf_no":"43823","perf_dt":"2019-05-01T19:30:00-05:00","perf_code":"EB21","perfname_desc":"Every Brilliant Thing","facility_desc":"RP ST Arena"},{"perf_no":"39782","perf_dt":"2019-05-01T19:30:00-05:00","perf_code":"RF45*****","perfname_desc":"Ring of Fire","facility_desc":"Rep Stackner"},{"perf_no":"40049","perf_dt":"2019-05-01T19:30:00-05:00","perf_code":"TT18","perfname_desc":"Two Trains Running","facility_desc":"Rep QP"}]
And here is an example of a single-row result set from the call:
{"Table":{"AppIterationCount":"102385"}}
[{"AppIterationCount":"102427"}]
To fix this quickly, rather than re-factor the custom code everywhere that depend on this procedure running in both windows and android environments, I created a crude function in my API abstraction layer that would look for the v15.0 response (an array) and make it look like the output expected from V14.1. Of course this is not ideal, but it works for now.
If you are interested in this code for C#, you can find it here: https://bitbucket.org/snippets/hfeiges/aeXe5E
Hopefully that works for all cases (please let me know if it doesn't work for you, and I will try to fix it).
Anyhow,
... I seem to remember something similar when we upgraded from V12 to V14 (or maybe that was from 14.0. to 14.1), but that was a while ago and I don't remember the details any longer. Perhaps this is how the output was formatted back in V12 and it changed for V14 and is now reverting back to the way it was.
So my question for Tessitura is:
Is this output from the custom/execute function going to change with each iteration of Tessitura?? Is this mentioned in some documentation somewhere that I did not see? Was this change intentional?
If I can be assured that the output will remain this way, then I will go ahead and re-factor all the code that utilizes this procedure in my customizations, rather than relying on that crude hack that alters the JSON output string like I am doing now.
I can see now, that the "Parameters" object in the LocalProcedureRequest object are going to be depreciated for V16, so I know I will need to at least re-factor setting the parameters, but how about the JSON output from the procedure? Is that going to change as well??
... Thank you for your guidance
Howard Feiges : DBA and software developer : Milwaukee Arts Partners
Howard, take a look at Custom/Execute/MultipleResultSets and see if that solves this problem for you. You might even be able to just swap it out where you used to call Custom/Execute. Changes were made in v15 to make the output of Custom/Execute more consistent if I recall; it used to return differently formed data when there was one item than when there were multiple items so that's why MultipleResultSets was formed.
I know you've asked about more than that here, but I couldn't help but wonder if that might solve your problem so I wanted to mention it. I will follow up on your other question next week.
Here is the full featured answer from development, Howard Feiges
We changed the response object structure because there was a bug that would cause the result to be inconsistent when returning a single entity or a collection. Unfortunately, several people had already coded around this inconsistency so for them, this would manifest as a breaking change.
We honestly spent a lot of time discussing if we should do this because we knew it would cause code breakage, but decided in the end that the consistency was worth it. Also we then discovered that in SOAP we supported multi table results but in REST we never really did, and in fixing this inconsistency we actually broke the hacky way some folks were able to still make that work. That is why we added the new MultipleResultSets call.
The long and short of it is, no - we do not expect to continue to change this endpoint, but that is not to say we never will. We understand that each of these changes are difficult and require devs to update their client code, so we think hard about if the resulting benefit is worth that pain.
In the future we hope to use the path we took with the parameters object in this call as an example. We added the new object in a previous version, and messaged that the old way would leave soon. Then in the current version we marked it deprecated in code so you would get compiler warnings, and finally in the next version we will actually remove it. This gives a rather large window for devs to respond to change.
All of this said, we may still need to change things with less notice from time to time, but that decision will be again based on a cost/benefit analysis that takes into account the pain of change for client devs.