Best Practices to Avoid Excessive SOAP and REST API DML | Salesforce Developer Guide
Ensure your code is as efficient as possible when developing integration applications with Force.com SOAP APIs to avoid poor performance or API limit issues. This will prevent poor performance and API limit issues caused by excessive API calls.
Resolution
Salesforce’s SOAP API and REST API provide powerful, convenient Web Services interfaces for interacting with Salesforce. These APIs are often used in integration projects, where Salesforce is integrated with existing systems.
In Integration projects, Salesforce data is created, updated or deleted using SOAP APIs and REST APIs records.
The APIs are capable of handling large record sets, but you should follow best-practice to ensure your code is as efficient as possible. Inefficient code can result in excessive API calls, resulting in poor performance, or even Salesforce limits.
There are some suggestions in this article that can help you improve the performance of your code when it comes to creating, updating or deleting large record sets.
Use Incremental Processing
Using incremental processing, you update only records that have changed in Salesforce. For example, you could use the SystemModstamp date-time field or a custom field to mark records that need to be modified and update them only in Salesforce, rather than doing a wholesale update.
If your integration code is doing large updates without taking advantage of incremental processing, see if you can take advantage of incremental processing to greatly improve performance and reduce the number of API operations.
You may be able to greatly improve performance and reduce API calls if your integration code performs large updates without using incremental processing.
See Incremental Processing for Heavy Bulk API / DML Use Cases for use cases, best practices and examples (the article applies to SOAP API and REST API as well as Bulk API)
Don't forget to check out: Salesforce To Salesforce Integration Using REST API
Bulkify your SOAP API Code
SOAP API calls should be processed in batches instead of one at a time, since processing records one at a time incurs extra overhead, reducing performance and using up more API calls per day.
Use of calls within for loops can indicate that you are not bulkifying your SOAP API calls. All Soap API data modification calls such as create(), delete(), update() and upsert(), can take an array of records.
You can batch your changes in an array and pass the array instead of calling create() for each account in a loop. For example, if you need to create a set of Accounts, you can create an array with each account and pass that array into a single create() call:
Account[] accounts; ... // populate accounts array with all new account records ... // create all accounts in Salesforce with a single call to create() SaveResult[] saveResults = connection.create(accounts);
NOTE: Array cannot exceed more than 200 records in a single call.
Array you pass to data modification calls doesn’t have to be limited to just one object type. SObject arrays can include records of multiple object types and are useful when modifying related records. Using an SObject array and foreign keys, you could create a parent and child record in a one call to create():
Opportunity new opportunity = new Opportunity();
newOpportunity.setName("OpportunityWithAccountInsert");
newOpportunity.setStageName("Prospecting");
Calendar dt = connection.getServerTimestamp().getTimestamp();
dt.add(Calendar.DAY_OF_MONTH, 7);
newOpportunity.setCloseDate(dt);
// Create the parent reference
// Used only for foreign key reference and doesn't contain other fields
Account accountReference = new Account();
accountReference.setMyExtID__c("SAP111111");
newOpportunity.setAccount(accountReference);
// Create the Account object to insert
// Same as above but has Name field
// Used for the create call
Account parentAccount = new Account();
parentAccount.setName("Hallie");
parentAccount.setMyExtID__c("SAP111111");
SObject[] createObjects = { parentAccount, newOpportunity };
// Create the account and the opportunity
SaveResult[] results = connection.create(createObjects);
NOTE: You can't refer to more than 10 different object types in one call.
Check for Data Skew Impact
A large number of related records might cause performance problems when performing DML operations. For example, if a client application calls a delete() to delete an Opportunity, then any associated OpportunityLineItem records are also deleted. Performance can be affected during DML operations when large amounts of related records are shared or locked. Another example is deleting a large number of master records in a master-detail relationship with many children will incur a cascade delete performance hit.
A record that has more than 10,000 related records can cause data to skew performance issues. Consider performing data management to address the data skew:
- Can any child records be removed?
- Can the relationship type be changed to avoid cascade operations (lookup instead of master-detail)?
Be Aware of Operations that Cause Cascading Changes
Check out another amazing blog by Navdita here: Defining Validation Rules in Salesforce
Data changes can trigger post-operation actions, including workflow rules, Apex triggers, and assignment rules, which can result in more data operations than expected.
There might be situations where the additional data operations generated by these post-operation actions are unnecessary.
For example, an Apex trigger could update Opportunities associated with an Account. A large-scale replacement of Account records followed by a large-scale replacement of Opportunity records will result in unnecessary trigger updates. Disable post-operation actions during large updates if you know you won’t need them.
Check for Parent Roll-up Summary Fields
SOAP API DML operations on a child object might be incurring a performance hit when the parent roll-up summary field is recalculated when a master object of that object has a roll -up summary field. The roll -up summary field recalculation may also trigger other workflow rules and field validations, which can slow down the system.
Check if your roll-up summary fields are still needed, if they can be adjusted, or if triggered workflows, validations, etc can be removed or reduced.
Responses