|
|
Рекомендации по устранению возможных проблем подключения к веб-сервисам Системы3.7.1. Проверка параметров при редактировании конфигурационного файла Адаптера WS При редактировании параметров конфигурационного файла необходимо проверять наличие, наименования и значения параметров в соответствии с именами параметров, приведенными в п. 3.3.2 «Настройки Адаптера WS» настоящего руководства. При следующих параметрах конфигурационного файла, определяющих рабочие каталоги Адаптера, возможно возникновение ошибки: configuration.incomingDir=C:\\e-osago-adapter\\samples\\incoming configuration.outgoingDir=C:\\e-osago-adapter\\samples\\outgoing configuration.statusDir=C:\\e-osago-adapter\\samples\\status configuration.statusDir=C:\\e-osago-adapter\\samples\\error configuration.tempStatus=C:\\e-osago-adapter\\samples\\tempStatus Ошибкой является дублирование параметра «configuration.statusDir» с присвоением ему значения «C:\\e-osago-adapter\\samples\\error». Для исправления ошибки следует заменить параметр «configuration.statusDir=C:\\e-osago-adapter\\samples\\error» на параметр «configuration.errorDir=C:\\e-osago-adapter\\samples\\error», т.е. параметры должны быть следующими: configuration.incomingDir=C:\\e-osago-adapter\\samples\\incoming configuration.outgoingDir=C:\\e-osago-adapter\\samples\\outgoing configuration.statusDir=C:\\e-osago-adapter\\samples\\status configuration.errorDir=C:\\e-osago-adapter\\samples\\error configuration.tempStatus=C:\\e-osago-adapter\\samples\\tempStatus 3.7.2. Проверка наличия связи с серверами веб-сервисов Системы При недоступности для СК веб-сервисов подсистемы «Электронный полис» (при проверках адресов, приведенных в подразделе 2.1 «Подключение СК к Системе» настоящего руководства, с помощью запросов в браузере), т.е. когда в браузере не открывается страница с WSDL, рекомендуются проверить наличие связи с серверами веб-сервисов Системы с помощью, например, команды PING, обслуживающей протокол TCP/IP: - если связь с серверами веб-сервисов подсистемы «Электронный полис» существует, то сообщить в РСА о том, что веб-сервисы при проверке не возвращают страничку с WSDL, т.к. возможно ПО Системы прекратило работу; - если связь с серверами веб-сервисов отсутствует, то необходимо решить проблему соединения в сетевых настройках сервера, с которого осуществляется доступ к веб-сервисам подсистемы «Электронный полис». Взаимодействие СК с веб-сервисами системы При взаимодействии СК с веб-сервисами подсистемы «Электронный полис» без использования Адаптера WS выполняется следующая последовательность действий: – Формируется SOAP-запрос к веб-сервису подсистемы «Электронный полис» (названия веб-сервисов и соответствующих методов веб-сервисов приведены в Таблице 3, в заголовке которого заполняются логин и пароль, предоставленные РСА. Подробнее формирование SOAP-запроса описано в п. 4.2и 4.3. – Осуществляется отправка запроса соответствующему веб-сервису подсистемы «Электронный полис». При отправке запроса указываются адрес соответствующего веб-сервиса Системы. Адреса веб-сервисов подсистемы «Электронный полис» для тестовой и промышленной среды приведены в п. 4.1. Ответное сообщение веб-сервиса Системы сжимается при помощи формата gzip. Адреса и методы веб-сервисов Системы Для Тестовой среды вызов веб-сервисов осуществляется по следующим ссылкам: Свойство МТОМ включено: - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/checkSubjectOSAGOService?wsdl - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyService?wsdl - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyListService?wsdl - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyCountService?wsdl
Свойство МТОМ выключено: - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/checkSubjectOSAGOServiceNoMtom?wsdl - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyServiceNoMtom?wsdl - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyListServiceNoMtom?wsdl - http://ТЕСТОВАЯ_СРЕДА/e-osago-1.0/services/projectPolicyCountServiceNoMtom?wsdl
Для Промышленной среды вызов веб-сервисов осуществляется по следующим ссылкам: Свойство МТОМ включено: - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/checkSubjectOSAGOService?wsdl - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyService?wsdl - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyListService?wsdl - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyCountService?wsdl
Свойство МТОМ выключено: - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/checkSubjectOSAGOServiceNoMtom?wsdl - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyServiceNoMtom?wsdl - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyListServiceNoMtom?wsdl - http://ПРОМЫШЛЕННАЯ_СРЕДА/e-osago-1.0/services/projectPolicyCountServiceNoMtom?wsdl
Таблица 3 Наименования методов веб-сервисов Системы и их назначение
Формирование SOAP-заголовка Для отправки запросов в подсистему «Электронный полис» должны быть безошибочно заполнены соответствующие элементы заголовка SOAP-сообщения (тег <SOAP-ENV:Header>). В заголовке обязательно указывается логин и пароль СК. Логины и пароли определяются РСА для каждой страховой компании. SOAP-заголовок состоит из элемента <wsse:Security>, предназначенного для передачи информации, относящейся к обеспечению безопасности SOAP-сообщения. Элемент <wsse:Security> состоит из подэлемента <wsse:UsernameToken>, который в свою очередь содержит вложенные элементы <wsse:Username> и <wsse:Password>. В элементе <wsse:Username> передается логин пользования, а в элементе <wsse:Password> – пароль, зашифрованный по формуле Base64 с помощью алгоритма SHA1 (Nonce + Created + Password) (тип пароля PasswordDigest). Элемент <Nonce> содержит случайное число, которое генерируется при каждом отправлении запроса в подсистему «Электронный полис», преобразованное в массив байт и закодированное с помощью base64, а элемент <Created> – дату отправления запроса в формате UTC. Таким образом, окончательный пароль в PasswordDigest формируется из следующих элементов: – password, выданный СК: «пароль в чистом виде»; – nonce из запроса: JlhRUAKiBCvdHg9I4ITPJA=="; – created из запроса: "2012-08-15T08:16:34.495Z". 4.2.1. Пример soap-заголовка <soapenv:Header> <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsse:UsernameToken wsu:Id="UsernameToken-14"> <wsse:Username>rsa</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest"> s9uYfMe+iSmO5zfKl/ZFqzMLE2I= </wsse:Password> <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"> JlhRUAKiBCvdHg9I4ITPJA== </wsse:Nonce> <wsu:Created>2012-08-15T08:16:34.495Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </soapenv:Header> 4.2.2. Контрольные примеры хеширования паролей Контрольные примеры генерации хеша пароля с исходными данными и результатом: Пример1: Пароль (password): wss22wert Случайное число (nonce): MzI2NjYyNzYxMQ== Время (created): 2012-10-29T05:39:24Z Результат: passwordDigest = "88FDZSIoCwQT9zhMqpcekDvZwVo="
Пример2: password = "test" nonce = "8kqcOS9SFYxSRslITbBmlw==" created = "2012-10-29T08:18:34.836Z" passwordDigest = "LOzA3VPv+2hFGOHq8O6gcEXsc/k=" (результат декодирования из base64 в строку не всегда дает строку из чисел, в руководстве имеется ввиду набор байт сгенерированных случайным образом)
Пример3: password = "ic3" nonce = "m4feQj9DG96uNY1tCoFBnA==" created = "2012-10-29T08:49:58.645Z" passwordDigest = "K80tK4TyuvjuXvMu++O8twrXuTY=" passwordDigest = "GkwwpX23bO588LKc3bNKgPFfE0E="
Пример4: password = "tashkent"
Пример5: password = "gd6Eh7Rf" 4.2.3. Пример реализации хэширования пароля на Java publicstaticString doPasswordDigest(String nonce, String created, String password) { String passwdDigest = null; try { passwdDigest = doPasswordDigest(nonce, created, password.getBytes("UTF-8")); } catch (Exception e) { if (DO_DEBUG) { LOG.debug(e.getMessage(), e); } } return passwdDigest; }
publicstaticString doPasswordDigest(String nonce, String created, byte[] password) { String passwdDigest = null; try { byte[] b1 = nonce!= null? Base64.decode(nonce): newbyte[0]; byte[] b2 = created!= null? created.getBytes("UTF-8"): newbyte[0]; byte[] b3 = password; byte[] b4 = newbyte[b1.length + b2.length + b3.length]; int offset = 0; System.arraycopy(b1, 0, b4, offset, b1.length); offset += b1.length;
System.arraycopy(b2, 0, b4, offset, b2.length); offset += b2.length;
System.arraycopy(b3, 0, b4, offset, b3.length);
byte[] digestBytes = WSSecurityUtil.generateDigest(b4); passwdDigest = Base64.encode(digestBytes); } catch (Exception e) { if (DO_DEBUG) { LOG.debug(e.getMessage(), e); } } return passwdDigest; } 4.3. Заполнение тега <Body> Обязательный элемент <Body> предназначен для передачи основных данных конечному SOAP-получателю. Дочерние элементы <Body> содержат передаваемую информацию и могут иметь различные атрибуты. Для передачи веб-сервисам Системы файлов-запросов в формате xml, тег <data> заполняется с учетом использования свойства МТОМ (с использованием МТОМ, либо без использования МТОМ). Адреса веб-сервисов подсистемы «Электронный полис» приведены в подразделе 4.1 «Адреса и методы веб-сервисов Системы» настоящего руководства. Процесс кодирования/декодирования пересылаемых бинарных данных большого размера занимает большие ресурсы. Использование механизма МТОМ позволяет увеличить эффективность передачи бинарных данных в SOAP-запросе путем включения их в качестве вложения без кодирования в base64Binary-формат. Структура файла-запроса, передаваемого веб-сервисам Системы в «теле» SOAP-запроса (тег <Body>), должна соответствовать актуальной схеме xsd, описанной в Приложении 3 «Спецификация форматов взаимодействия» настоящего руководства, а его содержание должно быть заполнено в соответствии с правилами, описанными в Разделе 5 «Правила формирования файлов-запросов» и Разделе 7 «Выполняемые проверки». 4.3.1. Пример заполнения тега <data> для передачи сообщения веб-сервисам с использованием МТОМ При использовании механизма МТОМ основное SOAP-сообщение передается по HTTP-протоколу без вложений, которые запрашиваются клиентом отдельно с помощью HTTP GET-запроса. В начале сообщения в стандартном наборе HTTP-заголовков должен быть указан HTTP-заголовок Content-Type, определяющий тип данных сообщения. Заголовок Content-Transfer-Encoding определяет представление данных при пересылке. Основное SOAP-сообщение ссылается на вложение, используя значение заголовка Content-ID соответствующего вложения как значение атрибута href. Формат прикрепленных заархивированных файлов – «gzip».
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:getLossKASKOStatusRequest xmlns:ns2="http://ws.dkbm.rsa.com/"><return><data><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:9fe4e963-cb33-4885-b608-0c62c33e2a9b-2@cxf.apache.org"/></data></return></ns2:getLossKASKOStatusRequest ></soap:Body></soap:Envelope>
--uuid:aa475c60-9a04-4fbd-9500-ee778d3c1b47 Content-Type: application Content-Transfer-Encoding: binary Content-ID: <9fe4e963-cb33-4885-b608-0c62c33e2a9b-2@cxf.apache.org>
??V?n?@~?????I??V???? 77Y?ElG^?[?J?B?=?ih ??????K+^?q??????? --uuid:aa475c60-9a04-4fbd-9500-ee778d3c1b47— 4.3.2. Пример заполнения тега <data> при передаче сообщения для веб-сервисов без использования МТОМ <ws:attachment>
  Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...  ЧТО ТАКОЕ УВЕРЕННОЕ ПОВЕДЕНИЕ В МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЯХ? Исторически существует три основных модели различий, существующих между...  Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычислить, когда этот...  ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|