Обновлено: 07.01.2025

Кому подойдет информация: Администратор 1С, Системный администратор, Бухгалтер
Подойдет для конфигураций: Все типовые конфигурации 1С новых редакций

В данной публикации будет рассмотрено, как завершить работу пользователей в базах новых редакций, работающих в режиме управляемого приложения. Зачастую это необходимо, чтобы можно было выполнить операции, требующие монопольного режима базы (например, удаление помеченных на удаление объектов, выполнение тестирования и исправления базы). Тогда в базе остается активным только один пользователь, выполняющий такие операции.

Вообще необходимо стараться избегать необходимости завершать работу пользователей базы принудительно, а завершать работу пользователей стандартным закрытием сеансов работы. Т.к. каждое такое "выкидывание" пользователей из базы является по своей сути аварийным завершением работы с базой. И именно в такие аварийные завершения работы могут возникать или накапливаться ошибки (но не обязательно каждый раз) в пользовательских файлах, которые могут потом выражаться в нетиповом поведении 1С у отдельных пользователей, потребуется очистка кэша базы на отдельном рабочем месте. Но, когда других вариантов не остается, то приходится удалять активные сеансы работы пользователей принудительно.

Будет рассмотрено три момента: в файловой базе, а так же два варианта с использованием возможностей базы в режиме 1С:Предприятие и с помощью утилиты администрирования баз данных для серверного варианта базы. Понять, какой тип базы у Вас - файловый или серверный можно по ссылке.

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

Внимание: описанные ниже действия доступны для пользователей с полным набором прав!

1. Блокировка работы пользователей в файловой базе

Завершить работу пользователей в файловой базе не возможно из-за того, что платформенные механизмы 1С 8 это не позволяют сделать. Но возможно выполнить блокировку базы, установив таким образом монопольный доступ. При блокировке работа других пользователей прерывается до момента, пока блокировка не будет снята.

Для этого необходимо перейти в разделе "Администрирование" ("НСИ и администрирование" - в зависимости от конфигурации может быть такое название) по ссылке "Обслуживание", далее по ссылке "Блокировка работы пользователей". Блокировка базы устанавливается текущим пользователем. После нажатия на кнопку "Установить блокировку" сеансы других пользователей будут прерваны до момента снятия блокировки.

2. Завершение работы пользователей серверной базы в режиме 1С: Предприятие

Переходим в раздел "НСИ и администрирование" или "Администрирование" в зависимости от конфигурации базы 1С 8, далее переход по ссылке "Обслуживание".

Далее, как продемонстрировано на, объединенном изображении переход по ссылке "Активные пользователи" откроет одноименную форму списка работающих пользователей базы 1С. Выделяем несколько строк или отдельные и с помощью кнопки "Завершить сеанс" работа пользователей будет завершена.

3. Завершение работы пользователей серверной базы с помощью "Администрирования серверов 1С Предприятия"

Возможна такая ситуация, что доступ в базу оказался не возможен, например, из-за того, что закончились свободные лицензии. Поэтому завершить работу пользователей базы 1С 8 не получиться вышеописанным способом. Так же, если используется старая редакция конфигурации базы, то вышеописанные способы окажутся попросту невозможными в силу отсутствия функционала. Но это все же возможно сделать с помощью дополнительной возможности.

Этот вариант уже предполагает завершение работы пользователей не в режиме Предприятие или Конфигуратор, а с помощью дополнительной утилитой "Администрирование серверов 1С Предприятия". Поэтому важно, чтобы у пользователя уже не 1С, а операционной системы на компьютере или сервере было достаточно прав для работы с данной утилитой.

Находим базу в ветке "Кластер" - "Локальный кластер" - "Информационные базы" по имени базы и "Сеансы". Имя базы можно найти в "Справка" - "О программе", "Имя базы" или в списке запуска баз, внизу формы списка. Выделяются строки с отдельными сеансами работы или несколько подряд. Правой кнопкой мыши вызывается контекстное меню, в котором необходимо выбрать пункт "Удалить".

Согласится с предупреждением о том, что удаление сеанса может привести к потере не сохраненных изменений в справочниках и документах. Мера вынужденная, поэтому нажимается кнопка "ОК".

Успешным результатом будет исчезновение строк удаляемых сеансов пользователей из списка.

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

Методика расследования причин медленной работы операции на примере открытия управляемой формы

