Overview

If your training content is tightly integrated with your platform and not easy to package for third-party use, delivering self-contained SCORM or AICC files to that LMS is a tough, if not impossible task. Rustici Cross Domain (RXD) solves this problem by helping you deliver your training content to your customers in the format they require, while maintaining control of the content and overall learner experience.

RXD allows you to create proxy files (SCORM 1.2, SCORM 2004 3rd Edition and AICC packages) that your customer uploads in their LMS. From a client perspective, this package appears like any other course – the course registration and launch process are the same.

When a learner launches the proxy file in the LMS, they are directed back to your servers to access the content. Once the learner exits the course or completes another action specified by your developers, Rustici Cross Domain sends key information to the LMS including Completion, Score, Time and Pass/Fail.

Because the content assets remain on your servers, you remain in control of all course functionality, reporting and features. That means you’ll be able to save important course data (including Completion, Score, Time and Pass/Fail) and learner data (including Student Name and Student ID) for your own reporting needs as well as sending it to your customer’s LMS.

Setup and Installation

Your Rustici Cross Domain deliverable contains two folders:

• server, which represents the remotely hosted content.
• client, which contains the templates on which to base the SCORM PIF (or package) to be imported into and launched from the host LMS.

To complete a successful RXD integration, you will need to include the RXD JavaScript files and relevant API calls in your content and create a SCORM/AICC package for the host LMS corresponding to each individual course.

Testing the Sample Content

The sample files (located in the remotecontent folder) are available for testing and debugging your setup.

It's a good idea to test the sample in order to confirm that remotely hosted content can communicate with a target LMS. If your target LMS (or LMSs) are not yet available for testing, you can easily use Rustici Software's hosted Cloud product for testing by setting up a trial account.

To set up a test of the sample content:

1. Place the files from server in a shared location on the remote server to be used by your courses. We recommend that your content server serve files over https rather than http.
2. Open the client folder and choose a learning standard template folder. Open the sdxd/configuration.js.template file and save it as configuration.js. Update the values, replacing the remote host parameters with your remote content server hostname and path to the remote content.
3. Update the imsmanifest.xml (for SCORM) or the .crs and .des files (for AICC) to replace the {COURSE_TITLE} values with your information.
4. Select all the files in the template folder, and package them as a ZIP archive. Note: your zip should have these files at its root, not in a subfolder.
5. Import the zip package into your target LMS, and then launch it.

If the launch works, you should be able to see a rendered version of /server/remotecontent/contentsample.html, which includes buttons that test the RXD API calls. After clicking "Commit Data" and "ConcedeControl", any other API calls you made should be communicated to the host LMS.

Configuring the Remote Content

Now that you have a proof of concept of remotely hosted content using the RXD API to send SCORM/AICC API data to a host LMS, it's time to make that content your own.

There are a few basic steps to this:

1. Create a generic landing page to redirect learners to the proper content. This page should include the RXD scripts for all content to share via an iframe or frameset.
2. Add your content.
3. Include the RXD JavaScript file.
4. Integrate the RXD API.

As we mentioned above, it's generally a good idea to ensure that your content is served over the same scheme as your target LMS (i.e., either http or https), probably preferring https as a default. If there is a scheme mismatch, you can wind up invoking browser security warnings.

The Landing Page

It is our expectation that many customers will use a single gateway page in front of a variety of dynamic pieces of content.

For instance, you might have Package1.zip and Package2.zip, each of which point to this gateway page to pull in different bits of remote content from your content server.

A common implementation approach is to read the values passed in on the query string to send the user to the proper place based on (content) server-side logic.

As an example of how to pass custom data to your content, the parameters clientid and courseid are supplied as examples via CustomParams in the configuration.js template file. They are both optional and passed to the ContentURL as a params querystring value for you to parse accordingly. clientid is included to represent a package representing a given learner or LMS. courseid is intended to represent an ID for a course that will be included dynamically by the content server. You can remove these parameters, change them, add to them ... whatever you need to do to pass parameters on a per-package basis to the content server. But do note that they are fixed per package.

In your landing page (whatever you call it), the important part is that you preserve any querystring or hash values when you ultimately redirect to the actual content. Without those values, the RXD server-side script will not be able to function properly.

Add Your Content

We provide remotecontent/contentsample.html, again, as a sample. You probably shouldn't use a file called contentsample.html to build your production content, and you don't need for the content you do use to live in a folder called "remotecontent". All you really need to do is ensure that whatever content you provide is available to the landing page for redirection.

Include the RXD JavaScript

In remotecontent/contentsample.html, you will notice this line in the head element:

<script language="javascript" src="../sdxd/sdxd.server.min.js"></script>

This is content that has included the RXD JavaScript to enable use of the RXD API.

One of the most important concepts of RXD is a read-once design. I.e., after the host LMS package has read a few key bits of information and passed them to the content server, the remotely hosted content never accepts additional messages.

What this means for your content is that you probably want to pursue one of two approaches:

• building your content with a wrapper page that includes the RXD scripts, and has a frame for the actual content so that the JavaScript is included only once per launch and, thus, the JavaScript environment is set only once per launch
• building your content so that important data elements are passed appropriately if there is more than a single page of content

Integrate the RXD API

With the JavaScript correctly included, you can now start using the RXD API.

The RXD API is a subset of the Rustici Driver API.

In short, you get completion, satisfaction (pass/fail), score, location, suspend data, and the ability to record interaction details (question/answer).

For best LMS response, you generally want to call CommitData whenever you make a set call of any kind on a page.