SCORM Engine Integration Overview

Welcome

Thanks for purchasing the SCORM Engine. We're eager to get started and to help you use the SCORM Engine to its full potential. This document will provide you with a road map to the integration process. It is not intended to be a comprehensive document listing every bit of functionality that the SCORM Engine provides, that would kill too many trees. Rather, this document will orient you to the integration process, set expectations and provide you with the key information needed to complete your integration.

If at any time you find yourself wishing that you had more information, or that the SCORM Engine could do something more, or that the integration could be handled differently, please ask. Chances are that the answer is "Yes! The SCORM Engine is built for that and here's how to do it". You've purchased a very flexible piece of software that can handle most anything that's thrown at it, and if it can't, we'll find a way to make it.

Working Together

So far, you've probably been working with Chris and TJ to gain some familiarity with the SCORM Engine and have concluded that the SCORM Engine is the right solution for you. Together you've been through demonstrations, some technical discussions and have executed a contract for licensing. Now it's time to hand things over to the technical folks to work their magic.

We have a team of developers that handle SCORM Engine integrations. We will assign one of them to this project to act as your integration consultant. The integration consultant is there to walk you through the process step-by-step. The consultant will handle all of the necessary SCORM Engine customizations and guide you through the changes that need to be made in your LMS. Our integrators are quite knowledgeable and are there to answer any questions you may have during the entire integration phase.

