7 lines
23 KiB
JSON
7 lines
23 KiB
JSON
{
|
||
"index": 359,
|
||
"slug": "editorial-2018-01-mechanism-bitrix-elements",
|
||
"title": "CIBlockElement::Add в Bitrix: где проходит граница между событием и сервисом",
|
||
"excerpt": "Разбираем путь создания элемента инфоблока: обработчики до и после Add, общий инвариант, диагностика LAST_ERROR и проверка результата без скрытой магии init.php.",
|
||
"contentHtml": "<p>Скрипт вызывает <code>CIBlockElement::Add</code>, получает ID и завершает работу. Через несколько минут элемент находится в админке, но каталог не показывает его, импорт не объясняет отказ, а повторный запуск создаёт дубль. Разработчик ищет проблему в шаблоне или кеше. На самом деле часть правил уже выполнил обработчик события, часть не выполнил никто.</p>\\n<p>Цена такой ошибки — не только одна неверная запись. Команда теряет исходные данные, повторяет операцию вслепую и рискует отправить наружу неполный товар. Если событие после добавления упало, ID уже существует. Если событие до добавления изменило поля, вызывающий код мог не знать об этом. Поэтому одного факта «метод вернул число» недостаточно.</p>\\n<p>Тезис статьи простой: <code>Add</code> — граница записи, а не готовый бизнес-сценарий. Сервис должен подготовить вход, вызвать метод и вернуть диагностируемую ошибку. Обработчик до записи должен защищать только общий инвариант. Обработчик после записи должен запускать отдельную реакцию. Публичную готовность нужно подтвердить отдельной выборкой.</p>\\n<h2>Механизм: что происходит вокруг Add</h2>\\n<p>Вызов начинается с массива полей. В нём обычно есть <code>IBLOCK_ID</code>, <code>NAME</code>, <code>CODE</code>, статус, раздел и <code>PROPERTY_VALUES</code>. Bitrix передаёт эти данные в обработчики события до добавления. Обработчик может изменить массив или отменить операцию с сообщением об ошибке.</p>\\n<p>Если проверка проходит, Bitrix записывает элемент и свойства. При успехе объект <code>CIBlockElement</code> возвращает ID. При ошибке он возвращает <code>false</code>, а причина доступна в <code>LAST_ERROR</code>. После записи вызывается событие <code>OnAfterIBlockElementAdd</code>. Это уже другой этап: элемент существует, даже если последующая реакция не завершилась.</p>\\n<p>Из этого следуют три разных результата. Первый — запись отклонена до сохранения. Второй — элемент сохранён, но зависимые действия ещё не завершены. Третий — элемент прошёл публичную выборку и готов для пользователя. Нельзя называть эти состояния одним словом «успех».</p>\\n<figure><img src=\"/assets/editorial/2018/bitrix-add-lifecycle.svg\" alt=\"Путь создания элемента Bitrix: сервис, событие до записи, Add, событие после записи и контрольная публичная выборка\" loading=\"lazy\" /><figcaption>Схема разделяет запись элемента, общую защиту и проверку пользовательского результата. Учебная иллюстрация не показывает конкретную production-конфигурацию.</figcaption></figure>\\n<h2>Где должно жить правило</h2>\\n<p>Сервис знает намерение операции. Он понимает, создаёт ли импорт черновик, форма — опубликованный материал, а миграция — временную запись. Поэтому сервис проверяет вход, задаёт значения по умолчанию, подготавливает свойства и связывает ошибку Bitrix с контекстом операции.</p>\\n<p><code>OnBeforeIBlockElementAdd</code> видит каждый подходящий вызов. Это хорошее место для инварианта, который нельзя нарушить ни из админки, ни из CLI, ни из endpoint. Например, для одного инфоблока всегда нужен непустой <code>CODE</code>. Но обработчик не знает, нужен ли конкретному импорту файл, цена или внешний HTTP-запрос. Эти правила относятся к вызывающей операции.</p>\\n<p>Событие после записи подходит для журнала, постановки фоновой задачи или обновления поискового индекса. Оно не должно молча менять смысл успешного <code>Add</code>. Если побочный шаг обязателен перед публикацией, храните состояние «элемент сохранён» отдельно от состояния «элемент готов». Тогда повторный запуск не создаст новую запись только потому, что индексатор временно не ответил.</p>\\n<table><caption>Распределение ответственности в жизненном цикле</caption><thead><tr><th scope=\"col\">Участок</th><th scope=\"col\">Что проверяет</th><th scope=\"col\">Чего не делает</th></tr></thead><tbody><tr><td>Сервис</td><td>Вход, намерение, конфигурацию, внешний ключ и понятный результат</td><td>Не подменяет общий инвариант глобальным событием</td></tr><tr><td>OnBeforeIBlockElementAdd</td><td>Обязательное правило для данного инфоблока</td><td>Не выполняет тяжёлые HTTP-вызовы и правила одного экрана</td></tr><tr><td>Add</td><td>Сохраняет элемент и переданные свойства</td><td>Не обещает цену, остаток, URL и публичную видимость</td></tr><tr><td>OnAfterIBlockElementAdd</td><td>Запускает реакцию после записи и фиксирует ID</td><td>Не отменяет уже сохранённую запись чистым возвратом</td></tr><tr><td>Контрольная выборка</td><td>Проверяет поля, свойства и фильтры потребителя</td><td>Не исправляет исходные данные автоматически</td></tr></tbody></table>\\n<h2>Минимальный предохранитель до записи</h2>\\n<p>Ниже — учебный пример для одного инфоблока. Он не является готовым обработчиком для любого проекта: идентификатор, регистрация события и текст ошибки должны соответствовать вашей конфигурации. Предохранитель проверяет только общий инвариант. Он не создаёт <code>CODE</code> из названия и не делает сетевой запрос.</p>\\n<pre><code><?php\\n\\nconst PRODUCT_IBLOCK_ID = 12;\\n\\nAddEventHandler(\\n \"iblock\",\\n \"OnBeforeIBlockElementAdd\",\\n [CatalogElementGuard::class, \"beforeAdd\"]\\n);\\n\\nfinal class CatalogElementGuard\\n{\\n public static function beforeAdd(array &$fields): bool\\n {\\n if ((int)($fields[\"IBLOCK_ID\"] ?? 0) !== PRODUCT_IBLOCK_ID) {\\n return true;\\n }\\n\\n if (trim((string)($fields[\"CODE\"] ?? \"\")) === \"\") {\\n global $APPLICATION;\\n $APPLICATION->ThrowException(\\n \"Для элемента каталога нужен символьный код\"\\n );\\n return false;\\n }\\n\\n return true;\\n }\\n}</code></pre>\\n<p>Возврат <code>false</code> здесь означает отказ до записи. Вызывающий код всё равно обязан проверить результат <code>Add</code> и прочитать <code>LAST_ERROR</code>. Нельзя считать, что сообщение из обработчика автоматически попадёт в нужный журнал, ответ API или интерфейс администратора.</p>\\n<h2>Сервис сохраняет контекст ошибки</h2>\\n<p>Сервис не должен прятать массив полей за глобальным вызовом. Он принимает данные операции, проверяет обязательные значения и передаёт Bitrix только подготовленный контракт. Внешний ключ нужен для повторного запуска: по нему можно решить, создавать запись, обновить черновик или остановиться с конфликтом.</p>\\n<pre><code><?php\\n\\nfunction addCatalogElement(array $input): int\\n{\\n if (!\\Bitrix\\Main\\Loader::includeModule(\"iblock\")) {\\n throw new RuntimeException(\"Модуль iblock не подключён\");\\n }\\n\\n $name = trim((string)($input[\"name\"] ?? \"\"));\\n $code = trim((string)($input[\"code\"] ?? \"\"));\\n $externalId = trim((string)($input[\"externalId\"] ?? \"\"));\\n\\n if ($name === \"\" || $code === \"\" || $externalId === \"\") {\\n throw new InvalidArgumentException(\\n \"Нужны name, code и externalId\"\\n );\\n }\\n\\n // Учебный пример: ID инфоблока и свойства заданы явно.\\n $fields = [\\n \"IBLOCK_ID\" => PRODUCT_IBLOCK_ID,\\n \"NAME\" => $name,\\n \"CODE\" => $code,\\n \"ACTIVE\" => \"N\",\\n \"PROPERTY_VALUES\" => [\\n \"EXTERNAL_ID\" => $externalId,\\n ],\\n ];\\n\\n $element = new CIBlockElement();\\n $id = $element->Add($fields);\\n\\n if ($id === false) {\\n throw new RuntimeException(\\n \"Не удалось добавить элемент \" . $externalId . \": \" .\\n ($element->LAST_ERROR ?: \"причина не указана\")\\n );\\n }\\n\\n return (int)$id;\\n}</code></pre>\\n<p>Пример учебный. В нём нет транзакции внешней системы, блокировки от конкурентного импорта и политики повторов. В production эти решения зависят от хранилища и контракта источника. Код показывает только границу: ошибка <code>Add</code> становится явным исключением, а ID не выдаётся без проверки.</p>\\n<h2>Симптом → причина → проверка → действие</h2>\\n<table><caption>Диагностическая карта для создания элемента</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td><code>Add</code> вернул <code>false</code></td><td>Пустое поле, отказ обработчика, права или неверный инфоблок</td><td>Сохранить <code>LAST_ERROR</code>, входной внешний ключ и итоговый массив без секретов</td><td>Исправить контракт или обработчик; повторять только после понимания отказа</td></tr><tr><td>ID есть, поле изменилось само</td><td><code>OnBeforeIBlockElementAdd</code> переписал массив</td><td>Сравнить поля до вызова с данными контрольного чтения</td><td>Оставить изменение только для общего правила или перенести его в сервис</td></tr><tr><td>Элемент есть, свойства пусты</td><td>Неверный код свойства, формат значения или неполный массив</td><td>Прочитать конкретные свойства по ID и сверить тип свойства</td><td>Исправить <code>PROPERTY_VALUES</code>; не маскировать сбой повторным <code>Add</code></td></tr><tr><td>Элемент есть в админке, но не в каталоге</td><td>Публичный фильтр исключает статус, дату, раздел, права или зависимые данные</td><td>Повторить выборку с фильтрами компонента</td><td>Исправить данные или фильтр; кеш проверять последним</td></tr><tr><td>После сбоя появился дубль</td><td>Повторный запуск не проверяет внешний ключ</td><td>Найти записи по внешнему идентификатору и журналу операции</td><td>Ввести правило идемпотентности до вызова <code>Add</code></td></tr><tr><td>Сервис вернул ID, а индекс не обновился</td><td>Ошибка в <code>OnAfterIBlockElementAdd</code> или отдельном обработчике</td><td>Разделить лог записи и лог реакции после записи</td><td>Повторить реакцию по сохранённому ID, не создавать элемент заново</td></tr></tbody></table>\\n<h2>Свойства и отрицательный путь</h2>\\n<p><code>PROPERTY_VALUES</code> удобно передавать вместе с обязательными полями при создании. Но массив должен соответствовать реальным кодам и типам свойств. Множественное свойство, список, файл и связь с элементом имеют разные форматы. Учебный массив со строкой не доказывает, что такой же формат подходит вашему инфоблоку.</p>\\n<p>Нельзя использовать точечное обновление как сигнал успеха без чтения результата. Если после создания нужно изменить одно свойство, применяйте поддерживаемый для вашей версии метод и затем читайте это свойство контрольным запросом. Не передавайте неполный набор в операцию, которая может затронуть остальные значения, пока не проверили её семантику на тестовом инфоблоке.</p>\\n<p>Отрицательный путь начинается там, где правило не выполняется. Нет внешнего ключа — операция останавливается до Bitrix. Нет обязательного <code>CODE</code> — сервис возвращает понятный отказ, а общий обработчик остаётся последней защитой. <code>Add</code> вернул <code>false</code> — запись не считается созданной. ID есть, но после-обработчик упал — запись считается созданной, а реакция получает отдельный статус. Не превращайте эти случаи в один повтор.</p>\\n<h2>Порядок проверки</h2>\\n<ol><li>Опишите источник операции: форма, импорт, CLI или endpoint. Запишите внешний ключ и ожидаемое состояние элемента.</li><li>Проверьте обязательные поля и свойства до вызова Bitrix. Отдельно зафиксируйте значения, которые добавит обработчик.</li><li>Найдите все обработчики <code>OnBeforeIBlockElementAdd</code> и <code>OnAfterIBlockElementAdd</code> для этого инфоблока. Для каждого запишите изменение, отказ и побочный эффект.</li><li>Вызовите <code>Add</code> с минимальным массивом, который соответствует контракту инфоблока. Не делайте элемент активным до заполнения зависимых данных.</li><li>Проверьте результат строго: положительный ID — успех записи, <code>false</code> — отказ. При отказе сохраните <code>LAST_ERROR</code> и не запускайте повтор вслепую.</li><li>Прочитайте элемент по ID без публичных ограничений. Проверьте поля, раздел и каждое обязательное свойство.</li><li>Повторите запрос с фильтрами потребителя: активность, даты, права, раздел, проектные свойства и товарные данные, если они участвуют в каталоге.</li><li>Проверьте реакцию после записи по тому же ID. Если она не завершилась, поставьте отдельный статус и повторяйте реакцию, а не создание.</li><li>Только после всех проверок переведите элемент в состояние, в котором его должен видеть пользователь.</li></ol>\\n<h2>Ограничения</h2>\\n<p>События Bitrix глобальны в пределах приложения. Один обработчик может влиять на админку, импорт и консольный скрипт. Поэтому широкое условие в <code>init.php</code> опаснее локальной проверки сервиса. Ограничивайте обработчик инфоблоком и фиксируйте его контракт рядом с регистрацией.</p>\\n<p>Успешный <code>Add</code> не проверяет весь каталог. Цена, остаток, торговое предложение, права, кеш, поиск и URL могут жить в других слоях. Не приписывайте методу эффект, которого он не обещает. Контрольная выборка должна повторять реальные фильтры компонента.</p>\\n<p>Проверка на тестовом инфоблоке не доказывает production-результат. Она подтверждает только выбранный сценарий и формат данных. Конкурентные импорты, права пользователя, версия Bitrix и конфигурация обработчиков требуют отдельных проверок. Если среда не позволяет их проверить, назовите это ограничением.</p>\\n<h2>Проверяемый критерий готовности</h2>\\n<p>Работа готова, если другой разработчик без автора может показать четыре доказательства: вызов либо принялся, либо отказал с текстом причины; созданный ID читается с ожидаемыми полями и свойствами; запись проходит публичную выборку с фильтрами потребителя; повтор после сбоя реакции не создаёт новый элемент. В журнале остаются внешний ключ, ID, итоговый статус и причина отказа, если она была.</p>\\n<p>Если есть только ID из ответа, готовности нет. Если админка показывает элемент, но контрольный запрос каталога его исключает, готовности нет. Если событие после записи запускает побочный процесс, но его ошибка теряется, готовности нет. Эти отрицательные результаты не требуют очистки кеша или повторного <code>Add</code>; они указывают на следующий слой проверки.</p>\\n<h2>Проверяемые источники</h2>\\n<ul><li><a href=\"https://dev.1c-bitrix.ru/api_help/iblock/classes/ciblockelement/add.php?print=Y\" target=\"_blank\" rel=\"noopener noreferrer\">Документация Bitrix: CIBlockElement::Add</a> — поля, <code>PROPERTY_VALUES</code>, обработчики, возвращаемый ID и <code>LAST_ERROR</code>.</li><li><a href=\"https://dev.1c-bitrix.ru/api_help/iblock/events/onbeforeiblockelementadd.php\" target=\"_blank\" rel=\"noopener noreferrer\">Документация Bitrix: OnBeforeIBlockElementAdd</a> — изменение полей и отмена добавления с ошибкой.</li><li><a href=\"https://dev.1c-bitrix.ru/api_help/iblock/classes/ciblockelement/setpropertyvaluesex.php\" target=\"_blank\" rel=\"noopener noreferrer\">Документация Bitrix: CIBlockElement::SetPropertyValuesEx</a> — точечная работа со значениями свойств.</li></ul>"
|
||
} |