Программное получение стека вызовов для поиска точек входа

13.06.23

Задачи пользователя - Адаптация типовых решений

Получение информации о точке входа в процедуру записи справочника.

Всем доброго времени суток!

Немного предыстории. На новом месте работы возникла проблема с размножением договоров контрагентов в системе "Бухгалтерия предприятия" (ред. 3.0.134.23). Было известно только то, что договора создаются автоматически при загрузке документов из других систем с использованием внешних обработок.

На мой взгляд было 2 варианта решения задачи: 1. бегать по пользователям и выпытывать что и откуда они грузят, после чего анализировать код во всех используемых обработках; 2. что-нибудь придумать чтобы автоматизировать сбор данных для последующего анализа. Я выбрал второй путь. Логика была следующей:

  • в справочник добавляем дополнительный строковый реквизит (я его назвал "CreatInfo");
  • используя в расширении подписку (решил использовать подписку с составным типом источника, т.к. необходимо было организовать данный механизм для нескольких справочников), обрабатываем событие "ПередЗаписью";
  • при создании нового договора, помимо записи даты и времени формирования, добавляем информацию о точке входа в процедуру.

Вся проблема заключалась в получении точки входа в процедуру, чтобы определить с какой обработки осуществляется формирование договоров. В процессе "загугливания" информации наткнулся на статью: //infostart.ru/1c/articles/1263068/. Автору большое спасибо за идею.

Т.к. явной процедуры получения данных стека нет и доступно только текстовое представление ошибки, в котором будет содержаться информация стека вызовов, сэмулировал через попытку - исключение ошибку, и в "исключении" обработал текст, получив необходимые строки.

Процедура "СправочникиПередЗаписью" вызывается из добавленной в расширение подписки на события.

Процедура СправочникиПередЗаписью(Источник, Отказ) Экспорт
	ТипИсточника = ТипЗнч(Источник);
	Если ТипИсточника = Тип("СправочникОбъект.ДоговорыКонтрагентов") Или
		ТипИсточника = Тип("СправочникОбъект.Контрагенты") Тогда
		
		ДобавитьИнформациюСозданияЭлемента(Источник);
		
	КонецЕсли;
КонецПроцедуры

Процедура ДобавитьИнформациюСозданияЭлемента(Источник)
	Если Не Источник.ЭтоНовый() Тогда
		Возврат;
	КонецЕсли;
	
	Свойство_CreatInfo = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоРеквизиту("Имя", "CreatInfo");
	Если Не ЗначениеЗаполнено(Свойство_CreatInfo) Тогда
		Возврат;
	КонецЕсли;
		
	Попытка
		Ошибка = 1 / 0;
	Исключение
		
		//Отсекаем лишний текст
		ПоследнееМестоВызова	= СтрЗаменить(ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()), "Деление на 0", "");
		ПоследнееМестоВызова	= Сред(ПоследнееМестоВызова, Найти(ПоследнееМестоВызова, ")}:ДобавитьИнформациюСозданияЭлемента(Источник);"), СтрДлина(ПоследнееМестоВызова));		
		ПоследнееМестоВызова	= СокрЛП(СтрЗаменить(ПоследнееМестоВызова, ")}:ДобавитьИнформациюСозданияЭлемента(Источник);", ""));
		
		СтрокаТаблицы			= Источник.ДополнительныеРеквизиты.Добавить();
		СтрокаТаблицы.Свойство	= Свойство_CreatInfo;
		СтрокаТаблицы.Значение	= "Дата создания: '" + Формат(ТекущаяДата(), "ДЛФ=DT") + "'" + Символы.ПС +
									"Пользователь: '" + Пользователи.АвторизованныйПользователь() + "'" + Символы.ПС +
									"Точка входа: '" + ?(ПустаяСтрока(ПоследнееМестоВызова), "Ручное формирование", ПоследнееМестоВызова) + "'";		
		
	КонецПопытки;	
КонецПроцедуры

 

Т.о. эта небольшая доработка сэкономила кучу времени, позволив четко определить откуда приходила проблема, т.к. в элементах справочника стала отражаться информация о их создании:

 

 

Надеюсь, кому-либо пригодится. Всем успехов!

стек стэк программное программно получить получение вызов вызовов вход входа точка

См. также

Адаптация типовых решений Платформа 1С v8.3 1С:Документооборот Россия Платные (руб)

