SCORM Engine Settings
The SCORM Engine contains a number of configuration settings. These settings contain logistical information about how the SCORM Engine is deployed and they control how the SCORM Engine behaves. The SCORM Engine settings do not need to be changed frequently. They are typically only accessed during integration with another system and during deployment to new servers. If non-static values for any of these settings are needed, their values can be altered through the integration layer instead of being statically stored in the configuration file. The settings control the operation of Engine.
Working with the SCORM Engine Settings
The method for accessing and changing the SCORM Engine settings varies depending on the platform you are running (.NET or Java).
.NET
In a .NET installation of the SCORM Engine, the settings are contained in a file called "SCORMEngineSettings.config". This file is located at the root of the SCORM Engine installation, in the "ScormEngineInterface" directory.
The "ScormEngineSettings.config" file is a standard ASP.Net Configuration file. It is included by reference in the "web.config" file in the ScormEngineInterface directory. The settings for Engine can be stored in any valid and accessible ASP.Net configuration location.
The "ScormEngineSettings.config" file is a standard XML file that can be edited in any text editor or XML editor.
Alternatively, recent version of IIS include an "Edit Cofiguration" button on the ASP.NET tab of the applications properties. This button brings up a GUI for editing application settings individually.
IIS doesn't automatically detect changes made to the "ScormEngineSettings.config" file. In order to get the changes you make to be detected by IIS, you need to either: restart IIS or make a small change to your "web.config" file (in the ScormEngineInterface directory) and resave them. IIS will pick up a change to the web.config file automatically. An easy way to get the changes picked up is to open the "web.config" file, type a character, delete the character and then re-save.
Java
In a Java installation of the SCORM Engine, the settings are contained in a file called "SCORMEngineSettings.properties". This file should be deployed to a location in the web applications' class path.
The "SCORMEngineSettings.properties" file is a standard Java configuration file. This file is a standard XML file that can be edited in any text editor or XML editor.
Depending on your Java Application Server, you may need to cycle the application in order for configuration changes to be picked up.
Settings Groups
The SCORM Engine settings can be broken up into eight groups:
Integration class
Data persistence
URLs
Upload import control
Registration instance and package versioning
Optional SCORM Engine features
Debug settings
Central / remote architecture
Integration Class
These two settings determine which class the integration factory will load. This class should be the concrete implementation of the integration interface that is designed to work with the current LMS (the integration layer).
LogicIntegrationAssemblyName - The .NET assembly in which the integration class resides. The assembly name is the name of the DLL containing the code and often corresponds to the namespace of the class in which the integration class resides. This setting is not required for Java.
Example: "RusticiSoftware.ScormEngine.VanillaIntegration"
LogicIntegrationClassName - The fully qualified name of the actual integration class to load. Usually, this is the assembly name concatenated with with the class name.
Example: "RusticiSoftware.ScormEngine.VanillaIntegration.VanillaIntegration"
Data Persistence
The data persistence settings control how the SCORM Engine accesses the database.
DataPersistenceEngine - The SCORM Engine supports many different data persistence options. This setting controls which of the supported options the SCORM Engine will use. The options are listed in the table below.
| Value | Description |
| "compactsqlserver" | Connect to a Microsoft SQL Server CE database. (.NET Only) |
| "db2" | Connect to a IBM DB2 database. (.NET Only) |
| "db2_zos" | Connect to a IBM DB2 for z/OS (Mainframe). (.NET Only) |
| "mysql" | Connect to a MySQL database. |
| "odbc" | Connect to any database that supports an ODBC interface. (.NET Only) |
| "oracle" | Connect to an Oracle database |
| "oracle-not_optimized" | Connect to an Oracle database without using the bulk persistence stored procedure. [DEPRECATED in v2009.1 - use the "oracle" setting instead] |
| "ole" | Connect to any database that supports an OLE interface. (.NET Only) |
| "plugin" | Use a custom devloped data persistence mechanism. |
| "sqlite" | Connect to a SQLite database. (.NET Only) |
| "sqlserver" | Connect to a Microsoft SQL Server database. |
| "sqlserver-not_optimized" | Connect to a Microsoft SQL Server database without using the bulk persistence stored procedure. [DEPRECATED in v2009.1 - use the "sqlserver" setting instead] |
DatabaseConnectionString - The connection string that the SCORM Engine will use to connect to the database. The value for this setting varied based on the platform you are running.
In .NET, the value is an actual connection string. The format of the connection string will vary depending on the data persistence engine selected. Some examples of connection strings on various platforms are included in the table below.
| Data Persistence Engine | Example .NET Connection String |
| SQL Server | "server=localhost;uid=sa;pwd=password;database=ScormEngine" |
| MySQL | "Host=localhost:3006;UserName=root;Password=password;Database=ScormEngine;" |
| Oracle | "Data Source=oracledb.local;User Id=ScormEngine;Password=password;Integrated Security=no" |
| IBM DB2 | "Provider=IBMDADB2;Data Source=ScormEngine;UID=ScormEngineUser;PWD=password" |
In Java installations, this parameter is optional. If not value is provided, the SCORM Engine will use a pre-defined data source named "jdbc/ScormEngine". If you would like the SCORM Engine to use another named data source, simply include it's name as the value of this setting.
Advanced Data Persistence Settings
These settings are all optional and are only used used in advanced scenarios to accomodate varied data persistence options. The data persistence engine setting is essentially a shortcut to specify various combinations of pre-define data peristence classes and should be used instead of these settings unless an uncommon scenario is encountered.
DataPersistenceAssemblyName (optional) - When using the "plugin" data persistence engine, this settings specifies the name of the assembly from which to load the data persistence plug-in class. This setting is not required for Java.
Example: "RusticiSoftware.ScormContentPlayer.Logic"
DataPersistencePersistClassName (optional) - When using the "plugin" data persistence engine, this setting specifies the name of the class within the DataPersistenceAssembly that handles persisting data to the database. This class contains the actual SQL (or other commands) for manipluating SCORM Engine data within the database.
Example: "RusticiSoftware.ScormContentPlayer.Logic.SqlPersistImplementation"
DataPersistenceRetrieveClassName (optional)- When using the "plugin" data persistence engine, this setting specifies the name of the class within the DataPersistenceAssembly that handles retrieving data from the database. This class contains the actual SQL (or other commands) for manipluating SCORM Engine data within the database.
Example: "RusticiSoftware.ScormContentPlayer.Logic.SqlRetrieveImplementation"
DataHelperAssemblyName (optional)- When using the "plugin" data persistence engine, this settings specifies the name of the assembly from which to load the data helper plug-in class. This setting is not required for Java.
Example: "RusticiSoftware.ScormContentPlayer.DataHelp"
DataHelperClassName (optional) - When using the "plugin" data persistence engine, this setting specifies the name of the class within the DataHelperAssembly that handles connecting to and interacting with the database. This class contains generic helper functions that abstract the process of connecting to an querying a specific database.
Example: "RusticiSoftware.ScormContentPlayer.DataHelp.JdbcDataHelper"
DataPersistenceUseStoredProcsIfAvailable (optional, default="true") - This setting modifies the behavior of the SQL Server and Oracle data persistence engines to use stored procedures or regular SQL when performing some functions. In general, this setting should not be modified. Possible values: "true" or "false".
UseGuidAsObjectId - This setting allows the SCORM Engine to toggle between using integers and GUIDs as primary keys in its tables. Possible values: "true" or "false".
DBMaxStringLength - This optional setting sets the maximum string length to allow through to be persisted in the database. This applies to all strings passed to the database, including text fields.
DatabaseTimeout - Value used by the default integration implementation specifying the timeout threshold for database operations. In seconds.
DatabaseSchema - String value used by the default integration implementation specifying the schema name that should be prepended to table names.
URLs
The URLs specified in the SCORM Engine settings contain information about where the SCORM Engine was deployed and where it should make requests to. These settings allow for a lot of flexibility in how the SCORM Engine is deployed, in most situations however, they will all point to the single directory in which the SCORM Engine is deployed.
Unless otherwise specified, the URLs can either be fully qualified (ex: "http://www.mylmsserver.com/ScormEngine/pagename.aspx") or, relative to the root of the web server on which the SCORM Engine is deployed (ex: "/ScormEngine/pagename.aspx").
Note: For simplicity, the file extension has been omitted from the page names included below. The file extension will either be ".aspx" for .NET deployments or ".jsp" for Java deployments.
Note: As of v2009.1 of the SCORM Engine, URLs that specify a directory have the option of including or not including the trailing slash ("/").
ScormEngineUrl - When doing a basic installation of the SCORM Engine, this is the only URL setting that must be included. It is simple a URL to the root location of the SCORM Engine on the web server. If this setting is used, the rest of the URL settings can be omitted.
Example: "/ScormEngineInterface"
ScormEngineFilesystemRoot - When using the optional offline/mobile SCORM Engine add-on you will need to define this location.
Example: "c:\inetpub\wwwroot\scormengine"
RemoteRequestProcessorUrl - URL to the "ProcessAiccRequest" file. This URL should be in the same domain that content is launched in. In a standard deployment, this setting should contain the same value as the "CentralAiccRequestProcesorUrl" setting, or it can be omitted. In a cross domain, central/remote deployment, this setting should point to the "ProcessAiccRequest" page in the SCORM Engine instance deployed to the content server. The URL should either be fully qualified, or relative to the location from which the content is lanched.
Example: "/ScormEngineInterface/ProcessAiccRequest.aspx"
CentralAiccRequestProcessorUrl - URL to the "ProcessAiccRequest" file. This URL should be in the same domain that LMS resides in. In a standard deployment, this setting should contain the same value as the "RemoteAiccRequestProcesorUrl" setting. In a cross domain, central/remote deployment, this setting should point to the "ProcessAiccRequest" page in the SCORM Engine instance deployed to the LMS server and the URL should be fully qualified.
Example: "/ScormEngineInterface/ProcessAiccRequest.aspx"
ScormResultProcessorUrl - URL to the "RecordResults" file. This URL should be in the same domain that the content resides in.
Example: "/ScormEngineInterface/RecordResults.aspx"
CentralWebServiceUrl - URL to the "RuntimeDataExchange.asmx" file. This setting is only needed for cross domain, central/remote deployments. This URL should be an fully qualified URL to the "RuntimeDataExchange.asmx" file on LMS server. Currently this functionality is only available in the .NET implementation of the SCORM Engine.
Example: "http://www.lmsserver.com/ScormEngineInterface/RuntimeDataExchange.asmx"
ImportWebServiceUrl - URL to the "ImportService.asmx" file. This setting only applies to deployments using the SCORM Engine's import controls on a server other than the LMS server. This URL should be an fully qualified URL to the "RuntimeDataExchange.asmx" file on LMS server. Currently this functionality is only available in the .NET implementation of the SCORM Engine.
Example: "http://www.lmsserver.com/ScormEngineInterface/ImportService.asmx"
UrlToCentralLaunchPage - URL to the "defaultui/launch" page. This setting no longer used by Engine by default. When creating a custom skin for Engine during integration, it may be helpful to change this setting to point to the launch page in the directory containing your skin (vs the "defaultui" directory) in order to test the functionality of your skin.
Example: "/ScormEngineInterface/defaultui/launch.aspx"
RemoteLaunchPageUrl - URL to the directory containing the "deliver" page. This directory can vary when using custom skins of the SCORM Engine. When using a cross domain, central/remote deployment, this setting should be a fully qualified URL pointing to the server from which the content will be served.
Example: "/ScormEngineInterface/defaultui/"
ScormEngineScriptsUrl - URL to the directory containing the "launch" page. This directory can vary when using custom skins of the SCORM Engine. When using a cross domain, central/remote deployment, this setting should be a fully qualified URL pointing to the server from which the content will be served.
Example: "/ScormEngineInterface/scripts"
RedirectOnExitUrl - URL to which the SCORM Engine should redirect the user after the user exits the SCORM Engine. This URL should point to a location in the host LMS.
Example: "/ScormEngineInterface/tools/console/"
StylesheetUrl - URL to the stylesheet used by the current SCORM Engine skin.
Example: "/ScormEngineInterface/defaultui/defaultstyles.css"
UrlToLaunchHistoryControlResources - URL to the directory that must be deployed with the launch history report web control. This directory contains the resources the user interface of the launch history report needs to display properly. Only applicable to applications using the launch history report web control.
Example: "/ScormEngineInterface/scripts/EngineUtils/LaunchHistoryControlResources"
EngineUtilsHelperUrl - URL to the "EngineUtilsHelper" aspx or jsp (depending on your platform) that is used for displaying, Properties Editor, the Registration Report, and other ajax-enabled functionalites. This URL is optional and is only necessary if your EngineUtilsHelper file is not in the folder represented by the "ScormEngineUrl" setting.
Example: "/ScormEngineInterface/EngineUtilsHelper.aspx"
Upload Import Control
These settings are used by the web control that provides an interface for uploading content and importing it into the SCORM Engine. If this web control is not used by the LMS integrated with the SCORM Engine, then these settings are not required.
WebPathToContentroot - HTTP path to the directory in which uploaded courses should be stored. This directory should map to the directory specified in "FilePathToContentRoot".
Example: "/courses/"
FilePathToContentRoot - File path to the directory in which uploaded courses should be stored. This directory should contain the files served by the path specified in "WebPathToContentroot". Individual courses will be placed in subdirectories within this directory.
Example: "C:\inetpub\wwwroot\courses"
FilePathToUploadedZippedPackage - Courses are uploaded as zip files. This setting specifies a temporary directory that zipped courses are uploaded to prior to their extraction into the directory specified in "FilePathToContentRoot". After extraction, zip files are deleted from this directory.
Example: "C:\inetpub\wwwroot\courses\uploads"
UrlToUploadResources - URL to the "UploadImportControl" directory that must be deployed with the upload import web control. This directory contains resources the user interface of the upload control needs to function properly.
Example: "/ScormEngineInterface/scripts/EngineUtils/UploadImportControl/"
UrlToLetsiRtwsEndpoint - URL to the LETSI RTWS endpoint which will be appended in an initial browser request for a LETSI RTWS enabled package as the LETSI_RTWS_URL. Only necessary if using the RTWS functionality.
Registration Instance and Package Versioning
These settings control how and when a new versions of packages and registrations are created. A version of a registration is called an "instance".
CreateRegistrationIfNeeded - When the SCORM Engine is launched with an external registration id that does not already exist, this setting controls whether a new registration is created for that id (setting="true") or if an error is thrown (setting="false"). This setting should be set to "false" only when SCORM Engine registrations are pre-created by the LMS via SCORM Engine API calls. Possible values: "true" or "false".
WhenToRestartRegistration - Controls the logic that is used to determine if a new instance of a registration should be created on launch.
<table>
<tr>
<td>Setting Value</td>
<td>Behavior</td>
</tr>
<tr>
<td>"1"</td>
<td>Never create new registration instances. Always relaunch the registration using the existing set of tracking data.</td>
</tr>
<tr>
<td>"2"</td>
<td>Create a new registration instance if there is a newer version of the package being delivered and the current registration instance is completed.</td>
</tr>
<tr>
<td>"3"</td>
<td>Create a new registration instance whenever there is a newer version of the package being delivered.</td>
</tr>
<tr>
<td>"4"</td>
<td>Create a new registration instance whenever the user launches a registration that has previously been completed.</td>
</tr>
<tr>
<td>"5"</td>
<td>Create a new registration instance whenever the user launches a registration that has previously been satisfied.</td>
</tr>
<tr>
<td>"6"</td>
<td>Create a new registration instance if there is a newer version of the package being delivered and the current registration instance is satisfied.</td>
</tr>
</table>
IsPackageVersioningEnabled -When the SCORM Engine's import routines are called with an external package id that already exists, this setting controls whether a new package version is created or whether an error is thrown. Possible values: "true" (create new package versions) or "false" (throw an error).
SystemHomepageUrl - Get the absolute URL of the cannonical, permanant, homepage for this system. Ideally this really is the homepage a user would use to access the system, but this must be cannonical and permanant, that is: it is a single URL the system can be identified by. Used by Tin Can when creating Actors from users in the system.
Optional SCORM Engine Features
These settings control the behavior of some optional SCORM Engine features that might not apply to all installations.
2004Enabled - Tells the SCORM Engine whether this installation has the capability to deliver SCORM 2004 content. This setting does not actually affect the SCORM Engine's ability to deliver SCORM 2004 content, instead it just tells the SCORM Engine whether or not to issue a warning message when the user attempts to import SCORM 2004 content. Possible values: "true" (SCORM 2004 support is enabled) or "false" (SCORM 2004 support is not enabled).
SSPEnabled- Tells the SCORM Engine whether this installation has the capability to deliver SSP content. This setting does not actually affect the SCORM Engine's ability to deliver SSP content, instead it just tells the SCORM Engine whether or not to issue a warning message when the user attempts to import SSP content. Possible values: "true" (SSP support is enabled) or "false" (SSP support is not enabled).
SSPSizeAllocation - When using SSP, this setting determines the maximum amount of storage that a given course can request for a given registration. This setting is an integer that specifies a number of bytes.
Example: "1048576" (corresponds to 1 MB of storage)
UseCompressedJavascript - The SCORM Engine sends a lot of JavaScript code to the user's browser to implement all of the required SCORM functionality. To speed up the loading process, by default, this code is compressed and consolidated. This setting controls whether the compressed version of the code is delivered to the browser (the best setting for production environments) or whether the raw, uncompressed code is delivered to the browser (useful for development and debugging). Possible values: "true" (deliver compressed code) or "false" (deliver raw code)
AiccSessionIdExternalConfigExclusions - If the AICC Url, with SID included, is too long, this parameter can be used to exclude non-essential external configuration parameters from serialization.
AiccUseLegacySidFormatForExistingRegs - The SCORM Engine is now using GUIDs for the AICC session ID (backed by the ScormAiccSession table). However, for continuity, we need existing registrations to continue to use the long tilde-delimited format. This parameter provides the ability to override that logic and force even existing registrations to use the GUID format.
EnableExternalIdEncryption - Value that determines if external IDs should be encrypted by default.
IntegrationEncryptionPassword - String used to generate the encryption key for securing URLs passed between the web services integration and the SCORM Engine. This should be set to a long random string.
SMTP_Host - Host name of the SMTP server used for email functionality. Used by the PENS system.
SMTP_Port - Port number of the SMTP server used for email functionality. Used by the PENS system.
SMTP_User - User name used for authentication of the SMTP server used for email functionality. Used by the PENS system.
SMTP_Password - User password used for authentication of the SMTP server used for email functionality. Used by the PENS system.
SMTP_UseSecureConnection - Whether to use a secure connection when communicating with the SMTP server used for email functionality. Used by the PENS system.
Pens_Mail_Receipt_From - The address that the PENS email receipts will be from.
Pens_Mail_Alert_From - The address that the PENS email alerts will be from.
Pens_Process_Sync - Whether PENS request should be processed synchronously (recommended for troubleshooting only).
Pens_ByPass_SSL_Validation - If set to true, PENS will ignore SSL certificate validation failures. Recommended for testing purposes only.
RtwsSessionTimeoutHours - Timeout of LETSI RTWS session in hours. RTWS servers may leave sessions enables indefinitely and should leave them enabled for at least 24 hours.
TinCanRootAccount - This is a colon-delimited name and password like "admin:mypass" which can be used to authenticate against the TCAPI with administrator rights. This parameter is required to use the built-in console's Tin Can statement viewer.
ConsolePassword - Password to gain access to the /tools/console/ page which contains some SCORM Engine diagnostic tools and hooks to the Tin Can Statement viewer.
Debug Settings
These settings control the amount of debugging information that is recorded by the SCORM Engine. There isn't much of a performance penalty for recording this information, so we recommend that these settings typically be left at their default values to assist with troubleshooting. In this context, "audit" means recording basic debug information about what happend and when. "Detailed" means recording the precise details of how each action was executed. In order for the "detailed" information to be properly recorded, the "audit" level information must also be captured.
KeepAuditLog - Determines whether server-side debug information is captured at the audit level. This log tracks which server-side pages where requested and when. Possible values: "true" (record information) or "false" (don't record information).
KeepDetailLog - Determines whether server-side debug information is captured at the detailed level. This log tracks the execution of server-side pages. Possible values: "true" (record information) or "false" (don't record information).
KeepSoapLog - When used a cross domain, central/remote architecture, this setting determines if the exact contents of SOAP web services calls between the central and remote instances are logged. Possible values: "true" (record information") or "false" (don't record information).
DebugControlAudit - Determines whether client-side information about the overall execution of the SCORM Engine is recorded at the audit level. "Control" information tracks what was launched when as well as the communication with the server. Possible values: "true" (record information) or "false" (don't record information).
DebugControlDetailed - Determines whether client-side information about the overall execution of the SCORM Engine is recorded at the detailed level. Possible values: "true" (record information) or "false" (don't record information).
DebugRteAudit - Determines whether SCORM runtime calls from SCOs are logged are recorded to the client-side debug log at the audit level. Possible values: "true" (record information) or "false" (don't record information).
DebugRteDetailed- Determines whether SCORM runtime calls from SCOs are logged are recorded to the client-side debug log at the detailed level. Possible values: "true" (record information) or "false" (don't record information).
DebugSequencingAudit - Determines whether the execution of the SCORM sequencing logic is recorded to the client-side debug log as the audit level. Possible values: "true" (record information) or "false" (don't record information).
DebugSequencingDetailed - Determines whether the execution of the SCORM sequencing logic is recorded to the client-side debug log as the detailed level. Possible values: "true" (record information) or "false" (don't record information).
DebugSequencingSimple - Determines whether the execution of the SCORM sequencing logic is recorded to the client-side debug log in the "simple" format when available. Possible values: "true" (record information) or "false" (don't record information). When true and enabled, this setting will disable DebugSequencingAudit and DebugSequencingDetailed.
DebugLookAheadAudit - The SCORM Engine executes "look ahead" runs of the SCORM sequencer whenever pertinent data is changed in order to determine whether or not to enable/disable/show/hide the various navigational controls available to the user. This setting determines if these executions are recorded to the client-side debug log at the audit level. Possible values: "true" (record information) or "false" (don't record information).
DebugLookAheadDetailed - Determines whether the execution of the look ahead SCORM sequencing is recorded to the client-side debug log as the detailed level. Possible values: "true" (record information) or "false" (don't record information).
DebugIncludeTimestamps -Determines whether or not the client-side debug logs should include time stamps indicating when audit-level events occur. Possible values: "true" (record time stamps) or "false" (don't record time stamps).
Logging - Both the .Net and Java implementations of the SCORM Engine include the capability to integrate with a server-side logging framework. The SCORM Engine uses Apache's log4net and log4j to store rolling logs of server-side activity on the file system. These logging systems have many settings that are stored in the web.config file in .Net and the log4j.properties file in Java. Refer to the appropriate logging system's website for information on configuring these systems. (Note that to use the log4net system, the "NETWORK SERVICE" user will need to have read/write permissions to the logging directory.)
Central / Remote Architecture
These settings apply to the use of the cross domain, central/remote architecture.
UseCrossDomainWebServices - Determines whether or not the cross domain, central/remote architecture is in use. If this setting is set to "true", requests to persist data will be forwarded to the location specified in the URLs specified in the CentralAiccRequestProcessorUrl and CentralWebServiceUrl settings. If this setting is set to "false", requests will be directly processed. Possible values: "true" or "false".
WebServiceRetries - If using web services, this setting determines the maximum number of times the remote instance will attempt to contact the central instance in the event of an error. Once the maximum number of retries has been reached, the remote instance will assume that communiation with the central instance has been lost and notify the user that an error has occured. This value is specified as an integer.
Example: "3"
WebServiceRetryInterval - If the remote instance needs to retry its communication with the central instance, this setting determines how long the remote instance will wait before resending the request. This value is specified in milliseconds. When using a central/remote architecture, the maximum time that could be spent retrying requests (calculated as WebServicesRetries * WebServiceRetryInterval) should be significnatly less than the default CommCommitFrequecy package property to prevent the remote server from being overloaded in the event of a failure of the central server. This maximum time value also needs to be less than the ASP.NET / JSP page timeout value.
Example: "5000" (corresponds to 5 seconds)
UseImportWebServices - Determines whether or not import controls should use web services to invoke import on a central server. Possible values: "true" or "false"