Integration Logs
If your Salesforce instance is talking to external services via REST or other types of APIs, Pharos Triton can perform a certain type of logging that helps troubleshoot those integrations.
Last updated
If your Salesforce instance is talking to external services via REST or other types of APIs, Pharos Triton can perform a certain type of logging that helps troubleshoot those integrations.
Last updated
In this article, we'll look at creating logs with supporting request/response payload information. A typical scenario involves performing an Apex callout. Oftentimes we expect an HTTP 200 response if all goes well. However, the most troublesome scenario is when things don't go well. You may receive a non 200 response from your external service and, at that point, the only way to get to the bottom of the problem is to examine the request/response payload.
Triton offers a convenient interface for visualizing payloads directly from a log record. Below is an example of such a log record:
If you've used Postman before, this view may look familiar. From this interface you have the ability to view the request endpoint, parameters, headers, and body. In a similar fashion, you can examine the response that is returned. There is also a replay capability that allows you to re-send the request (with optional modifications) to your external endpoint. The request will be sent from your org and not just your browser. This is a very powerful way to troubleshoot integrations. Moreover, there is an easy way to create these types of logs view the Pharos Triton Apex interface. Let's take a look at an example.
Regardless of where your integration is kicked off, you'll likely have some Apex code that sets up an HttpRequest and performs a callout to your external service. In the example below, we're going to collect some data from a custom object and use that to create the JSON body of the request and send it off to our external service.
Your use case may not be this exact operation, but in all likelihood, the idea is similar: gather data, create a request payload and perform the callout.
One glaring issue with the code snippet above is that it doesn't account for the possibility of failure. If the HttpResponse response returns a 500 status or some other non-200 failure, we will never know. At that point it's next to impossible to connect the dots, especially if the failure is discovered well after the request was performed. To remedy this situation, let's add some logging to help us out.
Executing this code snippet should result in a log similar to the following:
Because we also specified a record Id in the details of the log we should also see a related object linked to the log record: