Подключение к веб-сервису SAP
Прислали ссылку на веб сервис и отдельно файл wsdl.
true Integrated Configuration | BC_1C_NEFZ | si_DataLoad_outb_sync | |
true Integrated Configuration | BC_1C_NEFZ | si_DataSave_outb | |
В браузере поссылке открывается окно с текстом:
Message Servlet is in Status OK
Status information:
Servlet com.sap.aii.adapter.soap.web.MessageServlet (Version $Id: //tc/xpi.adapters/NW750EXT_22_REL/src/_soap_application_web_module/we
Classname ModuleProcessor: null
Lookupname for localModuleProcessorLookupName: localejbs/ModuleProcessorBean
Lookupname for remoteModuleProcessorLookupName: null
ModuleProcessorClass not instantiated
ModuleProcessorLocal is Instance of com.sun.proxy.$Proxy472
ModuleProcessorRemote not instantiated
Файл загрузили в WSСсылки. Пытаюсь подключиться к веб-сервису и получаю ошибку:
Ошибка при вызове конструктора (WSПрокси)
{ВнешняяОбработка.ПроверкаВэбСервисаОтветхранение.Форма.Форма.Форма(99)}: Прокси = Новый WSПрокси(Определение, "https://piservice.severstal.com:7000/XISOAPAdapter/MessageServlet?senderParty=&senderService=BC_1C_NEFZ&receiverParty=&receive
по причине:
Сервис не найден. {}:si_DataLoad_outb_syncBinding
Что не так?
true Integrated Configuration | BC_1C_NEFZ | si_DataLoad_outb_sync | |
true Integrated Configuration | BC_1C_NEFZ | si_DataSave_outb | |
В браузере поссылке открывается окно с текстом:
Message Servlet is in Status OK
Status information:
Servlet com.sap.aii.adapter.soap.web.MessageServlet (Version $Id: //tc/xpi.adapters/NW750EXT_22_REL/src/_soap_application_web_module/we
Classname ModuleProcessor: null
Lookupname for localModuleProcessorLookupName: localejbs/ModuleProcessorBean
Lookupname for remoteModuleProcessorLookupName: null
ModuleProcessorClass not instantiated
ModuleProcessorLocal is Instance of com.sun.proxy.$Proxy472
ModuleProcessorRemote not instantiated
Файл загрузили в WSСсылки. Пытаюсь подключиться к веб-сервису и получаю ошибку:
Ошибка при вызове конструктора (WSПрокси)
{ВнешняяОбработка.ПроверкаВэбСервисаОтветхранение.Форма.Форма.Форма(99)}: Прокси = Новый WSПрокси(Определение, "https://piservice.severstal.com:7000/XISOAPAdapter/MessageServlet?senderParty=&senderService=BC_1C_NEFZ&receiverParty=&receive
по причине:
Сервис не найден. {}:si_DataLoad_outb_syncBinding
ssl1 = Новый ЗащищенноеСоединениеOpenSSL(Новый СертификатКлиентаWindows(СпособВыбораСертификатаWindows.Авто), Новый СертификатыУдостоверяющихЦентровWindows());
Определение = Новый WSОпределения("C:/Users/savina.ikt/Documents/BC_SYS_CLNT_si_DataLoad_outb_syncService_1.wsdl", Пользователь, Пароль,,,ssl1);
Прокси = Новый WSПрокси(Определение, "https://piservice.severstal.com:7000/XISOAPAdapter/MessageServlet?senderParty=&senderService=BC_1C_NEFZ&receiverParty=&receive ПоказатьЧто не так?
Прикрепленные файлы:
По теме из базы знаний
- Настройка удаленного хранилища конфигурации 1С 8.1 ( HTTP)
- Интеграция SAP и 1С8
- Механизмы и транспорт обмена данными. Пример создания в КД 2.1 правил обмена данными ЗУП 2.5 -> БП 3.0. Выгрузка ведомостей и банковских счетов. Передача параметров обмена из Источника в Приемник. ВыгрузитьПоПравилу(). ПередатьОдинПараметрВПриемник().
- Опыт внедрения ESB (интеграционной шины) в ПАО "Газпром нефть"
- Лайфхаки: Ускоряем и «расшиваем» сложные обмены
Найденные решения
(1)
Там же механика простая как три копейки. Есть файл wsdl определения. Откуда он берется - вообще безразлично, с диска, с сети, скачивается по урлу с параметрами. Внутри этого файла уже есть описание сервисов - их имена, пространство имен, и точки подключения - те самый адреса,по которым надо дергать сервер для вызова метода сервиса.
Создаешь Новый WSОпределения по файлу, ставишь точку останова и в живую наблюдаешь значения этих свойств. Выбираешь оттуда глазками эти самые имена сервисов, их пространство имен, имена точек подключений.
Потом делаешь WSПрокси по этому определению, по нужным пространству имен сервиса (где твои методы), имени сервиса (где твои методы), и точки подключения. И этот твой корявый адрес с параметрами туда ну никак пихать не надо.
Фактическое соединение будет устанавливаться при вызове метода у WSПрокси по адресу, который содержит точка подключения, который ты выбрал в конструкторе WSПрокси. Адрес этот только для чтения, потому что он определяется в файле, по которому ты WSОпределения создавал.
И никакого отношения этот адрес к адресу, по которому традиционно wsdl получают - "..?wsdl" не имеет. Там всё что угодно может быть.
P.S.
В конструкторе WSПрокси параметр Местоположение есть, я про него и забыл. Он как раз и позволяет переопределить адрес из точки подключения, указанный в файле.
Файл загрузили в WSСсылки.
Нахрен ты уже вторую тему за эти WSСсылки цепляешся-то?
Там же механика простая как три копейки. Есть файл wsdl определения. Откуда он берется - вообще безразлично, с диска, с сети, скачивается по урлу с параметрами. Внутри этого файла уже есть описание сервисов - их имена, пространство имен, и точки подключения - те самый адреса,по которым надо дергать сервер для вызова метода сервиса.
Создаешь Новый WSОпределения по файлу, ставишь точку останова и в живую наблюдаешь значения этих свойств. Выбираешь оттуда глазками эти самые имена сервисов, их пространство имен, имена точек подключений.
Потом делаешь WSПрокси по этому определению, по нужным пространству имен сервиса (где твои методы), имени сервиса (где твои методы), и точки подключения. И этот твой корявый адрес с параметрами туда ну никак пихать не надо.
Фактическое соединение будет устанавливаться при вызове метода у WSПрокси по адресу, который содержит точка подключения, который ты выбрал в конструкторе WSПрокси. Адрес этот только для чтения, потому что он определяется в файле, по которому ты WSОпределения создавал.
И никакого отношения этот адрес к адресу, по которому традиционно wsdl получают - "..?wsdl" не имеет. Там всё что угодно может быть.
P.S.
В конструкторе WSПрокси параметр Местоположение есть, я про него и забыл. Он как раз и позволяет переопределить адрес из точки подключения, указанный в файле.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Там же механика простая как три копейки. Есть файл wsdl определения. Откуда он берется - вообще безразлично, с диска, с сети, скачивается по урлу с параметрами. Внутри этого файла уже есть описание сервисов - их имена, пространство имен, и точки подключения - те самый адреса,по которым надо дергать сервер для вызова метода сервиса.
Создаешь Новый WSОпределения по файлу, ставишь точку останова и в живую наблюдаешь значения этих свойств. Выбираешь оттуда глазками эти самые имена сервисов, их пространство имен, имена точек подключений.
Потом делаешь WSПрокси по этому определению, по нужным пространству имен сервиса (где твои методы), имени сервиса (где твои методы), и точки подключения. И этот твой корявый адрес с параметрами туда ну никак пихать не надо.
Фактическое соединение будет устанавливаться при вызове метода у WSПрокси по адресу, который содержит точка подключения, который ты выбрал в конструкторе WSПрокси. Адрес этот только для чтения, потому что он определяется в файле, по которому ты WSОпределения создавал.
И никакого отношения этот адрес к адресу, по которому традиционно wsdl получают - "..?wsdl" не имеет. Там всё что угодно может быть.
P.S.
В конструкторе WSПрокси параметр Местоположение есть, я про него и забыл. Он как раз и позволяет переопределить адрес из точки подключения, указанный в файле.
Файл загрузили в WSСсылки.
Нахрен ты уже вторую тему за эти WSСсылки цепляешся-то?
Там же механика простая как три копейки. Есть файл wsdl определения. Откуда он берется - вообще безразлично, с диска, с сети, скачивается по урлу с параметрами. Внутри этого файла уже есть описание сервисов - их имена, пространство имен, и точки подключения - те самый адреса,по которым надо дергать сервер для вызова метода сервиса.
Создаешь Новый WSОпределения по файлу, ставишь точку останова и в живую наблюдаешь значения этих свойств. Выбираешь оттуда глазками эти самые имена сервисов, их пространство имен, имена точек подключений.
Потом делаешь WSПрокси по этому определению, по нужным пространству имен сервиса (где твои методы), имени сервиса (где твои методы), и точки подключения. И этот твой корявый адрес с параметрами туда ну никак пихать не надо.
Фактическое соединение будет устанавливаться при вызове метода у WSПрокси по адресу, который содержит точка подключения, который ты выбрал в конструкторе WSПрокси. Адрес этот только для чтения, потому что он определяется в файле, по которому ты WSОпределения создавал.
И никакого отношения этот адрес к адресу, по которому традиционно wsdl получают - "..?wsdl" не имеет. Там всё что угодно может быть.
P.S.
В конструкторе WSПрокси параметр Местоположение есть, я про него и забыл. Он как раз и позволяет переопределить адрес из точки подключения, указанный в файле.
(3) Спасибо большое за разьяснения, вроде бы понимание появляется...
Далее ошибка порт не найден. Что делать? Куда смотреть? Soap12 пробовали.
Ошибка при вызове конструктора (WSПрокси)
{ВнешняяОбработка.ПроверкаВэбСервисаОтветхранение.Форма.Форма.Форма(99)}: Прокси = Новый WSПрокси(Определение, "http://severstal.com/pi/O2C/1C", "si_DataLoad_outb_syncService", "si_DataLoad_outb_syncServiceSoap",, , ssl1);
по причине:
Порт не найден. {}:si_DataLoad_outb_syncService:si_DataLoad_outb_syncServiceSoap
Далее ошибка порт не найден. Что делать? Куда смотреть? Soap12 пробовали.
Ошибка при вызове конструктора (WSПрокси)
{ВнешняяОбработка.ПроверкаВэбСервисаОтветхранение.Форма.Форма.Форма(99)}: Прокси = Новый WSПрокси(Определение, "http://severstal.com/pi/O2C/1C", "si_DataLoad_outb_syncService", "si_DataLoad_outb_syncServiceSoap",, , ssl1);
по причине:
Порт не найден. {}:si_DataLoad_outb_syncService:si_DataLoad_outb_syncServiceSoap
В SOAPUi подключение проходит (см.скрин).
В 1с не получается подключиться
Ошибка при вызове конструктора (WSПрокси)
{ВнешняяОбработка.ПроверкаВэбСервисаОтветхранение.Форма.Форма.Форма(399)}: Прокси = Новый WSПрокси(Определение, "https://piservice.severstal.com:7000/XISOAPAdapter/MessageServlet?senderParty=&senderService=BC_1C_NEFZ&receiverParty=&receive
по причине:
Сервис не найден. {}:si_DataLoad_outb_syncService
В чем искать проблему?
Если процедуре задать URIПространстваИменСервиса = подключение происходит, но ошибка 403 возникает в момент получения данных Прокси.MX1(WSПараметр).
По смыслу это нев ерно т.к. ссылка - является внутренним пространством имен.
В 1с не получается подключиться
ssl1 = Новый ЗащищенноеСоединениеOpenSSL(Новый СертификатКлиентаWindows(СпособВыбораСертификатаWindows.Авто), Новый СертификатыУдостоверяющихЦентровWindows());
Определение = Новый WSОпределения("C:/Users/savina.ikt/Documents/Severstal/ws2/BC_SYS_CLNT_si_DataLoad_outb_syn ПоказатьОшибка при вызове конструктора (WSПрокси)
{ВнешняяОбработка.ПроверкаВэбСервисаОтветхранение.Форма.Форма.Форма(399)}: Прокси = Новый WSПрокси(Определение, "https://piservice.severstal.com:7000/XISOAPAdapter/MessageServlet?senderParty=&senderService=BC_1C_NEFZ&receiverParty=&receive
по причине:
Сервис не найден. {}:si_DataLoad_outb_syncService
В чем искать проблему?
Если процедуре задать URIПространстваИменСервиса = подключение происходит, но ошибка 403 возникает в момент получения данных Прокси.MX1(WSПараметр).
По смыслу это нев ерно т.к. ссылка - является внутренним пространством имен.
Прикрепленные файлы:
(5)
Иди уже на курсы.
Прокси = Новый WSПрокси(Определение, "https://piservice.severstal.com:7000/XISOAPAdapter/MessageServlet?senderParty=&senderService=BC_1C_NEFZ&receiverParty=&receiverService=&interface=si_DataLoad_outb_sync&interfaceNamespace=http://severstal.com/pi/O2C/1C", "si_DataLoad_outb_syncService", "HTTPS_Port",, , ssl1);
является внутренним пространством имен.
Иди уже на курсы.
(2)Несомненно Ваша статья очень полезна! Но вопросы всетаки остались.
Через пердложенное Вами расширение bomerang подключение не состоялось (см скрины). В др програмке SoapUI подключение успешно с параметром - предварительная авторизация. Может быть в этом дело и как этот момент обойти? В 1с все также - сервис не найден. Со стороны SAP утверждают, что с их сервисом работают из 1с успешно.
Через пердложенное Вами расширение bomerang подключение не состоялось (см скрины). В др програмке SoapUI подключение успешно с параметром - предварительная авторизация. Может быть в этом дело и как этот момент обойти? В 1с все также - сервис не найден. Со стороны SAP утверждают, что с их сервисом работают из 1с успешно.
Прикрепленные файлы:
Тут другая ситуация. Непосредственно к wsdl файлу по ссылке они доступ не предоставляют. wsdl файл прислали отдельно и его мы загружаем как статическую ws ссылку или динамически с непосредственно с рабочей станции. При этом подключение к сервису происходит, а при обращении к его методу МХ1() выдает ошибку 403.
(12)
(12) В крупных компаниях, когда м/у разработчиком и конечной целью куча промежуточных лиц концов не найти.
Да все уже забили на эту задачуу) Чисто мой интерес научиться получать документы ч/з веб-сервис. На данном этапе подключение свершилось. Со своей стороны настройки и код не меняли. Видимо, на стороне источника, доступ донастроили. Теперь нужно разобрать ОбъектXDTO.
(12) В крупных компаниях, когда м/у разработчиком и конечной целью куча промежуточных лиц концов не найти.
Да все уже забили на эту задачуу) Чисто мой интерес научиться получать документы ч/з веб-сервис. На данном этапе подключение свершилось. Со своей стороны настройки и код не меняли. Видимо, на стороне источника, доступ донастроили. Теперь нужно разобрать ОбъектXDTO.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот