Storyline 1 and 2 TinCan publishing differences?
Dec 15, 2014
I have a web service that picks up TinCan output published by Storyline. It works great in Storyline 1. The webservice parses the JSON (content, Authorization, statementId, etc.), and formats TinCan statements out of these streams. My web service has ResponseFormat = WebMessageFormat.Json. To figure this out originally, I looked at Fiddler output and saw the story POSTing GET and PUT statements.
When I run a story published by Storyline 2, I always get a 405 Method Not Allowed error on the first PUT. The Fiddler output looks pretty much the same, with a couple of differences:
1. Storyline 1 publishes OPTIONS statements, which I just ignore. Storyline 2 does not -- so this shouldn't make a difference.
2. Even though the Content-Type is application/json in both cases, I notice that the Content-Type of the Entity Header in Storyline 2 is text/plain, whereas in Storyline 1, it's application/json.
I'm not sure if this is the issue. Can you tell me what other differences there are? I know that Storyline 2 now publishes for TinCan 1.0 and not .9. But what could cause my 405 error just with Storyline 2? I know 405 errors are generally IIS configuration issues, but Storyline 1 works great in the same site.
I noticed another post that nobody every answered:
Thanks for your help.
5 Replies
I did notice something interesting that is undoubtedly the cause of the problem. With Storyline 1, I see:
http://localhost/MyService/MyService.svc/xxxxxx/statements/?method=PUT
With 2, I see:
http://localhost/MyService/MyService.svc/xxxxxx/statements?method=PUT
There is no slash after statements in the second one. Now I have to figure out why and what to do about it.
Is this a bug in Storyline 2? Shouldn't it end in a slash?
Good Morning, Frank.
SCORM Cloud is an industry-standard tool for testing Tin Can API output. Have you tried testing your content there to see if you run into similar issues?
If the content also fails within SCORM Cloud, this is something that we would generally escalate to our Quality Assurance Team for further investigation. Otherwise, this may be an LMS-specific issue.
Please let us know if you need anything else. Thanks!
Also Frank, if you take a look at the Communications section of this document, you will see the following blurb:
Articulate content will report statements to the Tin Can endpoint as described under the section Cross Origin Requests in Internet Explorer in the Tin Can API. To summarize, if the endpoint is http://mycompany.com/TCAPI/endpoint/, then all statements will be posted tohttp://mycompany.com/TCAPI/endpoint/statements?method=PUT.
This change occurred in Storyline 2 when we jumped from version 0.9 of the Tin Can API specification to version 1.0 of the Tin Can API specification.
...hope that's helpful!
Yes - that's helpful. I had gotten it working earlier by changing the UriTemplate in my web service to take out the slash. I guess it's not a bug :-)
Thanks
This discussion is closed. You can start a new discussion or contact Articulate Support.