Стрначинаетсяс 1с не работает

Обновлено: 08.07.2024

Функции для работы со строками в 1С 8.2 и 8.3

Строка

Функция Строка(x) возвращает текстовое представление переданного ей значения “x”.

СтрДлина

Функция СтрДлина(x) вычисляет количество символов в строке “x”, учитывая пробелы и ничего не значащие символы.

СокрЛП, СокрЛ, СокрП

Функции СокрЛП(x), СокрЛ(x) и СокрП(x) убирают пробелы и ничего не значащие символы у переданной строки “x” с обеих сторон, слева и справа соответственно.

Лев, Прав, Сред

Функции Лев(x, y) и Прав(x, y) возвращают количество символов “y” с левого или правого края переданной им строки “x”. А функция Сред(x, y, z) возвращает количество символов “z” из указанного места “y” переданной строки “x”.

ВРег, НРег, ТРег

Сообщить(ТРег("Каждое слово с заглавной буквы")); //Каждое Слово С Заглавное Буквы

Найти

Функция Найти(x, y) возвращает номер первого символа первого вхождения подстроки “y” в строку “x”, если, конечно, такое вхождение найдено (при этом нумерация начинается с 1). Если же вхождений не найдено, то функция возвращает 0.

СтрЧислоВхождений

Функция СтрЧислоВхождений(x, y) возвращает количество вхождений подстроки “y” в строку “x”.

СтрЗаменить

Функция СтрЗаменить(x, y, z) позволяет в указанной строке “x” заменить все вхождения одной подстроки “y” на другую “z”, результатом выполнения функции будет строка с проведенными заменами.

Сообщить(СтрЗаменить("тест1,тест2,тест3,тест4", ",", " ")); //тест1 тест2 тест3 тест4

ПустаяСтрока

СтрЧислоСтрок

Функция СтрЧислоСтрок(x) возвращает количество строк в многострочном тексте “x”.

МногострочныйТекст = СтрЗаменить("тест1,тест2,тест3,тест4", ",", Символы.ПС); //тест1 тест2 тест3 тест4

СтрПолучитьСтроку

Функция СтрПолучитьСтроку(x, y) возвращает строку с номером “y” из многострочного текста “x”.

МногострочныйТекст = СтрЗаменить("тест1,тест2,тест3,тест4", ",", Символы.ПС); //тест1 тест2 тест3 тест4 Сообщить(СтрПолучитьСтроку(МногострочныйТекст, 2)); //тест2

Символ, КодСимвола

Символы

Это не функция, а набор наиболее часто используемых специальных символов, состоит из:

ЗначениеВСтрокуВнутр, ЗначениеИзСтрокиВнутр

Функция ЗначениеВСтрокуВнутр(x) возвращает системное строковое представление значения “x”. Функция ЗначениеИзСтрокиВнутр(x) проделывает обратную операцию и возвращает значение, полученное из строкового системного представления “x”. Обе эти функции используются для сохранения функциональной совместимости с версией 7.7. Использование для каких-либо других целей не рекомендуется. В новых версиях платформы данные функции не работают (хотя их описание присутствует в справке).

ВвестиСтроку

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

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

Функция форматирования СтрШаблон()

<Шаблон> - это строка, в которую нужно подставить представления параметров.

<Значение1> , . <Значение10> - это параметры (максимально - десять), представления которых нужно подставить в строку.

Чтобы указать конкретное место в шаблоне, в которое нужно выполнить подстановку, нужно использовать маркеры вида %1, . %10. Количество маркеров, задействованных в шаблоне, и количество параметров, содержащих значения, должны совпадать.

Например, результатом выполнения такого оператора:


Ошибка в данных в строке 2 (требуется тип Дата)

Функция работы со строками СтрСравнить()

Эта функция сравнивает две строки без учёта регистра. Например, так:


Это же действие вы могли выполнить и раньше с помощью объекта СравнениеЗначений:


Однако использование новой функции выглядит более простым. А кроме этого функция, в отличие от объекта СравнениеЗначений, работает и в тонком клиенте, и в веб-клиенте.

Функции работы со строками СтрНачинаетсяС(), СтрЗаканчиваетсяНа()

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

Например, их удобно использовать в операторе Если:


Функции работы со строками СтрРазделить(), СтрСоединить()

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


Функция работы со строками СтрНайти()

Вместо старой функции Найти() мы реализовали новую функцию, которая имеет дополнительные возможности:

  • Поиск в разных направлениях (с начала, с конца);
  • Поиск с указанной позиции;
  • Поиск вхождения с указанным номером (второе, третье и т.д.).

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

