Wrapper Class in Salesforce

Wrapper Class in Apex Salesforce

In simple words, a wrapper class is a class inside a class. It is also known as a container class. It stores a group of similar or different data type variables into a single object.

Lets understand with an example:

public class ExampleCls {

    public class WrapperCls{

        public Boolean selected { get; set;}

        public String record  { get; set;}

        

    }

}

In this example, ExampleCls is the main class and
WrapperCls is the wrapper or the inner class.

This wrapper class contains two different data types,
one Boolean and other one is String

Use of Wrapper Class:

1. It helps to stores a group of similar or different data type variables into a single object.
2. We can use a wrapper class in Lightning Component when we need to send group of data from apex to lightning components.
3. We can use Wrapper classes to parse the JSON request and response in REST API.

How to Check Custom Setting is List or Hierarchy in Apex

Today, we will learn how we can check whether the given custom setting is List of Hierarchy.

To Understand custom settings click here.

Apex Code:

String api = 'customSettingName__c';

Type reflector = Type.forName(api);

SObject sobj=(SObject)reflector.newInstance();

DescribeSObjectResult sobjResult = 

sobj.getSObjectType().getDescribe();

//some Name field info

SObjectField field = 

sobjResult.Fields.getMap().get('Name');

DescribeFieldResult fieldResult = 

field.getDescribe();

Integer length = fieldResult.getLength();

system.debug('length-'+length);

If length is 38 that means it is list, if length is 80 that means it is hierarchy

Please share your thoughts on this if there is any other way to do so.

What are Custom Settings in Salesforce

In Salesforce, custom settings are application metadata that offers a reusable set of static data that different departments in your company can access. 

Custom settings are classified into two types: 

• Hierarchy Custom Settings
• List Custom Settings 

The data in Hierarchy Custom Settings checks the organization, profile and user settings for the current user and makes the data visible for them accordingly. It uses a built-in hierarchical logic which lets you personalize settings for a specific user or a profile.

The data in List Custom Settings is directly visible to any user in the org. It provides a reusable set of static data which can be accessed across your organization.

Custom settings can be used to store a variety of data, such as configuration settings, feature switches, and business rules. They can be accessed using validation rules, workflows, Apex code, Lightning components, and the Salesforce API.

Advantages of Custom Settings

The main advantage of using Custom Settings is that the data is cached, which enables efficient access without the cost of repeated queries to the database. One doesn’t have to use SOQL queries which count against the governor limits.

How to Hide a Div Tag Like a Toast Message in Lightning Web Components

Lets understand how we can hide a div like a toast message.

HTML File:

<div data-id="overview" class="red-bg">

  <lightning-formatted-text value={errorMsg}>

</lightning-formatted-text>

</div>

In this HTML file, we are creating a div element and will set a data-id

Data-id value will be used in the JS file to show or hide the div.

Js File:

We can call this hidemsg() method from the success of a server call.

This above div tag will be hidden after 5 secs

hidemsg(){

 setTimeout(() => {

this.template.querySelector('[data-id="overview"]').style.display 

='none';

  }, "5000")

}

When this hidemsg() is called, we can add setTimeout()

method will put a delay.

Retry Mechanism Design in Salesforce

Lets understand a scenario to implement the Retry Mechanism in Salesforce.

Scenario:

There is a third party system which sends data to Salesforce and Salesforce processes that data and updates the objects. If there is a failure in update/insert then Salesforce system should retry to process them again. So, in such cases we can design the solution using the stage object.

Objects: 

Consider we want to do insert/update on Account based on the data received. For that, we can create a staging object lets say Accountstaging__c which will have fields similar to the Account object.

Design:

Using the standard APIs, third party system can send data to a staging table. There will no validation put in place when the data is being added to the staging object. This is done to assure that all the data reaches Salesforce system without any failure.

Salesforce then picks the data using a trigger or batch and performs the business logic and finally stores the data into Account Object.

Bulk Data Load to Salesforce:

This means when the other systems want to send data in bulk. In that case, we need to process all and update account object accordingly.

Lets say we are about to receive 10,000 records. We can discuss with the other system team and ask them to send a unique id for each bulk load and two extra records. One record will tell us that bulk data load has started to Salesforce and other record will tell that all the data has been sent. After this Salesforce can start its processing.

Record will come in this manner:

Begin of File(bof)-->Actual 10,000 records-->End of File(eof)

Here bof and eof are the checkboxes fields on the account stage object.

Data Processing:

We can have a trigger on stage object which will check whether the eof is true. If yes, then call the batch and query all the records using that unique id and process the data. At the end, we can mark the records in staging object as success or failed.

Retry Mechanism:

Consider some failures when doing the bulk updates in the system. We will have the list of failed records by querying all the failed records for that batch id.

These failed records can be retried using time based Process Builder to call the same batch class with a time gap or can call the batch class immediately by passing the list of records.

So based on the retry processing, we can update the stage records status as success or failure.

This mechanism can be done multiple times on the failed records if we add an integer field called retry counter on staging object. This field will be incremented by 1 whenever there is a failure. While doing the retry we can check whether the retry counter is less than 3, then only get the records. In this way the failed records can be retried multiple times.

If you have any thoughts on this, lets connect and discuss more this.