Tin Can LRS Installation and Configuration

Installing and Configuring the Tin Can LRS module

This document describes the steps to install and configure the Tin Can LRS module for use.

Module Dependencies

UUID -- https://www.drupal.org/project/uuid
Services -- https://www.drupal.org/project/services
Entity API -- https://www.drupal.org/project/entity
Entity Reference -- https://www.drupal.org/project/entityreference
Views -- https://www.drupal.org/project/views
Tin Can Server -- included with Tin Can LRS
Tin Can Services Basic HTTP Authentication -- included with Tin Can LRS
Tin Can LRS Field Types -- included with Tin Can LRS

Install each module listed above and their dependencies in the standard Drupal manner.

Services Configuration

Create an Services Endpoint

The first configuration item is to create a Services endpoint that will be the url which the Tincan LRS can be reached as a base for all API calls.

Navigate to <drupal_root>/admin/structure/services/add
Enter a machine name for the the endpoint
Select “Tincan” as the Server
Enter a path to the endpoint, recommend using “xAPI”, but any new relative path will do
Enable HTTP Tin Can basic authentication under “Authentication”
Click Save

Configure Endpoint Server Formatters and Parsers Settings

It is important to properly set the formatter and parser settings. The configuration for this area will likely change in the future. This is an area of fluid development. For the stable release the intention is to support three request parsers: “application/json”, “application/x-www-form-urlencoded”, and “multipart/mixed”. The “multipart/mixed” parser is still in development and not currently available.

The path to this configuration page is dependent on the machine readable name you entered for your endpoint. If you entered tincan_xapi for the machine name then the path to this page is:

<drupal_root>/admin/structure/services/list/tincan_xapi/server

It is the same as the “Server” tab if you are editing your endpoint

Make sure that “json” and "octet-stream" are checked for the Response Formatters

For Request parsers, make sure, “application/json”, "text-plain", and "octet-stream" option is selected and it is useful for some cases to enable the “application/x-www-form-urlencoded” option for the Request Parsing options

Configure Tin Can Authentication

There are no configuration options at this time

Currently only HTTP Basic authentication is available. Oauth support is currently in development.

Configure Resources

To enable resources, goto the “Resources” tab of your endpoint configuration. An example path is: <drupal_root>/admin/structure/services/list/tincan_xapi/resources This assumes the machine name of the endpoint is “tincan_xapi”

The Tin Can LRS module provides 4 resources, each with several CRUD operations

about (index)
activities (create, retrieve, update, delete, index)
agents (create, retrieve, update, delete, index)
statements (create, retrieve, update, index)

Create = POST

Update = PUT

Retrieve = GET

Index = GET (without any parameters)

Delete = DELETE

If you want to allow GET requests to any API you should enable both Retrieve and Index.

Check all resources that you want to expose for the endpoint.

The statements resource is the resource that exposes the Tin Can Statement API.

activities exposes the Activities, State and Activity Profiles API

agents exposes the Agents and Agent Profiles API

about exposes a simple About message

Tin Can LRS Users and Permissions

The Tin Can LRS module provides a large set of Drupal permissions.

For Tin Can Basic HTTP Authorization to work, you must give at least one user permissions to access the API. The Drupal user’s username and password will be the username and password to be used for API requests and that is authenticated.

We recommend creating a user role specifically for users that have credentials to access the API. In our implementations, we’ve created a user role “LRS User”.

The permission “Access Tin Can APIs” gets the user in the door, through the Services authentication. This permission is necessary for a user to access any API.

From there each API and HTTP method has appropriately named permissions. You can restrict a users of a role to only the GET method of the Statement API, if you only enable the “Access Statement GET API”.

There is also a special permission “Void Tin Can Statements”. If the user role is not given this permission, but all the other permissions for the Statement API are enabled, then the user may send statements to the LRS, but they will not be able to send statements which void other statements.

You need to setup at least one user that has permissions to use the API.

I recommend created a role, perhaps named "LRS Authority"

Give this role all the API related permissions. The username and password for this user, will be what you enter for the username and password in modules such as the TincanAPI module

For viewing all the data, View Tin Can statements, View Tin Can statement attachments, View Tin Can agents, View Tin Can activities, View Tin Can states, View Tin Can activity profiles, and view Tin Can agent profiles are all used to control access to viewing Tin Can Drupal entity data that is created as a result of API calls. These can be used to control access to any Views, or entity view pages.

Summary

That is all the configuration that is necessary to get up and running with the Tin Can LRS.

The Tin Can LRS is a work in progress. The goal is to achieve full Tin Can 1.0 Specification conformance. We are developing to meet the specific needs of our paying clients first, and from there we will finish off any necessary features and functionalities.

More is done than is not done, and this module has been tested with:

https://www.drupal.org/project/tincanapi

Verified to work in production environments Articulate Studio, Articulate Storyline 2, Articulate Storyline 3, Adobe Captivate, and should suppot any Tin Can 1.0 packages.