|
| Re: SalesForce wsdl |
 |
Tue, 29 Jan 2008 11:11:33 -080 |
Hello,
I'm not sure if this is related but yesterday someone in our Support
organization contacted me with something that sounds somewhat related to
your post. Here's the reply I sent back. If this is not about the same
issue, please let me know and I'll be happy to investigate.
Cheers,
Bruneau.
[[Reply sent to support]]
De: Bruneau Babet
Date: lun. 28/01/2008 16:00
Objet : RE : New WSDL import case
Hello,
Here's my initial assessment of the problem here. The queryResult returns an
array, named 'records', that's typed as an array of 'sObject' but that
really contains derived types of 'sObject'. Support for derived types were
added in Delphi SOAP recently. However, we rely on the 'xsi:type' attribute
to tell us what type of object was really sent. Based on the sample XML
response posted at the following URL -
https://wiki.apexdevnet.com/index.php/Enterprise_Query - the response for
records looks like the following:
<records xsi:type="sf:sObject">
<sf:type>Account</sf:type>
<sf:Id>001D000000HRzKCIA1</sf:Id>
<sf:Id>001D000000HRzKCIA1</sf:Id>
<sf:Name>salesforce.com</sf:Name>
<sf:BillingStreet>The Landmark @ One Market, Suite
300</sf:BillingStreet>
</records>
When Delphi SOAP sees this XML it has absolutely no idea was kind of object
to create. Rather I would expect the xml to read something like:
<records xsi:type="sf:Account">
This would tell us that "records is an array of 'sObject' but really
what's
coming down is an array of 'Account' objects". We would be happy with this
since 'Account' does derive from sObject.
Interestingly, I found a URL where the XML comes down correctly. See this
URL:
http://www.nabble.com/WebService's-SoapMarshaler-not-recocnizing-xsi:type%3D-spe
cs--td13796158.html
As you see, the records element there contains the following attribute:
xsi:type="sf:Contact". And the post correctly points out that the
marshaller should create an array of 'Contact' instead of a plain array of
'sObject'.
So - the question is - what does the XML look like that the customer is
seeing? This is crucial. If it matches the one on the apexdevnet.com site,
then I'm afraid there's not much we can do. There's no amount of voodoo that
would allow us to guess what's the right sObject-derived type. However, I
suspect that the information at that URL is wrong and that the XML being
seen by the customer is actually one that contains a correct xsi:type
attribute. If that's the case, then we have a bug that I need to
investigate/remedy.
Can you get me a sample of the XML the customer is seeing? The customer can
capture this information from the AfterExecute event of the RIO or by using
some proxy/trace utility that monitors HTTP request/response.
Cheers,
Bruneau.
[[End of Reply sent to support]]
"Chris Lively" <chris@livelyconsulting.com> wrote in message
news:479ea940@newsgroups.borland.com...
> Has anyone here been able to connect to salesforce.com with Delphi 2007?
>
> I have code that was generated under the D7 wsdl and hand modified to
> actually work. However, it doesn't return the same results when the
project
> is recompiled (no other changes), under 2007. Considering the 2007 wsdl
> importer doesn't come close to generating the right classes, I'm kind of
> stuck.
>
> My basic problem has to do with type casting. When I make a query call,
it
> returns an array of sObjects. A Contact descends from sObject; however, I
> can't cast my result into a contact... Under D7, same code, same query,
> runs fine.
>
> Ideas?
>
|
| Post Reply
|
| Re: SalesForce wsdl |
 |
