+ Start a Discussion
trinitytrinity 

PERL: Assigning lead rule when creating a lead through API

Does anyone have perl code for it?

Thanks!
Ron HessRon Hess
not tried it, but it would look something like this:

Inside Salesforce.pm, locate the sub create() ,
modify this sub to add a header to the create call to set the AssignmentRuleHeader

my example is based on query, so to set a batch size i use
my $batchsize = SOAP::Header->name('batchSize' => $in{'limit'});
my $qry_opts = SOAP::Header->name('QueryOptions' => \$batchsize);


then from the api help ---
useDefaultRule boolean

Specifies whether to use the default rule for rule-based assignment (True) or not (False). The default rule is assigned by users in the Salesforce user interface.
------------------------------

so you would do something like this
my $autoassign = SOAP::Header->name('useDefaultRule' => 'true' );
my $assign_hdr = SOAP::Header->name('AssignmentRuleHeader' => \$autoassign );

# then modify the client call to include this header

my $r = $client->call($method =>
SOAP::Data->name('sObjects' => \SOAP::Data->value(@elems))
->attr( { 'xsi:type' => 'sforce:'.$type } ),
$self->get_session_header(), $assign_hdr );


all of this requirs you modify the Salesforce.pm module, best of luck.
bildbild
I believe that using the default assignment rule should be the default, as it was in the old servlet-based WebToLead method. Is anyone currently maintaining the Salesforce.pm, etc, that we PERL developers are using?
Ron HessRon Hess
I don't think it's been updated recently, my version has diverged because it has custom objects listed inside the module, not the WSDL support that i would really like.
bildbild

my $autoassign = SOAP::Header->name('useDefaultRule' => 'true' );
my $assign_hdr = SOAP::Header->name('AssignmentRuleHeader' => \$autoassign );

use Data::Dumper ;
print STDERR "Salesforce.create: using assign_hdr: $assign_hdr\n" ;
print STDERR Dumper($assign_hdr) ;

my $r = $client->call($method =>
SOAP::Data->name('sObjects' => \SOAP::Data->value(@elems))
->attr( { 'xsi:type' => 'sfons:'.$type } ),
$self->get_session_header(), $assign_hdr);



By the way, I did try to do this, and I STILL did not get the auto-assignment I expected. The Salesforce 'experts' here at work say that my rules are set up correctly, but for some reason, the leads are always assigned to the user with which I called 'login', rather than the default queue, or any of the queues mentioned in the leads. My xsi:type is a little different from the one in your example (sfons vs. sforce), but I am well outside of my SOAP comfort range at this point, so I have no idea if that is an issue.
Ron HessRon Hess
every thing you are doing looks correct.

did you try to dump the return value from the create to see
if there was a fault or error?

the next step would be to capture the SOAP which is created by the SOAP::Lite
module and post it here so more eyes could look at it.

to get a trace of the soap i think you can just add the following trace
statement to your deserializer package decl inside Salesforce.PM

#
# BEGIN Deserializer
package Salesforce::Deserializer;
use SOAP::Lite +trace => 'debug' ;


i can try to reproduce this but it i'm not sure when.
bildbild
You asked for it. :) I did *** out my password, and you can see a couple of my own debugs in there. I see the AssignmentRuleHeader in there, so I have no idea what is going on. The same thing happens both in my development account (william@x1.com) and the live account, where the old servlet.WebToLead stuff still works fine.

Thanks for any insight you can give me,
b


