Триггер запускает рабочий процесс при возникновении в подсоединенной системе события подписки. Это позволяет автоматизировать сложные бизнес-процессы, чтобы не выполнять каждый раз рабочий процесс вручную.
Например, на следующем рисунке отображается список триггеров, которые могут быть созданы из проекта.
Периодически проверяют наличие обновлений с постоянными интервалами. Все триггеры опроса отмечаются значком часов в списке триггеров. Чтобы создать триггеры опроса, выполните следующее:
1. В командной строке выполните следующие команды:
a. cd <user project root directory>
b. flow add trigger -p
Для команды добавления триггера доступны следующие опции.
Опции | Описание | Тип данных |
---|
--version | Отображает номер версии. | [boolean] |
--help | Отображает справку. | [boolean] |
--parentDir,-d | Родительский каталог для проекта. | [по умолчанию: "."] |
--polling,-p | Показывает, что это триггер опроса. | [по умолчанию: false] |
-- artifactVersion,-v | Версия артефакта, который будет создан. | [по умолчанию: v1] |
2. При выполнении команды добавления триггера создается файл метаданных trigger.json, содержащий входные и выходные данные, и JavaScript-файл index.js, содержащий логику кода. Эти файлы создаются в папке <projectDir>\trigger\poll\<имя_триггера>\v1
| По умолчанию создается триггер веб-перехватчика. Чтобы создать триггер опроса, используйте опцию -p. |
Дополнительные сведения о форматировании схемы ввода и вывода см. в заметке в разделе
Создание действий. Ниже приведена усеченная и упрощенная схема.
Опции в файле trigger.json описаны в следующей таблице:
Файл trigger.json
Опции | Описание |
---|
type (требуется) | Внешний объект должен иметь тип "объект JSON". |
title (требуется) | Метка списка для разрешения выбора триггера. |
description | Краткое описание триггера. |
properties | Используется, чтобы определить поля входной формы для конфигурации триггера. Содержит следующие определения: • Поля входных данных, которые будут отображаться в окне конфигурации триггера. • Наименование события, появляющегося в списке сервисов триггера. |
Определение триггера начинается с набора общих свойств, таких как authentication и customFilters, и любых других свойств, которые являются общими для всех событий триггера. У всех свойств имеются свойства type, title и description. Внешние системы обычно представляют набор событий, и события должны быть представлены в блоке oneOf. Каждый объект в oneOf соответствует единственному событию. Если в системе представлено одно событие, блок oneOf не нужен.
Массив oneOf содержит одно или несколько событий. Каждое событие представляет собой объект JSON. В приведенном ниже примере рассматривается сервис, содержащий 2 события: Событие 1 и Событие 2. Заметьте, что для каждого события может потребоваться различное число и различные типы ввода.
[{
"type": "object",
"title": "Event1",
"description": "Event 1 description",
"properties": {
"event": {
"type": "string",
"title": "Trigger",
"enum": [
"Event1"
],
"propertyOrder": 2,
"options": {
"hidden": true
}
},
"input_for_event1": {
"title": "input for event 1 ",
"minLength": 1,
"type": "string",
"propertyOrder": 3,
"description": "input required by event 1"
}
}
},
{
"type": "object",
"title": "Event2",
"description": "Event 2 description",
"properties": {
"event": {
"type": "string",
"title": "Trigger",
"enum": [
"Event1"
],
"propertyOrder": 4,
"options": {
"hidden": true
}
},
"input_for_event2": {
"title": "input for event 2 ",
"minLength": 1,
"type": "string",
"propertyOrder": 5,
"description": "input required by event 2"
}
}
}
]
Для каждого из этих событий должна существовать соответствующая схема вывода в выходном свойстве. Например, если имеется 2 события, как показано выше, вывод должен содержать следующие схемы для События 1 и События 2:
"output": {
"Event1": {
"type": "object",
"properties": {
"opfield1": {
"type": "string",
"title": "Output field 1"
},
"opfield2": {
"type": "string",
"title": "Output field 2"
}
}
},
"Event2": {
"type": "object",
"properties": {
"opfield3": {
"type": "string",
"title": "Output field 3"
},
"opfield4": {
"type": "string",
"title": "Output field 4"
}
}
}
}
Файл index.js для триггеров опроса имеет следующую структуру:
module.exports = Trigger
Trigger.execute = function (input, options, output) {
}
Trigger.validate = function (input, options, output) {
}
Trigger.activate = (input, options, output) {
}
Код для метода validate подобен методу execute. См. код в примере.
Ниже перечислены методы, используемые в триггерах опроса:
• Метод execute - вызывается периодически. Интервал является конфигурацией сервера ThingWorx Flow. Метод execute использует информацию о соединении из входных данных, а затем выполняет соединение с внешней системой и вызывает данные с сервера ThingWorx Flow. В нем могут использоваться интерфейсы API объекта option для кэширования информации о вызванных объектах, чтобы определить, доступны ли новые сведения.
Объект options имеет свойство meta, которое используется, чтобы сохранять информацию, доступную в разных вызовах метода execute.
Метод setMeta объекта опций может использоваться для сохранения информации о текущем или предыдущем выполнении в базе данных. Например, его можно использовать для сохранения времени последнего выполнения метода. Также его можно использовать, чтобы хранить информацию для расчета дельты между предыдущим и текущим результатами. Параметр output представляет обратный вызов, который следует соглашению "сначала ошибка узла". Если возникает ошибка, она должна возвращаться как первый параметр; в противном случае первый параметр должен иметь значение null, а результат, который соответствует схеме вывода, возвращается как второй параметр.
• Метод validate - вызывается сервером ThingWorx Flow перед сохранением триггера в базе данных. При сбое проверки триггер не сохраняется. Этот метод можно использовать для проверки ввода данных, таких как соединение с сервисом.
• Метод activate - вызывается, когда существующий триггер связан с другим рабочим процессом. В большинстве случаев достаточно просто выполнить проверку с его помощью. См. следующий пример реализации метода activate:
function activate(input, options, output){
return output(null,true)
}
Чтобы получить доступ к выбранному событию триггера, используйте свойство "событие" объекта ввода (input.event). Объект документа содержит поля ввода из формы. Поле ввода содержит обычные свойства, такие как соединение и access_token, а также любые другие поля из формы ввода. Например, чтобы получить доступ к свойству user_name, являющемуся частью объекта соединения, используйте такое выражение, как document.input.connection.user_name
Это триггеры, основанные на подписке. Подписки создаются на события в присоединенной системе, и URL-адрес веб-перехватчика вызывается с информацией о событии, когда событие возникает в присоединенной системе. Для работы триггера этого типа присоединенная система должна поддерживать веб-перехватчики. При этом данные отправляются в обработчик ThingWorx Flow в реальном времени, что позволяет процессу выполняться, как только указанное событие возникает во внешнем приложении или сервисе.
Триггеры веб-перехватчика можно создавать с помощью следующей команды:
flow add trigger
При выполнении данной команды создаются следующие объекты.
• Файл метаданных trigger.json - содержит входные и выходные параметры.
• Файл JavaScript index.js - содержит логику кода.
Эти файлы создаются в папке <projectDir>\trigger\webhook\<имя_триггера>\v1 Процесс завершения файла trigger.json для триггера веб-перехватчика подобен процессу для триггера опроса. Однако код существенно отличается.
Файл index.js для триггеров веб-перехватчика имеет следующую структуру:
module.exports = Trigger;
Trigger.execute = function execute(input, data, output) {
}
Trigger.activate = function execute(input, data, output) {
}
Trigger.register = function register(document, callback) {
}
Trigger.unregister = function unregister(document, callback) {
}
Ниже перечислены методы, используемые в триггерах веб-перехватчика:
• Метод activate - может иметь простую неоперационную реализацию следующего вида:
function activate(input, options, output) {
return output(null, true);
}
• Метод register - используется, чтобы регистрировать URL веб-перехватчика, предоставленный сервером ThingWorx Flow с внешним сервисом. Метод register - принимает объект документа, который имеет свойство, содержащее URL веб-перехватчика. Объект документа имеет следующие свойства.
◦ webhook_name - имя объекта веб-перехватчика.
◦ webhook - URL-адрес веб-перехватчика.
◦ input - объект входных данных, который содержит другие свойства, такие как connection, access_token и любые другие поля из формы ввода триггера.
Вывод метода сохраняется в объекте документа как свойство hook_response. Это свойство hook_response во многих случаях содержит ИД триггера, передаваемого целевой системой. Обычно этот идентификатор отправляется обратно в целевую систему, если предпринимается попытка отменить регистрацию веб-перехватчика.
• Метод unregister - отправляет запрос на отмену регистрации, который удаляет подписку на веб-перехватчик, созданную при выполнении вызова регистратора в системах, с которыми устанавливалось соединение. Используйте document.hook_response и его свойства, чтобы получить информацию, которая может использоваться для отмены регистрации.
После завершения записи кода для триггера можно перейти к созданию аутентификации для триггера.
• Метод execute - используется следующим образом:
◦ Чтобы преобразовать данные сервиса из формы в форму, которая подходит для использования в рабочих процессах, или в форму, которая соответствует определенной схеме вывода.
◦ Иногда предоставляемой сервисом информации недостаточно. В таких случаях можно запросить сервис для получения дополнительной информации.
Дополнительные сведения и примеры для триггеров см. в разделе
Приложение B: учебник по SDK соединителя ThingWorx Flow.