cmi5: An overview of the Process Flow

This is the second in my series of articles on cmi5. In “The next generation SCORM: cmi5”, I provided an overview of the cmi5 specification. In this article I’ll provide an overview of the cmi5 process from beginning to end.

This is the second in my series of articles on cmi5. In “The next generation SCORM: cmi5“, I provided an overview of the cmi5 specification.  In this article I’ll take a brief look at the cmi5 process flow from beginning to end.

 Step 1: Develop your cmi5 AU(s)

This seems rather obvious, but first you have to develop your cmi5 compliant Assignable Units (AU).  To do this, you are going to need to know how to write and read xAPI statements.  cmi5 uses the xAPI Learning Record Store (LRS) as the communication path between the Learning Management System (LMS) and the AU.

cmi5 Communication Paths

As an AU developer, there are certain xAPI verbs that are required by cmi5.  You can of course make any xAPI statements you want, but only the cmi5 verb statements will be relevant to the LMS to AU communication.  To learn about the cmi5 verbs, see section 9.3 of the cmi5  specification.

Step 2: Develop your Course Structure XML

Like SCORM, courses are imported into the LMS.  A course consists of one or more AU(s).  Unlike SCORM, the actual AU files are not imported, only the course “structure”.  The AU(s) can reside anywhere; a mobile app, a content distribution network, inside your firewall, etc.  The course structure is an XML file.  The elements of this file are defined in the cmi5 specification, section 13.

Step 3: Import the Course Structure to your LMS

Under cmi5, the LMS is required to have the ability to both import and export a course structure.  The implementation of this is left up to the LMS.

Step 4: Assign and Register

Using whatever method available in your LMS, an Administrator can now assign the course to a student and the student can create a registration for the course.  Registration is an important concept in cmi5.  It should be create a unique identifier for the student and course.  Each cmi5 statement must include the registration in the “context” property.  For more information, see 9.6.1 of the cmi5 specification.

Step 5: Launch of the AU

The student may now launch the AU from the LMS.  At this point the LMS is required to perform the following:

  1. Write a contextTemplate document to the xAPI State in the LRS.
    Prior to launching an AU, the LMS must create a document in the State API of the LRS.  This document contains important information that the AU will require, including the mastery score and other data from the course structure.  Please note that the LMS may edit course structures once they are imported, so it is import to read values from the State API to determine the current values of properties like the masteryScore.  The State API document also includes a sessionId value that is a unique identifier for a single AU “session”.  The LMS must generate a unique sessionId each time a student launches an AU.  For more information, see section 10 of the cmi5 specification.
  2. Update the Agent Profile data
    Under cmi5, the xAPI Agent Profile stores preference data for the student.  Generally, both the AU and the LMS may make changes to the Agent profile, although there is a provision for the LRS/LMS to forbid changes to the profile by the AU.  Section 11 of the specification discusses the Agent Profile.
  3. Launch the AU
    The LMS next builds and executes a launch command using named parameters as defined in Section 8 of the specification.  These parameters include the base endpoint for the LRS.
  4. Write a “Launched” statement to the LRS.
    Under cmi5, both the LMS and the AU write statements to the LRS.  The “Launched” statement is used to indicate that the LRS has written the contextTemplate document and launched the AU.

Step 6: The AU Initializes

Once launched, there are several things the AU must do:

  1. Extract the various launch parameters from the command line.
    These include the LRS endpoint, the actor (student), the registration and the activity_id.  If basic security is being used, a fetch URL is also provided.  This is used to fetch an authorization token.
  2. Obtain authorization token
    As mentioned above, if basic authentication is being used the AU must fetch an authorization token.  This is done by making a one-time hit to the URL contained in the “fetch” parameter.  This token is then included in all xAPI communications with the LRS for the duration of the session.  The authorization token is required to read from and write to the LRS.  (See section 8.2 of the specification).
  3. Read parameters from xAPI State Document
    The AU must now fetch the xAPI State document created by the LMS in step 5, item 1 above.
  4. Read preferences from the xAPI Agent Profile
    While not all AU’s will have profile settings, any such preference will be stored in the Agent Profile.  The rules for preference settings are in section 11 of the specification.
  5. Write “Initialized” statement to the LRS
    The AU, once initialized and ready for student interaction, must make an xAPI statement to the LRS using the “Initialized” verb.  Section 9 of the specification is devoted to the structure of a valid xAPI statement for cmi5.

Step 7: Learner Interaction

At this point the path taken by the AU will vary.  The AU may send any valid xAPI statements to the LRS, but any “cmi5 defined” statements must follow the rules specified in section 9.3 of the cmi5 specification.

Move On Criteria

If you want your student to receive “credit” in the LMS for the AU, you must pay attention to the moveOn element of the State API.  This element can be one of the following values:

  • Passed
    If the LMS receives a statement with the verb “Passed”, then the LMS will consider the AU satisfied.  Please note that if you issue a “Passed” statement and include a score, that score must exceed the masteryScore contained in the contextTemplate document of the State API.
  • Completed
    If the LMS receives a statement with the verb “Completed”, then the LMS will consider the AU satisfied.
  • CompletedAndPassed
    In this case the LMS must receive two statements; one with the cmi5 verb “Completed” and one with the cmi5 verb “Passed”.  The AU is considered satisfied only when both statements have been received.
  • CompletedOrPassed
    If the LMS receives a statement with either of the cmi5 verbs “Completed” or “Passed”, then the LMS will consider the AU satisfied.
  • Not Applicable
    The LMS will consider the AU satisfied as soon as the student registers for the course.

For more information on the “moveOn” criteria, see section 13.1.4 of the specification.

Step 8: Student exits AU

A “Terminated” statement must be sent by the AU when the student exits the AU,  Assuming the student has met the “move on” criteria, the LMS will determine the next AU to assign (if any) and make it available to the student.

Summary

So now you have a basic overview of the cmi5 process flow.  In future articles, I’ll dive into more details about the cmi5 elements.

Art Werkenthin
Art Werkenthin is president of RISC, Inc. and has over 30 years' experience working with LMS systems in the Oil & Gas, Retail, Finance and other industries. Mr. Werkenthin holds a B.S. in Electrical Engineering and an M.B.A. in Information Systems Management from the University of Texas. Mr. Werkenthin is a member of the ADL cmi5 committee and frequently presents on cmi5 and xAPI. Follow him on Twitter @AWerkenthin for xAPI and cmi5 updates, as well as blog post announcements.
Menu