HTTPS Receipt of XML Message Yields "No Disassemble stage components can recognize the data"

Typically, I find the "No Disassemble stage components can recognize
the data" error easy to fix by establishing a subscriber for the
inbound xml. However, this one has me stumped. If I take an XML file
(copy and paste the inbound xml from the failed post from the client)
and send it to a HTTP receive port from my development BizTalk server
to another BizTalk server, the send works. However, when the client
sends their file from a WebMethods-based server (using Sonic
messaging), I get the error. They authenticate through our BTS web
server with a valid certificate successfully. IIS log reports 202 0 0
for the post. But, for some reason BizTalk doesn't recognize the data.
Any help with this is greatly appreciated.

Here's the clipped HTTP posted message fragment...

------=_Part_26352_30390425.1184093739947
Content-Type: application/xml
Content-Transfer-Encoding: binary

$1.0?>
... removed ...
------=_Part_26352_30390425.1184093739947
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYICKjCCAiYC
AQEwgc8wgboxHzAdBgNVBAoTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxFzAVBgNVBAsTDlZlcmlT
aWduLCBJbmMuMTMwMQYDVQQLEypWZXJpU2lnbiBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIENs
YXNzIDMxSTBHBgNVBAsTQHd3dy52ZXJpc2lnbi5jb20vQ1BTIEluY29ycC5ieSBSZWYuIExJQUJJ
TElUWSBMVEQuKGMpOTcgVmVyaVNpZ24CEGT765xJwog
+FyQIh6AXPjgwCQYFKw4DAhoFAKCBsTAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA3MTAxODU1MzlaMCMG
CSqGSIb3DQEJBDEWBBSl1GtgZuiWZ/
GJ6v8RSWzdjnPWszBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUr
DgMCBzANBgkqhkiG9w0BAQEFAASBgFpMzlOvrm+D2dUJ0Z1GMCeXeJaXkLMTL
+gHjYYQhzpHQtUw
feEjM8Wt4f6hhd/ZsWyOafk8KdjKk5iuL3By/JnEzO1ifQi9vY5BgWxH9E/
9BfPjIocoHmSD1Nf+
eQQ7z8r48IX4ZepBKtxL0K26RmMpJUcTkf019MqfGeLReQ96AAAAAAAA
------=_Part_26352_30390425.1184093739947--

I would maybe take a look at encoding issues - is there a chance the message

I would maybe take a look at encoding issues - is there a chance the message
is arriving as, for instance, utf-16 without a BOM ?
(I see you have an http header of Content-Transfer-Encoding: binary)

Scott Colestock
www.traceofthought.net

Thanks, Scott. This very well may be.

Thanks, Scott. This very well may be. I had issues with a test file
sent to the customer that contained a BOM and their system wouldn't
accept it. I'll look into it. Is there a site that lists the required
encodings with or without BOM?

Thanks again.

-ak

Aaron,I'm assuming you're using the SMIME decoder on your receive

Aaron,

I'm assuming you're using the SMIME decoder on your receive pipeline, right?

Anyway, the error you're getting usually means that the disassemblers were
not able to interpret the message correctly, normally caused by an encoding
problem. You might want to check what encoding the message is in (possibly
right after decoding but before disassembly) and, if necessary, insert an
intermediate component on the pipeline that tells biztalk what encoding to
use to interpret the message (such as the FixEncodingComponent you'll find
on my website).


--
Tomas Restrepo
http://www.winterdom.com/weblog/

Tomas, I was not using the SMIME decoder.

Tomas, I was not using the SMIME decoder. I'm new to the encryption
algorithms and am gladly learning as I go here. So, I'll start with
that and have the trading partner resubmit the message.

I've used your encoding component once before on another engagement
and must say that it was (is) very helpful. Thanks for offering it up!
I'll be trying it next if the MIME/SMIME decoding isn't the solution.

-ak

Tomas, I setup a receive pipeline component to use the MIME decodercomponent.

Tomas, I setup a receive pipeline component to use the MIME decoder
component. I set the mime decoder "Body part content type" =
pipeline component in the HTTP receive port location. I still get the
same error. It seems that with these settings I'd expect the xml to be
broken out of the original message by the pipeline component. Is that
what should happen?

If I send the message as just the raw xml, it gets processed
successfully. So, it seems that if I can just get the MIME decoder to
work, all will be good.

