Forum Discussion
How often does Rise ping the LMS?
I am considering creating a very video heavy Rise course. However, I am worried about my LMS timing out. Does Rise contact the LMS after each move to a new page?
Hi everyone! Our team has made improvements to the FORCED_COMMIT_TIME variable in Rise 360. Newly exported Rise 360 courses exported using SCORM 1.2, SCORM 2004, or AICC will communicate with the LMS every 60 seconds, as well as when you navigate to each new lesson. This change doesn't apply to courses exported with xAPI or cmi5.
Please let me know if you have any questions about this enhancement!
This is great news!
Hopefully this will go a long way to resolve the problems related to saving student results and bookmarking.
Hi Alyssa,
This is wonderful news! Thank you very much. I'm thrilled to see this in action at my next upload.
Looking at the comment from 3 years ago, it looks like the FORCED-COMMIT_TIME variable was updated for SCORM 1.2, SCORM 2004, and AICC, to communicate with the LMS every 60 seconds, but doesn't apply to xAPI.
What is the time for xAPI?Hi Pat,
I don't believe xAPI courses have the FORCED_COMMIT_TIME parameter available anywhere because it communicates using activities. I've opened a support case on your behalf so we can have our support engineers confirm this for you. If there is a setting to force the ping, they'll let you know in the support case!
Hi there, Will. Your course will communicate to the LMS when you navigate to each lesson. Because there isn't a way to otherwise force a commit to the LMS, you'll want to make sure that the LMS won’t time out in the time it takes learners to experience video-rich lessons!
Hi there
Can you explain what kind of communication goes to the LMS on the change of each Rise lesson? It's not SCORM commit is it? In our LMS (IMC Learning Suite) we have been seeing users timed out of the LMS when in Rise course for long periods (even with change of lesson) with these users often losing their progress.
Whatever this communication is, I would like to chase it up with LMS vender as it doesn't seem to be received.
Hi, Will!
If a learner watches half a video in a Rise 360 lesson then exits the course, they'll have to start the video over from the beginning when they revisit the lesson. They will not be able to skip ahead to the point where they left off.
If they watch the entire video, they will be able to fast-forward to any point in the video when they revisit the lesson.
Let me know if that answers your question!
Ok. Well. My dev wanted to find a solution and dug on it. Here is what we will use:
We will add this:
if (strElement == "cmi.core.lesson_location")SCORM_CallLMSCommit();Inside the Scorm_CallLMSSetValue function to force a commit when one change of lesson.
What could be the side effects?
Hi Joyce! I checked in on that case, and our team recommends that you coordinate with your LMS to extend the timeout, if that's a possibility for you.
Our team doesn't support modifying the published output file, but hopefully someone who has made a similar modification can chime in with their experience here!
Hi Alyssa,
Joyce is right. This is a coding error in Rise. We talked to the Articulate folks about it a few months ago, but it does not seem like a fix has been put into place. Without this code, Rise does not send any data back to the LMS until you close the course. There are major risks associated with this. Our code is a bit different than the one Joyce is using but does basically the same thing by simply sending Commit data back to the LMS after each setvalue. It seems like it would be a simple fix on the Articulate side to either fix their Force Commit variable (and maybe have it fire every 60 seconds like Storyline) or fire after each setvalue (but this may tax some LMS systems). There is a Force_Commit variable in the Rise code, but it is not connected to anything, therefore it never actually fires. Can you please help us get this pushed up the chain? We are not sure who else we can go to since we have already had calls with Articulate developers. Below is our code. The "Write to Debug" is so that we can easily see where this is firing off while we are in debug mode.
SCORM2004_objAPI = SCORM2004_GrabAPI();
WriteToDebug("Calling SetValue");
strElement = strElement + "";
strValue = strValue + "";
strResult = SCORM2004_objAPI.SetValue(strElement, strValue)
strResult = strResult + "";
WriteToDebug("strResult=" + strResult);
if (strResult == SCORM2004_FALSE) {
WriteToDebug("Detected Failed call to SetValue");
SCORM2004_SetErrorInfo();
WriteToDebug("Error calling SetValue:");
WriteToDebug(" strElement=" + strElement);
WriteToDebug(" strValue=" + strValue);
WriteToDebug(" Error Number=" + intSCORM2004Error);
WriteToDebug(" Error String=" + strSCORM2004ErrorString);
WriteToDebug(" Diagnostic=" + strSCORM2004ErrorDiagnostic);
return false;
}
WriteToDebug("####################################################################")
WriteToDebug("####################################################################")
WriteToDebug("#### START COMMIT CALL TO EVERY SET VALUE ##########################")
WriteToDebug("####################################################################")
WriteToDebug("####################################################################")
WriteToDebug("####################################################################")
SCORM2004_CallCommit();
WriteToDebug("####################################################################")
WriteToDebug("####################################################################")
WriteToDebug("####################################################################")
WriteToDebug("#### END COMMIT CALL TO EVERY SET VALUE ############################")
WriteToDebug("####################################################################")
WriteToDebug("####################################################################")
WriteToDebug("Returning true");
return true;
}
Hi Joyce,
Did you have luck with this? We are having the same issue with Rise courses not bookmarking due to our SSO timeout. Also, which file are you adding this string to?
Hi Joyce
In this case, Articulate admitted to a bug with how Rise 360 was handling keepalive/ping messages to the LMS. This was being investigated back in March 21, but there was no time-frame for a fix. We were advised to extend our LMS time-out, which we have since done.I'm not sure if this is the same issue that will be solved by development to the FORCED_COMMIT_TIME in Rise, but it certainly sounds like a promising start!
Alyssa is there any information on what this development/fix to the FORCED_COMMIT_TIME variable might look like? Will it bring Rise into line with how Storyline seems to work? I don't know about other's experiences, but i have always found Storyline's tracking to be very reliable in our LMS.
Hi Dave,
We didnt' have added it in production yet, but after some inter testing we feel confident enough to do so.
It's on the scormdriver.js (l.630).
Please keep in mind this is not something Articulate will support and that you will need to add this fix each time you export your content.
Thanks! This confirms my plan to make sure the video is split into shorter parts that are in separate lessons. One other thing I am debating... if I disable forward progress on a video, does their forward progress get bookmarked in the LMS? For example, if someone gets 10 minutes in to a 20 minute video and then exits the course, when they come back in to the lesson will they be able to start 10 minutes in? Or will they have to start it over?
Yes, that is helpful! Thanks to you both, Alyssa and Crystal. This helps make the decision of whether to prevent forward progress or not.
On the one hand, I want to make sure learners don't skip content. But on the other hand, I don't want learners getting stuck having to watch content they already have viewed. In a perfect world people would always have a steady and reliable internet connection to the LMS, for example. In that world I would always disable forward progress. But in the real world, making someone watch 10 minutes of a video they already watched because they got interrupted is really frustrating to the learner. So.. I can't bring myself to disabling forward progress to be honest. I'll only do it if the client makes me! :-)
Hi Mike! This sounds like a great question for our support engineers. They'll be able to look at your logs to determine how Rise is communicating with your LMS. I'll open a case for you, and you'll hear back from the team shortly!
Hi Alyssa,
Would it be possible to share the output of this case?
I'm facing the same kind of issue (the progression wasn't sent to the LMS at timeout so we lost a progression of 5 lessons). So it would be helpful to know what kind of communication goes to the LMS on the change of each Rise lesson.
Best regards,Hi there, Dave. I appreciate your message, and I shared your thorough reply with our development team. You're right -- this is currently a missing feature in Rise 360. Our team is going to do some more development on the
FORCED_COMMIT_TIMEvariable, which will result in Rise 360 courses communicating more frequently with your LMS.While I can't commit to a timeframe for this enhancement, we promise to keep you posted on our progress. Thanks for sticking with us as we work to improve this feature!
Thank you, Alyssa!
