function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
benfaustbenfaust 

Fatal Error Connecting Via API

Yesterday evening, connecting via PHP 5.1 was working properly as it has been for some time now. This morning, we're receiving a fatal error. Nothing has changed in our code overnight, and I was wondering if something has changed on the Salesforce side concerning connection.
 
Here's the error:
 
Fatal error: Uncaught SoapFault exception: [soapenv:Client] Element {)item invalid at this location in /path-to/SforceBaseClient.php:79 Stack trace: #0 [internal function]: SoapClient->__call('login', Array) #1 /path-to/SforceBaseClient.php(79): SoapClient->login(Array) #2 /another-path-to/connect.php(13): SforceBaseClient->login('my username is here', 'my password is here') #3 /another-path-to/index.php(228): include_once('/some-path/h...') #4 {main} thrown in /path-to/SforceBaseClient.php on line 79
Park Walker (TAGL)Park Walker (TAGL)
I'm havinga similar problem. Code which has been working for months is now broken and returning this odd error message. Something was changed around July 10 that caused this behaviour. Below is an example of a request and the response, but the same error message is being returned for create and retrieve requests as well. I've updated the WSDL just to be sure that there was no issue with that.

Code:
REQUEST:
<—xml version="1.0" encoding="UTF-8"–>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
                   xmlns:ns1="urn:enterprise.soap.sforce.com">
 <SOAP-ENV:Header>
  <ns1:SessionHeader>
   <ns1:sessionId>REMOVED</ns1:sessionId>
  </ns1:SessionHeader>
 <ns1:AssignmentRuleHeader>
  <item>
   <key>useDefaultRule</key>
   <value>true</value>
  </item>
 </ns1:AssignmentRuleHeader>
 <ns1:QueryOptions/>
 </SOAP-ENV:Header>
 <SOAP-ENV:Body>
 <ns1:query>
  <ns1:queryString>SELECT Id,Name,BillingCity,BillingState from Account</ns1:queryString>
 </ns1:query>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

RESPONSE:
<˜xml version="1.0" encoding="UTF-8"™>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
         xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Client</faultcode>
<faultstring>Element {)item invalid at this location</faultstring>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>

Regards,
Park

Park Walker (TAGL)Park Walker (TAGL)
Here is another example of this behaviour:

Code:
<—xml version="1.0" encoding="UTF-8"–>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                   xmlns:ns1="http://soapinterop.org/xsd" 
                   xmlns:ns2="urn:enterprise.soap.sforce.com">
<SOAP-ENV:Header>
<ns2:SessionHeader>
 <ns2:sessionId>REMOVED</ns2:sessionId>
</ns2:SessionHeader>
<ns2:AssignmentRuleHeader>
 <ns2:assignmentRuleId xsi:nil="true"/>
 <ns2:useDefaultRule>true</ns2:useDefaultRule>
</ns2:AssignmentRuleHeader>
<ns2:QueryOptions>
 <item>
  <key>batchSize</key>
  <value>2000</value>
 </item>
</ns2:QueryOptions>
</SOAP-ENV:Header>
 <SOAP-ENV:Body>
  <ns2:create>
   <ns2:sObjects xsi:type="ns1:Lead">
    <Company>Redsummit</Company>
    <Country>US</Country>
    <Email>fake@redsummiX.com</Email>
    <FirstName>Park</FirstName>
    <LastName>Walker</LastName>
    <LeadSource>Web Registration</LeadSource>
    <No_of_Sales_Reps__c>0-50</No_of_Sales_Reps__c>
    <Phone>666-555-4321</Phone>
    <State>CA</State>
   </ns2:sObjects>
  </ns2:create>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>



<xml version="1.0" encoding="UTF-8">
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <soapenv:Fault>
   <faultcode>soapenv:Client</faultcode>
   <faultstring>Element {)item invalid at this location</faultstring>
  </soapenv:Fault>
 </soapenv:Body>
</soapenv:Envelope>

 

SuperfellSuperfell
You're assignment rule header is not valid.

 <ns1:AssignmentRuleHeader>
<item>
<key>useDefaultRule</key>
<value>true</value>
</item>
</ns1:AssignmentRuleHeader>

it should be
 <ns1:AssignmentRuleHeader>
<useDefaultRule>true</useDefaultRule>
</ns1:AssignmentRuleHeader>


Park Walker (TAGL)Park Walker (TAGL)
Yes, that's correct... and here's the solution to the problem.

Apparently the serializer in ext/soap (v 5.1.4) doesn't properly handle type 'xsd:int'. If you use the code provided you get the incorrect XML:

$query_header = new SoapHeader('urn:enterprise.soap.sforce.com','QueryOptions',25);

produces:

<ns2:QueryOptions><item><key>batchSize</key><value>25</value></item></ns2:QueryOptions>

