Файл обработчик смены данного статуса на какой либо другой либо удаление результата
Если вам необходимо разместить на сайте собственный функционал, то наиболее правильным с точки зрения Bitrix Framework будет:
разработать собственный компонент и в дальнейшем разместить его на требуемых страницах сайта
Где хранятся значения по умолчанию параметров модуля?
в файле /bitrix/modules/ID_модуля/default_option.php
Папка с обновлением модуля должна содержать следующие обязательные файлы:
description.*
version.php
Какое написание ID модуля для Bitrix Framework является правильным?
my2module
mymodule2
mymodule
Если информация отдается из кэша до тех пор, пока она не поменяется в базе данных и кэш сбросится автоматически, то это:
Авто + Управляемое кэширование
Папки и файлы минимально необходимые для работы компонента с языковыми фразами:
component.php
/lang
.description.php
При разработке шаблона компонента разработчик
может использовать все возможности языка PHP
Административные скрипты - это
скрипты, используемые модулем в административной части системы и располагающиеся в каталоге /bitrix/modules/ID модуля/admin/
Основные методы достижения оптимальной производительности
ограничение выбираемых полей в запросах АПИ
кеширование «узких» мест
изменение логики для избавления от лишних и тяжелых запросов
Для написания быстрого кода разработчик должен:
использовать кеширование везде, где это необходимо
знать, как работают инструменты отладки в Битриксе
проектировать структуру данных исходя из последующих задач по выборке и фильтрации данных, а не только из простоты интерфейса
понимать, какие системные действия выполняют АПИ функции
ограничивать объём данных в кеше
Для реализации внешней авторизации необходимо создать обработчик соответствующего события в файле
/bitrix/php_interface/init.php
Bitrix Framework позволяет использовать следующие способы хранения кеша:
как в файлах, так и с использованием memcached
как с использованием memcached, так и APC
При программировании в Bitrix Framework:
необходимо подключать модуль, к которому обращается код
Чтобы шаблон компонента мог работать с пользовательским движком шаблонизации, необходимо:
в файл /bitrix/php_interface/init.php добавить описание переменной движка шаблонизации
Если модуль будет удален из системы, то:
при деинсталляции некоторых модулей могут сохраняться накопленные модулем данные (таблицы модуля);
дистрибутив модуля остается в системе, и он в любое время может быть снова установлен;
Основные ошибки в программировании в общем случае, вызывающие проблемы в производительности:
при написании своих компонентов не ограничивается кеш методом SetResultCacheKeys;
в result_modifier для каждого элемента дополнительные поля выбираются дополнительным запросом;
чтобы получить число элементов делается полная выборка с подсчетом средствами php;
при выборке разделов без необходимости включается подсчет числа элементов;
Работать напрямую с переменной $_SESSION
не желательно, но возможно.
Функция для регистрации обработчиков событий, расположенных в модулях
RegisterModuleDependences
Если вам требуется компонент, выполняющий специфичные для вас действия, то необходимо
разработать свой компонент с использованием API Bitrix Framework
Подключаемым файлом модуля является следующий файл в папке модуля
include.php
Для обеспечения внешней авторизации в продукте «1С-Битрикс» необходимо установить обработчик события
OnUserLoginExternal
Класс инсталяции и деинсталяции модуля должен быть описан в файле:
/bitrix/modules/ID_модуля/install/index.php
Укажите способы взаимодействия модулей между собой:
инициализация событий
Для создания и изменения статусов применяется страница одного типа. Переход к странице возможен только в полном режиме редактирования веб-форм.
Это весело
Вы все еще считаете, что динамическое обновление это хорошо? Что нет ни единой причины, чтобы отказаться от него? Что все описанные ошибки, которые даже можно воспроизвести прямо на свежих версиях платформы (от 8.0 до 8.3.20), не являются критичными? Может вы еще и бэкапы не делаете?
Кстати, описанные выше проблемы аткуальный как для платформы 1С версии 8.0, так и для всех более новых версий, вплоть до 8.3.20.*. И это только вершина айсберга!
Надеюсь, информация из статьи поможет кому-то хотя бы задуматься над тем, что Вы делаете!
P.S. А Вы задумывались над тем, что установка расширений тоже может приводить к подобным проблемам? :)
Вы поистине яркий человек
Если Вам и этого мало, то как Вы думаете, что будет, если оба этих случая будут комбинированы? В этом случае Вы "выкинете" всех пользователей из информационной базы, а потом еще и не сможете войти в конфигуратор повторно. Пойдете после этого вручную очищать таблицу "Config" от служебны записей динамического обновления и надеяться, что это в этот раз поможет.
Вы удивительный человек!
А ведь есть еще проблемы другого рода:
- Повреждение сеансовых данных сервера. Возникают из-за какого-то особого поведения платформы 1С, меняется от релиза к релизу, сложно прогнозируемые и сложновоспроизводимые ошибки.
- Повреждение клиентского кэша, которое приводит к:
- Ошибкам запуска клиентского приложения при входе в информационную базу
- Случайным ошибкам во время работы приложения, таким как "Тип неопределен" или подобные.
Ниже есть ссылки на примеры различных проблем и их решение. Для воспроизведения таких проблем мне пришлось бы откопать код приложений платформы 1С, но это не очень правильно.
Основная контекстная панель
Кнопка Описание Добавить Переход на страницу создания нового статуса формы. Настроить Позволяет перейти к диалогу настройки внешнего вида отчетной формы. Excel Экспорт данных из отображаемой таблицы в MS Excel. Подробный пример динамического обновления
Для того, чтобы детальней погрузиться в происходящее при таком обновлении, рассмотрим все действия платформы 1С, до которых можно добраться законым способом. То есть мы не будем влазить в модули работы самой платформы и открывать то, за что можно получить повестку в суд. Мы лишь посмотрим что делает платформа на стороне базы данных. И этого нам будет достаточно!
В нашем примере есть некоторая конфигурация на базе БСП (хотя это и не важно), в которой добавлен очень важный общий модуль "ДляДинамическогоОбновления".
Модуль полностью клиентский, имеет в своем составе только одну функцию.
На первом шаге мы вносим изменения в модуль и нажимаем "Сохранить конфигурацию". При этом изменения в конфигурации сохранены, но не применены к информационной базе.
На этом шаге платформа 1С делает записи в таблицу "ConfigSave", некоторое промежуточное хранилище, из котого потом измененные элементы конфигурации должны будут перенесены в основную таблицу конфигурации "Config".
Вот вся история операций в таблице "ConfigSave" после сохранения конфигурации. Здесь подробная информация обо всех действия практически на физическом уровне, поэтому некоторые операции "INSERT" разделены на две (INSERT и UPDATE), а операция UPDATE может быть выделена как операции DELETE и INSERT. Но эти особенности сейчас не играют роли.
Кроме этого в таблице есть дата операции (Period) и идентификатор транзакции (__$start_lsn). По факту все эти действия выполняются в разных транзакциях, лишь некоторые из действий в таблице выполняются в единой транзакции.
Вся операция, как уже упоминалось выше, делится на два этапа:
- Записываем в таблицу информацию об изменениях конфигурации , в частности нашего общего модуля "ДляДинамическогоОбновления". Кстати, на скрине выше видно, что его идентификатор "cb327a01-e9cc-44e6-af31-5f30c88faeca", отсюда и эти названия похожие. Имена содержат суффикс "new", что говорит о промежуточной записи объектов.
- На следующем шаге промежуточные записи преобразовываем в нормальные , просто исключив "new" из имен элементов конфигурации.
Тут все достаточно просто, идем к следующему шагу. Вы нажимаете кнопку "Обновить информационную базу", но так как в базе есть сеансы, а изменения касаются только модулей, то платформа 1С предлагает выполнить динамическое обновление без завершения сеансов.
В этот момент платформа 1С сделала два действия:
- Скопировала записи из таблицы "ConfigSave" в таблицу "Config" с суффиксом "new", почти все действия выполнены в одной транзакции.
- Затем было обнаружено, что обновление невозможно продолжить из-за наличия активных сеансов. Был показан диалог для динамического обновления, а ранее добавленные записи удалены из таблицы "Config" в одной транзакции.
Изменений в таблице "ConfigSave" в этот момент не выполнялось.
И вот мы добрались до последнего шага - запуска динамического обновления. Соглашаемся с этой операцией и получаем следующее.
- В таблице "Config" сначала добавляются новые записи с суффиком "new" для последующих операций с ними. Примерно такие же действия мы видели в самом начале в таблице "Config", перед тем как было предложено выполнение динамического обновления. Но в этот раз также сделаны служебные записи "commit", "dynamicCommit" и "dbStruFinal", которые относятся непосредственно к динамическому обновлению (частично о них было упомянуто выше).
- Предварительные записи с суффиксом "new" теперь платформа преобразовывает в нормальные записи, также добавляет записи с форматом "_dynupdate_", плюс вставляет флаг динамического обновления "DynamicallyUpdated".
- Из таблицы "ConfigSave" удалены все сохраненные ранее записи. Все в одной транзакции.
- И напоследок из таблицы "Config" удаляются служебные данные "commit", "dynamicCommit" и "dbStruFinal".
Заметьте, каждый этап - почти всегда разные транзакции, это важно.
После этого конфигурация успешно обновлена динамически, база работает. Чтобы клиентам получить новые изменения достаточно перезапустить сеанс. Вроде все хорошо.
На самом деле это не все действия платформы 1С, т.к. еще обновляются данные в таблице "Params" и некоторые другие. Но мы это рассматривать сейчас не будем.
Разработчики ликуют и со словами "Я же говорил" продолжают убеждать коллег, что динамическое обновление это нормально!
Закладка Свойства
Поле Описание Изменен Дата и время последнего изменения настроек статуса. Результатов в данном статусе Количество результатов, имеющих данный статус. Активен Флаг активности статуса. *Заголовок Заголовок статуса. Описание Описание статуса. Порядок сортировки Порядок сортировки статуса (используется, в частности, при выводе выпадающего списка статусов). Присваивать данный статус всем новым документам по умолчанию Данный флаг позволяет присваивать редактируемый статус всем вновь создаваемым документам в случае, если статус не был явно указан. CSS класс для отображения заголовка статуса CSS класс для текста, которым будет выводиться заголовок статуса. Например, в таблице результатов или при просмотре, редактировании статуса при использовании шаблонов типа default.php. Файл-обработчик смены данного статуса на какой-либо другой (либо удаление результата) Адрес файла-обработчика, который будет запускаться при смене статуса. Файл-обработчик смены какого-либо статуса на данный (либо добавление нового результата) Адрес файла-обработчика, который будет запускаться при смене какого-либо статуса на данный. * - Поля, обязательные для заполнения.
Закладка Уведомления
Настройка почтовых шаблонов для уведомления пользователей о смене статуса результата заполнения веб-формы.
Что может пойти не так
Весь процесс динамического обновления мы рассмотрели, но что же может случиться?
Представим простую ситуацию: что, если все обновление прошло успешно, кроме последнего этапа? Например, во время выполнения запросов на удаление служебных данных соединение с базой данных почему-то "отпало":
- Сбой сети.
- Регламентные работы на сервере, внезапно.
- Обслуживание базы, которое завершило блокирующий сеанс, опять же внезапно!
- Конфигуратор вылетел из-за ошибки внутренней.
- Разработчик 1С был странным и завершил сеанс конфигуратора во время обновления.
- И еще сотни причин, которые лень добавлять.
Чтобы такое проще было представить, можно добавить в базу данных триггер, который при попытке удаления служебной записи о динамическом обновлении упадет в ошибку.
Попытаемся теперь выполнить динамическое обновление и столкнемся с ошибками:
- Сначала во время обновления в конфигураторе поймаем ошибку.
- А при попытке зайти в конфигуратор повторно мы словим ошибку.
- При попытке повторить обновление мы уйдем в бесконечную ошибку вида.
Все, конфигуратор нам больше недоступен! Чистите кэш, пытайтесь выполнить обновление ИБ, удаляйте сеансовые данные! Все бесполезно! Можете еще взять бубен, но и он бесполезен!
После этого проблема будет полностью исправлена в 99% случаев.
Закладка Доступ
Настройка прав групп пользователей на доступ к результатам, находящимся в данном статусе.
Для создания и изменения статусов применяется страница одного типа. Переход к странице возможен только в полном режиме редактирования веб-форм.
Контекстная панель
На странице отображены две контекстные панели: основная, аналогичная Основной контекстной панели веб-формы и дополнительная, для формы редактирования статусов. Дополнительная контекстная панель:
Кнопка Описание Новый статус Переход на страницу создания нового статуса формы. Кнопка отображается на странице редактирования уже существующего статуса. Копировать Копирование текущего статуса в новый. Кнопка отображается на странице редактирования уже существующего статуса. Удалить Удаление текущего статуса. Кнопка отображается на странице редактирования уже существующего статуса. Форма редактирования
Закладка Свойства
Поле Описание Изменен Дата и время последнего изменения настроек статуса. Результатов в данном статусе Количество результатов, имеющих данный статус. Активен Флаг активности статуса. *Заголовок Заголовок статуса. Описание Описание статуса. Порядок сортировки Порядок сортировки статуса (используется, в частности, при выводе выпадающего списка статусов). Присваивать данный статус всем новым документам по умолчанию Данный флаг позволяет присваивать редактируемый статус всем вновь создаваемым документам в случае, если статус не был явно указан. CSS класс для отображения заголовка статуса CSS класс для текста, которым будет выводиться заголовок статуса. Например, в таблице результатов или при просмотре, редактировании статуса при использовании шаблонов типа default.php . Файл-обработчик смены данного статуса на другой (либо удаление результата) Адрес файла-обработчика, который будет запускаться при смене статуса. Файл-обработчик смены какого-либо статуса на данный (либо добавление нового результата) Адрес файла-обработчика, который будет запускаться при смене какого-либо статуса на данный. * - Поля, обязательные для заполнения.
Закладка Доступ
Настройка прав групп пользователей на доступ к результатам, находящимся в данном статусе.
как подменить приходящий статус в событие и сохранить другой?
- Вопрос задан 12 мая 2021
- 522 просмотра
Сам обработчик. У меня в примере логика на смена статуса заказа для определенных служб. Ее можно переписать на что угодно. Основное это $event->addResult
Пример 100% рабочий. Взят с прода.Айнур Валиев, это была какая то бизнеслогика для конкретного проекта. Там может быть вообще какое угодно условие
Айнур Валиев, В Вашем проекте возможно так и есть. Повторюсь, это РАБОЧИЙ пример с сайта где работает именно так. Это часть бизнес логики и не имеет отношения к самому принципу изменения заказа на событии.
Yuriy, я только что так пробовал и ничего не зависает, ищи ошибку в коде до этого. Все закомментируй и оставь только четыре строки и увидишь, что все работает
PetrPo, вот полная версия
Yuriy, вопрос как звучит? как подменить приходящий статус в событие и сохранить другой?
Я тебе написал как это сделать, повторю еще раз. Оставь только эти строки в событии:Измени статус и увидишь что все работает. Если это так, то проблема в остальной твоей писанине, я в нее не вникал и дал ответ на поставленный вопрос.
Yuriy, ну давай тогда в угадайку поиграем, почему у тебя не работает. Открой в консоли network и посмотри, что в ответе приходит и на что ругается
PetrPo, ты понимаешь что такое зависание?? какой может быть ответ если всё висит. срабатывает timeout 504 getway.. в логе тоже нет ошибок ни в битриксе ни в nginx
Любите ли Вы динамическое обновление конфигураций так, как люблю его я? Обожаю что-нибудь с его помощью пропатчить на продакшене! Особенно в пятницу! Вечером! Перед майскими праздниками! Без предупреждения!
На самом деле нет! Динамическое обновление с одной стороны выглядит отличным механизмом платформы 1С, который позволяет вносить изменения в конфигурации "на лету". Главное, чтобы изменения не затрагивали структуру базы данных, в противном случае придется выполнять обновление монопольно и "выгонять" пользователей.
Согласитесь, при появлении ошибки в коде после очередных изменений просто берешь и обновляешь базу "на горячую" и никаких проблем! Главное всем, кому нужны были эти изменения, перезапустили сеанс и изменения вступят в силу!
С другой стороны может что-то пойти не так и Вы найдете небольшую, но весомую порцию багов у себя.
И никакие отговорки, что это были изменения для ТОП-менеджеров Вам не помогут!
Но как же так! Вы пользуетесь динамическим обновлением и у Вас нет никаких проблем? Коллеги рассказывают страшные истории, но Вы им не верите? "Просто они плохие 1Сники!", думаете Вы?
Контекстная панель формы
Кнопка Описание Параметры формы Переход на страницу редактирования параметров веб-формы. Результаты Переход на страницу со списком результатов заполнения веб-формы. Вопросы Переход на страницу со списком вопросов веб-формы. Поля Переход на страницу со списком полей веб-формы. И это все?
Такая ошибка вас не остановит? Говорите, что ну и ладно, что в конфигуратор не вошли, зато клиенты работают, а с конфигуратором бы разобрались? Ведь решения есть на просторах интернета!
Хорошо, а как вам такой же "обрыв" соединения на этапе обновления данных в таблице "Params". Сделаем другой триггер (отключите только предыдущий):
При попытке обновления записи "DynamicallyUpdated" в таблице "Params" мы получим падение. Конфигуратор закроется системной ошибкой. Не страшно, скажите Вы! Но в этот же момент все клиентские соединения также вылетят, причем с разными ошибками. Например, с такой.
А при попытке перезапустить клиентский сеанс, также будут происходить различные ошибки. Никто не сможет работать с информационной базой!
Но и тут не все потеряно!
Клиентские сеансы не могут зайти в базу, их всех выкинуло и так далее! Но мы все еще можем в большинстве (но не во всех) случаев зайти в конфигуратор! И при повторном обновлении также в большинстве (но не во всех) случаях мы восстановим работу информационной базы!
Итог, все вылетели из базы, мы словили адреналина, и восстановили работу после штатного повторного обновления. Вас и это не убедило, что динамическое обновление очень опасно?
Контекстная панель формы
Кнопка Описание Параметры формы Переход на страницу редактирования параметров веб-формы. Результаты Переход на страницу со списком результатов заполнения веб-формы. Вопросы Переход на страницу со списком вопросов веб-формы. Поля Переход на страницу со списком полей веб-формы. Как работает динамическое обновление
Наверное это странный вопрос, ведь ответ лежит на поверхности - это механизм позволяет обновить конфигурацию базы данных без остановки ее работы, внося изменения не требующие модификации на уровне базы данных. В официальной документации на ИТС есть информация в каких случаях платформа позволяет провести динамическое обновление. Вроде все просто. Но что если пойти дальше.
В любой информационной базе есть таблицы "Config" и "ConfigSave". Назначение этих таблиц также известно:
- Config - содержит основную конфигурацию информационной базы, которая соответствует актуальной структуре базы данных и используется активными сеансами.
- ConfigSave - содержит сохраненную конфигурацию. Ту самую, которую Вы редактируете в конфигураторе. Как только Вы нажимаете "Сохранить", все измененные объекты и связанная информация записывается именно сюда. После запуска обновления информационной базы все изменения из этой таблицы переносятся в таблицу Config. Если же выполнить команду "Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД", то вся информация об изменениях в этой таблице удалится.
Все просто, не так ли? Но пойдем еще дальше. Посмотрите на структуру таблиц для хранения данных конфигурации.
Структура таблиц идентична.
Описание полей такое:
- FileName - строка длиной 128, используется для хранения имени "файла", это некоторая часть конфигурации.
- Creation - дата создания записи.
- Modified - дата модификации записи.
- Attributes - целое число, назначение которого сейчас нет смысла рассматривать (на самом деле я точно не могу утверждать, только предполагаю зачем оно нужно. Но если Вы знаете, то напишите в комментариях).
- DataSize - размер данных в байтах, хранящийся в поле "BinaryData"
- BinaryData - непосредственно данные конфигурации.
- PartNo - номер части. Иногда размер данных объекта метаданных может быть очень большим и платформа его разбивает на части.
То есть конфигурация хранится некоторыми блоками. Вообще, структура хранения конфигурации в таблице базы соответствует тому, как устроена внутренняя структура форматом файлов CF. Подробнее об этом Вы можете узнать в отличной статье "Описание формата файлов конфигурации (CF, EPF, ERF)" от Андрея Овсянкина.
Со структурой таблиц и их назначением понятно. Пойдем дальше.
Когда Вы начинаете процесс обновления информационной базы, на первом этапе платформа 1С выполняет множество служебных действий, останавливаться на которых сейчас особо нет смысла. Самое интересное начинается после того, как Вы нажимаете заветную кнопку "Обновить динамически".
Среди множества служебных действий, платформа переносит данные об объектах из таблицы ConfigSave в Config:
В следующий раз, когда информационная база будет обновляться в обычном режиме, записи об объектам, созданных при динамическом обновлении, будут удалены и останутся только основные записи с актуальными данными конфигурации.
Это очень поверхностное описание и сам процесс имеет множество особенностей как со стороны работы БД, так и со стороны работы клиентских приложений платформы 1С. Но суть должна быть понятной.
Читайте также: