Salesforce Webform 3.x

Also per Bryan's urging to take advantage of the webform hooks now available in webform 3.x

Right now I am thinking of doing this in the 2.x branch.. although i think the commits would really make this a code rewrite of the module. Dunno yet .. I am currently digging in and coding in a sandbox.

Some random notes I've compiled so far:

1. Architecture of the module should take advantage of webform hooks

Why is this important? It's important because the webform 3.x branch introduced a lot of features like:
a.) Any Content Type is a webform which means our form alters have changed from form id checks to more of does the form object have a webform object?
Webform 3.x Checkout admin/settings/webform
b.) Multi value fields.
c.) deprecate the extras steps our user's have to go through thus making this module more user friendly.
for example:
because of the hook_webform_submission_insert, hook_webform_submission_load, hook_webform_submission_delete
we already have access to the webform sid via $submission->sid we can avoid this entry:

As the last entry in the Webform, add a hidden field 'SID Key'. Select 'Webform SID Key'
as the Salesforce key to map to. It is very important that the SID Key be the LAST item in
the form.

(Please include the changes this list has missed)

2. Should we make use of Salesforce API?

This is big one -- I dont know. Currently doing a few sandboxes to figure out the strengths and weaknesses.

Here's what I did I installed BtLife's Updated Salesforce Webform Integration module located @ http://drupal.org/sandbox/btlife/1099228
, the module requires salesforce api.

There's are a lot of good things to say about the updated module, things we can improve upon, and things that are part of drupal's salesforce suite api that's just too .. bloated in there design. I might be wrong about it please correct me if I am wrong.

for improvement
a.) Installation of Salesforce Suite API requires users to upload their own wsdl file and create your own directory where that particular wsdl file is located. This differs from what our users are currently used to already. Install the Salesforce PHP toolkit and make use of it's wsdl file.
Having said that in the updated module... it ignores the wsdl file provided by salesforce_api and makes use of the wsdl file in the salesforce php toolkit.

So here we are .. using salesforce api has some wins.. and a few losses.

wins:
a. ) cuts down function definition
losses:
a. ) we are going with the over generalized way of doing things by salesforce_api things like : hey our users are now forced to create their own wsdl directory and upload their own wsdl file. yikes! big fail.
b.) our users see additional configuration settings that they really do not need to see aka admin/settings/salesforce/fieldmap this is where salesforcewebform excel's with because the workflow gives contextual information to the user like.. on the webform field they get to map the salesforce field. I think was my huge frustration with the sf_webform module.. prolly one of the reasons I failed to install it.

this is some of thoughts so far. will be sure to add more, what do you guys think?

Here's a summary report of btlife's updated module taken from btlife's email to me.

1. Reduced Complexity in the code
2. Removed Custom Fields as it's no longer needed
3. Removed internal SalesForce API and made it dependant on Salesforce
Suite (Salesforce API) module. This allows for AES encryption support
for Credentials, and provides an already configured upgrade path if
Drupal to Salesforce two-way sync is needed in the future. This module
only does one-way submissions from a Webform to Salesforce, only the ID
of the record submitted is returned from Salesforce and it isn't stored
in Drupal. The only thing stored in Drupal is the data that was
submitted to Salesforce in the form of a normal Webform Submission.
4. Removed Webform PHP requirement
5. Converted "Special Type" objects (i.e. multiple inserts from one
webform, or specialized standard object like Person Account) to their
own modules. They can be enabled or disable as necessary.
6. Created hooks to allow developers to add their own "Special Types"
7. Added auto creation, and maintaining of know required fields.
8. Added optional auto creation of know optional fields
9. Added Event, Contact + Event, and Lead + Event types

It's early in the morning now in chicago about 12:35 am .. so my post's are not as coherent. Having said that here's my helpful suggestions/response and what I am prepared to put in coding time to improve.

1. Reduced Complexity in the code
** Most definitely! Although I think we need to put in our own hook_menu page handler for config settings. Pretty much like a report of hey I know ... salesforce suite api is asking for a lot of stuff.. well the module actually does not require all those stuff salesforce suite api is asking we only need the following stuff:

like on admin/settings/salesforcewebform
a.) salesforce user ** Maybe some helpful link here if variable_get('salesforce_api_username',false) yields false **
b.) salesforce password
c.) salesforce token
d.) salesforce toolkit

then like an all systems go ... if they are all complete.

