Forum Discussion
Storyline Suspend Data Compression
Good day!
As some of us know SCORM 1.2 only limits its suspend data for up to 4096 characters. Storyline (360) compresses its data (e.g. SL variables and such) in order to fit the limitations of t...
Thank you David for your help and advice!
I have now successfully implemented the code and tested it on SCORM CLOUD and on our LMS (Webanywhere) Moodle version 1.6.
However this is to be implemented on my clients system who use SAP success factors.
I am slightly apprehensive to give a 100% guarantee that the problem won't occur on their system but am struggling to find out the exact specification of the LMS but I believe it is a custom based solution (if anyone reading this knows?)
I have suggested that they complete a test but my team want to just offer a solution.
I have explained that although we have tested, it still needs to be tested on the Clients LMS as the
LMS can still truncate the data
Would this be a fair analysis? I appreciate your advice, although i'm confident with editing the package, when it comes to API's I am reaching my depths of understanding.
I'm still unclear as to whether this is specific to Articulate Storyline or this happens with any software of this type?
Thanks in advance
regards
Thanks in advance
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!
David, counting the bytes in the suspend data using the SCORM Cloud registration info is great. This is the closest method I have seen for measuring the suspend data for a course. It may not be exact, but it at least gives you an idea of where you are. Thank you very much.
