Контроль использования лицензий 1С, мы видим сколько реально утилизируется лицензий, так как они конкурентные, и принимаем решение о приобретении новых, если подходим к границе. Это позволяет более эффективно использовать бюджет.
Выявление неоптимальных алгоритмов, выкаченных при обновлении, но не являющихся ошибкой (сказывается на общей производительности), например из реальных кейсов:
Подтормаживание одного из методов API из-за кратного увеличения количества транзакций-записи в регистр сведений, по факту просто постоянно перезаписывались одни и те же данные.
Значительный объема передачи данных между сервером 1С и СУБД, при этом объем данных переданных между клиентом и СУБД не увеличивался: причина - неоптимальные настройки одного из отчетов СКД.
Выявление падений платформы (крах rphost) и сопоставление событий предшествующее этим падениям, повышение стабильности работы системы.
Быстрый поиск событий в логах, например кто поменял тот или иной документ.
Мониторинг ошибок, особенно в служебных сеансах (в фоновых заданиях и http-сервисах), с точки зрения бизнеса - раньше узнаем о проблемах, а не когда партнер скажет (если скажет), что функционал недоступен.
Так же на основании агрегированных данных можно понимать объем бизнес-транзакций, например количество созданных заказов покупателей, как показатель активности интернет покупателей, не на этапе "положили в корзину", а на этапе, что весь бизнес-процесс отработал.
Да, это один из вариантов. Думаю таким образом сделать парсинг технологического журнала.
С журналом регистрации могут быть сложности, так как он может быть как в текстовом варианте, так и в варианте SQL Lite. Плюс его структура так или иначе "подвижна" с изменением версии платформы. Поэтому выбрали нативно разбирать его. Дополнительная сложность во внешнем парсинге возникает, когда 1С развернута на нескольких серверах с включенной функциональной ролью "Сервис журнала регистрации".
То что на поверхности:
Контроль использования лицензий 1С, мы видим сколько реально утилизируется лицензий, так как они конкурентные, и принимаем решение о приобретении новых, если подходим к границе. Это позволяет более эффективно использовать бюджет.
Выявление неоптимальных алгоритмов, выкаченных при обновлении, но не являющихся ошибкой (сказывается на общей производительности), например из реальных кейсов:
Подтормаживание одного из методов API из-за кратного увеличения количества транзакций-записи в регистр сведений, по факту просто постоянно перезаписывались одни и те же данные.
Значительный объема передачи данных между сервером 1С и СУБД, при этом объем данных переданных между клиентом и СУБД не увеличивался: причина - неоптимальные настройки одного из отчетов СКД.
Выявление падений платформы (крах rphost) и сопоставление событий предшествующее этим падениям, повышение стабильности работы системы.
Быстрый поиск событий в логах, например кто поменял тот или иной документ.
Мониторинг ошибок, особенно в служебных сеансах (в фоновых заданиях и http-сервисах), с точки зрения бизнеса - раньше узнаем о проблемах, а не когда партнер скажет (если скажет), что функционал недоступен.
Так же на основании агрегированных данных можно понимать объем бизнес-транзакций, например количество созданных заказов покупателей, как показатель активности интернет покупателей, не на этапе "положили в корзину", а на этапе, что весь бизнес-процесс отработал.
Думаю, что список можно дополнять и дополнять :)
Да, это один из вариантов. Думаю таким образом сделать парсинг технологического журнала.
С журналом регистрации могут быть сложности, так как он может быть как в текстовом варианте, так и в варианте SQL Lite. Плюс его структура так или иначе "подвижна" с изменением версии платформы. Поэтому выбрали нативно разбирать его. Дополнительная сложность во внешнем парсинге возникает, когда 1С развернута на нескольких серверах с включенной функциональной ролью "Сервис журнала регистрации".