Importing CC v1.1 content with BLTI

[David Lippman]

Hi,

I am the lead developer for IMathAS (www.imathas.com), which is a
BasicLTI v1.1 compliant tool (provider), and a CC v1.1 compliant write
tool.

Basically, a course on my system includes a bunch of non-QTI
assessments, which I want to be able to bulk-load into Canvas as BLTI
placements using CC v1.1.

All of my BLTI items in the cartridge use the same launch URL, and use
a custom property to specify the assessment on my platform the
placement should load.

When I try importing this into Canvas, Canvas creates a separate
external tool for each of these placements, even if I have previously
set up an external tool with a "Match By: URL" option.

Am I doing some wrong, or is there some way I can adjust my output to
work better with Canvas? If it would help, you can download a copy of
an example CC export at http://www.myopenmath.com/course/files/CCEXPORT44.imscc

Thanks
David Lippman

[Brian Whitmer]

David,

I think you're going to run into problems if all of the tools have the same URL but different custom fields. In Canvas, custom fields are stored on the tool configuration, not the link configuration, so yes, it makes sense that Canvas is creating multiple tools since each of your links has different custom fields. 

The problem you're going to hit is if all your URLs are identical, then since LTI matches by URL, the system doesn't know which tool configuration to pick for each link, and all links will get sent with the same custom fields. 

As an example:

Tool 1:

  name: Quiz 1

  url: http://example.com

  custom fields: assessment=1

Tool 2:

  name: Quiz 2

  url: http://example.com

  custom fields: assessment=2

If I insert two links, one for Quiz 1 and one for Quiz 2, there's going to be a problem. LTI specifies that tool retrieval should happen at tool launch time, so when you click either link, Canvas is going to search for the first tool it can find that matches the URL specified (http://example.com). So both links will use Tool 1 configuration, and both links will launch Quiz 1.

This is a problem with the LTI specification, and I don't believe will be unique to Canvas. Correct me if I'm wrong.

An alternative approach would be as follows:

Tool 1:

  name: Quiz 1

  url: http://example.com?custom_assessment=1

  custom fields: none

Tool 2

  name: Quiz 2

  url: http://example.com?custom_assessment=2

  custom fields: none

This would then allow you to create links to Quiz 1 and Quiz 2 without any conflict.

Or you could configure one tool that matched on the domain instead of URL:

Tool 1:

  name: Quiz Links

  domain: example.com

And then have the user insert links to http://example.com?custom_assessment=1 and http://example.com?custom_assessment=2.

As far as properly crafting your CC package, it might be easiest to build up a course in Canvas that's configured how you like, exporting that to CC, and seeing what it looks like. If there are discrepancies between what you see and what you think you should see please let us know.

Thanks,

-Brian

[David Lippman]

Interesting. I had interpreted the specs as implying that the custom
fields should be link-level, not tool-level.

The Use Case for CC placements says "When a TC User launches an LTI
link imported from the Common Cartridge, the TC signs the launch
request using the pre-configured credentials associated with the TP
address."

However, the custom fields are specified for each individual link,
which implies they are not part of the domain credentials.
Additionally, the specs given an example of "For example if the link
were a section in an eTextbook, there might be a setting like:
<parameter key="section">1.2.7</parameter>" which suggests to me that
the custom fields were intended to be for link-specific purposes.

Perhaps not. Sadly, the specs are not that specific :)

Thanks for the suggestions. I'll play around with Domain matching
tomorrow and see if I can get something to work better that way.

-David

> And then have the user insert links tohttp://example.com?custom_assessment=1andhttp://example.com?custom_assessment=2.

[Dr. Chuck]

Brian,

While the spec is not explicit in this area, the simple fact that each
LTI placement in a CC 1.1 cartridge has its own custom parameters and
you can have many links in a cartridge naturally implies that each
link can have its own distinct custom parameters. In the LTI 1.0
specification, the notion of how custom parameters work was left vague
when it comes to authoring links (i.e not as part of an import).

Folks reading the LTI 1.0 spec some implementations made it so that
(a) the single tool shared configuration was the only place that
custom parameters be set and other implementations made it so (b) that
custom parameters could only be set on the individual resource link.
The more common approach was (a) which sounds like the approach you
took in Canvas.

This worked well until you think of the export/import cartridge use
case where tools like an assessment engine want to store a setting
like "which assessment" in a custom field. Pearson, McGraw-Hill and
lots of folks want to do this where they want many resource links in a
cartridge and have those links point to different resources *without*
adding a parameter to the URL (which is not recommended) - which would
mess up much more than adding a custom parameter. Of course some of
my presentations (i.e. using resource_link_id configuration) talk
about the way a tool can work around the lack of per-resouce custom
parameters parameter support in an LMS. This work-around is
sufficient for initial link authoring in an LMS where the course is
being built - but fails across export/import as resource_link_ids are
not carried in the CC.

