Триггеры - это отдельный модуль, который общается с Системой по интеграционной шине.
Цель триггеров как инструмента - автоматизация бизнес-процессов. Возможность сделать так, чтобы пользователю приходилось делать меньше действий в Системе и не совершать ошибок на уровне «забыл проставить нужный реквизит».
Идеальная картина: нажал одну кнопочку - и готово. Система магическим образом узнала, чего от неё хотел пользователь. Всё заполнилось-настроилось-появилось как надо.
Реальность: есть множество небольших кейсов, условий, каждый из которых влечёт за собой действия, которые раньше пользователь воспроизводил вручную.
«Большая» автоматизация - это набор небольших сценариев. Каждый «большой» бизнес-процесс декомпозируется на составляющие.
Таким образом первоначально триггеры автоматизируют маленькие кусочки бизнес-процессов.
Только когда процессы, которые Вы перенесли в Систему, обкатаны вручную. Когда вы «на коленке» убедились в их жизнеспособности.
В момент первоначального внедрения ИСУП, вы можете только предполагать, как это будет работать.
Автоматизация фиксирует процессы. Прежде чем процесс зафиксировать, нужно его обкатать, убедиться в его жизнеспособности.
На этапе внедрения может быть некая идеальная картина, которую воспроизводят объекты и таблицы Системы. Но уже через несколько месяцев бизнес-процессы могут внести свои коррективы в то, что было настроено. → Если будет на старте внедрена автоматизация, она либо перестанет работать, либо станет проблемой, которую пользователи вынуждены будут обходить.
Сейчас этот процесс автоматизирован. Когда триггер фиксирует событие о том, что в такой-то таблице появилась запись из такого-то объекта, и там указан определённый классификатор, триггер через API инициирует создание нужного объекта.
Слабость автоматизации в том же, в чём и сила: в «бетонировании» бизнес-процессов.
Меняются требования, отчёты, данные, которые нужно вносить. Появляются новые идеи, которые конфликтуют со старыми.
Расхождения между реализованной автоматизацией и реальным бизнес-процессами могут показаться ошибками. Но на самом деле - это лишь старые бизнес-процессы, которые перестали быть актуальными.
Ошибка в контексте триггеров - это если реализация не соответствует требованиям из согласованного технического задания.
Если же прошло полгода-год-два, сами процессы изменились, а триггер работает по-старому, это не ошибка работы триггера. Программный код не в курсе ваших изменений - об этом можете знать только Вы.
Процессы изменчивы, и это нормально. Самое сложное в триггерах - это соблюсти баланс:
Триггер - это мощный инструмент в руках человека, понимающего настроенные в ADVANTA процессы и знающего, как они работают.
В руках сотрудника не совсем понимающего как все работает, но имеющего права доступа этот инструмент может принести больше вреда, чем пользы.
Триггер это микроавтомат (робот), выполняющий набор рутинных действий при наступлении определенного события в бизнес-процессе, и поэтому чувствителен к изменению условий в которых он работает. Если изменились условия или процесс, то триггер, выполняющий рутину под старый процесс, скорее всего станет выполнять неадекватные новому процессу действия, или сломается.
Соответственно самый верный способ «завалить» работу триггеров - это создать хаос в настройках: забыть, зачем и что было настроено, смело добавлять, удалять и переименовывать реквизиты, объекты, таблицы, менять ограничения по созданию дочерних объектов и т.п. Впрочем, такие действия обязательно создадут массу неадекватных данных и сломают отчетность, OLAP-кубы и прочие аналитические инструменты Системы и без всяких триггеров. С ними же сломается все еще быстрее.
И тогда у вас будут почти безграничные возможности автоматизации!
Действия пользователя:
Работа триггера (может быть как одно, так и все перечисленные действия):
Действия пользователя:
Работа триггера (может быть как одно, так и все перечисленные действия):
Действия пользователя:
Когда согласование завершено/дискуссия закрыта, Система ADVANTA с помощью триггеров автоматически: