Users wanting to integrate their own applications into the ILP user interface have several options; choosing one means determining what kind of experience you’re trying to afford users, and what level of context you need passed back and forth between your application and the ILP (from a simple URL launch point to in-depth Learning Tools Interoperability®, abbreviated as LTI®).
|Minimal context passing||Complex context passing|
|Loose UI integration||
A simple link can act as a launch point from the
Learning Service's UI to your own application's
separate user interface, embedded in the navigation bar.
You can use replacement strings to pass simple context information through the invoked URL.
An external learning tool quicklink can act
as an LTI launch point to your application's
separate user interface, embedded in the navigation bar.
You can customize the LTI context data passed to your application, and also use replacement strings if needed.
|Tight UI integration||
A simple custom widget can provide LMS
course and site designers with a bounded region
within a Learning Service's homepage in which they
can place their own HTML for rendering. This can
include links off to your application or service.
Simple URLs placed in the widget can use replacement strings to provide you with a minimal level of context.
Custom widgets can also include quicklinks and
stuff-style objects, and these can act as an
LTI launch point to your application.
You can customize the LTI context data passed to your application, and also use replacement strings if needed. When your application responds to the launch point, you can send back data to render within the widget's bounded region.
A number of these scenarios can be conveniently and powerfully packaged by Remote Plugins that you can register wtih the Remote Plugin service.
D2L’s ILP can support connections to your application with various depths of context (letting you know who’s connecting to your application, from where, and why). The simplest connections you can build to your application provide the thinnest amount of context.
Each org unit can have a collection of links defined as resources it can draw upon. Simple links consist of an URL (which can include query parameters) paired with a descriptive title.
Referrer header. Your application can use the referrer HTTP header to intuit that the request comes from a D2L ILP service, and your application can then proceed to make Brightspace API calls to gather more data before sending back a response to the URL request. However, since all Brightspace API calls need to be made within the context of a particular user, unless your application already knows the right user context, you’ll probably need more contextual information.
Replacement strings. When you define a simple link, you can inline replacement strings in the URL text. These replacement strings get expanded by the Learning Service when the user clicks on the link, allowing your application to receive some contextual information directly encoded in the full URL of the request (for example, a user name, or organization name).
Because this substitution happens directly in the text of the URL being directed to, the site handling the link cannot really be guaranteed of the integrity or authenticity of this contextual data unless the communication path between the LMS server and the site handling the link are secured by some external means (for example, if the LMS server and the handling site were both within the LMS organization’s firewall).
An org unit’s custom link can be, instead of just a simple URL link, a QuickLink (an ILP-specific connection to a well-defined type of system tool) pointing to an External Learning Tool (a custom-defined interface to an externally hosted tool, taking advantage of LTI v1.1 to provide context).
You can define a custom link using LTI and then place that link in the D2L Learning Environment’s navigation bar, on a homepage, or within a course offering’s course content (via the Course Builder tool). These LTI links can pass your service a limited amount of pre-defined contextual information along with the HTTP request when an LMS user clicks the link.
In this case, the work flow uses these steps:
A LTI launch passes your application the context defined when the custom link was created. Some of the contextual information your application receives is defined within the LTI standard; D2L’s implementation supports several additional custom properties that it can provide to your application.
(Optional) You can decide to use LTI v1.1’s facility for posting result data back to the back-end Learning Service.
(Optional) You can decide to use the Brightspace APIs to fetch more context around the request (more detail about a user’s profile, for example), and to post result data back into the Learning Service.
Data exchange. When performing an LTI launch, tool consumers (the back-end learning service in this case) provide their context data to the tool provider (your service in this case) in POST form data.
Remote plugins. The Remote Plugin Service running in a D2L Learning Environment provides your service with a way to register a particular kind of integration with the Learning Service. This connection between the Learning Environment and your service gets built on top of the LTI protocol.
D2L’s ILP provides several general launch points, or places where you can integrate with the standard LMS user interface.
By default, organization and course homepages get constructed out of a set of widgets. For example a student’s view of the organization homepage might be built from several system widgets: My Settings, My Courses, Events, News, and so forth. Custom widgets let you expand this visual experience by adding custom HTML into a defined frame that can later be placed on a homepage. Custom widgets can point to content resources in LE, or act as an IFrame to other systems (but without inherent single sign-on).
Custom widgets can be placed on the org page where they’re created, and shared to all (and only) its descendants. (So, a custom widget can be created once at a department level, and then shared to all course offerings within that department; however, if you create a custom widget in one department, you can’t share it to another department: you’d have to re-create it.)
Permissions. For each role type, over each org unit type, a set of Homepage role permissions control this technique:
Manage Widgets lets a user role place an existing widget available to the current org unit onto that org unit’s home page.
Create/Edit Widgets lets a user role create a custom widget so that the current org unit can use it.
Share Widgets and Delete Shared Widgets lets a user role share a custom widget to org units that are descendants from the org unit where they’re created.
When using system-provided widgets, the permissions governing the system tool pertain to the content shown (or not shown) inside the widget. (So, when a user has the News widget embedded on a homepage, that user’s role in that context determines the News permissions that will affect the content the user sees.)
The Remote Plugin Service can provide a way for third-party applications or services to take advantage of a rich context connection with the LMS and directly provide you with a way to provide UI elements you control into the Learning Service’s visual content space. You register a Remote Plugin in the same way that you would create a custom link or widget: you define the item through its connection to your application or service within a particular org unit, and then you can choose to share that item down to any descendant org unit.
When you register the Remote Plugin, you choose its build type, declaring the way in which you intend it to integrate with the Learning Service’s UI:
Course Builder plugins will become available as first-class content objects available through the Course Builder’s drag-and-drop content palette, letting users select one or more content items from a remote library for inclusion in a course offering’s content.
Widget plugins will be usable on an org unit homepage, just as are other system or custom widgets.
Insert Stuff plugins will be registered with the back-end service’s Insert Stuff Framework, letting users fetch content from your service for embedding in user-created content (for example, course content, discussion posts, and so forth).
Quicklink plugins will become available as quicklink objects, just as they would be if you manually created a quicklink to an External Learning Tool.
Navbar plugins will become available as navbar links, just as they would be if you manually created a navbar link to an External Learning Tool by using a quicklink.
Read the Remote Plugins details topic for more information about registering, and implementing, a Remote Plugin.