If you uses this instead:

$batch_size = new SoapVar(25, XSD_UNSIGNEDINT, 'batchSize', "http://soapinterop.org/xsd"); $query_header = new SoapHeader('urn:enterprise.soap.sforce.com','QueryOptions',$batch_size);

you get: <ns2:QueryOptions xsi:type="ns1:batchSize">25</ns2:QueryOptions>

and your query works.

Similarly, the assignment rule header needs to use the following:    

$assign = new SoapVar(true, XSD_BOOLEAN, 'useDefaultRule', "http://soapinterop.org/xsd");     $rule_header = new SoapHeader('urn:enterprise.soap.sforce.com','AssignmentRuleHeader',$assign);

The PHP library should be updated to generate the headers correctly. Now if we could just figure out why this worked three weeks ago but doesn't now we might better understand how to avoid these surprises in the future.

Regards, Park

Message Edited by Redsummit on 07-28-2006 03:56 PM

SuperfellSuperfell
I would suggest that something (whether intentional or not) changed on your end, the code that handles the parsing of inbound requests hasn't changed since the 7.0 api was released back in January.

You should also note that while this might not error out, it is also not correct, and is probably being ignored by the server
<ns2:QueryOptions xsi:type="ns1:batchSize">25</ns2:QueryOptions>

it should be
<ns2:QueryOptions>
  <ns2:batchSize>25</ns2:batchSize>
</ns2:QueryOptions>

Park Walker (TAGL)Park Walker (TAGL)

After another look through v1.0.5 of the PHP library it appers that this problem is already known as there is now a file containing the classes necessary to get the headers working correctly. Unfortunatly, SForcebaseClient does not yet incorporate the new header code.

To get the correct headers it's necessary to use something along the lines of the following to set the headers rather than the current code:

Code:
include 'SForceHeaderOptions.php';

$sforce_header = new SoapHeader($this->namespace,'SessionHeader',array('sessionId' => $loginResult->sessionId));
$batch_size = new QueryOptions(25);
$query_header = new SoapHeader($this->namespace,'QueryOptions',$batch_size);
$assign = new AssignmentRuleHeader(null, true);
$rule_header = new SoapHeader($this->namespace,'AssignmentRuleHeader',$assign);
$sforce->__setSoapHeaders(array($sforce_header,$query_header,$rule_header));

Message Edited by Redsummit on 07-28-2006 08:30 PM

Tran ManTran Man
There is an example of using the AssignmentRuleHeader in test/SforcePartnerClientTest.

Here is a standalone example.


Code:
require_once ('../soapclient/SforcePartnerClient.php');
require_once ('../soapclient/SforceHeaderOptions.php');

try { $mySforceConnection = new SforcePartnerClient(); $mySoapClient = $mySforceConnection->createConnection("../samples/partner.wsdl.xml"); $mylogin = $mySforceConnection->login("test@test.com", "xxxxx"); $createFields = array ( 'FirstName' => 'First', 'LastName' => 'Last', 'Company' => 'TestCompany', 'SICCode__c ' => '9999', ); $header = new AssignmentRuleHeader(null, true); $sObject1 = new SObject(); $sObject1->fields = $createFields; $sObject1->type = 'Lead'; $createResponse = $mySforceConnection->create(array ( $sObject1, ), $header, NULL); print_r($createResponse); } catch (Exception $e) { echo $e->faultstring; } echo $mySforceConnection->getLastRequest();

Also, the instructions.html provides a brief mention of this.


Message Edited by Tran Man on 07-28-2006 09:09 PM

Tran ManTran Man
And here is an example of using queryOptions

Code:
require_once ('../soapclient/SforcePartnerClient.php');
require_once ('../soapclient/SforceHeaderOptions.php');

$query = 'SELECT Id,Name,BillingCity,BillingState,Phone,Fax from Account';

$mySforceConnection = new SforcePartnerClient();
$mySoapClient = $mySforceConnection->createConnection("../samples/partner.wsdl.xml");
$mylogin = $mySforceConnection->login("test@test.com", "xxxxxxx");

$queryOptions = new QueryOptions(200);

try {
  $response = $mySforceConnection->query($query, $queryOptions);
} catch (SoapFault $fault) {
  $this->fail($fault->faultstring);
}
echo $mySforceConnection->getLastRequest();

 

benfaustbenfaust

So is the error "Element {)item invalid at this location" also related to this? We had this error one day last week, and the next morning it had mysteriously fixed itself and continued to work until some time over the weekend when not only did this error reappear, but also it appeared in more places than before. Either I have a serious sleep disorder and am coming to the office changing code in my sleep, or something is going on elsewhere. Or we have some very smart and pesky mice.