Tue, 29 Jan 2008 21:18:47 -060 |
Hi Jean-Marie,
It's probably the exact same issue.
however, here is an example of the return xml. Note that the
xsi:type="sf:Contact" on all of them.
<?xml version="1.0"
encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns="urn:enterprise.soap.sforce.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sf="urn:sobject.enterprise.soap.sforce.com"><soapenv:Body&
gt;<queryResponse><result><done>true</done><queryLoca
tor
xsi:nil="true"/><records
xsi:type="sf:Contact"><sf:Id>003300000034zdFAAQ</sf:Id>
<sf:FirstName>Jack</sf:FirstName><sf:LastName>Rogers</sf:La
stName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdHAAQ</sf:Id>
<sf:FirstName>Andy</sf:FirstName><sf:LastName>Young</sf:Las
tName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdEAAQ</sf:Id>
<sf:FirstName>Sean</sf:FirstName><sf:LastName>Forbes</sf:La
stName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdIAAQ</sf:Id>
<sf:FirstName>Tim</sf:FirstName><sf:LastName>Barr</sf:LastN
ame></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdGAAQ</sf:Id>
<sf:FirstName>Pat</sf:FirstName><sf:LastName>Stumuller</sf:
LastName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdDAAQ</sf:Id>
<sf:FirstName>Rose</sf:FirstName><sf:LastName>Gonzalez</sf:
LastName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdKAAQ</sf:Id>
<sf:FirstName>Babara</sf:FirstName><sf:LastName>Levy</sf:La
stName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdMAAQ</sf:Id>
<sf:FirstName>Jane</sf:FirstName><sf:LastName>Grey</sf:Last
Name></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdJAAQ</sf:Id>
<sf:FirstName>John</sf:FirstName><sf:LastName>Bond</sf:Last
Name></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdRAAQ</sf:Id>
<sf:FirstName>Ashley</sf:FirstName><sf:LastName>James</sf:L
astName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdSAAQ</sf:Id>
<sf:FirstName>Tom</sf:FirstName><sf:LastName>Ripley</sf:Las
tName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdWAAQ</sf:Id>
<sf:FirstName>Jake</sf:FirstName><sf:LastName>Llorrac</sf:L
astName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdOAAQ</sf:Id>
<sf:FirstName>Avi</sf:FirstName><sf:LastName>Green</sf:Last
Name></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdQAAQ</sf:Id>
<sf:FirstName>Lauren</sf:FirstName><sf:LastName>Boyle</sf:L
astName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdVAAQ</sf:Id>
<sf:FirstName>Siddartha</sf:FirstName><sf:LastName>Nedaerk<
/sf:LastName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdUAAQ</sf:Id>
<sf:FirstName>Edna</sf:FirstName><sf:LastName>Frank</sf:Las
tName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdTAAQ</sf:Id>
<sf:FirstName>Liz</sf:FirstName><sf:LastName>D'Cruz&l
t;/sf:LastName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdLAAQ</sf:Id>
<sf:FirstName>Josh</sf:FirstName><sf:LastName>Davis</sf:Las
tName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdNAAQ</sf:Id>
<sf:FirstName>Arthur</sf:FirstName><sf:LastName>Song</sf:La
stName></records><records
xsi:type="sf:Contact"><sf:Id>003300000034zdPAAQ</sf:Id>
<sf:FirstName>Stella</sf:FirstName><sf:LastName>Pavlova</sf
:LastName></records><size>20</size></result></quer
yResponse></soapenv:Body></soapenv:Envelope>
"Jean-Marie Babet" <bbabet@borland.com> wrote in message
news:479f79d7$1@newsgroups.borland.com...
> Hello,
>
> I'm not sure if this is related but yesterday someone in our Support
> organization contacted me with something that sounds somewhat related to
> your post. Here's the reply I sent back. If this is not about the same
> issue, please let me know and I'll be happy to investigate.
>
> Cheers,
>
> Bruneau.
>
> [[Reply sent to support]]
>
> De: Bruneau Babet
> Date: lun. 28/01/2008 16:00
> Objet : RE : New WSDL import case
>
>
> Hello,
>
> Here's my initial assessment of the problem here. The queryResult returns
> an
> array, named 'records', that's typed as an array of 'sObject' but that
> really contains derived types of 'sObject'. Support for derived types were
> added in Delphi SOAP recently. However, we rely on the 'xsi:type'
> attribute
> to tell us what type of object was really sent. Based on the sample XML
> response posted at the following URL -
> https://wiki.apexdevnet.com/index.php/Enterprise_Query - the response for
> records looks like the following:
>
>
> <records xsi:type="sf:sObject">
> <sf:type>Account</sf:type>
> <sf:Id>001D000000HRzKCIA1</sf:Id>
> <sf:Id>001D000000HRzKCIA1</sf:Id>
> <sf:Name>salesforce.com</sf:Name>
> <sf:BillingStreet>The Landmark @ One Market, Suite
> 300</sf:BillingStreet>
> </records>
>
>
> When Delphi SOAP sees this XML it has absolutely no idea was kind of
> object
> to create. Rather I would expect the xml to read something like:
>
> <records xsi:type="sf:Account">
>
> This would tell us that "records is an array of 'sObject' but really
> what's
> coming down is an array of 'Account' objects". We would be happy with
this
> since 'Account' does derive from sObject.
>
> Interestingly, I found a URL where the XML comes down correctly. See this
> URL:
>
>
>
http://www.nabble.com/WebService's-SoapMarshaler-not-recocnizing-xsi:type%3D-spe
cs--td13796158.html
>
> As you see, the records element there contains the following attribute:
> xsi:type="sf:Contact". And the post correctly points out that
the
> marshaller should create an array of 'Contact' instead of a plain array of
> 'sObject'.
>
> So - the question is - what does the XML look like that the customer is
> seeing? This is crucial. If it matches the one on the apexdevnet.com site,
> then I'm afraid there's not much we can do. There's no amount of voodoo
> that
> would allow us to guess what's the right sObject-derived type. However, I
> suspect that the information at that URL is wrong and that the XML being
> seen by the customer is actually one that contains a correct xsi:type
> attribute. If that's the case, then we have a bug that I need to
> investigate/remedy.
>
> Can you get me a sample of the XML the customer is seeing? The customer
> can
> capture this information from the AfterExecute event of the RIO or by
> using
> some proxy/trace utility that monitors HTTP request/response.
>
> Cheers,
>
> Bruneau.
>
> [[End of Reply sent to support]]
>
>
>
> "Chris Lively" <chris@livelyconsulting.com> wrote in
message
> news:479ea940@newsgroups.borland.com...
>> Has anyone here been able to connect to salesforce.com with Delphi
2007?
>>
>> I have code that was generated under the D7 wsdl and hand modified to
>> actually work. However, it doesn't return the same results when the
> project
>> is recompiled (no other changes), under 2007. Considering the 2007
wsdl
>> importer doesn't come close to generating the right classes, I'm kind
of
>> stuck.
>>
>> My basic problem has to do with type casting. When I make a query
call,
> it
>> returns an array of sObjects. A Contact descends from sObject;
however,
>> I
>> can't cast my result into a contact... Under D7, same code, same
query,
>> runs fine.
>>
>> Ideas?
>>
>
>
|
| Post Reply
|
| Re: SalesForce wsdl |
 |