SOAP::Transport::HTTP::Client::send_receive: POST https://www.salesforce.com/services/Soap/u/4.0 HTTP/1.1
Accept: text/xml
Accept: multipart/*
Content-Length: 577
Content-Type: text/xml; charset=utf-8
SOAPAction: ""

william@x1.com******
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
Connection: close
Connection: close
Date: Mon, 24 Oct 2005 21:27:02 GMT
Server: Resin/3.0.12
Content-Type: text/xml; charset=utf-8
Client-Date: Mon, 24 Oct 2005 21:27:02 GMT
Client-Peer: 63.146.199.33:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=Salesforce.com, Inc./OU=Applications/OU=Terms of use at www.verisign.com/rpa (c)00/CN=www.salesforce.com
Client-SSL-Cipher: RC4-MD5
Client-SSL-Warning: Peer certificate not verified
Client-Transfer-Encoding: chunked






https://na1-api.salesforce.com/services/Soap/u/4.0
2FN7ON_wr8WLv78237_4fD6TypgDRmbklbJfYOv78t31X5KN_ZNrP_6DnVi9U1MozshC_C0gBkZkc3kNA1fYORhD2wYHcrlK4SNdGN37zi4=
00530000000iSMcAAM





SOAP::Transport::HTTP::Client::send_receive: POST https://na1-api.salesforce.com/services/Soap/u/4.0 HTTP/1.1
Accept: text/xml
Accept: multipart/*
Content-Length: 2857
Content-Type: text/xml; charset=utf-8
SOAPAction: ""


>
>
>
>2FN7ON_wr8WLv78237_4fD6TypgDRmbklbJfYOv78t31X5KN_ZNrP_6DnVi9U1MozshC_C0gBkZkc3kNA1fYORhD2wYHcrlK4SNdGN37zi4=
>
>true
>
>
>
>Operations
>Script

>130 W. Union Apartment X
>TestClasses Test Script

>Pasadena
>26-50
>California
>YDS
>Le Dude
>Tester
>bild@x1.com
>X1





>444-000-3334

>United States


>Yes

>Agriculture
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 24 Oct 2005 21:27:02 GMT
Server: sfdc
Content-Type: text/xml; charset=utf-8
Client-Date: Mon, 24 Oct 2005 21:27:02 GMT
Client-Peer: 63.146.199.40:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=Salesforce.com, Inc./OU=Applications/OU=Terms of use at www.verisign.com/rpa (c)00/CN=na1-api.salesforce.com
Client-SSL-Cipher: RC4-MD5
Client-SSL-Warning: Peer certificate not verified
Client-Transfer-Encoding: chunked







00Q30000007f2s6EAA
true





Ron HessRon Hess
enough of this got chopped out to make it not usefull to debug
i think you need to to replace < and > with [ and ] so we can see the soap
envelope and body elements

thanks
bildbild
Yeah, that was pretty rough. I replaced < and > with [ and ].

Related question: is it possible that, for some reason, my account simply does not have the capability to use the auto-assignment rules?

I tried to manually (through the browser interface) to create a Lead (and a Case), checking the 'assign using active assignment rules' box, and it gives me the error 'there is no active case assignment rule'.


SOAP::Transport::HTTP::Client::send_receive: POST https://www.salesforce.com/services/Soap/u/4.0 HTTP/1.1
Accept: text/xml
Accept: multipart/*
Content-Length: 577
Content-Type: text/xml; charset=utf-8
SOAPAction: ""

[?xml version="1.0" encoding="UTF-8"?][SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"][SOAP-ENV:Body][namesp14:login xmlns:namesp14="urn:partner.soap.sforce.com"][username xsi:type="xsd:string"]william@x1.com[/username][password xsi:type="xsd:string"]******[/password][/namesp14:login][/SOAP-ENV:Body][/SOAP-ENV:Envelope]
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
Connection: close
Connection: close
Date: Mon, 24 Oct 2005 21:27:02 GMT
Server: Resin/3.0.12
Content-Type: text/xml; charset=utf-8
Client-Date: Mon, 24 Oct 2005 21:27:02 GMT
Client-Peer: 63.146.199.33:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=Salesforce.com, Inc./OU=Applications/OU=Terms of use at www.verisign.com/rpa (c)00/CN=www.salesforce.com
Client-SSL-Cipher: RC4-MD5
Client-SSL-Warning: Peer certificate not verified
Client-Transfer-Encoding: chunked

[?xml version="1.0" encoding="UTF-8"?]
[soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"]
[soapenv:Body]
[loginResponse xmlns="urn:partner.soap.sforce.com"]
[result]
[serverUrl]https://na1-api.salesforce.com/services/Soap/u/4.0[/serverUrl]
[sessionId]2FN7ON_wr8WLv78237_4fD6TypgDRmbklbJfYOv78t31X5KN_ZNrP_6DnVi9U1MozshC_C0gBkZkc3kNA1fYORhD2wYHcrlK4SNdGN37zi4=[/sessionId]
[userId]00530000000iSMcAAM[/userId]
[/result]
[/loginResponse]
[/soapenv:Body]
[/soapenv:Envelope]
Salesforce.create: using assign_hdr: SOAP::Header=HASH(0xa25d81c)
$VAR1 = bless( {
'_name' =] 'AssignmentRuleHeader',
'_signature' =] [],
'_value' =] [
\bless( {
'_name' =] 'useDefaultRule',
'_signature' =] [],
'_value' =] [
'true'
],
'_attr' =] {}
}, 'SOAP::Header' )
],
'_attr' =] {}
}, 'SOAP::Header' );
SOAP::Transport::HTTP::Client::send_receive: POST https://na1-api.salesforce.com/services/Soap/u/4.0 HTTP/1.1
Accept: text/xml
Accept: multipart/*
Content-Length: 2857
Content-Type: text/xml; charset=utf-8
SOAPAction: ""

[?xml version="1.0" encoding="UTF-8"?]
[SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
]
[SOAP-ENV:Header
]
[SessionHeader
]
[sessionId xsi:type="xsd:string"
]2FN7ON_wr8WLv78237_4fD6TypgDRmbklbJfYOv78t31X5KN_ZNrP_6DnVi9U1MozshC_C0gBkZkc3kNA1fYORhD2wYHcrlK4SNdGN37zi4=[/sessionId][/SessionHeader]
[AssignmentRuleHeader
]
[useDefaultRule xsi:type="xsd:string"
]true[/useDefaultRule][/AssignmentRuleHeader][/SOAP-ENV:Header]
[SOAP-ENV:Body
]
[sforce:create xmlns:sforce="urn:partner.soap.sforce.com" xmlns:sfons="urn:sobject.partner.soap.sforce.com"
]
[sObjects xsi:type="sfons:Lead"
]
[sfons:Department__c xsi:type="xsd:string"
]Operations[/sfons:Department__c]
[sfons:FirstName xsi:type="xsd:string"
]Script[/sfons:FirstName]
[sfons:Purchasing_Role__c xsi:null="1"/]
[sfons:Street xsi:type="xsd:string"
]130 W. Union Apartment X[/sfons:Street]
[sfons:LeadSource xsi:type="xsd:string"
]TestClasses Test Script[/sfons:LeadSource]
[sfons:annual_overall_sales__c xsi:null="1"/]
[sfons:City xsi:type="xsd:string"
]Pasadena[/sfons:City]
[sfons:Number_of_Employees__c xsi:type="xsd:string"
]26-50[/sfons:Number_of_Employees__c]
[sfons:State xsi:type="xsd:string"
]California[/sfons:State]
[sfons:source__c xsi:type="xsd:string"
]YDS[/sfons:source__c]
[sfons:Title xsi:type="xsd:string"
]Le Dude[/sfons:Title]
[sfons:LastName xsi:type="xsd:string"
]Tester[/sfons:LastName]
[sfons:Email xsi:type="xsd:string"
]bild@x1.com[/sfons:Email]
[sfons:Company xsi:type="xsd:string"
]X1[/sfons:Company]
[sfons:annual_software_sales__c xsi:null="1"/]
[sfons:PostalCode xsi:null="1"/]
[sfons:Geographic_market__c xsi:null="1"/]
[sfons:Product_Interest__c xsi:null="1"/]
[sfons:Level__c xsi:null="1"/]
[sfons:Phone xsi:type="xsd:string"
]444-000-3334[/sfons:Phone]
[sfons:funding_status__c xsi:null="1"/]
[sfons:Country xsi:type="xsd:string"
]United States[/sfons:Country]
[sfons:email_client__c xsi:null="1"/]
[sfons:purchase_timeframe__c xsi:null="1"/]
[sfons:Evaluating_for_Company__c xsi:type="xsd:string"
]Yes[/sfons:Evaluating_for_Company__c]
[sfons:Description xsi:null="1"/]
[sfons:Industry xsi:type="xsd:string"
]Agriculture[/sfons:Industry][/sObjects][/sforce:create][/SOAP-ENV:Body][/SOAP-ENV:Envelope]
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 24 Oct 2005 21:27:02 GMT
Server: sfdc
Content-Type: text/xml; charset=utf-8
Client-Date: Mon, 24 Oct 2005 21:27:02 GMT
Client-Peer: 63.146.199.40:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=Salesforce.com, Inc./OU=Applications/OU=Terms of use at www.verisign.com/rpa (c)00/CN=na1-api.salesforce.com
Client-SSL-Cipher: RC4-MD5
Client-SSL-Warning: Peer certificate not verified
Client-Transfer-Encoding: chunked

[?xml version="1.0" encoding="UTF-8"?]
[soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"]
[soapenv:Body]
[createResponse xmlns="urn:partner.soap.sforce.com"]
[result]
[errors xsi:null="true"/]
[id]00Q30000007f2s6EAA[/id]
[success]true[/success]
[/result]
[/createResponse]
[/soapenv:Body]
[/soapenv:Envelope]
SalesforceUtils.createLead: result: HASH(0xa27af14)
$VAR1 = {
'success' =] 'true',
'errors' =] undef,
'id' =] '00Q30000007f2s6EAA'
};

Message Edited by bild on 10-25-2005 12:05 PM

SuperfellSuperfell
The AssignmentRuleHeader needs to be in the urn:sobject.enterprise.soap.sforce.com namespace
bildbild


SimonF wrote:
The AssignmentRuleHeader needs to be in the urn:sobject.enterprise.soap.sforce.com namespace




Aha! Well, this is something. Ron or Simon (or anyone), any idea how to realize this in the current Salesforce.pm module?

I am still curious as to why my developer login (william@x1.com) does not allow me to manually create Leads (or Cases) with the auto assignment rules by checking the 'assign using active assignment rule' box.
trinitytrinity
Change u to c in the following line in Salesforce.pm or your code.

https://www.salesforce.com/services/Soap/u/4.0
bildbild


trinity wrote:
Change u to c in the following line in Salesforce.pm or your code.

https://www.salesforce.com/services/Soap/u/4.0




This does not seem to make any appreciable difference. I have modified the namespace in several places in order to try to conform to Simon's suggestion, again with no effect on the non-performing auto-assignment rules.

Since I cannot even create one manually, I am of the opinion that either (a) I have not correctly configured the rules, (b) my 'Developer' account does not allow their use. However, I would still appreciate any insight on changing the Salesforce.pm that I downloaded from sourceforge in order to call out the correct namespace.
Ron HessRon Hess
I did something like this to my module

# comment out partner namespace
# my $uri = 'urn:partner.soap.sforce.com';
my $uri = 'urn:enterprise.soap.sforce.com';
my $sorun = 'urn:sobject.enterprise.soap.sforce.com';

near to top of the module to move everything into the enterprise name space, you must also search out
and replace any hard-coded uses of 'urn:partner...' to use one of these two new variables

Also, i would really look into why your default rule does not fire when creating leads from within the app, then move on to testing to make sure it fires when using web2lead, then come back to the api problem.

sorry the perl module is giving so much trouble, if i get a chance to make a fresh start on changes i will.
bildbild
First of all, thanks for all of your help.

I spoke to Nia at Salesforce Support, and it turns out that the default auto-assignment rule created when someone gets a new Developer account is defective. You have to COMPLETELY DELETE your auto-assignment rule, and create a new one from scratch. Deleting just the rule entries is not enough.

Once I did that, auto-assignment rules correctly kicked in when I manually (through the web interface) created a Lead. Also, they correctly kick in when I use Web-to-Lead (which I had to enable in Setup > Customize > Leads > Web-to-Lead before it would properly store them in the database).

Unfortunately, even after replacing all of the uri and sfons references in Salesforce.pm with variables, pointing to the ones you suggested, auto-assignment rules still do not kick in when I create a Lead that way. Would it be possible for you to post your version of Salesforce.pm that DOES work somewhere, so I can try it out to see if it makes a difference?
Ron HessRon Hess
i'll have to setup a dev org and config this the way you did.
may take me a few days, been sorta busy writing some new scontrols...
bildbild
Nia Samady got back to me after I sent her my SOAP dump that we thought should have been working. It turns out that the AssignmentRuleHeader itself also had to be explicitly placed in the enterprise namespace.

So in create:


my $uri = "urn:enterprise.soap.sforce.com" ;

...

my $autoassign = SOAP::Header->name('useDefaultRule' => 'true' );
my $assign_hdr = SOAP::Header->name('AssignmentRuleHeader' => \$autoassign )->uri($uri) ;


Then pass the header through to the call as mentioned earlier ...


my $r = $client->call($method =>
SOAP::Data->name('sObjects' => \SOAP::Data->value(@elems))
->attr( { 'xsi:type' => 'sfons:'.$type } ),
$self->get_session_header(), $assign_hdr);


And remember, if you have a newly created Developer account, YOU MUST COMPLETELY DELETE ALL OF YOUR AUTO-ASSIGNMENT RULES, and then recreate them. The ones that are created by default do not work, for some reason. If you cannot manually create a Lead or Case using the web interface (using the 'Assign using active assignment rule' checkbox at the bottom of the new lead/new case page), you are already hosed.
Ben KusBen Kus
Anyone ever get this to work?
 
I have the same issue as bild... I tried the same thing (changing the headers to include the default rule), which seems to show up OK in the SOAP headers, but does not apply the assignment rules properly.

Ben
Ben KusBen Kus
Finally got it to work! My browser was cutting off part of the solution that bild posted.

Thanks!