The WSDL<\/strong> (Web Service Description Language<\/a>) is a language used to contain the information necessary to interact with a given Web Service (WS). It is a XML-based standard that is widely used to create WS clients in different programming languages. In Salesforce, it is useful to create a client that will be able to make calls to the standard SOAP API<\/strong><\/a>.<\/p>\r\n\r\n\r\n\r\n As explained before, the WSDLs are files that are useful to create a client of the Salesforce SOAP API. It is generated by an org and consumed by a client to generate a code that serves as a proxy between the client app and Salesforce. There are different types of WSDL that Salesforce offers : the Partner<\/strong> and Enterprise<\/strong> WSDL are used to retrieve and edit Salesforce data like Account via the SOAP API. While the Metadata<\/strong> and Tooling<\/strong> WSDL are used to call respectively the Metadata<\/a> and Tooling<\/a> APIs useful to deploy metadata or develop Salesforce IDE apps.<\/p>\r\n\r\n\r\n\r\n In this article : <\/strong><\/p>\r\n The WSDL files are accessible in any Salesforce org, in the setup under Integration<\/strong> -> API<\/strong>. Here can be found different links<\/a> corresponding to the different WSDL files available, including the Partner and Enterprise.<\/p>\r\n\r\n\r\n\r\n It is to be noted that WSDL can also be used in the other way to create Apex class as client of external Web Services<\/strong>. This is done in the setup under Custom code -> Apex classes by clicking the \u201cGenerate from WSDL\u201d button, as explained here<\/a> and using the WSDL provided by the external service.<\/p>\r\n This will create a proxy code in Apex that can be used to make external calls to the WS.<\/p>\r\n\r\n\r\n\r\n Before going in the details of the WSDL and how to use them, let\u2019s first set up the client project that will make the API calls.<\/p>\r\n Here we\u2019ll create a Java project using the Eclipse IDE, but any other IDE and language works as well.<\/p>\r\n\r\n\r\n\r\n The WSDL (Partner or Enterprise, in the next examples we use the Partner) that can be generated in the org as explained above, and the WSC (Web Service Connector<\/strong>). It can be found here<\/a> as explained in the Salesforce documentation<\/a> or in the Git repository<\/a>.<\/p>\r\n This file is important when converting the WSDL into Java classes. It contains valuable code as well to connect to your org (among other things as well).<\/p>\r\n Then, we compile the stub code <\/strong>using both WSDL and WSC files with the command provided in the documentation<\/a> (this example uses the Partner WSDL but the same procedure applies with the Enterprise one) :<\/p>\r\n\r\n\r\n\r\n This generates a file (in our example After we have generated and linked the Salesforce libraries to our project, we can analyze further the purpose of each one.<\/p>\r\n There is the The other library is partner.jar that contains the classes to interact with the SOAP API.<\/p>\r\n So the main package ( And the Finally the last package ( Now, before making any attempt to call the SOAP API …<\/p>\r\n where Here we are, we\u2019ve generated the proxy code necessary to our project, now let\u2019s see in a bit more details what these WSDL are.<\/p>\r\n\r\n\r\n\r\n If we recall the documentation, this file is loosely typed<\/strong> and static<\/strong>. The static part means the file does not change when there is a change in the org customization<\/strong>, hence it can be used to interact with any configuration of org. This means that an application using the Partner WSDL will not need to generate its proxy code every time there is a change in the org, it thus requires less maintenance. About the \u201cloosely typed\u201d part of the description, we\u2019ll see in details what it means in this section.<\/p>\r\n\r\n\r\n\r\n As an XML file, it is composed of a hierarchy of tags nested one into the other. Each of these tags will be interpreted by the compiler and translated into something in the proxy code, either a class or a method, for instance.<\/p>\r\n The first section is a This tag includes a sequence section that contains a list of So from what we observe in the file we expect that the proxy code created using this file is going to include a class named Indeed this is what we find in the This is what is meant by \u201cloosely typed\u201d in the WSDL definition : there is not a specific class for each SObject but rather a generic class that will have to be attributed a type.<\/strong><\/p>\r\n\r\n\r\n\r\n As we can see, the first step after creating the SObject is to set its type, then we can set any field using the syntax : We then put this variable into a list and use the There is also the possibility to use The response of the request is stored in the Hence, because of its loosely typed property, the Partner WSDL is used for application that retrieve information about an object<\/strong> (with methods<\/a> like Now we have seen what are the distinctive features of the Partner WSDL. We can guess what the Enterprise WSDL definition means : strongly typed and tied to a specific Salesforce configuration<\/strong>.<\/p>\r\n Strongly typed, as opposed to loosely typed, means that the This also implies that the Enterprise WSDL is generally a much bigger file than the Partner (24000 lines against 7900 in our example), as it must contain the information about the metadata present in the org.<\/p>\r\n\r\n\r\n\r\n In this case, we have classes that represent each object in your org including the custom objects. This means that the type of each object we would use is more strongly defined in the proxy code, which is what is meant by \u201cstrongly typed\u201d.<\/p>\r\n\r\n\r\n\r\n The enterprise WSDL thus allows you to manipulate directly your objects, with the associated fields. On the other hands you need to re-generate the WSDL and consume it again every time you make a change in an object which is not the case with the partner WSDL.<\/p>\r\n Unlike with the Partner WSDL, this time we don\u2019t have to set the object type<\/strong> as it is a different class we manipulate. There are specific methods associated to each field <\/strong>(that contain the API name of the field) to either get or set it.<\/p>\r\n The same methods as with the Partner WSDL ( It is to be noted that, as another difference with the Partner WSDL, the connection uses an Also the endpoint url is of the form<\/a> The fact that a lot of elements of configuration are present in the Enterprise WSDL means that one would need to generate and compile it again to take into account any new piece of customization<\/strong> in the client app. But this also makes the client code more readable as well. So it can be suited for some applications where there is a unique link between an org and a client app.<\/p>\r\n\r\n\r\n\r\n In summary, the Partner WSDL is more likely to be used in applications that would dynamically inspect object properties before using it.<\/strong><\/p>\r\n For instance when an application works across several orgs<\/strong>. Because it is loosely typed, it requires to set the type of each object in use, but it does not need to be re-generated every time there is a modification in the org (only once for each release). This makes it a strong candidate to be used in flexible applications that could make calls to several Salesforce organizations.<\/p>\r\n\r\n\r\n\r\n On the other hand, the Enterprise WSDL is strongly typed which means it is bound to a specific org. Any modification in the customization needs a new consumption<\/strong> to be taken into account. This doesn\u2019t require to inspect the metadata before using it but prevents from working across multiple orgs. The fact that each object has a designated class also makes the code more readable.<\/p>\r\n\r\n\r\n\r\n In conclusion, there is a tradeoff between maintainability, readability and flexibility<\/strong> that should be considered when choosing between Partner and Enterprise WSDL. That also depends on the specific context of each usage of the SOAP API.<\/p>\r\n In any case, the possibilities offered by the SOAP API are the same regardless of the type of WSDL that is used. Furthermore, we saw that it allows a great variety of operations to be performed on the Salesforce data.<\/p>\r\n\r\n\r\n\r\n Introduction The SOAP protocol is one of the many possibilities offered by Salesforce to interact with its database using standard or custom APIs. Using it in a client application can prove difficult if one has no deep knowledge about how the protocol works and how to build the requests. That\u2019s why Salesforce provides us with […]<\/p>\n","protected":false},"author":14,"featured_media":5311,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[150],"tags":[307],"class_list":["post-187","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-conseils","tag-development-en"],"acf":[],"yoast_head":"\nWhat are the WSDL files\u00a0?<\/h2>\r\n\r\n\r\n\r\n
\r\n
Client project\u00a0setup<\/strong><\/h2>\r\n\r\n\r\n\r\n
We need two files<\/strong> :<\/h4>\r\n
java -classpath pathToJar\\force-wsc-XX.X.X-uber.jar com.sforce.ws.tools.wsdlc pathToWSDL\\wsdlFilename .\\wsdlGenFiles.jar<\/code><\/pre>\r\n\r\n\r\n\r\nwsdlGenFiles.jar<\/code>) that is a library containing the proxy code that allows the interaction with Salesforce. All we need to do then is to reference<\/strong> both the WSDL and WSC libraries in the project (for instance, a Build path<\/a> in Eclipse) and import<\/strong> them before any class with :<\/p>\r\n\r\n\r\n\r\nimport<\/strong> com.sforce.ws.*;
import<\/strong> com.sforce.soap.partner.*;
import<\/strong> com.sforce.soap.partner.sobject.*;<\/code><\/pre>\r\n\r\n\r\n\r\nforce-wsc-49.3.0-uber.jar<\/code> library that contains, among other things, the classes necessary to initiate a connection to an org.<\/p>\r\ncom.sforce.soap.partner<\/code>) contains the classes and methods to send instructions to an org.<\/p>\r\ncom.sforce.soap.partner.fault<\/code> package contains various classes including the ones necessary for error handling.<\/p>\r\ncom.sforce.soap.partner.sobject<\/code>) is where the main difference between Partner and Enterprise WSDL lies, and it will be detailed in a later section.<\/p>\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/texei.com\/dev\/wp-content\/uploads\/2021\/08\/1_K8fCkse8KHoBm_xD8sen8w.png\")
\r\nWe need to create a connection<\/strong> to the org<\/a>, which needs a proper authentication. This is done using the following bit of code :<\/h4>\r\n\r\n\r\n\r\n
ConnectorConfig config = new<\/strong> ConnectorConfig();
config.setUsername(username);
config.setPassword(password);
config.setAuthEndpoint(authEndPoint);<\/code><\/pre>\r\n\r\n\r\n\r\nPartnerConnection connection = Connector.newConnection<\/em>(config);<\/code><\/pre>\r\n\r\n\r\n\r\nusername<\/code>, password<\/code> and authEndPoint<\/code> are String variables defined in the code. The username and password are the user credentials <\/strong>(for the password, we need to append the security token<\/a> after the user password as well). The authEndPoint string is a url on the form: https:\/\/[org<\/a> name].my.salesforce.com\/services\/Soap\/u\/[version number]\/<\/code>. We thereafter use this connection<\/code> object to initiate any call we make to Salesforce.<\/p>\r\n\r\n\r\n\r\nThe Partner\u00a0WSDL<\/strong><\/h2>\r\n\r\n\r\n\r\n
Let\u2019s start with the Partner<\/strong> WSDL :<\/h4>\r\n
Let\u2019s look a bit closely to the structure of the file itself\u00a0:<\/h4>\r\n
Here is what we get when we look more closely at the first part in our Partner WSDL :<\/h4>\r\n\r\n\r\n\r\n
<schema elementFormDefault=\u201dqualified\u201d xmlns=\u201dhttp:\/\/www.w3.org\/2001\/XMLSchema\" targetNamespace=\u201durn:sobject.partner.soap.sforce.com\u201d>\r\n\r\n <import namespace=\u201durn:partner.soap.sforce.com\u201d\/>\r\n\b\r\n <! \u2014 Dynamic sObject ->\r\n <complexType name=\u201dsObject\u201d>\r\n <sequence>\r\n <element name=\u201dtype\u201d type=\u201dxsd:string\u201d\/>\r\n <element name=\u201dfieldsToNull\u201d type=\u201dxsd:string\u201d nillable=\u201dtrue\u201d minOccurs=\u201d0\" maxOccurs=\u201dunbounded\u201d\/>\r\n <element name=\u201dId\u201d type=\u201dtns:ID\u201d nillable=\u201dtrue\u201d \/>\r\n <any namespace=\u201d##targetNamespace\u201d minOccurs=\u201d0\" maxOccurs=\u201dunbounded\u201d processContents=\u201dlax\u201d\/>\r\n <\/sequence>\r\n <\/complexType>\r\n<\/schema><\/code><\/pre>\r\n\r\n\r\n\r\nschema<\/code> tag, that will be interpreted as a Java package when the WSDL is consumed. This contains an import<\/code> tag, followed by a complexType<\/code> that represents a class.<\/p>\r\nelement<\/code> tags, each representing a method or an attribute of this object.<\/p>\r\nSObject<\/code> that contains several attributes such as Type<\/code> or Id<\/code> and the associated setter and getter methods.<\/p>\r\ncom.sforce.soap.partner.sobject<\/code> package. We also see that the class extends another class, XmlObject<\/code>, that is defined in the WSC file that we used above to compile the libraries. This SObject<\/code> class can represent any Salesforce object<\/strong> (such as Account or Case, for instance). That is the class we are going to use when calling the API.<\/p>\r\nHere is a sample code to create an Account as an example(similar to the documentation example<\/a>) :<\/h4>\r\n\r\n\r\n\r\n
SObject account = new<\/strong> SObject();\r\naccount.setType(\"Account\");\r\naccount.setField(\"Name\", \"Test\");\r\n\r\nSObject[] accounts = new SObject[1];\r\naccounts[0] = account;\r\n\r\nSaveResult[] results = connection.create(accounts);<\/code><\/pre>\r\n\r\n\r\n\r\nvariable.setField(\u201cfieldName\u201d, \u201cvalue\u201d);<\/code>.<\/p>\r\ncreate()<\/code> method of the connection object we created earlier to insert this list.<\/p>\r\nupdate()<\/code> or upsert()<\/code> methods, and there is a wide variety of <\/strong>methods<\/strong><\/a> that are available such as convertLead()<\/code> or findDuplicates()<\/code>.<\/p>\r\n\r\n\r\n\r\nresult<\/code> variable that we can use to check the success of the record creation and more details like the record Id (in case of a success) or an error message (in case of failure).<\/p>\r\n\r\n\r\n\r\ndescribeSObject()<\/code>, for instance) before interacting with this object. In that case, the type of the object being handled is one of several parameters.<\/p>\r\n\r\n\r\n\r\nThe Enterprise WSDL<\/h2>\r\n\r\n\r\n\r\n
SObject<\/code> class will be replaced by more specific classes (even though the SObject<\/code> class still exists). It results from this that it will be bound to a single Salesforce configuration (indeed, if a new object is added to and org, it automatically makes any previous Enterprise WSDL obsolete).<\/p>\r\nThe structure of the file is similar to the Partner WSDL, except it contains not only a definition of the SObject but a large number of other objects such as the Account, as shown below (abridged version) :<\/h4>\r\n\r\n\r\n\r\n
<complexType name=\"Account\">\r\n <complexContent>\r\n <extension base=\"ens:sObject\">\r\n <sequence>\r\n <element name=\"AccountCleanInfos\" nillable=\"true\" minOccurs=\"0\" type=\"tns:QueryResult\"\/>\r\n <element name=\"AccountContactRoles\" nillable=\"true\" minOccurs=\"0\" type=\"tns:QueryResult\"\/>\r\n <element name=\"AccountNumber\" nillable=\"true\" minOccurs=\"0\" type=\"xsd:string\"\/>\r\n <element name=\"AccountPartnersFrom\" nillable=\"true\" minOccurs=\"0\" type=\"tns:QueryResult\"\/> ...\r\n\r\n <element name=\"Type\" nillable=\"true\" minOccurs=\"0\" type=\"xsd:string\"\/>\r\n <element name=\"UserRecordAccess\" nillable=\"true\" minOccurs=\"0\" type=\"ens:UserRecordAccess\"\/>\r\n <element name=\"Users\" nillable=\"true\" minOccurs=\"0\" type=\"tns:QueryResult\"\/>\r\n <element name=\"Website\" nillable=\"true\" minOccurs=\"0\" type=\"xsd:string\"\/>\r\n <element name=\"YearStarted\" nillable=\"true\" minOccurs=\"0\" type=\"xsd:string\"\/>\r\n <\/sequence>\r\n <\/extension>\r\n <\/complexContent>\r\n<\/complexType><\/code><\/pre>\r\n\r\n\r\n\r\nHere is a sample code to create an Account as in the previous example, this time using the Enterprise WSDL :<\/h4>\r\n\r\n\r\n\r\n
Account a = new<\/strong> Account();\r\na.setName(\"AccountTest\");\r\n\r\nAccount[] accounts = new Account[1];\r\naccounts[0] = a;\r\n\r\nSaveResult[] results = connection.create(accounts);<\/code><\/pre>\r\n\r\n\r\n\r\nupdate()<\/code>, convertLead()<\/code>, etc\u2026) are available as well.<\/p>\r\n\r\n\r\n\r\nEnterpriseConnection<\/code> instead of the PartnerConnection<\/code> to connect with the org.<\/p>\r\nhttps:\/\/[org<\/a> name].my.salesforce.com\/services\/Soap\/c\/[version number]\/<\/code> (note the c<\/code> instead of the u<\/code>).<\/p>\r\n\r\n\r\n\r\nSummary<\/strong><\/h2>\r\n\r\n\r\n\r\n
References<\/strong><\/h2>\r\n\r\n\r\n\r\n
\r\n