The following components are involved in the integration of Mumie into Moodle (master LMS):
  • Moodle as the master LMS
  • Mumie as the CMS with mathematical content
  • Activity (module/plugin) in Moodle
  • Mumie service layer that provides webservices to store data in the Mumie and to get data out of the Mumie

Components of the Mumie integration into a master LMS

The communication between Moodle and Mumie takes place over the activity in Moodle and the Mumie service layer. The activity in Moodle activates the synchronization and the Mumie service layer is responsible for the actual synchronization of the data.


  • Clear interface
  • Decoupling of systems
  • Outsourcing of logic
  • Reuse possible: connection of other master LMS or other external applications

Mumie activity in Moodle

  • Moodle is modular.
  • Activities in Moodle are a concept for expanding the functionality of Moodle.
  • The Mumie activity is a part of Moodle.
  • The activity expands Moodle with Mumie functionality.
  • Other well known examples of activities in Moodle are the forum or the quiz.
  • PHP

Mumie service layer

  • The Mumie service layer is located between Moodle and the Mumie.
  • It is independent and is neither a part of the Mumie nor Moodle.
  • It contains the synchronization logic.
  • The Mumie service layer has a clearly defined interface to the outside.
  • Java, [[|Apache Axis2]] (webservice framework)
  • Runs in a servlet engine (i.e. [[|Apache Tomcat]])
  • FIXME link to API spec.

Interface of Mumie service layer


Synchronisation-ids are used to identify the synchronized data. All synchronized data get a synchronisation-id. It's a string that identifies a user, a class or a tutorial explicitly. The master lms as the active part of the synchronisation is responsible for creating the synchronisation-ids. In some cases the vc-thread-id of mumie elements are used as synchronisation-ids. Examples are mumie courses, worksheets and problems.

Naming convention: "lms-table-id", "lms" is the master lms, "table" the database table and "id" the id in the database of the master lms.
For example "moodle-user-12" indicates a user from moodle with the id 12, "ilias-class-1" indicates a class with id 1 from ilias.

Transfer Parameters

Parameters of the webservices are transfered as objects. To create a user in the mumie for example, the method createUser() is called. If the parameters are transfered as objects, the method expects a user object, createUser(user). The user object contains the attributes syncid, surname, firstname, login, password, email, lang, pure_name, section and groups of the user. The advantage is that the interface is simple und readable.

Classdiagram of transfer objects

Classdiagram of grade transfer objects

integration-components.png (13.9 KB) Marek Grudzinski, 04/07/2013 12:01 PM

imumieservice.jpg (142 KB) Marek Grudzinski, 04/07/2013 12:02 PM

transfer.jpg (90.4 KB) Marek Grudzinski, 04/07/2013 12:02 PM

transfer_grade.jpg (70.2 KB) Marek Grudzinski, 04/07/2013 12:02 PM

Integration-components Imumieservice Transfer Transfer_grade
Add picture from clipboard (Maximum size: 500 MB)