Tag Archives: Force.com

External ID in Salesforce

An External Id is a custom field that has enable the “External ID” attribute. This field is usually references an ID from another (external) system. When a field is marked as external Id, the field will be automatically indexed.

Note: External Id is not case-sensitive – for example, “XYZ” will be matched with “xyz”. if the custom field has enable the “Unique” attribute and the case-sensitive option for that attribute is selected, uppercase and lowercase letters will not be considered identical.


  • External Id is an attribute that can be added to a custom field to indicate that it should be indexed and treated as an Id.
  • It is a user-defined cross-referenced field.
  • It can be created for custom field type (Text, Number or Email ONLY).
  • Each object can have up to 7 external Ids (as of Spring ’15).
  • Configure UPSERT action to traverse object relationships defined in Salesforce, but use External Id’s from legacy system to discover Salesforce record ID’s.


  • It helps improve Report and API SOQL performance.
  • It can be used with UPSERT DML operation to seamlessly integrate apps with other systems.
  • No need to know Salesforce record Id’s to load data.
  • Very convenient for data integrations and migrations.
  • The import wizard will detect existing records in Salesforce that have the same external ID.
  • It becomes searchable in the sidebar search.

Example: If you have an Oracle Financials system that they will be linking with Salesforce, it may be easier for them to be able to refer to the Oracle ID of account records from within Salesforce. So, You can create an external ID in Salesforce and you can load the Oracle ID into that field for each account. You can then refer to that ID field, rather than the Salesforce id.

Difference Between Enterprise WSDL and Partner WSDL

WSDL (Web Services Description Language) is an XML document that describes a web service. WSDL is derived from Microsoft’s Simple Object Access Protocol (SOAP) and IBM’s Network Accessible Service Specification Language (NASSL). WSDL replaces both NASSL and SOAP as the means of expressing business services in the UDDI registry. It is used in combination with SOAP and XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the functions listed in the WSDL.

Salesforce provides a WSDL (Web Service Description Language) files. They are called “Enterprise WSDL” and “Partner WSDL”. The WSDL is used by developers to aid in the creation of Salesforce integration pieces. A typical process involves using the Development Environment (eg, Eclipse for Java, or Visual Studio for .Net) to consume the WSDL, and generate classes which are then referenced in the integration.

Enterprise WSDL:

  • The Enterprise WSDL is strongly typed, which means that it contains objects and fields with specific data types, such as int and string.
  • The Enterprise WSDL document is for customers who want to build an integration with their Salesforce organization only.
  • Customers who use the enterprise WSDL document must download and re-consume it whenever their organization makes a change to its custom objects or fields or whenever they want to use a different version of the API.

Partner WSDL:

  • The Partner WSDL is loosely typed, which means that you work with name-value pairs of field names and values instead of specific data types.
  • This WSDL document is for customers, partners, and ISVs who want to build an integration that can work across multiple Salesforce organizations, regardless of their custom objects or fields.
  • The Partner WSDL is static, and hence does not change if modifications are made to an organization’s Salesforce configuration.

Read REST API GET Parameters in Apex Class

URL: /services/apexrest/AccountAPI?id=AccountId
Method: Get