Для начала необходимо убедиться, что проблема стабильно воспроизводится (в одинаковых условиях) и что все пункты с описанием применения методики выполнены. Для этого можно сделать следующее:

Сбор и анализ стандартных данных

Разберем пример для операции открытия формы документа "Табель учёта рабочего времени".

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

Настройка технологического журнала на клиенте может быть такой:

Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 1С:Предприятие) мы в отдельном каталоге Client_Full увидим данные только клиентских приложений (хотя при этом подкаталоги других процессов тоже будут созданы, но они буду пустыми). Свойство Interface не собираем, так как оно дублируется более "человек читаемым" свойством IName (хотя даже последнее нам в данном примере не обязательно нужно).

После настройки технологических журналов и проверки корректности замера времени ОценкиПроизводительности БСП выполняем повторение операции с включенной отладкой.

Замеры времени средствами БСП будут выглядеть следующим образом:

Везде далее будем рассматривать верхний в этом списке замер от последнего повторения, его длительность 13,022 секунды.

Замер отладчиком конфигуратора изображен на следующем рисунке:

Как видно, сумма длительности всех строк, связанных с открытием формы составила всего 1,523 секунды.

'00010101' + ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000

а для миллисекунд взять остаток от деления на 1000 (то есть просто последние три цифры, обратите внимание на "779" на следующей картинке).

Точное время начала замера (минут:секунд.миллисекунд): 25:10.779

Точное время окончания замера (минут:секунд.миллисекунд): 25:23.801

Найдем теперь записи технологического журнала, соответствующие данному замеру, они будут примерно следующими:

Здесь видно, что соответствующий нашему замеру серверный вызов SCALL завершился примерно за 10,1 секунды, это соответствует интервалу между запросом VRSREQUEST и ответом VRSRESPONSE.
Причем время начала замера почти совпадает с началом вызова, то есть событием VRSREQUEST, что собственно ожидаемо, так как замер БСП начинается на клиенте и должен быть непосредственно перед командой открытия формы. А вот окончание вызова сервера случилось раньше, чем окончание замера, что значит, что эта разница во времени пришлась на часть работы клиентского приложения.

Итак, промежуточный итог по длительностям замеров разными способами показывает соответствие нашей ситуации ограничениям и выполнение неравенства: 1,5 < 10,1 < 13.

Стандартными инструментами не удается увидеть причину проблем низкой производительности работы (открытия) управляемой формы, поэтому воспользуемся следующими помощниками:

• Отладчик операционной системы: Windows Performance Recorder для сбора метрик и Windows Performance Analyzer для их визуализации и анализа;
• Анализатор сетевых протоколов Wireshark или прокси-сервер Fiddler Web Debugger.

Установим и запустим Windows Performance Recorder ("C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\WPRUI.exe"), укажем настройки:

После того, как их подготовили, перейдем в тонкий клиент 1С, откроем форму списка документов и непосредственно перед воспроизведением проблемной операции запустим сбор данных WPR (кнопка Start).

После открытия формы в тонком клиенте запись можно остановить и открыть ее для анализа. В открывшемся окне найдем по PID 5508 (его можно определить в диспетчере задач ОС или по логам ТЖ) наш тонкий клиент 1С и должны получить примерно следующую картинку:

По данным Windows Performance Analyzer видим, что у нас нет серьезной нагрузки по дискам, а поток тонкого клиента потребляет 100% ЦП на протяжении длительного времени вплоть до завершения замера.

Запомним этот результат и проанализируем траффик.

Запустим Wireshark и повторим проблемную операцию в тонком клиенте 1С:Предприятие с прямым подключением к серверу приложений 1С.

При сборе данных с помощью Wireshark (и отбору по пакетам с сервером-источником равным серверу приложений 1С:Предприятие) запуск открытия формы документа будет выглядеть примерно так:

Здесь каждая такая строка – это пакет (или если точнее, то "кадр", frame), который в свою очередь является частью общего большого пакета поверх протокола TCP (PDU – Protocol Data Unit). Если их сложить, получим пакет около 70 Кб. Стоит обратить внимание, что это будет размер с учётом сжатия, а если без него – то должны получить что-то около 2500 – 3500 Кб данных.

