Manually invoke LMSCommit() on slide load with JS?

Hi,

I'd like to add "save points" to various slides within my course to ensure that learner progress is preserved as best as possible (e.g. guarding against a lost internet connection, failed race condition onwindowclose(), etc).

I see that I can execute arbitrary javascript using a trigger, and even that I can execute JS on "timeline start".  I tried setting this up and setting this:

LMSCommit()

...as the Javascript I want to execute, but nothing seemed to happen.  

Similarly, I'd like to add an "exit course" button to each of my slides, and again, I'd like the trigger on this button to do an LMSCommit back to the LMS, and *then* "window.close()" (I always open my courses in their own window).

Is there a way to do what I want?  I'm actually not 100% sure if "LMSCommit()" is even the JS command I want--what I want to do is send a "save the current state of the course; whatever that is" command.  My assumption is that LMSCommit() is that command.

Any help is appreciated.


Thanks,

Ben

40 Replies
Steve Flowers

Hi Mark - 

1. Nope. One is on the LMS side, the other is on the content side.

2. Yes. The rules for when something is written to the database is determined by the LMS logic. The content is sending it. It's being cached. When it's written is up to the LMS. May not be able to do anything about the way the LMS works. I don't have much experience with Saba but based on the other LMSs I've used (Inquisiq, SumTotal, PeopleSoft, Taleo/Learn, SCORM Cloud), the behavior of Saba is an outlier. Other LMS commit the data when it's sent. Otherwise they'd get into situations where suspend data and location aren't stored if a connection gets dropped. And connections drop, browsers crash, etc... a lot. 

3. That was in this post: http://community.articulate.com/forums/p/22517/123636.aspx#123636. Not really relevant since it referred to Storyline. 

I think there's a fix that can patch over Saba's behavior. Let us know in this thread if Saba can't work it out.

Mark King

So....per your post, there are, at least, two separate APIs. One on the LMS side and another on the content side. Can I interpret that to mean the API on the LMS side is owned by the LMS vendor and the one on the content side owned by Articulate?

I'm trying to pin down who might owe us a solution here. We can clearly see that the data sent by the SCO is correct. What I can't troubleshoot is why it isn't being written consistently to the database.

Thank you Ashley. We've already implemented the patch referenced in the link you provided. Unfortunately, that doesn't appear to be the source of our trouble.

We seem to keep dancing around these two fundamental questions.

1. Who owns the APIs, however many there are involved in the transaction?

2. Is the frequency of the LMSCommit() calls initiated by the SCO controlled by any software provided by Articulate? If yes, can it be modified?

TJ Buchanan

Question-  the company that built and maintaines our LMS uses .net for their courses.  We recently began using Storyline to buld courses in-house as opposed to paying the high costs of the LMS builders course developing service.  The good news is that they can and will be ptting our Storyline courses on the LMS for us.  The bas news is that they are saying we need a Java Script to be run so that the course will track progress properly.

I am definitely not tech savvy enough with coding to even know where to begin.  Please help, startning with the very beginning  (ex:  open storyline, click on xxxxx, you get the idea.

thanks for any and all help!

TJ Buchanan

Steve-  Here is specifacally what I have learned from the LMS developer...

"Ihave my developers looking at it right now, basically here’s what we have foundso far:

1)     The course will haveno tracking whatsoever if we take what was sent and we just put it on the LMSfor purchase. So the course that is purchased by the user will always be at 0%.Page completion will still exist within the shell during the current session,but the user will always have to use the same computer and never cleartemporary files for that to happen.

2)     To get the course togo from 0 to 100% complete (and nothing in-between) a JavaScript call will needto be added to the final page of the course, the entire thing will need to berepublished, then we will plug it into our LMS and test it. The user will stillhave to use the same computer and never clear temporary files for middle-pagecompletion but we will be able to track beginning and end completion.

3)     To get full pagetracking, a JavaScript call will need to be added to every page in the course,the entire thing will need to be republished, then we will plug it into our LMSand test. We know that JavaScript calls can be added into Articulate (thanks toGoogle) but we have not found out if JavaScript can be passed back into theshell. So this option is our best guess on how we will achieve full coursetracking.

Withall that being said, we don’t own a copy of articulate. If we give you thecalls and ask to put them at the end of the pages, is that an option? The onlyreal problem here is we won’t know where to tell you to put them exactly, sincenone of us have ever done anything with articulate we are unfamiliar with thatway of course building.

