Tag Archives: Salesforce Challenges

Integration with Salesforce Lightning External Services

Nowadays there is an API Integration in almost every org. The main purpose of integration with another service is to avoid reinventing the wheel. However, the development effort that is required to integrate with services is a complex and time-consuming venture. It reduces speed to market, but it also saps developer energy that is better spent in the front end, building the features that will really differentiate their app. With Lightning External Services, Salesforce makes this a lot easier and admin friendly.

With external services you can connect to any service that you want to, invoke methods based on the external source via a flow all with the help of an easy-to-use wizard. Declarative tools are used to import API definitions right into Salesforce. Swagger or Interagent-based API definitions can be used to define an external service. Once the definitions have been imported, you can create lightning flows which will invoke actions generated from the API definition schema. Below is a depiction of how external services works.

KaranP1

Here is what is happening in the above image:

Based on provided API schema specification, a schema definition is created that describes the API. Once this is done, named credential is created to authenticate to the service’s endpoint using the URL provided by the external service provider. The endpoint is URL that exposes the web services resources that External Services needs to interact with. Using the named credential and schema definition, external service is registered. External Services imports the definitions into your org and generates Apex actions, which are available immediately in Lightning Flow. While creating a flow, these Apex actions are added into the flow which sends a callout to the endpoint and output is returned based on schema definition.

Schema Definition for your external service:

Schema specification is basically a contract which contains which type of inputs and outputs can be included in the API calls that are made from your external service. Endpoint information and authentication parameters for REST based API service are also included in specs. On the other hand, schema definition is human readable structured data.

Below is the schema definition of a pet store Swagger API.

Pet Store Schema

This schema declares various methods available in the API and the inputs, outputs included in this service. For example, the below snippet contains information about a GET method which is used to get all the inventories by status.

KaranP2

We will be using the Pet Store Schema to illustrate the whole external service in this blog.

Registering an External Service:

Registering an external service involves the below two steps:

1. Named Credential: In order to register an External service, you need to create a named credential first. Named credential is created to authenticate to the service’s endpoint using the URL provided by the external service provider. Create a Named Credential as below in your org:

  • For Label, use SwaggerPet.
  • For URL, use https://petstore.swagger.io
  • Leave other fields as they are and click Save.

2. External Service: In your org, go to setup and search for external service in the quick find box. Create a new external Service and provide the below information in the fields:

  • For name, give ExternalSrv1
  • For Named credential, select SwaggerPet named credential created in previous step
  • In the Service Schema Relative URL field paste “/v2/swagger.json”

KaranP3

 

KaranP4

The generated actions are used in the flows. Below is the list of actions available in the pet store endpoint. We cover getOrderById action in this blog.

KaranP5

External Services in flow:

Apex actions generated from external services can be used in lightning flows. When users run the flows, during runtime external services sends a callout to the service’s endpoint. Create a new flow and drag the Apex Action element. Select “ExternalSrv1_getOrderById__Service”

This action takes an Order id (any integer between 1 and 10) and returns details for that order like Order quantity, pet id, shipping date. Create variables for input and output data and configure the output variables to be stored in the variables as done below. Provide the default value of id such that 1<=id<=10. Set the input values and the output values by associating each with a flow variable. Make sure that the data type of input/output matches the input/output specs mentioned in the schema definition.

KaranP6

 

KaranP7

Connect the Apex Action with the start element.

KaranP8

After completing all these steps, click on debug. Doing this will start the flow in debug mode. On the next screen select Show details of what’s executed and render flow in Lightning runtime and click Run.

KaranP9

Above is the output of “ExternalSrv1_getOrderById__Service” for order Id = 2. Similarly, other Apex Actions can also be invoked using external services and flow without writing any code.

Summary:

External services are a great tool which along with point-and-click automation tool like flows and process builders can be used to integrate any API with Salesforce without writing any code. It reduces the development effort and is very much admin friendly making the process of integration making this process simpler and thus cheaper.

Posted in Agile, Salesforce, Salesforce Challenges, salesforce development, salesforce integration, Salesforce Lightning, Service Cloud. Tagged with , , , , , , .

Data Skew in Salesforce