We have to get this working again immediately. From the above discussion it appears as though there is a header issue. The problem with that is we're getting this error before the headers are set. We're just logging in with the exact same code that has always worked before.

Message Edited by benfaust on 07-31-2006 10:39 AM

Park Walker (TAGL)Park Walker (TAGL)
I was getting exactly the same error message. I did a fair amount of testing and it was pretty obvious that the headers were the issue. My previous code had also been working fine up until mid-July. I'd suggest that you try either removing all but the session header or implement the headers using the new format to see if that solves your problem.

Park
benfaustbenfaust
With just the login, we're not setting any headers. Are you referring to non-related headers on the page PHP is drawing, or API headers?
Park Walker (TAGL)Park Walker (TAGL)
If you'd like to post the code you're using I'll take a look and see if I can spot the problem. My testing only turned up a problem with the headers: everything else was working fine. Changing the way the headers were created and passed solved the problem.

Are you using version 1.0.5 of the PHP library?

Park
benfaustbenfaust
We're using 1.0.5. Once again, keep in mind none of our code changed to start these errors. Here's the stripped-down version of one place in which our program is breaking.
 
include_once('SforcePartnerClient.php');
include_once('SforceHeaderOptions.php');
$client2=new SforcePartnerClient();
$client=$client2->createConnection("partner.wsdl.xml");
 
$client2->setClientID('ClientID/Here');
$result = $client2->login('usernamehere','passwordhere');
jrizzojrizzo

Bump...

This is a critical issues that has not yet been resolved.  The result of this "error" is that we cannot insert or upsert data into SF, and in effect, rendering our value proposition null and void.

What do we have to do on our end to elevate this to extreme?  Pls advise!

Joseph Rizzo
President/CEO
PluraPage/iNeoMarketing
Direct Line: 571.203.7081
Company Line: 703.453.9120
Cell: 703.244.8516
Fax: 703.453.9170
AOL IM: joemktg2
www.PluraPage.com

www.iNeoMarketing.com

SuperfellSuperfell
The forums are for peer support. You should call the support line or log a case via the app for offical support.
As a head up, they will need captures of the requests / response that you think are in error.

jrizzojrizzo
Appreciate that, but we've been asked to post everything to this board.
SuperfellSuperfell
post captures of the request / response that you think is in error.
SuperfellSuperfell
Looks like your case is waiting on the answers to the API questionare you were sent.
benfaustbenfaust
These were answered over the phone, and login access was granted and a copy of the errors were sent within minutes after the phone call to open the case ended.
benfaustbenfaust

I was instructed to post this e-mail summary here:

From: Ben Faust
Sent: Friday, August 04, 2006 7:19 AM
To: 'Ralph Eddy'
Subject: RE: not able to resolve SF issue

 

Ralph,

 

There is no error at the point of this line. The error comes at the login call after the setClientID line.

Thanks,
Ben Faust


From: Ralph Eddy [mailto:reddy@salesforce.com]
Sent: Thursday, August 03, 2006 6:01 PM
To: Ben Faust
Cc: Joseph Rizzo
Subject: RE: not able to resolve SF issue

 

I see your point.

 

Do you get the error when you execute this line of code or is it after you make a call back to the API?

 

Ralph

 


From: Ben Faust [mailto:Ben@eem.tv]
Sent: Thu 8/3/2006 2:35 PM
To: Ralph Eddy
Cc: Joseph Rizzo
Subject: RE: not able to resolve SF issue

Ralph,

 

The problem seems to keep changing.

 

When the error “Element {)item invalid at this location” first appeared, commenting out the line which logs in with the Enterprise code (setClientID) removed the error. That day no resolution was found, and at the end of the day the error persisted. The next morning the error was gone.

 

When the error reappeared Monday (or during the weekend), commenting out that line did NOT fix the problem.

 

Today I just now tried commenting out that line again (since the sample login works), and the error is gone.

 

So using the same code, there are errors some days and no errors other days. Some days commenting out the setClientID removes the errors, other days it makes no difference.

 

It’s possible there’s some type of error in our code, but if so, that error is being ignored some days, and handled in different ways the other days.

 

The error is server-side, and persists using different computers at different locations. Installing our system on another server isn’t a viable option.

 

So for today, the line which is breaking our system is this:

$mySforceConnection->setClientID('Credentials Here');

 

 

 

(Note, in regards to the API Server URL because it is not specifically addressed in the email response above. We have hard coded into the bottom of the WSDL both:

https://na4.salesforce.com/services/Soap/u/7.0

https://www.salesforce.com/services/Soap/c/7.0

)

 

 

 

benfaustbenfaust

...continued...

From: Ralph Eddy [mailto:reddy@salesforce.com]
Sent: Thursday, August 03, 2006 4:46 PM
To: Jase Clamp; jrizzo@ineomarketing.com; Blaine Okamura; Michael Kreaden
Cc: Nick Tran
Subject: Re: not able to resolve SF issue

