Программное получение стека вызовов для поиска точек входа
Задачи пользователя - Адаптация типовых решений
Всем доброго времени суток!
Немного предыстории. На новом месте работы возникла проблема с размножением договоров контрагентов в системе "Бухгалтерия предприятия" (ред. 3.0.134.23). Было известно только то, что договора создаются автоматически при загрузке документов из других систем с использованием внешних обработок.
На мой взгляд было 2 варианта решения задачи: 1. бегать по пользователям и выпытывать что и откуда они грузят, после чего анализировать код во всех используемых обработках; 2. что-нибудь придумать чтобы автоматизировать сбор данных для последующего анализа. Я выбрал второй путь. Логика была следующей:
- в справочник добавляем дополнительный строковый реквизит (я его назвал "CreatInfo");
- используя в расширении подписку (решил использовать подписку с составным типом источника, т.к. необходимо было организовать данный механизм для нескольких справочников), обрабатываем событие "ПередЗаписью";
- при создании нового договора, помимо записи даты и времени формирования, добавляем информацию о точке входа в процедуру.
Вся проблема заключалась в получении точки входа в процедуру, чтобы определить с какой обработки осуществляется формирование договоров. В процессе "загугливания" информации наткнулся на статью: //infostart.ru/1c/articles/1263068/. Автору большое спасибо за идею.
Т.к. явной процедуры получения данных стека нет и доступно только текстовое представление ошибки, в котором будет содержаться информация стека вызовов, сэмулировал через попытку - исключение ошибку, и в "исключении" обработал текст, получив необходимые строки.
Процедура "СправочникиПередЗаписью" вызывается из добавленной в расширение подписки на события.
Процедура СправочникиПередЗаписью(Источник, Отказ) Экспорт
ТипИсточника = ТипЗнч(Источник);
Если ТипИсточника = Тип("СправочникОбъект.ДоговорыКонтрагентов") Или
ТипИсточника = Тип("СправочникОбъект.Контрагенты") Тогда
ДобавитьИнформациюСозданияЭлемента(Источник);
КонецЕсли;
КонецПроцедуры
Процедура ДобавитьИнформациюСозданияЭлемента(Источник)
Если Не Источник.ЭтоНовый() Тогда
Возврат;
КонецЕсли;
Свойство_CreatInfo = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоРеквизиту("Имя", "CreatInfo");
Если Не ЗначениеЗаполнено(Свойство_CreatInfo) Тогда
Возврат;
КонецЕсли;
Попытка
Ошибка = 1 / 0;
Исключение
//Отсекаем лишний текст
ПоследнееМестоВызова = СтрЗаменить(ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()), "Деление на 0", "");
ПоследнееМестоВызова = Сред(ПоследнееМестоВызова, Найти(ПоследнееМестоВызова, ")}:ДобавитьИнформациюСозданияЭлемента(Источник);"), СтрДлина(ПоследнееМестоВызова));
ПоследнееМестоВызова = СокрЛП(СтрЗаменить(ПоследнееМестоВызова, ")}:ДобавитьИнформациюСозданияЭлемента(Источник);", ""));
СтрокаТаблицы = Источник.ДополнительныеРеквизиты.Добавить();
СтрокаТаблицы.Свойство = Свойство_CreatInfo;
СтрокаТаблицы.Значение = "Дата создания: '" + Формат(ТекущаяДата(), "ДЛФ=DT") + "'" + Символы.ПС +
"Пользователь: '" + Пользователи.АвторизованныйПользователь() + "'" + Символы.ПС +
"Точка входа: '" + ?(ПустаяСтрока(ПоследнееМестоВызова), "Ручное формирование", ПоследнееМестоВызова) + "'";
КонецПопытки;
КонецПроцедуры
Т.о. эта небольшая доработка сэкономила кучу времени, позволив четко определить откуда приходила проблема, т.к. в элементах справочника стала отражаться информация о их создании:
Надеюсь, кому-либо пригодится. Всем успехов!
Вступайте в нашу телеграмм-группу Инфостарт
стек стэк программное программно 1С получить получение вызов вызовов вход входа точка
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Разработка Адаптация типовых решений Производство готовой продукции (работ, услуг) Розничная торговля 1С:Управление торговлей 10 Россия Платные (руб)
Доработка для 1С:Управление торговлей 10.3 (релиз 10.3.88.3) добавляет поддержку маркировки новых категорий товаров согласно постановлениям Правительства РФ 2025–2026 гг. Конфигурация УТ 10.3 снята с поддержки — новые маркируемые категории в типовую поставку больше не попадают. Доработка закрывает этот пробел: новые виды номенклатуры, обмен с ГИС МТ «Честный Знак». Поставляется в виде файла .cf
14640 руб.
23.04.2026 5276 49 13
Банковские операции Адаптация типовых решений Бухгалтер Пользователь 1С:Предприятие 8 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)
Решение позволяет автоматически заполнять отдельные реквизиты загружаемых банковских документов, основываясь на известных значениях реквизитов и тексте назначения платежа. Простая настройка, широкие возможности анализа назначения платежа без написания кода и сложных шаблонов.
12200 руб.
17.06.2025 5284 15 0
Логистика, склад и ТМЦ Адаптация типовых решений Пользователь 1С:Предприятие 8 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)
Чтобы не допустить путаницы с обещаниями клиентам и для четкого контроля исполнения заказов мы используем резервирование товаров. Расширение для УНФ, чтобы автоматически отменять старые резервы и не мешалть эффективно продавать.
9150 руб.
02.08.2023 8956 27 5
Печатные формы Адаптация типовых решений Бухгалтер Пользователь 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)
Расширение позволяет вывести в табличном документе факсимиле печати и подписей и/или вывести произвольную картинку из прикреплённых файлов организации для 1С УТ 11.5, КА 2.5, ERP 2.5, УНФ 3, Розница 3. Вывод факсимиле возможен в табличные документы УПД, УКД, Счёт-фактура, ТОРГ-12 и другие. Возможно настроить вывод для любых типовых макетов (Акт сверки, М-15, ТТН), для этого потребуется отредактировать макет и разместить на нём картинки с соответствующими именами, при выводе на печать в размещённые картинки будут выводиться факсимиле из прикреплённых рисунков. Редактирование осуществляется через типовой механизм в пользовательском интерфейсе.
6000 руб.
07.02.2023 14483 122 25
Адаптация типовых решений Создание на основании Пользователь 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)
Расширение позволяет в 1 клик поставить весь состав заказа клиента в отгрузку и открыть заполненные формы документов отгрузки по заказу.
4880 руб.
25.08.2023 4305 9 0
Адаптация типовых решений 1С 8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)
Расширение, которое в форму списка и форму выбора справочника «Номенклатура» добавляет табличную часть в виде дерева, в которую выводится информация об остатках и доступности выбранной номенклатурной позиции.
6710 руб.
20.04.2026 961 1 0
Адаптация типовых решений БСП (Библиотека стандартных подсистем) Кадровый учет ЭДО и ОФД 1C:Бухгалтерия 1С:Зарплата и кадры 7.7 1C:ERP 1С:ЗУП 1С:УТ 1С:ДО Платные (руб)
Наше расширение 1С Госключ обеспечивает интеграцию любой конфигурации 1С на базе БСП с мобильным приложением «Госключ», позволяя сотрудникам подписывать кадровые документы (КЭДО) и документы материальной ответственности (МОЛ, ПБ) усиленной электронной подписью прямо со смартфона. Решение автоматизирует формирование и отправку документов на подпись, отслеживает статусы подписания и хранит подписанные файлы непосредственно в базе 1С
25000 руб.
06.03.2026 2728 4 0
Адаптация типовых решений 1С 8.3 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 Беларусь Россия Платные (руб)
Расширение "Дополнительные документы" предназначено для создания дополнительных документов различного назначения, как форм для внесения данных так и печатных форм в расширяемой конфигурации пользовательскими средствами, без работы в конфигураторе и внесения изменений в структуру данных. Тестировалось для "1С:БП", "1С:УНФ","1С:КА"
21859 руб.
29.12.2025 2152 1 8
Сам не проверял, но источникам верю.
Какой объем данных в день перезаписывается и логируется таким образом?
Хочется оценить снижение производительности.
Заодно добавляя в лог данные по тек. пользователю и машине.
Тогда не придется как-то обрабатывать сообщение об ошибке - вырезая из него лишние фрагменты.
Читаться будет нормально, да и полный стек может пригодиться.
Таким образом, даже если случайно кто-то что-то массово начнет делать с данными база не ляжет.
Открываете файл пока не откроется, на случай, если запись совпадет до миллисекунд, потом пишете.
Если на сервере, то будете работать под тем пользователем под которым он запущен, если на клиенте, то под текущим пользователем (точнее под владельцем сеанса).
Это не привносит лишние сущности в виде реквизитов или отдельных таблиц/регистров.
Если вы не боитесь разбухания журнала регистрации и согласны долго, нет, ДОЛГО, ждать пока он соизволит отобраться по нужным событиям, то можете писать и туда. Он как бы для такого также предназначен.
Кстати, могу ошибаться, но именно тормоза при записи заставили вести журнал регистрации в "старом" формате, вместо молодежной записи в базу.
Потом добавить расширение, в него добавить общий модуль ОбщегоНазначенияКлиентСервер(), и вынести функцию туда.
В качестве результата возвращать структуру с нужными полями))
Если первоисточник данных с договорами "другие системы", то кардинальным решением проблемы было бы
1) Объявить какую-то систему первоисточником договоров и "договоров" (всяких там счетов и соглашений, которые регистрируются как договора в справочнике Договоров). И вносить договора вначале только туда.
2) Реализовать рассылку договоров по другим системам на основе уникального кода/guid
Собственно задача о правильной организации работы с НСИ в системе.
Конечно, со стороны это выглядит как бардак бухгалтерии в учёте договоров, но не наше программистское дело осуждать дела в палате умалишённых.
А так ситуация выглядит как формирование отношений один-ко-многим. Один договор в БУ равен нескольким договорам УУ.
Т.е., условно говоря десять реквизитов договора в УУ сливаются в два реквизита договора в БУ. Т.е. есть два реквизита для свёртки.
Значит на пути перед загрузкой в базу БУ и в другие системы (не первоисточники договоров) должна быть таблица мэппинга, где хранится соответствие один-ко-многим.
Один гуид БУ равен нескольким гуидам УУ.
И прийти в итоге к истории версий которая уже есть в платформе.
Нет тут главное, что было причиной для поиска такой идеи?. Понятно что ты не напишешь в статье: "у меня такая хня в базе, что я не могу разобраться кто постоянно меняет данные приходится изворачиваться и при каждой записи ловить стек, чтобы хоть что-то понять" разумеется, что такие костыли приходится изобретать не от хорошей жизни.
Неужели это верно?
ИМХО мы юзаем историю версию для объектов с программным созданием, кажется, что история все-таки ведется для всех изменений.
Насчет причины - я в самом начале описал что меня на это сподвигло.
И по поводу включения истории версий - это бы не решило проблему, т.к. мне необходимо было отловить точку входа в процедуру записи элемента именно при его создании, а история версий может лишь помочь определить кто и когда изменял те или иные реквизиты.
1. Отладочная инфа должна быть в журнале регистрации, а не перемешиваться с данными. Это правило справедливо для разных систем, включая 1С. Один из примером почему так, следующим пунктом.
2. Если больше одного обработчика изменяют данные, высокая вероятность получить искаженные данные. Например: Обработчик1 изменяет реквизит1. Потом Обработчик2 изменяет реквизит2 или вообще не изменяет ничего а просто записывает объект и затирает инфу об том, кто изменил реквизит1. В результате мы не то, что не можем получить ответ кто изменил реквизит1, мы получим неверную информацию.
3. Любые логи должны вести обработчики которые делают исправления, но никак не сами объекты. Да конечно проще воткнуть единую подписку на все случаи жизни, но при работе обработчика, есть возможность записать в лог контекст. Почему был записаны именно такие данные и откуда они взялись.
Поэтому, предлагаю не множить хаос, а делать сразу хорошо, а не как проще всего в текущей ситуации. И уж тем более не учить других лепить вот такие вот.. кхм...
Я не понимаю к чему вся эта демагогия. Суть статьи заключается в том, чтобы показать людям что есть возможность программно получить данные стека. И все это как раз и делается для выяснения причины возникновения ошибки и устранения хаоса. А какова реализация данной идеи будет, это уже разработчику решать. Для меня рациональнее, удобнее и проще использовать именно такой подход. Если вы считаете что корректней фиксировать отладочную информацию в журнале - ради бога.
И о каких обработчиках вы речь ведете? У меня задача состоит в получении данных при создании элемента а не при каждом изменении и записи. Читайте внимательней.
Я так и думал что мы перейдем к аргументам в духе "сам дурак" и "а мне удобно и так". Но надеялся, что этого не произойдет. Ну ок, если детали не важны то статью нужно сократить до: "искусственно вызовите ошибку и перехватите исключение, в том месте где вам удобно". Основная идея услышана нее была - вы защищаете "свое болото"(не в смысле, что идея болото, а в смысле что свое)
(31)
Мы с этого разговор и начали когда дошли до версий. Я говорю, что если в вашем частном случае это допустимая погрешность, зачем вы учите плохому людей у которых это вполне может быть не так? В своей базе вы конечно вольны хоть регистр накопления реализовать табличными частями справочника. Никто не против конечно.
Причина - Зачем разводить холивар по задаче, которая косвенно касается проблемы из публикации?
публикация описывает интересное решение проблемы, которое позволяет разобраться с инцидентами на стороне автора, достаточно быстро и комфортно.
понятно, что в общем случае стоит переделать систему создания договоров, их появления и т.д., но эта история дорогая и вдолгую.
давайте не уходить в сторону мисты - тебе это не нужно, зачем это делать и т.п.
Что я делаю не так? У меня описанный способ не работает, стек ограничивается модулем в которым было вызвано исключение.... Полного стека нет.
1С:Предприятие 8.3 (8.3.27.1936), клиент-серверная архитектура (не файловая база).
Что сделал:
Расширение, в нем подписку на документ, событие "ПередЗаписью".
Обработчик: НашОбщийМодуль.ЗаписьОбъектаПередЗаписью
Код:
Процедура ЗаписьОбъектаПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
Попытка
а=1/0;
Исключение
ИнформацияОбОшибке = ИнформацияОбОшибке();
Текст = ОбработкаОшибок.ПодробноеПредставлениеОшибки(ИнформацияОбОшибке);
КонецПопытки;
КонецПроцедуры
Подскажите пожалуйста.
Рейтинг: 251
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1879817
Создание 13.06.23 15:30
Обновление 13.06.23 15:30
Просмотры 14995
Загрузки 0
Рейтинг
125
Комментарии 39
Код открыт Да
Рубрики Адаптация типовых решений
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1С:Бухгалтерия 3.0
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