So this meant that LMS's could not be used to author proper cartridges
unless they allowed per-link custom parameters so these could persist
across an export / import path. Yikes! We figured that many who
wanted to make cartridges would simply use an LMS to do it while
waiting for a specific authoring tool or process.

So in LTI 1.1, we made it more explicit in section B.7 with the
following new text:

B.7.1 Instructor Creates New Tools
In the case that the TC decides to allow the instructor to place tools
without administrator action by getting a URL, key, and secret from a
TP and plugging them into a course structure, it is a good practice to
allow the instructor to enter custom parameters without requiring
administrator assistance. Some TPs will need custom parameters to
function properly. Also if the instructor is using a TC to produce an
IMS Common Cartridge with LTI links in the cartridge, often setting
custom parameters for a tool placement is an essential part of
authoring a cartridge.

B.7.2 Admin Creates New Tools, Instructor Only Places Tools
Another common case is to only allow the administrator to create new
tools (i.e., key/secret/url) and then let the instructor place those
pre-configured tools in their courses. In this use case, instructors
never handle url/key/secret values. Even in this use case it is
important to allow the instructor to be able to set or augment custom
parameters for each placement. These parameters may be necessary for
the TP to function and/or may be necessary if the instructor is
building a course in the TC to be exported into an IMS Common
Cartridge. It is not necessary to always give the instructor the
option to configure custom parameters, but it should be possible for
the administrator to make a choice to reveal a user interface to set
custom parameters.

You can also read B.7.2 as to applying to a situation where an
instructor makes their own tool configuration to share across multiple
resource links. The best practice is to have both the shared config
and the resource-link contribute to the custom parameters.

You merge the custom parameters at launch if they exist both places -
I think that my code for this treats the shared / admin as having
higher precedence. You would naturally take the same merge approach
when exporting to a CC 1.1 - since the CC 1.1 has no concept of a
shared link - it only knows about the resource link - you have to pull
in the inherited parameters on export or data will be lost.

Now lets talk about LTI 2.0 that does not exist yet and how it treats
this in the draft versions so far. LTI 2.0's view of a cartridge
explicitly models two separate items. The first is a tool
configuration with url, vendor, etc. The tool configuration registers
itself mime-type style resource-handler as a "pearson-mymathlab-quiz"
indicating that once this tool is installed it handles resources that
are of tyoe "pearson-mymathlab-quiz. The second is a resource-link
that is the actual link in the course structure that includes title,
custom parameters, and needs a resource handler of type "pearson-
mymathlab-quiz".

If you look at the LTI 1.0 / CC 1.1 data model for simplification, we
condensed these into a single structure. Simplification makes things
easier sometimes and harder other times.

LTI 2.0 will add two new resource types to a future CC version,
keeping the basiclti all-in-one resource type. But my guess is that
once the LTI 2.0 CC support marke it into the field, folks will
quickly switch as it is *much* prettier. One of the major advantages
of the LTI 2.0 approach (at the cost of more UI and workflow
complexity) is that since the resource handler idea is a bit of an
abstraction between resource links and tool configurations, it allows
LMS builders and LMS admins to re-map those resource handlers to solve
use cases like living behind a firewall or having a local copy of
Pearson MyMathLab in South Africa.

The 2.0 specs are pretty mature but it always takes a while for
adoption so we need to focus on and deal with the current CC and LTI
1.1 and get it right so it works well while we finish up LTI 2.0 and
its associated CC release and get it out and into the marketplace.

Hope this helps.

[David Lippman]

Thanks for the clarification, Chuck.

Also, Brian, I tried your idea and set up an External Tool in Canvas
with Match By: Domain, and then importing in a modified cartridge that
removed the custom fields and used query-strings instead. Canvas did
not match them, and instead imported each LTI item in the CC as a
separate external tool as it did before.

David

[Brian Whitmer]

David, sorry I wasn't clear. Adding a domain-matching tool wouldn't have any effect on the CC import process. I'm less familiar with our CC import process than I am with our LTI code, but I do know that tools and tool links are in separate models, that is probably reflected in the CC format somehow. I'd probably suggest building what you want by hand inside of a Canvas course, exporting the course as CC, and seeing what the difference is between that package and the one you're trying to import.

Chuck, since you chimed in :-).

I talked to Bracken and he finally convinced me that custom parameters on links *and* tools is an ok thing. I don't mean to be slow, it just takes me a while sometimes. My worry is the usability side of things. The reason I tend to push people to use query parameters on a URL is that at least in that case the user only has to copy and paste on "weird" value instead of two (a URL and custom parameters) when inserting a link. 

My ideal preference would be that the instructor wouldn't have to do any copy and pasting at all. That's what I'm shooting for with the "Link Selection" extension you can see in our API docs https://canvas.instructure.com/doc/api/link_selection_tools.html. The admin sets up the tool, the teacher gets a nice dialog where they pick their resource, and the values are automatically inserted. We can add custom parameters to that sort of workflow without causing the link creator any additional burden.

