We are in the process of implementing Success Factors LMS, and trying to play and view SCORM compatible files exported from Adobe Captivate 8 and 9 in Success Factors LMS.
I get the message - 'ERROR – unable to acquire LMS API, content may not play properly and results may not be recorded. Please contact technical support’
I have tried SCORM versions 1.2 v3 and 2004 V2 and V4. We can view the content, however it does not track, show as complete etc.
We are also producing Scorm compliant files using Skillcast and Articulate, but we still hit the same issue, we can view the content after closing the API error window, but still does not track.
Anyone experienced this problem before? Or know of a fix?
Many thanks
Normally this issue comes up when the course is unable to get the SCORM API from the LMS...I have seen a ton of SCORM content running in Success Factors before, so I wonder if the issue is in the setup. Are you seeing any "Access Denied" type errors in the browser element inspector/developer tools? I wonder if the course just can not find/have access to the player window. If the course is launching in a new window, you may want to try launching it in the frameset. I have seen folks get around this issue by making sure the player and sco are in the same window...
If you wanted to rule out the content being the issue, you can always test your content in the SCORM Cloud's free sandbox (https://cloud.scorm.com) to make sure the course is properly asking for the API...
If you have any other questions, we would be happy to help...you can just shoot us an email at support#scorm.com.
Thank you!
Joe
The error occurs because the content is not speaking to the Learning Management System (LMS). The code that runs to initialize the session doesn't happen. There is no return "ping" from the LMS.
You will get this error when you publish in SCORM and run from your desktop, or from a web server that isn't connected to an LMS. If it occurs when you are launching from an LMS it can either mean that the SCORM API isn't configured correctly, or your content server is on a different domain (cross-domain) than your application servers.
To test, you should try launching your content in different browsers. Our system was configured in such a way that Firefox and Chrome read our content to be cross-domain issue, and threw the SCORM API error, but Internet Explorer worked just fine.
In the end, it was determined that our server configuration in tandem with our firewall and security settings read the Content server as cross-domain and we had to redeploy our content servers within the firewall.
Related
I am working on a site that uses the PayPal API. This new site will replace the old site at my job. As of right now, I need to check what data the old site sent to the PayPal API. Is there a way to check what data is being sent to and from a different site or API? It is data that is not typed in by the user, but data that already exists in the database that is being sent to the API.
Any help or advice would be great.
Thank you!
It "depends". On Windows platform you could use:
Fiddler or;
Microsoft Message Analyzer
to inspect traffic i/o (on the client system where either tool is installed). I'm sure other platforms will have similar tools.
Chrome Dev (or any other browser) tool will help with browser based traffic.
IMHO, depending on how "old" the existing system is, it maybe worth looking at the API again to see if any newer features are worth the effort since you're updating things...and seems to me getting paid/payments systems/ops would be something high on the priority list :)
Hth...
My SL application is commercial and working just fine on hundreds of machines.
SL is using a WCF service and it works as expected, but today I observed behavior on client machine, where literally no call is made to server.
After you click button that sends a call, some error occures, and no record about WCF call is created in Fiddler.
Error is:
[HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable...
I read about this error that people recommend to use Fiddler, but as I say there is no call displayed in Fiddler
So problem is worse than I thought initially.
It comes and goes. Currently we have found a working solution that fixes the problem after it appears although it doesn't make any sense to me.
For example if I get this error in chrome & mozilla & OOB version,
launching a program in IE works, and after that chrome,mozilla & OOB
start to work too.
Thing is that same people who had this problem solved with this workaround experience it again in some days, like a week, with no apparent reason, and then combination of launches from various locations helps (usually IE helps the most).
Any help appreciated, I start a bounty as its pretty sick bug and I need to fix it somehow.
Update
Weird IE fix scenario:
At some point OOB version gets into state where it doesn't send any WCF request to server.
(fiddler doesn't see it, server doesn't gets it).
After launching web version in IE, and hitting the same button, that sends WCF request we get desired result in IE web version.
Without changing anything else, just relaunching OOB version which was in this buggest state before, makes OOB version work correctly. Its not reinstalled, not changed - nothing.
This is what I call "IE cure" of this problem.
So the question is what can IE launch potentiall change for OOB version?
According to this thread the message Debugging resources are unavailable appears when de client is not using the the Silverlight Developer Runtime.
This means that the actual exception is hidden from you (and us) so the next step is to reproduce the error on a system that has the Silverlight Developer Runtime.
I found this article. It might be worth it to check the certificate you are using (are you using a certificate) It is one of those things that is different with OOB apps and browsers.
I'm not really sure how to word this exactly, so hopefully someone can make sense of it. I've been working on an iPad app that syncs files from a server to your iPad and lets you build presentations with the various files. The corporation I'm working with on this app has a wireless network that requires you to re-authenticate every hour. So every hour instead of getting the expected JSON api response, any HTTP request pulls down the page needed to reauth with the wireless network. I was wondering is there is a specific HTTP response code related to getting sent that page or a "best-practice" way of testing for that page as opposed to JSON.
Granted I could just test to see if the response is HTML, but that doesn't account for other redirect responses that I haven't found yet. I could just test part of the HTML to see if it matches a predetermined portion of the html, but I'm an outside contractor. I can't guarantee they won't change the markup or verbiage of the page after I've made my deliverable.
So does anyone out in the ether know a "best practices" methodology for testing if the app needs to reauth before syncing?
I noticed that on Mac OS X and maybe even iOS, when you connect to a new Wi-Fi network, it will try to contact www.apple.com. This is being done to check if the internet connectivity is available. If it's not available, the Captive Network Assistant will pop-up, showing you the authentication page, or sometimes when I'm in Starbucks, an advertisement.
Following your question, since Apple themselves is doing it this way, I think you could check for HTTP response code, look for something in the HTML markup (slightly discouraged though) or trying to connect to a known server (Reachability).
For a corporation practicing well-documented projects, I am quite sure they won't be changing things without making sure that your app, once deployed will continue to work.
Okay here is our setup:
Simple form being submitted via AJAX using Prototype 1.7 to a Apache server captured by ColdFusion. (We have noticed similar bugs on pages that submit form data in the conventional way but these pages are used far less.)
Some of our clients are reporting an error. After looking through the logs and doing live testing from their machine Firebug Light is reporting that the request was being sent with the post data.
However on the server side the post data is not present in raw logs or ColdFusion's FORM object or in GetHttpRequestData().
This problem has been isolated to IE only even when running Chrome Frame and is intermittent.
We can not reproduce this error with our IE8 installs on our machines OR on their machines running Firefox or Chrome.
Any thoughts on this extremely difficult bug to track down?
Do you have an HTTP proxy involved in this somewhere? We have had issues in the past, I can't recall the details, but I know that it had something to do with using AJAX to POST. The proxy was configured such that a certain combination of headers would make it misbehave. Take a good look at the HTTP headers coming from the browser, comparing one that works and one that doesn't.
I'm a web application developer, who runs a site http://myfav.es. We've been struggling with this issue for about a month now.
We use the HTML application cache spec - www.w3.org/TR/offline-webapps/ - with dynamically generated manifest files - myfav.es/personal.manifest - to speed page delivery. These dynamically generated manifest files use proper headers, and PHP to serve up custom manifests for users.
We also use gzip compression to serve the site from a linux/apache host.
For the life-cycle of our site, users report getting a err_failed similar to this screenshot in chrome. twitpic.com/272237.
This error is intermittent, occuring once every 200-300 visits, but will persists on every page refresh, including hard refreshes, which presumably means that an error using app cache is causing them to continuously load a failed version of the site. However, mysteriously JUST clearing cookies causes the error to fix itself.
I'm completely out of ideas on how to approach this error, and googling the error message appears to get a ton of confused users with voodoo-ish approaches to solving it. I've personally seen the error, along with a number of complaint from other users of chrome, so I'm fairly certain it cannot be caused by a particular user having abnormal settings or browser preferences.
Does anyone have any insight into the cause of this browser error and its origins? Whether its likely server-side or a byproduct of app design?