During integration, we use a tool called Basecamp for project management. Basecamp provides a simple interface for exchanging messages, transferring files, tracking to-do lists and setting milestones. We strongly encourage the use of Basecamp for all electronic communication (you'll even notice our implementers logging summaries of phone calls in there). Basecamp provides you and us with a single place to go to find the latest deliverables, see notes from prior conversations and refresh our memories as to why things are implemented the way they are. We have found this tool to be invaluable to both our implementers and our clients. You will receive a welcome message via email with your log in information to Basecamp. We can add as many users as needed to the system, so if you have additional people who will be participating in this project or just want visibility into its progress, we'll be happy to give them access.

Our expectation is that the integration consultant will be working very closely and very intensely with your developers over the next few weeks. There is a rough project schedule listed below that represents the typical timeline for SCORM Engine integrations (this work can go considerably faster for simple integrations). There is work to be done both on our side and on yours. If this schedule doesn't match your expectations or if the resources on your side aren't fully available during this time period, please let us know so we can schedule accordingly.

SCORM Engine Integration Timeline

Week 1: Kickoff Meeting. Identify unique requirements. Generate integration layer. Initial deploy of Console to client environment.

Week 2: Importing and Launching SCORM courseware.

Week 3: Rollup results. Coding for unique requirements.

Week 4: Skinning the player. Final tweaks. Testing and cleanup.

We have carefully architected the SCORM Engine to isolate our code from your code and vice versa. We maintain this barrier to ensure that changes to one system don't require additional integration work and don't adversely affect the other system. Similarly we find it best to maintain a similar boundary in the work that our integration consultants do and the work that your developers do. We are very reluctant to make changes or affect your code in any way. Your developers are the experts in your code and they are the ones that should be trusted to modify your system. We will work side by side with them, guide them and advise them as much as needed, but at the end of they day, they will be responsible for maintaining your system and they need to fully understand everything that is in there. Likewise, we do not expect your developers to become experts in our system overnight. We will gladly handle the the customizations and configurations needed in the SCORM Engine. If you prefer, we can also set your developers up with a simple development environment where they can make changes to the integration code. We are also happy to help your developers learn the innards of the SCORM Engine's source code should they be so motivated, but we don't want this learning curve to stand in your way.

The Kickoff Meeting

The first step in the integration process is a kickoff meeting with all involved parties. This is our chance to make introductions, work out some logistics and get the ball rolling. This is very much a working meeting from which we hope to take away most, if not all, of the information we need to generate your custom SCORM Engine integration.

The biggest part of the kickoff meeting is a tour of your LMS. We need you to show us around and give us a feel for how your LMS works. During the tour we will be looking for any unique requirements you have that might necessitate an advanced integration or other tweaks to the SCORM Engine. We've seen more than a few LMS's in our days so we will probably be very quick to understand yours.

We don't need to see everything your system has to offer, the main thing we need to figure out is how the entities in your system map to the entities in the SCORM Engine. Specifically, all LMS's have two entities that we will need to relate to, "packages" and "registrations".

If something just clicked and you see how these concepts map directly to your system, great! If not, don't worry, our consultants excel at comprehending your system and identifying the appropriate touch points.

During the tour, it will help to look at these areas of your LMS:

The LMS tour will segue into a look at your database schema. In the database schema, we are looking for two things, unique identifiers for a "package" and unique identifiers for a "registration". Every LMS has these concepts, but they can be called by different names and structured in different ways. These identifiers are the primary input our integration consultant needs to generate the first deliverable.

Information about the platform(s) we will be working with is the final piece of information we need from the kickoff meeting. Would you like a Java or .Net version of the Engine? Which database platforms do you need to support? SQL Server, Oracle, MySQL, PostgreSQL?

If there's time (and energy) during the kickoff meeting, we might get into topics that answer questions for later in the integration process. Specifically, the SCORM Engine needs to directly exchange two pieces of information with your system. First, the SCORM Engine needs ask your LMS for some information about each user (first name, last name and unique identifier). Second, the SCORM Engine needs to tell your LMS about the results of training it has delivered to a learner (we call this process "rollup"). We need to figure out the best way to perform this communication with your LMS. The SCORM Engine is quite flexible and can be used in any number of communication protocols, such as:

Kickoff Meeting Checklist

  1. Introductions made and contact information exchanged

  2. LMS tour

  3. Unique identifier for package established

  4. Unique identifier for registration established

  5. Code and database plaftform(s) established

  6. Communication protocol established (Optional - often discussed later)

The Setup Phase

After the kickoff meeting, we're going to give you some homework to do while we go off and generate the foundation of the integration.

Your homework is to get the SCORM Engine up and running in your development environment. The SCORM Engine itself isn't very usable without an LMS, so to get you started, we ship a simple SCORM Engine Console. The SCORM Engine Console is nothing more than a simple interface to the SCORM Engine that allows you to import and launch courses along with some debugging and system health tools. It will allow you to get everything set up and running in your environment before the integration with your LMS is completed. Once the integration code has been generated, the SCORM Engine Console provides us with a way to deploy and test the integration code before it is tied into your system. See /2-integrationwithconsole.html#scorm-engine-console-overview to get started.

While you are deploying the SCORM Engine, our integration consultant will be busy generating a customized integration for your LMS. This integration will be tailored to the unique identifiers and supported platform(s) we identified during the kickoff meeting. See SCORM Engine Integration Architecture for more information about the technical aspects of this generated integration.

The Integration Phase

Now it's time to start hooking the two systems together. Our integration consultant will deliver a generated integration to you and instructions for how to deploy it using the SCORM Engine Console. The Console will then be running with your specific code to let us simulate actions your LMS will eventually initiate after integration is completed.

There are three primary touch points where we need to integrate our systems, "import", "launch" and "rollup". This document will cover these touch points at a high level.

Key Integration Points

Import

We typically begin the integration process with the import mechanism. The goal of this part of the integration is to ensure that your LMS has an interface to upload and import SCORM conformant courses. Your LMS may already have an existing interface for importing external courses. If so, it is usually best to make slight modifications to the existing interface rather than attempting to create an entirely new interface, but that will vary from system to system.

There are three main outcomes that need to be met for the import integration to succeed:

  1. File upload and deployment - SCORM, AICC and Tin Can packaged courses are delivered as a set of files (often in a zip package). These files need to be uploaded to your LMS server and deployed to the appropriate locations for serving. The deployment process can be manual or automated, but there needs to be some form of administrative interface to enable it.

  2. Invoking the SCORM Engine's import routines - The SCORM Engine has some routines that need to be invoked to discover the course and properly populate the SCORM Engine's tables with data about the course.

  3. Package entity flagging - There needs to be some mechanism for flagging the package entity in your system as being a course that should launch with the SCORM Engine.

The SCORM Engine comes with some reusable interfaces that will handle the first two items above. These interfaces can be easily dropped into your existing interfaces. Alternatively, if these interfaces aren't an ideal fit, we can show you how to create your interface to invoke the SCORM Engine import methods through either web service calls or through direct API calls.

When thinking about the import mechanism, you will also want to think about package versioning. Package versioning controls how you handle updates to courses. We can help you select from several built in schemes for dealing with versioning that the SCORM Engine offers. These schemes should allow us to mirror the versioning functionality that your LMS currently uses or they can be completely transparent to the LMS and only applicable inside the SCORM Engine.

The SCORM Engine offers over 60 customized settings for controlling how each courses is delivered to the user. We call these the "package properties". The ability to manipulate each course's package properties is essential to ensuring broad courseware compatiblity. The SCORM Engine offers a reusable interface for editing package properties (we recommend using this interface instead of your own as we are constantly adding new properties). After a course is imported, we need to make sure that your LMS provides administrators with a way of accessing these property settings.

Launch

Launching a course in the SCORM Engine is a simple matter of redirecting the user's browser to an appropriate URL with some query string parameters appended. These launch parameters tell the SCORM Engine which course to launch, which registration identifier to associate the tracking data with and what "mode" to launch the course in. The format of these parameters is specific to your integration, however since the SCORM Engine Console is configured for your integration, it can provide examples of how to construct the launch settings.

When building the launch mechanism, we will want to consider the different modes in which content can be launched and how they map to the functionality in your LMS. For example, your LMS might provide a way to preview content or a way to review completed content. The SCORM Engine can handle these and other launch modes once they have been mapped to the functionality in your LMS.

Also during launch development, we will want to consider registration "instances". An instance is to a registration as a version is to a package. We will need to examine your LMS's policies around re-taking courses to see how they map to the SCORM Engine's registration instance schemes and then select the scheme most appropriate for your situation. Registration instances are closely related to package versions as often, new versions of packages will trigger new instances of registrations.

Rollup and Reporting

The final major integration point is rollup and registration. This is where we take all of the detailed data stored by the SCORM Engine for a particular registration, consolidate it down to the data that is relevant to your LMS and push the data into your system. The first step in the rollup integration process is determing what data you actually care about. Usually, most LMS's will want to know high level data about the course such as its status, score and the amount of time the learner spent in the course. The SCORM Engine can provide this and much more. The key is to figure out what your LMS needs to operate and getting that data in the right place. We will want to look at things such as the data that is displayed to the student, the data that is available to administrators via reports and the data points that trigger actions in the system (such as moving a course to the transcript or taking it off the learner's to-do list, etc). There will also be some business rules to flesh out, such as if a course is completed and failed, can the user retake it?

