2016-01-27 9 views
0

Я пытаюсь отправить SOAP-сообщение через WCF в IRS, и он продолжает отклоняться, потому что мое приложение MTOM отформатировано неправильно.Отправлять SOAP-сообщения через WCF с помощью MTOM и Content-Transfer-Encoding: 7-bit

Я сузил вопрос до своего значения Content-Transfer-Encoding. Он установлен в Binary (стенограмма для 8-bit).

Служба IRS хочет, чтобы я использовал 7-bit с 8-битным вложением (другими словами, кодировал UTF-8, а затем гарантировал, что я не использую символы, отличные от ASCII).

Я уже использую специальный кодер сообщений, чтобы gzip мои запросы (ответы возвращаются на обычный текст, тьфу). Это то, что сейчас выглядит моим WriteMessage.

public override ArraySegment<byte> WriteMessage(Message message, int maxMessageSize, BufferManager bufferManager, int messageOffset) { 
    // get an instance of the underlying encoder 
    var encoder = new MtomMessageEncodingBindingElement() { 
      MessageVersion = MessageVersion.Soap11WSAddressing10, 
      WriteEncoding = System.Text.Encoding.UTF8 
     }.CreateMessageEncoderFactory().Encoder; 

    // write the message contents 
    var uncompressed = encoder.WriteMessage(message, maxMessageSize, bufferManager, messageOffset); 

    // compresses the resulting byte array 
    return CompressBuffer(uncompressed, bufferManager, messageOffset); 
} 

Любые идеи? Когда я изменяю свойство WriteEncoding на ASCII или UTF7, .NET генерирует исключение ArgumentException и сообщает, что формат не поддерживается.

+0

Я думаю, что 8-битное кодирование является менее проблематичным после нескольких исследований, чем тот факт, что MTOM пытается кодировать заголовок безопасности WSS (который является в результате чего сертификат будет оптимизирован в приложение MTOM). Это делается WCF из-под моего контроля, поэтому я ищу в написании пользовательского кодера сообщений для его преодоления. Надеюсь, кто-то здесь может дать мне лучший ответ, если он существует, прежде чем я заберусь слишком далеко :) – Dave

ответ

1

Я использую Java Apache CXF и WSS4J для решения IRS, но если вы получаете эту ошибку «Сообщение не было отформатировано правильно и/или не может быть интерпретировано. Ознакомьтесь со стандартами XML, изложенными в разделе 3 AIR Руководство по подаче и справочное руководство, расположенное по адресу https://www.irs.gov/for-Tax-Pros/Software-Developers/Information-Returns/Affordable-Care-Act-Information-Return-AIR-Program, исправьте все проблемы и повторите попытку ». это потому, что IRS ожидает это:

Content-Type: application/xml 
Content-Transfer-Encoding: 7bit 
Content-ID: <[email protected]:us:gov:treasury:irs:common> 
Content-Disposition: attachment;name="1094B_Request_BBBBB_20151019T121002000Z.xml" 
+1

После того, что мы прошли через .NET и WCF, это, вероятно, гораздо более простой подход. Я слышал о том, что люди, использующие Java, имеют проблемы с подписями, но, скорее всего, они просто не понимают безопасность SOAP. – Dave

1

Он появляется встроенный в MTOM кодировщика в WCF не будет кодировать запрос, совместимый со службой IRS. Он кодирует все, что он находит в запросе, закодированном в base64, включая BinarySecurityToken в подписанном запросе. Я смог получить запрос ближе к требованиям IRS, создав собственный кодировщик. В WriteMessage вы можете добавлять и добавлять разделители MIME и перекодировать файл в качестве вложения. Для правильной установки заголовков требуется инспектор исходящих сообщений: https://blogs.msdn.microsoft.com/carlosfigueira/2011/04/18/wcf-extensibility-message-inspectors/

+0

Я считаю, что вы правы. Я принял несколько иной подход и просто отменил части результата кодирования MTOM, которые я не хотел. Я все еще работаю над тем, чтобы получить запрос, принятый в настоящее время, но ошибка, которую я получаю, не может быть воспроизведена IRS, используя мой необработанный запрос с их конца. У меня сегодня запланирован звонок, чтобы узнать, в чем проблема (надеюсь). Спасибо, что входите! Если текущее решение, которое я использую, не работает, я попробую ваш метод. – Dave

+0

Очень интересно узнать, есть ли у вас работа с C#. Я очень близко подошел к пользовательскому методу кодирования mtom, но теперь получаю сообщение об ошибке при анализе запроса: TPE1106 Недействительный контент был найден, начиная с элемента 'Подпись'. В этот момент не ожидается никакого дочернего элемента ... Поскольку единственный элемент подписи находится в маркете безопасности, и безопасность уже проверена, я полагаю, что IRS начинает синтаксический анализ через заголовки конвертов. Возможно, из-за того, что заголовки безопасности .NET не имеют пространства имен wsse, оно выбрасывает эту ошибку. – jabtri

+0

У меня работает MTOM (пришлось по-настоящему взломать WCF, чтобы заставить его работать), и теперь мой заголовок безопасности недействителен из-за того, что я сделал с сообщением после кодирования MTOM.Я отправлю отчет через пару часов после того, как я (повторно) выполним ручное подписание сообщения. – Dave