Что такое триггеры?
. (Info) (Примечание) Эта тема рассматривается в курсе»Основы дизайна и логики приложений» в Tulip University.
В этой статье вы узнаете:
- Какие действия могут выполнять триггеры.
- Какие типы триггеров существуют и как их использовать.
- Общие примеры использования триггеров
Когда оператор нажимает кнопку, запущенную в приложении в цеху, вы, вероятно, захотите определить некоторую пользовательскую логику.
Триггеры позволяют добавить логику в приложение. С помощью триггеров можно взаимодействовать с устройствами, отправлять оповещения, связываться с внутренними системами и т.д. — и все это без написания единой строки кода!
Триггеры также позволяют обновлять переменные, которые являются инструментом для отслеживания данных в приложении. Прежде чем приступить к работе с этой статьей, необходимо разобраться с переменными.
Типы команд триггера
В триггере можно использовать два типа команд
- Действие: Изменение в приложении, не связанное с изменением шагов
- Переход: Изменение шагов или завершение работы приложения в проигрывателе.
Вот как это выглядит:
«Переходы» — это события, которые могут позволить сработать другим триггерам. Например, можно создать триггер, который срабатывает каждый раз, когда приложение завершается.
Типы триггеров
Существует три типа триггеров, которые можно использовать в обычном шаге:
Кнопочные триггеры
Кнопочные триггеры активизируются при нажатии кнопки. На шаге может быть несколько кнопочных триггеров, которые срабатывают при нажатии соответствующей кнопки оператором в Tulip Player.
Доступ к ним можно получить в меню виджета в контекстной панели после выбора кнопки.
Триггеры уровня шага
Триггеры уровня шага активизируются такими событиями:
- Через регулярные временные интервалы («временные пожары»)
- При поступлении входного сигнала от машины или устройства («Машины и устройства»)
- При открытии шага («Когда шаг открыт»)
- Когда шаг закрывается («Когда шаг закрыт»).
Доступ к ним осуществляется через вкладку Step в контекстной панели.
Более подробная информация о триггерах уровня шага доступна здесь
Триггеры уровня приложений
«Триггеры на уровне приложений активируются такими событиями:
- Запуск приложения
- Завершение работы приложения
- Приложение отменено
Они могут быть изменены на вкладке App контекстной панели:
Все эти триггеры могут быть активированы автоматически на любом шаге.
Например, если на трех разных шагах имеется кнопка «Завершить», триггер «Приложение завершено» может сработать на любом из этих шагов.
Примеры использования триггеров
Примерами распространенных действий, которые можно выполнить с помощью триггеров, являются:
Навигация внутри приложения: Используйте триггеры для перехода к следующему или предыдущему шагу. Или перейдите к конкретному шагу, например, к шагу «Обращение за помощью».
Завершение работы приложения: регистрация данных, полученных в результате выполнения приложения.
Вызов функции коннектора для доступа к внутренней системе: Коннекторы позволяют Tulip взаимодействовать со сторонними системами. Эти коннекторы можно вызывать из триггеров. Это позволяет передавать или извлекать данные из Tulip во внутреннюю систему с помощью переменных.
Отправка оповещений: С помощью триггеров можно также отправлять электронные письма или SMS-сообщения соответствующему администратору. Эти сообщения могут содержать изображения, информацию о состоянии процесса и другую необходимую информацию.
Хранение данных: Если вы хотите хранить данные в Tulip, вы можете использовать:
- Переменные: Данные, которые относятся только к одному приложению.
- Таблицы: Таблицы для хранения данных, которые будут использоваться в нескольких приложениях.
Для этого в операторе «Then» используется команда «Data Manipulation», «Store».
Создание триггеров
Триггеры работают по логической структуре «когда», «тогда»:
- когда «событие зарегистрировано в Tulip»
- , то «выполнить действие» или «сделать переход».
Несколько более сложным вариантом такой логики являются триггеры с условием:
- когда «событие зарегистрировано в Tulip»
- если «условие выполнено»
- то «выполнить действие»
- иначе «выполнить другое действие».
Если вам необходимо использовать операторы «if/else», ознакомьтесь с этим руководством по триггерам с условиями.
События, которые приводят к выполнению действий, могут быть простыми, например, нажатие кнопки, которое заставляет приложение перейти к следующему шагу.
Или же это могут быть более сложные действия, например, сканирование штрих-кода, которое запрашивает внутреннюю базу данных и возвращает информацию о заказе в виде переменной.
- «Устройство» «Сканер штрих-кода» выходит на «этой станции»
- «Запустить функцию коннектора» коннектор: «Пример базы данных» «Order Lookup Multiline» штрихкод: «Device Output» «data» и сохранить результат как: «Переменная» «Сведения о заказе»
- «Go To Step» «Next»
Вот более подробная информация об операторе «Then»:
Этот триггер использует сканер штрих-кодов для:
- Получить данные о заказе из внешней системы,
- сохранения значения в качестве переменной
- автоматического перехода к следующему шагу.
Дальнейшее чтение
Список всех возможных действий и переходов триггера приведен в этом отдельном руководстве
Список 10 наиболее распространенных триггеров, которые мы видим у клиентов, создающих Tulip, приведен в этой статье: » 10 наиболее распространенных триггеров в Tulip».
Вы нашли то, что искали?
Вы также можете зайти на community.tulip.co, чтобы задать свой вопрос или узнать, сталкивались ли другие с подобным вопросом!
Почему вызов триггеров осуществляется автоматически
Триггеры являются наиболее эффективным инструментом сохранения целостности баз данных, так как позволяют подробно проанализировать события, происходящие в системе. Все триггеры можно разделить на два класса: триггеры DML – перехват команд insert , update , delete и триггеры DDL – перехват команд DDL . В свою очередь триггеры DML делятся на триггеры After – выполняющиеся после выполнения команды и триггеры Instead of – триггеры выполняются вместо соответствующих команд SQL .
Триггеры DML
Структура и создание
Формат команды создания триггера следующий
create trigger [ schema_name . ] trigger_name
[ not for replication ]
■ [ schema _name . ] trigger_name – имя создаваемого триггера . Должно удовлетворять требованиям, предъявляемым к идентификаторам. Имя триггера не может начинаться с символа ‘ #’ , поскольку триггер не может быть временным объектом.
■ on < table | view >– опция указывает к какой таблице или представлению (имя таблицы или представления) триггер будет относиться. Только триггеры типа instead of могут создаваться для представлений.
■ for | after | instead of – определяется тип триггера. Опции и for и after являются синонимами.
■ [ delete ] [ , ] [ insert ] [ , ] [ update ] — указываются команды DML , на которые будет реагировать данный триггер. Следует указать, по крайней мере, одну команду.
■ with append — данная опция устарела и используется для совместимости.
■ not for replication – опция показывает, что триггер не будет срабатывать, когда во время репликации будут происходить изменения в таблице.
■ sql _ statement [ ; ] [ . n ] – последовательность команд языка Transact SQL , которые будут выполняться, при запуске триггера.
■ external name < method specifier >– опция используется при создании триггера на основе технологии . NET .
Структура команды alter trigger несколько отличается от структуры команды, которую мы только что разобрали, но все опции в ней те же самые. Вот эта команда .
alter trigger schema_name.trigger_name
on ( table | view )
( for | after | instead of )
[ not for replication ]
Удаление триггера DDL осуществляется командой drop trigger schema_name.trigger_name [ . n ] . Т.е. одной командой можно удалить сразу несколько триггеров.
Триггеры after выполняются после успешного выполнения команд, вызвавших его. Если команда, по каким либо причинам не выполняется, то не выполняется и триггер. И команда и триггер выполняется в одной транзакции. Поэтому откат при выполнении триггера приведет и к откату команды, вызвавшей его. Триггеры after могут быть определены только для таблиц и не могут быть для представлений. Для таблицы можно определить несколько after -триггеров.
Триггеры instead of выполняются вместо операций DML и по одному для каждой операции. Эти триггеры могут создаваться и для представлений.
В триггерах after используются специальный инструментарий для определения того, что произошло с таблицей (чем вызван запуск триггера). Функция update ( column ) определяет, был или не был модифицирован данный столбец. Относиться к командам update и insert . Если столбец был модифицирован, то функция возвращает TRUE . Функция columns _ updated () позволяет определить, какой столбец был изменении. Функция возвращает двоичное число, каждый бит которого относиться к конкретному столбцу. Если бит равен 1 то это значит, что столбец был изменен командой update или insert .
Перед выполнением для триггера автоматически создаются две временные таблицы: inserted и deleted . Их содержимое зависит от того, какая операция была выполнена:
■ При выполнении команды insert таблица inserted будет содержать новые строки. Таблица deleted будет пуста.
■ При выполнении команды delete таблица deleted будет содержать удаляемые строки, таблица inserted будет пустой.
■ При выполнении команды update таблица deleted будет содержать старые значения строк, таблица inserted – новые.
В случае триггера instead of таблицы deleted и inserted будут содержать строки, которые соответственно должны быть удалены или должны быть вставлены.
Во временные таблицы ( deleted и inserted ) нельзя вносить какие-либо изменения. Но из триггера можно менять содержимое любых других таблиц. Из триггера нельзя выполнять следующие команды языка Transact SQL : reconfigure , create database , alter database , drop database , restore database , restore log , load database , load log .
На время выполнения триггера происходит блокирование данных, с которыми он работает, так что из других процедур нельзя к ним обратиться. Поэтому триггер должен планироваться таким образом, чтобы его выполнение не занимало слишком много времени.
Если триггер обращается к таблице, которая защищена другим триггером, то возникает ситуация вложенности. Всего по умолчанию возможно до 32 вложений, как для хранимых процедур и пользовательских функций. Если уровень вложенности превосходит допустимый, то возникает ошибка. Вложенные триггеры можно отключить, если использовать системную хранимую процедуру sp _ configure . Возможен и рекурсивный вызов триггера при обращении триггера к той же таблице. По умолчанию рекурсивный вызов триггеров отключен. Так же как и вложенные триггеры, рекурсивные триггеры лучше не использовать.
Как уже было сказано, для одной таблицы можно создать несколько триггеров, причем настроить на одну операцию. Для того чтобы внести порядок в выполнение таких триггеров можно использовать хранимую процедуру sp _ settriggerorder , имеющую следующую структуру вызова.
sp_settriggerorder [@ triggername = ] ‘ triggername ‘
■ [@ triggername = ] ‘ triggername ‘ – определяет имя триггера, которое может содержаться и в переменной.
■ [@ order = ] ‘ value ‘ – порядок следования триггера. Который может быть:
o first – выполняется первый.
o last – выполняется второй.
o none – порядок не определен.
■ [@ stmttype = ] ‘ statement_type ‘ – тип инструкции .
Таким образом, очевидно, что можно определить только первый и последний триггер. Т.е. порядок может быть определен при наличии максимум трех триггеров.
Наконец триггер не возвращать никаких наборов строк. Эта возможность считается устаревшей и будет удалена в будущих версиях SQL Server .
Примеры триггеров
В Листинге 3.83 представлен простой триггер after , который запрещает обновлять значение столбца t1 для таблицы table1 . При этом в вызывающий модуль с помощью функции raiserror будет возвращено сообщение о причине отказа. Поскольку триггер расположен в одной транзакции с командой, которая вызвала данный триггер, то команда rollback transaction возвращает состояние таблицы в исходное положение.
Листинг 3.83
create trigger no_update on table1
raiserror (‘ Обновлять нельзя ‘, 15,1)
Рассмотрим еще один пример (см. Листинг 3.84 ).
Листинг 3.84
create trigger dt_del on dbo.students
instead of delete
— удалить из таблицы marks
delete from dbo.marks
where id_student in (select id from deleted)
raiserror(‘ Ошибка удаления из таблицы marks’,16,3)
— удалить из таблицы students
delete from dbo.students
where id in (select id from deleted)
raiserror(‘ Ошибка удаления из таблицы students’,16,3)
Триггер из Листинга 3.84 срабатывает на попытку удаления из таблицы dbo . students . Триггер в начале удаляет строки из связанной таблицы dbo . marks , а затем уже из таблицы dbo . students (каскадное удаление). При этом в триггере обрабатываются и возможные ошибки с откатом тразнакции и возвращаением в приложение сообщения об ошибке.
Триггеры DDL
Триггеры DDL запускаются в ответ на команды DDL .
Вот формат команды создания триггера DDL
■ on < all server | database >– данная опция показывает, будет ли триггер действовать в пределах текущей базы данных или в пределах всего сервера SQL .
■ < ddl _ trigger _ option >— данная опция аналогична такой же опции для триггеров DML .
■ event _ type – имя события, при наступлении которого должен быть запущен триггер. Список событий можно найти в документации. Например, ALTER_INDEX означает, что триггер будет запускаться при попытке изменить индекс.
■ event _ group – можно указать целую группу событий, при наступлении которых должен быть запущен данный триггер. Список имен групп событий можно найти в документации. Например, DDL_TABLE_EVENTS означает группу событий, связанных с таблицами.
Поскольку остальные опции нам уже знакомы, перейдем сразу к примеру (см. Листинг 3.85 ).
Листинг 3.85
create trigger tr1
for DDL_TABLE_EVENTS – триггер на операции с таблицами
raiserror ( ‘ Операции над таблицами запрещены ‘,16,3)
При работе с DDL триггерами удобно использовать функцию eventdata () . Данная функция, запущенная внутри триггера возвращает полную информацию о происшедшем событии. Особенностью функции является то, что информация, которую она возвращает, имеет структуру xml -документа.