You need to sign in to do that
Don't have an account?
benfaust
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
Code:
Regards,
Park
Code:
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, ParkMessage Edited by Redsummit on 07-28-2006 03:56 PM
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>
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:Message Edited by Redsummit on 07-28-2006 08:30 PM
Here is a standalone example.
Code:
Also, the instructions.html provides a brief mention of this.
Message Edited by Tran Man on 07-28-2006 09:09 PM
Code:
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
Are you using version 1.0.5 of the PHP library?
Park
include_once('SforceHeaderOptions.php');
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
As a head up, they will need captures of the requests / response that you think are in error.
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
)
...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.
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