SCORM runtime: explanation and examples (2023)

Overview of the SCORM runtime environment

The SCORM runtime specification controls how the LMS launches content and then how the content communicates with the LMS. All of this communication takes place in the context of a single attempt from a single SCO. the navegationin betweenSCOs are subject to the sequence specified in the manifest and explained in more detailHere.

post content

All SCORM content must be delivered over the Internet, and all SCORM communication takes place in the context of a web browser session. The LMS launches one SCO at a time, as selected by the user or specified by SCORM 2004 sequencing rules. In versions prior to SCORM 2004 3rd Edition, there were no formal requirements for the user interface provided by an LMS. Every LMS is a bit different, but in most cases it's fair to expect an LMS to offer an interface similar to the one below. It should contain at least some sort of navigable table of contents, as well as flow navigation controls (previous and next buttons). These navigation elements control navigation between SCOs. If navigation is required within a SCO, the SCO must provide its own navigation elements.

The LMS has two options for starting a SCO. You can launch the SCO in a frameset (as shown above) or in a new window. Some LMS always publish content in one form or another. However, if a course contains only one SCO (and therefore does not need any LMS navigation elements), the SCO is usually launched in a popup window. On the other hand, if the course contains many SCOs, the LMS will typically launch the SCOs in a set of frames surrounded by navigation elements. Some LMS allow content authors to control exactly how SCOs are launched, which navigation elements are available, and even the size of SCO windows.

die API

All communication between a SCO and the LMS is done through an ECMAScript (JavaScript) API. this is itfairhow communication occurs. Other communication channels are not available. Content cannot be communicated through web services, form posts, database writes, or any other mechanism, only through the JavaScript API provided by the LMS.

(Video) What is SCORM?

Search API

The LMS is responsible for delivering a specially named JavaScript object to a specific location in the browser's DOM. Therefore, the content can always find this API using a common algorithm.

In SCORM 1.1 and SCORM 1.2, the API object is always called "API". In SCORM 2004, the object is called "API_1484_11".

Using API

Once a SCO finds the SCORM API, it can use the API to communicate with the LMS. Note that only the SCO can initiate the communication. The LMS is a passive entity that simply responds to API calls from the content. The LMS cannot initiate any communication, it just launches content and responds to requests.

The SCORM API contains eight methods with the following signatures:

(Video) What Is SCORM & How Does It Work?

SCORM 2004

Initialize( "" ): bool Terminate( "" ): bool GetValue( elemento : CMIElement ): string SetValue( elemento : CMIElement, valor : string): string Commit( "" ): bool GetLastError() : CMIErrorCode GetErrorString( errorCode : CMIErrorCode ) : Cadena GetDiagnostic( errorcCode : CMIErrorCode ) : Cadena

SCORM 1.1 / SCORM 1.2

LMSInitialize( "" ): bool LMSFinish( "" ): bool LMSGetValue( elemento : CMIElement ): cadena LMSSetValue( elemento : CMIElement, valor : cadena): cadena LMSCommit( "" ) : bool LMSGetLastError() : CMIErrorCode LMSGetErrorString( errorCode : CMIErrorCode ) : Cadena LMSGetDiagnostic( errorcCode : CMIErrorCode ) : Cadena

Method names vary slightly between SCORM versions, but conceptually the methods are identical.

Comments:

The bool type is a SCORM boolean, which is actually a string with the value "true" or "false".
The "" parameter is required for all SCORM methods that do not accept other arguments. SCOs only need to pass an empty string parameter to these methods.
The CMIElement data type is a string that corresponds to the SCORM data model elements described below.
The CMIErrorCode data type is a three-digit number represented as a string that corresponds to one of the SCORM runtime error codes.

Initialize / LMS Initialize

The Initialize method tells the LMS that the content wants to start a communication session. All SCOs must call Initialize before doing any other communication. The LMS returns a boolean value indicating the success or failure of the initialization. Normally, the LMS does not need much initialization and always returns true.

Exit / LMS End

