SCORM (Adobe Captivate and ADL Test Suite 1.2.7)

This document describes my experience using Adobe Captivate to generate a SCORM 1.2 content package. This includes the verification of such a package using the ADL test suite.

Using captivate I created a set of multiple choice questions – I won’t go into all the details of how to do this as it was the easy bit! Export the package as a SCORM 1.2 zip file.

Running the output from captivate straight through the ADL test suite you’ll see it fails with an initial error of ERROR: LMS Not initialized. If you look at the content window opened up by the test suite you’ll also notice there are javascript errors, the first one being access denied to scorm_support.js

The details of this fix have been borrowed, then embellished, from

To make sure that your SCO gets launched in the test suite, you need to edit the html file that is generated by Captivate when publishing your content (the .html that has the same name as your project .swf). Open the file with a text editor (Notepad), on the second line you will find <!– saved from url=(0013)about:internet –>. Delete that line.

Restart your test, and your SCO will now launch. But you will get errors in your test now. Fix number two: change the security settings of the Flash player on your machine.

  • Get some Flash content playing in your browser. Any Flash animation will do. Go e.g. to
  • Right-click on the animation, you will get the Flash context menu. Select Settings.
  • You will get a little menu like this:
  • Click the Advanced button. This will bring you to an Adobe Web site.
  • In the table of contents on the left, click Global Security Settings Panel. This will show you a panel like this:
  • Add the location where your ADL TestSuite software is installed to the trusted locations. The location of the TEST SUITE software, not the location of your zip file or your content files. Those get copied automatically to a TestSuite subfolder when you run the test.
  • Close all your browser windows and re-run the test.

From here, I continue the explanation with my own experience … having unzipped the original zip file to make changes to the HTML file I decided to test with it unzipped as the test suite has that option – do not do this. I wasted a great deal of time trying to work out why LMSInitialize() was not being called by my content, to the extent that I actually hardcoded a change in to make sure it was called. This unzipped package now passed the test suite, but having never run anything through the test suite before I couldn’t tell if it was working correctly.

Everything now works, hurrah, so I rezip the package and decide to give it a final test. LMSInitialize() now gets called twice, hence the waste of all my effort – I then removed my hardcoded call. Now, when you run this package through the test suite, not only does it pass, but it shows you all the data communicated from the content package to the LMS (getValue/setValue calls).

In summary, the only thing wrong with the initial Captivate output is that it contains a comment (on line 2) that needs to be removed. I suspect the other fix is only needed to satisfy the test suite running the package from the local disk, as opposed to being served through a web server over HTTP.

Tomcat SSL Certificate – Alias tomcat name does not identify a key entry

A post that may help someone out if they get into the same situation I did with regards to importing SSL certificates into a java keystore for Tomcat.

When renewing my certificate, my CA had the ability to use my old CSR (certificate signing request) which I accepted as it saved me a few minutes. Before, I’d always started with an empty keystore, generated my private key, CSR, then imported my new certificate along with the any needed to complete the chain. It seemed easy, I just needed to import my new certificate into the old keystore, right?

keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gd_intermediate.crt
Enter keystore password:  
keytool error: java.lang.Exception: Certificate not imported, alias  already exists

I see, I’ve already got a certificate under that alias, so I need to remove it first. Into the manual, -delete option looks good and away we go … I delete and then import 2 certificates that make up the chain and do the same with my newly issued certificate. Update my tomcat config to be greeted by the following:

LifecycleException:  service.getName(): "Catalina";  Protocol handler start failed: Alias name tomcat does not identify a key entry

To cut a long story short, when you use the -delete option of keytool on an alias with a private key in it, it doesn’t just remove the certificate, it removes your private key as well. Adding in my new certificate is all well and good if I no longer have a private key associated with it! The correct thing to do is not use the -delete option at all, because keytool will not complain if you’re importing a new certificate like that over the top of an old one, e.g I already have a certificate in the alias ‘tomcat’ but …

keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file
Enter keystore password:  
Certificate was added to keystore