Once we have the required data identified, we then need to figure out the best way to technically get it into your system. Every time new data is saved to the SCORM Engine (this happens constantly while the course is being delivered), it triggers a process called "rollup". We can configure this rollup process to take any action we need it to. For instance, we can have it write data directly into your LMS's tables, we can have it call a web service or we can make an API call into your system. The critical data that the learner sees and that triggers actions in your LMS is pushed to your system via the SCORM Engine whenever there is new data. If your system requires more detailed data for reporting, it can either be pushed with the summary data, or pulled on demand by a later process.

Further Integration Considerations

There are a few other things that need to be considered when completing a basic integration.

Learner information - The SCORM standards require that the SCORM Engine make some information about the learner available to the content. Specifically, we will need to figure out how to retrieve the learner's name and a unique identifer for the user from your system.

Database deployment - The SCORM Engine requires a database to operate. It can run on its own database, or within the context of your existing database. How this deployment is handled is largely a matter of style and your personal preference.

Code integration - Similar to the database, the SCORM Engine can be tightly integrated into your code base to be compiled together, or it can be run as a stand alone compiled application (potentially on its own server). How code is integrated and deployed is also largely a matter of your existing setup and procedures.

Skinning - The SCORM Engine is fully skinnable and can be customized to match whatever aesthetic scheme you desire.

Advanced Integration - There is much more that the SCORM Engine can do and many more ways in which it can be tightly integrated into your LMS. An integration may want to explore other areas like distributed content delivery, tight authentication, integrated error logging, partitioned databases, advanced importing or offline delivery (using our offline player software developer kits (SDKs), which are sold separately). Your integration consultant will happily talk you through these areas.

Localization - The SCORM Engine is capable of rendering the player and the SCORM Engine Package Properties Editor in a variety of languages. By default, localization is automatically based on the browser's configured language. However, if your LMS has its own means of establishing the user's locale, the SCORM Engine can base its language off that instead.

Testing Phase

Once the integration is completed, it is of course important that we validate and test it. The best way to test the integration is simply to run a few sample courses through the cycle of importing, launching, and reporting. It is generally not necessary to test every combination and permutation of course type because the subtle errors that might be generated by course variations happen in the SCORM Engine itself and don't vary between integrations.

Going Forth

Material Completion

