Soap ui не закрыт тег 1с
Я пробовал с SOAP 4.0.1, а также с SOAP 5.1.2. Я пробовал это на своих окнах, но также и на Windows Server 2008 Пытаюсь импортировать WSDL: Представлен диалог NT Authentication: Укажите учетные данные для аутентификации NT для заполнения имени пользователя, пароля, домена
Я могу открыть определение WSDL в Firefox:
После ввода логина и пароля
Но при попытке импортировать файл WSDL или при попытке импортировать файл wsdl с использованием URL-адреса местоположения
У меня такая же ошибка при использовании последней версии Soap UI 5.3. Никакого взлома с настройкой не помогло (прокси нет, аутентификация с упреждением и т. Д.). В конце концов, я импортировал WSDL с диска. Вызов операций через NTLM тогда работал без проблем. Похоже на ошибку в SoapUI при импорте WSDL через NTLM в некоторых средах.
Обновление: проверено, что включение анонимной аутентификации и отключение Windows auth в IIS решает проблему с импортом в SoapUI. Так что это определенно какая-то ошибка в SoapUI при импорте через NTLM.
Я тоже столкнулся с этой проблемой. Решение. Подключитесь к открытой сети (не офисной сети) и отправьте параметр прокси в SOAPUI как «Нет».
У меня такая же проблема. Предоставление учетных данных прокси-сервера решило проблему для меня.
Была та же проблема здесь, с WSDL, который работает в другой системе. Проблема была в настройке прокси-сервера, и, поскольку мне не нужен прокси-сервер, просто отключение его через меню браузера решило проблему для меня.
Поэтому вам нужно быть уверенным, что этот объект представлен в вашем WSDL или импортированных схемах.
Если ваш WSDL на 100% правильный и там есть "raquo", то я могу только предложить вам загрузить WSDL в локальный файл со всеми схемами, изменить schemaLocation на локальные относительные пути и попробовать импортировать этот локальный файл.
Вы измените настройки прокси-сервера в разделе «Настройки»> «Настройка прокси-сервера» на «Нет», это должно решить проблему аутентификации, с которой вы столкнулись.
Описанный метод позволяет обратиться к веб-сервисам 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.
Веб-сервис возвращает 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С не будут работать в данной среде. Это значит, что нужно дополнительно решать проблему с написанием драйверов для оборудования.
Описанный метод позволяет обратиться к веб-сервисам 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.
Веб-сервис возвращает 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С не будут работать в данной среде. Это значит, что нужно дополнительно решать проблему с написанием драйверов для оборудования.
Вступление
Кто-то может сказать: "Ой, да что там руками формировать, XML простая". Однако протокол содержит некоторое количество расширений, таких как, например, WS-Addressing и WS-Security, которые могут превратить ручное формирование в боль.
Подготовка
В качестве инструмента для решения задачи я буду использовать node.js. Почему? Во-первых, мне так удобнее: я его знаю :). Во-вторых, на нем есть простые для запуска библиотеки для построения веб-приложений, работы с soap и кластеризацией. В качестве редактора я рекомендую использовать Visual Studio Code, но это уже дело вкуса. Тренироваться будем на классическом сервисе npm install --save soap body-parser express
Файл с wsdl положим в корень каталога с именем DailyInfo.wsdl в кодировке UTF-8.
Для достижения нашей цели нам надо решить следующие задачи:
Написать веб-сервер, который сможет принимать POST запросы (это совсем не так сложно, как звучит).
Подключиться к soap-серверу как клиент.
Преобразовать входящий POST-запрос в вызов soap-метода и вернуть на клиент результат.
Страшно? 10 минут, помните?
Реализация – веб-сервер
Создадим скелет нашего приложения - файл index.js в корневом каталоге (если вы не указывали иное при выполнении npm init) со следующим содержимым:
Этим небольшим скриптом мы сразу же решили задачу №1 из нашего списка. Осталось запустить и проверить.
Для запуска приложения у нас есть два варианта:
запуск из командной строки через node index.js;
запуск отладчика в VSCode.
С первым вариантом все просто: вбили в консоль и радуемся:
Останавливаем работу через Ctrl-C.
Отладчик VSCode запускается по кнопке F5. В выпадающем меню надо выбрать Node.js:
После выбора node.js на вкладке Debug console можно убедиться, что наше приложение запустилось и готово обрабатывать запросы:
В ответе сервиса видим, что он не может обработать GET-запрос, что логично. Поменяем запрос на POST и получим уже ожидаемый ответ:
Реализация – soap-клиент
Перейдем ко второй части – подключение по soap-серверу в качестве клиента. Для этого в уже существующий файл нужно добавить два участка кода. В секцию подключения библиотек добавим подключение “soap” – библиотеки, с помощью которой можно как подключиться к чужому soap-серверу, так и опубликовать собственный.
Внутрь функции main добавим создание soap-клиента:
Иии… всё. Теперь через созданного клиента мы можем вызывать методы soap-сервера, как указанные с «полным» именем в виде soapClient,service.port.methodName(), так и по короткому soapClient.methodName().
Реализация – Преобразование запроса
Добавим, собственно, вызов нужного нам soap-метода. В качестве API нашего сервиса предлагаю такую простую схему: в теле POST-запроса передается JSON следующей структуры:
method – строка – имя вызываемого soap-метода;
body – произвольный – тело soap-запроса в виде js-объекта.
Таким образом, получение списка валют на определенную дату через наш промежуточный сервис может выглядеть так:
Заменим наш ответ «привет, мир» на следующий код:
Кода меньше, чем комментариев :). Сохраняемся, перезапускаемся и снова идем в Postman. На вкладке body укажем, что мы отправляем raw-данные с типом application/json и содержимым из примера выше:
В результате видим тело soap-ответа в виде JSON.
Реализация – вызов из 1С
Postman – это хорошо, но мы же изначально пришли с проблемой вызова из 1С. Выполнить обычный POST-запрос из 1С не составит труда, однако, я приведу пример реализации здесь, чтобы показать работу с JSON и XDTO.
Вытащим из WSDL все содержимое тега s:schema в отдельный файл и перенесем объявление пространства имен s из заголовка WSDL в заголовок нового файла. Получится что-то вроде такого:
Сохраним содержимое в файл с разрешением XSD, и, если все прошло успешно, полученная схема успешно импортируется в конфигуратор как XDTO пакет:
Если от вендора пришла «нечитаемая» в 1С XSD, то использование фабрики XDTO из следующего примера не имеет смысла, однако десериализацию из JSON будет просто написать по аналогии с сериализацией.
Для формирования запросов создадим внешнюю обработку со следующим кодом:
Некоторые пояснения по коду.
Ставим в конец процедуры точку останова, выполняем обработку… Вуаля:
Кластеризация
Окей, сервис готов, можно в прод? :)
Если не страшно, то можно сразу и в прод, однако, я бы на вашем месте помимо обработки ошибок и общего причесывания кода добавил бы еще одну вещь. Node.js штука хоть и быстрая, но не всемогущая. Возможно вам знакома фраза, что «нода – асинхронная, но однопоточная». В новых версиях node.js уже появилась честная поддержка многопоточности, но для простоты воспользуемся другим старым и проверенным механизмом – кластеризацией. А асинхронность обработки в нашем случае есть, но нам не помешает воспользоваться дешевым ускорителем.
Ставим пакет cluster-service с помощью команды:
Запускаем наше приложение в командной строке, но в вместо node укажем приложение cservice:
Наш промежуточный сервис запустился в режиме кластера с количеством потоков, равным количеству логических процессоров. Можете выполнить нагрузочное тестирование через тот же SoapUI и замерить количество обрабатываемых запросов в секунду при обычном запуске и при кластеризованном запуске – заметите ощутимую разницу.
Что там было про WS-Addressing?
Ах-да, заголовки, те самые soap-headers, которые не поддерживает 1С. Добавить их довольно просто – для этого в soapClient есть метод addSoapHeaders, в который можно передать либо готовую строку с заголовками, либо JS-объект. Попробуем реализовать добавление пары заголовков семейства WS-Addressing, а именно Action и MessageID.
Добавим ее в секцию импорта библиотек:
Между проверкой указателя на soap-метод и самим вызовом soap-метода добавим заполнение заголовков:
Убедиться в корректности отправляемых заголовков можно через тот же SoapUI или настроив логирование запросов в промежуточном сервере.
Дополнительные вопросы
- А зачем JSON? Можно гонять туда-сюда XML?
- Можно, но зачем, если есть возможность гонять более легковесный JSON, а 1С уже умеет нативно с ним работать?
- Можно ли накрыть авторизацией?
- Можно, причем и веб-приложение (для этого надо добавить еще один middle-ware с авторизацией в вызов app.post), и soap-сервер, который можно поднять в этом же приложении как сервис обратного вызова в случае асинхронного soap-обмена.
Заключение
Вот таким нехитрым способом мы смогли обойти ограничение возможностей платформы 1С, таких как отсутствие поддержки soap-headers и не полной поддержки WSDL-описания.
Не бойтесь использовать другие языки в своей работе. Даже начальный уровень знаний какого-либо языка, фреймворка или технологии может существенно сократить вам время на разработку требуемой функциональности.
Полный код получившегося приложения, а также исходники обработки доступны в
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
Читайте также: