FORCED_COMMIT_TIME value of 60000 (60k)

Thanks Ashley,

We've got our own LMS which is hosting SL2 courses.  We're getting occasional cases where users complete the course (got a printout of the certificate etc.) but we've not got a record on our LMS.  

We've noticed that if there is a communication failure writing the SCORM data back via our API Adaptor, the exception is caught (in our adaptor) and logged but we're not alerting the user to the problem.  We're testing a fix for this (including a retry option).  

However we're unsure about whether the heartbeat LMSCommit()s from SL2 are being fired or not and if they are whether they are doing so at the frequency given by FORCED_COMMIT_TIME.  Certainly they don't appear to be happening as frequently as 60000ms (=1 minute) - which is a value which we would be happy with BTW.

Thanks,

Chris

If my memory serves me well, I believe this was set high so as not to add an overhead to the LMS, I also understand you can change this to any value you are happy with.

Thanks Phil.  I know we can change the value (a simple edit to the js file) and why you may not want to set the value too high or low.  I'm just questioning whether it is actually being used by the course and if it is, whether it is treating the units as milliseconds.  

The reason I question it is because I can't see anywhere where any JavaScript actually reads this value and the rate of LMSCommit() don't seem to tally with the value set.

Okay, I think I can give a clearer example of the problem.

I have an LMS-published SL2 course with default configuration.js settings including  FORCED_COMMIT_TIME=60000 (60000ms = 1 minute)

On my LMS, whenever an LMSCommit() call is raised by the course, I log the time into a log window.  I run the course and let it sit idle.

My log looks like this...

...
LMSCommit()
Time=10:42:51
...
LMSCommit()
Time=10:52:52
...
LMSCommit()
Time=11:02:52
...
LMSCommit()
Time=11:12:52
...

Clearly 60000ms = 1 minute does not equal (11:12:52 - 11:02:52) = 10 minutes, so either SL2 is incorrectly interpreting the 60000 as 60000 hundreds of a second = 10 minutes or it is ignoring the value completely and using a default/hardcoded value (which is what I suspect as I cannot see any other reference to FORCED_COMMIT_TIME in any other Javascript file in the course)).

Is there a means for me to raise this with Articulate at a technical level?
Thanks,

Chris

Hi Chris,

I double checked with our team, that the 60000 = 10 mins in Articulate for the LMS Commit time, and you'll see another thread with that time mentioned here. 

If you'd like to see the data we're passing to your LMS, I'd recommend enabling LMS debug mode as detailed here. If you're still having difficulty with it and would like to investigate further with our Support Engineers we're happy to do so and you can reach out to them here. 

Hi Ashley,

Thanks.  That has explained a lot of what is going on (despite being related to Studio '09).

I've checked the lms.js file that SL2 packages up with the course and found:

setInterval("ForceCommit()", 600000);

So,

1. SL2 uses a 600000ms (10 minute) interval rather than a 60000ms (1 minute interval)
2. SL2 is NOT using the value in configuration.js despite it making sense to do so.
3. The value is hardcoded in the code rather than in configuration.js.
4. There is no option (such as setting the value to 0 like the comment suggests in configuration.js) to switch off auto-committing.  One would have to comment out the line of code in lms.js.

I can propose a change request for the developers to:

1. Amend configuration.js to set the value of FORCED_COMMIT_TIME to 600000 (10 minutes) in line with a 10 minute interval currently hard coded in lms.js.
2. Amend lms.js to make use of the FORCED_COMMIT_TIME rather than hard coding the value.

This will make it a lot easier (and a lot less misleading) to course builders who wish to customise the forced commit time.

Thanks,

Chris

Hi Chris,

I can certainly pass that along as a feature request - but hopefully we at least got to the bottom of the behavior you were seeing! 

Yes we did.  And thanks for adding it to the feature requests.

No problem Chris - and we don't share information in terms of product roadmaps, so I can't say when there may be such a feature in Storyline or Studio but once we have information about an update or new release, we'll be certain to let folks know. 

Hi, we're two years on and we're still seeing freshly published courses committing every 10 minutes instead of every 1 minute despite FORCED_COMMIT_TIME = "60000";. 

We've shed a bit more night on it though:

• Running a course in Google Chrome shows an auto- ommit every 1 minute
• Running a course in IE11 shows an auto- ommit every 10 minutes

We've tried two different courses and it's the same.  

So why is IE11 different to (say) Chrome?  Well IE11 is running the course in "Flash" whereas Chrome is running it in native HTML5. 

So we've disabled Flash in IE11 to run the Native HTML5 and we then got the correct 1 minute auto-commit.

So this might be a bug in the Flash framework.  Are you seeing the same situation?  Thanks.

Hi Chris,

I know this discussion has gone on for some time, but I wanted to confirm what version of Storyline you're using? We had an issue in Storyline 360 where the HTML5 LMS output sends a status to the LMS even if we set var FORCED_COMMIT_TIME = from 60000 to 0. That was fixed in Update 16, and it'll be fixed in the next update of Storyline 3 as well.

If you are still seeing something odd in your files, could you connect with our Support team so that we can take a look! 

Hi Ashley,
It is still occurring in the latest version of SL360 and SL3 (as of 12/06/2018 - our authors update as soon as updates come out).

The issue related to using the default value of 60000 rather than when setting the value to 0).

