How to bulk import courses that do not have distinct identifiers in their course descriptions

EKP features bulk import utilities for both SCORM and AICC content. Using these utilities, you can package multiple courses into a zip file which you can then upload. EKP will create online modules based on the course descriptions in the zip file. In addition to information on how to launch and track the courses, EKP will extract descriptive information such as course titles, descriptions, objectives and so on. This is extremely handy if you need to import catalogs of hundreds or even thousands of courses.

Previously, the ID fields that EKP would use for the new modules would also be extracted from the course description files. While this usually works well, it fails if the course description files contain duplicate identifiers, since each module in EKP needs to have a distinct ID. This might happen for example if the course description files were created by copying a template and making only minimal changes.

Starting from version 5.6.0.119, the bulk import utilities provide an option to generate module IDs based on the file names of the imported items instead of the identifiers contained within course descriptions themselves. This provides an easy way to import large numbers of courses even if the identifiers within the course descriptions are not distinct.

The default is to use the identifiers specified in the course description files, as before. If you choose to generate IDs based on the file names and the items being imported are content packages, the IDs used will be the names of the “inner” zip files, without the .zip extension. If the items being imported are sets of AICC course structure files, the IDs used will be the base file names—for example, if one of the sets uses the file names course1.au, course1.crs, course1.cst and course1.des, then the ID used will be course1.

We know that many of you rely on the bulk import utilities to set up and updates your course catalogs, and we hope that this change makes them even more useful.

PENS authentication

I've written before about how to use a PENS-conformant authoring tool or LCMS with EKP. However, in that post I didn't fully explain the intricacies of how EKP handles authentication of PENS requests.

EKP actually provides two PENS endpoints, which differ only in how they handle authentication. Assuming your installation uses the default /ekp/ path prefix, the endpoint URLs are as follows.

/ekp/pens
/ekp/servlet/ekp/pens

The first of these endpoints handles authentication exactly as described in the PENS specification. That is, the PENS request is expected to include parameters named system-user-id and system-password, the values of which should correspond with, respectively, the user ID and password of an EKP account with permission to create courses. (In fact, this endpoint will also accept credentials supplied as an HTTP basic authentication header. This is allowed primarily for consistency with other EKP web services. However, the request parameters always take precedence when supplied.)

The second endpoint ignores the PENS authentication request parameters and HTTP basic authentication headers, and instead uses EKP's standard login sessions for authentication. While this is strictly outside the scope of the PENS specification, it is convenient in situations where the PENS request originates directly from a browser. Since the user is likely to have already logged into EKP at the time at which the PENS request is sent, this approach avoids the need for the user to re-enter his or her credentials every he or she initiates the PENS publishing process.

User accounts and user statuses

Every user account in EKP has a Current Status field which, as of EKP 5.5, can take one of seven possible values. Herewith, a list of the possible values, and an explanation of the usage of each.

Active

The account is available for login.

Suspended

The account is not currently available for login, but is expected to be reactivated in the future. An account can be marked as Suspended by an administrator, or automatically as a result of too many failed logins.

Account Closed

The account is not available for login, and is not expected to be reactivated in the future. However, the account will still be viewable using review and administrative functions.

Logically Deleted

The account is not available for login, and is not expected to be reactivated in the future. Moreover, the account will be hidden in most parts of the system aside from the User Editor.

Self registration user pend for approval

The account was created by a user self-registering with the system. It is awaiting approval and activation by an administrator.

Locked

The account is not currently available for login, but might be reactivated in the future. Similar to Suspended. If specified under System Configuration, accounts are automatically marked as Locked after a period of inactivity.

User Account/Records Migrated

Used to indicate that records that were previously associated with this account have been migrated to a different account. The account is effectively obsolete, but has not yet been deleted.

[This post was updated on October 28, 2010 to remove obsolete licensing information.]

Desktop publishing tools and PENS

I've written before about how PENS can be used to enable one-click publishing from a publishing system (authoring tool or LCMS). Herewith, some notes on using PENS with desktop, as opposed to web-based, tools.

PENS requires that, when a publishing system sends a request to the LMS to “collect” a content package, it supplies a URL (typically using one of http, https or ftp for the URL scheme) from which the package can be collected. If the publishing system is web-based, then this URL will typically refer back to the publishing system itself.

For a desktop publishing system, this requirement effectively means that there needs to be a server, separate from the desktop software, to which the content can be uploaded prior to being collected by the LMS. Typically this will be an FTP server, although it could in principle be a web server.

Ideally, the desktop software will enable the user to configure details of this FTP server (including host, user name and password) in addition to the LMS details. When a course is published, the software should perform the following actions:

• package the content into a zip file;
• upload the content package to the FTP server using the configured host, user name and password; and
• send a PENS request to the LMS instructing it to collect the content package from the FTP server.

In principle, it would be possible to manually upload the content package to the FTP server if the desktop software does not do this automatically. In practice, though, this really defeats the purpose of using PENS, since it would be simpler to create a SCORM or AICC content package on the desktop machine, and then upload the package directly to the LMS.

Another theoretical possibility would be to run a web or FTP server on the desktop machine itself. However, this would require that the desktop machine has a stable IP address and/or host name that the LMS can call back to, and that HTTP or FTP requests to the desktop machine are not blocked by hardware or software firewalls. In other words, it's almost guaranteed not to work in practice.

In summary, a desktop publishing system can theoretically “support” PENS without also supporting the automatic FTP upload step. However, without this automatic FTP upload, PENS is unlikely to provide any practical benefit.

Sun Java Plug-in bug and SCORM communication

A few users have encountered the following issue that affects tracking of SCORM courses on a small number of EKP sites.

