Как отобразить параметр групп типа массива в LTI1p0

У меня есть потребитель инструментов LTI (LMS), использующий LTI1p0, который отправит запрос службе, которая в настоящее время не использует LTI. Поэтому я пишу реализацию оболочки NodeJS, которая будет

  1. получать от LTI Tool Consumer,
  2. сопоставить его с API службы,
  3. отправить в сервис,
  4. затем проанализируйте ответ службы в формате поставщика инструментов LTI,
  5. и, наконец, отправьте его обратно потребителю инструмента.

У службы есть обязательное поле с именем groups, которое ожидает массив таких групповых объектов:

group: [ {
    id: <string>, // id of the group
    name: <string>, // name of the group
    role: <string> // role of the user
}]

Этот параметр точно не существует в руководстве по внедрению LTI1p0. Поэтому я хочу знать, как лучше всего отправлять информацию типа массива (groups в моем случае) через LTI.

Просматривая документы, я обнаружил несколько потенциальных параметров, которые я мог бы использовать:

1. Параметры контекста

В руководстве упоминается, что «тип контекста будет« группа »», и есть параметры для context_id, context_type, context_title. Проблема будет в том, что это вариант только для одной группы на запрос / пользователя.

2. Пользовательские параметры

Я мог бы создать специальный параметр и назвать его custom_groups, что кажется простым, но я не уверен, как значение должно выглядеть для массивов? Как строковый объект json?

custom_groups = "{"id":123,"name":"Group Name","role":"Instructor"}, {"id":124,"name":"Group Name 2","role":"Creator"}"

Для параметра roles можно отправить список строк, разделенных запятыми (т.е. roles= Instructor, Creator,..), но в моем случае этого было бы недостаточно.

Я все еще новичок в LTI, поэтому приношу свои извинения, если это явно очевидно.

Примечание. И LTI Consumer (LMS), и сервис являются внешними, т. е. я не могу их изменить, а предоставляю только оболочку. Я могу сообщить потребителю инструмента о возможных настраиваемых параметрах, но опять же не знаю, какой формат запрашивать. Кроме того, к концу года служба может реализовать LTI, поэтому в идеале оболочку можно было бы удалить, и потребителю инструментов не пришлось бы сильно менять.

Любая помощь очень ценится!


arrays wrapper lti
person Annemarie Köhler    schedule 06.02.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Примечательно, что группы отсутствуют в спецификации LTI. Так что любой ответ будет частичным мнением.

Я бы согласился с вами, используя поля параметров контекста, с одним запуском LTI на группу. Было бы наиболее правильным способом, если судить по спецификации.

Однако я не видел LMS, которая позволяет запускать LTI из группового контекста. Таким образом, вы не сможете использовать службу без оболочки, даже если она изначально поддерживает LTI.

Альтернативно:

LTI 1.0 Поддерживает пользовательские параметры, поскольку вы расширяете уже отправленную информацию (контекст и роли). Вы можете использовать префикс ext_. Ссылка: https://www.imsglobal.org/specs/ltiv1p0/implementation-guide < / а>

Если профиль хочет расширить эти поля, он должен префикс всех полей, не описанных здесь, с помощью «ext_».

Таким образом, вы можете отправить специальный параметр с этим префиксом. Предположим, ваша LMS позволяет отправлять полезные настраиваемые параметры. LTI предназначен для использования базового запроса POST, а не многомерных объектов Json. Но строковый объект JSON вполне допустим с соответствующим ключом.

i.e:

ext_custom_groups = "{"id":123,"name":"Group Name","role":"Instructor"}, {"id":124,"name":"Group Name 2","role":"Creator"}"
person Kirby    schedule 12.02.2018
comment
Спасибо за ваш ответ! Думаю, я знаю, что вы имеете в виду, но просто чтобы прояснить, почему мы отправляем параметр ext_custom_ вместо самого custom_: мы отправляем расширенный настраиваемый параметр, потому что мы меняем формат с простых строк на строковый объект JSON? Огромное спасибо! :) - person Annemarie Köhler; 12.02.2018
comment
Ничего общего с типом контента. Просто моя интерпретация лексики. Вы расширяете контекст и роли. Которые отправляются со стандартным LTI. так что ext_ будет действительным. Подумав еще немного. custom_ сам по себе был бы менее запутанным и более очевидным, поскольку это не стандартный параметр. Я обновлю свой ответ, чтобы отразить это. - person Kirby; 14.02.2018