Reduce retry interval time

Hi Divya,

If you guys are using on-premise environment than try changing properties in custom.properties.

###########################
#### Web Services Node ####
###########################

## The following are properties that control the behavior of HTTP connections
## made by the Call Web Service Node during service invocation.
## Number of seconds to wait to establish a connection with a web service host
#conf.node.webservice.connection.timeout=60
## Once a connection is established, the number of seconds to wait for a
## response to a request
#conf.node.webservice.socket.timeout=60
## Number of redirect responses (HTTP 304) the web service node will accept
#conf.node.webservice.max.redirects=4

You may need to change you node to use call webservice node.

You can also implement a timer based loop logic in the Process based on the standard HTTP responses/ HTTP codes. in this way you will be able to control the timer event that suits best as per the your requirements.

Hi divyaa as per my understanding, i would recommend you to handle this scenario via process instead of changing the settings globally.

You can configure Timer on your Integration Node based on your requirement and have a gateway to identify whether it's a success or timeout, if it's a timeout then try delegating the flow to your Integration node once again.

Have a flag variable to identify whether the it has chosen timer path or the actual one.

NOTE: You should define max attempts limit, because if your Target API keep on getting time out, then you should terminate your process instead of looping it again and again.

Hi, if you're cloud based then the timeout setting is pretty much well fixed. We use the timer pattern as suggested by Alok to determine if a service call has timed out (red line through the node). The highlighted node is where we call the service, either via an Integration (for REST GET) or Web Service expression rule for SOAP. We pass back information to the calling process so that it can determine what it wants to do - display error message to user, retry service based on predetermined factors (ie message content in the service response payload) or raise a technical issue with the support team to investigate. Ideally we shouldn't have services that timeout - so I'd suggest that the service is investigated to understand why it is not responding to Appian in a timely manner.