The Finish method tells the LMS that the content transfer is complete. All SCOs should call Terminate. Calling Terminate does not necessarily indicate that the user is done with the SCO, technically it just indicates that the SCO has finished communicating. In practice, however, calling Terminate only when the content can be removed from the user makes the content more compliant and usable. Since Terminate must always be called regardless of how the student exits the SCO, it is a good idea to call Terminate on a SCO download event. The boolean value returned by the LMS usually indicates whether or not the SCO data was successfully saved to the server.

Get Value / LMS Get Value

The GetValue method allows a SCO to retrieve data from the LMS. The data that is always retrieved is one of the defined elements of the SCORM data model. Each of these data model elements contains a different data element. Some of the data model elements have values initialized by the LMS that indicate the circumstances under which the SCO is launched. The SCO initializes other values through calls to SetValue. If calling GetValue returns an empty string, an error may have occurred and the GetLastError method should be called to check for problems.

(Video) What is SCORM?

DefinirValor / LMSSetValue

The SetValue method allows the SCO to store data in the LMS. The data is always stored in one of the defined SCORM data model elements. Some elements of the data model are restricted to having values in a limited vocabulary (for example, the status can be "complete" or "passed"), others are restricted to a specific data type (for example, the score must always be a number). others allow the SCO to store free text data without semantic meaning. The SetValue call returns a boolean value that indicates the success or failure of the call.

Confirmar / LMSCommit

The commit method tells the LMS that a significant amount of data has been saved and that it must ensure that the data is preserved correctly. There are no requirements on how the LMS should implement the confirmation method, it's just an informational signal. Some LMS perform a round trip to the server for each commit call to ensure that all data is persisted. While this deployment strategy is intuitive, it can lead to scalability issues. Be careful not to overload the confirmation to avoid overloading this LMS.

GetLastError / LMSGetLastError

The GetLastError method checks if the last SCORM API call caused an error. In this case, this method returns an error number that corresponds to a defined set of possible errors. Some error numbers represent perfectly legitimate situations (for example, 403 - data model element not initialized). SCO authors should be careful to only report bugs that are legitimately unexpected to the user. The full list of error codes can be found atSCORM Runtime Benchmark Chart.

GetErrorString / LMSGetErrorString

Given an error number (usually the error number returned by GetLastError), the GetErrorString method returns a textual description of the meaning of the error code. For example, in SCORM 2004, passing the error number "406" will return a string named "Data model element type mismatch" to indicate that the result of the previous call (probably a SetValue) failed because the data stored they were in the wrong format. .

GetDiagnostic/LMSGetDiagnostic

The GetDiagnostic method allows the LMS to return detailed information about the previous error that can help diagnose the problem. For example, the diagnostic information for the "406" error mentioned above might say "The value 'null' is not allowed for cmi.score.raw. The element cmi.score.raw must contain a valid number represented as digits only." .

The SCORM Runtime Data Model

The runtime data model contains many elements, each with its own meaning. Elements can be read and written via the API. The SCORM Runtime Reference Diagram contains a list of all data model elements along with their data type and a brief description of their meaning and usage.

Each SCO has its own runtime data set. Each of these data model elements has a separate value for each SCO within a course, the data model elements are not shared among all SCOs. Also, each "test" in a SCO has its own set of runtime data. When the student starts a new attempt with a SCO, the data model values are reset to start the new attempt.

(Video) SCORM The Basics and Beyond

Data model elements differ slightly between SCORM versions, but most of the time there is a corresponding element in each version of the standards. SCORM 1.1 and SCORM 1.2 have identical data models. SCORM 2004 has a different set of data models. There are also minor differences between SCORM 2004 editions. The table provides a complete reference for each version/edition. Major changes in SCORM 2004 include:

Minor name change, mainly removing the "core" from the data model element names.
separation of states. In SCORM 1.2, a single element, cmi.core.lesson_status, represents the status of the SCO. In SCORM 2004, status is divided into two separate elements, cmi.completion_status (completed vs. incomplete) and cmi.success_status (passed vs. failed).
Interactions (question results) are read-only and not read-only. Interactions also contain a description field, which was missing in SCORM 1.2.
Added adl.nav.* data model elements that allow SCO to initiate sequencing requests

