Icodeon SCORM Player .NET Edition Plugin and Extension Guide

This documentation is for Icodeon SCORM Player .NET Edition Version 2

                Icodeon Ltd
                St Johns Innovation Centre
                Cowley Road
                Cambridge
                Cambs
                CB4 0WS
                United Kingdom
                +44 (0)870 950 6582
                <sales@icodeon.com>

Plugin and Extension Guide for Icodeon SCORM Player Version 2 (.NET Edition)

Feb 2008

Table of Contents

1. Extending the SCORM Player with a Custom Plug-In

1.1. Introduction
1.2. CMI Service Persistence Plug-In
1.3. CMI Service Event Observer Plug-In

Chapter 1. Extending the SCORM Player with a Custom Plug-In

Table of Contents

1.1. Introduction
1.2. CMI Service Persistence Plug-In
1.3. CMI Service Event Observer Plug-In

1.1. Introduction

The Icodeon SCORM Player comes with numeroous configuration and customization options. However, sometimes these options provided by Icodeon do not meet the specific needs of a particular vendor.

To respond to this requirement, the Icodeon SCORM Player has a number of "extension points" where the standard Icodeon implementation can be "removed" and a custom implementation "plugged-in". Icodeon provide some source code and full API documentaion to support vendors with their custom implementation work.

API Documentation to facilitate custom plug-in development

1.2. CMI Service Persistence Plug-In

SCORM objects cache tracking data on the client, and periodically commit this state. SCORM refers to this tracking data as elements from the Computer Managed Instruction (or CMI) datamodel. In the Icodeon SCORM Player, this state is posted to a web service (the CMI SCORM Tracking Service) as an XML binding of the CMI state using the IEEE 1484.11.3 schema for Content Object Communication Data Model (or COCD). How the web service persists the data between invocations and sessions depends on which persistence strategy is "plugged-in" to the CMI service.

The distribution comes with two persistence strategies:

File system plug-in for persistence to the file system as XML
Database plug-in for persistence to a relational database through the NHibernate layer

The system is extensible, and this section documents how a vendor would add a third strategy for custom persistence and reporting requirements. The figure below illustrates how a vendor would to plug-in a custom persistence strategy for the CMI service:

Default and custom plug-in persistence strategies for the CMI service

Default and custom plug-in persistence strategies for the CMI tracking service

The steps for building and deploying the a plug-in are as follows:

Implement two interfaces using the C# language compiled using .NET 1.1 or .NET 2.0. The interfaces to be implemented are in the /src directory that comes with the distribution:
```
                
[PARENT DIRECTORY]/src/Icodeon/Services/Cmi/DAO/ICocdDAO
[PARENT DIRECTORY]/src/Icodeon/Services/Cmi/DAO/CmiServicePersistenceFactory

              
```
The first interface is for a "data access object" class that manages the typical "create, read, update, delete" (CRUD) operations set. The second interface is for a "factory" class that manages the creation of data access objects.
Skeleton classes that require concrete implementation within the method signatures of the interface are provided as a starting point for vendor implementation:
```
                
[PARENT DIRECTORY]/src/Vendor/Services/Cmi/DAO/Example/CocdDAOImpl
[PARENT DIRECTORY]/src/Vendor/Services/Cmi/DAO/Example/PersistenceFactoryImpl

              
```
API documentation for the implementation code is available in the distribution as a Help file at:
```
                
[PARENT DIRECTORY]/api/

              
```
Compile the implementations of the DAO and Factory classes, and any requried supporting classes, and package into a class library/assembly .dll file. The new assembly can have any suitable naming scheme. The assembly is then deployed to the /bin directory of the web application where the other assemblies and satellite asseblies are located.
```
                
[PARENT DIRECTORY]/wwwroot/bin/*.dll

              
```
Edit the application configuration file (called web.config) for the fully qualified class name of the Factory class and the chosen name of the new assembly .dll file against the "CMIPersistenceFactory" key. These values are added as attributes of a service factory element within the "playerGroup" configuration section:
```
                
  <playerGroup>
    <sessionFactories>
      ...
    </sessionFactories>
    <serviceFactories>
      <serviceFactory 
          key="CMIPersistenceFactory"
          className="Vendor.Services.Cmi.DAO.Example.PersistenceFactoryImpl"
          assemblyName="Vendor.Player.Plugins.dll"/>
    </serviceFactories>
  </playerGroup>

              
```
NOTE: the vendor values added here override any Icodeon values set for the "CMIPersistenceFactory" key/value pair in the "appSettings" configuration section
Re-start the web server to reload the web.config file. The new factory will be loaded at run time and will manufacture instances of the data access objects as required.

1.3. CMI Service Event Observer Plug-In

SCORM objects have a life cycle during a session within the Icodeon SCORM Player. The life cycle is characterized by the thee "data transfer" operations of the SCORM JavaScript API (IEEE 1484.11.2):

Initialize: Tracking data from a prevous session is sent from the server to the client.
Commit: Tracking data that has been recorded and cached on the client is sent to the server.
Terminate: Session time is calculated and tracking data that has been recorded and cached on the client is sent to the server.

Sometimes there will be a vendor requirement to observe these life cycle events, perhaps to trigger custom behaviour within another system. Icodeon provide the opportunity to "plug-in" a custom observer class to intercept these life cycle events and implement required functionality.

Custom plug-in observer for events in the CMI service

The steps for building and deploying the a plug-in are as follows:

Implement two interfaces using the C# language compiled using .NET 1.1 or .NET 2.0. The interfaces to be implemented are in the /src directory that comes with the distribution:
```
                
[PARENT DIRECTORY]/src/Icodeon/Services/Events/IRteEventObserver
[PARENT DIRECTORY]/src/Icodeon/Services/Events/IServiceEventObserverFactory

              
```
The first interface is for an "observer" class that accepts callback for event handlers for the "initialize, commit, terminate" (data transfer) operations set. The second interface is for a "factory" class that manages the creation of observer objects.
Skeleton classes that require concrete implementation within the method signatures of the interface are provided as a starting point for vendor implementation:
```
                
[PARENT DIRECTORY]/src/Vendor/Services/Events/Example/RteEventObserverImpl
[PARENT DIRECTORY]/src/Vendor/Services/Events/Example/ServiceEventObserverFactoryImpl

              
```
API documentation for the implementation code is available in the distribution as a Help file at:
```
                
[PARENT DIRECTORY]/api/

              
```
Compile the implementations of the Observer and Factory classes, and any requried supporting classes, and package into a class library/assembly .dll file. The new assembly can have any suitable naming scheme. The assembly is then deployed to the /bin directory of the web application where the other assemblies and satellite asseblies are located.
```
                
[PARENT DIRECTORY]/wwwroot/bin/*.dll

              
```

Edit the application configuration file (called web.config) for the fully qualified class name of the Factory class and the chosen name of the new assembly .dll file against the "ServiceEventObserverFactory" key. These values are added as attributes of a service factory element within the "playerGroup" configuration section:

                
  <playerGroup>
    <sessionFactories>
      ...
    </sessionFactories>
    <serviceFactories>
      <serviceFactory 
          key="ServiceEventObserverFactory"
          className="Vendor.Services.Events.Example.ServiceEventObserverFactoryImpl"
          assemblyName="Vendor.Player.Plugins.dll"/>
    </serviceFactories>
  </playerGroup>

Re-start the web server to reload the web.config file. The new factory will be loaded at run time and will manufacture instances of the observer objects as required.