5

I've generated a C# file with classes wrapping the Salesforce Enterprise API by downloading the enterprise.wsdl file from my organization's Salesforce website to my PC, and running .Net's wsdl.exe utility on it.

My issue is that the generated SforceService.cs file has 262000+ (!!!) lines of code!

All I need to do is be able to execute a single, simple SELECT Name FROM Account WHERE [critera] SOQL query. Committing a 200k+ line source file to my project just for this seems like significant overkill.

My question is: What's the best way to go about reducing the SforceService.cs file to only what I need?

  • Should I manually remove some stuff from the enterprise.wsdl file before running wsdl.exe on it to generate the .cs file? If so, how can I determine what can be pared out? Is there documentation on this somewhere?
Improve this question
2
  • 2
    Use the partner WSDL for this. It will be loosely typed, but should be a lot smaller. You could also use an Apex Web Service to call a query and just get the data back as say, a JSON string, before converting it to a wrapper object.
    – battery.cord
    Oct 15, 2015 at 14:08
  • If you did want to go the "pared out" route, you should find that the vast majority of the generated classes are for the standard and custom objects in the org so delete all the entries except the Account one. That will leave you with a typed class for Account and a very much smaller file. (I've done this for the Metadata API and while it is a bit tedious it is not that hard to do.)
    – Keith C
    Oct 15, 2015 at 18:13

1 Answer 1

Reset to default
2

Salesforce provides two main WSDLs for accessing your orgs data via SOAP.

  1. Enterprise WSDL
    This is a strongly typed WSDL that is bound to the specific org it was generated from. It will have elements for every sObject and field that the generating user can access. Any changes to the schema in the org will require the WSDL to be generated again.
  2. Partner WSDL
    This is a loosely typed WSDL that can be used against any Salesforce Org. You can describe the meta data for sObjects and their fields and adapt as required. They only time you need to update it is if you want to access features from a new Salesforce release. Otherwise you can continue using it indefinitely.

So, the Partner API offers an immediate reduction to the WSDL size, especially if you are dealing with an org with a large number of sObjects and fields. It has other advantages to. If you add a new field to Salesforce, you can have the integrating code query the metadata to see if it is available yet. This makes staged deployments much easier.

If you still really want to use the Enterprise WSDL I have an idea that I haven't tried in practice yet. As the generated WSDL will only expose the objects that the current user has access to, you could try restricting the Salesforce user to just the Account object. Then generate the Enterprise WSDL as that user before restoring the security settings.

Improve this answer

You must log in to answer this question.

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