1с подключение к soap

Обновлено: 07.07.2024

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

Способ применим для случаев, когда веб-сервис и html-страница опубликованы на одном сервере. В этом случае не возникает кросс-доменных проблем. Например, если домены будут отличаться, то Chrome выдаст ошибку:

Failed to load resource: Origin localhost:3299 is not allowed by Access-Control-Allow-Origin

Не вдаваясь в подробности публикации веб-сервисов, предположим, что на стороне 1С создан и опубликован веб-сервис catalogs с операцией Execute. На входе — параметр script типа string, на выходе тип string. Операция запускает на стороне произвольный код script из параметра и возвращает JSON-сериализацию от переменной result.

С JSON-сериализацией удобно работать средствами JavaScript и преобразовать строку в объект/массив одной командой eval(resultText). В Интернете можно найти несколько JSON-сериализаторов для 1С.

Удостоверимся, что веб-сервис отвечает, введя его адрес:

На форме сверху разместим элементы настройки веб-сервера: wsUrl — адрес веб-сервиса, wsUser — логин, wsPassword — пароль. На стороне веб-сервиса 1С включена basic autherization. Логин и пароль соответствуют пользователю, прописанному в 1С.

Левая панель отвечает за отображение доступных справочников catalogsList, правая — за отображение букв (letters) и данных (catalogRecords).

JavaScript

Функция обращения к SOAP веб-сервису определена следующим образом:

Получение списка наименований каталогов.

Получение первых букв наименований справочника

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

При нажатии на кнопку Обновить происходит вызов функции

и при успешном выполнении вызывается обработчик processSuccess

Веб-сервис возвращает xml, где значимым является содержимое m:return-тэга — JSON-сериализация. Перевести его в объекты JavaScript можно через eval-вызов. Обработчик очищает перечень справочников и заново его формирует через li-тэги с атрибутом catalog. Каждому элементу устанавливается класс catalogTitle.

Аналогично обрабатываются нажатия на все управляющие элементы. Нажатие на справочник очищает буквы и данные, перезаполняет буквы. Нажатие на букву перезаполняет данные из справочника. За обработку кода на 1С отвечают куски кода в script-блоках с типом «text/1c».
Приложение выглядит так:

Нерешенная проблема авторизации на браузере IE

Существует проблема авторизации на IE. На IE 8/9 не удалось решить проблему basic authorization аналогичным для остальных браузеров методом.

На IE Ajax не работает с использованием user/password — свойств $.ajax. На FF и Chrome все работает нормально. По какой-то причине на сервер в случае с IE не передается заголовок

Authorization: Basic 0JHQsNGF0YjQuNC10LLQn9CYICjRgNGD0LrQvtCy0L7QtNC40YLQtdC70YwpOg==
Если кто-нибудь знает причину и как обойти, пожалуйста, напишите в комментариях.

Выводы

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

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

Внешние компоненты Native API от 1С не будут работать в данной среде. Это значит, что нужно дополнительно решать проблему с написанием драйверов для оборудования.

Disclaimer: Статей на эту тему написано очень много и, как вы, конечно, догадались, это очередная. Возможно, вы узнаете из неё что-то новое, но ничего сверхсекретного, что нельзя было бы нагуглить самостоятельно, здесь не описано. Только заметки из личного опыта.

Вступление

Рассматривать будем только ситуацию, когда есть сторонний web-сервис и стоит задача наладить обмен данными.

Строение сервиса описывается в файле WSDL (англ. Web Services Description Language)

Файл чаще всего доступен по ссылке, где находится точка входа в сам web-сервис. Я написал «чаще всего», так как бывают исключения. Например, Web-сервис на базе SAP не публикует wsdl и его можно получить только выгрузив из самого приложения.

И так, у нас есть описание web-сервиса, логин, пароль. Давайте подключимся.

Отлично! Мы подключились к web-сервису! По идее это основа любого варианта обмена, так как позволяет создавать объект структуры данных на основании wsdl, а работать с таким объектом одно удовольствие.

Рассмотрим XML который нам выдает SoapUI

Теперь опишем его программно

В этот самый момент и возникает множество нюансов. Попробуем рассмотреть каждый.

