Storyline Suspend Data Compression

Hello Zoe,

Since our LMS only uses SCORM 1.2, I had to make do with the 4096 character limit (unless you republish to SCORM 2004 3rd or 4th edition). While the solution in #3 worked for me, there is no actual workaround with the limit. So basically what happened is, I found out that Storyline's Slide Setting "Resume to saved state" takes up additional suspend data and all I did was to limit its usage.

I highly discourage using it on slides that are "media-rich"; that is, slides that have a lot of video, graphics or sounds in them. Instead, for these kind of slides I used the "Reset to initial state" option this helped me save some of those precious suspend data.

Uh, yes.  We have been using this patch in production for about 6 months now on all of our Articulate-authored courses (both for our courses that are hosted on Cloud Scorm as well as for a number of customer-hosted LMS systems.  The customer-hosted LMS systems were the primary instigation for creating this patch since we seem to encounter quite a few of them that either do not support SCORM 2004 (where the suspend_data default size was increased to 32kb) and/or they do not have the ability to override the default size for suspend_data. FWIW, the Rustici SCORM driver does allow configuring/overriding the suspend_data size.  However, we have a couple of courses that were resulting in suspend_data sizes exceeding 50kb. After compression. these courses were then saving suspend_data that was just barely under 4k!

Oh, and I can say that I have run into issues like you describe with the stuck loading prompt in the past.  Usually it has turned out to be some odd event that failed upon resuming.  One of the best troubleshooting things in this situation is to have the user who experienced the problem (loading stuck) open their browser developer console (usually Ctrl-Shift-I on most browsers or right click then inspect).   All the browser errors are logged to that console, and though there are often lots of warnings and other errors going on, there may be a tell-tale error message that could help you down the path to a solution (or at least with what's going on that's preventing it from completing the resume).

Well, I would think one of two possibilities is going on: either the LMS is truncating or corrupting your suspend_data; or you may have made a very small typo or error in your implementation of the above. 

The first thing to check would be to open the browser developer console and then check for any errors.  If you accidentally made any mistakes when patching the above files, those errors would be reported in the developer console.

The other thing you can do to help debug, is to look at the LMS interface debug window.   To see the LMS debug window, you simply have to make a couple of changes in the file lms/Configuration.js.  First, make sure the first line has blnDebug = true;  If it's false, then just change it to true.   Then scroll down to or search for SHOW_DEBUG_ON_LAUNCH = false; and change that to true.  You will then need to re-zip the package and re-upload it to the LMS.   This simple change will then cause an additional window to open up when you launch the course that has all the debug logs for the LMS interface.

Note: if blnDebug is already set to true, then you can also open the debug window from the browser developer console of an already launched course.  To do that, go to the console section of the developer console, and type: window.SearchParentsForContentRoot().ShowDebugWindow();

Within the debug window, what you need to do is to find and compare the value of the suspend_data when SetDataChunk() is called versus the value when resuming from GetDataChunk().   If these values are different then your LMS is likely truncating or corrupting the data.

I hope that helps with your debugging.

I do have a bit of experience dealing with customers using SAP Success Factors.  It has definitely been one of the more pain-in-the-derrière LMS systems.   And yes, SuccessFactors seems to be fixed in time on SCORM 1.2 (and doesn't even support recording interaction data).   Anyway, this fix should still help and work fine. But like you, and with my previous SuccessFactors experiences, I would be hesitant to give a 100% guarantee, at least without someone first testing your course on your client's specific version of SuccessFactors.   Though, I do know that by using base64 encoding, the suspend_data itself should be fine with SuccessFactors as long as it's not truncated.  What would cause me reservation is just the broad number of issues I've encountered with SuccessFactors.

As to whether the suspend_data actually gets truncated or not, that should depend solely on whether your course creates more than 4096 bytes of compressed data.  What we usually do is test our courses on cloud.scorm through to the last slide and then exit (causing a suspend).  We then look at the registration data on cloud.scorm and examine the size of the suspend_data (typically, you can just copy the result into a web-based byte/string counter and see how long it is).  If it's close to 4096, then we have concerns.  If it's smaller by at least a 10% margin, then we feel more confident that everything will be fine.  Otherwise, we have to figure out how to trim out some of the items that cause saved state to be larger (typically we pair down the number of interactions).

I hope that helps!   And good luck!

Yes, this will also work on 2004 published courses.  The code change is in lms/API.js which is common to both the SCORM 1.2 and the SCORM 2004 interfaces.

"I wonder if articulate can do something to bypass this limitation." - unfortunately, the limitation of 4096 bytes comes from the SCORM 1.2 specification itself.  Depending on the LMS system, some will adhere to the specification very strictly and others will make accommodations where it makes sense.  Eg, many LMS systems will allow the administrator to configure the maximum size of suspend_data regardless of the spec (all variants of the Rustici driver support this).   However, Articulate is bound by whatever implementation of the specification the LMS's has and can not just bypass that.

Note: The really simple solution is actually just to use any variant of SCORM 2004 where it was quickly recognized that 4096 bytes was insufficient and increased the specification maximum to 32768 bytes (as well as many other improvements to the specification).   SCORM 1.2 is from 2000-2001, almost 20 years ago!  It's unbelievable to me that we are still struggling to get out from under a specification from that long ago!  Unfortunately, they did not build in a plan for obsolescence to force progression to newer standards (many standards today do this).  About all I can say is there must be a clear desire for simplicity and that is one of the driving reasons why so many people continue to use SCORM 1.2 - it is "simpler".

In regard to your question about that piece of source code, that is designed for the few LMS systems that will potentially crash your course if you attempt to send more than 4096 bytes.  If you happen to have one of those rare LMS systems, then you can simply set the USE_STRICT_SUSPEND_DATA_LIMITS variable in the Configuration.js file.  Most LMS systems that strictly support 4096 bytes will merely drop the portion that is over 4096.   This will often result in your Articulate course resuming some place prior to where you actually left off.   With the setting above, if you get to a point that suspend_data exceeds the 4096, all suspend_data will be dropped and you will be resumed to the beginning of the course.