Question
Last activity: 23 Sep 2015 10:03 EDT
Connect-SOAP to a client SOAP service which is deployed on IIS server and uses NTLM v1 authentication
Hello,
I have a client SOAP service which is deployed on IIS server and uses NTLM v1 authentication.
Our connect-soap was able to communicate with the SOAP service properly till yesterday evening and after that we are facing weird issue.
We are not getting expected result even after passing correct data, tt is not working even from SOAP UI.
We are not able to understand as there was no change done on either side.
Interestingly one of their legacy system (Biztalk server) is using same SOAP service and is able to get expected result with similar set of data.
I don't have any experience with Biztalk server to debug, nor client has any experienced resource to help us out. This is impact our potential GO Live.
Anyone having Biztalk server experience who can help us understand the difference in the request sent by the biztalk server vs what is sent by us, that will be very helpful.
Amit
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Thanks everyone for the response... We decided to accomplish the job where client created a new connector and that worked well for us.
Sorry for late update
Pegasystems Inc.
CA
Amit, when you say you are "not getting expected result”, do you mean the NTLM authentication is going through fine but the service isn't returning the correct response or have you started getting 401 (unauthorized) error?
Hi Praneeth,
No, i am not getting unauthorized error. The service is supposed to perform some logic and then return a boolean. In our case it is always returning false.
Same is happening even from SOAP UI.
The headers from SOAP UI indicate that the request which is sent is as expected and there is something wrong at the service side.
But what is interesting is that when the same service is called from the their existing application (Biztalk server) then it is working fine with similar set of data. So i was looking for if there is some Biztalk experience available to help us debug and understand what is sent from Biztalk server.
Pegasystems Inc.
CA
Are the requests sent from Pega SOAP connector, soapUI and Biztalk server exactly the same? As John recommended, have you tried sniffing the requests using TCPMON? If the authentication is going through fine, then I suspect there is some difference in the request. Either the difference is in the actual SOAP envelop in the request body or in the HTTP request headers. TCPMON should give you this information.
Another question for you: is the request from Biztalk server going directly to the IIS service or is it going via a proxy? If it is the latter, perhaps the proxy is adding something to the request that makes it work?
Accepted Solution
Thanks everyone for the response... We decided to accomplish the job where client created a new connector and that worked well for us.
Sorry for late update
Pegasystems Inc.
GB
Hi Amit,
It is sometimes useful (and sometimes necessary) to get at the HTTP traffic itself for troubleshooting a SOAP/HTTP issues such as this.
I usually use the (very old, not-maintained, but still useful) Apache 'tcpmon' tool for this: basically you can proxy your PRPC SOAP CONNECTOR through it and examine the response : kinda like using 'Fiddler' for Web Services.
'tpcmon' is available still on Apache Web Sites: http://ws.apache.org/tcpmon/tcpmontutorial.html
The basic approach is to fire up tcpmon as a 'listener' (not a proxy) and change the host/port configuration on your PRPC Connector to talk to that endpoint. *
You then configure 'tpcmon' to forward it's requests to the original host:port of the original endpoint: and then read off the HTTP traffic (including HTTP responses and headers etc).
Thanks,
John
*[ Sometimes this simplistic approach doesn't work : the endpoint may insert the original endpoint hostname (via HTTP headers) in the traffic, which will cause the client to attempt to contact the original endpoint...defeating the object of this diagnostic.
In that case: you can usually get round this by having three physical hosts (prpc, endpoint and tcpmon): edit the 'hosts' file of the prpc host, to 'lie' about the 'endpoints' IP address - instead you map that to the 'tcpmon' host.
Hi Amit,
It is sometimes useful (and sometimes necessary) to get at the HTTP traffic itself for troubleshooting a SOAP/HTTP issues such as this.
I usually use the (very old, not-maintained, but still useful) Apache 'tcpmon' tool for this: basically you can proxy your PRPC SOAP CONNECTOR through it and examine the response : kinda like using 'Fiddler' for Web Services.
'tpcmon' is available still on Apache Web Sites: http://ws.apache.org/tcpmon/tcpmontutorial.html
The basic approach is to fire up tcpmon as a 'listener' (not a proxy) and change the host/port configuration on your PRPC Connector to talk to that endpoint. *
You then configure 'tpcmon' to forward it's requests to the original host:port of the original endpoint: and then read off the HTTP traffic (including HTTP responses and headers etc).
Thanks,
John
*[ Sometimes this simplistic approach doesn't work : the endpoint may insert the original endpoint hostname (via HTTP headers) in the traffic, which will cause the client to attempt to contact the original endpoint...defeating the object of this diagnostic.
In that case: you can usually get round this by having three physical hosts (prpc, endpoint and tcpmon): edit the 'hosts' file of the prpc host, to 'lie' about the 'endpoints' IP address - instead you map that to the 'tcpmon' host.
From the 'tcpmon' host, you just set up the normal forwarding. ]
Pegasystems Inc.
US
Hi Amit,
Another option is to set the loggers for the httpclient.wire.header and httpclient.wire.content to debug using Pega Logging Level Settings.
This will produce all connect soap traffic and will also show the http headers and can sometime help diagnose these issues.
See support article SA-6279 for an example of its use.