Wed, 30 Jan 2008 17:38:11 -080 |
Hello,
What version of Delphi are you using? I received a copy of the WSDL from our
support organization and I built a service that implements the WSDL and I
have no problem deserializing the proper type. I'm running with the latest
updates posted at the following URL:
http://cc.codegear.com/Item/24535
Also, the sample that support sent me contains a comment about the fact that
D7 and D2007 behave differently. D7 did not support doc|lit services. The
records happened to deserialize correctly in this case strictly because of
the presence of the xsi:type attribute - which was prominent in rpc|encoded
services but is only used in doc|lit services when derivation is involved.
As noted by the comment, the first two records of the array did not get
handled properly in D7 and that was because of the two elements without
xsi:type attribute in the result. i.e.:
<result>
<done>true</done>
<queryLocator> xsi:nil="true"/>
<records xsi:type="sf:Contact">
The two empty elements in the D7 array corresponded to <done> and
<queryLocator> elements respectively.
At this point I need more information to be able to investigate this
properly.
I have a client ready to talk to any implementation of the WSDL. If I can
get a sample of the code that fails, I can investigate further. But first
I'd like to confirm that we're using the same runtime. Also, send me a copy
of the binding generated by the importer.
Cheers,
Bruneau.
|
| Post Reply
|
| Re: SalesForce wsdl |
 |
Wed, 30 Jan 2008 20:23:45 -060 |
It sounds like my client may be going through your support department. I'll
let you take it from them; however, the code was generated from D2007's
importer.
Lively.
"Jean-Marie Babet" <bbabet@borland.com> wrote in message
news:47a125f8$1@newsgroups.borland.com...
> Hello,
>
> What version of Delphi are you using? I received a copy of the WSDL from
> our
> support organization and I built a service that implements the WSDL and I
> have no problem deserializing the proper type. I'm running with the latest
> updates posted at the following URL:
>
> http://cc.codegear.com/Item/24535
>
> Also, the sample that support sent me contains a comment about the fact
> that
> D7 and D2007 behave differently. D7 did not support doc|lit services. The
> records happened to deserialize correctly in this case strictly because of
> the presence of the xsi:type attribute - which was prominent in
> rpc|encoded
> services but is only used in doc|lit services when derivation is involved.
> As noted by the comment, the first two records of the array did not get
> handled properly in D7 and that was because of the two elements without
> xsi:type attribute in the result. i.e.:
>
> <result>
> <done>true</done>
> <queryLocator> xsi:nil="true"/>
> <records xsi:type="sf:Contact">
>
> The two empty elements in the D7 array corresponded to <done> and
> <queryLocator> elements respectively.
>
> At this point I need more information to be able to investigate this
> properly.
>
> I have a client ready to talk to any implementation of the WSDL. If I can
> get a sample of the code that fails, I can investigate further. But first
> I'd like to confirm that we're using the same runtime. Also, send me a
> copy
> of the binding generated by the importer.
>
> Cheers,
>
> Bruneau.
>
>
|
| Post Reply
|
|
|