-ak

The customer sending the document claims that they aren't using MIMEat all.

The customer sending the document claims that they aren't using MIME
at all. We are using two-way SSL cert authentication to encrypt/
decrypt the transfer. So, does IIS or BTS convert this to a MIME
message?  This is really confusing.

-ak

Hi Aaron,SSL is transparent to an application like BizTalk because encryption

Hi Aaron,


SSL is transparent to an application like BizTalk because encryption and
decryption all happen at the transport level (i.e. you wouldn't even noticed
except for configuring the receive location and send port properly).

Clearly, they are doing more than that if what you showed in the first
message is any indication. I might be wrong, but this:

------=_Part_26352_30390425.1184093739947
Content-Type: application/xml
Content-Transfer-Encoding: binary
...

------=_Part_26352_30390425.1184093739947
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
...

Sure looks like a standard SMIME signed document :)

If it's not S/MIME, then it's likely they are using some form of XML Digital
Signatures, in which case you'd still need special stuff to decode it. That
said, It still looks like MIME to me, (if not, and you left the "Allow non
MIME message" option in False, then a different error might have been
raised). It might be that indeed Scott's suggestion is also happening, in
which case you might need to solve both problems to get it to work!
If you send me a sample document (that contains no confidential
information!) I'd be happy to take a look....

--
Tomas Restrepo
http://www.devdeo.com/
http://www.winterdom.com/weblog/

Tomas, thanks for your persistence in the matter.

Tomas, thanks for your persistence in the matter. I'll try to draft of
a copy of their post shortly. where should I send it?

Also, I noticed that in the S/MIME structure that they don't include
the boundary (_Part_26352_30390425.1184093739947). Do you think that
this may have anything to do with not parsing out the body?

Hi Aaron,Just send it to my email (reply to this message to the author)Humm,

Hi Aaron,


Just send it to my email (reply to this message to the author)


Humm, not sure yet.. I'll look at it in detail when you send me the message!


--
Tomas Restrepo
http://www.devdeo.com/
http://www.winterdom.com/weblog/

The customer claims that they are sending the document in utf-8.

The customer claims that they are sending the document in utf-8. I
noticed that they didn't include the MIME version or the boundary for
part as it is multipart. So, I was able to include the following text
at the top of the document and have BTS successfully parse the
document...

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=----
=_Part_44402_2241816.1184609080873;

As I am new to the world of S/MIME, I'm unsure how their system could
send the message without this information. They are a recognized
resource in B2B for mining companies. So, it seems that I must be the
one missing something.

-ak

Hi Aaron,Now, that's pretty funky.

Hi Aaron,


Now, that's pretty funky. On the other side, the good news is that at least
knowing that, it could be possible to inject that small piece through a
custom pipeline component sitting in front of the S/MIME decoder (heck, the
FixMsg sample component in the SDK should be able to take care of it with
little or no modification).


--
Tomas Restrepo
http://www.devdeo.com/
http://www.winterdom.com/weblog/

HTTPS Receipt of XML Message Yields "No Disassemble stage components can recognize the data"

Tomas, I saw in the context information of the received message that
there was a reference to the boundary. As you are probably aware,
BizTalk strips any http headers out into the context. Here, I also saw
AS2 references mixed with other MIME headers. This lead me to believe
that they were intending the connection for an AS2 adapter for an EDI
system (which was a connection that they had built previously for our
EDI system) - yikes. So, I had them post without signing the doc and
it came through successfully.

The AS2 MIME format didn't have the "MIME-Version: 1.0" header. I
think that was causing the glitch as BizTalk probably relies on this
(and the boundary setting) to interpret the MIME format.

Thanks for all your help.

-ak

Hi Aaron,Ahh, that makes a lot of sense; thanks for posting the explanation.

Hi Aaron,



Ahh, that makes a lot of sense; thanks for posting the explanation. I'm not
very familiar with EDI and AS2 myself, so that's why I didn't spot it :)

You could certainly also consider (eventually) exposing an AS2 endpoint to
them to keep the signing features instead of using plain HTTP. There are a
few companies that sell AS2 adapters for BizTalk, and BizTalk 2006 R2 will
come with a built-in AS2 adapter, fwiw.


--
Tomas Restrepo
http://www.devdeo.com/
http://www.winterdom.com/weblog/