Расширение конфигурации для «1С:Документооборот КОРП», редакция 3.0. позволяет: 1.использовать произвольные табличные части в качестве дополнительных реквизитов к документу; 2 использовать произвольные табличные части в шаблонах в формате docx для автоматического заполнения таблиц.

29400 руб.

29.06.2023    5164    11    5    

20

Логистика, склад и ТМЦ Адаптация типовых решений Пользователь Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)

Чтобы не допустить путаницы с обещаниями клиентам и для четкого контроля исполнения заказов мы используем резервирование товаров. Мы доработали УНФ, чтобы она автоматически отменяла старые резервы и не мешала эффективно продавать.

7200 руб.

02.08.2023    3538    8    0    

27

Адаптация типовых решений Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Абонемент ($m)

Каждый из нас сталкивается с ситуацией, когда какой-нибудь менеджер показывает свой Excel и рассказывает, как он что-то из 1С копирует в него, снабжает пояснениями, выделяет цветом и т.д. и т.п. Заканчивается все просьбой сделать вот чтобы также было в 1С. И оказывается такой человек (почти с гарантией) либо лучшим продажником, либо каким-то важным, за все отвечающим, - на ком все держится.

2 стартмани

22.04.2024    4738    dimanich70    15    

20

БСП (Библиотека стандартных подсистем) Адаптация типовых решений Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Понадобилось в подменю "Создать на основании" добавить свою команду, которая открывает обработку. В процессе доработок появилась проблема двух подменю "Создать на основании". В статье о том, как решились проблемы.

01.03.2024    3669    dimanich70    8    

16

Адаптация типовых решений Программист Платформа 1С v8.3 1С:Управление торговлей 11 Россия Абонемент ($m)

Доработка типового отчета "Связанные документы" позволяет просто и быстро расширять состав объектов для построения структуры подчиненности документов, используя объекты основной конфигурации и любых расширений.

1 стартмани

27.10.2023    2806    21    avmartynov    14    

53
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Xershi 1506 13.06.23 16:52 Сейчас в теме
Хороший лайфхак, возьму на заметку!
Плавающие ошибки будет легко отловить!
Nikolay_Vld; DrAku1a; Plotks2017; cheiser1982; +4 Ответить
2. Nikola23 700 13.06.23 17:23 Сейчас в теме
Тут на форумах говорят, что получение полного стека вызовов - нагружает систему.
Сам не проверял, но источникам верю.

Какой объем данных в день перезаписывается и логируется таким образом?
Хочется оценить снижение производительности.
3. cheiser1982 222 14.06.23 07:09 Сейчас в теме
(2) в моем случае потери производительности несущественные, т.к. во-первых выполняется порционный переброс данных, во-вторых получение данных стека происходит лишь при записи нового элемента справочника, что происходит не так часто. Да и наконец после обнаружения проблемы данный механизм можно отключить.
5. Vladimir-R 168 14.06.23 09:09 Сейчас в теме
(3) может быть стоит добавить константу для включения/выключения данного механизма при необходимости использования?
7. cheiser1982 222 14.06.23 09:26 Сейчас в теме
(5) это уже на ваше усмотрение. Лично у меня все выполнено в расширении для быстрого исправления багов и ловли плавающих ошибок. Т.к. оно обновляется ежедневно, заморачиваться насчет включения/отключения не стал.
4. milkers 2893 14.06.23 08:37 Сейчас в теме
Лайфхак года! Огромное спасибо.
A_Artem; ixijixi; ayarov; cheiser1982; +4 Ответить
6. SpiegelWiegel 6 14.06.23 09:16 Сейчас в теме
Спасибо за отличную идею!)
8. booksfill 14.06.23 09:41 Сейчас в теме
Если надо таким образом находить проблемы, наверное, лучше не добавлять никаких реквизитов, а писать в обычный текстовой файл,
Заодно добавляя в лог данные по тек. пользователю и машине.

Тогда не придется как-то обрабатывать сообщение об ошибке - вырезая из него лишние фрагменты.
Читаться будет нормально, да и полный стек может пригодиться.