Рецепт 1. Отправляем XDTO-объект целиком

Остается лишь обработать результат, который нам вернул сервис и на этом всё. Согласитесь, что это очень удобно!

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

Рецепт 2. Отправляем чистый xml в качестве параметра

Если не удалять пространство имен, которое 1с добавляет по умолчанию, то стало больше всего на 5 строк кода. Чаще всего я заворачиваю преобразование xml в функцию, так как обычно вызываем более одного метода.

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

Далее описываем заголовки согласно документации. Некоторые сервисы спокойно прожуют наш запрос и без заголовков, тут надо смотреть конкретный случай. Если вы не знаете какие заголовки прописывать, то самый простой способ это подглядеть запрос в SoapUI переключившись во вкладку RAW.

Функция получения Base64 строки выглядит так (подсмотрел здесь):

Здесь по сути тоже самое, что и в предыдущем варианте, но работаем с COMОбъектом. Строку соединения указываем полностью, вместе с протоколом. Особое внимание следует уделить только флагам игнорирования ошибок SSL-сертификатов. Они нужны, если мы работаем по SSL, но без определенного сертификата, так как создать новое защищенное соединение в таком варианте не предоставляется возможным (или я не умею как). В остальном механизм схож с предыдущим.

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

Обработка результата

В рецепте 1 мы чаще всего получаем готовый XDTO-объект и работаем с ним как со структурой. Во всех остальных случаях можно преобразовывать xml-ответ в XDTO

Вместо заключения

1. Начинайте работу с web-сервисами с программы SoapUI. Она предназначена для таких работ и позволит быстрее понять как работает тот или иной сервис. Для освоения есть статья про SoapUI.

4. Если вас пугает XDTO, то рекомендую ознакомится с циклом статей злого бобра Андрея XDTO - это просто.

5. Если аутентификация предполагает использование Cookie, то нашлась следующая статья.

P.S. Если у вас появились вопросы, предложения по улучшению кода, есть собственные рецепты, отличные от описанных, вы нашли ошибки или считаете, что автор "ниправ" и ему "не место в 1с", то пишите комментарии, и мы все обсудим.

UPD:
1. Добавил по просьбе join2us XML, который выдавал SoapUI
2. Исправил ошибки найденные пользователем VasilVtoroy

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

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

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

Принцип работы данного модуля

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

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

Более подробно схематично:

От теории к практике

Как это работает в коде:

Платформа 8.3, управляемые формы.

Платформа 8.2, обычные формы.

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

Под капотом при выполнении метода:

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

Так как статья ориентирована на программистов, так или иначе умеющих читать код 1С и делать логические выводы, я не буду слишком сильно углубляться в обьяснение принципов работы данного модуля.

Файлы во вложении:

1. Тестовые конфигурации с интегрированными тестовыми внешними веб-сервисами:

1.1. на платформе 8.2, с режимом запуска обычное приложение.

1.2. на платформе 8.3, с режимом запуска управляемое приложение.

1.3 Соответствующие обработки на обычных и управляемых формах, для вызова и тестирования интегрированных веб-сервисов.

2. Текстовые файлы содержащие код технического общего модуля и шаблон обслуживающего веб-сервис общего модуля.

3. Текстовый файл, описывающий необходимые действия для интеграции данного модуля.

В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.

Переиспользование сеансов

Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».

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

Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:

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

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

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

Средства управления

reuseSessions – аналог свойства ПовторноеИспользованиеСеансов, может принимать значения autouse, use и dontuse;
sessionMaxAge - аналог свойства ВремяЖизниСеанса;
poolTimeout - используется при автоматическом управлении сеансами, содержит время ожидания доступности сеанса;
poolSize - используется при автоматическом управлении сеансами, содержит максимальное количество сеансов, которое может быть создано в пуле.

Например, файл default.vrd может выглядеть так:

Автоматическое переиспользование сеансов

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

При вызове платформа проверяет, есть ли простаивающий сеанс с подходящим сочетанием этих реквизитов. Если такой сеанс есть, то он выделяется для обработки вызова. Если такого сеанса нет, то создается новый сеанс и выделяется для обработки.

Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).

Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.

Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.

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

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

Управление сеансами

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

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

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

Веб-сервисы в расширениях

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