I don't recommend people not review for their maintenance exams. It will not serves you well in the long run. However, I understand that sometimes we don't have enough time to read thru the release notes or even watch release videos (which sometimes lacks information) at the same time pay for the maintenance fee. So proceed if you are really out of options.
Identity and Access Managment - Spring 18 Release
1) An administrator resets a user password in Salesforce. Which attribute will be updated with the "True" value in the Identity URL or UserInfo endpoint?
(A) password_reset
(B) active
(C) password_updated
(D) email_verified
ANSWER: D.
NOTE: See https://help.salesforce.com/articleView?id=remoteaccess_using_userinfo_endpoint.htm&type=5
2) Universal Containers uses Customer Community for its customers and wants to make sure that there is an extra layer of security to avoid unauthorized access. What is the recommended way of enabling two-factor authentication for external users?
(A) Use an AppExchange application to implement two-factor authentication for external users
(B) Use dynamic login on the customer community to allow customers to verify their identity
(C) Use custom login flows to implement two-factor authentication for external users
(D) Update external user profile to allow users to verify their identity and avoid unauthorized access
ANSWER: D.
NOTE: Initially I thought this is "C" because that was the old way of doing it but a new feature as part of Spring 18 was introduced. See https://releasenotes.docs.salesforce.com/en-us/spring18/release-notes/rn_security_auth_communities_verification.htm
3) Universal Containers uses Customer Community to allow its customer to register and perform self-service functions. Due to the growth of the business and customer base, UC wants to deliver a different experience to its customers based on run-time circumstances. What is the secure and recommended way of enabling this?
(A) Use custom login flows to deliver different experiences by extracting the source from the URL where the customer is visiting form
(B) Use an AppExchange product to customize the Customer Community login experience and deliver a personalized experience to customers
(C) Enable dynamic login experience by adding expid request parameter in the client configuration SSO initialization URL
(D) Develop Lightning components to deliver different experience to customers using their information stored in Salesforce
ANSWER: C
NOTE: Keyword "run-time circumstances". See https://releasenotes.docs.salesforce.com/en-us/spring18/release-notes/rn_security_identity_dynamic_auth_providers.htm
4) Universal Containers uses an external website to allow its customer to perform self-service functions. The website doesn't support authentication through SAML or OpenID Connect. UC has decided to implement Salesforce and authenticate its user via Salesforce.
What is the recommended solution to allow users to authenticate via Salesforce on the external website?
(A) Configure Salesforce as a Service Provider, and implement custom federation services using existing Identity store
(B) Migrate the website to Customer Community to allow a seamless experience and set existing passwords as their customer community user passwords
(C) Configure Customer Community Identity providers, and use Embedded Login to allow customers to authenticate on the website using configured identity providers
(D) Configure a connected app in Salesforce and use username-password flow to allow customer to authenticate on the website
ANSWER: C
NOTE: Keyword is "doesn't support SAML or OpenID Connect". See https://developer.salesforce.com/docs/atlas.en-us.212.0.externalidentityImplGuide.meta/identityImplGuide/external_identity_login_intro.htm
5) Universal Containers uses Salesforce for all of its internal users. Recently, Universal Containers started getting a lot of complaints from users regarding locked user accounts due to users not being able to reset their passwords.
(A) Enable two-factor authentication using lightning login to allow users to log in without their passwords
(B) Modify password policies and set Password Expires to "Never Expires" so that users can log in without any interruption
(C) Implement a third-party Identity Provider to centralize user management and authentication policies
(D) Configure social media authentication provider to allow users to log in via their social media credentials
ANSWER: A
My Cloud Experience
This blog contains design implementations, sample solutions and opinions on implementing Salesforce.com customisations including configuration, development, integration and overall solution architecture.
02 August 2018
20 February 2017
Salesforce and SoapUI TLS 1.1 or higher
Salesforce is disabling TLS 1.0 and all new Sanboxes created after June 26, 2016 will require TLS 1.1 and above to communicate. More info here.
If you been using SoapUI on Windows to do some testing on the API, you will need to set the TLS version of it. To do this do the following:
If you been using SoapUI on Windows to do some testing on the API, you will need to set the TLS version of it. To do this do the following:
- Locate the 'vmoptions' file of SoapUI. This is normally located on the installation directory under the bin folder (e.g. C:\Program Files (x86)\SmartBear\Soap-5.3.0\bin\)
- Open the file using your favorite editor
- Add "-Dsoapui.https.protocols=SSLv3,TLSv1.1" at the end of the file ans save (without the double quotes)
- Open SoapUI
07 December 2016
Installing Force.com Migration Toolkit on Mac
In this blogpost, I will provide the steps on how I installed the Force.com Migration Toolkit on my MacBook with MacOS Sierra 10.12.1.
INSTALL ANT ON YOUR MAC
Step 1: If you Mac is not pre-installed with ANT you will need to download it. Go to the Apache website and download the latest tar.gz version as depicted below:
Step 2: Once downloaded, extract the files by double-clicking the downloaded archived file and saving the extracted folder into a path of your choosing. I added it on my user path ~/Users/<user_name>/apache-ant-1.9.7
Step 3: Add the ANT path to the environment variable so that it can be called from any location in terminal. To do this we need to edit .bash_profile and export the ANT path. First, execute the command below and save the path it will give:
echo $PATH
Then open .bash_profile using the nano terminal text editor by executing the following command:
nano .bash_profile
Create the ANT_HOME variable and append it to the path retrieved earlier using colon:
export ANT_HOME=<location_of_the_extracted_ant_files>
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$ANT_HOME/bin
The editor should look like below:
Verify that you can call ant by executing ant -v
INSTALL FORCE.COM MIGRATION TOOLKIT
Step 1: Download the toolkit from the salesforce developer website
Step 2: Once downloaded, extract files by double-clicking it
Step 3: Copy ant-salesforce.jar on your ANT lib folder
Labels:
Force.com ANT,
Mac
02 December 2016
Community Cloud Certification Tips
I decided to take to community cloud certification before the end of this year because I think there are a lot of opportunities in the market right now that requires specialisation on implementing communities. Having been involved in the old customer/partner portal implementations as well as a community implementation 2 years ago when it was still in beta, I felt that this is the best time to take it since the functionality is growing every release.
Anyway, this post is about what I think you should be aware of and take time to review when you take the exam and so that you can pass it.
- Understand data access using sharing set, sharing group, OWD
- Opening data access using super user access (for partner and customer community plus licenses)
- What objects each community license types provides access
- Difference between Private and Unlisted groups for community collaboration
- Live agent setup with Communities
- Setting up multi-language with Communities
- Providing public access to Communities
- Benefits of using custom domains for Communities
- Community limits (# of keyword in a list, # of moderation rule etc)
- Other specific things such as:
- What are the available lightning components in Home page
- Managing recommendations
- Setting up Community Logo on login page
- What are the scenario the welcome email will get sent
- Which template is Salesforce1 ready
- What type of changes can be done on the community page header
Most of the questions are scenario-based that will ask which implementation options are efficient (yes, multiple answers). There are tricky questions that will really test your Salesforce knowledge not just for Community functionalities.
For some reason, I thought that this certification is the easiest compared to Sales and Service Cloud. I didn't get any question related to community integration like question and answer and escalate-to-case, community rollout process and measuring community success thru reports and dashboard.
Labels:
Certification,
Community Cloud,
Configuration,
Salesforce,
Tips
04 July 2015
Outbound Message Retry Mechanism
Workflow outbound messaging is great. It provide a simple and declarative way of integrating your Salesforce environment to another system via SOAP protocol by allowing administrators to select fields to send to a certain endpoint. So take for example for Account object, I can send the record Id, Account Name and Description easily by creating a workflow outbound message and associate it with a workflow rule. I can also include a user for which the message will be send on behalf and optionally include the session id so that if the endpoint needs to update back a value to the system, it can use it back without having to authenticate.
Below is a sample workflow rule, outbound message configuration and XML SOAP message:
Sample Workflow Rule
Sample Workflow Outbound Message
Sample SOAP Message
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <notifications xmlns="http://soap.sforce.com/2005/09/outbound"> <OrganizationId>ORG_ID</OrganizationId> <ActionId>OBM_ID</ActionId> <SessionId>ENCRYPTED_SESSION_ID</SessionId> <EnterpriseUrl>SOAP_ENTERPRISE_URL_FOR_YOUR_ORG</EnterpriseUrl> <PartnerUrl>SOAP_PARTNER_URL_FOR_YOUR_ORG</PartnerUrl> <Notification> <Id>04l9000001F11SQAAZ</Id> <sObject xsi:type="sf:Account" xmlns:sf="urn:sobject.enterprise.soap.sforce.com"> <sf:Id>0019000000g0uFmAAI</sf:Id> <sf:Description>Edge, founded in 1998, is a start-up based in Austin, TX. The company designs and manufactures a device to convert music from one digital format to another. Edge sells its product through retailers and its own website.</sf:Description> <sf:Name>Edge Communications</sf:Name> </sObject> </Notification> </notifications> </soapenv:Body> </soapenv:Envelope>
Note: I use requestbin to get the XML payload that Salesforce sends based on the the configuration.
Annoying Limitation
Unfortunately while its easy to create and configure outbound message, It's also worth mentioning that this great feature has a limit. If it cannot reach the endpoint, it will only retry sending the message within 24 hours in an exponential interval up to 2 hours maximum between retries (see help documentation).
Now many can argue that the endpoint, either an integration tool or an on premise system like .Net or Java should always be up. That's an ideal scenario but may not always be true. I have worked in an ecosystem before for which the integration tool handles all of the integration for the whole company's systems and because they are in a tight budget, cannot increase the server to handle the load during peak hours and sometimes the system goes down for more than 24 hours (true story). In short, we cannot always rely on the standard retry mechanism.
Solution/Workaround
There are two things we can do to mitigate this limit. Option one is to use the Outbound Messaging Dead Letter Queue feature which was introduce last Summer '08. What this feature does is it provides a list of failed outbound message queue and then allows administrator to request that these messages be retried for another 24 hours, and assign up to five email recipients to receive a notification once every 24 hours if one or more outbound messages are in the failed outbound message queue.
When enabled, a new checkbox named 'Add failures to failed outbound message related list' on the outbound message configuration will be added.
A new 'Failed outbound messages' related list on the Outbound Message monitoring page will be added (Setup -> Monitor -> Outbound Messages).
The limitation of using this is you can only automate resending by using browser action recorder such as Selenium or iMacros as you would need to click each link on the new outbound message related list.
Use Apex Scheduler
Option number two is to use Apex scheduler to execute a logic that will update the records and execute a work rule that then fires the outbound message. However, to do this there would be a couple of changes in SFDC and your middleware.
First create a sync status in the object with three statuses which we will use later. Status values would be Sent, Success and Error. The idea is that when the workflow rule that sends the Outbound Message executes, we want the Sync Status of the record to set to 'Sent'.
On the middleware, they need to update back the record status with either 'Success' or 'Error' depending if the operation succeed or not on the other system. The idea is the record will be tagged with a success or error status and will be stuck in sent when Salesforce cannot reach the middleware.
Sample Apex Schedule Class
global class ApexRetrySchedule implements Schedulable {
global void execute(SchedulableContext SC) {
try{
List<Account> accountList = [SELECT Id FROM Account WHERE
Sync_Status__c = 'Sent' LIMIT 200];
update accountList;
}catch(Exception e){
}
}
}
You will noticed I only used the scheduleable class. The reason for this is because I don't want to use the batchable interface because it will restrict the context of records the job will process. Using the scheduleable class I can query any objects and update then from the execution, keeping in mind the DML rows governor limits.
In addition, while time-based workflow can be used to update the record when the sync status is still in 'Sent', I won't recommend it as there is a limit on a number of it that an organization can be executed on a rolling 24 hours (see blogpost regarding limits dashboard).
You can schedule the batch job via the Scheduler page or via code depending on the time interval you need it.
18 April 2015
Rollout your own limit dashboard
Spring 15 release brings some goodies as usual. One particular feature I liked is the REST API Limit Resource feature which will be in GA and will be available 24 hours after the scheduled release. I particularly like this feature, which I even sign up for a developer a preview a couple of months back, is because I'm annoyed with the system lack of dashboard page that allows me to track whether I'm almost hitting organisation limits. Simple requirement such knowing how many mail SingleEmail have been sent out requires you to contact Salesforce contact centre. Now it might be a product strategy from the San Francisco company as some of these limits (soft limits) can be increase by buying it in addition to the editions hard limits, or maybe just really not in the roadmap yet. We don't really know for sure but its good that developers and in some ways, administrators now has a way to check these limits without calling support.
Here are the limit information the the feature currently returns:
- Daily API calls
- Daily Batch Apex and future method executions
- Daily Bulk API calls
- Daily Streaming API events
- Streaming API concurrent clients
- Daily generic streaming events (if generic streaming is enabled for your organization)
- Daily number of mass emails that are sent to external email addresses by using Apex or Force.com APIs
- Daily number of single emails that are sent to external email addresses by using Apex or Force.com APIs
- Concurrent REST API requests for results of asynchronous report runs
- Concurrent synchronous report runs via REST API
- Hourly asynchronous report runs via REST API
- Hourly synchronous report runs via REST API
- Hourly dashboard refreshes via REST API
- Hourly REST API requests for dashboard results
- Hourly dashboard status requests via REST API
- Daily workflow emails
- Hourly workflow time triggers
How to normally check the limit usage
Before we delve into how we can expose the limit information, lets take a look first on how we can normally access it. I will use workbench here for the purpose of simplification but feel free to use any tool of your liking.
Basically, we just need to go to the REST Explorer section of Workbench. Then you type in then limit resource url /services/data/<version>/limits/, then choose the GET option and then click Execute button.
Note that this is only available for REST API version 29 and to users with "View Setup and Configuration" permission. The DataStorageMB and FileStorageMB limits will only show for users with if "Managed Users" permission.
Rolling out your custom limit dashboard
Administrators wouldn't want to always execute a REST call just to see the limit usage for the environment. What is needed is a dashboard the shows the current usage versus the hard limit. Below is a simple Visual force page executing a JavaScript to retrieve the same limit information.
I will not explain the code in detail but as a high level, we did an HTTP get using JavaScript XMLHttpRequest object to the REST url /services/data/<version>/limits/, passing our session Id to authenticate and then iterating over the list of information returned by the call.
The sample screenshot is below:
We can include a lot of of other improvements to the page like changing the look and feel so that it would look better and to retry retrieving the information on a timed interval. I hope this post have help anyone.
Happy coding!
<apex:page> <script type="text/javascript"> var xmlhttp = new XMLHttpRequest(); var url = "/services/data/v32.0/limits/"; xmlhttp.onreadystatechange=function() { if (xmlhttp.readyState == 4 && xmlhttp.status == 200) { myFunction(xmlhttp.responseText); } } xmlhttp.open("GET", url, true); xmlhttp.setRequestHeader("Authorization", "Bearer {!$Api.Session_ID}"); xmlhttp.send(); function myFunction(response) { var res = JSON.parse(response); var d = document.getElementById('result'); // iterate to the object keys // and display the property values Object.keys(res).forEach( function(key,index) { //key = the name of the object key //index = the ordinal position of the key within the object d.innerHTML += "<strong>" + key + "</strong><br/>" + "Max: " + res[key].Max + "<br/>" + "Remaining: " + res[key].Remaining + "<br/><br/>"; }); } </script> <div id="result"> </div> </apex:page>
I will not explain the code in detail but as a high level, we did an HTTP get using JavaScript XMLHttpRequest object to the REST url /services/data/<version>/limits/, passing our session Id to authenticate and then iterating over the list of information returned by the call.
The sample screenshot is below:
We can include a lot of of other improvements to the page like changing the look and feel so that it would look better and to retry retrieving the information on a timed interval. I hope this post have help anyone.
Happy coding!
Labels:
Dashboard,
Governor Limits,
JavaScript,
REST,
Salesforce,
Spring 15,
Visualforce
12 April 2015
Using SoapUI to do SOAP calls to Salesforce
I've been involved on integration with Salesforce.com from and to other systems. One of the oldest protocol used on integrating with the system is using the SOAP protocol as it has a SOAP API that allows other systems to manipulate records.
Personally, its worth while to have knowledge on how to consume the Salesforce SOAP method specially if you are working with an integrator who does not have prior experience integrating to Salesforce using the protocol.
In the below examples I will be using SoapUI, an open source testing tool that supports not just SOAP but also other protocols such as REST and HTTP. I'll also be using the Salesforce partner wsdl but will provide alternative examples using the enterprise wsdl. For more information on the difference of the two, please take time to read this article.
The first thing to do is to download the Salesforce WSDL from Setup --> Develop --> API.
Once the WSDL is generated and download, we need to create a new SOAP project in SoapUI as depicted below.
Clicking the "Ok" will create the project as well as list the SOAP methods and samples (if "Create Request" checkbox is selected). Below is the generated project tree.
So let's starting creating our sample SOAP calls.
Partner login call
There are different ways of authenticating with Salesforce but for our example, we will use the login method that require to pass the user name and password to get a Session ID which is an encrypted value Salesforce pass back which is needed for succeeding calls.
Go to the login method from the SoapUI project tree and use or create a new request. Delete all of the values under <soapenv:Header> as we don't need to pass any value on the SOAP envelop. We will refer to this as the soap envelop header moving forward.
The request should be as follow (click here for the enterprise wsdl sample):
The request should be as follow (click here for the enterprise wsdl sample):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:partner.soap.sforce.com"> <soapenv:Header> </soapenv:Header> <soapenv:Body> <urn:login> <urn:username>Salesforce User Name</urn:username> <urn:password>Password + security token</urn:password> </urn:login> </soapenv:Body> </soapenv:Envelope>
From the request window, click the submit icon to process the request. SoapUI will then attempt to do a SOAP call to Salesforce and returns a response below.
Note that I have removed a couple of information from the response. However, the most important thing to note from the response is the Session ID and the ServerURL which we will used in our succeeding examples.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <loginResponse> <result> <metadataServerUrl> https://na5.salesforce.com/services/Soap/m/30.0/00D700000008fqn </metadataServerUrl> <passwordExpired>false</passwordExpired> <sandbox>false</sandbox> <serverUrl> https://na5.salesforce.com/services/Soap/u/30.0/00D700000008fqn </serverUrl> <sessionId>Session ID</sessionId> <userId>005700000012RyAAAU</userId> <userInfo> <accessibilityMode>false</accessibilityMode> <currencySymbol>$</currencySymbol> <orgAttachmentFileSizeLimit>5242880</orgAttachmentFileSizeLimit> <orgDefaultCurrencyIsoCode>USD</orgDefaultCurrencyIsoCode> <orgDisallowHtmlAttachments>false</orgDisallowHtmlAttachments> <orgHasPersonAccounts>true</orgHasPersonAccounts> <organizationId>00D700000008fqnEAA</organizationId> <organizationMultiCurrency>false</organizationMultiCurrency> <organizationName>REMOVED</organizationName> <profileId>00e70000000sEkZAAU</profileId> <roleId>00E70000000olJBEAY</roleId> <sessionSecondsValid>7200</sessionSecondsValid> <userDefaultCurrencyIsoCode xsi:nil="true"/> <userEmail>REMOVED</userEmail> <userFullName>REMOVED</userFullName> <userId>005700000012RyAAAU</userId> <userLanguage>en_US</userLanguage> <userLocale>en_US</userLocale> <userName>REMOVED</userName> <userTimeZone>America/Los_Angeles</userTimeZone> <userType>Standard</userType> <userUiSkin>Theme3</userUiSkin> </userInfo> </result> </loginResponse> </soapenv:Body> </soapenv:Envelope>
Note that I have removed a couple of information from the response. However, the most important thing to note from the response is the Session ID and the ServerURL which we will used in our succeeding examples.
Partner create call
Now that we have a Session ID and Server URL, we need to create a new request using the create method. Go to the create method from our project tree and use or create a new request. Delete all of the values soap envelop header except for <urn:SessionHeader> where we will need to add the Session ID value from the login call.
The request should be as follow (click here to see create call using enterprise wsdl):
Note that we have manually typed the type node (represents the SObject type) and Name (which is the API name of the standard Name field) above for the request.
Before submitting the request, we also need to change the submit endpoint using the Server URL login response.
Below is the response from the create call.
Note that the <createResponse> node will have the result of the call. The <id> will contain the record Id for the record you are creating and the <success> will tell whether the call is successful or not.
The SoapUI should look like below:
Partner update call
Using the same Session ID, Server URL and the record Id from the create call, use or create a new update request from the SoapUI project tree and delete all the values from the soap envelop header except for the SessionHeader. The request should look as below (click here to see update call using enterprise WSDL):
The response is below:
The SoapUI should look like below:
Partner upsert call
The upsert call is not much different with the update call except that there is an <externalIDFieldName> node that is required to have the API name of the field marked as external Id or the Id field. The field must be part of the request.
Below is the sample request using the same Session ID , Server URL and record Id which was used as the external id fr(click here to see update call using enterprise wsdl):
Now that we have a Session ID and Server URL, we need to create a new request using the create method. Go to the create method from our project tree and use or create a new request. Delete all of the values soap envelop header except for <urn:SessionHeader> where we will need to add the Session ID value from the login call.
The request should be as follow (click here to see create call using enterprise wsdl):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:partner.soap.sforce.com" xmlns:urn1="urn:sobject.partner.soap.sforce.com"> <soapenv:Header> <urn:SessionHeader> <urn:sessionId>Session ID from Login Call</urn:sessionId> </urn:SessionHeader> </soapenv:Header> <soapenv:Body> <urn:create > <urn:sObjects> <urn1:type>Account</urn1:type> <Name>Sample Account (Partner)</Name> </urn:sObjects> </urn:create> </soapenv:Body> </soapenv:Envelope>
Note that we have manually typed the type node (represents the SObject type) and Name (which is the API name of the standard Name field) above for the request.
Before submitting the request, we also need to change the submit endpoint using the Server URL login response.
Below is the response from the create call.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com"> <soapenv:Header> <LimitInfoHeader> <limitInfo> <current>2</current> <limit>15000</limit> <type>API REQUESTS</type> </limitInfo> </LimitInfoHeader> </soapenv:Header> <soapenv:Body> <createResponse> <result> <id>0017000001ExlcFAAR</id> <success>true</success> </result> </createResponse> </soapenv:Body> </soapenv:Envelope>
Note that the <createResponse> node will have the result of the call. The <id> will contain the record Id for the record you are creating and the <success> will tell whether the call is successful or not.
The SoapUI should look like below:
Partner update call
Using the same Session ID, Server URL and the record Id from the create call, use or create a new update request from the SoapUI project tree and delete all the values from the soap envelop header except for the SessionHeader. The request should look as below (click here to see update call using enterprise WSDL):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:partner.soap.sforce.com" xmlns:urn1="urn:sobject.partner.soap.sforce.com"> <soapenv:Header> <urn:SessionHeader> <urn:sessionId>Session ID from Login Call</urn:sessionId> </urn:SessionHeader> </soapenv:Header> <soapenv:Body> <urn:update> <!--Zero or more repetitions:--> <urn:sObjects> <urn1:type>Account</urn1:type> <Name>Sample Account (Partner) Updated</Name> <urn1:Id>0017000001ExlcFAAR</urn1:Id> </urn:sObjects> </urn:update> </soapenv:Body> </soapenv:Envelope>
The response is below:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com"> <soapenv:Header> <LimitInfoHeader> <limitInfo> <current>3</current> <limit>15000</limit> <type>API REQUESTS</type> </limitInfo> </LimitInfoHeader> </soapenv:Header> <soapenv:Body> <updateResponse> <result> <id>0017000001ExlcFAAR</id> <success>true</success> </result> </updateResponse> </soapenv:Body> </soapenv:Envelope>
The SoapUI should look like below:
The upsert call is not much different with the update call except that there is an <externalIDFieldName> node that is required to have the API name of the field marked as external Id or the Id field. The field must be part of the request.
Below is the sample request using the same Session ID , Server URL and record Id which was used as the external id fr(click here to see update call using enterprise wsdl):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:partner.soap.sforce.com" xmlns:urn1="urn:sobject.partner.soap.sforce.com"> <soapenv:Header> <urn:SessionHeader> <urn:sessionId>0Session ID from Login Call</urn:sessionId> </urn:SessionHeader> </soapenv:Header> <soapenv:Body> <urn:upsert> <urn:externalIDFieldName>Id</urn:externalIDFieldName> <!--Zero or more repetitions:--> <urn:sObjects> <urn1:type>Account</urn1:type> <!--Zero or more repetitions:--> <Name>Sample Account (Partner) Upserted</Name> <Id>0017000001ExlcFAAR</Id> </urn:sObjects> </urn:upsert> </soapenv:Body> </soapenv:Envelope>
Below is the response.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com"> <soapenv:Header> <LimitInfoHeader> <limitInfo> <current>4</current> <limit>15000</limit> <type>API REQUESTS</type> </limitInfo> </LimitInfoHeader> </soapenv:Header> <soapenv:Body> <upsertResponse> <result> <created>false</created> <id>0017000001ExlcFAAR</id> <success>true</success> </result> </upsertResponse> </soapenv:Body> </soapenv:Envelope>
Here is the SoapUI screenshot:
Most of the other SOAP methods follow the same request sample. However there are other functionalities such as running assignment rules, changing the debug log levels that are controlled via the envelop header.
Hopefully the example above can help anyone starting to learn integrating to Salesforce.com. :-)
Labels:
API,
Enterprise WSDL,
Integration,
Partner WSDL,
Salesforce,
SOAP,
SoapUI,
Web Service
Subscribe to:
Posts (Atom)