We have a platform which is programmed in Java. The problem is, every time the WSDL changes(happens more often), the platform crashes. Is there a way to communicate to Salesforce without the WSDL? Or some way to auto generate a WSDL every time a change is made?
2 Answers
It sounds like you are using the Enterprise WSDL. This is a strongly typed WSDL that is bound to the Salesforce configuration/schema at the time it was generated.
On the plus side, it gives you easy access to the objects and corresponding fields that were present at the time it was generated.
On the minus side, as you have found, if there is any change in the Salesforce metadata that is exposed via the WSDL then your integration will break.
Now you could automate downloading the WSDL the integrating with that, but it would be much easier to use the Partner API which is designed to be flexiable and adapt to schema changes.
The Partner API is loosely typed. Rather than giving you all the sObjects and the corresponding fields. You get methods like describeSObjects()
that tell you which sObjects you can currently access and what fields they expose.
On the plus side, your code can adapt to changes in the configuration. If a new field is added in Salesforce that you don't care about you don't need to do anything (as long as it isn't required). If a new field hasn't been deployed from the Sandbox to production yet the code can test to see if it is present yet. This makes coordinating deployments significantly easier.
Also, you won't need to upgrade the Partner API unless you want something from the latest seasonal release.
On the down side, you will need to do more work from the code to handle the dynamic nature of the connection. You will also need to do more work to extract basic field data from the sObject.
See also: Salesforce provides two WSDL files, what are the differences?
If you really don't want to use a WSDL, there is always the REST API.
The problems aren't caused by the WSDL per say, but rather it's the underlying changes to the system that are changing the WSDL and also breaking your connection. If you find the connection is breaking a lot, the problem is probably that there are too many dependencies.
I'd say the best advice is to keep the integrations between the systems as simple as possible so that changes can be made in salesforce that are irrelevant to the other system without causing problems there.
For example, if you are making a query, don't query all of the fields on the object, just query the fields that you actually need. That way when a field that you don't need is removed, there won't be a problem, but when a field that you do need is removed, you will get errors, as you should.
Otherwise, you could implement a policy against deleting and renaming fields in Salesforce except at set times and regenerate a wsdl right afterwards.
A third option might be to programmatically retrieve the wsdl periodically. If you want to investigate that option, there was someone who was doing that here: Obtain enterprise WSDL via curl
-
But the thing is, that we are not querying everything. We had for example a field on the Opportunity which I deleted, which is used no where on the Java Platform. The application still crashed because the WSDL wasn't the same anymore. Aug 10, 2016 at 11:55
-
From my experience, in this type of situation, the debug logs will usually show that a query was being made with those missing fields. Even if you haven't explicitly written such a query, there could something running that generates that query dynamically based on the WSDL. Best case scenario, you can change it and make it stop doing that.– martinAug 10, 2016 at 11:58
-
Otherwise, I'd say you could have a policy against deleting and renaming fields in Salesforce except at set times and regenerate a wsdl right afterwards.– martinAug 10, 2016 at 12:02
-
Also, if you wanted to try something that used a programmatic approach to getting the wsdl, there was someone who was doing that here: Obtain enterprise WSDL via curl– martinAug 10, 2016 at 12:04
-
ah okay I get your first point. It makes sense to make a policy like that, although it would be nice of course to keep the objects neat. I guess the last one is something which we could implement, I am going to look deeper into that. Could you include that in your answer? Aug 10, 2016 at 12:33