Once you are able to import and deliver and rollup data from courses (even just a couple of examples that we provide), you have achieved what we refer to as "material completion". This a relevant milestone from both a process perspective and a contractual one. From this point forward, we have found that your requests are often better managed via our support portal (see below for information). Our project managers will confirm with you that you are comfortable importing content and that you can access the support portal as needed.

It is important to understand that moving from the "implementation phase" to the "support phase" has no impact whatsoever on the level of support or access to our people. It is merely a change in process that helps us take better care of you.

Certification

Historically, ADL has offered a certification program that formally certifies or declares products to be SCORM conformant. The SCORM Engine has been certified for every version of SCORM, but unfortunately this certification does not transfer to your product. To be formally certified by ADL, you must put your LMS through the certification process. If you decide to pursue the certification process, we will be happy to walk you through it.

"Powered By" Logo Use

We want to make sure that you're getting the most out of SCORM Engine. Some of our customers prefer to tuck their use of our products away, and others want to scream from the mountaintop that they're using the best SCORM conformance software available. For the screamers, we've created a way for you to do just that. Visit our "Powered By" page for more info.

Support Process

We are always here for you, even after your integration is complete and your application is deployed. We have a dedicated support staff. If something goes awry after your integration is completed, please email us at support@scorm.com or visit our support portal. This will open up a support ticket and ensure you the fastest response. Our integration consultants rotate between many projects, including development of our products, and may not always be available to answer your questions directly once the integration is complete. Our support staff has unfettered access to all of our consultants and developers and can quickly put you in touch with the best person to resolve your problem.

For more details on the support process and our support portal, visit this document.

Troubleshooting

Nobody's perfect, we all make mistakes and things don't always go as expected. When problems arise, the SCORM Engine provides a few mechanisms for getting additional diagnostic information.

The most common problem our customers face is content behaving in unexpected ways. In almost every instance, this problem stems from a misunderstanding of the SCORM standard on the part of the content author, but we want to hear about these problems anyway so that we can ensure the SCORM Engine does everything it can to accommodate these varying interpretations of the standards. To diagnose SCORM content problems, the SCORM Engine maintains a very detailed debug log that tracks all of the SCORM calls made by the content as well as the internal SCORM logic that the SCORM Engine executed. This debug log can be accessed by clicking anywhere in the SCORM Engine's interface (the frames with the blue background in our default skin, or the frames that contain the table of contents or navigational elements). Then press the question mark (?) key five times. This should cause the debug window to pop up. If there doesn't seem to be much information in the log, check the package properties for the course in question. The package properties have a few settings that control how much debug information is recorded, make sure that all of the properties are set to record information. More details about accessing the client-side debug log can be found in our support portal.

For deeper problems that affect the operation of the SCORM Engine itself, we have a detailed server-side log that can be accessed.

Rustici Software offers another tool that can be invaluable in diagnosing content problems. SCORM Cloud is a hosted version of the SCORM Engine (free trial accounts are available) that is designed to help you quickly evaluate and debug courseware. SCORM Cloud always contains the latest updates and patches to the SCORM Engine. If content is not behaving as expected in your LMS, it is often useful to run the content through SCORM Cloud as well to see if the problem is with your LMS and integration in particular or if it is a more general problem with the content or SCORM Engine.

Our clients will often instruct content vendors to validate content on SCORM Cloud before attempting to import it into their LMS. This step can save countless hours of troubleshooting and messaging back and forth. We provide this free service for this very reason and we encourage you to take advantage of it.

Updates and Patches

We are constantly developing and improving the SCORM Engine. Our release schedule is largely dictated by the evolution of the standards, but we typically target about one major release per year. In the interim, we will periodically issue patches to fix significant errors or to deal with significant standards issues. These updates are available to any customer that is current with their licensing fees. Our support representatives will notify customers of new releases and we will post announcements to our knowledge base as well. Patches are typically only applied as necessary to avoid overly burdensome update processes. Updates are generally straightforward to apply, but our consultants are available to you as needed.

Synchronized Code Bases

We maintain a current copy of the integration code specific to your LMS in an internal source control system. This system allows us instant access to your specific code base if we need to reference it to help troubleshoot an issue or upgrade your system. If you make any changes to your integration, please send them our way so we can keep our copy up to date. Also, if you need to make any changes to the source code of the core SCORM Engine, please let us know so that we can try to work your requirements into a release and keep you on the standard maintenance path.