Таким образом, даже если случайно кто-то что-то массово начнет делать с данными база не ляжет.
EliasShy; JohnyDeath; cheiser1982; +3 Ответить
18. AntonProgma 47 14.06.23 14:28 Сейчас в теме
(8) в этом случае нужно параллельно работать с одним файлом лога от имени разных пользователей?
19. booksfill 14.06.23 15:29 Сейчас в теме
(18)
в этом случае нужно параллельно работать с одним файлом лога от имени разных пользователей?


Открываете файл пока не откроется, на случай, если запись совпадет до миллисекунд, потом пишете.

Если на сервере, то будете работать под тем пользователем под которым он запущен, если на клиенте, то под текущим пользователем (точнее под владельцем сеанса).

Это не привносит лишние сущности в виде реквизитов или отдельных таблиц/регистров.

Если вы не боитесь разбухания журнала регистрации и согласны долго, нет, ДОЛГО, ждать пока он соизволит отобраться по нужным событиям, то можете писать и туда. Он как бы для такого также предназначен.

Кстати, могу ошибаться, но именно тормоза при записи заставили вести журнал регистрации в "старом" формате, вместо молодежной записи в базу.
9. webester 26 14.06.23 09:56 Сейчас в теме
Какой смысл писать куда либо отладочную информацию кроме как в журнал регистрации?
user1455510; +1 Ответить
10. kser87 2454 14.06.23 10:26 Сейчас в теме
Вот это лайфхак. Очень крутая идея
maksa2005; +1 Ответить
11. binx 172 14.06.23 10:43 Сейчас в теме
Лайфхак интересный, но может проще в данном конкретном случае, при записи договоров проверять договора на дубли и не создавать такие договоры с выдачей ошибки, тогда пользователи сами прибегут с обработкой.
12. cheiser1982 222 14.06.23 11:29 Сейчас в теме
(11) возможно справедливо для небольшой компании, где 1 или 2 бухгалтера, которые адекватно реагируют на любую нештатную ситуацию и никуда не торопятся. )) Однако если у тебя с десяток организаций, раскиданных по различным регионам нашей необъятной Родины и плюс в каждом регионе по сети магазинов и все это объединено в единую базу, то когда у кучи бухгалтеров одновременно встает загрузка данных и тебе нужно со всем этим оперативно разобраться, ваш вариант не кажется рациональным. Я дорожу своими нервами и психическим здоровьем... ))
maksa2005; user591389_aska_rabota; artbear; +3 Ответить
13. binx 172 14.06.23 11:35 Сейчас в теме
(12)
Согласен ситуации бывают разные, но все таки предусмотреть чтобы дубли договоров не плодились стоит
17. webester 26 14.06.23 13:16 Сейчас в теме
(12)Особенно если две разных операции могут менять объект, а видишь ты только последнее изменение, эта фича мало того, что увеличивает время записи объекта, так еще и становится бесполезной.
14. sapervodichka 6865 14.06.23 12:22 Сейчас в теме
"Автору большое спасибо за идею" - не за что, приятно, что оценил + 1
BomjBandit; G_116449793522595596167; cheiser1982; +3 Ответить
15. NiGMa 14.06.23 12:42 Сейчас в теме
Снимаю шляпу и неистово аплодирую!!!
maksa2005; +1 Ответить
16. Pawlick 10 14.06.23 12:57 Сейчас в теме
Осталось вынести в отдельную функцию, что то типа ПолучитьТехническиеДеталиОперации()
Потом добавить расширение, в него добавить общий модуль ОбщегоНазначенияКлиентСервер(), и вынести функцию туда.
В качестве результата возвращать структуру с нужными полями))
Светлый ум; +1 Ответить
20. PerlAmutor 130 14.06.23 18:20 Сейчас в теме
Так чем история то закончилась, почему дублировались договоры?
21. Grigoriy251 116 16.06.23 08:41 Сейчас в теме
Интересно, а данные для отлова загрузки объектов из сервисов (xml, json) он запишет в журнал?
22. roman72 384 16.06.23 13:01 Сейчас в теме
"Лайфхак" в этой статье решает проблему постфактум, а не априори.
Если первоисточник данных с договорами "другие системы", то кардинальным решением проблемы было бы
1) Объявить какую-то систему первоисточником договоров и "договоров" (всяких там счетов и соглашений, которые регистрируются как договора в справочнике Договоров). И вносить договора вначале только туда.
2) Реализовать рассылку договоров по другим системам на основе уникального кода/guid

