How to Debug

Not all platforms are created equal

I typically advocate using the Inspector/FireBug/Console to review trace messages. Sometimes you don't have debug enabled. In those situations I recommend using my SCOverseer Bookmarklet. This was coded to work with SCORM 1.2, 2004 and AICC. I had to make it work from the top down, and the bottom up on a LMS Platform. SCO's are normally loaded within IFRAMEs, new Windows, new Tabs or nested neck deep in (cough) frame sets. So if you run into a issue using this bookmarklet make contact.

When using SCOBot with debug set to true, you'll see trace messages in the console.

SCOBotBase: Initialize Called. 
   version: 4.0.7
   modified: 03/11/2015 16:25PM

SCOBot: SCO Loaded from window.onload true
SCOBot: I am starting...
SCOBot: Launch Data:
SCOBot: First time running this SCO based on LMS entry value.

This lets you know SCOBot has started. Your version and date should appear letting you know which one your using. First run you'll see something like the above. If its the second, third or beyond time the student has come back to a SCO and you 'suspend' on exit, they will be in 'resume' entry when they return.

Launch Data

Launch Data can come from the imsmanifest.xml or possibly a edit made on the LMS platform if they do that sort of thing. Launch Data is commonly a way to extend the functionality of a SCORM centric options, and should not be confused with Launch Parameters (QueryString) values "grade=4&language=es&theme=dark" that might actually augment the look and feel. They both can accomplish similar things, but I typically try to make the distinction that I edit the SCO behavior with Launch Params, and the SCORM behavior with Launch Data. There are no rules though other than they must be in QueryString format. If you were expecting some and you didn't get it, this is where you'd see it in the log.

Mode

This is very important in SCORM 2004. You'll want to know if your in 'browse' mode as the LMS may not retain or persist any data and per the specification they aren't required to. 'review' mode will represent what the student entered to a teacher, or allow the student to review how they answered questions. Lastly, 'normal' mode which is the default behavior of a SCO that tracks and communicates status among other metrics to the LMS Runtime API.

Entry

When the student first enters the SCO cmi.entry should be 'ab-initio'. And if you 'suspend', when you return it should be 'resume'. Now if you exit normally without suspending, SCORM 2004 should reset you back to 'ab-initio' as this will be another try. A LMS may not track tries, and others may. They can also limit your retry attempts either in the imsmanifest.xml or if its supported within the Administration of the LMS.

[TBD other areas]

Exiting

SCOBot bakes in suspend, finish and timeout. These would be triggered uniquely based on the defaults.

SCOBot: SCO is being unloaded, forcing exit ...

This is a sign the browser is exiting. Or a popupwindow or tab. In single page apps, it may be a sign the IFRAME is unloading. What will follow after, is SCOBot going thru its spin down process.

1. log the type of exit
2. set the exit type
3. begin the termination process
4. log the completion and success status
5. commit the students data (save to the LMS)
6. log "Terminated"
7. log "SCOBot is done unloading"

Any thing that has to get done, has to occur prior to this getting called. Commit will save what ever has changed to the student attempt and once Terminate has finished that is the end of the communication with the SCORM Runtime.

If you are losing student data I commonly look to these messages as a sign something is getting interrupted. If you only receive partial traces in the console, it could be a sign the LMS is not allowing the content enough time to wrap up its work. It could also be a sign the LMS is not performing a 'synchronous' call to the backend server to store the student attempt resulting in data loss.