"ECC Queue Retry" plugin - can be used for monitoring/fixing outgoing errors?

[bradmartin]

We have a MID server setup for passing calls between our instance and that of one of our partners. Occasionally, due to some intermittent network issues, we get Bridge transactions failing with a "handshake timeout" error.

I've been having a look at the ECC Queue Retry plug-in as a possible fix/work-around for this, but as per the doco, it seems it's only geared towards dealing with incoming transactions failing?? Does anyone know if there's a way this plug-in can work for the outgoing transactions as well... or if there's a viable alternative for this? (or am I just totally misunderstanding the doco provided for the plugin?)

http://wiki.servicenow.com/index.php?title=ECC_Queue_Retry_Policy#gsc.tab=0

What we are seeing is entries like this, for a record showing up in error:

05-06-2017 11:35:17 - SNCMIDServer SNCMIDServerLog

Probe Error: run failed with error javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

05-06-2017 11:35:16 - Optus Ticket ExchangeLog

Successfully Create Outbound Client Ack Health Check (28)

05-06-2017 11:35:16 - Optus Ticket ExchangeLog

Created ECC Queue entry f2210f934f47b60036604c111310c70d

Generally, we can "fix" this issue by manually hitting the "retry" option, but I would much rather be able to use an automated/scripted option like that in the Retry plugin. Does anyone have any experience with setting this kind of thing up? At present, am having to manually deal with anything up to 20 or so failed transactions in a day, with some days being quieter than others... but it's a manual task I could quite happily go without 😉

Any constructive suggestions/feedback greatfully welcomed.

Cheers,

Brad.

[shivanipatel]

Brad,

We are glad you took advantage of the ServiceNow Community to learn more and to get your questions answered. The Customer Experience Team is working hard to ensure that the Community experience is most optimal for our customers.

If you feel that your question was answered, we would greatly appreciate if you could mark the appropriate thread as "Correct Answer". This allows other customers to learn from your thread and improves the ServiceNow Community experience.

If you are viewing this from the Community inbox you will not see the correct answer button.   If so, please review How to Mark Answers Correct From Inbox View.

Thanks,

Shivani Patel

[bradmartin · Accepted solution]

Thanks Shivani for the follow-up - I hadn't forgotten the thread - I was wanting to confirm successful testing on what we had set up before coming back to close this one off

On Friday we managed to have a successful attempt at a retry in our DEV environment, after finally get another chance to take a look at this. In case others are looking into this also, what we ended up using for the script was:

var ProbeError = gs.getXMLText(current.payload, "//ProbeError");

answer = ProbeError.startsWith('run failed with error javax.net.ssl.SSLHandshakeException:');

The answers from both Ahmed and Brian were helpful in getting us to a working solution, so not entirely sure how to handle that, with regard to accepting a solution?

[shivanipatel]

Hi Brad,

Thank you for your response! I would suggest marking your last reply on June 11th, 2017 at 4:14 pm as the "correct answer." Thank you for your engagement with the ServiceNow Community Brad!

Best,

Shivani Patel

[Zhiming Dai]

Hi,

I hope you are doing well. We have similar requirements that need to trigger the retry policy on output queue failure. I tried your implementations but I still couldn't get the retry policy to trigger

Can you share a little more details about your final implementation please? For the trigger conditions, did you use output queue or input queue (please see the screenshot)? Thank you in advance for your help!