Modern Signal Blog

Viewing posts for topic: "ASP.Net". View all posts.

Connecting to Salesforce API from .Net

This is a bare-bones, step-by-step guide for setting up a .NET MVC site to connect to the Salesforce API. Just the facts.

Get the Enterprise WSDL and Security Token

Login to a salesforce.com sandbox to begin. To get to the sandboxes for a live instance of Salesforce, go to the upper right hand and click on your name. Select "Setup" in the menu. Once there you can go to the lower left and click data management, and you will see sandbox listed under there. There is a login button to log in to the sandbox from there.

To generate the WSDL go to Setup => Develop => API => Generate Enterprise WSDL

Click the Generate button and save the resulting file to your computer.

To generate a security token go to Setup => My Personal Information => Reset My Security Token

Click on Reset Security Token to get a security token sent to your email address. You will need that later.

Set up the service reference

Add a service reference in Visual Studio. For the address, enter the path to the WSDL file you downloaded. For the namespace enter SalesforceService, or whatever makes sense for your project.

Binding and endpoint configuration information will be automatically added to your Web.config file.

Add settings in Web.config for the salesforce login. E.g.

        <add key="SalesforceUsername" value="[email protected]" />
        <add key="SalesforcePassword" value="Qal3jR......" />

The password is a combination of the password used to login to the site and the security token you got earlier.

Use transformations in your Web.Release.config file to set the endpoint and login for the live server.

Working with Salesforce

A small utility file, such as this example, makes working with Salesforce pretty easy.

For example, to create a lead:

var sf = new SalesforceUtil();
sf.SaveLead(new Lead
{
    FirstName = "Joe",
    LastName = "Shmoe",
    Email = "[email protected]
});

Error Workaround

You may get the following error when your site tries to connect to Salesforce (I did both times I set this up):

Unable to generate a temporary class (result=1).
error CS0030: Cannot convert type 'MySite.SalesforceService.ListViewRecordColumn[]' to 'MySite.SalesforceService.ListViewRecordColumn'
...

The fix (which I found here: https://developer.salesforce.com/forums/?id=906F0000000Aj5kIAC) is pretty easy. In the auto-generated Reference.cs file for the service reference, search for this:

ListViewRecordColumn[][]

and replace it with this:

ListViewRecordColumn[]

More Documentation

SOAP API
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_quickstart_intro.htm

SOQL Queries
https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/

Comments (0)   Posted on February 25, 2016 10:03:40 AM EST by David Hammond

Avoiding Double Submit of Form in ASP.Net

I just implemented something that should have been simple, and actually is simple, but which ended up being a bit more of a struggle than it should have been.

We have a site where occasionally we were getting duplicate payment transactions when people submitted orders.  The transactions were all within a couple seconds of each other, so it appeared that people were just double-clicking the submit button (despite, of course, a message on the page saying to only click the button once).  We did, once upon a time, have javascript code in place that disabled the submit button when it was clicked once, but that code has been removed somewhere along the line.  I think it had been disabled due to the difficulty of dealing with client side validation -- i.e. if the client-side validation failed, the button should not be disabled, because then the user will not be able to submit the form.

I found a variety of posts online about dealing with this problem.  The basic solution is simple, which is to insert code into the form submit handler that runs the client-side validation and only disables the button if it passes.  First I set up this javascript function:

<script type="text/javascript">
    function handleSubmit() {
        if (typeof (ValidatorOnSubmit) == 'function' && ValidatorOnSubmit() == false) {
            return false;
        } else {
            $("form#aspnetForm input[type=submit]")
                .click(function() { return false })
                .fadeTo(200, 0.5);
            return true;
        }
    }
</script>

Then in the page's code behind, I registered the onsubmit function like so:

Page.ClientScript.RegisterOnSubmitStatement(Me.GetType, "OnSubmitScript", "return handleSubmit()")

The javascript function runs the same code that ASP.Net automatically runs for client-side validation, and, if the validation passes, uses jQuery to disable the submit button and fade its appearance.  The fading isn't necessary, but since it's so easy to do with jQuery, why not?

There is one thing in there though, that threw me for a loop.  Most of the posts I found online set the disabled parameter for the button, which you could do with jQuery like this:

$("form#aspnetForm input[type=submit]").attr("disabled", "disabled");

But when I did that I found that the submit action tied to the button no longer fired on the server side.  After puzzling over this for a while, I realized that when the button is disabled, the button value is no longer sent along with the form parameters, and thus the server-size click event for the button is not fired.  I wasn't able to find any references to this problem online (hence the impetus for this blog post).  So instead of using the disabled parameter, I set the click event of the button to return false, which seems to work well.

Something else that I like about this solution, is that it is very generic.  Since I use a generic selector to get the submit button ("form#aspnetForm input[type=submit]"), the javascript function could be included in a site-wide javascript library, and the onsubmit function could be registered in a master page to enable this functionality for all submit buttons on a site.  I'm not ready to do that on this site, since I just want to make sure the order checkout works well for now, but it's nice to know that if this comes up again, I can fix it in a flash.

Comments (6)   Posted on November 5, 2010 3:22:46 PM EDT by David Hammond