Собственно задача о правильной организации работы с НСИ в системе.
28. cheiser1982 222 19.06.23 06:14 Сейчас в теме
(22) полностью согласен насчет подхода с ГУИДами. Однако у нас не все так однозначно ). В управленческой системе ведется множество договоров с различными условиями и периодами действия. Но в бухгалтерском учете эти данные не нужны. Важно лишь различие на договор с поставщиком/покупателем, ну и плюс валюта. Соответственно договора в бухгалтерию залетают именно по вышеуказанным ключевым реквизитам. Такой принцип учета организован еще с 2012 года и что-либо перестраивать касаемо данного НСИ считаю не рациональным.
33. roman72 384 19.06.23 10:04 Сейчас в теме
(28) А и не надо ничего перестраивать.
Конечно, со стороны это выглядит как бардак бухгалтерии в учёте договоров, но не наше программистское дело осуждать дела в палате умалишённых.
А так ситуация выглядит как формирование отношений один-ко-многим. Один договор в БУ равен нескольким договорам УУ.
Т.е., условно говоря десять реквизитов договора в УУ сливаются в два реквизита договора в БУ. Т.е. есть два реквизита для свёртки.
Значит на пути перед загрузкой в базу БУ и в другие системы (не первоисточники договоров) должна быть таблица мэппинга, где хранится соответствие один-ко-многим.
Один гуид БУ равен нескольким гуидам УУ.
cheiser1982; +1 Ответить
23. milkers 2893 16.06.23 16:21 Сейчас в теме
(344) Людям свойственны ошибки. Конечно проектировать систему надо с умом. Но в больших организациях трудятся сменяя друг друга сотни программистов. Часто проблема выявляется когда уже нет документации или уже никто и не помнит реализацию всех обменов данными и все места где что-нибудь может быть создано или затерто. И иметь волшебную палочку, что-б БЫСТРО найти источник проблемы - это просто может быть спасением.
artbear; cheiser1982; +2 Ответить
24. milkers 2893 16.06.23 16:26 Сейчас в теме
(17) Тут главное - идея. Ничего не мешает создать регистр и писать в него версии и стек протоколов. Что-б сэкономить ресурсы, можно писать не все изменения объекта и все реквизиты, а только проблемные реквизиты (в ситуации когда затирается реквизит) для только проблемного подмножества объектов.
cheiser1982; +1 Ответить
25. webester 26 16.06.23 18:09 Сейчас в теме
(24)
Ничего не мешает создать регистр и писать в него версии и стек протоколов

И прийти в итоге к истории версий которая уже есть в платформе.
Тут главное - идея.

Нет тут главное, что было причиной для поиска такой идеи?. Понятно что ты не напишешь в статье: "у меня такая хня в базе, что я не могу разобраться кто постоянно меняет данные приходится изворачиваться и при каждой записи ловить стек, чтобы хоть что-то понять" разумеется, что такие костыли приходится изобретать не от хорошей жизни.
26. milkers 2893 16.06.23 22:33 Сейчас в теме
(25) История версий не пишется, если запись происходит в режиме обмена данными.
34. artbear 1558 19.06.23 11:44 Сейчас в теме
(26)
История версий не пишется, если запись происходит в режиме обмена данными.

Неужели это верно?

ИМХО мы юзаем историю версию для объектов с программным созданием, кажется, что история все-таки ведется для всех изменений.
36. milkers 2893 19.06.23 11:52 Сейчас в теме
(34) Не путай программное создание и создание в режиме обмена. Я говорю по памяти, 100 проц. про текущие релизы не скажу. Но как то добавлял запись реквизитов, которые хранятся в другом регистре и только выводятся на форму документа в историю изменений и столкнулся с таким.
29. cheiser1982 222 19.06.23 06:28 Сейчас в теме
(25) мы к сожалению живем не в идеальном мире, где все доработки описаны, настроена логически правильная структура бизнес процессов и каждый пользователь знает и понимает что он делает. Соответственно порой возникают ошибки, которые достаточно сложно отловить простой отладкой либо другими типовыми методами. Вот и приходится придумывать так называемые "костыли".
Насчет причины - я в самом начале описал что меня на это сподвигло.
И по поводу включения истории версий - это бы не решило проблему, т.к. мне необходимо было отловить точку входа в процедуру записи элемента именно при его создании, а история версий может лишь помочь определить кто и когда изменял те или иные реквизиты.
30. webester 26 19.06.23 06:43 Сейчас в теме
(29)Возможно мои ответы были неправильно прочитаны. Или неправильно поняты. Или и то и другое. Кратко перечислю основные тезисы:
1. Отладочная инфа должна быть в журнале регистрации, а не перемешиваться с данными. Это правило справедливо для разных систем, включая 1С. Один из примером почему так, следующим пунктом.
2. Если больше одного обработчика изменяют данные, высокая вероятность получить искаженные данные. Например: Обработчик1 изменяет реквизит1. Потом Обработчик2 изменяет реквизит2 или вообще не изменяет ничего а просто записывает объект и затирает инфу об том, кто изменил реквизит1. В результате мы не то, что не можем получить ответ кто изменил реквизит1, мы получим неверную информацию.
3. Любые логи должны вести обработчики которые делают исправления, но никак не сами объекты. Да конечно проще воткнуть единую подписку на все случаи жизни, но при работе обработчика, есть возможность записать в лог контекст. Почему был записаны именно такие данные и откуда они взялись.
мы к сожалению живем не в идеальном мире,

