1

I am writing a small program in .net (C#) which is connecting with Salesforce. I downloaded wsdl file from both production and sandbox environment.

What is the correct way of using the service reference for Debug and Release configurations? Should I import both references and use the corresponding one depending on selected configuration?

#if DEBUG
using WebApi.Salesforce_DEV;
#else
using WebApi.SalesForce_PRO;
#endif

Or is the preferred way just to change the endpoint url for each configuration?

Thank you

Improve this question
2
  • Are you using the Enterprise or Partner API? If the Partner API then you can use it for both production and the sandbox as it will adapt. You only need to change the endpoint.
    – Daniel Ballinger
    Commented Mar 8, 2019 at 21:22
  • I am using Enterprise API. I am wondering why would production and test wsdl files differ? The things I test should also be the same on production environment, except the endpoint. Otherwise there is not much sense in testing.
    – gtu
    Commented Mar 10, 2019 at 0:01

1 Answer 1

Reset to default
0

The Enterprise WSDL is strongly typed and specific to the org it was generated from. If there is the slightest difference in the Metadata between the production and the sandbox org they will get differing WSDLs (beyond the SOAP endpoint).

Unless both your production and sandbox orgs have metadata that is permanently fixed I'd probably recommend going with the Partner API, which is loosely typed. It is more effort up front without the strong typing, but it gives you the flexibility to handle metadata/schema changes.

Lets go through an example of adding a new custom field that is on an sObject that you work with via the API.

With the Enterprise API, once you make the change in the sandbox to add the new field you will need to update your code to the new sandbox WSDL. Make any required changes for the new field, rebuild the code, and deploy the updates so it can work with that Sandbox. However, that new fields Metadata hasn't been deployed to the production org yet. You won't be able to deploy that branch of the code base until production gets updated to match the sandbox. Better still, when production is updated you will need to do a coordinated push of the C# code at the same time.

Compare that to the Partner API. When the need field is added to the sandbox you don't necessarily need to do anything to the C# code. There is no need to update the WSDL as it can already show you the new field details via the describe metadata calls. When you are ready, you can code and deploy the changes to work with the new field in the sandbox. Better yet, you can deploy that code all the way to production before the new field even exists there. You use the describe calls to detect the presence of the field and adapt accordingly.

The flexibility that the Partner API gives you requires more effort, but I believe it is worth it for any real world scenario where you are going to need to support changes to the org over time.

Improve this answer
1
  • 1
    The strongly typed nature of Enterprise WSDL was the reason why I tried SOAP API. I will rather switch back to REST API and write the minimalist classes myself.
    – gtu
    Commented Mar 11, 2019 at 7:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .