Publishing a podcast using the News Manager

EKP 5.6 provides RSS feeds both for public news on the login page and for personalized news on a learner's home page. (Note: RSS feeds are available only if your license includes API access.)

In EKP 5.6.0.129 we have added support for RSS enclosures. Roughly speaking, RSS enclosures serve the same purpose as email attachments—they make is possible to attach a file of arbitrary type to a text message. Probably the most interesting consequence of this change is that it's now possible to use the News Manager to publish a podcast. Here's how.

1. Record a podcast episode, edit it as necessary, and save as an appropriate media file (audio or video). There are many tools available for recording, editing and encoding media files. For audio, we suggest Audacity for recording and editing, with the LAME MP3 encoder to generate MP3 files.

2. Upload your media file to the Repository Manager.

   

3. Create a news article in the News Manager. For the File Attachment URL field, select the media file you uploaded in the previous step. Make sure the article is targeted to the appropriate audience, and publish as usual.

   

4. A listener/viewer can subscribe to an appropriate RSS feed using a “podcatcher” such as Apple's iTunes. The podcatcher will download new podcast episodes as they are made available. The episodes can then be played offline, and can also be synchronized to devices such as portable MP3 players and phones.

   

The API Explorer

EKP provides an application programming interface (API) that enables other applications and Web sites to interact with EKP—for example, to create user accounts and enrollments, and to obtain information about courses, catalogs, enrollments and training records.

We've always provided API documentation as part of the EKP distribution. However, in working with software developers, we've identified a couple of ways in which the documentation could be improved.

Firstly, the API changes between releases as new API functions are added. This means it's important to work with the correct version of the documentation for the EKP version you're developing for. However, keeping track of different document versions is a hassle.

Secondly, most developers learn more easily if they are able to call API functions interactively and generate actual responses, rather than simply reading dry documentation. However, calling API functions generally involves writing code.

With these points in mind, in EKP 5.6 we introduced the API Explorer. The API Explorer serves two purposes: it is both an online reference for the API functions, and a tool that enables developers to learn about the API by calling its functions interactively.

The API Explorer lists the API functions available. For each function, it provides information about how to invoke the function, including the URL and the expected HTTP method, parameters and authentication scheme. Where possible, it provides one or more HTML forms that can be used to call the API function directly from the browser. (Note: some API functions cannot be invoked from a browser.)

The API Explorer can be accessed by appending api/ to the base URL of your EKP site. For example, if your site is located at http://www.example.com/ekp/, then the API Explorer for the site can be accessed at http://www.example.com/ekp/api/. At the time of writing, an instance of the API Explorer is available at http://utest2.netdimensions.com/utest/api/.

Note: If you do not see the API Explorer at the expected URL, your Web server (e.g. Apache or IIS) might not be forwarding the requests to Tomcat. In the case of Apache, you can fix this by adding a directive like the one below to httpd.conf.

JkMount /ekp/api/* ajp13

Publishing a new course revision to learners who have already completed an earlier revision

EKP 5.5 introduced the ability to create new revisions of existing courses. This simplified the process of updating an existing course, and made it possible to keep track of which version of a course a learner was taking or had completed.

When you created a new revision of a course, EKP would automatically make the new revision available to learners who were enrolled in, but had not yet started, an earlier revision. EKP also provided the option to make the new revision available to learners who had already started, but had not yet completed, an earlier revision.

Since we released support for course revisions, several of you have told us that you also needed to be able to make new revisions automatically available to users who had already taken and completed an earlier revision of the course, so that those learners would see the latest content if they reviewed the completed course. So, as of EKP 5.6.0.122, there is a third option when creating a new course revision, which publishes the new revision to all learners, including those who have already completed an earlier revision.

We hope this makes course revisions in EKP even more useful.

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, user statuses and license restrictions

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. Only accounts with this status are counted against the license user limit.

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.

Note that only accounts with the Active status are counted against the number of licensed users. There is no limit on the number of users with other statuses that may exist in the system, regardless of license restrictions.

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.