Symptoms: SCORM courses fail to communicate with EKP, and one or more messages like the one below appear in the browser's Java console.

java.security.AccessControlException: access denied (java.net.SocketPermission www.example.com:80 connect,resolve)

Analysis: This issue is caused by a bug in certain versions of Sun's Java Plug-in. The bug was introduced in Java 6 Update 3, and is fixed in Java 6 Update 10. It affects Firefox and Safari; Internet Explorer is not affected.

Note that this problem does not affect all sites. It appears to affect a small proportion of sites, and is related to the site's DNS configuration.

Solution: Users who encounter the problem described above can apply one of the following solutions.

• Ensure that your users are using a version of the Sun Java Plug-in that is not affected by this problem. Users who currently have Java 6 Update 3 or above can upgrade to Java 6 Update 10. (Note that, as of 9 July 2008, Update 10 is flagged as “beta.” However, it is the first version offered on the downloads page.)
• Another solution that appears to be effective is to ensure that each EKP domain (e.g. ekp.example.com) is mapped (via DNS) to a unique IP address. That is, where multiple EKP instances are located on a single server, ensure that each instance on the server is associated with a different IP address.

When do I need to use the Content Server Configuration settings in EKP Gold?

EKP Gold includes a Content Server Configuration page (under Manage > System Administration Manager > System Settings). However, it's not always necessary to explicitly configure a content server in order to enable learners to launch courses from servers other than the EKP server. Herewith, clarification of when it's necessary to explicitly configure a content server, and when it isn't.

EKP's content server configuration settings are designed to help you deliver courses to groups of learners whose connections to the main EKP server have limited bandwidth. You can upload the same course content to multiple content servers, and ensure that, when a learner launches a course, the course content will be delivered to the learner from a server that provides optimal delivery speeds. (The choice of server can be based on either the learner's identity or their network location.)

For example, suppose you need to deliver courses to employees located in your brand new lunar office. Since bandwidth between the moon and Earth is limited, you would like to ensure the course content is delivered to your lunar employees from a dedicated lunar content server, while Earth-based employees will continue to receive course content from your Earth-based server. You can use EKP's content server configuration to ensure that lunar employees receive course content from moon.example.com, while terrestrial employees receive the same content from earth.example.com.

However, there are other reasons besides bandwidth why you might want course content to reside on a different server from EKP. For example, the course content might require a server-side scripting language that is not available on the EKP server. Or the courses might be provided by a vendor that hosts the content themselves instead of providing it as files to be uploaded to an LMS server (which can be extremely convenient if the content is updated frequently). In these cases, although the content for a particular course will be delivered from a content server separate from the main EKP server, it will always be delivered from the same server regardless of the learner's identity and network location.

If the content of any particular course should always be delivered from the same server, even if it is not the main EKP server, then it's not necessary to explicitly configure any content servers, and it's not necessary to be running EKP Gold. In this case, it's only necessary to ensure that the relevant launch URLs accurately reflect the location of the course content (which might require that they be specified as absolute, rather than relative, URLs), and this will work just fine on EKP Silver or EKP Bronze. Note that it's still possible to import the EKP course catalog entries from SCORM or AICC content packages even if the course content will not reside on the EKP server; however, in this case the packages will typically contain only course description files (i.e. imsmanifest.xml and related files in the case of SCORM-conformant courses, or AICC course structure files in the case of AICC-conformant courses), and not the actual course content files. Note also that you might still need to work around cross-site scripting issues—however, it's generally more straightforward to do this by setting up a reverse proxy on the EKP server rather than by explicitly configuring content servers in EKP.

(To be really precise, we should state that content server configuration is required only if the host portion of any course content URLs needs to change based on the learner's identity or location—for example, http://earth.example.com/path/to/content versus http://moon.example.com/path/to/content. This is not quite the same as stating that the courses need to be launched from different servers, since it is possible to map a single host name to multiple physical servers—for example, the single host name earth.example.com might be mapped to multiple physical servers. However, this difference is unlikely to matter in practice unless special content distribution technology is being used.)

How can I change the size of the navigation frames for a course with multiple SCOs or AUs?

When you launch a SCORM course with multiple shareable content objects (SCOs), an AICC with multiple assignable units (AUs), or a course created using the Courseware Manager with multiple lessons, EKP provides one or more frames containing navigation controls that the learners can use to navigate between the SCOs, AUs or lessons of the course.

If you are using EKP Gold or EKP Silver, you can change the size of these frames by creating a custom courseware template, provided that you have the appropriate administrative privileges. The steps are as follows.

• Create a courseware template package. You can use the files under nd/fresco/template/course/default as a guide. Copy the files to a new folder, edit default.css as required, then package the files as a zip file, ensuring that default.css is in the root of the package. (Note that you do not need to edit default.css to change the size of the navigation frames, but you can change the fonts and colors used for the navigation controls.)
• Go to Manage > Courseware Manager > Courseware Template Editor, and click the Create button.
  
• In the new window, enter a name for the template, then click the Browse... button and select the courseware template package (zip file) you created.
  
• On the next page, click the top frame in the image.
  
• In the Top Frame window, enter the desired height for the top frame. You can specify the height as a percentage of the total window height or as an absolute number of pixels.
  
• Set the width of the left frame by clicking the left frame in the image.
  
• Click Update to save the courseware template settings.

You can configure a course with multiple SCOs, AUs or lessons to use your custom template by opening the course in the Catalog Editor, clicking Navigation Setup in the left frame, selecting your custom template from the Template drop-down list, then clicking the Save button in the top frame.

Note that EKP needs to provide navigation controls for a course with multiple SCOs, AUs or lessons in order to ensure correct tracking, so you cannot remove the navigation frames. For a more detailed, see my earlier post.