Experience API (xAPI)

At Rustici Software, our hope is that we have read and implemented the specifications of important learning standards so that you don't have to. We work hard to be the AICC, SCORM, xAPI, and cmi5 experts so that you can implement our software without the need to become a standards expert. Our product design philosophy boils down to: it just works.

We implement several important learning standards in Engine: AICC, SCORM, xAPI, and cmi5 to name a few. Our support for AICC and SCORM spans more than a decade, so we focus our discussion in this section on the implementation of xAPI, as it represents a sea change from the implementations of AICC and SCORM.


The Experience API (or xAPI) is a learning standard that seeks to resolve some of the acknowledged shortcomings of AICC and SCORM by providing a means to track learning experiences across a much broader variety of platforms and sources.

xAPI enables tracking experiences by describing a way to record statements of the basic form <I> <did> <this>.

Key concepts of xAPI:

  • statements -- the expression of an experience implemented in JSON and stored in a learning record store (LRS).
  • learning record store (LRS) -- the repository for xAPI statements
  • activity provider -- anything that can generate statements and post them to an LRS, whether packaged content similar to previous related learning standards or a physical device with a network connection

There are a variety of REST resources described by xAPI, and Engine implements each of them fully. Using Engine as your LRS, though, should enable a common approach across all learning standards to basic import and launch functionality (where applicable, depending on the nature of activity providers), as well as a flexible approach to reporting.

Generally, we would expect reporting based on data in the LRS to occur against a companion data store designed to support reporting requirements rather than for ad hoc queries to be run directly using xAPI.

For the purposes of packaging, importing, and launching xAPI content Engine implements a companion document to the core xAPI specification that describes a packaging and launch mechanism originally devised by Rustici Software and adopted widely by most major authoring tools. Additionally, Engine also implements support for the new cmi5 specification. This specifications exists as a profile of the xAPI specification that defines a new format for packaging, importing, and launching content that uses the xAPI standard to communicate details back to Engine's LRS. The expectation is that this standard will eventually eclipse the pre-existing companion launch specification in usage within the industry.

Since the xAPI standard emerged from Project Tin Can, there are still references to "Tin Can" or "the Tin Can API" in Engine's implementation.

Your instance of Engine, by default, implements the API at an endpoint of /lrs/{tenant}. For example, /RusticiEngine/lrs/acme would only deal with xAPI data from the tenant named acme.

Please note that you will need to create the tenant before referencing it through the LRS.

If you are not using the multi-tenant capabilities of Engine, and want the data to go into the 'default' tenant, then you can leave the tenant portion off of the url.



In order to use xAPI in Engine, you must first uncomment or add SystemHomepageUrl to your Engine settings file. Because xAPI requires that some IDs exist as URIs, we require that a URL be configured for the circumstances where Engine has responsibility for creating xAPI IDs. Our recommendation is that this setting be unique to and descriptive of your application. So, for instance, the SystemHomepageUrl for our hosted LRS in Cloud is simply "https://cloud.scorm.com/".

xAPI Files Storage

In previous versions of Engine, we required customers provide a file storage mechanism for entities like large xAPI documents and attachments. This was made optional in 2016.1.23, though specifying a files path was still required for attachment support until 2017.1.9. In any case, if you are coming from an earlier version of Engine and can verify that you have no data in your xAPIFilesPath storage any longer, you no longer need to specify a storage mechanism.

Large documents are a very rare phenomenon, and as of 2017 xAPI attachments are barely seeing usage outside the context of the ADL conformance test suite, much less large attachments. In the vast majority of cases it will not be necessary for your LRS to support them. If you discover that you must support large attachments and documents, however, you will need to provide a storage mechanism for those objects. (In this context, "large" means greater than xAPIMaxSizeForDatabaseInBytes, which can be configured, but the default of which 64 KB). You can specify xAPIFilesPath to specify a storage mechanism for both large documents and large attachments. If you want to support one but not the other, or otherwise provide different storage mechanisms for each, you can specify xAPILargeDocumentsPath and xAPILargeAttachmentsPath individually. All these settings are file store, and so they do not necessarily have to be filesystem paths.

results matching ""

    No results matching ""