Tag Archives: Apex

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 consume any external/third party application web service, a call needs to send to the external system. It is an Inbound call to the external system, but outbound call to Salesforce. 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.

Example:
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:

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

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

Note:

  • 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.

Apex Trigger Context Variables

All triggers define implicit variables that allow developers to access runtime context.
These variables are contained in the System.Trigger class:

Variable Usage
isExecuting Returns true if the current context for the Apex
code is a trigger, not a Visualforce page,
a Web service, or an executeanonymous()
API
call.
isInsert Returns true if this trigger
was fired due to an insert operation, from the Salesforce user
interface, Apex,
or the API.
isUpdate Returns true if this trigger
was fired due to an update operation, from the Salesforce user
interface, Apex,
or the API.
isDelete Returns true if this trigger
was fired due to a delete operation, from the Salesforce user
interface, Apex,
or the API.
isBefore Returns true if this trigger
was fired before any record was saved.
isAfter Returns true if this trigger
was fired after all records were saved.
isUndelete Returns true if this trigger
was fired after a record is recovered from the Recycle Bin (that is, after an undelete operation from the Salesforce user
interface, Apex,
or the API.)
new Returns a list of the new versions of the sObject records. This
sObject list is only available in insert, update,
and undelete triggers, and the
records can only be modified in before triggers.
newMap A map of IDs to the new versions of the sObject records. This map
is only available in before
update
, after
insert
, after
update
, and after
undelete
triggers.
old Returns a list of the old versions of the sObject records. This
sObject list is only available in update and delete
triggers.
oldMap A map of IDs to the old versions of the sObject records. This map
is only available in update and
delete triggers.
size The total number of records in a trigger invocation, both old and
new.

Get Key Prefix of Salesforce Object

Let’s say we have a custom object “Customer__c”, and we want the Key Prefix of this object.

Using Apex:

String keyPrefix result = Customer__c.SObjectType.getDescribe().getKeyPrefix();
System.Debug('Key Prefix: ' + keyPrefix);

Using Workbench:
Login to Workbench || Info || Standard & Custom Objects || Select one object from the picklist || Expand Attributes

Big Objects in Saleforce

What is Big Object?

  • Big Object means 100s of billions of record on AppCloud.
  • It is a new capability with highly scalable object to store and manage large amount of data on the Salesforce platform.
  • This feature helps to engage directly with customers by preserving all your historical customer event data.
  • Big Objects are built by Salesforce to provide consistent performance whether there is 1 million records, 100 million, or even 10 billion records.

Use Cases:

  • Audit and Tracking: Track and maintain a long-term view of your user’s usage of Salesforce or your customer’s usage of your products for analysis or compliance purposes.
  • 360 view of Customers: Now data models can be extended to contain billing infos/ecommerce transactions/any other info related to customers.
  • Historical Data Archive: Maintain access to historical data for analysis or compliance purposes while optimizing the performance of your core CRM or Force.com applications.

Considerations:

  • It is provided as a pilot to selected premium customers.
  • The Big Objects cannot be created from the UI. We have to take help of the Metadata APIs to create one.
  • Big Objects don’t support triggers however they support object and field permissions.
  • BigObject don’t support standard UI elements (Home Pages, Detail Pages, List Views), But It can be used in Visualforce Page and Lightning components.
  • Data can be populated to the Big Objects via SFDC APIs/Bulk APIs/using Apex(insertImmediate() method).
  • The only SOQL relationship queries available are based on a lookup field from a BigObject to a standard or custom object.
  • Mostly Async SOQL would be used for the querying the Big Objects. Single level child-to-parent relationship queries and aggregate queries are supported.
  • Big Objects don’t support transactions.
  • We can create up to 100 Big Objects per org. The limits for BigObject fields are similar to the limits on custom objects, and depend on your org’s license type.
  • Big Objects don’t appear in the Setup UI until they are deployed.
  • Big Objects don’t appear in Salesforce1.