Unable to make async rest request from a before business rule?

[dachtman]

I have a business rule that runs on insert and update on a app scoped table.The business rule calls a restful webservice and based on the response the operation should either be aborted or continue.

When I run this as a before rule I get an error stating Use an async business rule to perform outbound HTTP requests. I have tried switching the webservice to use executeasync and that has caused more errors with truncation of the endpoint. I have also tried switching the business rule to async but that doesn't allow for me to stop the current operation.

[xMTinkerer]

No, I lied, it does NOT complete the request if doSync is set to true, it just throws the error.

So, I must be using that waitForResponse wrong.

Did either of you get this passable? As is, the executeAsync isn't usable.

[dachtman]

I am still working on getting this work. The execute async does not need the wait for response method as it is getting passed into the ecc queue and then be executed from there. If you wanted to use the waitforresponse this would be used with the execute method.

Also from talking and doing some research I understand why this is being enforced. ServiceNow doesnt want to create a infinite loop or long running transaction that is outside of the system. A good alternative to this is to do it async or create an event and do the work there.

[dachtman]

I was able to accomplish what I was trying to do using events and creating script actions. The only down side to this is that there is a small lag between when updates occur with the third party request. so the user is not always aware that an error occured.

[bbarnard]

Agree that evented approach is a better way to go with this. But now you're concerned about providing the user feedback regarding the outcome of the REST request. Are you feeding the outcome of the request back into a field on the record? Some type of status or a journal field?

[xMTinkerer]

We are adding a note to the work notes. "Successfully sent event 1234" or "Failed to send event. Check the logs for details". Having the event id and a record of when it was successfully sent is needed for audit purposes.