What are Different Ways xAPI Data Can Flow from an LMS to an LRS?

What are Different Ways xAPI Data Can Flow from an LMS to an LRS?

Client Side

This is the most common case.


This is usually the approach taken if you create your content in a commercial authoring tool and export the content to xAPI/TinCan. The content package sends xAPI data directly to the LRS. The content package includes hard-coded credentials to connect to the LRS. Data might also be exchanged between the content and the LMS. The content package is hosted by the LMS.

Pros

  1. Doesn’t require any special integration with the LMS.
  2. Simple and easy (supported by most authoring tools).

Cons

  1. Uses long-lived LRS access key credentials, which is not ideal and less secure.
  2. Requires modifying each content package/course if the target LRS system changes.
  3. Requires you to upload a physical copy of the content into the LMS.
  4. Requires you to make duplicate copies of the content if you need to distribute it to more than one LMS.
  5. Potential for identity confusion.

Server Side

A more secure solution.


The content communicates with the LMS via SCORM, as usual. The LMS sends data to the LRS over xAPI. This is transparent to the content and keeps the LRS access credentials more secure. Content is hosted by the LMS.

Pros

  1. More secure than client side.
  2. Identity is easier to support (uses the LMS).
  3. Only requires making a code change in one place if the target LRS system changes in the future.
  4. Can generate xAPI data from SCORM content and sends the data to both the LMS and the LRS.

Cons

  1. Requires integration support from LMS vendor (they may not support it).
  2. Some relevant analytics and data are only available via the client side (content).
  3. Requires you to upload a physical copy of the content into the LMS.

Veracity Launch Delegate™

This improves upon the server-side option.


The Veracity Launch server talks with the content via any standard (SCORM, xAPI, cmi5) and sends xAPI data to the LRS. Content is hosted on the Launch server. The LMS hosts a Delegate™ package. SCORM completion data is also sent back to the LMS.

Pros

  1. More secure than client side.
  2. Compatible with any LMS that supports SCORM 1.2.
  3. Adds optional xAPI and cmi5 content playback support to your LMS.
  4. Allows you to distribute and deliver the same content to multiple LMSs (if they support SCORM 1.2).
  5. Sends data to both the LMS and LRS.

Cons

  1. Introduces another technology solution in the ecosystem (i.e., requires you to upload the physical content in Veracity Launch and download a Delegate™ package).