Skip Ribbon Commands
Skip to main content
Sign In
Advancing the public health workforce to achieve organizational excellence
How TRAIN can be Integrated with Partnering Learning Management Systems


TRAIN, the premier learning management network for professionals who protect the public's health, can be integrated with external, partnering LMSs in order to ease the transfer of information between two systems and improve collaboration and coordination between public health organizations using different LMSs in jurisdictions across the nation. It is recommended, but not required, that any organization or learning management system interested in establishing an integration with TRAIN first contact Public Health Foundation's TRAIN Team at training@phf.org.


The information outlined below and in the linked pages are meant for information technology (IT) professionals at external, partnering LMSs. This information will help outline what the current webservice capabilities of the TRAIN LMS are.


At the following link, a description of the webservice operations that TRAIN currently supports can be found: https://train.staging.kmionline.com/LMSIntegrator/Registrar.asmx In addition, this URL provides space for testing on TRAIN's staging server.


The above URLs are the actual webservices available for TRAIN. Typically you would put the "Service Description" or WSDL link in your SOAP client software.


It is recommended that a partnering LMS use the UpdateRegistrationAllInOne operation option, as it is simpler. The other operation options are for: logging in, updating many registrations, and logging out. Moreover, sometimes some software has issues keeping track of the session information, thus the UpdateRegistrationAllInOne accepts the username/password on each registration update without the need to keep session state. One call per update should be performed, so if you are doing batch updates you would create a loop and invoke the service many times with different data. In addition, because this is a SOAP webservice, using a SOAP client would be best, however a partnering LMS can simply conduct an HTTP POST if a SOAP Client for the programming language being used cannot be found.


When a course from the LMS being integrated is posted to TRAIN, the Course Provider will need to select the external LMS integration option and provide a lunchURL. Then, when the course is launched, TRAIN sends data on the launchURL for the partnering LMS to pickup and begin the tracking. ProviderCourseID is the ID of the course in the partnering LMS's backend; this information can be provided to TRAIN when posting the course to train.  The ProviderCourseID should be unique to the course so that the LMS knows what course to launch for the particular request.  This allows a partnering LMS to use the same integration for multiple courses from its system. The TRAINCourseID is the ID of the course within TRAIN; this will be unique to each course posted to TRAIN.  The ID number will be needed to perform the postback.


The remaining URL fields sent back to the partnering LMS are:


UserID - The user's ID within TRAIN; this data point will be needed to perform the postback to TRAIN.
Email - User's email address
Name - User's name (last,first)


Therefore, a sample LaunchURL with the External LMS Integration option turned on in TRAIN may look like: http://some.courseprovider.com/integratedfromtrain.asp?ProviderCourseID=12312&TRAINCourseID=4323423&UserID=123123&email=favoritelearner@kmionline.com&name=Learner,Favorite

 

That information is then picked up and the external, partnering LMS performs the necessary steps on its end to get the user started in the course in the partnering LMS's system. Therefore, it is necessary for some of this information to be stored in a database on the partnering LMS's end. For example when the completion data for a user is postbacked, the partnering LMS will need the TRAINuserID and the TRAINcourseID. When the user completes the course, the partnering LMS simply invokes the webservice to post the completion data to TRAIN.


The username/password the webservice asks for is the username/password of the Course Provider who posted the course to TRAIN. If there is more than one Course Provider for the courses posted from the partnering LMS to TRAIN, then the partnering LMS will have to know what username/password to use for what course. Therefore, it is suggested to create a special Course Provider account on TRAIN specifically for the External LMS Integrated course(s) to avoid this problem. TRAIN will need to know what username(s) will be used as Course Providers for the External LMS Integration so that they can be granted special permissions on their account that allow the process to complete.

A flow diagram outlining the step-by-step information transfer process of the TRAIN Integration functionality with an external, partnered LMS can be found here. We recommend reviewing this document to help visualize the transfer process.


Please send any questions or requests for assistance to training@phf.org.

How TRAIN can be Integrated with Partnering Learning Management Systems