Поэтому, предлагаю не множить хаос, а делать сразу хорошо, а не как проще всего в текущей ситуации. И уж тем более не учить других лепить вот такие вот.. кхм... костыли решения.
31. cheiser1982 222 19.06.23 07:24 Сейчас в теме
(30)
Поэтому, предлагаю не множить хаос, а делать сразу хорошо, а не как проще всего в текущей ситуации. И уж тем более не учить других лепить вот такие вот.. кхм... костыли решения.

Я не понимаю к чему вся эта демагогия. Суть статьи заключается в том, чтобы показать людям что есть возможность программно получить данные стека. И все это как раз и делается для выяснения причины возникновения ошибки и устранения хаоса. А какова реализация данной идеи будет, это уже разработчику решать. Для меня рациональнее, удобнее и проще использовать именно такой подход. Если вы считаете что корректней фиксировать отладочную информацию в журнале - ради бога.
И о каких обработчиках вы речь ведете? У меня задача состоит в получении данных при создании элемента а не при каждом изменении и записи. Читайте внимательней.
milkers; artbear; +2 Ответить
32. webester 26 19.06.23 07:36 Сейчас в теме
(31)
Я не понимаю к чему вся эта демагогия

Я так и думал что мы перейдем к аргументам в духе "сам дурак" и "а мне удобно и так". Но надеялся, что этого не произойдет. Ну ок, если детали не важны то статью нужно сократить до: "искусственно вызовите ошибку и перехватите исключение, в том месте где вам удобно". Основная идея услышана нее была - вы защищаете "свое болото"(не в смысле, что идея болото, а в смысле что свое)
(31)
Если вы считаете что корректней фиксировать отладочную информацию в журнале - ради бога.

Мы с этого разговор и начали когда дошли до версий. Я говорю, что если в вашем частном случае это допустимая погрешность, зачем вы учите плохому людей у которых это вполне может быть не так? В своей базе вы конечно вольны хоть регистр накопления реализовать табличными частями справочника. Никто не против конечно.
И о каких обработчиках вы речь ведете?
Обработчик, хендлер, код, который делает запись.
35. artbear 1558 19.06.23 11:48 Сейчас в теме
(32) Поставил минус к ответу.
Причина - Зачем разводить холивар по задаче, которая косвенно касается проблемы из публикации?

публикация описывает интересное решение проблемы, которое позволяет разобраться с инцидентами на стороне автора, достаточно быстро и комфортно.

понятно, что в общем случае стоит переделать систему создания договоров, их появления и т.д., но эта история дорогая и вдолгую.

давайте не уходить в сторону мисты - тебе это не нужно, зачем это делать и т.п.
shoy; maksa2005; milkers; cheiser1982; +4 Ответить
27. webester 26 18.06.23 08:35 Сейчас в теме
(26) Ну это записано в обработчике, Если надо, будет писаться. Если мы говорим про подсистему версии объектов. По истории данных точно сказать не могу, не было возможности пощупать, но там тоже вроде как пишутся любые изменения.
37. devtelscargo 21.03.24 16:24 Сейчас в теме
Аналогичная тема: https://infostart.ru/1c/articles/1263068/
только комменты поинтереснее
Оставьте свое сообщение