Ниже приведён пример, использующий новые возможности поиска. Поиск в обратном направлении удобен тогда, когда вам нужен последний фрагмент формализованной строки, например, полное имя файла в URL. А поиск с указанной позиции помогает в тех случаях, когда нужно искать в известном фрагменте, а не во всей строке.

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

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

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

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

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

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

Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 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 Мб), и они представляют собой большое количество сложных вложенных структур.

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

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

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

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

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


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

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

    Основные преимущества

    Чтобы вы могли представить себе объём выполненных нами изменений, коротко перечислим основные преимущества нового механизма.

    Современная архитектура отладки

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

    Новый механизм отладки перестал нуждаться в соединении с отлаживаемой информационной базой. Главное, что требуется теперь отладчику, это такая же конфигурация, которая работает у клиентов. Для её получения нет необходимости подключаться к отлаживаемой информационной базе. Вы можете загрузить её, например, из файла.

    Отладка мобильных приложений

    Изменение переменных, свойств объектов и асинхронные вычисления выражений

    Теперь в процессе отладки вы можете изменять значения любых переменных, которые доступны для записи. Для быстрого просмотра и изменения локальных переменных мы реализовали отдельное окно. А само вычисление выражений, отображаемых отладчиком, теперь выполняется в асинхронном режиме.

    Отладка в Development Tools

    При создании нового механизма отладки мы реализовали новый, универсальный программный интерфейс взаимодействия с ним. Этот интерфейс использует конфигуратор 1С:Предприятия, и этот же интерфейс использует теперь и новая среда разработки 1C:Enterprise Development Tools. Таким образом, все возможности отладки доступны теперь и при работе в Development Tools.

    Архитектура процесса отладки

    Новая архитектура отладки выглядит следующим образом:


    В отладке участвуют отладчик, предметы отладки и новый элемент - сервер отладки.

    Взаимодействие с сервером отладки выполняется по инициативе отладчика и предметов отладки. Для этого организуются дополнительные соединения. Их основное назначение - узнать, не появилась ли для них информация на сервере отладки. И если появилась, получить эту информацию.

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

    Идентификация информационных баз

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

    В новом механизме мы избавились от строки соединения. Теперь мы используем идентификатор информационной базы. В файловой информационной базе такой идентификатор генерируется при первом подключении клиентского соединения. В серверной информационной базе в качестве такого идентификатора используется идентификатор регистрации информационной базы в кластере.

    Приятным дополнительным моментом здесь является то, что мы пока сохранили в платформе старый механизм отладки (в дальнейшем он может быть исключён). И вы можете пользоваться им при желании, или при необходимости. Так вот старый механизм мы доработали, и теперь он тоже использует идентификатор информационной базы, а не строку соединения.

    Типичные сценарии отладки

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

    Несмотря на это имеет смысл познакомиться с тем, что происходит теперь при запуске отладки. Потому что это может быть полезно вам в каких-то нестандартных сценариях работы.

    Файловый вариант

    Клиент-серверный вариант

    Подключение предметов отладки

    При запуске отладочных сеансов из конфигуратора, приложения выполняют автоматическое подключение предметов отладки (как клиентского, так и серверного) к серверу отладки.

    При этом, как и раньше, у вас есть возможность настроить в конфигураторе автоматическое подключение предметов отладки независимо от того, каким образом они были запущены. Теперь эти возможности стали гораздо богаче.

    Во-первых, теперь платформа предлагает вам для выбора все возможные предметы отладки.


    А во-вторых, появился ещё один, более тонкий способ настройки. Это использование заранее созданных отборов.

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


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

    Изменение переменных, свойств объектов и асинхронные вычисления выражений

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

    Для удобного просмотра и изменения локальных переменных, что представляется наиболее частой задачей, мы реализовали окно «Локальные переменные».


    Внешне оно очень похоже на привычное вам «Табло». Но, во-первых, это окно уже автоматически заполнено всеми локальными переменными, а во-вторых, значения переменных вы можете теперь менять.

    Значения примитивных типов вы можете изменить прямо в ячейке «Значение»:


    А для изменения других значений вы можете воспользоваться окном ввода выражений:


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


    Точно таким же образом вы можете изменять и значения любых (не только локальных) переменных, свойств, доступных для записи. В окне вычисления выражений (которое вызывается командой Shift+F9) вы можете менять значения переменных как в ячейке «Значение», так и с помощью отдельного диалога.


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

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