Also the mime-type idea is interesting. Have you looked at all at Google's Web Intents project? This is the first I've heard of LTI 2.0..

-Brian

[David Lippman]

Brian,

My tool is designed so that if a placement is made without custom
parameters, my tool will guide the instructor through selecting what
assessment should be associated with that placement (what Chuck called
resource_link_id configuration). This works great for an instructor
trying to set up their own content links.

Unfortunately, while I can use the same Tool in Canvas several times
to create multiple placements linked to different assessments, those
connections are based on the resource_link_id which, as Chuck
mentioned, is not included in a CC export, so all those links between
placements in Canvas and assessments on my system will not persist
across export/import.

Just the same, I tried making two placements in Canvas with the same
tool and exporting it. Only one LTI xml file was created, and neither
item in the organization section referenced it, which was odd. In the
module view, only one of the placements made with the tool showed up
after import, so one of them completely got lost in the export/import
process. As I suspected, the link between the placement and an
assessment on my system was lost in the process as well.

Your link selection extension seems like an interesting idea for
building courses that can be exported, though as discussed it might
make more sense to be setting a custom parameter rather than a
different URL.

David

On Jan 13, 12:28 pm, Brian Whitmer <br...@instructure.com> wrote:
> David, sorry I wasn't clear. Adding a domain-matching tool wouldn't have
> any effect on the CC import process. I'm less familiar with our CC import
> process than I am with our LTI code, but I do know that tools and tool
> links are in separate models, that is probably reflected in the CC format
> somehow. I'd probably suggest building what you want by hand inside of a
> Canvas course, exporting the course as CC, and seeing what the difference
> is between that package and the one you're trying to import.
>
> Chuck, since you chimed in :-).
>
> I talked to Bracken and he finally convinced me that custom parameters on
> links *and* tools is an ok thing. I don't mean to be slow, it just takes me
> a while sometimes. My worry is the usability side of things. The reason I
> tend to push people to use query parameters on a URL is that at least in
> that case the user only has to copy and paste on "weird" value instead of
> two (a URL and custom parameters) when inserting a link.
>
> My ideal preference would be that the instructor wouldn't have to do any
> copy and pasting at all. That's what I'm shooting for with the "Link

> Selection" extension you can see in our API docshttps://canvas.instructure.com/doc/api/link_selection_tools.html. The admin

[Brian Whitmer]

The fact that there was only one lti xml doesn't surprise me, since you only had one tool configured. The connection between links and tools is very loose, so it also makes sense that the items wouldn't reference the specific tool. I'm not sure why there was only one item added instead of two, though. Can you send a copy of the export package?

I agree custom parameters would be a nice thing to add to the link selection extension. We'll have to change our model a bit because, like I said before, we're not currently built to have custom parameters tied to the link placement, only to the tool itself. But that makes sense to add.

-Brian

[ed.eu...@gmail.com]

Hello,

I'm building an assignment engine prototype that integrates with the Canvas LMS via a basic LTI Launch link. 

Similar to Brian, I'd like a single url that points to my assignment launcher, but the external tool is configurable for each assignment to point to a different item that I'll provide.

Brian, I'm wondering what you did to get your application to work with Canvas. 

From what I can see at the moment I'll need a unique url for each item which will create an external tool for each url.

Best,

Ed

[Denis Lantsman]

I am trying to configure my app as a Tool Provider, and am having the same issue. My app provides a collection of interactive activities for math. I am working with a publisher that will author canvas courses and redistribute to school districts via canvas export.

- I want to provide my publisher with a single set of credentials.

- I want the publisher to be able to place links to particular activities while authoring their course.

- The publisher will then export their course and share it with districts

- When the district imports the canvas course, I want them to enter my credentials once, and for the activities to be linked accordingly.

My initial thought was to specify the custom activity via a custom_parameter, but I quickly ran into the issues described here:

- since custom parameters are done at the App (LTI link) level, I need to create a separate app for each parameter value, so:

App1: /lti/launch, custom_activity=a
App2: /lti/launch, custom_activity=b

etc...

This means that both the publisher, and every district, will need to re-enter the consumer key and secret for each such activity.

Also, based on the conversation in this thread, I'm worried that it still won't work - because the launch url's are the same, and so I fear my custom parameters will get mangled by canvas during import/export.

I'm curious what the recommended way to approach this issue with LTI is...

One thought I had was to try and do this via the Content Item extension. I'd configure a single App with Content Item. During the conentitem request, I'd return a list of preconfigured launch urls, perhaps encoding the parameter by appending it to the url:
[

  /lti/launch?param=a

  /lti/launch?param=b

]

The publisher would author using this interface, and hopefully after export/import, the district would only need to enter the single app credential, and have the relationships between links and params persist.

I am going to try this approach, but would appreciate any input about what the best way to approach this is (now that 5 years have passed)