Kevin Daly

Fun with SAP and web service interop

The project I am currently working om (I mean for the day job) requires various financial information to be posted to SAP on a nightly basis. Our interface to SAP is via web services exposed from the SAP end, which act as an interface to BAPIs written by our SAP service providers. In this particular case it's a very simple web service with one method and a handful of parameters, one being a header structure and the others being structure arrays passed by reference. I'm not too keen on passing ref parameters to web services, partly because it's a bit of a hack (we all know that in reality the proxy just repopulates the parameters from return values), but mostly because it promotes an illusory way of looking at what is happening with the service (actually now that I think of it those two objections are closely related).
But never mind, what the proxy wants the proxy gets.

Except that in this case it didn't work. While I was able to verify that we were communicating successfully with the remote server, the referenced arrays were coming back as null.

Eventually I added a trace to the proxy method call and dumped the outgoing and incoming Soap messages to a file...at which point I was surprised to see that the response was being returned as expected - it just wasn't being deserialised.
Given that deserialisation was essentially controlled by attributes on the proxy, and the proxy was generated from the WSDL using the WSDL.exe tool, then it seemed that either I was using an incorrect command line switch or there was something wrong with the WSDL. I checked my parameters and checked the options for the WSDL tool: there really aren't very many, so that didn't look like it could be the problem. I then compared the attributes on one of our earlier SAP web service clients that has similar parameters but is known to work,  and noted that there were some differences in attributes where I wouldn't have expected them. When I used the WSDL tool to generate a new proxy for that service, lo and behold that one also failed to work...then acting on a hunch I tried again using the .NET Framework 1.0 version of the WSDL tool (we're now on 1.1), and it did work. Naturally I tried that on the service that my own project is calling, and that worked too. The upshot is that if I run the 1.0 version of WSDL.exe against our SAP web service WSDL, I get a valid proxy. If we run the 1.1 version against the same WSDL we get a proxy with additional attributes which appear to result in deserialisation not working.

The SAP web service is Java-based, but that has not previously been a problem for us. I have not been able to find a description of a breaking change in WSDL.exe that matches this behaviour, so I strongly suspect that it's one of those things that Microsoft regards as a bug fix...which suggests that there is something a bit dodgy in the WSDL that formerly didn't cause any problems, but which the 1.1 tool interprets more strictly in such a way that the end result is useless.

The devil as they say is in the details, and I think it's clear that web service interoperability is very dependent on disparate tools agreeing to intepret WSDL exactly the same way, which can be tricky (define same).  

We have a workaround obviously in this case in that we can simply use the 1.0 version of the WSDL tool when creating SAP proxies (which is what I'm doing now), but that's not an ideal solution.

At some point I'll have to work out exactly what in the WSDL causes the tool to generate those additional attributes, and what I need to change to get it not to. Then I think I'll use an XSLT transformation as a kind of pre-processor to generate WSDL that the tool will be more happy with.

Sigh.