XML Exception - iUsageReporting GetReport method - Soap API
Original Post: Sean Ohlinger, July 9, 2019 at 8:48 AM
Good Evening All,
I have been trying to use the GetReport method through the Soap API and a C# script and have been receiving the following Exception.
_______________
System.ServiceModel.ProtocolException: 'There is a problem with the XML that was received from the network. See inner exception for more details.'
Inner Exception:
XmlException: The data at the root level is invalid. Line 1, position 1.
_______________
I'm relatively new to working with SOAP and C# but have managed to get authenticated and query all other methods in several of the services. I'm hoping someone with a little more experience might see my newbie mistake and point me in the right direction.
Currently, I have the authenticated client and call GetReport with the authentication and the reportID but get the above error.
I have tried using the default app.config file and creating my own bindings and endpoint (both methods work for all other methods).
_____________
Panopto_UsageReporting.AuthenticationInfo authInfo
= new Panopto_UsageReporting.AuthenticationInfo();
//Local login for test server
authInfo.UserKey ="XXUsernameXX";
authInfo.Password = "XXpasswordXX";
UsageReportingClient src = new UsageReportingClient();
StatsReportStatus[] reports = src.GetRecentReports(authInfo,null);
//this call is successful with a return type of StatsReportStatus List
src.GetReport(authInfo,Guid.Parse("10101010-1010-1010-1010-101010101010"));
//since GetReport does not return a value, I cannot assign it to a variable.
//just running it as the above causes the above error.
Responses
Mark Brewsala, Moderator, July 17, 2019 at 6:02 PM
Hello,
Sorry about the delay in response and confusion here!
The response from the GetReport API is actually a compressed stream of the report contents themselves. As such, the response is not a proper SOAP envelope, so any SOAP client will tell you the response is not well-formed.
The solution is to create your own HttpRequest, add a proper SOAP envelope to the request, and parse the raw response manually.
An example of this in Python has been available here:
https://github.com/Panopto/python-soap/blob/master/examples/stats_report_example.py
And for C-Sharp developers, we've just added this example:
Thanks,
Mark
Sean Ohlinger, July 17, 2019 at 6:49 PM
Thanks Mark,
This is a good start. I'll take a stab at it but I see with Net 4.5 (required in the SSIS environment I'm coding for) I will need to force set the security to TLS 1.0 or above.
Can you confirm the highest supported TLS setting?
I see you use the UserKey and Password for authentication. Is that recommended / more secure than an AuthCode?
Thanks again for the help!
Sean
Sean Ohlinger, July 19, 2019 at 1:23 PM
Hey Mark and All,
Ok, I was able to successfully download the report.
Based on my research, I believe calling the following code prior to the creation of the request forces the connection to use TLS 1.1 or 1.2 in Net 4.5:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 | System.Net.SecurityProtocolType.Tls11;
Also, I use both the envelope you provided and altered for using the AuthCode (below):
string.Format(@"
http://schemas.xmlsoap.org/soap/envelope/"">
xmlns:a=""""
xmlns:i="""">
{1}
{0}
{2}
",
auth.UserKey,
auth.AuthCode,
reportId);
Thanks again for your help!
Sean
Comments
I've just encountered the exact same problem. Under what circumstances, if any, will the GetReport work as all the other SOAP calls?
Hi Robin,
Since GetReport does not return a standard SOAP response, and instead returns the contents of the report, it would always work differently than our other SOAP API calls.
Please let me know if you have any questions.
Thanks,
Kevin
Thanks Kevin. I got the sample C# code you provided to work so it's no biggie. It should be better documented that it doesn't work as I wasted a bit of time over this. https://support.panopto.com/resource/APIDocumentation/Help/html/7f856457-d8d3-76b8-42d9-61c697008c42.htm
Hi Robin,
Thank you for the feedback. I've filed an internal item to update the documentation on that SOAP call and clarify that it's behavior is different than our other SOAP API calls.
Thanks,
Kevin