RE-posted from DSXchange.
We are currently investigating replacing a Microsoft Excel application with DataStage. Behind the Excel workbook is a series of VBA objects (such as macros) that invoke web services through MSSOAP. This proceeds a row at a time through the worksheet, invoking the appropriate web services.
Our goal is to replace this with DataStage, in the hope that bulk data loads will proceed faster. One constraint is that we must employ the same web services as the Excel VBA application (behind these web services a DB2z database is updated through a CICS transaction layer, we just don't want to go there!) The web services have been in existence for years, but do not appear to be documented.
From the VBA code we have worked out which web services we need to invoke, and which of their operations, and are fairly confident from the WSDL that we can do the SOAP body.
But the WSDL does not specify what needs to go into the SOAP header. Trying to invoke the web service without a SOAP header yields a SOAP fault ("security header required").
What we're hoping to accomplish is to trace the XML being sent from the Excel application and received by the WebSphere Application Server that is exposing the web services. Then we can reverse-engineer the header information into DataStage.
"They" (the WAS administrators) are happy to help, but have asked which ports they need to open for tracing.
Can anyone advise which ports MSSOAP is likely to use, or at least how we can find out? The web service URL does not have a TCP port number which we guess means that it is using a default port number, but we don't know which that is, or even t's the same "port" as that being referred to by the WAS Administrator.
Anny assitance is appreciated. Thank you for your time.
beach_bum 270001TFEN49 Posts
Re: Capturing SOAP2012-06-22T13:33:18ZThis is the accepted answer. This is the accepted answer.The way I was doing it a long time is crude, but it did the job:
Can you run netstat -a while running the Excel VBA object from the same workstation? Taking three snapshots of the command's output (before/ during/ after) should show you the remote port.
If the WAS trace logs aren't helpful, once you know the port (and assuming the request is through unsecured http), you can get (or code) a forwarding proxy that listens on the localhost and forwards all data to the server of your choosing. In the meantime, you can log all requests and data that is sent.
It then is just be a matter of pointing the VBA object at the local machine and running the forwarding proxy and that should provide you with enough information to reverse engineer the protocol.
You might be lucky and get this working over https, but last time I had to do something similar encryption wasn't a huge issue.