Use case: latencies reported while testing the integration
You are involved in a project where an inbound or outbound integration with a third party application to/from Salesforce has been built.
As part of the test phase, the integration team is reporting latencies when Salesforce APIs are called to trigger a business process and is asking you to investigate the reason why Salesforce is taking so long to answer back.
Reminder: How to correctly setup your API User
First and foremost, as explained in this previous article about How to setup your API user or integration user for a secure and scalable design over the time, it is assumed that you have followed these recommendations in order to segregate the business processes associated to each integration stream, and clearly identify which user needs to be tracked.
If not, investigating could be a much tougher task. Please have a look on these recommendations, you could find good reasons to tweak the way you have setup your API user.
Suggested approaches to catch logs and track the run time
There are basically 3 routes, which depend on the features available on your org.
You have access to Event Monitoring Logs on your Org
It is assumed you have purchased Event Monitoring feature, part of the Shield suite.
In order to access the logs, simply follow the online trailhead to understand how to retrieve logs from event monitoring and which event log you should look after.
Pros
- You get access to the server Run time, CPU time used, DB time used by each single API call
- These times include
- The time needed by Salesforce to execute its standard layer: framework initialization, processing a DML without automation, …
- Any declarative features execution time (flows, validation rules, …)
- Any custom code execution time
Cons
- You will get access to the detailed log, one line of log = one API call and need to filter based on your own criterias
- You have to buy this feature
You don’t have Event Monitoring but the inbound or outbound interface triggers some declarative or custom automations
Use the standard Salesforce Debug Logs feature on the API user to catchs the logs. Setting a debug log on your integration user will catch all declarative actions and custom code that are triggered by the API call.
This is therefore more relevant to inbound API calls to Salesforce than outbound calls.
Pros
- You can see in detail which part of your code or automation is running too long and use the Full Developer Console Perspective view to analyse deeper
- If option 1 using Event Monitoring confirm something is running too long in Salesforce transaction, setting this debug logs is probably the next step you will go through anyway
Cons
- Having debug logs activated while the process is running make it run a bit slower and using more CPU than when not activated, thus slightly altering the measures
- Depending on the integration complexity and your automations you have to navigate between each log files generated and find the right one
- If you have no automation, no code triggered by the interface call, you can’t catch any log, as this feature doesn’t catch the Salesforce standard layer
You don’t have Event Monitoring and no automations are triggered by the inbound or outbound interface
There is unfortunately nothing much you can do using Salesforce free features here. You’d better ask the integration team to share the details of their logs, and work with them to understand what’s going wrong.
Also depending on your Salesforce Support level, just raise a ticket and request help. They might be aware of an ongoing incident on your instance. Have a look on Salesforce Trust site.