The purpose of this series of articles is to provide an easy to understand technical explanation of how exactly the SCORM protocol works. One of the things that greatly surprised me when I first began working with SCORM was that there seemed to be a surprising lack of good, practical technical documentation.

Getting Started with SCORM: How does SCORM really work?

Coming from a heavy development background I was used to having either code samples available or a very clear explanation of a technology’s inner workings. When it came to SCORM the only information I could find discussed the protocol at a very high and theoretical level (such as the SCORM specification itself).  Uncovering the nuts and bolts of how data bubbled up from the SCO (e.g. the course) to the learning management system (LMS) seemed almost impossible.

That was nearly a decade ago and the availability of information has definitely increased since then. Even still, in the eLearning world the ins and outs of how SCORM actually works continues to be a bit of "black magic" that is hard to break into. I’m hoping we can begin to change that.

It’s tempting in this world of rapid content development editors, with hundreds of different learning management systems to choose from, to argue that unless you are building your own LMS or SCORM wrapper that you needn’t be bothered with this level of technical detail. I would contend that is a mistake. There have been countless times where understanding the interplay between SCO and LMS has helped me troubleshoot issues.  There is great value (regardless of how you build your courses) in understanding how the technology you are utilizing works and what its limitations are. 

So let’s start at the beginning. With SCORM,

How does information get from a SCO to the LMS?

The SCORM specification is generally broken down into several subsections. For our purposes we are going to be focusing on the “Run time environment” (also referred to as RTE) subsection.  Run time is what happens when a user wants to launch a SCO – it describes how a SCO should be launched and how communication between the SCO and the learning management system (LMS) should operate. Please keep in mind that all run time communication between the LMS and the SCO is handled with JavaScript.

Per the specification, when a user launches a course from a LMS the first thing the SCO does is utilize JavaScript to look for the SCORM API. “API” might sound complicated, but really the API is simply a JavaScript object (which to make things easy for developers is always named “API”) that the LMS provides for the SCO to interface with. The API object is defined by the LMS and the SCO simply needs to reference it.  If you want to see a real working example of how the SCO finds the API, you can review the getAPI() function in the sample SCORM wrappers provided by the ADL (http://www.adlnet.gov/adl-releases-scorm-version-1-2-and-scorm-2004-api-wrapper-files). Please take heart - out of all the topics we are going to cover the API concept is one of the most challenging to understand.

Once a SCO has found the API it can then request or send data to the LMS.  It’s worth noting here that the SCO is always the one initiating the request.  It asks the LMS when it needs information or tells the LMS when it wants to send information. The LMS passively waits for the SCO to make these requests. The API has access to the following 8 basic functions (which are defined in the SCORM spec).  Please note the name of these functions varies slightly from SCORM 1.2 to SCORM 2004).

  1. LMSInitialize
  2. LMSSetValue
  3. LMSGetValue
  4. LMSCommit
  5. LMSFinish
  6. LMSGetErrorString
  7. LMSGetLastError
  8. LMSGetDiagnostic

Most of these have a relatively descriptive name that gives you an idea of their purpose – As always the devil is in the details, so we will be delving into these specific functions in much more depth in future articles.

You may also find useful:

Getting Started With SCORM: The basics of initializing/closing a SCO and sending/receiving dat

a