I'm not sure who is maintaining the PHP Toolkit code, but I keep coming across things that don't seem to make any sense (and they seem easily fixable). For example, I just downloaded PHP Toolkit 13.1 and tried to upsert a record into a custom object.
Of course, there's no sample code for the upsert method for the Enterprise client - only the Partner client and that sample doesn't work at all. Inside SforceEnterpriseClient.php's upsert method, "Contact" is literally hardcoded as the object type.
I changed the code from:
public function upsert($ext_Id, $sObjects) { $arg = new stdClass; $arg->externalIDFieldName = new SoapVar($ext_Id, XSD_STRING, 'string', 'http://www.w3.org/2001/XMLSchema'); foreach ($sObjects as &$sObject) { $sObject = new SoapVar($sObject, SOAP_ENC_OBJECT, 'Contact', $this->namespace); } $arg->sObjects = $sObjects; return parent::_upsert($arg); }
to:
public function upsert($ext_Id, $sObjects,$objectType = "Contact") { $arg = new stdClass; $arg->externalIDFieldName = new SoapVar($ext_Id, XSD_STRING, 'string', 'http://www.w3.org/2001/XMLSchema'); foreach ($sObjects as &$sObject) { $sObject = new SoapVar($sObject, SOAP_ENC_OBJECT, $objectType, $this->namespace); } $arg->sObjects = $sObjects; return parent::_upsert($arg); }
That seems to solve the problem - I simply pass the custom object's name as the third argument, and the field list array as the second argument, and it works just fine. Why can't SalesForce just make that the default behavior? It's been hardcoded for years now... (and nobody's ever bothered to fill out the rest of the PHP Toolkit documentation)
I have a bit of code that uses the username/password/security token combo to log into the API using the PHP Toolkit, and it works fine. What I'd like to do is download the WSDL using this session. My code looks like:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <meta HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> <script src="/static/041509/js/ClientHash.js" type="text/javascript"></script><script type="text/javascript">ClientHash.prototype.needsClientHash('sid_Client', '0000... some stuff omitted...00KeyB', 'my ip address here', '/servlet/servlet.ClientHashValidator?ResponseRequestedURL=%2Fsecur%2Ffrontdoor.jsp%3Fsid%3D00 .... the long session ID again ... rwziBBY%26retURL%3D..%2Fsoap%2Fwsdl.jsp%3Ftype%3D*'); </script><script type='text/javascript'> if (window.location.replace){ window.location.replace('..\/soap\/wsdl.jsp?type=*'); } else {; window.location.href ='..\/soap\/wsdl.jsp?type=*'; } </script> </head> <body> <noscript> You do not have Javascript enabled. Javascript is required to use salesforce.com. Please enable Javascript, then click <a href="../soap/wsdl.jsp?type=*">here</a> to continue. </noscript> </body> </html>
Anyone know how to fix this? All I want to do is download the Enterprise WSDL every once in a while (so when someone adds a field, the server can can auto-download the updated WSDL)
We have a client who has been using Web2Lead for their forms, and once a form has been filled out, the lead assignment rule is triggered and an e-mail is sent to the new lead owner AND to the person who filled out the form.
We're using version 11.0b of the PHP toolkit with a Partner-level connection, and we have the EmailHeader set in the connection correctly. The lead assignment rule gets triggered properly, and the new lead owner receives the appropriate e-mail. However, that e-mail is NOT sent to the person who filled out the form, and the client is upset that our service doesn't behave like the Web2Lead version.
Is this intended behavior or a bug or should it be a completely separate process? I'm not sure where to go from here... Any help is welcome!
The create method still accepts an AssignmentRule object as a valid second argument. In fact, the script didn't complain when I left it in. But when I tried to create a lead with it, the assignment rule didn't get executed, and was not even present in the request sent to the server (which is why it didn't work).
I didn't see any clear documentation to support this besides the name, but using $connection->setAssignmentRuleHeader($AssignmentRuleObject) worked and properly assigned the new lead. Also, when constructing a new AssignmentRule object, the docs say that the first argument should be an int type, but it doesn't look like it's enforced anywhere in the code (which is good, because the rule ID is not an integer). So maybe the data type should be changed from "int" to "string" or "mixed" or something?
2. QueryOptions - not limiting the recordset
I nearly copied the code verbatim from the online samples, but still no go. Limiting the batch size doesn't work:
Code:
$options = new QueryOptions(1);
$client2->setQueryOptions($options);
$rules=$client2->query("Select Id,Name,SobjectType from AssignmentRule where SObjectType='Lead'");
print_r($rules);
I have 3 lead assignment rules, and all 3 of them come back, instead of just 1 as specified in the QueryOptions. The quantity doesn't matter - it can be 1 or 100, but the limit doesn't work. The last line of that code will dump a stdClass object with 3 records in it. Changing the code to use a QueryResult object doesn't seem to make a difference, either. It just changes the type of object that is dumped by print_r to "QueryResult" instead of "stdClass" - the data is the same.
If I try printing out the last request and response immediately after using setQueryOptions, it doesn't look like there was any request/response that went to the server - I just see the data from a describeSObject request that occurred earlier in the testing script.
Select Id,Name from AssignmentRule where ruleType='leadAssignment'
It seems to work fine for pulling back a list of lead assignment rules. But if I try the same query with 1.1 or 11.0, the query fails and says there's no column called "ruleType"
I'm assuming this is just another difference in the APIs, but someone wrote that ruleType code for a reason. Is there any scenario where ruleType would be needed, or can it be safely left out to pull a list of lead assignment rules?
This is actually my 2nd or 3rd question about the transitition to the new 11.0 toolkit from 1.0. I can't find many resources to talk about upgrade paths or things that need to be changed for a smooth transitition, and I'm scared to just implement something and find out later that it just happened to not be transferring over some critical field data or not doing something properly. I don't want to rely on "well, it seems to work in these 5 different scenarios, so it probably works in all the rest of them" - we have a pretty dynamic environment, so it would be helpful to have some sort of documentation on upgrading. Anyone know of anything I could read?
It used to work fine in 1.0 and 1.1, but now it just fails every time. I used XDebug to trace it back, and here's the error:
PHP Fatal error: SoapClient::__setSoapHeaders() [<a href='function.--setSoapHeaders'>function.--setSoapHeaders</a>]: Invalid SOAP header in /....yada yada.../11.0/soapclient/SforceBaseClient.php on line 250
I looked at that line, and it's just setting a SOAP header of "describeSObject" - not sure why it's failing. Any guesses or suggestions?
So I loaded php toolkit to the hosting server that I have online... I get an error trying to start it
Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home/domain/public_html/sfdc/samples/header.inc:9) in /home/domain/public_html/sfdc/samples/login.php on line 30
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/domain/public_html/sfdc/samples/header.inc:9) in /home/domain/public_html/sfdc/samples/login.php on line 30
Does anyone know where I am going wrong???
Am I suppose to do something?
I did test out the report/index.html and got no errors and place my salesforce login...
The create method still accepts an AssignmentRule object as a valid second argument. In fact, the script didn't complain when I left it in. But when I tried to create a lead with it, the assignment rule didn't get executed, and was not even present in the request sent to the server (which is why it didn't work).
I didn't see any clear documentation to support this besides the name, but using $connection->setAssignmentRuleHeader($AssignmentRuleObject) worked and properly assigned the new lead. Also, when constructing a new AssignmentRule object, the docs say that the first argument should be an int type, but it doesn't look like it's enforced anywhere in the code (which is good, because the rule ID is not an integer). So maybe the data type should be changed from "int" to "string" or "mixed" or something?
2. QueryOptions - not limiting the recordset
I nearly copied the code verbatim from the online samples, but still no go. Limiting the batch size doesn't work:
Code:
$options = new QueryOptions(1);
$client2->setQueryOptions($options);
$rules=$client2->query("Select Id,Name,SobjectType from AssignmentRule where SObjectType='Lead'");
print_r($rules);
I have 3 lead assignment rules, and all 3 of them come back, instead of just 1 as specified in the QueryOptions. The quantity doesn't matter - it can be 1 or 100, but the limit doesn't work. The last line of that code will dump a stdClass object with 3 records in it. Changing the code to use a QueryResult object doesn't seem to make a difference, either. It just changes the type of object that is dumped by print_r to "QueryResult" instead of "stdClass" - the data is the same.
If I try printing out the last request and response immediately after using setQueryOptions, it doesn't look like there was any request/response that went to the server - I just see the data from a describeSObject request that occurred earlier in the testing script.
Select Id,Name from AssignmentRule where ruleType='leadAssignment'
It seems to work fine for pulling back a list of lead assignment rules. But if I try the same query with 1.1 or 11.0, the query fails and says there's no column called "ruleType"
I'm assuming this is just another difference in the APIs, but someone wrote that ruleType code for a reason. Is there any scenario where ruleType would be needed, or can it be safely left out to pull a list of lead assignment rules?
This is actually my 2nd or 3rd question about the transitition to the new 11.0 toolkit from 1.0. I can't find many resources to talk about upgrade paths or things that need to be changed for a smooth transitition, and I'm scared to just implement something and find out later that it just happened to not be transferring over some critical field data or not doing something properly. I don't want to rely on "well, it seems to work in these 5 different scenarios, so it probably works in all the rest of them" - we have a pretty dynamic environment, so it would be helpful to have some sort of documentation on upgrading. Anyone know of anything I could read?
It used to work fine in 1.0 and 1.1, but now it just fails every time. I used XDebug to trace it back, and here's the error:
PHP Fatal error: SoapClient::__setSoapHeaders() [<a href='function.--setSoapHeaders'>function.--setSoapHeaders</a>]: Invalid SOAP header in /....yada yada.../11.0/soapclient/SforceBaseClient.php on line 250
I looked at that line, and it's just setting a SOAP header of "describeSObject" - not sure why it's failing. Any guesses or suggestions?
The PHP toolkit provides you an easy way to make Web service API method calls.
Newly supported or enhanced in this release are: * Metadata API * Email * Merge * Workflow * EmptyRecycleBin * Proxy Server * LoginScopeHeader * Header Options at the Connection Level
Click this link to enjoy. Be sure to check out the extensive Samples section as well.
