Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: Bpar  Еще офтоп Автор: Inviz
Я добавил еще один импорт в типы и все сгенирилось через wsimport нормально
<wsdl:types>
<xsd:schema targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" xmlns:smev="http://smev.gosuslugi.ru/rev120315">
<xsd:import schemaLocation="xsd/request/smev.unifo.rev120315.xsd" namespace="http://smev.gosuslugi.ru/rev120315"/>
<xsd:import schemaLocation="xsd/request/Message.xsd" namespace="http://roskazna.ru/gisgmp/xsd/116/Message"/>
<xsd:element name="GISGMPTransferMsg" type="smev:BaseMessageType"/>
</xsd:schema>
</wsdl:types>
При попытке импорта xsd схем выдается ошибка wsdl.exe /language:cs SmevGISGMPService.wsdl Ошибка. Не удается импортировать привязку "SmevGISGMPServiceSOAP" из пространства имен "http://roskazna.ru/gisgmp/0 2000000/SmevGISGMPService/". - Не удается импортировать операцию "GISGMPTransferMsg". - Отсутствует тип данных "http://smev.gosuslugi.ru/rev120315:BaseMessageType". Архив со схемами распакован в тот-же каталог с сохранением иерархии каталогов. Что делать, подскажите. Импорта куда? Что вы из этих схем хотите получить? Если просто классы, то скачайте архив с подправленным wsdl и схемами, что я выкладывал несколькими страницами выше. С помощью apache cxf (http://cxf.apache.org/docs/wsdl-to-java.html) получите из wsdl корректный набор классов. Если хотите клиент к вебсервису сгенерить, то тут не помогу.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 05.08.2014(UTC)
Сообщений: 12
Поблагодарили: 2 раз в 2 постах
|
Автор: ARnikev
Импорта куда? Что вы из этих схем хотите получить? Если просто классы, то скачайте архив с подправленным wsdl и схемами, что я выкладывал несколькими страницами выше. С помощью apache cxf (http://cxf.apache.org/docs/wsdl-to-java.html) получите из wsdl корректный набор классов. Если хотите клиент к вебсервису сгенерить, то тут не помогу.
Дело в том, что и Ваш архив и оригинальный wsdl генерят только некоторые классы. Вот что пишет техподдержка: В xsd схеме форматов 1.16 отсутствуют ссылки на данные xsd как в форматах 1.15 и соответственно автоматически не подтянуться.. Например, в xsd-схемах есть BudgetIndex, Charge и др., а в результирующем коде и классах, генерируем wsdl их нет.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: Bpar Автор: ARnikev
Импорта куда? Что вы из этих схем хотите получить? Если просто классы, то скачайте архив с подправленным wsdl и схемами, что я выкладывал несколькими страницами выше. С помощью apache cxf (http://cxf.apache.org/docs/wsdl-to-java.html) получите из wsdl корректный набор классов. Если хотите клиент к вебсервису сгенерить, то тут не помогу.
Дело в том, что и Ваш архив и оригинальный wsdl генерят только некоторые классы. Вот что пишет техподдержка: В xsd схеме форматов 1.16 отсутствуют ссылки на данные xsd как в форматах 1.15 и соответственно автоматически не подтянуться.. Например, в xsd-схемах есть BudgetIndex, Charge и др., а в результирующем коде и классах, генерируем wsdl их нет. С оригинального генерятся не все классы, это правда, а вот с архива, который я выкладывал, все генерится корректно. Вроде как товарищ afev его же использовал для генерации классов. Наверное что-то не так делаете.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8
Поблагодарили: 2 раз в 1 постах
|
Автор: belgampaul Автор: ARnikev Автор: belgampaul
Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли.
Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились.
В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.
Что значит на другом статусе документ выгружаете? Вы убедились что ошибка в этом, удалось в итоге импортировать что-то корректно на тестовый сервис? Я только что проверил у себя, у меня все префиксы и сущность в целом остается неизменной, что до подписи, что после, что перед самой отправкой сообщения в ГИС ГМП... >>Что значит на другом статусе документ выгружаете? Это значит, что сущность подписывается на одном статусе, а пакет отправляется на другом. В пакете раньше пространства имен в сущности могли отличаться от тех, что были использованы при подписании, т.к. jaxb по-умолчанию сам выбирает префиксы. Выгрузить пока не удалось. Что удалось выяснить, так это-то, что код в архиве с первой страницы содержит ошибку. Во всяком случае DigestValue, для сущности неправильно генерит с корректного примера. Но для нас эта проблема неактуальна. Система использует нативный КриптоПро провайдер. Все. Выгрузилось без ошибки. Краткое содержание наших крупных ошибок: 1. Для DigestValue генерировался неправильный хэш, т.к. данные приходили для подписи в кодировке UTF-16LE. 2. После исправления п. 1. DigestValue был неверным из-за отличающихся пространств имен в сущности и той же сущности в пакете. 3. После исправления п. 2. SignatueValue был неверным (подпись сама). Это был самая тяжелая ошибка. Суть ее описана http://www.cryptopro.ru/....aspx?g=posts&t=6288Коротко: результат хэша нужно инвертировать побайтно. Если кому понадобится, могу выложить xml с запросом на импортом и сертификат с закрытым ключом для ЭП-СП, чтобы была возможность контролировать правильность вычислений поэтапно. Ну и библиотеку могу выложить сгенеренную с wsdl. Там правда неймспейсы подкорректированы. Отредактировано пользователем 30 июня 2015 г. 17:22:06(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963  Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Если не сложно, выложите, могут пригодиться. |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8
Поблагодарили: 2 раз в 1 постах
|
Автор: afev Если не сложно, выложите, могут пригодиться.  2015_06_30_22_01_19_271_request.txt (8kb) загружен 33 раз(а). 2015_06_30_22_01_23_535_response.txt (13kb) загружен 19 раз(а). EPSPGISGMP.pfx.txt (2kb) загружен 20 раз(а). 2015_06_30_22_01_13_415_response.txt (12kb) загружен 18 раз(а). 2015_06_30_22_01_07_546_request.txt (17kb) загружен 26 раз(а).Файлики приаттачил (запрос иморта платежа -> ответ; запрос статуса запроса -> ответ). Сертификат и закрытый ключ.Расширение txt убираете и импортируете. ГИС ГМП ответит ошибкой, что УИП некорректный, но это совсем другая история ) Отредактировано пользователем 1 июля 2015 г. 1:29:50(UTC)
| Причина: Не указана
|
 2 пользователей поблагодарили belgampaul за этот пост.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: belgampaul Все. Выгрузилось без ошибки. Краткое содержание наших крупных ошибок: 1. Для DigestValue генерировался неправильный хэш, т.к. данные приходили для подписи в кодировке UTF-16LE. 2. После исправления п. 1. DigestValue был неверным из-за отличающихся пространств имен в сущности и той же сущности в пакете. 3. После исправления п. 2. SignatueValue был неверным (подпись сама). Это был самая тяжелая ошибка. Суть ее описана http://www.cryptopro.ru/....aspx?g=posts&t=6288Коротко: результат хэша нужно инвертировать побайтно. Если кому понадобится, могу выложить xml с запросом на импортом и сертификат с закрытым ключом для ЭП-СП, чтобы была возможность контролировать правильность вычислений поэтапно. Ну и библиотеку могу выложить сгенеренную с wsdl. Там правда неймспейсы подкорректированы. Можно про 2 пункт по-подробней, пожалуйста? Что значит сущности и сущности в пакете? Можно с примером? По поводу 3 пункта, вы какой библиотекой подписываете? Примером что afev выложил? На сколько я понимаю, для этого примера эта ошибка не актуальна, т.к. у меня при формировании запроса полностью руками, подпись сервисом проверяется корректно, не работает только при формировании запроса с помощью классов, полученных из wsdl сервиса? Можете выложить классы, которые вы получили с подкорректированного wsdl и кусок кода, который формирует сообщение?
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8
Поблагодарили: 2 раз в 1 постах
|
gisgmp_1.16.1.jar.txt (143kb) загружен 17 раз(а).Автор: ARnikev Можно про 2 пункт по-подробней, пожалуйста? Что значит сущности и сущности в пакете? Можно с примером? По поводу 3 пункта, вы какой библиотекой подписываете? Примером что afev выложил? На сколько я понимаю, для этого примера эта ошибка не актуальна, т.к. у меня при формировании запроса полностью руками, подпись сервисом проверяется корректно, не работает только при формировании запроса с помощью классов, полученных из wsdl сервиса? Можете выложить классы, которые вы получили с подкорректированного wsdl и кусок кода, который формирует сообщение? По 2 пункту уже выше писал. Еще раз повторюсь, значит. Пользователь подписывает документ стандартно в системе. В системе документы отличаются от тех, что мы выгружаем по нескольким (дополнительным) полям. Но подписывает пользователь по факту не документ системы, а сущность, которую отправит позднее. Т.е. в момент подписания, мы из документа собираем сущность и подписываем. Подпись храним в БД. Далее пользователь доводит документ до статуса Готов к выгрузке. Как только выбирает действие Выгрузить, сущность собирается заново. Точнее даже не только сущность собирается, а целиком запрос GISGMPTransferMsg. Если жестко не прописать в package-info.java префиксы для неймспейсов, то существует высокая вероятность, что префиксы будут отличаться от тех, что были сформированы для сущности, которую подписывали. Просто так написана система. Далее мы отправляем пакет. При отправке пакета подписей вообще нет. Их мы и вставляем в хэндлерах. Сначала подпись сущности достаем из базы (ds:Signature), потом уже весь пакет подписываем. Т.к. подпись подпихивали в уже сформированный soap документ, то несовпадение неймспейсов приводило к невалидности. По п.3: подписывает КриптоПро через нативный код. Ему Java прокидывает канонизированный SignedInfo в виде бинарного массива. Что касается куска кода, который формирует сообщение, то этим вопросом занимается JAX-WS на пару с JAXB. Я только передаю BaseMessage (что-то типа port.transferMsg(baseMessage)). Дальше как выше описал, отрабатывает хэндлер, смысл которого подпихнуть подпись сущности и затем наложить ЭП-ОВ. Сгенеренную библиотеку выложу как только смогу. Завтра точно. Имейте в виду, что префиксы неймспейсов там жестко прописаны. Могу и исходники в личку бросить. Библиотеку можно юзать как есть, там ничего лишнего нет. Отредактировано пользователем 2 июля 2015 г. 13:41:58(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: belgampaul Автор: ARnikev Можно про 2 пункт по-подробней, пожалуйста? Что значит сущности и сущности в пакете? Можно с примером? По поводу 3 пункта, вы какой библиотекой подписываете? Примером что afev выложил? На сколько я понимаю, для этого примера эта ошибка не актуальна, т.к. у меня при формировании запроса полностью руками, подпись сервисом проверяется корректно, не работает только при формировании запроса с помощью классов, полученных из wsdl сервиса? Можете выложить классы, которые вы получили с подкорректированного wsdl и кусок кода, который формирует сообщение? По 2 пункту уже выше писал. Еще раз повторюсь, значит. Пользователь подписывает документ стандартно в системе. В системе документы отличаются от тех, что мы выгружаем по нескольким (дополнительным) полям. Но подписывает пользователь по факту не документ системы, а сущность, которую отправит позднее. Т.е. в момент подписания, мы из документа собираем сущность и подписываем. Подпись храним в БД. Далее пользователь доводит документ до статуса Готов к выгрузке. Как только выбирает действие Выгрузить, сущность собирается заново. Точнее даже не только сущность собирается, а целиком запрос GISGMPTransferMsg. Если жестко не прописать в package-info.java префиксы для неймспейсов, то существует высокая вероятность, что префиксы будут отличаться от тех, что были сформированы для сущности, которую подписывали. Просто так написана система. Далее мы отправляем пакет. При отправке пакета подписей вообще нет. Их мы и вставляем в хэндлерах. Сначала подпись сущности достаем из базы (ds:Signature), потом уже весь пакет подписываем. Т.к. подпись подпихивали в уже сформированный soap документ, то несовпадение неймспейсов приводило к невалидности. По п.3: подписывает КриптоПро через нативный код. Ему Java прокидывает канонизированный SignedInfo в виде бинарного массива. Что касается куска кода, который формирует сообщение, то этим вопросом занимается JAX-WS на пару с JAXB. Я только передаю BaseMessage (что-то типа port.transferMsg(baseMessage)). Дальше как выше описал, отрабатывает хэндлер, смысл которого подпихнуть подпись сущности и затем наложить ЭП-ОВ. Сгенеренную библиотеку выложу как только смогу. Завтра точно. Имейте в виду, что префиксы неймспейсов там жестко прописаны. Могу и исходники в личку бросить. Библиотеку можно юзать как есть, там ничего лишнего нет. Ясно, у вас все сложно как-то). У нас вроде нет такого рода проблем. Спасибо за пояснения.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 04.06.2015(UTC)
Сообщений: 10
Поблагодарили: 1 раз в 1 постах
|
Автор: Bpar Еще офтоп Автор: Inviz
Я добавил еще один импорт в типы и все сгенирилось через wsimport нормально
<wsdl:types>
<xsd:schema targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" xmlns:smev="http://smev.gosuslugi.ru/rev120315">
<xsd:import schemaLocation="xsd/request/smev.unifo.rev120315.xsd" namespace="http://smev.gosuslugi.ru/rev120315"/>
<xsd:import schemaLocation="xsd/request/Message.xsd" namespace="http://roskazna.ru/gisgmp/xsd/116/Message"/>
<xsd:element name="GISGMPTransferMsg" type="smev:BaseMessageType"/>
</xsd:schema>
</wsdl:types>
При попытке импорта xsd схем выдается ошибка wsdl.exe /language:cs SmevGISGMPService.wsdl Ошибка. Не удается импортировать привязку "SmevGISGMPServiceSOAP" из пространства имен "http://roskazna.ru/gisgmp/0 2000000/SmevGISGMPService/". - Не удается импортировать операцию "GISGMPTransferMsg". - Отсутствует тип данных "http://smev.gosuslugi.ru/rev120315:BaseMessageType". Архив со схемами распакован в тот-же каталог с сохранением иерархии каталогов. Что делать, подскажите. BaseMessageType содержится в xsd/request/smev.unifo.rev120315.xsd Я генерил через wsimport Не могу выложить архив - на работе запрещена загрузка файлов. Опишу устно.. Берем форматы http://www.roskazna.ru/g...0%9C%D0%9F%201_16_1.docxВ документе на последней странице wsdl и архив с XSD WSDL сохраняем в файл, редактируем. Получается так Код:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:unifo="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" name="SmevGISGMPService" targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/">
<wsdl:types>
<xsd:schema targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" xmlns:smev="http://smev.gosuslugi.ru/rev120315">
<xsd:import schemaLocation="xsd/request/smev.unifo.rev120315.xsd" namespace="http://smev.gosuslugi.ru/rev120315"/>
<xsd:import schemaLocation="xsd/request/Message.xsd" namespace="http://roskazna.ru/gisgmp/xsd/116/Message"/>
<xsd:element name="GISGMPTransferMsg" type="smev:BaseMessageType"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="GISGMPTransferMsgRequest">
<wsdl:part name="inputmsg" element="unifo:GISGMPTransferMsg"/>
</wsdl:message>
<wsdl:message name="GISGMPTransferMsgResponse">
<wsdl:part name="outputmsg" element="unifo:GISGMPTransferMsg"/>
</wsdl:message>
<wsdl:portType name="SmevGISGMPService">
<wsdl:operation name="GISGMPTransferMsg">
<wsdl:input message="unifo:GISGMPTransferMsgRequest"/>
<wsdl:output message="unifo:GISGMPTransferMsgResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="SmevGISGMPServiceSOAP" type="unifo:SmevGISGMPService">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="GISGMPTransferMsg">
<soap:operation soapAction="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/GISGMPTransferMsg"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="SmevGISGMPService">
<wsdl:port name="SmevGISGMPServiceSOAP" binding="unifo:SmevGISGMPServiceSOAP">
<soap:address location="http://roskazna.ru/gisgmp/02000000/"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Архив распаковываем так что бы папка xsd лежала рядом с wsdl. Структура файлов должна выглядеть следующим образом (у меня это лежит в C:\dev\GisGmp\wimport\) Код:
-|
|- gen
|- xsd
| |- entity
| | |- directory
| | | |- куча файлов
| | |- document
| | |- куча файлов
| |- request
| |- куча файлов
|- SmevGISGMPService.wsdl
И выполняем c:\Program Files\Java\jdk1.6.0_45\bin>wsimport -s C:\dev\GisGmp\wimport\gen -Xnocompile C:\dev\GisGmp\wimport\SmevGISGMPService.wsdl Или берем NetBeans и создаем "Клиент веб-службы...", указываем wsdl. Название пакета оставляем пустым - иначе будет конфликт имен. Отредактировано пользователем 2 июля 2015 г. 10:52:01(UTC)
| Причина: Не указана
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
