2

My application (utilizing SOAP and BULK APIs) uses Partner WSDL for different organizations. I have a concern that the version mismatch may pose an error in the application. For example, the Partner WSDL I use was generated from API v34. If the customer uses an older version, say V31, how do I manage this mismatch?

For this, I need to find the versions used by the salesforce instance. This can be performed using REST. How can the same be done using SOAP?

Once I have got the version, I can do for BULK by modifying the URL endpoint:

ConnectorConfig.setEndPoint(newUrl);

Again, can the same be modified using SOAP?

Alternate: I could have partner WSDLs for all the versions in my local disk. Once I know the version (through REST), I can load the corresponding wsdl for my application and recompile it. But this seems to be an overkill and there must be another way to do it.

2 Answers 2

2

Salesforce supports a number of versions all at once, so the only two important factors are (a) don't upgrade to the latest version (e.g. 35.0 for Winter 16) until all orgs have been upgraded, and (b) don't worry about upgrading to a later version as long as your version is still supported and has all the features you need.

As far as I can tell, there are many apps on the AppExchange that are still using version 25.0 or earlier. The apps work good with those versions, and they don't need to be updated until the version is dropped from support. A general guideline is to use whatever the current version is when starting a project, and not updating the version again until you need a new feature. This gives your apps a much longer shelf life, since older versions that are still supported are forward-compatible with later versions (they just don't get access to new fields, objects, etc from later versions).

As long as the org you're targeting has the same or greater version as the one from your WSDL, and that version is still supported, your app will run. Keep in mind that you simply won't have access to new features until you upgrade your WSDL to the minimum version that supports a given feature. In your example, you wondered about if a customer was still using 31.0. That's not the case, because everyone is upgraded automatically with new releases, so everyone's running at least version 34.0. To flip it around, next year around this time would be version 38.0 or so. This version will still support your version 34.0 WSDL, so there's no need to upgrade unless you need a new feature that comes out in the next year.

1
  • I just wanted to know how to move forward with using partner connection if the Salesforce version is ahead. For example, AccountFeed has ContentData field that is accessible to versions <=36.0. My application with partner v36.0 has to move forward to the latest version of Salesforce in the org v37.0 (to be consistent). Since salesforce is upgraded, will overriding the url parameters on partner connection be sufficient to carry on? There's no way right now to automate sf updates on api.
    – dmachop
    Jun 13, 2016 at 20:07
1

Generally speaking, you only need one version of the Partner WSDL at any one time. An org will be backwards compatible with any previous WSDL.

For example, right now all orgs are either on Summer '15 (v34.0) or Winter '16 (v35.0). As such, you can safely use v34.0 of the WSDL with any Org. There have been some recent bugs with the Partner API v34.0 in Winter '16 orgs, but those are exceptions to the rule and are being fixed by Salesforce in patches. If you tried to use v35.0 any org that was still on Summer '15 would reject the connection.

If you absolutely must have the latest version available, you would only need to support two WSDL versions at any one time.

You must log in to answer this question.

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