Posts Tagged ‘TinCan’
After a long amount of foot dragging …. Bright now polls and stores xAPI/TinCan Statements. What is in all of this data? That remains to be seen; but for the moment, at least there’s a somewhat consistent structure to it.
In the past, we’d have to go spelunking into a course production tool’s activity storage format, which usually turned into some sort of bizarro XML-parsing exercise.
The first step of what is sure to be a long adventure.
Sounds easy right?
Not so fast!
The state of the state is that how exactly to do this is yet to be defined.
This means for TinCan adopters, our recommendation is to hold fire for the moment.
See also:
https://github.com/adlnet/xAPI-Spec/issues/170
If you read through this thread, you can see its pretty much TBD at this point although Rustici does have a recommendation.
Also:
https://github.com/adlnet/CMI-5_Spec_Current/blob/master/cmi5_runtime.md#content_launch
https://github.com/RusticiSoftware/launch/blob/master/lms_lrs.md
Back before TinCan, you could make a SCORMCloud API call like this:
http://cloud.scorm.com/api?method=rustici.registration.getLaunchHistory &appid=myappid®id=myreg001
and you get a nice XML document like this:
<launchhistory regid="e222daf6-6005-4344-a07e-0aaa46b21dc9">
<launch id="c7f31a43-706a-4f43-8ab9-ebbf0dde4cbc">
<completion>complete</completion>
<satisfaction>failed</satisfaction>
<measure_status>1</measure_status>
<normalized_measure>0.2</normalized_measure>
<experienced_duration_tracked>2628</experienced_duration_tracked>
<launch_time>2011-04-05T19:06:37.780+0000</launch_time>
<exit_time>2011-04-05T19:07:06.616+0000</exit_time>
<update_dt>2011-04-05T19:07:06.616+0000</update_dt>
</launch>
<launch id="fc80087b-0fde-4263-8a89-29bee96eb65a">
<completion>unknown</completion>
<satisfaction>unknown</satisfaction>
<measure_status>0</measure_status>
<normalized_measure>0.0</normalized_measure>
<experienced_duration_tracked>2628</experienced_duration_tracked>
<launch_time>2011-04-05T19:15:51.177+0000</launch_time>
<exit_time>2011-04-05T19:15:59.450+0000</exit_time>
<update_dt>2011-04-05T19:15:59.450+0000</update_dt>
</launch>
<launch id="ffd2d304-439c-4c59-8be8-5d3fc1eb3f92">
<completion>complete</completion>
<satisfaction>failed</satisfaction>
<measure_status>1</measure_status>
<normalized_measure>0.27</normalized_measure>
<experienced_duration_tracked>10223</experienced_duration_tracked>
<launch_time>2011-04-05T19:16:07.214+0000</launch_time>
<exit_time>2011-04-05T19:17:25.294+0000</exit_time>
<update_dt>2011-04-05T19:17:25.294+0000</update_dt>
</launch>
</launchhistory>
If you been loading TinCan courses into SCORMCloud, you may have noticed that you no longer get any data from this!!!!
For example, we now just get this:
"<?xml version='1.0' encoding='UTF-8'?>\n<rsp stat='ok'><launchhistory regid='DiabetischeNeuropathied648d063-05b7-43e3-8b67-57568e329f4a-f59356563f5fd7e6104fe03d870c5007' /></rsp>"
So what’s the story? A lurking TinCan-ism that doesn’t match to SCORM? Probably.
So here’s the response from support.scorm.com ….
The Launch history, as it lives today, is focused around the SCORM API calls that are made by the content. Because the SCORM API is part of the SCORM player we have an opportunity to record those calls at the time they happen and format them into a readable log. For TinCan there is no player. This is a boon for content creators because it gives them far more freedom with their content than SCORM did but it has some limitations.
Those limitations all exist around the lack of a player for tinCan content. TinCan content exists in the browser outside of a player and sends statements back to some endpoint via existing http protocols which can’t be intercepted.
What this means is that you have two “views” of what might be considered launch history:
1) Statement Viewer – Statement viewer can show you all of the statements related to a registration. This represents all of the communication between the content and the ScormEngine that was *saved*. The only exception for this would be the state (replacement of suspend data) data which we only save the most recent value and don’t display in the statement viewer.
2) Browser Debug tools – Obviously these tools are only going to be useful when you’re testing a course live but they will provide more information than the statement viewer. Because all communication in TinCan will be handles by simple HTTP POSTS, PUTS and GETS you should be able to see all the successful and unsuccessful API calls including Statements and State.
This sort of illustrates what I’ve been saying to a few customers. If you don’t have a good reason to publish your course packages in TinCan format, SCORM packages will be a smoother landing, at least for the time being. There are a few reason for this….
