You do not need to generate the partner WSDL again as it will not have changed.
But if the customer has hard coded the set of field names in their logic your new field will not be handled. That may be OK.
If you need them to handle the new field in some specific way you will have to let them know so they can change their code. Or if the fields are handled ...
Where did you get your accessToken from? If you used OAuth to establish the session then you will need to have the web OAuth scope to use the sessionid for what is essentially a screen scraping web request. Having the api scope would be sufficient for the Partner API, but for for mocking UI requests.
Other than that, as you have found, you need to put the ...
The complexType VisualforcePage was added to the Winter '16 Partner API in v35.0. In v34.0 and earlier it didn't exist.
<element name="showLabel" type="xsd:...
A critical difference between the two is how change is handled i.e. what needs to be done when the org the WSDLs are generated from's structure changes - when new fields and objects being added. In most businesses such changes do happen.
With the Partner WSDL, the client code can automatically adapt with no need for the Partner WSDL to be generated again ...
Sounds like a bug, you are correct that old API versions shouldn't start returning enumeration values added in later API versions.
Response from support for case #12544039
R&D has set the bug corresponding to the issue - "New enumeration value of SearchLayoutFieldsDisplayed is returned in old api version, breaks old api clients" with the highest ...
There isn't a permission for that, but could be an api version. I ran into this in a similar project and they were somehow using the partner v2.5 endpoint which did not include an org id at that point. Using the correct endpoint addressed the issue.
The Lead FirstName field is not required. As such, it will return as null via the API if it is not defined.
You will need to check if it is null before attempting to convert it to a string.
It is likely that you are only getting a subset of records back for the SOQL query as the API user that ...
The trick here is in the warning message that is included in the sobjectPartnerSoapSforceCom class:
//Warning: '<xsd:any>' element type has been changed to dataType List<DOM.XmlNode> called anyElement
Natively WebServiceCallout.invoke can't handle the <xsd:any> that appears in the WSDL for sObjects. See Supported WSDL Features.
Salesforce may alter the QueryResult batch size based on the fields selected. For example, selecting an Attachment Body reduces the size to 1. Fields with the long text type will also reduce the batch size.
From Change the Batch Size in Queries (my emphasis):
The maximum batch size is 2,000 records. However this setting is only a suggestion. There is no ...
You can use the Metadata API (just import that WSDL separately), login with the Partner WSDL, assign the endpoint/session ID to the Metadata API binding, then call listMetadata from the Metadata API. The specifics will depend on your programming language.
PartnerConnection partnerApi = new PartnerConnection();
LoginResult loginResult = partnerApi.login(...
This is a really good explanation and you would've been able to find it if you simply typed "Salesforce differences between partner and enterprise WSDL" on google.
Enterprise WSDL - This WSDL document is for customers who want to
build an integration with their Salesforce organization only.It is
strongly typed, which means that it contains objects and ...
The metadata API isn't for retrieving records, it is for retrieving information about the structure of those records. E.g. what fields are on a custom object and what data type each field is.
The partner API isn't really intended for consumption from Apex. It includes a number of schema features that aren't supported by Wsdl2Apex.
One of these is the any ...
The Salesforce Metadata API is the only API that will do this for you. You can use the listMetadata operation to accomplish this, here is a previous question with answer detailing this, How to get a list of the managed packages (including version numbers) installed in an org?. If your interested in doing this from Apex, you can find a library that exposes ...
Partner WSDL is loosely coupled so you do not need to provide the WSDL again .
However the third party code would still use string identifier for the field names that needs to be updated .So you will pass the name of the field that's newly created and third party code would incorporate it .
Here is a simple Java code that shows how the update call will be ...
I made a alternative version of WSDL2Apex that can also generate the test classes for coverage and the Mock. You can get it via the FuseIT SFDC Explorer for free (Disclaimer: This is from my current employer)
See also Dreamforce 2014 Presentation - Improved Apex support for SOAP based web services
Short answer is Yes.
There is a caveat - you do not login to SFDC using Tooling Api or Metadata APIs directly.
You have to use Partner API to login and obtain "API endpoint" + "Session Id", and then use this information in subsequent Tooling Api or Metadata API calls.
After login with Partner API you will get session Id and API endpoint.
Session Id you use ...
It can be used for any org.
Using the Partner WSDL
As a loosely typed representation of the Salesforce data model that works with name-value pairs of field names and values instead of specific data types, it can be used to access data within any organization
Endpoint is returned as part of the login call.
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.
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) ...
Apparently, there is a bug on Salesforce API v45.0 which leaks the new type JSON designed for Salesforce API v46.0. This is observed on the APIEvent object on the RecordData field whose type is json. Here is a plug from the documentation:
A JSON string that represents the ...
You assign it to an sforce.SObject instead of a designated object class. Here's the example from the API documentation:
public void querySample()
QueryResult qr = null;
binding.QueryOptionsValue = new sforce.QueryOptions();
binding.QueryOptionsValue.batchSize = 250;
binding.QueryOptionsValue.batchSizeSpecified = true;
I have come up with a solution after examining the QueryResult of an Account query including owner fields. All you need to do is append the sObject's fields (including the external id) as child nodes under the related sObject field.
List<sObject> sObjects = new List<sObject> ();
XmlDocument xDoc = new XmlDocument ();
If you difference the two WSDL files, the only difference your should see (apart from a comment timestamp) is this location for the binding at the bottom:
I am not ...
You will need to set the endpoint for the client based on the LoginResult serverUrl.
The login call will go to login.salesforce.com. When it comes back the serverUrl will be something like https://na5.salesforce.com/services/Soap/u/34.0.
partnerSoapSforceCom.Soap partner = new partnerSoapSforceCom.Soap();
partnerSoapSforceCom.LoginResult lr = partner....
Salesforce supports a number of versions all at once, so the only two important factors are (a) don't upgrade to the latest version (e.g. 35.0 for Winter 16) until all orgs have been upgraded, and (b) don't worry about upgrading to a later version as long as your version is still supported and has all the features you need.
As far as I can tell, there are ...
RecordType is a reference field. If you wanted to set the record type by name, you'd use that. However, since you already have the recordTypeId, you need to use the RecordTypeId field.
We got the Reference ID from the dropdown list provided in the SFDC GUI, so we're fairly certain that we're correct here too. Are we missing something?
No, that's a ...
What you are currently doing is not secure, and in fact you have compromised any credentials shared this way. Passing the username and password to an external system is a bad practice, as is passing a session id. HTTPS does not make this safe. In the Appexchange security review, we no longer allow this form of authentication.
Never share credentials for ...
If your java application implements an oauth flow then it is definitely possible .
I would recommend you to explore oauth flow .For oauth you will create a connected app in your developer org .
Every time the user uses your java application they will go through the oauth flow and you will have user context .
Here is a simple servlet link to guide you
You are trying to generate partner.jar using WSDL file and you are using "force-wsc-36.1.1.jar" (File as Web Service Connector).
As of WSC-36 connector required an additional framework to generate "partner.jar" call "StringTemplate engine framework".
Download latest "StringTemplate binary" jar file using below link: String Template jar file
Put that ...