Data is getting generated at an explosive pace nowadays and we are running out of storage solutions in order to manage that data. Researches by multiple magazines and portals suggest that 90 percent of the total data in the world was created in the last two years only. This pace continues to increase day by day and we are slowly approaching a state where we would not be able to deal with this data. Salesforce is no exception in this case where organization instances are having large amount of records related to the business process needs. When this plethora of data is not managed properly, we slowly approach a state which is termed as Data Skew.

What is Data Skew?

Data Skew generally refers to a condition where data is distributed unevenly in a large data set. In Salesforce, data skew occurs when more than 10000 child object records are related to a single parent object record, or more than 10000 records of any object are owned by a single Salesforce user. This skewness leads to major performance hits and long running processes which are something that one should avoid.

ShubhamPic1

Types of Data Skew in Salesforce

Three types of data skew exist in Salesforce which are as follows:

  1. Account Skew
  2. Ownership Skew
  3. Lookup Skew

 

1. Account Skew

This type of Salesforce data skew comes into existence when you have large number of child records present under a single account record. This is a very common scenario as it is quite tempting to place all your unwanted or unassigned records under an account named ‘Miscellaneous’ or ‘Unassigned’. As easy and correct as it may look, it can cause major issues such as record locking and sharing performances. This is mainly because certain standard objects like Opportunity and Account, have special data relationships which maintain record access under private sharing models. The problems that you will face in a state of Account skew are:

  • Record Locking: When we are performing an update operation on large number of child records in separate threads, the system locks the child being updated as well as the parent record in order to maintain database integrity for each update. Hence, the parent record might be locked by one thread while some other thread is trying to update the same.
  • Sharing Problems: When we have many child associations with a single parent record, a simple change in sharing setting might lead to a chain of time-consuming processes. Even a meagre change like updating the owner of a parent record may lead to all the sharing rules on the child records being recalculated as well as recalculation of the role hierarchy.

Possible Way for Avoiding Account Skew:

There is only one way to avoid Account skew, that is by distribution of such child records across multiple accounts rather than accumulation on a single record. Having an even distribution of child records across parent accounts fool proofs our organization against performance hits due to account skew.

 

2. Ownership Skew
Ownership data skew is another type of date skew which is very common in Salesforce. This issue occurs when more than 10000 records are owned by a single Salesforce user. Since every record inside Salesforce needs to have an owner, it is quite common in organizations to make a default owner or queue, to which all the unassigned or unused records go to. It is a preferred solution for many organizations in such use case, but little do they know that though this might work for small data sets, this will fail when we are dealing with large data. This increases the probability of performance issues whenever some change to the sharing settings or some similar operation occurs. For example, if a user owns large number of records and he/she is moved around in the role hierarchy, then the sharing rules for all the records owned by that user will be reevaluated and that will result in a long running operation.

Possible Ways for Avoiding Ownership Skew:

  • The best way to avoid this kind of skew will be even distribution of such records among multiple users rather than having a single user for all.
  • If you are compelled to stay put with this solution, then the performance impacts can be reduced by not assigning the user (record owner) to a role.
  • If the owner must have a role, then try to keep the user on top of the role hierarchy. This will avoid the user being passed around the role hierarchy.
  • Make sure that the user is not a member of any public group which is acting as the source for a sharing rule.

 

3. Lookup Skew
Lookup skew is similar to Account skew but can affect a broader number of objects. This happens when large number of records are associated to a single record in the lookup object. Since lookup fields can exist on standard as well as custom fields, lookup skew problem can arise on any custom object in the organization. This happens regardless of whether that lookup exists on a single object or across multiple objects.

Possible Ways for Avoiding Lookup Skew:

  • One method is to distribute the skew across multiple lookup fields. The main cause of the problem is that large number of records are lookup to the same record. By providing additional lookup values to distribute the skew, record lock exceptions can be minimized or even eliminated.
  • Remove unnecessary workflow rules or process builders on the objects in order to reduce the record saving time. Also, make sure that the synchronous apex code and triggers are well optimized.
  • In case the number of lookup values are low and definite, you can use picklist values to represent the lookup values rather than using lookup fields.

 

Conclusion

Data plays a crucial role in the business architecture of large organizations and hence these problems are very common. By taking a few steps while designing our architecture, the data skew problems can be avoided. Having a distributed data is still the best bet for getting rid of these skews and their repercussions.

Posted in Uncategorized. Tagged with , , , .