I am still unclear on one question: Can you get any PHP code to connect to salesforce?

In this situation I would try anything and everything.

Get sample PHP from our dev site or from Nick and make a connection.

Try the same code, as well as your production code, from home - eliminates your firewall.

You can hardcode the API Server URL since this is a test.

Also, try making a connection back to salesforce using our single sign-on.

Some of these items will hopefully return valuable results.

I will be honest and say that none of these tests assumes that there is a problem with our API.

Different computers running different code passing through different firewalls connecting to different accounts and api servers should give enough evidence to point us towards a solution.

Ralph

 

From: Jase Clamp
Sent: Thursday, August 03, 2006 2:03 PM
To: 'Joseph Rizzo'; 'Ralph Eddy'
Subject: RE: not able to resolve SF issue

 

Am I correct that test code does login but your productiion code does not? 

We have not been able to obtain any test code to trouble shoot this problem regarding the login. You are correct that login is not working for our production code. We have tried two different PHP toolkits from Nick Tran and reloaded a new WSDL with multiple toolkits with no resolution.

Is your test running from the same computer? 

We have one server dedicated to running the PluraPage application and association SF connection, however we have tested from numerous client browsers. The error is of course, server side. 

Does the test use the same username and password as a failing customer? 

Yes, we have tested under multiple verified usernames and passwords and all are failing. We are logging connections and all customers that are connecting are failling. 


Are you using the partner WSDL?
Yes, we have it setup to use Partner 7.0  (specifically, the wsdl.xml file references https://www.salesforce.com/services/Soap/c/7.0)

 

From: Ralph Eddy [mailto:reddy@salesforce.com]
Sent: Thursday, August 03, 2006 1:15 PM
To: jrizzo@ineomarketing.com; jclamp@ineomarketing.com
Cc: Blaine Okamura; Michael Kreaden; Jesse Dailey
Subject: Re: not able to resolve SF issue

Joesph, I am on vacation and will not be able to do a call.

Am I correct that test code does login but your productiion code does not?
Is your test running from the same computer?
Does the test use the same username and password as a failing customer?
Are you using the partner WSDL?

I feel your message as to the cause of this problem that is going to be read by our customers is a bit premature.

10s of millions of API calls are successful every day.

Let's work together to solve this issue.

Ralph

 

From: Jase Clamp [mailto:jase@eem.tv]
Sent: Thursday, August 03, 2006 8:50 AM
To: Joseph Rizzo
Subject: not able to resolve SF issue



Joe,

Its been 3 days and we've been working very aggressively on this SF api issue but not making progress. This is the same problem that cropped up last week, dissappeared and then came up again. We can not isolate any changes on our side. No one else has access to the server and the code did not change, I am not aware of any upgrades that took place on iNetU's part and I'm 99% sure that no normal server upgrade would affect this.

We've been on the discussion board with other users and with SF employees and no one is saying anything changed on their end - although other users have expressed the same concerns. I just want to underline the importance of this issue - the API isn't even letting PluraPage log-in, no forms results are being submitted, all SF functionality is disabled until we can have this resolved. Since logging in to the API never gave us trouble before - I am seriously concerned about the stability of the API. I have tested their java toolkit and it seems to be logging in so I can only assume that there is an error in their WSDL/toolkit.

We're doing everything we can think of to diagnose this such as examining/isolating relevnt portions of the toolkit/WSDL. I'm also leaving an urgent voicemail and email for Ralph to try and schedule a call with him the moment he gets to his desk. We have been working with Nick but we're not getting anywhere.

benfaustbenfaust
Timeline of shifting errors:
 
Thursday, 07/27/2006 - System was breaking unless setClientID was commented out.
 
Friday, 07/28/2006 - System was working perfectly.
 
Monday, 07/31/2006 - System was breaking regardless of whether setClientID was commented out.
 
Thursday, 08/03/2006 - System was breaking unless setClientID was commented out. (current state)
SuperfellSuperfell
post a capture of the request/response xml you think is in error.
Park Walker (TAGL)Park Walker (TAGL)
Ben,

I have modified SforceBaseClient to use the new format headers. You can grab the modified file at http://www.redsummit.com/SforceBaseClient-test.zip. Please give this a try and see if it solves your problem.

Regards,
Park

2007-04-11: This file is no longer available, and no longer necessary. use the v1.1 toolkit instead.

Message Edited by Redsummit on 04-11-2007 12:25 PM

RmcnultyRmcnulty
[11-Apr-2007 10:24:24] PHP Fatal error:  Using $this when not in object context on line 17
RmcnultyRmcnulty
I'm using php5-soap-5.2.1_3  with the same error