Использование API бизнес-сценариев в Microsoft Graph для интеграции с Планировщик (предварительная версия)

Важно!

API версии /beta в Microsoft Graph могут быть изменены. Использование этих API в производственных приложениях не поддерживается. Чтобы определить, доступен ли API в версии 1.0, используйте селектор версий.

API бизнес-сценариев позволяет создавать задачи Планировщик с политиками, управляемыми сценариями, в указанном целевом объекте.

конфигурация Планировщик

Приложения могут настраивать Планировщик сущности двумя способами при использовании API бизнес-сценариев. Ниже перечислены поддерживаемые способы.

  • Конфигурация плана, определяющая элементы планов, созданных для размещения задач сценария
  • Конфигурация задач, управляющая поведением созданных задач для пользователей и приложений

Настройка плана

Конфигурация плана представлена сущностью plannerPlanConfiguration . В конфигурации плана приложение может настроить контейнеры, которые отображаются в плане, порядок этих контейнеров, а также название плана и имя контейнеров. Каждый контейнер определяется внешним идентификатором, который можно использовать при создании или обновлении задач, чтобы поместить их в правильный контейнер. Контейнеры, настроенные в конфигурации плана, не указывают имена для использования, вместо этого эти сведения являются частью локализованных имен. Конфигурация плана также указывает локализованные имена для плана и контейнеров, а также код языка по умолчанию. В настоящее время созданные элементы используют язык по умолчанию.

Конфигурация задачи

Конфигурация задачи представлена сущностью plannerTaskConfiguration . В конфигурации задач приложение может настроить политики, ограничивающие доступ к приложениям и пользователям, которые используют задачи, управляемые сценарием. Политики группируются по ролям. Каждая роль идентифицирует группу вызывающих, и для каждой группы могут быть указаны разные правила. Правила, применяемые к конкретному вызову, выбираются в следующем порядке. Когда запрос изменяет задачу, применяются только первые указанные правила.

  • taskAssignees: применяется, если целевая задача назначена пользователю, который выполняет вызов.
  • groupOwners: применяется, если пользователь, который выполняет вызов, является владельцем контейнера, в который входит план целевой задачи.
  • groupMembers: применяется, если пользователь, который выполняет вызов, является членом контейнера, в который входит план задачи.
  • applications: применяется, если вызывающий объект имеет разрешения приложения, поэтому вызов не связан с пользователем.
  • defaultRules: применяется, если ни одно из других условий не соответствует.

Примечание: Эти правила ограничивают возможности вызывающей стороны, но они не могут разрешить вызывающей организации выполнять операции, которые в противном случае не были бы разрешены.

Каждая роль задает правило по умолчанию и правила для определенных действий и полей в задаче. Правилом по умолчанию должно быть или allowblock. Если для действия или поля не определено правило, правило по умолчанию используется для сохранения его неограниченного allowили заблокированного использования для block. Имейте в виду, что это применимо, когда доступны новые свойства и действия, которые можно настроить, но конфигурация сценария еще не обновлена, чтобы указать правила для них.

Дополнительные сведения об использовании правил см. в разделе Настройка правил задач в Планировщик.

Назначение задач

Созданные задачи помещаются в планы на основе указанного целевого объекта при их создании. В текущей версии группа может быть целевой. Задача помещается в план , связанный со сценарием в этой группе. Если у группы нет плана для сценария, создается новый план на основе конфигурации плана.

Метаданные и поведение задачи

В рамках задач требуются свойства сценария . Эти свойства включают внешний идентификатор задачи, который необходимо указать для каждой задачи. Это значение должно быть уникальным в клиенте. Если создать вторую задачу с тем же внешним идентификатором, первая задача будет возвращена без каких-либо изменений. Внешний идентификатор также можно использовать в качестве альтернативного ключа при работе с задачами. Кроме того, можно указать идентификатор контекста для каждой задачи. Это значение можно использовать для запроса задач с одинаковым идентификатором контекста, что позволяет приложениям группировать задачи по планам.