@RestResource (urlMapping='/AccountAPI/*')
global with sharing class AccountRESTService {
    global static Account getAccount() {
        RestRequest req = RestContext.request;
        String accountId = req.params.get('id');
        Account acc = [SELECT Id, Name FROM Account WHERE Id =: accountId];
        return acc;

URL: /services/apexrest/AccountAPI/AccountId
Method: Get

@RestResource (urlMapping='/AccountAPI/*')
global with sharing class AccountRESTService {

    global static Account getAccount() {
        RestRequest req = RestContext.request;
        String accountId = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1);
        Account acc = [SELECT Id, Name FROM Account WHERE Id =: accountId];
        return acc;

Difference Between Inbound and Outbound Web Service in Salesforce

Inbound Web Service:
Inbound web service is when Salesforce exposes SOAP/REST web service, and any external/third party application consume it to get data from your Salesforce org. It is an Inbound call to Salesforce, but outbound call to the external system. Here, Salesforce is the publisher and external system is the consumer of web services.

Outbound Web Service:
Outbound web service is when Salesforce exposes SOAP/REST web service, and any external/third party application consume it to get data from your Salesforce org. It is an Inbound call to Salesforce, but outbound call to the external system. Here, external system is the publisher of web services and Salesforce is the consumer.

There are two commonly used web service:

    • SOAP(Simple Object Access Protocol)
      • SOAP is a web service architecture, which specifies the basic rules to be considered while designing web service platforms.
      • It works over with HTTP, HTTPS, SMTP, XMPP.
      • It works with WSDL.
      • It is based on standard XML format.
      • SOAP Supports data in the form of XML only
      • SOAP API preferred for services within the enterprise in any language that supports Web services.
    • REST (Representational State Transfer)
      • REST is another architectural pattern, an alternative to SOAP.
      • It works over with HTTP and HTTPS.
      • It works with GET, POST, PUT and DELETE verbs to perform CRUD operations.
      • It is based on URI.
      • REST Supports both XML and JSON format.
      • REST API preferred for services that are exposed as public APIs and mobile, since JSON being Lighter the app runs smoother and faster.

Queueable Apex in Salesforce

The class which implements the Queueable interface are basically called as Queueable apex class. This interface enables you to add jobs to the queue and monitor them, which is an enhanced way of running your asynchronous Apex code compared to using future methods. The interface has only one method execute which takes the parameter of QueableContext.

For Apex processes that run for a long time, such as extensive database operations or external Web service callouts, you can run them asynchronously by implementing the Queueable interface and adding a job to the Apex job queue. In this way, your asynchronous Apex job runs in the background in its own thread and doesn’t delay the execution of your main Apex logic. Each queued job runs when system resources become available. A benefit of using the Queueable interface methods is that some governor limits are higher than for synchronous Apex, such as heap size limits.

It allows you to submit jobs for asynchronous processing similar to future methods with with these additional benefits:
Non-primitive types: Your Queueable class can contain member variables of non-primitive data types, such as sObjects or custom Apex types. Those objects can be accessed when the job executes.
Monitoring: When you submit your job by invoking the System.enqueueJob method, the method returns the ID of the AsyncApexJob record. You can use this ID to identify your job and monitor its progress, either through the Salesforce user interface in the Apex Jobs page, or programmatically by querying your record from AsyncApexJob.
Chaining jobs: You can chain one job to another job by starting a second job from a running job. Chaining jobs is useful if you need to do some sequential processing.

This example is an implementation of the Queueable interface. The execute method in this example inserts a new account.

public class QueueableExample implements Queueable {

    public void execute(QueueableContext context) {
        Account acc = new Account(Name='Biswajeet');
        Insert acc;        

To add this class as a job on the queue, call this method:

ID jobID = System.enqueueJob(new AsyncExecutionExample());

After you submit your queueable class for execution, the job is added to the queue and will be processed when system resources become available. You can monitor the status of your job programmatically by querying AsyncApexJob or through the user interface Setup || Monitoring || Apex Jobs.

To query information about your submitted job, perform a SOQL query on AsyncApexJob by filtering on the job ID that the System.enqueueJob method returns.

AsyncApexJob jobInfo = [SELECT Status,NumberOfErrors FROM AsyncApexJob WHERE Id=:jobID];

Test class for Queueable Jobs:

public class AsyncExecutionExampleTest {
    static testmethod void test1() {
        //startTest/stopTest block to force async processes to run in the test.
        System.enqueueJob(new AsyncExecutionExample());

        Account acct = [SELECT Name FROM Account WHERE Name='Biswajeet' LIMIT 1];
        System.assertNotEquals(null, acct);
        System.assertEquals('Biswajeet', acct.Name);


  • The execution of a queued job counts once against the shared limit for asynchronous Apex method executions.
  • You can add up to 50 jobs to the queue with System.enqueueJob in a single transaction.
  • Limits.getQueueableJobs() helps to check how many queueable jobs have been added in one transaction.
  • No limit is enforced on the depth of chained jobs, which means that you can chain one job to another job and repeat this.
  • You can add only one job from an executing job with System.enqueueJob, means that only child job can exist for parent queueable job.
  • For Developer Edition and Trial organizations, the maximum stack depth for chained jobs is 5.