Пользовательские хуки и триггеры

Hooks and triggers connect platform lifecycle events to automated responses – so that things happen at the right moment automatically, not when someone remembers to act.

Фреймворк Behavior Extensibility предоставляет события платформы как точки подключения для пользовательской логики. Происходит событие — проект фиксируется в Workspace, инициируется выпуск, изменяется состояние жизненного цикла компонента — и хук срабатывает в ответ. Ответом может быть проверка, которая блокирует действие, если условия не выполнены, побочный эффект, который уведомляет или обновляет внешнюю систему, либо преобразование, подготавливающее данные для следующего этапа конвейера.

Именно хуки делают платформу проактивной. Без них автоматизация реактивна: кто-то замечает состояние и запускает действие. С хуками платформа по определению действует в нужный момент, потому что триггером является само событие.

Типы хуков и их роли

• Blocking hooks (pre-action) — блокирующий хук срабатывает до завершения действия и может предотвратить его выполнение. Хук, зарегистрированный на событие перед выпуском, может выполнить финальный набор проверок и прервать выпуск, если хотя бы одна из них не пройдет. Хук на утверждение компонента может проверить, что все обязательные поля заполнены и все детали производителей входят в утвержденный список, прежде чем компонент попадет в библиотеку.

  Блокирующие хуки — это механизм обеспечения правил, которые должны быть истинны до того, как действие будет разрешено, — не правил, которые желательно выполнять, а правил, которые обязаны выполняться. Именно они определяют разницу между «мы рекомендуем проверить X перед выпуском» и «выпуск невозможен, если X не выполняется».

• Non-blocking hooks (post-action) — неблокирующий хук срабатывает после завершения действия и инициирует побочные эффекты. Хук после выпуска может отправить артефакты выпуска во внешнюю систему, обновить запись в ERP, уведомить следующую по цепочке команду или зафиксировать событие аудита. Выпуск уже состоялся; хук обрабатывает его последствия.

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

• Scheduled triggers — помимо хуков, управляемых событиями, платформа поддерживает выполнение логики автоматизации по расписанию — скриптов или проверок, которые запускаются регулярно, а не в ответ на конкретное событие. Это полезно для периодической отчетности, синхронизации данных, не требующей работы в реальном времени, и операций обслуживания, которые должны выполняться регулярно.

Типовые шаблоны

• Release gate enforcement — блокирующий хук перед выпуском выполняет финальный набор проверок — пользовательские валидации, запросы к внешним системам, проверки полноты документации — и блокирует выпуск, если хотя бы одна из них не пройдена. Инженер получает понятную обратную связь о том, что именно не прошло и что нужно исправить. Запись о выпуске включает результаты хука, поэтому сохраняется полный аудиторский след того, что проверялось и что было пройдено.

• Post-release propagation — неблокирующий хук после выпуска отправляет данные выпуска в последующие системы: управление производственным исполнением, ERP, системы управления проектами, архивные системы. Хук срабатывает автоматически после завершения выпуска, устраняя ручной этап уведомления или обновления каждой системы.

• Lifecycle synchronization — когда состояние жизненного цикла компонента изменяется в Altium 365 — с «In Design» на «Released» или с «Active» на «Obsolete» — хук может распространить это изменение в PLM, ERP или другие системы, которые ведут записи о компонентах. Хук является точкой синхронизации; событие платформы — авторитетным триггером.

• Key System Flow override — в более сложных случаях хуки могут использоваться для переопределения или расширения основных потоков платформы — изменения поведения по умолчанию в ключевых точках жизненного цикла системы. Это продвинутое использование, и оно включено в дорожную карту как возможность, которая со временем будет расширяться.

Риски и обработка сбоев

Блокирующие хуки, которые завершаются ошибкой из-за недоступности внешней системы, не должны молча пропускать проекты дальше. Режим отказа имеет значение: хук, который не может получить доступ к списку утвержденных поставщиков, должен завершаться по принципу fail closed — блокировать действие и сообщать, что проверка не могла быть выполнена, — а не по принципу fail open, позволяя потенциально несоответствующему проекту продолжать выполнение.

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