Javascript code for LMSCommit() SCORM 2004

May 08, 2024

I would like to submit a LMSCommit() command using JavaScript. Can anyone help me with the syntax? Which of the options for //submit data to LMS is best practice for SCORM 2004 version 4?

// connect course to JavaScript
var player = GetPlayer();

// connect to LMS API
function findLMSAPI(win) {
 if (win.hasOwnProperty("GetStudentID")) return win;
 else if (win.parent == win) return null;
 else return findLMSAPI(win.parent);
}
var objAPI = findLMSAPI(this);

// submit data to LMS (which one?)
lmsAPI.SCORM2004_LMSCommit();

lmsAPI.SCORM2004_objAPI.LMSCommit();

SCORM2004_objAPI.Commit("");

LMSCommit();

6 Replies
Joseph Francis

You can use the JS Function CommitData(); located in Storyline's API.js file, by calling lmsAPI.CommitData(); in your JavaScript.

If your LMS doesn't recognize that, you can try using SCORM_CommitData(); located in the SCORMFunctions.js file, by calling lmsAPI.SCORM_CommitData(); in your JavaScript.

Or, you can try using SCORM2004_CommitData(); located in the SCORM2004Functions.js file, by calling lmsAPI.SCORM2004_CommitData(); in your JavaScript.

John Cooper

Hi Todd,

Andrew is correct, the syntax for the commit statement is:

lmsAPI.Commit();

The Commit method typically takes an empty string as an argument and returns a boolean value "true" or "false" indicating whether the commit to the LMS was successful.
You might want to consider just checking the Commit  was successful:
 
var commitSuccess = lmsAPI.Commit();
if (commitSuccess !== "true") {
console.error("Failed to commit changes to the LMS");
}
Todd Haynes

Thank you: this line worked for me without error (returns "true").

SCORM2004_objAPI.Commit(""); 

LOL - I assumed this command sends all current course data to LMS, including "session_time". I have not yet confirmed the specific data that Commit() actually sends to the LMS.

Official definition:  Indicates to the LMS that all data should be persisted (not required).

Another: The Commit method signals to the LMS that a significant chuck of data has been saved and that it should ensure the data is properly persisted. 

So Commit() doesn't actually send course data, only signals to LMS it should consider a chunk of data (SetValue) sent?

Joseph Francis

Mike Rustici was quite candid when the question "LMSCommit... what does it do?" was posed about 15 years ago.

I received this question from a customer today:

Is there a mechanism for content to force the Scorm API Adapter to send data back to the LMS without calling LMSFinish()?  We did find a reference to LMSCommit() on the web but wanted to confirm with you that this would work.

Well, it sure sounds like that's the right answer, doesn't it? Contextually, it's important to understand that this question comes from one of our SCORM Engine customers (LMS side of things).

Technically, according to the standard, the LMS's behavior isn't substantially impacted by the call of LMSCommit. (LMSCommit, in particular, as part of SCORM 1.2, has little effect. In the SCORM Engine, when Commit (the SCORM 2004 comparable) is called, we invoke our look ahead sequencer, which might change the available links in the course menu. But that's SCORM 2004 only.)

Some LMS's are more substantially impacted though. Some wait for a call to LMSCommit to actually push data to the server. Others won't ever persist data unless that call is made.

In the SCORM Engine, the decision about when to send data from the browser to the server is governed entirely by the commit frequency set in the SCORM package properties. This invokes a method that assesses if there's any dirty data, and if it finds any, pushes it to the server.

https://support.scorm.com/hc/en-us/articles/206166206-LMSCommit-what-does-it-do

John Cooper

Hi Todd - Yes it's just a reassurance. We recently wrote a course where we took learner text input and used SetValue to insert the text in the cmi.comments_from_learner.n.comment SCORM Data Array. But the limit is 4000 characters per comment so, in case the learner typed more than 4000 characters we split the input into two entries. Since it was possible that the script could get interrupted having done part one and not part two we used the successful Commit to signal both parts had been written and the comment index (n) was properly updated - otherwise we could back the transaction out - it's just 'belt and braces'...