I spent a bit of time today beating my head against the wall with some complex data translation services for an application I’m helping out on. The application in question is a FoxPro app consuming data from a very complex asynchronous Web Service that uses SOA messaging techniques to communicate it application data. In a nutshell a message is sent to a Web Service which tells the service what to do and returns immediately. The server then does what it needs to, which can take a bit of time – hours or days even. When done the server responds with a SOAP formatted message to send to another Web server at a URL we provide.

Because of the complex nature of the request and response methods I’ve been pushing for using C# and .NET to handle the Web Service and XML interaction, then using COM interop to get the data back into the FoxPro application.

When I started with this app my first thought was that the hardest part was going to be get to the Web Service calls to work (it’s a non Windows service on the other end) and then parsing these fairly complex messages into something meaningful when they are returned. As it turns using .NET for that portion of the process is fairly straight forward. After manually tweaking the WSDL a bit (with help from the vendor of the service) I was able to get the inbound calls to work. The return end is a bit more complicated – the service returns results asynchronously as SOAP Web requests to our server to be picked up and parsed here. Thankfully the messages used for the return messages are also defined in the WSDL contract so getting strong type information is possible using the Web Service references. Parsing the message is then possible by using the .NET  XMLSerializer and de-serializing right into an object. Sounds easy enough, but it wasn’t quite so obvious to get to that point <s>…

But now the real bummer is that I’m not able to get the complex message object passed over COM to and from FoxPro. .NET’s type TLBExport somehow mangles type library and that in turn is causing problems when this complex message structure is returned. It’s not just a problem with FoxPro actually – even the VS OleView utility chokes on the exported type library.

The type is very complex as it defines basically all the different message permuations. There are something like 15 types that live under the master message type with even more subtypes and list types that deal with the actual data. Altogether there are more than 50 types defined for this single message object.

The full type is defined as part of the generated WSDL class and then exposed with ComVisible at the assembly level (which causes all classes to be exported). In VFP’s Object Browser I can see all the top level classes, but as soon as I drill down into the properties the object browser chokes. OleView won’t even load the type library altogether…

I’m not sure what the problem is – looking at the actual types exported it doesn’t look like there’s anything there that shouldn’t export. I suspect it has something to do with the various attributes the generated type proxy classes that the WSDL import generates. <shrug>

Has anybody seen this behavior before with COM exports? The ultimate end result in VFP is if I make a call against this object and return this complex type it will fail with Unknown COM Status errors.

So now I’m stuck on the interop issues. The .NET end is working well, but if COM Interop isn’t work, then there’s no good way to get the data back to VFP. Unfortunately for this customer there’s really little choice, since the interfacing application is a large Fox vertical app and there’s no way that it will go the .NET route anytime soon if ever. The Web Service functionality is more of an add-on behavior…

So now I’m stuck with the unfortunate prospect of having to resort to manually dealing with these monstrous XML documents – parsing out many nested types containing enumerated lists, enum types and all sorts of other nasty structures that allow pretty much preclude automatic data parsing of any sort.

The only other alternative I can think of is to create a set of wrapper types in .NET that contain only the data points we’re actually interested in which is somewhat smaller and make sure that these types created properly export. But that too doesn’t sound very appealing. If that much duplication is used XML parsing is only a slightly more low level approach.