Устанавливаем и запускаем Fiddler, на панели инструментов ищем "Browse", выбираем любимый браузер и запускаем в нем необходимое нам приложение (информационную базу 1С:Предприятие). После запуска переходим в форму списка документов (готовимся воспроизвести сценарий), возвращаемся в Fiddler и включаем сбор траффика (кнопка F12), переходим в браузер и открываем форму документа. После её открытия сбор траффика можно отключить и заняться его анализом. Мы должны получить примерно следующее:

В данном дампе достаточно быстро находится относительно большой пакет искомого размера, выбираем его в списке слева, а в правой части окна переключаемся на страницу Inspectors, выбираем там просмотр заголовков (Headers), и так как у нас пакет является сериализованным json (Content-Type: application/json), то попросим Fiddler десериализовать его для нас.

После этого в окне предпросмотра отобразится древовидная структура ответа (response), которая передается с сервера на клиент и содержит так много данных. Далее нам необходимо проанализировать её и найти наиболее проблемные места. Может помочь кнопка Expand All, которая развернёт все элементы дерева, но это может занять некоторое время. Чтобы его сократить, сначала поймем, что именно нужно искать.

Подведем промежуточный итог:

• Проблем с медленной работой прикладного кода 1С или запросов нет.
• Большая часть времени открытия формы состоит из сетевого взаимодействия.
• Размер пакета с формой подозрительно велик.
• После получения пакетов имеем высокую утилизацию ЦП тонким клиентом 1С (или веб-клиентом).
• Потерянное время находится где-то между окончанием/началом работы прикладного кода 1С и сетевой передачей.

Из всех этих пунктов для нас наиболее полезным и требующим дополнительного анализа является тезис "Размер пакета с формой подозрительно велик".
Какие могут быть причины для такой ситуации? В общем случае их несколько:

