how to avoid hardcoding environment urls for salesforce api for our call ins

Question

Currently we have a couple of webservices which we have built in salesforce which would be called by an external application. The external application uses soap protocol and uses the integration profile user information to login to salesforce and make the webservice calls. The java application consumes the wsdl using the java client and uses the below information to make the calls. E.g sfdcURL = "https://cs16.salesforce.com/services/Soap/u/27.0/"; sfdcUserName = "[email protected]"; sfdcPassword = "xxxx"; cbmsEndPoint ="https://cs16.salesforce.com/services/Soap/class/xxxxService";

The problem is that every time we refresh our sandboxes, the instances of salesforce change like cs16 to cs17 etc and our network team has to open the firewall to allow the new end point so that the java application can connect to salesforce. How can we avoid this and use any generic dns name in salesforce which we can provide to our network people so that it can be used for all sandbox and production instances? How are you guys managing this in your callins to salesforce from different sandboxes? Buyan

Answer 1

You should always be logging in to https://test.salesforce.com/ for sandboxes, and https://login.salesforce.com/ for production instances. Your firewall should likewise be configured to allow connections to https://*.salesforce.com/. This is to allow load balancing, future expansions, etc. Edit: The login response includes a serverUrl that should be used for all future requests. Your client should be resetting the endpoint after logging in.

Edit 2, Code Sample

I wrote up an example login script using Visual Studio 2008. It took me some time to find a syntax that worked, because C# created bindings that were not like the examples on the developer site Quick Start.

Here's my basic example (no error checking):

        // Create a client
        SforceService.SoapClient client = new ForceTools.SforceService.SoapClient();
        // Attempt to login. You should catch faults/exceptions.
        // The two nulls are headers I'm not using.
        SforceService.LoginResult lr = client.login(null, null, username, password);
        // Create a session header for future calls.
        SforceService.SessionHeader sh = new ForceTools.SforceService.SessionHeader();
        // Assign a session ID.
        sh.sessionId = lr.sessionId;
        // We need to reset the Endpoint. For some reason, C# wouldn't let me actually
        // set a new client.Endpoint.Address value, so I just trashed the original
        // client and created a new one with the reset URL.
        client = new ForceTools.SforceService.SoapClient("Soap", lr.serverUrl);
        // Now I can do things like query. Those nulls are various headers I could set.
        SforceService.QueryResult qr = client.query(sh, null, null, null, null, "SELECT Id FROM Account");

This successfully returned records from my demo org. This binding was the partner.wsdl; I assume the Enterprise WSDL is easier to work with. If you find a better way get this to work (e.g. actually be able to set the Endpoint without re-initializing the entire client), I'd be glad to see it.