I've raised it as Case No 01407604.

Thanks,

Chris

Thanks, Chris.  We'll follow your case too.

Hi, we have a SL3 course sending LMS calls every 1 minute. Are you saying the ability to edit this is not available? I'm on SL3 v3.4. I've edited the configuration.js file but as others mentioned it does nothing.

Hi Dave,

Really sorry you're running into this, as well. We had an issue in Storyline 360 where the HTML5 LMS output sends a status to the LMS even if we set var FORCED_COMMIT_TIME = from 60000 to 0. That was fixed in Update 16, and it'll be fixed in the next update of Storyline 3 as well.

We'll keep you posted and let you know as soon as that fix is released!

Hey Dave. I'm excited to let you know that we just released update 5 for Storyline 3! It includes new features and fixes - check them all out here.

One of the fixes addresses an issue where HTML5 output sends a status to the LMS even if we set var FORCED_COMMIT_TIME = from 60000 to 0.

Here’s where you can download and install the latest version of Storyline 3. Let me know how you make out!

I'm wondering if the same problem exists for Rise. In scormdriver.js I can see the declaration of the FORCED_COMMIT_TIME variable, but I can't find where (or if) it's being utilized.

Hey Nathan! 

Are you seeing issues with the data your Rise 360 course is sending to your LMS? If you can tell me a little more about what you're seeing, I'll try and point you in the right direction!

Hi Alyssa, thanks for writing back. Sorry for being vague in my former post. Yes, I'm seeing a problem with Rise that's very similar to this conversation about Storyline. For the purpose of establishing some context, here's how Storyline works:

Storyline calls the ForceCommit() function at an interval that's defined by the   FORCED_COMMIT_TIME variable in configuration.js. With Storyline, even if the communication to the LMS is severed after some time has passed, I can still see from the LMS communication log that data was written back to the LMS up to the point where the communication was severed. It took place every 60 seconds, as defined by the FORCED_COMMIT_TIME variable. This is great! This is as it should be.

Rise does not have the same behavior. Even though the scormdriver.js file declares the FORCED_COMMIT_TIME variable, it is not being utilized even if it's set to 60000 (the same default value of the Storyline variable).

This behavior in Rise is the same as the original post by by Chris Walsh. (But, of course, the original post was for Storyline - which now works as expected.)

Hey, Nathan! Our Support Engineers have a deeper knowledge on this topic, so I'm going to put you in touch with someone from that team! I've shared the latest information with them, and they'll reach out to you via email soon.

Hi, folks! I wanted to share an update for anyone following along in this discussion.

Our team found that Rise 360 courses are not sending keep-alive messages to the LMS, even if the FORCED_COMMIT_TIME variable is changed the value from 0 to 60000.

If we get an update on this issue, we'll pass it along to you. Thanks for bringing this to our attention!

Hi Alyssa / Articulate, is there any further update on this please? We are experiencing issues with Rise's lack of automatically committing data as reported by Nathan above. 

Hi Ian! Your Rise 360 course will communicate to the LMS when you navigate to each lesson.  There isn't a way to otherwise force a commit to the LMS. Can you tell us more about the issue this is causing for you? Are your learners timing out and losing their progress while taking your courses? 

Thanks Alyssa. We are embedding the majority of the learning experience within an iframe within Rise, so there isn't much navigation happening from lesson to lesson. As a result, exactly as you said, some learners are timing out and losing their progress, therefore we were hoping to use the FORCED_COMMIT_TIME variable to periodically force LMS Commits to happen in the background.