Skip to content


Offer a new “Tasks that run after the document” event on maps

Marc Bellanger asked 3 years ago
In several scenarios, but specifically when working with a REST destination, we’ve needed the ability to personally assess and override the success/failure result of a document that SmartConnect naturally returns.  If we had an event which we could build this logic into that executes after the document is processed but prior to the success/failure events, where we could access and override the success/failure result, this would resolve this gap.
We would need access to these global variables in this new tasks section as well as “Document fails” & “Document succeeds”:

  • Document Error – Allow a post document run task to set this global variable to true/false indicating that an error did or did not occur even though SmartConnect has its own opinion.  It’s initial value should be what ever error state SmartConnect determined for the document, but this would give us the ability to override that when needed.

    • If the “Document Error” global variable is true, the “Tasks that run if the document fails” section should be executed

    • If the “Document Error” global variable is false, the “Tasks that run if the document succeeds” section should be executed

  • REST Response Body – This would allow us to manually search the message the REST API sent back for errors so that SmartConnect doesn’t have to magically handle all possible formats and keywords that should be monitored for (eg. valid, error, etc.).  Leave it up to the user to sift through the response body and find our own errors when the status codes don’t automatically do that.

  • Document Error Message – In the new tasks section “Tasks that run after the document” allow us to set the value of a variable which will be used as the error message and will be included in the global variable GlobalRunErrors and GlobalLastError and GlobalErrorCount.

With REST destinations, not having this functionality, along with the fact that SmartConnect is hardcoded to hide the response body of a communication status code of 200, means there is no way to error handle (capture and report) business logic errors being returned from REST API’s.  The communication with the REST API was good so it returns status code 200, but the business logic rejected your attempted call (eg. The customer code you provided is not valid) so in reality your attempted REST integration failed.  Currently in SmartConnect you can only flag a communication status code to always succeed or always fail, and even if you configure it to always fail, it will hide the response body so there is no way to capture it or report it out to a log, email or user.

If you would like to submit an answer or comment, please sign in to the eOne portal.