Whatwe are looking at now, is what it will take to get this course up for purchasewithin Personify. I also want to make sure there are no tracking calls that weare forgetting since it has been a while since we built a course using SWFs.

So,we’re on it J But still have a bitof digging before we have a final answer.

Inthe short term, do you know if (or how) you can add JavaScript to the end ofthe pages? If so, then we can test if the course can track as it should. Is weclear that hurdle, then all we have to tackle is how to make sure a user whohas purchased it can access it."

Drew Pruitt

Mark King said:

So....per your post, there are, at least, two separate APIs. One on the LMS side and another on the content side. Can I interpret that to mean the API on the LMS side is owned by the LMS vendor and the one on the content side owned by Articulate?

I'm trying to pin down who might owe us a solution here. We can clearly see that the data sent by the SCO is correct. What I can't troubleshoot is why it isn't being written consistently to the database.

Thank you Ashley. We've already implemented the patch referenced in the link you provided. Unfortunately, that doesn't appear to be the source of our trouble.

We seem to keep dancing around these two fundamental questions.

1. Who owns the APIs, however many there are involved in the transaction?

2. Is the frequency of the LMSCommit() calls initiated by the SCO controlled by any software provided by Articulate? If yes, can it be modified?


Great conversation on LMSCommit.  I am using a legacy LMS that SumTotal acquired several years ago called Pathlore.  Believe it or not they still even update it although you cannot purchase it as a new customer. The SCORM 1.2 or 1.3 communication with this LMS has always challenged me.  We have used a variety of authoring tools over the years (Captivate, Storyline, Presenter, Toolbook) and regardless of our own scripting to call additional LMSCommits they do not update the database immediately.  It seems to communicate to a persistent storage cache layer "in the middle" between the SCO and the true LMS database.  It creates a batch of values that  seem to be gathered and submitted to the true database at the end of the course.  I have attempted to create a custom close button in Storyline that executes Javascript and commits data to the LMS and then exits the course, but it does not work accurately.  When I close the browser window it communicates successfully every time.  Very frustrating.  My next test is to execute more javascript to simulate the closing of the browser and see if that invokes a "batch submit" of values.  If that works I can update the database at will with my LMS.  

Justin Grenier

Good Afternoon Mark, and welcome to Heroes!

Storyline 2 will send a keep-alive message to the LMS every 10 minutes by default, and this keep-alive message includes Suspend Data that will help the LMS recover from a learner's session that has been suspended for any reason.  A great way to verify that this keep-alive message is happening is to enable LMS Debug Mode so that you can watch the communication flowing across the wire.

Although we can't support the modification of published output, Gerry hints here at how you might go about modifying the frequency of that keep-alive message.

The conversation Ben started (above) talks about how you might configure a JavaScript Trigger to invoke an LMSCommit() upon the load of every slide, but this feels like overkill to me, and Storyline's default keep-alive message should be more than enough.

I'd recommend enabling LMS Debug Mode and using the resulting debug log to show the keep-alive message to your LMS Admin.  If you need any help interpreting those logs, please feel free to send us a copy for a closer look.

Please let us know if you need anything else, and have a great day!

Robert Edgar

Hi Mark,

My current practice is to include the JavaScript trigger LMSCommit() in a layer that holds only it and a small, light text that says "Loading" in the lower right of the screen.

The "Loading" text is extremely helpful for checking whether or not each screen's layer is triggering upon playback in the LMS.

Putting it on a separate layer, instead of the base layer, allows you to set the separate layer to "Resume Saved State", without forcing you to do that on the base layer.

I've attached a .pdf with the procedures I use for doing this. It takes some time to do, but frankly for us it was absolutely necessary, and for those of us who had to answer tickets about course status' being "in-progress" even though the learner finished the course, it has been extremely helpful.

Note that you can test your work by launching your course through the LMS, working into it a few screens, then turning off or unplugging your wifi connection. Click ahead a screen or two, and your "disconnected" message should pop up. Note that this will not work with Safari, but we've found that Safari will sense a disconnect almost immediately with its own code, and will provide its own message to the learner upon disconnect.

Hope this is helpful,

Robert

Robert Edgar

Program Manager, Learning Systems Design

Stanford | University Human Resources | Learning Solutions Group