Несоответствие количества параметров операции веб сервиса и процедуры обработчика
Передача параметров веб сервису, и разбор полученного ответа
В предыдущей статье мы проверяли орфографию с помощью веб сервиса от Яндекса. Сегодня мы создадим еще одну обработку с проверкой орфографии, но усложним задачу, если почитать документацию по яндекс спеллер API можно узнать, что проверка текста возможна на 3 языках:
Также можно управлять параметрами проверки: таблицу берм из описания API спеллера. Это кстати неправильно по WSDL мы должны получить полное описание сервиса, а тут есть параметр, который вычислить без чтения документации невозможно, но главное что документация есть.
Значение (десятичное)
Описание (пример)
Пропускать слова, написанные заглавными буквами, например, “ВПК”.
Пропускать слова с цифрами, например, “авп17х4534”.
Пропускать интернет-адреса, почтовые адреса и имена файлов.
Подсвечивать повторы слов, идущие подряд. Например, “я полетел на на Кипр”.
Пропускать слова, написанные латиницей, например, “madrid”.
Только проверять текст, не выдавая вариантов для замены.
Отмечать слова, написанные латиницей, как ошибочные.
Не использовать словарное окружение (контекст) при проверке. Опция полезна в случаях, когда на вход сервиса передается список отдельных слов.
Игнорировать неверное употребление ПРОПИСНЫХ/строчных букв, например, в слове “москва”.
Для установки параметров добавим к нашей предыдущей обработке дополнительную форму с незатейливым название «Настройки» Выглядеть она будет так:
Немного изменим код обработки. Теперь нам нужно передать не просто текст в веб сервис, а структуру с несколькими параметрами, для этого нам нужно получить описание параметра веб сервиса.
Сначала смотрим, что мы должны передать веб сервису:
Операции checkTexts мы должны передать параметр с типом CheckTextRequest, который состоит из атрибутов: lang, options, format, text.
Код, который осуществляет это следующий:
Заметьте, для облегчения понимания работы с веб сервисом я использовал Wsссылку из структуры метаданных конфигурации, но работаем мы с динамической ссылкой.
Параметры передали, теперь можно обрабатывать результат, в предыдущем примере мы это сделали без проблем, запускаем обработку и … у нас выскакивает ошибка, почему? У нас немного не тот формат результата, который возвращается у операции checkText формат результата SpellResult ( http://speller.yandex.net/services/spellservice ) а у операции checkTexts формат другой CheckTextsResponse ( http://speller.yandex.net/services/spellservice ),
который состоит уже из SpellResult – ов. Посмотрим, как выглядит ответ сервера в XML формате, воспользовавшись soapUI.
Модифицированный код разбора результата будет такой
как видите, мы просто спустились по структуре ХМЛ до уровня, на котором уже есть нужные нам данные.
Web сервис, момент подключения
Объект конфигурации Web-сервис содержит модуль, в котором создаются процедуры на встроенном языке, выполняемые при вызове тех или иных операций Web-сервиса. Типы параметров операций Web-сервиса описываются с помощью типов XDTO и могут представлять собой либо значения XDTO, либо объекты XDTO.
Вызов Web-сервиса происходит следующим образом:
? из пула соединений выбирается подходящее соединение с информационной базой; при отсутствии необходимого соединения соединение создается;
? выполняется вызов затребованного метода Web-сервиса, при этом происходит вызов обработчика УстановкаПараметровСеанса() (в модуле сеанса) каждый раз, когда происходит обращение к неинициализированному параметру сеанса.
СОВЕТ. Не рекомендуется выполнять ресурсоемкие операции в обработчике события УстановкаПараметровСеанса.
Событие УстановкаПараметровСеанса модуля сеанса вызывается на сервере в привилегированном режиме. Модуль вызванного сервиса исполняется на сервере в обычном режиме.
Модуль сеанса (см. здесь) служит для инициализации параметров сеанса и выполнения некоторого набора команд при вызове любого Web-сервиса системы «1С:Предприятие».
(4) ну у меня доступа нет))
Но как я понл, если необращаться к параметрам сеанса то все ок будет, тоесть не будет вызываться установка параметров сеанса.
(6) вот это будет всегда вызываться:
? создается новый сеанс и для созданного сеанса вызывается событие УстановкаПараметровСеанса (в модуле сеанса);
ИмяПриложения (ApplicationName)
Использование:
Только чтение.
Описание:
Тип: Строка.
Имя приложения, использующего соединение с информационной базой.
Допустимые имена:
(18)
Пользователя все равно придется делать, и роль, и права прописывать.
Добавить роль веб сервис.
Веб-сервис. Ошибка. Несоответствие типов XDTO: Свойство является списковым
Всем доброго дня!
Вопрос для гуру веб-сервисов.
Имеется следующий код:
Определения = Новый WSОпределения(“https://apitest.merlion.com/re/mlservice3?wsdl", Пользователь, Пароль);
ВебСервис = Новый WSПрокси(Определения, “https://apitest.merlion.com/re/mlservice3", “MLService”, “MLPort”);
ВебСервис.Пользователь = Пользователь;
ВебСервис.Пароль = Пароль;
Результат = ВебСервис.getCatalog(“All”);
При отрабатывании выдает ошибку:
<ВнешняяОбработка.MERLION_API_20.Форма.Форма.Форма(432)>: Ошибка при вызове метода контекста (getCatalog)
Результат = ВебСервис.getCatalog(“All”);
по причине:
При вызове веб-сервиса произошла ошибка. Ошибка вызова операции сервиса:
по причине:
При вызове веб-сервиса произошла ошибка. Неизвестная ошибка. Несоответствие типов XDTO:
Свойство является списковым
по причине:
Несоответствие типов XDTO:
Свойство является списковым
Вопрос: чего ему надо? и как пофиксить?
Заранее премного благодарен за конструктивные ответы!
по причине:
-2147221005(0x800401F3): Invalid class string
не подскажете, чего ему надо?
(6) Надеюсь в 1С хватит здравого смысла выпустить новую версию Native API, что бы можно было возвращать и передавать в параметрах метода объекты ВК, как это можно делать с COM.
Не ну конечно можно написать метод. Например здесь http://catalog.mista.ru/public/466196/
Можно конечно написать универсальный метод для получения данных свойств или полей получив типы через рефлексию и используя люмбды. Например
Методика расследования причин медленной работы операции на примере открытия управляемой формы
Ограничения применимости методики
Когда применяется методика:
Проверка ограничений и подготовка к расследованию
Для начала необходимо убедиться, что проблема стабильно воспроизводится (в одинаковых условиях) и что все пункты с описанием применения методики выполнены. Для этого можно сделать следующее:
Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 1С:Предприятие) мы в отдельном каталоге Client_Full увидим данные только клиентских приложений (хотя при этом подкаталоги других процессов тоже будут созданы, но они буду пустыми). Свойство Interface не собираем, так как оно дублируется более “человек читаемым” свойством IName (хотя даже последнее нам в данном примере не обязательно нужно).
После настройки технологических журналов и проверки корректности замера времени ОценкиПроизводительности БСП выполняем повторение операции с включенной отладкой.
Замеры времени средствами БСП будут выглядеть следующим образом:
Везде далее будем рассматривать верхний в этом списке замер от последнего повторения, его длительность 13,022 секунды.
Замер отладчиком конфигуратора изображен на следующем рисунке:
Как видно, сумма длительности всех строк, связанных с открытием формы составила всего 1,523 секунды.
Определим точное время начала и завершения операции по данным регистра замеров времени БСП.
Для этого необходимо любым удобным способом преобразовать данные колонок “Дата начала замера” и “Дата окончания” из миллисекунд UTC, начиная с 01.01.0001 00:00:00 (обычно эти значения получены с помощью функции ТекущаяУниверсальнаяДатаВМиллисекундах()).
Например, можно воспользоваться онлайн инструментами вроде https://www.epochconverter.com/ (нас будут интересовать минуты, секунды и миллисекунды, отличия в часовых поясах и годах не важны), либо можно преобразовать значение в дату с точностью до секунд с помощью функции вида:
‘00010101’ + ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000
а для миллисекунд взять остаток от деления на 1000 (то есть просто последние три цифры, обратите внимание на “779” на следующей картинке).
Точное время начала замера (минут:секунд.миллисекунд): 25:10.779
Точное время окончания замера (минут:секунд.миллисекунд): 25:23.801
Найдем теперь записи технологического журнала, соответствующие данному замеру, они будут примерно следующими:
Здесь видно, что соответствующий нашему замеру серверный вызов SCALL завершился примерно за 10,1 секунды, это соответствует интервалу между запросом VRSREQUEST и ответом VRSRESPONSE.
Причем время начала замера почти совпадает с началом вызова, то есть событием VRSREQUEST, что собственно ожидаемо, так как замер БСП начинается на клиенте и должен быть непосредственно перед командой открытия формы. А вот окончание вызова сервера случилось раньше, чем окончание замера, что значит, что эта разница во времени пришлась на часть работы клиентского приложения.
Итак, промежуточный итог по длительностям замеров разными способами показывает соответствие нашей ситуации ограничениям и выполнение неравенства: 1,5
После того, как их подготовили, перейдем в тонкий клиент 1С, откроем форму списка документов и непосредственно перед воспроизведением проблемной операции запустим сбор данных WPR (кнопка Start).
После открытия формы в тонком клиенте запись можно остановить и открыть ее для анализа. В открывшемся окне найдем по PID 5508 (его можно определить в диспетчере задач ОС или по логам ТЖ) наш тонкий клиент 1С и должны получить примерно следующую картинку:
По данным Windows Performance Analyzer видим, что у нас нет серьезной нагрузки по дискам, а поток тонкого клиента потребляет 100% ЦП на протяжении длительного времени вплоть до завершения замера.
Запомним этот результат и проанализируем траффик.
Запустим Wireshark и повторим проблемную операцию в тонком клиенте 1С:Предприятие с прямым подключением к серверу приложений 1С.
При сборе данных с помощью Wireshark (и отбору по пакетам с сервером-источником равным серверу приложений 1С:Предприятие) запуск открытия формы документа будет выглядеть примерно так:
Здесь каждая такая строка – это пакет (или если точнее, то “кадр”, frame), который в свою очередь является частью общего большого пакета поверх протокола TCP (PDU – Protocol Data Unit). Если их сложить, получим пакет около 70 Кб. Стоит обратить внимание, что это будет размер с учётом сжатия, а если без него – то должны получить что-то около 2500 – 3500 Кб данных.
Если вернуться к анализу технологического журнала и посмотреть на “Content-Length” (или “Body”), то увидим также те самые 70577 байт. Познавательно, можно взять на заметку, но пока новой информации не дает. В таком дампе Wireshark бывает полезно анализировать каждый отдельный кадр и возможные повторы отправки пакетов или увидеть сбросы TCP-соединений, которые могут приводить к ошибкам в работе клиентов (например, из-за антивирусов, которые могут распознать такое содержимое как подозрительное). Однако для нашей проблемы удобнее воспользоваться другим инструментом – прокси-сервером Fiddler и проанализировать с его помощью уже http-траффик.
Устанавливаем и запускаем Fiddler, на панели инструментов ищем “Browse”, выбираем любимый браузер и запускаем в нем необходимое нам приложение (информационную базу 1С:Предприятие). После запуска переходим в форму списка документов (готовимся воспроизвести сценарий), возвращаемся в Fiddler и включаем сбор траффика (кнопка F12), переходим в браузер и открываем форму документа. После её открытия сбор траффика можно отключить и заняться его анализом. Мы должны получить примерно следующее:
В данном дампе достаточно быстро находится относительно большой пакет искомого размера, выбираем его в списке слева, а в правой части окна переключаемся на страницу Inspectors, выбираем там просмотр заголовков (Headers), и так как у нас пакет является сериализованным json (Content-Type: application/json), то попросим Fiddler десериализовать его для нас.
После этого в окне предпросмотра отобразится древовидная структура ответа (response), которая передается с сервера на клиент и содержит так много данных. Далее нам необходимо проанализировать её и найти наиболее проблемные места. Может помочь кнопка Expand All, которая развернёт все элементы дерева, но это может занять некоторое время. Чтобы его сократить, сначала поймем, что именно нужно искать.
Подведем промежуточный итог:
Из всех этих пунктов для нас наиболее полезным и требующим дополнительного анализа является тезис “Размер пакета с формой подозрительно велик”.
Какие могут быть причины для такой ситуации? В общем случае их несколько:
Так как наша проблема (у вас может быть по-другому) воспроизводится даже при очень небольшом количестве данных в ТЧ, и реквизитов у документа (т.е. объекта формы) совсем не много, то их мы не рассматриваем. Остаются реквизиты формы, не равные основному реквизиту “Объект”.
Среди них находится несколько реквизитов, имеющих произвольный тип. Могут выглядеть так:
Сопоставляем эти данные с уже собранным ранее замером с помощью конфигуратора, и видим заполнение этих структур достаточно большим количеством элементов (например, можно 5059 в реквизите “СвойстваИзмерений”).
Снова вернемся к дампу траффика в Fiddler и найдем там элемент, отвечающий за параметры формы (response/props). Увидим там примерно следующее:
И если развернем далее эти элементы, убедимся, что их там несколько тысяч, каждый из которых представляет собой вложенную структуру вида:
Найдем прикладной код, заполняющий эти параметры, и убедимся, что данных там действительно достаточно много (2-3 Мб), и они представляют собой большое количество сложных вложенных структур.
Отключив заполнение данных реквизитов, убеждаемся, что проблема с производительностью формы исчезает, что значит, что причина была найдена правильно.
Выводы и рекомендации
Длительная работа открытия формы обусловлена сериализацией и десериализацией больших коллекций значений при передаче их между клиентом и сервером.
Для того чтобы оценить степень влияния всех факторов, которые имеют значения в этом процессе, можно сделать несколько тестов (замеров), изменяя эти факторы и оценивая корреляцию их значений и длительности. В нашем случае причиной проблем были структуры, хранящие данные справочников территорий и условий труда, поэтому изменяли количество этих элементов и пробовали замерять передачу с клиента на сервер этих данных (процедура ДанныеДляРедактированияВХранилище).
В следующей таблице приведены результаты таких замеров в нашем примере. Сразу следует оговориться, что не стоит никаким образом рассматривать в ней абсолютные значения, так как это будет зависеть еще и от конфигурации компьютера, сети, версии платформы и многого другого, связанного именно с нашим примером. Для нас же важны зависимости и их характер (линейная, экспоненциальная и т.д.). Предлагаем вам проанализировать их самостоятельно (или даже повторить замеры на актуальной версии платформы в вашей среде).
Принимая во внимание полученные таким образом данные, можно предложить следующие возможные пути решения:
Заметки из Зазеркалья
Реализовано в версии 8.3.9.1818.
В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.
Переиспользование сеансов
Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».
Кроме этого существовал и функциональный недостаток. Веб-сервисы не обладали состоянием. Это не позволяло реализовывать логику, использующую сохранение состояния между вызовами веб-сервиса.
В версии 8.3.9 мы доработали механизм веб-сервисов (SOAP-сервисы, HTTP-сервисы, сервисы OData). В результате их производительность увеличилась примерно в 10 раз.
Мы проводили тесты на типовой конфигурации Бухгалтерия предприятия. В неё мы добавили HTTP-сервисы, выполняющие выборку из справочника Контрагенты. Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с.
Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:
При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.
Например, это может быть автоматизация торговой деятельности удаленных торговых точек, предусматривающая периоды пиковой нагрузки на сервер. Для обработки будет выделено нужное количество сеансов. Они будут завершены по мере падения нагрузки.
Другой пример это получение/помещение файлов в конфигурации Документооборот посредством http-сервисов. Для таких операций можно использовать одного и того же специального пользователя.
Стратегия ручного управления сеансами подразумевает, что клиент самостоятельно управляет количеством сеансов и временем их жизни. Эта стратегия лучше подходит для высокоинтегрированных систем в рамках одной организации. Вы можете реализовать собственный алгоритм, который будет управлять временем жизни сеансов и их количеством.
Средства управления
Необходимость использования одной или другой стратегии вы можете определить в дереве объектов конфигурации, и, при необходимости, переопределить в файле публикации default.vrd. В дереве объектов конфигурации мы добавили два новых свойства объектам Web-сервис и HTTP-сервис:
В файле default.vrd для элементов, описывающих SOAP-сервисы, HTTP-сервисы и сервисы OData, мы ввели несколько новых атрибутов:
Например, файл default.vrd может выглядеть так:
Файл default.vrd имеет больший приоритет, чем конфигурация. При публикации конфигурации атрибуты reuseSessions и sessionMaxAge заполняются из соответствующих свойств объектов конфигурации Web-сервис и HTTP-сервис. Но при необходимости вы можете изменить эти значения прямо в файле, и тогда платформа будет использовать их, а не значения из конфигурации.
Автоматическое переиспользование сеансов
Сеансы в пуле хранятся в разрезе типа сервиса, наименования сервиса, пользователя/пароля, значений разделителей и безопасного режима. Причём в пуле может быть несколько сеансов с одинаковыми значениями перечисленных реквизитов.
При вызове платформа проверяет, есть ли простаивающий сеанс с подходящим сочетанием этих реквизитов. Если такой сеанс есть, то он выделяется для обработки вызова. Если такого сеанса нет, то создается новый сеанс и выделяется для обработки.
Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).
Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.
Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.
При выборе размера пула следует учитывать все разрезы, в которых хранятся сеансы в пуле. Мы рекомендуем устанавливать размер пула немного больше, чем количество возможных вариантов. Это позволит вам избежать ситуации, когда пул заполнен сеансами, и вызов с новой комбинацией разделителей/пользователей обработан быть не может.
Эта стратегия не подходит для сценариев, в которых нужно использовать сохранённое состояние сеанса на сервере. Потому что нет никакой гарантии, что при следующем вызове клиент будет подключен к тому же самому сеансу. Как мы говорили в начале, в пуле может быть несколько сеансов с одинаковыми значениями ключевых реквизитов.
Управление сеансами
Инициатором создания и завершение сеанса является клиент сервиса. Чтобы создать постоянный сеанс клиент должен передать заголовок IBSession в http – запросе. Этот заголовок вы устанавливаете вручную. Значением этого заголовка должна быть директива start.
После получения такого заголовка на сервере стартует сеанс информационной базы, происходит аутентификация, установка разделителей и вызывается обработчик УстановкаПараметровСеанса().
Если клиент затребовал создание сеанса, а сервер не может это сделать, генерируется сообщение об ошибке 406 Not Acceptable.
Если всё хорошо и сеанс создан, платформа помещает в http-ответ директиву установки куки IBSession с идентификатором созданного сеанса.
Для подключения ранее созданного сеанса, вам необходимо указать куки IBSession с идентификатором сеанса.
Для завершения сеанса вам нужно использовать заголовок IBSession http-запроса. Его нужно установить в директиву finish.
Получив сообщение с таким заголовком, сервер отрабатывает вызов, и закрывает сеанс.
Эта стратегия позволяет вам реализовать сценарии, в которых используется состояние сеанса, сохранённое на сервере. Потому что вы имеете уникальный идентификатор сеанса. Единственное, о чём нужно помнить, что завершение сеанса может происходить не только по вашей «команде», но и автоматически. В том случае, когда превышен период бездействия сеанса (ВремяЖизниСеанса). Поэтому вы, как клиент сервиса, должны быть готовы к тому, что сеансовые данные могут быть сброшены, если сеанс завершен.
Веб-сервисы в расширениях
Если объекты конфигурации Web-сервис или HTTP-сервис располагается в расширении конфигурации, то возможность редактировать свойства ПовторноеИспользованиеСеансов и ВремяЖизниСеанса у вас отсутствует. Поэтому, если вы хотите включить автоматическое или ручное переиспользование сеансов, вам нужно использовать для этого файл default.vrd.
В дальнейшем мы будем рассматривать возможность поддержки этих свойств в расширениях.