SAP BC Webservice call Urgent pls

Hi All,

present situation is : BC is making a web s ervice call to JAVA based hub to submit a XML having client details.

Recently our BC server has been relocated todifferent place from then these messages seems to be missing somewhere…
there are no exceptions while making awebservice call and everything seems to be nice at BC end but it’s not reaching java hub.

FYI - I created web service connector which created set of services to connect to hub. even ‘heartBeat’ service is working fine…

all packages are fine when compared to old SAP BC system …!!!

i’m actually stuck…where to look into!

kindly help me …
thanks
sreedhar

Just to make sure I understand the situation:

  1. You created a Web Service Connector that connects to a Hub and you can call the Hub’s heartbeat service and get a correct SOAP Response, but when you call another of the operations generated in the same Web Service Connector it appears to work correctly, but the call never gets to the Hub.

  2. There are no errors in the BC logs.

  3. The Hub confirms that the heartbeat service is getting called by your BC, but never gets the SOAP Request the service that does something interesting.

Are these SOAP RPC services? If so, it is not too hard to step through the Web Service Connector code and see the exact SOAP Response message in both cases. I would assume the interesting service has an interesting return that would show some version of the Hub software was called.

Are you using the “port” parameter to the WSC? This allows for selecting between multiple Ports (each with possibly a different soap:address) defined in the Hub’s WSDL. When stepping into the WSC check the value that gets put into the address and binding fields by the first Flow Sequence of the WSC. You can compare those address settings with the soap:address settings of the Hub’s WSDL. It would be nice if the Hub’s heartbeat service is running on the same host:port as the interesting service, so you can just compare/validate the addresses.

If they are the same, then you know the DNS resolution from the new BC host should send the heartbeat and interesting calls to the same IP, otherwise, there could be a network/DNS issue.

HTH,
Fred

Hi fred,

as you suggested I did step thru the web service connector and found the following soapResponseData …
<?xml>
<soapenv:envelope>
<soapenv:body>
<ns1:sendstringresponse>
</soapenv:body>
</soapenv:envelope>

and added to this the variable “soapStatus” is 0 which I presume is fine. but when I contact java hub people, they seem to not getting this message !!!

Kindly let me know ur valuable advises pls…

Thanks in advance
Sreedhar K

Guys,
I think i found the anamoly happening in BC… but i’d like to take your suggestions/advices before furthering it up…

i’m making a web service call to java hub through web-service connector which was created by SAP BC… it’s SOAP RPC call …

for the same invoice when i’m debugging , i’m getting the <soapresponsedata> as <?xml> <soapenv:envelope> <soapenv:body> <ns1:sendstringresponse> </soapenv:body> </soapenv:envelope></

and sometimes as

GFSServiceBrokerString
<p>Hi there, this is an AXIS service!</p> Perhaps there will be a form for invoking the service here…

in both cases <soapstatus> is OK, but in later case message is not reaching Java HUB…

Is this something to do with teh service coding or some anamoly with BC ?

as you can intuite,in both cases same code was debugged and nothng was changed…
Please reply your suggestions/advices asap …

If you think that it’s anamoly with BC, is there an possibility that I can log a call with SAP or SAP BC product customer care ??

Thanks in advance
Sreedhar Kurella

Is there anyone to answer my query please ?
thanks in advance …

  1. I would think that the HTML result (returned rather than a SOAP Response) should trigger a bad soap status in the Web Service Connector. This sounds like a bug.

  2. I don’t know what the SAP support policy is. I would log an issue with them. webMethods does have a good deal on upgrading BC to the latest Integration Server release (BC is based on IS 4.6, so it is rather old, which shows particularly in SOAP interoperability, because what interoperated in 2002 does necessarily still work with newer releases of 3rd party SOAP implementations such as Axis).

  3. Does the sendstring service return no results? If so the SOAP Response that you are getting sometimes is correct. I don’t understand why Axis is returning two different results. If the SOAP Request message or endpoint address different or is the Axis implementation or server unstable?

HTH,
Fred

Sounds like sometimes you are hitting a server where the service you are calling has been stubbed out returning only the “Hi there” message. Or perhaps the service has been taken offline and only the stub is there to respond.

Mark

Guys,

Yesterday we did a debugging session on production environment (i know we did a bolder step!!!) and found that few messages are not reaching java hub for which soapStatus is ‘2’ which ‘WebConnector’ service doesn’t handle (it handles only status 0 and 1) and thus those messages are going under cover unnoticed.

Status 2 says i’ts ‘Forbidden’ !!! I’m attaching screenshots taken from Developer. Any suggestions would be highly helpful …
Thanks in advance…

Screen Shot
SShot.zip (65.0 k)

Hi Fred & Mark,

Any comments pls ?

I believe that a soapStatus of 2 is used for HTTP protocol errors that occur when the soap client is sending a soap message to a soap server. I’ve seen that before when the target service hung and the HTTP timeout period expired.

Sounds like the soap endpoint URL on the target server is either unavailable or you don’t have permissions to access that resource (URL).

You can confirm this by posting the soap message from a testing tool. I sometimes use a simple Java command-line app to replicate errors like this outside of Integration Server. Assuming that the error happens when the same soap message is posted to your soap server URL from a tool other than IS, you will have isolated the problem to your target server.

Mark