Posts Tagged ‘getLaunchHistory’
SCORMCloud maintains launch history, but so does Bright.
But they are totally different animals.
In SCORMCloud, launch history is recorded, in Bright launch history is ‘captured’.
HUH WHAT!? Yer talking …… MADNESS!!!!
But all kidding aside, what’s the difference [there are lots of Bright blog posts with this theme]?
- in SCORMCloud, a course has to write its own ‘launch history’ data. So if its a TinCan course, for instance, there’s no launch history. Also for misbehaving courses, you may also get no launch history. In the world of debugging, this can be a big bummer.
- for Bright, we capture the fact a course has been launched before it happens. This means that you get launch history for TinCan and you get it even if the course didn’t load correctly.
That’s what I mean the difference between recorded and captured.
So we does the Bright launch history include? Lots of goodness! Check it out:
Now this is just formatted JSON like is returned from the Bright API:
- id – that’s just an internal reference. Unlikely to be of much use.
- registration_guid – for SCORMCloud, that’s the registration ID. For other types of course providers, the unique ID for that resource.
- course_guid – for SCORMCloud, that’s the course ID. For other types of course providers, the unique ID for that resource.
- learner_id – that’s the user. Hi!
- launch_source – what requested the launch; or the client type.
- http_referer – this is the page we launched off. It’s the where. Click it, it should be live!
- http_user_agent – the holy grail. User agent. YES!
- remote_addr: IP address of where the launch was requested. Also highly useful and also not available from SCORMCloud.
- request_uri: the actual request generated to the Bright server. Just guts.
- created_at: when?
- provider_launch_url: see below
So there’s some REAL magic here in the provider_launch_url. Since we capture this, we now can provide introspection to running courses. If they can grab their own location [via window.location from javascript], they can do their own logging by holding onto the window URL and logging it.
You can then backtrack via Bright to the original learner id and registration ID. Already we’ve built some really amazing tracking with this…. and the possibilities are quite breathtaking.
What’s next? Recording the registration state before and after the launch. That will be too cool and will provide great insight.
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….
