Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

External tool: Difference between revisions

From MoodleDocs
Line 4: Line 4:
== LTI Source Plugins ==
== LTI Source Plugins ==


The External tool supports sub plugins that live under the ''mod/lti/source'' directory and the plugin type is ''ltisource''.  The purpose of a LTI source plugin is to extend the functionality of the External Tool activity.  Those extensions are discussed below.
The External tool supports sub plugins that live under the ''mod/lti/source'' directory with the plugin type of ''ltisource''.  The purpose of a LTI source plugin is to extend the functionality of the External Tool activity.  Those extensions are discussed below.


=== Extending the LTI protocol ===
=== Extending the LTI protocol ===

Revision as of 17:16, 16 May 2014

This page documents the External tool plugin in Moodle and its features.


LTI Source Plugins

The External tool supports sub plugins that live under the mod/lti/source directory with the plugin type of ltisource. The purpose of a LTI source plugin is to extend the functionality of the External Tool activity. Those extensions are discussed below.

Extending the LTI protocol

The most powerful thing that the LTI source plugins can do is extend the LTI services provided by the External Tool activity. All incoming requests are handled by mod/lti/service.php and all standard LTI requests are automatically handled. But, if the request is not one of the standard LTI requests, then an LTI source plugin has an opportunity to handle the request.

The request is routed to the LTI source plugin by using the message type. For example, let's say this request was sent to the External Tool:

<?xml version="1.0" encoding="UTF-8"?> <imsx_POXEnvelopeRequest xmlns="http://www.imsglobal.org/services/ltiv1p1/xsd/imsoms_v1p0">

   <imsx_POXHeader>
       <imsx_POXRequestHeaderInfo>
           <imsx_version>V1.0</imsx_version>
           <imsx_messageIdentifier>999998123</imsx_messageIdentifier>
       </imsx_POXRequestHeaderInfo>
   </imsx_POXHeader>
   <imsx_POXBody>
       <widgetCustomRequest>
           <widgetRecord>
               <sourcedGUID>
                   <sourcedId>3124567</sourcedId>
               </sourcedGUID>
           </widgetRecord>
       </widgetCustomRequest>
   </imsx_POXBody>

</imsx_POXEnvelopeRequest>

In the above request, the message type is widgetCustomRequest. Since this is not a standard request, a LTI source plugin can handle it. We can do this by adding a LTI source plugin and for this example, we will call it widget. In order to handle the request, we must make a function in our widget plugin to handle the request. The function name takes on the form of component_messageType. So, for our above example we would create mod/lti/source/widget/lib.php and add this to the file:

/**

* Handle a custom widget request.
*
* @param object $data The LTI request details
*/

function ltisource_widget_widgetCustomRequest($data) {

   $data->body;         // The raw LTI request XML body.
   $data->xml;          // A SimpleXMLElement of the XML body.
   $data->messageid;    // The value of the <imsx_messageIdentifier> element in the request.
   $data->messagetype;  // The message type.
   $data->consumerkey;  // OAuth consumer key.
   $data->sharedsecret; // The shared secret used to verify the request body.
   // Do your custom work here.
   // Throw exceptions on error, they will be sent back appropriately.
   // When done, echo out your response XML.
   $responsexml = lti_get_response_xml(
       'success',
       'Widget handled',
       $data->messageid,
       $data->messagetype
   );
   echo $responsexml->asXML();

}