The Open Source TeSLA CE SDKs for supporting TeSLA CE REST API.

Available SDKs:

• PHP Client : VLE integration
• Python Provider SDK : Providers integration
• Pyhton Client : General API methods for generic and admin calls such as system installation, client set up, and so on.

Table Of Contents

$this->client = new Client($role, $secret, $base_url, !$debug, $tesla_cache);

self._client = Client.create_instance(config['VAULT_URL'], config['VAULT_ROLE_ID'], config['VAULT_SECRET_ID'], config['VAULT_SSL_VERIFY'])

VLE Integration User Cases

1. Course Management

SDK for Course Management including 3 user cases: Create/Get/Update a Course.

$this->client->getCourse()->create(...);

$this->client->getCourse()->get(...);

$this->client->getCourse()->getByVleCourseId(...);

$this->client->getCourse()->update(...);

self._client.vle.course.create(...)

self._client.vle.course.list(...)

self._client.vle.course.find_by_vle_id(...)

# Not implemented
self._client.vle.course.update(...)

2. Add User to a Course

SDK for adding User to an existing Course.

Note that the User can be an Instructor or a Learner.

$this->client->getCourse()->addInstructor(...);

$this->client->getCourse()->addLearner(...);

# Not implemented
self._client.vle.course.add_instructor(...)

# Not implemented
self._client.vle.course.add_learner(...)

3. Get a Launcher

What you need for forwarding from your LMS to TeSLA CE Dashboard, without need of the use of credentials. TeSLA CE Dashboard can be used for monitoring status of instruments, informed consent, activities. Example: an Instructor using Moodle that wants to check TeSLA reports about specific activity in TeSLA Dashboard.

Note: TeSLA Dashboard can be access directly by an Institution role (legal, admin, send), but, by default, a user (either Instructor or Learner) is not allowed to access directly to TeSLA dashboard, she needs access through the LMS front-end. Please, note that you can change this behaviour by activating the option “login allowed” of the user profile in the Institution Admin Dashboard. In that case, you will need to assign a new password using the “Change Password” button.

Note: A course should be created first in the LMS front-end (for example Moodle). When the user uses the launcher, the system will check and decide if it needs to create the course in the TeSLA system.

$this->client->getLauncher()->create(...);

self._client.get_launcher(...)

4. Create/Get/Update an Activity

SDK for Activity Management including 3 user cases: Create/Get/Update an Activity.

$this->client->getActivity()->create(...);

$this->client->getActivity()->get(...);

$this->client->getActivity()->getByVleActivityIdAndType(...);

$this->client->getActivity()->update(...);

self._client.vle.course.activity.create(...)

self._client.vle.course.activity.get(...)

self._client.vle.course.activity.find_by_vle_id(...)

self._client.vle.course.activity.update(...)

5. Learner Information

$this->client->getLearner()->create(...);

// Not implemented
$this->client->getLearner()->get(...);

$this->client->getLearner()->getByUid(...);

// Not implemented
$this->client->getLearner()->update(...);

# Not implemented
self._client.vle.course.learner.create(...)

self._client.vle.course.learner.get(...)

self._client.vle.course.learner.find_by_uid(...)

self._client.vle.course.learner.find_by_mail(...)

# Not implemented
self._client.vle.course.learner.update(...)

6. Assessment Data

In order to apply for a TeSLA CE Assessment, the system needs to send different type of data from the learner to the system.

We can differentiate two main types of send data processes: the enrolment data and the verification data.

The enrolment data is done once (unless the Institution decides it needs to be done more than once, such, for instance, once a year), and it’s done in the TeSLA CE dashboard. It implies the capturing of sample data in order to later verify that the learner applying for an assessment is, in fact, the right and allowed learner to do it.

The verification data process, instead, needs to be done every time that the learner applies for an assessment. Inside this verification data process we can differentiate between verification done during the assessment (while the learner is performing the assessment), versus the verification done after the assessment (once the learner has delivered task of the assessment).

The verification done during the assessment implies the capturing of several data (depending on the activated instruments for that specific activity) in order to verify that person typing, or sending, or recording the assessment is, actually, the allowed learner. An example of this assessment data could be face pictures for face recognition, or keystroke recording for keystroke dynamic recognition.

On the other hand, for the verification done after the assessment, the system analyzes the data sent by the learner (the deliverable item of the assessment, such a document) and compares it with other delivered items in order to detect if the content is copied by an other source or learner. As an example, the plagiarism detection tool uses this process in order to compare a delivered document with all the other delivered documents.

Create an Assessment

Since an assessment can be performed over several days, every different day will need a dedicated assessment for letting the system know that all verification data sent during the assessment is related to the same assessment and to the same learner. In order to achieve that target, the system returns a dynamic URL to be inserted in the LMS.

Moreover, when using this method, the system will take care of the following 3 possible scenarios:

• Enrolment process not done: system forwards the Learner to the TeSLA CE Dashboard for making the enrolment.
• Informed Consent is not accepted/signed: the system forward the Learner to the informed consent page in the TeSLA CE Dashboard.
• Otherwise (everything correct): the system returns a javascript (the URL connection) that should be inserted
  in the LMS for starting capturing data dynamically.

$this->client->getAssessment()->create(...);

$this->client->getAssessment()->close(...);

# Not implemented
self._client.vle.course.activity.assessment.create(...)

# Not implemented
self._client.vle.course.activity.assessment.close(...)

Verification Data sending during the Assessment

As mentioned in previous section, all data sent during an assessment needs to be related to an assessment session, i.e. needs to use the dynamic URL created in the “Create an Assessment” User Case.

Verification Data sending after the Assessment

For the verification data sending after the assessment, the data is not related to a session, but to a learner and activity. That’s the reason why the system needs to verify if the verification data can be sent, i.e. validate if the Course exist in TeSLA system, if the Activity exist, and if the instrument is activated for that particular TeSLA Activity.

So, the system needs to create the attachment stored in the LMS (the deliverable sent by the Learner) and also needs to verify if the data can be sent.

TODO: add document to an assessment

$this->client->getVerification()->sendActivityDocument(...);

$this->client->getVerification()->canSend(...);

# Not implemented