Currently, if a failure happens to Salesforce the watchdog entry looks something like:

SalesforceException 400: MALFORMED_ID

This is because the mappings in includes/salesforce.inc are like:

throw new SalesforceException($this->response->error, $this->response->code);

I think a more helpful exception would result in something like:

SalesforceException 400: Account ID: id value of incorrect type: 001900K0001pPuOAAU

Proposed Resolution

Take the documentation from https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest... and https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_ap... and write a mapping from the Salesforce API response to a more useful PHP exception.

CommentFileSizeAuthor
#4 salesforce-include_response_in_exceptions-2792043-4.patch6.57 KBaaronbauman
#3 2792043_3.patch1.46 KBjosephdpurcell

Comments

josephdpurcell created an issue. See original summary.

josephdpurcell’s picture

josephdpurcell commented

A good example of where a more useful handling would be this:

{
  "message": "Required field",
  "errorCode": "FIELD_CUSTOM_VALIDATION_EXCEPTION",
  "fields": ["AccountId"]
}

This may map to an exception that says:

SalesforceException 400: Required field AccountId

This may also be a great opportunity to also implement a deeper level of debugging, perhaps a hook, to be able to see the full request and response objects, or perhaps toggle that info to be also printed in watchdog as an extremely verbose option.

The use case for this deeper debugging would be building out a mapping and getting obscure errors from Salesforce.

josephdpurcell’s picture

josephdpurcell commented
StatusFileSize
new 2792043_3.patch1.46 KB

This patch is an example of extreme debugging that was very helpful to me in discovering the problem with the mapping. This is obviously not to be reviewed or committed, but shows a proof-of-concept of the extent of info one might need to be displayed in the extreme case.

I think the more common and appropriate case would be as mentioned in the description: just map the error code and message in the response to an appropriate PHP exception.

aaronbauman’s picture

aaronbauman
he/him
commented
StatusFileSize
new salesforce-include_response_in_exceptions-2792043-4.patch6.57 KB

I was just dealing with the same issue yesterday.
I was thinking of extending the SalesforceException object, something like this:

 class SalesforceException extends Exception {
+  public function __construct($message = NULL, $code = 0, Exception $previous = NULL, stdClass $response = NULL) {
+    parent::__construct($message, $code, $previous);
+    $this->response = $response;
+  public function getResponse() {
+    return $this->response;
+  }
 }

so that implementations could fetch any info they need from the response object (which also contains the request).

Patch attached - lemme know if this will work for you.

aaronbauman’s picture

aaronbauman
he/him
commented
Status: Active » Needs review
josephdpurcell’s picture

josephdpurcell commented
Status: Needs review » Active

What I'm proposing here shouldn't be reviewed--a solution still needs written. The patch I include in comment 4 is just an extreme example of what could be done, this may help others who are in dire need of some thorough debugging help (as I was) :)

The solution I expect would involve mapping the Salesforce codes to useful outputs, e.g. the validation exception mapping to an exception that shows the message and fields.

josephdpurcell’s picture

josephdpurcell commented
Issue tags: +Dublin2016

This might be a fun bit of work for a sprinter today. The goal here is to provide better "debuggability" of the Salesforce module.

aaronbauman’s picture

aaronbauman
he/him
commented
Status: Active » Closed (won't fix)

7.x is no longer supported

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.