Runtime Usage

Using the SCORM runtime is largely optional from a strict compliance perspective, but the industry standard is to use at least a subset of the runtime data model elements available to you.

In the simplest case, no runtime calls are needed if your course only contains runnable elements. The LMS simply launches each asset as requested by the user and the asset is considered complete immediately after launch.

For a richer interaction, we must first enable communication at runtime. This involves finding the API and making sure that Initialize and Terminate are called. In most cases, Initialize should be called immediately after starting the SCO. After calling initialize, make sure you call Finishoneexit scene

Once the communication has been initialized, it is time to start the actual data transfer. The following Tier 1 data model elements are the most important and commonly used (SCORM 1.2 equivalent in parentheses):

cmi.completion_status & cmi.success_status(cmi.core.lesson_status): These elements of the data model are the most basic and important. They show when a user completed a course and whether they passed or failed. This basic information is essential for most LMS.
cmi.scaled.score(cmi.core.score.raw) - Indicates the score that the student obtained in an assessment within a SCO. Specifying a minimum and maximum score along with a raw score is also considered polite.
cmi.session_time(cmi.core.session_time) - Indicates the time the learner spent in the SCO.
cmi.location(cmi.core.lesson_location): Provides a free text field for the SCO to register a marker. If the SCO is longer than a few HTML pages, you should consider implementing a markup feature so that the student can resume a paused experiment.
cmi.exit(cmi.core.exit): This value specifies how the student exits the SCO. Setting cmi.exit to "suspend" ensures that the current intent is preserved and the runtime data is not reset the next time the SCO is started. Setting cmi.exit to "" indicates that the LMS should retry with a new set of runtime data the next time the SCO starts.

The industry standard expects all elements of the Tier 1 data model in a SCO to be used correctly. Once this functionality has been enabled, the following most common or second level data model elements include:

interactions– Use elements of the interaction data model to report the results of each response to the question. An interaction does not have to be a traditional test response. For example, a SCO can document student decisions during a simulation. Whenever possible, use all of the interaction elements to get the most complete picture of student responses. Use at least "ID", "Type", "Result" and "Description" for the LMS to provide basic reporting.
Goals– In large SCOs, consider reporting student mastery of specific learning objectives using data model elements for the objectives. Objectives allow for more detailed reports on learner progress and mastery of training material.
cmi.measure_of_progress- Use the Progress_measure element in SCORM 2004 to report the user's progress in completing a SCO. Progress_measure is like a "Percent Complete" measure that would allow the LMS to provide a progress bar for the overall completion of a course.

Entry, mode and credit

The data model elements cmi.entry (cmi.core.entry), cmi.mode (cmi.core.lesson_mode), and cmi.credit (cmi.core.credit) provide the SCO with a context that it can use to inform the learner deliver the optimal experience.

(Video) What is Scorm | Introduction to Scorm | Course Authoring | E-Learning

cmi.inputindicates whether the user is starting the SCO for the first time or resuming a previous attempt. When using placeholders, the SCO can use this value to prompt the user to restart or to restart from the point where the previous attempt ended.
cmi.wayindicates whether the learner initiates this SCO: typically, in a "live" training session; in browse mode: the user is browsing a training catalog and wants to "see" that course; o In review mode: the user has already completed the SCO and returns to review the material. In navigation mode, the SCO author should consider changing the behavior of the SCO to allow for freer navigation, provide an overview or map of the course, and possibly hide grades. Similarly, in review mode, the SCO author should consider allowing complete freedom of navigation. In review mode, the student can also freely navigate through all tests and browse a list of correct answers. When starting a SCO in review mode, care must be taken not to change the student's status or reset the score.
cmi.creditindicates if this SCO is a credit attempt or if it "counts" or not. Similar to browse mode, the behavior should probably be changed when starting a SCO with no credit.

SCORM Runtime References

SCORM API detection algorithm
SCORM Runtime Benchmark Chart- Comprehensive cheat sheet for the entire SCORM runtime, including API signatures, a complete list of data model elements, and a list of all SCORM runtime error codes.

Examples at runtime

See our sample SCORM packages for runtime examples