Problems with sending SOAP messages asynchronously

[robbika]

I've come across a problem with sending asynchronous SOAP messages.

I've noticed this because I closed a Catalog Task that would close a Requested Item and a Request, that I knew would send out a SOAP message to another system (a B2B link with another system). The message is constructed and sent in a Business Rule. The relevant part of the script in the Business Rule is:

var response = s.post(true);

where 's' is the SOAP message and using s.post(true) means the message should be asynchronously inserted into the ECC Queue and then something else on the ECC Queue would deal with it. So, changing the status of a ticket thus causing a message to be posted to the ECC Queue, the web page should return immediately. In a synchronous interaction, I'd expect the web page not to return until the SOAP message has been sent synchronously.

What seems to happen currently, even though we are using 'post(true') is that the web page does not return until the SOAP transaction has happened or at least fails.

I know this because I put a ticket to closed, hit 'save', and the page did not return for more than 2 minutes. Curious about this, I looked at 'stats.do' on another page and looked at the currently executing Java stacktrace, and it was clear that the code was waiting for a SOAP response. Looking into the ECC Queue, indeed the message appeared there, and indeed failed with a timeout.

Questions:

- are my assumptions true? Should 'post(true)' put a message on the ECC Queue and then return leaving the queue to process it asyncrhonously?

- the Business Rules that all send message are 'after' BRs. Should they me 'async'? (If so I have some issues with that with journal fields maybe).

Has anyone else seen this behaviour? Are we doing something wrong?

Because of this behaviour we have many many issues. We recieve SOAP messages from systems that cause ticket to be created or ticket states to changes, sending out SOAP message to other system. This is all supposed to be event driven and asynchronous. If part of it isn't, runs synchronously, and has a timeout, then part of the overall system is going to fail, which indeed it is does on occasion.

This is in Dublin with the latest hotfixes.

[Mike Allen]

I would run it async and create a sensor that watches the response.

Web Services Integrations Best Practices - ServiceNow Wiki

[robbika]

I'm not interested in the response really.

In Web Services Best Practice, it simply says to use 'post(true)' instead of just 'post()' and that should give an asynchronous way of working. If for any reason the business rule is made to wait for a response, I would not call that asynchronous.

I have issues with using 'async' business rules. I might be wrong, but let's say we have two actions on a ticket to put an Additional Comment: 'Comment 1' and 'Comment 2'. If the biz rule to send a SOAP on these comments is 'after' that does a 'getJournalEntry(1)' for the last journal entry, then the first SOAP will contain 'Comment 1' and the second 'Comment 2'. If I make the rule 'async', then if the two comments are put on quickly one after the other, then I think although the biz rule will run twice, both will pick up 'Comment 2'.

i.e. I don't think 'after' can be directly changed to 'async' without consequences where Journal Fields are concerned.

I'd love to be corrected.

Why is 'post(true)' not asynchronous in the way I think it should be?

Why do I need to use 'async' biz rules?

Will it work if I do convert them?

[poyntzj]

I run all my routines via a BR that calls a Script Include and so far, no problems.

I have had a similar issue with a Workflow script with 4 branches for 4 slightly different scenario's. The code was the same except for one variable's value. That got a little confusing.

in the end I changed that so they were agr, pgr, cgr and ogr and it works

If your updates are all Business rules, see if making the code

is (incident)

ris (request item)

rqs (request)

cts (change task)

crs (change request)

works

[Ravish Shetty]

Though i do not address the exact problem here but you could use the alternate to async BR here which may or may not work:

• Script action
• ScheduleOnce API