logo
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

6 Страницы«<456
Опции
К последнему сообщению К первому непрочитанному
Offline two_oceans  
#101 Оставлено : 29 ноября 2018 г. 2:34:33(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 186
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 12 раз
Поблагодарили: 40 раз в 40 постах
Цитата:
2.3.3 Широковещательные рассылки
В случае широковещательных рассылок активной стороной взаимодействия является поставщик, то есть он отправляет запросы. При этом потребители не могут посылать ответы (это контролируется СМЭВ). Подписка на рассылки производится по видам сведений.
Цитата из методических рекомендаций по работе с ЕСМЭВ 3.4.0.3. Написано не очень внятно. Я все же понимаю так, что потребитель в случае рассылки получит запрос в GetRequestRequest, но типом будет указано BROADCAST. Ну, поживем - увидим.

Отредактировано пользователем 29 ноября 2018 г. 2:36:25(UTC)  | Причина: Не указана

Offline Александра П  
#102 Оставлено : 29 ноября 2018 г. 4:29:09(UTC)
Александра П

Статус: Новичок

Группы: Участники
Зарегистрирован: 28.06.2018(UTC)
Сообщений: 5

Автор: two_oceans Перейти к цитате
Цитата:
2.3.3 Широковещательные рассылки
В случае широковещательных рассылок активной стороной взаимодействия является поставщик, то есть он отправляет запросы. При этом потребители не могут посылать ответы (это контролируется СМЭВ). Подписка на рассылки производится по видам сведений.
Цитата из методических рекомендаций по работе с ЕСМЭВ 3.4.0.3. Написано не очень внятно. Я все же понимаю так, что потребитель в случае рассылки получит запрос в GetRequestRequest, но типом будет указано BROADCAST. Ну, поживем - увидим.


В методических рекомендациях 3.4.0.3. на стр.81 есть рисунок "Последовательность обращений к веб-сервису СМЭВ при передаче сообщений с запросами и ответами", по нему очередь GetRequestRequest опрашивает поставщик, если он в неё же будет класть ответы по подписке, то сам по итогу и вычитает их. И с другой стороны, если потребитель будет получать с GetRequestRequest сообщения, то возможно заберет сообщение предназначавшееся поставщику, а не рассылочное.
В общем, в рекомендациях ничего вразумительного по подписке не сказано, пока одни догадки приходится строить..
Offline two_oceans  
#103 Оставлено : 30 ноября 2018 г. 1:32:55(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 186
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 12 раз
Поблагодарили: 40 раз в 40 постах
Ну так там схема для обычного запроса, а для рассылки просто абзац, что "задом наперед и все наоборот".
Цитата:
И с другой стороны, если потребитель будет получать с GetRequestRequest сообщения, то возможно заберет сообщение предназначавшееся поставщику, а не рассылочное.
Так точно не будет, так как у поставщика и потребителя разные очереди. Точнее в том же документе сказано, что все очереди входящие, исходящей очереди потребителя просто нет, поэтому для обычного вида сведений GetRequestRequest потребителю просто вернет ошибку, что очереди не существует. Ну и не забывайте, что по рассылке нельзя отправить ответ, то есть в конкретном виде сведений - рассылке сообщения идут только в одну сторону. Максимум можно вызвать Ack что сообщение получено.

И для каждого вида сведений также своя отдельная очередь. При чтении можно указать фильтр из какой очереди читать. Получается, что поставщик складывает в одну очередь, а читает из другой, вычитать свой ответ тоже не получится. За исключением тестирования, когда поставщик сам себе отправляет данные, поэтому читает оттуда же куда записал. Но это уже более сложный вопрос о реализации табличной маршрутизации.

Отредактировано пользователем 30 ноября 2018 г. 1:40:10(UTC)  | Причина: Не указана

Offline Bpar  
#104 Оставлено : 5 декабря 2018 г. 6:48:47(UTC)
Bpar

Статус: Участник

Группы: Участники
Зарегистрирован: 05.08.2014(UTC)
Сообщений: 11

Поблагодарили: 2 раз в 2 постах
Автор: Bpar Перейти к цитате

Братцы, может надо как-то регистрировать подписи?

Таки да, техподдержка ответила, что моя подпись не зарегистрирована в СМЭВ-3.
Такой подписи у меня пока нет, но поскольку страница проверки подписей сообщает, что всё хорошо,
UserPostedImage

думаю, что код рабочий. SMEV3sign.zip (6kb) загружен 2 раз(а).

Технология такая: Поскольку сериализация туда-назад возможно нарушает целостность подписи (экспериментально установлено, что с CallerInformationSystemSignature это действительно так, а с PersonalSignature - нет), то пакет подписывается непосредественно перед отправкой внутри службы SMEVMessageExchangePortTypeClient. Для этого в службе заменяется конструктор, в котором создаётся экземпляр класса от IEndpointBehavior, в свою очередь в котором экземпляр класса от IClientMessageInspector. И в нём в методе-событии BeforeSendRequest всё и происходит.
Также "доработан" SMEVTextMessageEncoder, который теперь обрезает оригинальную подпись в Header. Но это не принципиально.

Надеюсь, кому-то поможет.

П.С. спасибо мистеру two_oceans за помощь с проверками подписей.

Отредактировано пользователем 5 декабря 2018 г. 6:57:21(UTC)  | Причина: Не указана

Offline Lunatic  
#105 Оставлено : 7 декабря 2018 г. 7:47:22(UTC)
Lunatic

Статус: Новичок

Группы: Участники
Зарегистрирован: 19.10.2017(UTC)
Сообщений: 1
Российская Федерация

После пары дней танцев с бубном вокруг подписи, удалось получить от тестового СМЭВ3 ответ 'Отправитель сообщения не зарегистрирован.'

Работаю через WCF-сервис и основная проблема была не в алгоритме подписи (он тут уже несколько раз выложен), а в том, что при сериализации отдельных кусков пакета (например, SendRequestRequest или SenderProvidedRequestData) им не проставлялся Namespace.
А т.к. я сначала подписывал SenderProvidedRequestData а потом создавал через конструктор новый SendRequestRequest, получалось что подписываю я один XML, а в СМЭВ3 в итоге улетает другой.
Решается это добавлением атрибута [XmlRoot] с указанием нужного неймспейса для SenderProvidedRequestData (можно задать аналогичный атрибут для SendRequestRequest и сначала создавать новый реквест без подписи, сериализовать его, подписывать и добавлять в него подпись, но это не удобно).
Сервис создает partial-классы, поэтому сделать это можно в отдельном файле и при обновлении сервиса ничего не слетит:

Код:

[XmlRoot(Namespace = "urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2")]
public partial class SenderProvidedRequestData
{
}

Надеюсь кому-нибудь это поможет.


Автор: Max Zimin Перейти к цитате
Я столкнулся со следующей проблемой - я получаю ошибку при сериализации XML SendRequestRequest.
Прошу помочь с данным вопросом или дать наводку.


Если я правильно понял, это связано с ошибкой генерации WSDL, к сожалению починить это не меняя сгенерированный код у меня не получилось.
Я пока заменил массивы на списки:

Код:

private AttachmentHeaderList attachmentHeaderListField;
private RefAttachmentHeaderList refAttachmentHeaderListField;

private AttachmentContentList attachmentContentListField;

и дальше по коду

Если кто-то придумал, как это сделать не трогая автоматически-генерируемый код, буду рад подсказке.


RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
6 Страницы«<456
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.