Is there any reason behind Enterprise WSDL being recommended for Customers over partner WSDL? Is it that Enterprise WSDL is more secure than Partner WSDL?
Please throw some light on the security perspective of both the WSDL types?
Add a comment
|
4 Answers
Enterprise WSDL contains an org's customizations thus any client application integrating with your org must understand and conform to your org's customizations. For example, you want to build a Java-based application that aggregates sales data from your company's in-house eCommerce platform, and upload them to a set of custom objects that comprise your heavily customized Sales Cloud.
Partner WSDL is for building client applications that can work for any org so it is more "abstract". It does not immediately understand or know the customizations in the org you connect it to, but it gives you tools to understand them. Example apps: data loader, workbench, etc.
This Knowledge Article might help you for understanding Why Enterprise WSDl is recommended for customers
Personally, I've never used the Enterprise WSDL for anything other than quick one off integrations that aren't going to be around for very long.
Why?
While it's handy having the strongly typed Enterprise WSDL to generate all the corresponding types into your language of choice it can be a pain as time ticks on. The Enterprise WSDL:
... is tied (bound) to a specific configuration of Salesforce (ie. a specific organization's Salesforce configuration)
... changes if modifications (e.g custom fields or custom objects) are made to an organization's Salesforce configuration.
Source - Salesforce provides two WSDL files, what are the differences?
I've never worked with an org for any period of time that doesn't have configuration and metadata changes. An integration based on the Enterprise API could readily break as changes are made in Salesforce.
So while the Partner API is more work up front it gives much greater flexibility in being metadata driven. You can code around it to adapt to field changes using describeSObjects.
I.e. I'll typically be told of changes that are going to occur in production ahead of them being deployed. I can have code deployed to my integrations that will check the metadata exposed via the Partner API to activate as soon as those Salesforce changes are present.
Allowing for the same behavior with the Enterprise API would be more difficult.
answered May 2, 2017 at 20:18
The security will be the same.
The general rule of thumb is if you are writing code for a specific org, then the Enterprise WSDL will be easier to use. This is because code generation tools will be able to generate strongly typed objects for you to work with.
If you are writing code that will be used in multiple orgs, then the Partner WSDL offers greater flexibility. The downside here is that you will have to work with raw values that are sent in the XML <any> tag. This will require you to manually serialize/deserialize values in your code.
