ошибка soap сервера нарушение прав доступа к операции web сервиса
Руководство администратора
Типичные проблемы, возникающие при синхронизации
Обмен данными не работает
Запрет обмена с «Первой Формой».
Совпадение событий по времени при синхронизации
Возможна ситуация, когда два события — выполнение синхронизации данных и попытка изменения этих же данных штатными средствами «1С:Предприятие» — совпадают во времени. В этом случае пользователю при сохранении данных будет выдано сообщение о ошибке:
Сообщение об ошибке при совпадении изменений по времени.
Это нормальное поведение системы, поскольку в БД содержится уже другая версия данных. В этом случае форму документы/элемента справочника надо закрыть без сохранения и затем открыть снова.
Для администратора возникновение таких ошибок должно стать сигналом к пересмотру правил настройки бизнес-процесса. Возможно, для таких документов/справочников достаточно одностороннего обмена данных из «1С:Предприятие» в «Первую Форму».
Таймаут при синхронизации
При синхронизации данных между «Первой Формой» и 1С могут возникать ошибки из-за того, что не все данные успевают обработаться в одной системе за то время, пока вторая система ожидает ответа. В частности, таймауты могут возникать при синхронизации виртуальных документов, имеющих табличную часть с 200 и более записей. Таймаут на стороне 1С фиксируется в журнале ошибок.
На стороне «Первой Формы» таймаут ожидания ответа при вызове веб-сервиса 1С составляет 12 часов.
На стороне 1С таймаут можно регулировать. Для этого в «1С:Предприятие» в справочнике » Настройки обмена («Первая форма») » откройте предопределенный элемент » Общие настройки » и в поле » Таймауты WS » увеличьте значение в поле » Прокси » – укажите, сколько секунд сервер 1С должен ждать ответа от сервера «Первой Формы» до обрыва соединения. Если указать значение 0, то таймаут не ограничен (сервер будет ждать до тех пор, пока операция не будет выполнена).
В поле » Определение » указывается длительность подключения к сервису (в секундах), а в поле » Прокси » – длительность выполняемой операции внутри «Первой Формы» (в секундах).
Недостаточно прав доступа в 1С
При обмене данными может возникать следующая ошибка:
«Error while calling 1С service. Нарушение прав доступа к операции Web-сервиса:
Причина возникновения ошибки связана с недостатком прав пользователя на стороне приложения «1С:Предприятие». Для исправления необходимо в конфигураторе «1С:Предприятие» проверить роли у пользователя, который указан в «Первой Форме» в настройках для подключения (атрибут OneCUserName в XML-настройках), и убедиться, что хотя бы одна из этих ролей имеет доступ к сервису.
Не выполняются регламентные задания
Если на стороне «1С:Предприятие» задания в очередь ставятся и видны в регистре сведений «Очередь обмена (Первая Форма)», но не выполняются, необходимо убедиться, что регламентное задание по обработке очереди есть в системе, оно включено, и регламентные задания не заблокированы на стороне сервера.
1. Проверка существования регламентного задания.
В пакете «Модуль 1С», скачиваемом через интерфейс администратора «Первой Формы», есть папка «Диагностика», в которой находится внешняя обработка «Консоль заданий.epf». Этот файл необходимо открыть в режиме «1С:Предприятие». Появится окно, в котором будут отображены все регламентные задания в системе. Задание модуля синхронизации имеет название «Очередь обмена с Первой Формой».
2. Проверка, что задание включено.
В «Консоли Заданий» можно просмотреть, включена ли обработка и какой период ее выполнения.
3. Проверка блокировки.
На сервере «1С:Предприятие» можно полностью блокировать выполнение всех регламентных заданий (т.е. при блокировке все регламентные задания будут простаивать). Эту блокировку должны снимать специалисты «1С:Предприятие», т.к. нужно учитывать, какие из регламентных заданий уже включены и к каким последствиям это приведет.
4. Поиск и проверка объектов, вызвавших ошибки синхронизации.
В пакете «Модуль 1С», скачиваемом через интерфейс администратора «Первой Формы», есть папка » Диагностика «, в которой находится внешняя обработка » ГУИДОбъекта.epf «. Этот файл необходимо открыть в режиме «1С:Предприятие». С помощью обработки можно:
• определить объект, вызвавший ошибку при синхронизации с «Первой Формой», и проверить правильность заполнения его реквизитов. Для этого выберите тип объекта в поле «Объект», введите его GUID в поле «ГУИД» и затем нажмите кнопку «Найти по ГУИД». GUID и тип объекта можно посмотреть в журнале ошибок синхронизации.
Нераспознанная версия сообщения
Если при любом обращении «Первой Формы» к 1С появляется сообщение
System.ServiceModel.CommunicationException: Нераспознанная версия сообщения/Unrecognized message version
Синхронизация скрытых и «только для чтения» колонок ДП «Таблица»
Если в категории «Первой Формы» присутствует ДП «Таблица», в которой есть скрытые колонки или колонки с признаком «только для чтения», то данные для них перед отправкой берутся не из карточки задачи, а непосредственно из базы данных перед отправкой в 1С. Чтобы обмен данными в этом случае работал корректно, необходимо использовать очередь обмена, а не обмен данными в режиме онлайн. См. здесь.
Не загружаются данные из справочника 1С
Из-за ограничений на количество символов объекты с длинными названиями могут не сопоставляться. Попробуйте в 1С увеличить длину полей.
Неверный адрес сервиса 1С
В журнале ошибок есть ошибка вида:
Request format is unrecognized for URL unexpectedly ending in ‘/TC1CService.asmx’.
Это может означать, что в пользовательских настройках приложения в поле TC1C_ServiceAppAddress указан неверный адрес.
1С SOAP веб-сервис / проблема отправки XML
Всем доброго дня. Уже писал пост на эту тему.
Имеется сторонний SOAP веб-сервис. Вот выдержка из описания:
«API cистемы «****-Информ» представляет собой SOAP веб сервис, взаимодействие с которым осуществляется по протоколу HTTP или HTTPS. Пользователю предоставляется пара [логин, пароль], с помощью которых можно пользоваться сервисом.»
У этого веб-сервиса есть метод:
Через программу SOAPUI мне удалось подрубиться к этому сервису и даже получаю отклики по этому методу.
Проблема возникла на стороне 1С: не знаю как синтаксически подрубиться.
ЗащищенноеСоединениеOpenSSL = Новый ЗащищенноеСоединениеOpenSSL(Новый СертификатКлиентаWindows(), Новый СертификатыУдостоверяющихЦентровWindows);
ИмяВебСервиса = «http://ws.prima-inform.ru/PrimaService.asmx?wsdl";;
WSОпределение = Новый WSОпределения(ИмяВебСервиса, ИмяПользователя, Пароль. ЗащищенноеСоединениеOpenSSL);
ВСДанные = WSОпределение.Сервисы[0];
Прокси = Новый WSПрокси(WSОпределение, ВСДанные.URIПространстваИмен, ВСДанные.Имя, ВСДанные.ТочкиПодключения[0].Имя. ЗащищенноеСоединениеOpenSSL);
Прокси.Пользователь = ИмяПользователя;
Прокси.Пароль = Пароль;
ЗапросТип = Прокси.ФабрикаXDTO.Тип(«http://ws.****-inform.ru/", «GetServiceInfo»);
Запрос = Прокси.ФабрикаXDTO.Создать(ЗапросТип);
В последней строчке кода выходит ошибка с кучей непонятной 1С-ку с небольшим стажем работы иероглифами.
Подскажите, может я не так подрубаюсь к сервису?
В инете инфы не нашел достаточной, а если и нашел, то не смог додуматься.
(9) В общем все получилось, использовал HTTP соединение и HTTP запросы. Все вроде бы хорошо отрабатывает, ответ приходит, как в SOAP UI.
У этого сервиса есть метод «GetFullReport», вот выдержка из инструкции:
На входе у этого метода следующие параметры:
— requestId (Идентификатор запроса)
— format (Формат отчета. В данном методе формат может принимать только следующие значения: Xml, Json, Pdf).
В SOAP UI формирую следующий XML:
‘3’ is not a valid value for ReportFormat
и
— format (Формат отчета. В данном методе формат может принимать только следующие значения: Xml, Json, Pdf
Добрый день. Надо «научить» 1С ERP «общаться» с некой программой. Был выдан WS ссылка, подцепил её к 1С в общие метаданные «WS-ссылки» получил описания пакетов, составил по присланному XDTO длинную XML строку, а при отсылке этой длинной строки с помощью описанного метода SendMessage получаю ошибку :
При вызове веб-сервиса произошла ошибка. Ошибка SOAP сервера: Указанное в сообщении действие SOAP, «», не соответствует действию HTTP SOAP, «http://********/********ServiceContract/SendMessage».
Код ошибки: Sender.ActionMismatch
Техническая информация:
a:Action
по причине:
При вызове веб-сервиса произошла ошибка. Ошибка вызова операции сервиса:
по причине:
При вызове веб-сервиса произошла ошибка. Ошибка SOAP сервера: Указанное в сообщении действие SOAP, «», не соответствует действию HTTP SOAP, «http://*******/*******ServiceContract/SendMessage».
Код ошибки: Sender.ActionMismatch
Техническая информация:
a:Action
Потом решили сделать более универсально данные поws ссылке в РС прописываются. оттуда и «ВыборкаНастроек».
Описание, Прокси создаётся без ошибок, WSПараметры создаются заполняются без ошибок. При SendMessage ошибка.
Создавал прокси по общему объекту WSСсылки и конструктором и напрямую прописывал параметры и через вызов определения и т.д. и т.п. Авторизация при подключении прокси не нужна.
Что это вообще может быть? Не нашел описания буквально нигде.
Не могу заставить работать Web сервис, ошибка XDTO
Здравствуйте!
Надеюсь на вашу помощь, бьюсь безрезультатно уже который день, как в стену уперся (
Ситуация такая. Есть сайт, предоставляющий веб сервис рассылки смс, адрес WSDL пакета таков:
http://promotion.md:8080/ecm/services/soap?wsdl
Создаю в конфигурации объект «WS-Ссылка», все создается без проблем.
Необходимо реализовать работу с этим сервисом из 1С.
Написал простенькую обработочку, которая обращается к функции GetCurrentCredit этого веб сервиса.
Прокси = WSСсылки.SMS.СоздатьWSПрокси(«http://soap.ecm.emotion.com/»,»EcmService»,»EcmServicePort»);
Фабрика = Прокси.ФабрикаXDTO;
ПараметрТип = Фабрика.Тип(«http://soap.ecm.emotion.com/»,»GetCurrentCredit»);
ЛогинТип = Фабрика.Тип(«http://soap.ecm.emotion.com/»,»auth»);
Логин = Фабрика.Создать(ЛогинТип);
Логин.username = «username»;
Логин.password = «password»;
РезультатТип = Фабрика.Тип(«http://soap.ecm.emotion.com/»,»result»);
Результат = Фабрика.Создать(РезультатТип);
Результат = Прокси.GetCurrentCredit(Логин);
После запуска 1С думает и выкидывает вот такую вот ошибку:
Причем ошибка не зависит от того, присваиваю ли я возвращаемый результат чему-то (в данном случае переменной Результат) или нет. Не зависит и от того, какие логин и пароль передаю. Возникает впечатление, что 1С просто не может обработать ответ с сервера. Что-то можно сделать? Может я что-то делаю не так? Очень прошу помощи, не первый день уже бьюсь с этой дрянью 🙁
Прокси soap-сервер. Когда 1С не может в SOAP
Вступление
Кто-то может сказать: «Ой, да что там руками формировать, XML простая». Однако протокол содержит некоторое количество расширений, таких как, например, WS-Addressing и WS-Security, которые могут превратить ручное формирование в боль.
На работе мне пришлось столкнуться с довольно замороченным soap-сервером, с которым не получалось легко работать из 1С. Сегодняшняя моя статья про то, как можно разработать легковесную прослойку между 1С и soap-сервером, принимающую в себя обычный http-запрос и перекладывающую содержимое в вызов soap-сервера. Естественно, код в статье максимально упрощен для простоты восприятия. Код работающего у меня production-решения сильно отличается от указанного примера и более «архитектурный» :).
Подготовка
В качестве инструмента для решения задачи я буду использовать node.js. Почему? Во-первых, мне так удобнее: я его знаю :). Во-вторых, на нем есть простые для запуска библиотеки для построения веб-приложений, работы с soap и кластеризацией. В качестве редактора я рекомендую использовать Visual Studio Code, но это уже дело вкуса. Тренироваться будем на классическом сервисе курсов валют.
После сразу установим все библиотеки, которые нам понадобятся для нашей прослойки с помощью команды:
Файл с wsdl положим в корень каталога с именем DailyInfo.wsdl в кодировке UTF-8.
Для достижения нашей цели нам надо решить следующие задачи:
Написать веб-сервер, который сможет принимать POST запросы (это совсем не так сложно, как звучит).
Подключиться к soap-серверу как клиент.
Преобразовать входящий POST-запрос в вызов soap-метода и вернуть на клиент результат.
Страшно? 10 минут, помните?
Реализация – веб-сервер
Этим небольшим скриптом мы сразу же решили задачу №1 из нашего списка. Осталось запустить и проверить.
Для запуска приложения у нас есть два варианта:
запуск из командной строки через node index.js;
запуск отладчика в VSCode.
С первым вариантом все просто: вбили в консоль и радуемся:
Останавливаем работу через Ctrl-C.
Отладчик VSCode запускается по кнопке F5. В выпадающем меню надо выбрать Node.js:
После выбора node.js на вкладке Debug console можно убедиться, что наше приложение запустилось и готово обрабатывать запросы:
Для проверки работоспособности я воспользуюсь чудесным инструментом отладки http-запросов Postman:
В ответе сервиса видим, что он не может обработать 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.
Для начала добавим пакет XDTO в конфигурацию 1С. Если WSDL от поставщика soap-сервера читается, можно сразу добавить WS-ссылку. Сэмулируем проблему «нечитабельности» wsdl и добавим XDTO пакет вручную. В этом нам поможет знание о том, что WSDL содержит XSD для содержимого всех сообщений и методов.
Вытащим из WSDL все содержимое тега s:schema в отдельный файл и перенесем объявление пространства имен s из заголовка WSDL в заголовок нового файла. Получится что-то вроде такого:
Сохраним содержимое в файл с разрешением XSD, и, если все прошло успешно, полученная схема успешно импортируется в конфигуратор как XDTO пакет:
Если от вендора пришла «нечитаемая» в 1С XSD, то использование фабрики XDTO из следующего примера не имеет смысла, однако десериализацию из JSON будет просто написать по аналогии с сериализацией.
Для формирования запросов создадим внешнюю обработку со следующим кодом:
Некоторые пояснения по коду.
Первое, за что может зацепиться взгляд – использование «обычной» ЗаписиJSON вместо ФабрикиXDTO. Причина тут довольно проста – ФабрикаXDTO умеет записывать произвольные типы, но с «мусорными» тегами “#value” и “#type” (тип добавляется, только если это указано явно в настройках записи). Наш промежуточный сервер ни про какие value ничего не знает. Выхода тут два – либо научить понимать сервер, либо использовать упрощенный сериализатор на базе структуры и записи. Выбор за вами.
Второе – пляски с бубном вокруг ФабрикиXDTO. Это всего лишь проверка валидности нашего сообщения. Мы же порядочные граждане, хотим быть уверены, что мы не шлем soap-серверу что-то, чего он не ожидает. В конкретно данном случае дополнительный реверанс пришлось сделать для получения типа создаваемого свойства, т. к. исходная wsdl вообще не содержит явных описаний типов значений, а только описания свойств с вложенными описаниями типов.
А вот чтение сообщения мы уже выполним «честной» ФабрикойXDTO для получения объекта XDTO и возможности работы в объектной модели.
Ставим в конец процедуры точку останова, выполняем обработку… Вуаля:
Кластеризация
Окей, сервис готов, можно в прод? 🙂
Если не страшно, то можно сразу и в прод, однако, я бы на вашем месте помимо обработки ошибок и общего причесывания кода добавил бы еще одну вещь. Node.js штука хоть и быстрая, но не всемогущая. Возможно вам знакома фраза, что «нода – асинхронная, но однопоточная». В новых версиях node.js уже появилась честная поддержка многопоточности, но для простоты воспользуемся другим старым и проверенным механизмом – кластеризацией. А асинхронность обработки в нашем случае есть, но нам не помешает воспользоваться дешевым ускорителем.
Ставим пакет cluster-service с помощью команды:
Запускаем наше приложение в командной строке, но в вместо node укажем приложение cservice:
Наш промежуточный сервис запустился в режиме кластера с количеством потоков, равным количеству логических процессоров. Можете выполнить нагрузочное тестирование через тот же SoapUI и замерить количество обрабатываемых запросов в секунду при обычном запуске и при кластеризованном запуске – заметите ощутимую разницу.
Что там было про WS-Addressing?
Ах-да, заголовки, те самые soap-headers, которые не поддерживает 1С. Добавить их довольно просто – для этого в soapClient есть метод addSoapHeaders, в который можно передать либо готовую строку с заголовками, либо JS-объект. Попробуем реализовать добавление пары заголовков семейства WS-Addressing, а именно Action и MessageID.
Для генерации UUID сообщения установим библиотеку uuid:
Добавим ее в секцию импорта библиотек:
Между проверкой указателя на soap-метод и самим вызовом soap-метода добавим заполнение заголовков:
Убедиться в корректности отправляемых заголовков можно через тот же SoapUI или настроив логирование запросов в промежуточном сервере.
Дополнительные вопросы
— А зачем JSON? Можно гонять туда-сюда XML?
— Можно, но зачем, если есть возможность гонять более легковесный JSON, а 1С уже умеет нативно с ним работать?
— Можно ли накрыть авторизацией?
— Можно, причем и веб-приложение (для этого надо добавить еще один middle-ware с авторизацией в вызов app.post), и soap-сервер, который можно поднять в этом же приложении как сервис обратного вызова в случае асинхронного soap-обмена.
Заключение
Вот таким нехитрым способом мы смогли обойти ограничение возможностей платформы 1С, таких как отсутствие поддержки soap-headers и не полной поддержки WSDL-описания.
Не бойтесь использовать другие языки в своей работе. Даже начальный уровень знаний какого-либо языка, фреймворка или технологии может существенно сократить вам время на разработку требуемой функциональности.
Полный код получившегося приложения, а также исходники обработки доступны в репозитории на GitHub.