Ця документація була автоматично перекладена штучним інтелектом.
Тригери типу подій колекції відстежуватимуть події створення, оновлення та видалення даних у колекції. Коли відбувається операція з даними в цій колекції, і вона відповідає налаштованим умовам, запускається відповідний робочий процес. Наприклад, це можуть бути сценарії, такі як списання товарних запасів після створення нового замовлення, або очікування ручної перевірки після додавання нового коментаря.
Зміни в колекції можуть відбуватися в кількох випадках:

Ви можете вибрати час спрацьовування відповідно до різних бізнес-потреб. Якщо вибраний тип зміни включає оновлення колекції, ви також можете обмежити поля, які спричиняють зміну. Умова спрацьовування буде виконана лише тоді, коли зміняться вибрані поля. Якщо поля не вибрано, це означає, що зміна будь-якого поля може запустити робочий процес.

Більш детально, ви можете налаштувати правила умов для кожного поля рядка даних, що викликає спрацьовування. Тригер спрацює лише тоді, коли поля відповідатимуть відповідним умовам.

Після спрацьовування події колекції рядок даних, що її згенерував, буде вставлено в план виконання як контекстні дані тригера, щоб наступні вузли в робочому процесі могли використовувати їх як змінні. Однак, якщо наступні вузли потребують використання полів зв'язків цих даних, вам потрібно спочатку налаштувати попереднє завантаження даних зв'язків. Вибрані дані зв'язків будуть вставлені в контекст разом із тригером і можуть бути вибрані та використані ієрархічно.
Події колекції наразі не підтримують спрацьовування за допомогою масових операцій з даними. Наприклад, при створенні статті та одночасному додаванні кількох тегів для цієї статті (дані зв'язку «один-до-багатьох»), буде запущено лише робочий процес для створення статті. Одночасно створені теги не запускатимуть робочий процес для створення тегів. При зв'язуванні або додаванні даних зв'язку «багато-до-багатьох» робочий процес для проміжної колекції також не буде запущено.
Операції з колекціями через виклики HTTP API до інтерфейсу застосунку також можуть запускати відповідні події. Однак, якщо зміни даних відбуваються безпосередньо через операції з базою даних, а не через застосунок NocoBase, відповідні події не можуть бути запущені. Наприклад, власні тригери бази даних не будуть пов'язані з робочими процесами в застосунку.
Крім того, використання вузла SQL-операції для роботи з базою даних еквівалентно прямим операціям з базою даних і не запускатиме події колекції.
Робочі процеси підтримують зовнішні джерела даних, починаючи з версії 0.20. Якщо ви використовуєте плагін зовнішнього джерела даних, і подія колекції налаштована для зовнішнього джерела даних, то доки операції з даними цього джерела виконуються в межах застосунку (наприклад, створення, оновлення користувачем та операції з даними робочого процесу), відповідні події колекції можуть бути запущені. Однак, якщо зміни даних відбуваються через інші системи або безпосередньо у зовнішній базі даних, події колекції не можуть бути запущені.
Розглянемо сценарій, коли після створення нового замовлення розраховується загальна вартість і списуються товарні запаси.
Спершу створимо колекції «Товари» та «Замовлення» з такими моделями даних:
| Назва поля | Тип поля |
|---|---|
| Назва товару | Однорядковий текст |
| Ціна | Число |
| Запаси | Ціле число |
| Назва поля | Тип поля |
|---|---|
| Номер замовлення | Послідовність |
| Товар замовлення | Багато-до-одного (Товари) |
| Загальна вартість замовлення | Число |
Додамо базові дані товарів:
| Назва товару | Ціна | Запаси |
|---|---|---|
| iPhone 14 Pro | 7999 | 10 |
| iPhone 13 Pro | 5999 | 0 |
Потім створимо робочий процес на основі події колекції «Замовлення»:

Ось деякі з параметрів конфігурації:
Потім налаштуйте інші вузли відповідно до логіки робочого процесу: перевірте, чи запаси товару більші за 0. Якщо так, спишіть запаси; інакше замовлення є недійсним і має бути видалене:

Конфігурація вузлів буде детально описана в документації для конкретних типів вузлів.
Увімкніть цей робочий процес і протестуйте його, створивши нове замовлення через інтерфейс. Після оформлення замовлення на «iPhone 14 Pro» запаси відповідного товару зменшаться до 9. Якщо ж замовлення буде оформлено на «iPhone 13 Pro», замовлення буде видалено через недостатність запасів.
