function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
ConorConor 

Value of Partner WSDL when relying on schemas

Hi, 

 

as opposed to writing java code, I'm using a java-based tool (Oracle BPEL)  for calling the Web Services API. My use-case is simply to bi-directionally synchronize cloud-based Contact data with an in-house Contact Master.

 

For calls inbound to force.com, I have been advised by our force.com consulting partner to use the Partner WSDL (to insulate the middleware from configuration changes in the cloud). I have proof-of-concepted both WSDLs, and they both work fine. However, the partner API seems to me to have little value for my particular use case, as:

 

1) The tool I am using finds it much easier to transform messages when it has source and target XSDs/schemas. However, the Contact object's complex type is only in the Enterprise WSDL schema, and not in the Partner WSDL schema. Although I can use the Enterprise WSDL complex type to build the message and then copy the nodes to the appropriate Partner WSDL node, I don't see the value in that ... why not just use the Enterprise WSDL ?

 

2) Also, this is an in-house development for a single organization. I'm not trying to develop a multi-organizaiton product.

 

3) Finally, it seems to me that if contract-impacting configuration changes to custom fields are made in the Cloud (i.e. such as field renames or field deletes) that strong typing is an advantage - as it's better to fail than have things continue to operate in a possibly unintended fashion. So long as non-mandatory custom field additions in the cloud don't force me to rebuild my integrations, I'm happy, and I believe the Enterprise WSDL will not need to be rebuilt in this case.

 

For the reasons above,  I prefer the advice from salesforce.com at http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_partner.htm

which encourages me to use the Enterprise WSDL for my fairly simple use case. However, as I'm new to force.com, I'm hoping for some validation from some of the experts out there.

 

Thanks, Conor.

 

 

Best Answer chosen by Admin (Salesforce Developers) 
mpiercempierce
If you're only integrating with one organization, the partner api offers little benefit. I agree that since you're tightly coupled to a particular schema you probably want to have compilation failures rather than runtime failures if required fields change. I see two minor benefits to using the partner api. One is that when changes need to be made you don't have to re-download the wsdl and regenerate classes. The other is that the loosely typed api is easier to wrap and modify in case you need things like thread safety, etc. since there are fewer methods to expose. I don't think that either of these outweighs the benefits of using the enterprise api in your case, though.

All Answers

mpiercempierce
If you're only integrating with one organization, the partner api offers little benefit. I agree that since you're tightly coupled to a particular schema you probably want to have compilation failures rather than runtime failures if required fields change. I see two minor benefits to using the partner api. One is that when changes need to be made you don't have to re-download the wsdl and regenerate classes. The other is that the loosely typed api is easier to wrap and modify in case you need things like thread safety, etc. since there are fewer methods to expose. I don't think that either of these outweighs the benefits of using the enterprise api in your case, though.
This was selected as the best answer
SuperfellSuperfell

For single org use, it really comes down to the tools/environment you're using, some of them feel more natural with the enterprise WSDL, some feel more natural with the partner WSDL, go with whatever seems like a better fit for you.
ConorConor

Hi mpierse, Simon, thanks for the useful insights.

 

mpierce: "...when changes need to be made you don't have to re-download the wsdl and regenerate classes."
As my transformation tool uses a copy of the the Contact xsd/schema (only held in the Enterprise WSDL) to prepare the object before calling the Partner WSDL operation, I would have to do this anyway."


mpierce: "...the loosely typed api is easier to wrap and modify in case you need things like thread safety"
The tool I am using does it's own thread management, and will assure thread safety.
As regards wrapping for reusable marshalling, etc.., the tool can leverage the sObject type extensibility (to Contact, Account, etc...)  in the Enterprise WSDL schema


Simon: "...go with whatever seems like a better fit for you"
Right now, that's Enterprise WSDL for my (single org, Oracle BPEL) use case.


Thx, Conor.