Banner LMB

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 2.0. Up-to-date documentation for the latest stable version is available here: Banner LMB.

The Banner/Luminis Message Broker is a Banner-Moodle integration enrolment module originally developed by Eric Merrill. It can be downloaded from the Modules and Plugins page here: [1] and is in the Moodle Tracker here: [2]

What it is...

The Banner/LMB enrolment plug-in can process either an XML flat file or live feed from Banner via the Luminis Message Broker. Information such as "people" "courses" and "enrollments" are used to set up users, courses and enroll users in courses in Moodle.

How it works...

Implementation Considerations...

Below is a list of considerations when installing and running the Banner/LMB Plugin:

Luminis Message Broker:

  • Firewall port must be open to allow outgoing traffic to the Moodle instance (in case of outsourced Moodle)
  • Does NOT like SSL certificates from certain companies, or which do not have the primary Moodle destination as the first listed domain on the cert. (aka Common Name on SSL Cert must match the LMB destination) (See more on SSL Certificates below)


  • watch out for permissions settings on the directories such as the /enrol/lmb, enrol/lmb/upload/ etc. - when improperly set, the logs did not work, nor the processing of the XML files/folder

SSL Certificates:

Known to Work:

  • Digicert
  • Geotrust

Known not to work:

  • PositiveSSL

From the README File


This enrollment plugin can digest XML from the Luminis Message Broker, allowing realtime Banner to Moodle integration, as well as full XML extractions from Banner.

You can use this module with or with Luminis Message Broker. If you do not use Luminis Message Broker, you can instead use this module to import XML files from banner on a manual or automated basis.

This is a heavily modified version of the IMS Enterprise plugin.

Unlike the Moodle 1.5 version of this module, the current can be almost completely customized from with the standard Moodle configuration pages. If you need to make changes for your specific install, please let me know, so I can look into making it into a preference item (also take a look at the todo list below).


1. Copy enrol/lmb into the enrol/ directory on your Moodle server.

2. Copy lang/en_utf8/enrol_lmb.php into the lang/en_utf8/ directory on your Moodle server.

3. Copy lang/en_utf8/help/enrol/lmb into the lang/en_utf8/help/enrol/ directory on your Moodle server.

4. You should secure enrol/lmb/secure/ with a username/password using .htaccess.

5. Login to your Moodle server as an admin user, and visit the 'Notifications' page. Moodle will automatically setup the tables for this module.

6. Under Course->Enrolments edit the settings for Luminis Message Broker. NOTE: You must save the setting at least once, even if you don't make any changes, before you use this module. This is a bug that will be fixed later.

LMB --- You can configure, through the Luminis Message Broker interface, the LMB module to be a HTTP consumer. You should point it to enrol/lmb/secure/liveimport.php on your Moodle server, and enter the HTTP username and password you setup previously. You should only use SSL (HTTPS) to ensure security of the interface.


When used with the Luminis Message Broker, you will generally import a complete XML from banner before the start of a term/semester, and the Luminis Message Broker will continuously send messages that will keep Moodle up-to-date throughout the term.

If you are using this module without Luminis Message Broker, you can configure the module to import a full XML file on a regular basis. To do this, call importnow.php from a script or cron, much in the same way that the Moodle cron is polled.

You should disable users from being able to change the course and user idnumber fields, these are used to reference courses. This may change in the future.

When doing mass imports, terms should come before courses and then crosslisted courses, users should come before enrolments (which need to come courses and crosslistsing). There are tools in work that will make this order less important.


Place a directory at the XML Folder path that you have specified in the settings. In this folder, place any XML files to be processed (must end in .xml), as well as a empty file called 'start'. The 'start' file and directory must be writable by the webserver.

When this is complete, you call extractprocess.php to preform the extract.

When the processing starts, the module will remove the file 'start', and create a file called 'processing'. After extract processing has completed, the 'processing' will be removed, and a 'done' file created. These status files allow people/scripts to check the state of the run. It is important that the XML files are not modified/replaced while the extract is processing, or inconsistent results may occur. Should a problem occur during extract, such as the processor dies, or the XML files are inadvertently modified/removed, it is safe to re-process the extract with a consistent set of XML.

In the event an incomplete XML set is processed, students/instructors may be inadvertently removed from their courses. Re-processing with a complete XML set will reinstate users into their courses and no data is lost.