• Сама по себе большая и сложная форма с большим количеством экранных элементов и реквизитов. Наверное, редкий и точно не очень правильный случай, лучше такого избегать на этапе проектирования систем.
• Простая форма, но много данных в реквизитах формы (включая данные объекта), в особенности:
  • Хранилище значения, Строка(0);
  • Большие коллекции (Таблица, Дерево, Список);
  • Произвольный тип (концентрация проблем).

  Так как наша проблема (у вас может быть по-другому) воспроизводится даже при очень небольшом количестве данных в ТЧ, и реквизитов у документа (т.е. объекта формы) совсем не много, то их мы не рассматриваем. Остаются реквизиты формы, не равные основному реквизиту "Объект".

  Среди них находится несколько реквизитов, имеющих произвольный тип. Могут выглядеть так:

  
  

  Сопоставляем эти данные с уже собранным ранее замером с помощью конфигуратора, и видим заполнение этих структур достаточно большим количеством элементов (например, можно 5059 в реквизите "СвойстваИзмерений").
  Снова вернемся к дампу траффика в Fiddler и найдем там элемент, отвечающий за параметры формы (response/props). Увидим там примерно следующее:

  
  

  И если развернем далее эти элементы, убедимся, что их там несколько тысяч, каждый из которых представляет собой вложенную структуру вида:

  
  

  Найдем прикладной код, заполняющий эти параметры, и убедимся, что данных там действительно достаточно много (2-3 Мб), и они представляют собой большое количество сложных вложенных структур.

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

  Выводы и рекомендации

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

  Для того чтобы оценить степень влияния всех факторов, которые имеют значения в этом процессе, можно сделать несколько тестов (замеров), изменяя эти факторы и оценивая корреляцию их значений и длительности. В нашем случае причиной проблем были структуры, хранящие данные справочников территорий и условий труда, поэтому изменяли количество этих элементов и пробовали замерять передачу с клиента на сервер этих данных (процедура ДанныеДляРедактированияВХранилище).

  В следующей таблице приведены результаты таких замеров в нашем примере. Сразу следует оговориться, что не стоит никаким образом рассматривать в ней абсолютные значения, так как это будет зависеть еще и от конфигурации компьютера, сети, версии платформы и многого другого, связанного именно с нашим примером. Для нас же важны зависимости и их характер (линейная, экспоненциальная и т.д.). Предлагаем вам проанализировать их самостоятельно (или даже повторить замеры на актуальной версии платформы в вашей среде).

  
  

  Принимая во внимание полученные таким образом данные, можно предложить следующие возможные пути решения:

  Методологически реализовать отправку POST-запроса в формате JSON на сайт не сложно, в написании исполнчемого кода может помочь любая из метологий по ссылке из списка ниже.

  1. Заголовки запроса

  
  

  В моем случае путем проверки уже на рабочем варианте запроса было установлено, что заголовок имеет значение. По возможности надо уточнять у php-программиста сайта заголовок. В моем случае программист ответил по поводу заголовков, что "я не разбираю заголовки, это делается автоматом в php", поэтому пришлось перебирать.

  Таким образом в Вашем случае может сложиться ситуция, что, возможно, придется перебирать из примерных вариантов, если иного не сообщит php-программист:

  
  

  ЗапросPOST . Заголовки . Вставить ( "Content-type" , "application/x-www-form-urlencoded" ); ЗапросPOST . Заголовки . Вставить ( "Content-type" , "application/x-www-form-urlencoded; charset=utf-8" ); ЗапросPOST . Заголовки . Вставить ( "Content-type" , "application/json" ); ЗапросPOST . Заголовки . Вставить ( "Content-type" , "application/json; charset=utf-8" );

  Возможны и другие варианты значения заголовка.

  2. Передача параметра запроса

  Я долго не мог понять выражение, которое мне предоставлял программист сайта, сопровождая фразами:

  Поэтому были попытки поместить в запрос JSON строку и так:

  ЗапросPOST . УстановитьТелоИзСтроки ( "mData=" + СтрокаJSON , КодировкаТекста . UTF8 , ИспользованиеByteOrderMark . НеИспользовать ); - как можно встретить в примерах по ссылкам выше

  , и так: ЗапросPOST . УстановитьТелоИзСтроки ( СтрокаJSON , КодировкаТекста . UTF8 , ИспользованиеByteOrderMark . НеИспользовать ); - т.е. просто СтрокаJSON в первом параметре метода УстановитьТелоИзСтроки().

  На все вышеуказанные попытки сайт возвращал ошибку с описанием "Пустой запрос". Помог тот же комментарий, который помог в случае с заголовками, там же в теме 1C и отправка POST запроса с JSON на сайт

  
  

  
  

  Он должен соответствовать кодировке на сайте. Уточнять у программиста или администратора сайта. В примерах так же встречался вариант "windows-1251" - но он оказался в данной ситуации настройки отправки POST запроса с JSON на сайт не актуальным.

  4. Декодирование JSON-ответа

  Готовой информации не нашлось. Поэтому пришлось, изучив Синтаксис помощник, реализовать рабочий код с использованием метода ОткрытьПоток() для ЧтенияJSON с указанием кодировки:

  Описание ошибки:
  Доработка правил обмена для односторонней выгрузки из базы конфигурации 1С: Управление торговлей ред.10.3 в базу конфигурации 1С: Бухгалтерия прдприятия, ред.3.0.

  Для подобного рода доработки традиционно были взяты правила конвертации из УТ 10.3 в БП 3.0, предназначенные для выгрузки, инициируемой в базе УТ 10.3.

  После доработки в правиле конвертации объекта "КорректировкаРеализации" (на скрине ниже приведен пример доработки для автоматической установки в документе после выгрузки в базу БП признака "Бухгалтерский учет прошлого года закрыт для корректировки (отчетность подписана)" для случая, когда в поле "Основание" находится документ, год даты которого меньше, чем год даты документа корректировки; так же в поле "Статья прочих доходов и расходов" устанавливается предопределенный элемент справочника "Исправительные записи по операциям прошлых лет") и теста обмена доработка не сработала.

  
  

  
  

  Было понятно, что с новой редакцией Бухгалтерии 3.0, разработчики могли поменять что-то в привычном механизме. Благодаря обсуждению на форуме Конвертация данных. ПКО ПослеЗагрузкиОбъекта не срабатывает решение было найдено:

  
  

  
  

  
  

  Извлекаем из сохраненного архива файл CorrespondentExchangeRules.xml.

  
  

  Добавляем в файл правил конвертации необходимые доработки. Обновляем в архиве.

  
  

  Загружаем в "Параметры синхронизации данных". Оставляем вариант "Загрузить из файла на компьютере".

  
  

  После проведенных операций. Выгрузка/загрузка документов из УТ 10.3 в БП 3.0 с доработкой обработчика "после загрузки" правил конвертации объекта стала выполняться как необходимо.

  Читайте также:

    
  • Анимировать фон в after effects
    
  • Программа для андроид читатель
    
  • Triton плагин для fl studio что это
    
  • Как сделать кюветы в ворде
    
  • Как оформлять исследовательскую работу в ворде