Фундамент автоматизации
Уровень Продвинутый
Переменные и константы: как проектировать общее состояние системы в бизнес-процессах
Забудьте про «глобальные переменные — это зло». Научимся использовать их по назначению: как единый источник истины для независимых процессов, которые должны знать общее состояние системы (например, наработка станка).
Когда вам пригодятся эти знания?
Эта статья содержит много специфической информации. Чтобы настроиться на "правильное" восприятие попробуйте разложить процессы в компании на мелкие составляющие. В итоге Вы увидите:
- секретарь присваивает номер исходящему письму прибавляя 1 к предыдущему номеру;
- водитель сообщает, что необходимо делать ТО, потому что с предыдущего прошло много времени или по пробегу уже пора;
- на совещание по итогам квартала пришли два заместителя руководителей отдела, потому что один руководитель заболел, а другой в командировке.
Понятные жизненные ситуации, с которыми мы сталкиваемся ежедневно и не обращаем на них особого внимания, потому что "так и должно быть".
Теперь посмотрим на эти события со стороны автоматизации!
Во всех событиях есть:
- переменные - номер последнего исходящего; пробег автомобиля на дату последнего ТО или кто замещает руководителя на совещании;
- константы - сколько км между ТО; какую цифру прибавлять к последнему номеру исх; кто замещает начальника транспортного цеха на период его болезни по понедельникам.
Вот о переменных и константах мы и поговорим
Где мы видим переменные и константы в битрикс24?
Глобальные переменные и константы
Локальные переменные и константы
Все данные разные. И хранилище для них должно быть разным.
В бизнес-процессах есть временные данные (например, счётчик отправленных писем в рамках одной жалобы), а есть состояние системы (например, общая наработка станка в часах). Первые должны умирать вместе с процессом, вторые — жить своей жизнью и быть доступными всем. Сегодня мы разберём полную типологию данных в БП и главный кейс, где глобальные переменные — это не костыль, а архитектурное решение.
ЧАСТЬ 1
ТИПОЛОГИЯ: ЧЕТЫРЕ КОНТЕЙНЕРА ДЛЯ ДАННЫХ
| Контейнер | Область видимости | Можно изменить? | Предназначение (Когда использовать?) | |
| Локальная переменная | Только внутри одного запущенного экземпляра БП. | Да. | Для промежуточных расчётов, счётчиков и временных данных, которые не имеют смысла за пределами этого процесса. Живут и умирают с процессом. | |
| Глобальная переменная | Видна всем бизнес-процессам в CRM. | Да. | Для хранения общего состояния системы (state), к которому нужно обращаться из разных, независимых процессов. Это единый источник истины для агрегированных данных. | |
| Константа (значение) | Глобальная (по умолчанию). | Нет. Задаётся при создании. | Для хранения справочной, неизменяемой информации: ID шаблонов, фиксированные коэффициенты, эталонные списки. | |
| Константа (список) | Глобальная (по умолчанию). | Нет (но список — набор значений). | Для хранения неизменяемых наборов, например, состав комитета по ролям. |
💡 Ключевой вывод: Выбор контейнера зависит не от удобства, а от семантики данных и их жизненного цикла. Где рождаются данные? Кому они нужны? Как долго должны жить?
ЧАСТЬ 2
АРХИТЕКТУРНЫЙ ПАТТЕРН: ГЛОБАЛЬНАЯ ПЕРЕМЕННАЯ КАК «СОСТОЯНИЕ СИСТЕМЫ»
Проблема: как связать независимые процессы общими данными?
Представьте, что у вас есть смарт-процесс «Резка», который фиксирует каждую производственную операцию. И есть правило техобслуживания: каждые 1000 минут работы станка нужна очистка.
Простой подход (попытка через локальные данные):
- Каждый процесс «Резка» считает своё время (5 или 10 минут) и... не может передать его куда-то для накопления.
- Чтобы узнать общую наработку, придётся постоянно формировать сводный отчет о всех завершённых процессах «Резка» с различными значениями в поле со списком вариантов (ведь каждый вариант отличается по времени выполнения) и путем нехитрых математических операций получать итоговое значение за выбранный период.
- При достижении определенного значения ставить задачу на чистку оборудования.
Этот вариант требует контроля выполнения, длителен, отвлекает ресурсы.
Правильный подход (глобальная переменная как состояние):
1. Создаём Глобальную переменную Станок_1_Наработка_Минут;
2. В каждом процессе «Резка» при завершении операции:
2. В каждом процессе «Резка» при завершении операции:
- Берем из Глобальной константы Время_Операции значение для выполнения определенного задания (5, 10, 15 мин).
- Атомарно увеличиваем глобальную переменную: Станок_1_Наработка_Минут = Станок_1_Наработка_Минут + Время_Операции.
При достижении 1000 — создаёт задачу на очистку.
Почему это архитектурно верно:
- Разделение ответственности: Процесс «Резка» отвечает за фиксацию факта. Дополнительная активити в бизнес-процессе — за контроль состояния. Они слабо связаны.
- Единый источник истины: Состояние системы (наработка) хранится в одном месте.
- Производительность: Не нужно постоянно агрегировать данные из сотен завершённых сделок.
⚠️ Важное техническое замечание: Атомарность и блокировки
В этом примере станок один, и процессы идут последовательно. Но в теории два процесса «Резка» могут почти одновременно попытаться изменить одну глобальную переменную.
Битрикс24 не гарантирует атомарность таких операций «прочитать-изменить-записать» для глобальных переменных из разных потоков.
Решение: Для сверхкритичных сценариев можно реализовать простую «блокировку» через дополнительную глобальную переменную-флаг.
Битрикс24 не гарантирует атомарность таких операций «прочитать-изменить-записать» для глобальных переменных из разных потоков.
Решение: Для сверхкритичных сценариев можно реализовать простую «блокировку» через дополнительную глобальную переменную-флаг.
Но для 95% бизнес-кейсов вероятности коллизии ничтожны, и паттерн работает отлично.
ЧАСТЬ 3
ПАТТЕРН: КОНСТАНТЫ КАК ИНТЕРФЕЙС МЕЖДУ БИЗНЕСОМ И IT
Отделяем настройки от кода: константы вместо жёстких ссылок
Этот паттерн дополняет первый. Допустим, в вашем процессе «Резка» время операции (5 или 10 мин) хранится не в коде БП, а в Глобальной константе Время_Резки_Прямой и Время_Резки_Угловой.
Что это даёт:
- Смена таймингов — это изменение значения константы, а не переписывание десятков БП.
- Чистота шаблонов: Ваш шаблон БП «Резка» становится универсальным. Он знает, что нужно взять время из константы, но не знает, какое именно.
- Разделение сфер: Технолог меняет нормативы (константы) → Все процессы автоматически начинают работать по новым нормативам.
ЧАСТЬ 4
ПРАКТИКА: КОГДА ЧТО ИСПОЛЬЗОВАТЬ (ШПАРГАЛКА)
Быстрое решение: куда положить эти данные?
Используйте ЛОКАЛЬНУЮ переменную, если:
- Считаете что-то внутри одного процесса (счётчик писем, промежуточная сумма).
- Данные нужны только для принятия решений внутри этого БП и больше нигде.
- Нужно накапливать состояние от множества независимых процессов (наработка, общее количество заказов за день, текущий номер договора).
- Данные должны быть единым источником истины для других, независимых процессов или роботов.
- Храните справочник (состав комитета по ролям, ID шаблонов документов).
- Храните неизменяемые нормативы и настройки (время операции, коэффициенты, лимиты).
- Хотите отделить настройки от логики процесса.
Итог: данные на своих местах — система под контролем
- Локальные переменные — ваша рабочая память. Активны только во время выполнения задачи.
- Глобальные переменные — долговременная память системы. Хранят её состояние. Используйте их осознанно для связки независимых процессов.
- Константы — инструкция и справочник системы. Хранят настройки, которые должны быть неизменны во время работы, но могут быть легко обновлены администратором.
Опишите ваш процесс — я предложу архитектуру решения
Ваш самый сложный и запутанный кейс — лучший кандидат для разбора. Опишите его, и я подготовлю анализ и принципиальный план автоматизации. Так мы сразу поймем, можем ли работать вместе.
— Бесплатные Сайты и CRM.