- This topic has 7 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
Hi all!
I’m developing a system to need make calls to Java Web Service using SOAP adapter. I send correctly the request but the response never reaches BizTalk. Using wireshark I detect the message from the web service and the data is the next:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Mon, 06 Oct 2008 14:35:58 GMT2de
<?xml version=”1.0″ encoding=”UTF-8″?>
<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance“>
<soapenv:Body>
<processResponse xmlns=”http://namespace.name.space“>
<processReturn>BusinessData</processReturn>
</processResponse>
</soapenv:Body>
</soapenv:Envelope>
0As you can see, appear HEX chars before the XML, this generates an understanding in BizTalk, which reject the message for a wrong XML data. This is produced for the “Transfer-Encoding: chunked“.
How can I say to BizTalk that avoid this HEX chars and read directly the XML?
Thanks a lot!
-
I don’t believe you can (however I’m happy to be proved wrong!).
This sounds like a configuration issue with your Java WS that is sending the response – is it possible to re-configure the response message?
Nick.
-
The first problem is about the Java WS, it is not mine! I’m triying to get that they delete the chunked from their Apache server, it is the best option without any doubt!
I’m thinking in create a pipe that read the response message with a MIME decoder because the exception information is the next:
“Inner exception: The XLANG/s message has no part at index ‘0’. The total number of parts found in the message is ‘0’. If you expect a multipart message, check that the pipeline supports multipart messages such as MIME. “
Perhaps I can use this to get a solution,
-
This issue seems like it should be addressed at the transport level. Chunked transfer encoding is a perfectly valid transport protocol, so the Java WS is not breaking any rules. I would try using the WCF-BasicHttp adapter to consume the Java WS instead of the SOAP adapter (it’s OK that the WS on the other end of the wire is Java and not WCF). The WCF adapters have many more configuration settings than SOAP, so maybe they can handle chunked transfer. Here is a walkthrough: http://msdn.microsoft.com/en-us/library/bb246019.aspx.
If that doesn’t work, a custom pipeline might do the trick, but the MIME decoder is not the way to do it. A custom decoder pipeline component is probably the way to go. The custom component might contain C# that walks the message data stream and removes the extra hex characters.
-
Hi ruselw!
Of course chunked is correct but perhaps not needed, for this reason I’m triying that the WS supplier check if they can change the chunked option.
During last evening I reach the same conclusion than you using a custom pipeline, but now I go to check the option using the WCF-BasicHttp adapter. I will keep you informed.
Thanks a lot
-
Hi all, deeping in this problem, any solution finded in .Net. The WCF-BasicHttp adapter doesn’t work and the custom pipe doesn’t receive the message neither. At the end (two last posts) we find the next info in this web: http://www.theserverside.com/discussions/thread.tss?thread_id=42032
Re: Web Service Response encoding problem
Posted by: Alan Jones on septiembre 14, 2006 in response to Message #217623
OK, so after a bit of digging, I’ve made some progress.The ‘junk’ characters aren’t junk at all! They are just control characters for the ‘chunked’ transfer-encoding that JBoss appears to be using! It would appear that Java tools (such as my Java test client, and the SoapUI tool) can understand messages sent using chunked encoding (hence why we’d never seen this ‘problem’ before), but as soon as we use a .NET tool, such as our suppliers client or the MSSoapT tool, they don’t seem to understand the output, and hence display the control characters as part of the message.
So, I suppose the next question is, does anybody know anything about the different setting for transfer-encoding, and more specifically how I can use something other than ‘chunked’ in JBoss?
Re: Web Service Response encoding problem
Posted by: Alan Jones on septiembre 19, 2006 in response to Message #217907
OK, I found the solution (and cause) of the problem. Apparently .NET doesn’t implement HTTP/1.1 correctly, so needs the following line adding to the connector element of the Tomcat server.xml file:
restrictedUserAgents=”^.*MS Web Services Client Protocol.*$”As with everything, once you know what to look for, you find it! There is an entry in the JBoss Wiki about it 😉
Now, I’m absolutly stopped. Does someone know about a hotfix in .Net to solve this?
Thanks a lot
-
Sorry, I don’t know anything about JBoss, but I do have another idea: Use a WCF message inspector to strip out the chunking characters. A message inspector would give you a chance to strip out the charcters before the the data hits BizTalk. To apply the message inspector, you would need to use the WCF-Custom adapter and apply the inspector through a custom behavior. If you want to investigate this route, it might be a little easier to test the inspector using a WCF client generated with svc-util before adding it into your BizTalk solution. Here is a good link on message inspectors:
http://weblogs.asp.net/paolopia/archive/2007/08/23/writing-a-wcf-message-inspector.aspx
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.