Delphi 7 Client Not Connecting to .NET web service
Kevin Tye
I've been working on Delphi 7 client that needs to use a web service written using Visual Studio .NET (C#). Two of the parameters are WideString, one is a TByteDynArray. I keep getting an error message back that says, "Server was unable to process request.-->Array cannot be null. Parameter name:bytes" The TByteDynArray is populated correctly and the SOAP request appears to be formatted properly. I've used the ioDocument parameter in RegisterInvokeOptionsCall.
I finally decided to try the same thing in BDS 2006 using a Delphi .NET application. The client works fine. No problem.
I've never run into a problem using D7 to write SOAP clients before and really don't have access to the server application. It's written by another party and they are not being cooperative. Their response is "use Visual Studio .NET".
Granted I do have a Delphi-built client now, but I really don't like the idea of having to create a .NET client to use a SOAP service.
Any ideas on what else I might try?
Kevin Tye
Synaptech
Jean-Marie Babet
Any chance you could post the WSDL here? I investigated the ioDocument issue
(you seem to be aware of it already) this week and found that newer .NET
WebServices no longer have the 'style' attribute on the <soap:binding ...>
element: only the operations specify the style. This throws off the
importer.
> The TByteDynArray is populated correctly and the SOAP
> request appears to be formatted properly.
If you happen to have a snapshot of the request sent, that would be helpful
also. It's often enough to compare the request packet with the WSDL. If I
feel that the packet generated by Delphi is correct, then I tweak it using
something like the PostSOAP sample included with Delphi. With .NET that's a
little easier to do since the page about a particular operation (i.e.
xxxx.asmx?op=operationName ) typically shows a sample SOAP request; so it's
a little easier to guess at what the server expects.
Since the issue you're running into seems array related, I would still lean
towards ensuring that 'ioDocument' is on. Otherwise Delphi will encode
arrays as per Section 5 and if there's an area that definitely different it
array encoding.
Cheers,
Bruneau.
Kevin Tye
>Any chance you could post the WSDL here?
Unfortunately I cannot. The service is for posting/querying medical records. Security is an issue, and posting the WSDL wouldn't go over well.
Thanks though,
Kevin
Jean-Marie Babet
records. Security is an issue, and posting the WSDL wouldn't go over well.
I understand the issue with posting the WSDL. If it works with BDS but fails
with D7, I suspect it's a serialization issue that maybe was addressed. The
first I would do is compare the request packets from BDS and D7. I suspect
there's a discrepancy - or even many. Sometimes the issue is obvious. At
other times, they both seem valid. At that point I use a tool that allows me
to post XML packets to an endpoint. There's a sample, PostSOAP, that ships
with Delphi that can be used. (It started out as a tool I was using back
until one day someone in QA asked that we include it as it's useful for
tracking down this kind of thing). You can tweak the packet and see what's
bugging the server.
Also, pay attention to the options on the components. For example, the BDS
one may have a HTTPRIO|Converter|Options with 'soDontSendEmptyNodes' enabled
while the D7 does not. This may cause a server error because one of the
things that's lost when importing is minOccurs="0". IOW, we don't know if
something is optional and could be skipped when not specified.
Anyway... please let us know if we can be of any help investigating. Also,
if you'd like feel free to email me the WSDL directly (bba...@borland.com)
if this route alleviates the security concerns of a public post.
Cheers,
Bruneau.
Dan Barclay
I've run into a situation very similar to Kevin. That is, a soap interface
exposed from a .Net application to which I haven't been able to connect.
We're connecting to other soap interfaces, but this one has been a problem
and we haven't had time to study what the problem may be. Like Kevin, we
can't provide the wsdl or data (banking application).
In our case, it's not a project we have to get done immediately so we've
just backed off until we get time to work it out. OTOH, we're quite
concerned that we'll get a project we need to do quickly and can't. That
leaves writing a client side interface with .net and then exposing it to the
w32 client. It's not something we're real excited about.
Is there a hotfix process for the soap wizardry? Failing that, is there a
tutorial somewhere on how to "roll our own" using the components?
Thanks,
Dan
"Jean-Marie Babet" <bba...@borland.com> wrote in message
news:45077e37$1...@newsgroups.borland.com...
Jean-Marie Babet
Today management approved a fix for some issues I noticed within the last
week or two (i.e. since I've started look at WIN32 SOAP issues again). I
can't say when it will be released [and probably mentioning that something
is in the works is not quite in line with the policies here either but...].
In the meantime, I would like to start describing the issues I've run into
and propose workaround/solution wherever possible. I can't quite post
something unless it's approved but I am not opposed to sending out something
via email as long as it's understood that it's not Borland-approved yet.
So maybe I should with some issues right here:
1. The big issue we have with .NET services is that they default to
document|literal. That in itself is not a big issue except that the importer
fails to recognize this fact. I believe I've posted some details in another
post. Basically what happens is that the importer relies on the style
attribute on the <soap:binding ...> element as in:
http://www.w3.org/TR/wsdl#_soap:binding
<wsdl:binding name="SimpleDocumentServiceSoap"
type="tns:SimpleDocumentServiceSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/> <<== 'style attribute'
<wsdl:operation name="echoString">
Newer .NET services (I believe this started with .NET 2.0 but I don't know
for sure) no longer specify the style on the binding element. Instead, each
operation specifies its style. This is correct as per the current spec. But
the importer logic was not updated to account for this :(
2. The next item is related to arrays:
- Initially WSDL had it's own way of describing arrays (
http://www.w3.org/TR/wsdl#_types ) via the arrayType attribute. Our importer
handles that fine.
- Then with doc|lit .NET was using a different approach to arrays. Basically
an array within a complex type would end up as its own complex type with
just one "unbounded" element. The complexType created is typically named
'ArrayOf' with the name of the member. The importer handles this properly
too.
- Now I see cases where instead of the array element in the complexType no
longer maps to an 'ArrayOfXXXX' type. Instead, it's flatly marked with
'maxOccurs="unbounded"'. Again, that's perfectly legal but the WSDL importer
totally ignores 'maxOccurs="unbounded"' on any complexType that has more
than one element.
3. The third item I noticed is that under certain circumstances [I don't
know the rules yet] a .NET WSDL will import another WSDL and another schema
instead of inlining all the declarations. I can easily get a .NET WebService
to do that if I start using some of the tricky attributes that control how
the schema types are declared. The WSDL typically looks like this:
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions>
<wsdl:import namespace="..."
location="http://localhost/webservices/EchoComplex.asmx?wsdl=wsdl1" />
<wsdl:types>
<s:schema targetNamespace="...">
<s:import
schemaLocation="http://localhost/webservices/EchoComplex.asmx?schema=schema1
" namespace="..." />
</s:schema>
</wsdl:types>
<wsdl:service name="EchoComplex">
[....]
</wsdl:service>
</wsdl:definitions>
A WSDL importing another WSDL is not an issue as the importer recursively
loads them. However, the schema <import ...> [or <include ...>] in the
<types...> is not handled properly. We assume all types to be inlined within
a WSDL - not to be imported from an external schema :(
There are other issues with .NET services but the above three are the
highest ones on my list. Most of the reports that I've seen tie back to
these items. If the issue you're running into seems related to one of these,
please feel free to contact me and we can work on a solution/workaround
until something more official comes out. If you feel it's something else,
please contact me if there's a way that I can help investigating.
Cheers,
Bruneau.
Dan Barclay
> I
> can't say when it will be released [and probably mentioning that something
> is in the works is not quite in line with the policies here either
> but...].
<chuckle> Fine print noted. You can start a blog. Apparently they ignore
mis-steps there<g>.
The issues you describe appear to have befallen us. While I'm not an
expert, I did recognize the failure to suck in some of the external
references as you described.
> something unless it's approved but I am not opposed to sending out
> something
> via email as long as it's understood that it's not Borland-approved yet.
Dan at BarclaySoftware dot com. The email address stashed within my
newsgroup postings (D...@MVPs.org) does get back to me sometimes, but is
heavily filtered and occasionally just ignored by me.
If you are having trouble getting priority, let me know publicly or
privately. IMHO, it's imperitive that Delphi be able to consume .Net web
services as a "given". Delphi also needs to emit wsdl's for its own web
services that .net can consume. It's a reality of the marketplace, and the
marketeers know (or should know) that.
Dan.
"Jean-Marie Babet" <bba...@borland.com> wrote in message
news:45118c04$1...@newsgroups.borland.com...
Sweta Mistry
Hi Bruneau,
We’re getting the following two ERemotableExceptions when making calls to a VS .NET web service:
1: Object reference not set to an instance of an object
2: Index was outside the bounds of the array
We’ve verified the index/parameters/objects being passed - all looks good on the Delphi client side.
Do you know of a work around? We are using Delphi 7.
Thanks,
Sweta
BizTalk Utilities - Frustration free BizTalk Adapters
http://www.topxml.com/biztalkutilities