execute() vs executeAsync()
If you are using RESTMessageV2 or SOAPMessageV2 within your scripts you may have noticed that there are two ways to execute a call:
- execute(): this method will make the call Synchronously meaning that the script execution will WAIT until the call completes before continuing. In general, it is not a good idea to use this method unless you set a very short timeout.
- executeAsync(): this method will make the call Asynchronously meaning that the script execution will not wait for the call to continue executing. The rest of the script's execution is not guaranteed to occur after the call has completed.
When to use execute() and things to think about when using it:
- This method should only be used for very quick service calls and should not be called in very high volume no matter how quick the service.
- Only use execute when the timeout is very short, otherwise, the instance can be brought to a standstill. There are 2 properties to focus on for this, glide.http.timeout and glide.http.connection_timeout. By default (property not set in properties table) these are set to 175 seconds and 10 seconds respectively.
- Generally, you should not use this method if the request must go through the MID. MID requests must go through the ECC queue which is an asynchronous queue in the first place. The thread will not only be held up by the request itself but it will also be held up by waiting for the MID server to respond back to the instance. If MIDs are involved it is highly recommended to use asynchronous calls with a sensor business rule (see examples below).
When to use executeAsync() and things to think about when using:
- When you don't care about the response it is better to use executeAsync ("fire and forget")
- When your request is very large or has the potential to take a long time. From there, if you need the response then you can set up a sensor business rule to listen to the ecc_queue for the response.
- Generally, you should be using executeAsync whenever you can as it is the safer option.
- Calling waitForResponse() right after calling executeAsync() essentially turns this method into a simple execute() method and should only be used with very short wait times.
How to switch from using execute() to executeAsync() when it is not fire and forget:
Many scripts using execute() may look something like this -
To switch this over to use executeAsync we must simply move block C out to a business rule that is set on the ECC Queue looking for the response to our asynchronous method
Your new script using executeAsync():
The script of your new sensor business rule (see the "Process Get Stock Quote" business rule as reference for SOAP) -
Using this kind of setup is much safer for the instance as threads will no longer be sitting around doing nothing waiting for possibly long-running services to finish.