If everything worked as expected in SCORM Cloud you'll want to reach out to your LMS team to investigate further as that indicates the issue is occuring in that end.
Please feel free to keep us posted on what you find.
Yep does look more like a configuration issue had a quick nose about there's a chap over on linkedin talking a whole lot of sense regarding the issue, get your IT guys to wrap there noodles around that.
SCORM content. SCORM relies on the use of JavaScript within the browser as the means of sending and receiving SCO and learner data. It's also critical to point out this is JavaScript and not Java - they are two completely different and unrelated technologies despite the fact the name contains the word Java.
All modern web browsers limit what JavaScript can and can not do in the browser session, and one of these limitations is known as cross-domain scripting. In a nut shell, what this means is if the browser calls web content from abc.com (web content such as html, JavaScript, images, CSS, etc.), but the JavaScript in that session wants to communicate with xyz.com, the browser will prevent this from occurring. This is a basic security measure to prevent session hijacking and the injection of malicious content. The web browser can't make the distinction between what is good or bad, so all cross-domain scripting is block.
What this means for SCORM content is the content must reside within the same domain as ELM. The easiest solution is to simply place the the SCO content on the WebLogic or IIS server running the ELM web server. That method however doesn't scale well in large implementations and can be difficult to manage large amounts of content. There are a number of different ways to work around the cross-domain scripting restriction and ADL, the governing body for SCORM, publishes a document with a number of different options depending on your needs. The most common method is the use of a reverse proxy.
When dealing with SCORM content hosted by (multiple) external vendors, your best option with the least amount of effort is to ask the vendor if they also support AICC. AICC, since it uses standard HTTP GET and POST calls, not JavaScript, for communication is unaffected by the cross-domain scripting restriction in SCORM. Unless you have a specific need to use SCORM 2004 content (available in ELM 9.1 B7) the common feature functionality between AICC and SCORM 1.2 is identical.
6 Replies
First thing i would suggest is try launching in a different browser this reminds me of salesforce issue i was having a few years back,
My brain is saying there was a issue with the java version but i cant quite recall
any screenshots or if theres a more information link etc that has error info would help.
I have tried with Safari on Mac, Chrome on Mac, Chrome on Windows and Internet Explorer on Windows.
Same message.
I have also update to the latest version of Java; same message.
I have tested in scorm cloud, and everything seems OK.
Thanks,
Darrell
error dialog box
Thanks Darrell
Have to scoot home now, but ille take a look later,
First thing that pops out to me in the Javascript error dump is that its referencing the html file on dropbox, could be having issues accessing this?
Not a 100% on that just what i saw in the first few seconds ille take a closer look when i get in.
Hi Darrell,
If everything worked as expected in SCORM Cloud you'll want to reach out to your LMS team to investigate further as that indicates the issue is occuring in that end.
Please feel free to keep us posted on what you find.
Yep does look more like a configuration issue had a quick nose about there's a chap over on linkedin talking a whole lot of sense regarding the issue, get your IT guys to wrap there noodles around that.
https://www.linkedin.com/groups/Unable-Acquire-LMS-API-Error-3739925.S.209208838
Credits to Mr Zach Owenby
SCORM content. SCORM relies on the use of JavaScript within the browser as the means of sending and receiving SCO and learner data. It's also critical to point out this is JavaScript and not Java - they are two completely different and unrelated technologies despite the fact the name contains the word Java.
All modern web browsers limit what JavaScript can and can not do in the browser session, and one of these limitations is known as cross-domain scripting. In a nut shell, what this means is if the browser calls web content from abc.com (web content such as html, JavaScript, images, CSS, etc.), but the JavaScript in that session wants to communicate with xyz.com, the browser will prevent this from occurring. This is a basic security measure to prevent session hijacking and the injection of malicious content. The web browser can't make the distinction between what is good or bad, so all cross-domain scripting is block.
What this means for SCORM content is the content must reside within the same domain as ELM. The easiest solution is to simply place the the SCO content on the WebLogic or IIS server running the ELM web server. That method however doesn't scale well in large implementations and can be difficult to manage large amounts of content. There are a number of different ways to work around the cross-domain scripting restriction and ADL, the governing body for SCORM, publishes a document with a number of different options depending on your needs. The most common method is the use of a reverse proxy.
When dealing with SCORM content hosted by (multiple) external vendors, your best option with the least amount of effort is to ask the vendor if they also support AICC. AICC, since it uses standard HTTP GET and POST calls, not JavaScript, for communication is unaffected by the cross-domain scripting restriction in SCORM. Unless you have a specific need to use SCORM 2004 content (available in ELM 9.1 B7) the common feature functionality between AICC and SCORM 1.2 is identical.
This discussion is closed. You can start a new discussion or contact Articulate Support.