2. Removed Custom Fields as it's no longer needed
** nice one!
3. Removed internal SalesForce API and made it dependant on Salesforce
Suite (Salesforce API) module.
** hehe nothing like api functions to lessen our workloads!
4. Removed Webform PHP requirement
** I think I can improve upon this by taking advantage of webform hooks now available. patch will be coming.
5. Converted "Special Type" objects (i.e. multiple inserts from one
webform, or specialized standard object like Person Account) to their
own modules. They can be enabled or disable as necessary.
** No comment because I have not encountered a use case for this one, but overall all -- a wow.
6. Created hooks to allow developers to add their own "Special Types"
** needs cleaning up. will put in patch
7. Added auto creation, and maintaining of know required fields.
** WOW!
8. Added optional auto creation of know optional fields
** WOW! Time saver!
9. Added Event, Contact + Event, and Lead + Event types
** No comment because I have not encountered a use case for this one, but overall to those folks that might use this feature they might say wow.

Good points, I am going with a tacit acceptance of making use of salesforce_api . Also please see comment #8 bullet point 1. I think with that we can have a visual guide to our user's of the specific requirements of this module.

I am going to work on this module now. Coding.

Branch now active here in this project.

To module developers:

Things unsaid in the salesforce_api module is that its using the sForceClientEnterprises.php its different from the previous SforcePartnerClient.php .. watchout the class definition is different. In fact in the upsert function sForceClientEnterprises has a default type of Contact instead of Lead.

I personally used it for about 5 production sites already. No complaints yet from my clients. Is there an upgrade path from 1.x to 3.x not really :( pretty much un-install and install.

1. Well you need to a properly installed salesforce module. see their docs.
2. See docs (README.txt and INSTALL.txt) of v3 of this module (should be updated)

Heads up on this one, there is a design differences between how the salesforce module views things and how salesforcewebform views things. What I mean by that is after you have properly install and set the config settings ie. set the salesforce api username, token, password. You still need to go to each individual webform node and set "Submit to Salesforce", after which you have to go to each individual webform component and mapped it to your existing salesforce fields @ salesforce. Pretty much we took advantage of existing webform "edit component" functionality (for example /node/1/webform/components/1 ) and added a select drop down box there. So in the salesforce module admin gui side -- after setting salesforce api username, token, password your done there.

3. re-creating a v1 configuration in v3 , Well all is pretty much the same except that the salesforce api username token and password is done @ the salesforce module admin settings. Well not really the same, v3 has more cooler features like implementing salesforce assignment rule :)

Hope this helps. I am eager for feedback.

Hey Evan,

It's nice to hear from a friendly colleague, how are you buddy? (we should talk at skype my id is chriscalip) .. Last time we talk was at Drupal Con Chicago @ that deli (dinner) with my co-worker Dave. Well anyways about : When will the 3.x branch be recommended, do you think, or at least mentioned on the project page? -- Really I was just collecting glitch reports from the user base that are using 3.x; i figured i give it a few weeks then once i get the free time hammer it out then fix those glitches and do a release candidate. Well weeks turn into a few months now.. its been crazy busy for me.. now i am currently doing my first d7 site with a twist of (multidomain) Domain Access, (faceted-search) Apache Solr, and (multilingual) i18n package. Yikes talk about baptism by fire.

I think i collected enough bug reports and gave it enough time in the contrib space; i'll put in the time to make a stable release. I don't have access to the project page though..

And about: Are there any features that you provide which Salesforce Webform Integration lacks -- Yup pretty much on the user experience the configuration settings is taking advantage of first the salesforce api for the salesforce credentials; but more importantly the mapping of each webform component is done at the existing webform component fields form page. Make's it more easy to use because users familiar to webform expects mapping done there.. while the other module does it on a separate admin page???. Also correct me if I am wrong... but this one is doing the actual passing of data to salesforce after the webform submit, while the other module does it by batch (cron)?? I've also used my experience with the webform api to make sure of a more stable integration with webform see Webform 3.x Compliance http://drupal.org/node/1146084 Also btlife architectured the 3.x module to have module hooks for other modules... easier to extend.

We really should deprecate one in favor of the other at some point, to reduce confusion, but I'm not sure yet what is the best way forward. -- I am also pressed for time and cannot maintain 3.x branch by myself.. but i kinda like the work done by btlife and myself in 3.x branch it just works but we (btlife,obsidiandesign,myself) are busy.. . I am up for finding a better way and what's best for our community using drupal and salesforce.

Hey Evan about my offer to tag team with you on salesforce webform; are you still up for it? I tend to be busy at times but there are times that i can allocate a lot of effort and time for salesforce webform. Of course right now I am spread thin but in a few weeks I should be up and running again. Wanna collaborate?