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.

[robbika]

In general I don't think 'async' business rules are the solution.

Messages should be in order.

If we have a 3rd party resolver system that sends a message to change the state of the ticket, and then we need to send out a B2B message to a customer system to reflect the change in the ticket (caused by the incoming message), then those things should be done in order. Do 'async' business rules guarantee anything?

Also I have an issue with journal fields. If a 3rd party resolver system has 3 rapid updates to do with comments, and that fires the async business rule 3 times to send the last comment, won't they just ALL send the last applied comment? I want it that three B2B messages are sent out, each with a different comment each, and each in order.

I think that 'post(true)' should work asynchronously and I'm surprised that it doesn't seem to.

[Dan117]

Yeah, the post(true) really just means that it is waiting for the response asynchronously, not that the entire request is asynchronous. One way to accomplish what you are looking for is to have a business rule that will fire an event and provide the work notes or comments as a parameter. Then use a script action to make the soap call which will be truly asynchronous.

[robbika]

After re-reading the wiki page 100 times, it looks like just using 'post(true)' simply puts the message on the ECC Queue which is processed by a 'before' business rules called 'SOAPClient', and that business rule waits for a synchronous reply.

So to make the sending truly asynchronous, I have to make the out-of-the-box business rule 'async' plus add 'current.update()' at the end.

To make sure the message is sent, I'm using the ECC Retry Policy plugin to repeat the sending if it doesn't go through first time.

I'll give this all a go and see if it works.

[Dan117]

Yes, you can use an async business rule as well. Using an event accomplishes the same thing, and you can pass in specific information like the work notes as a parameter vs an async business rule which may have been altered since it ran.

[robbika]

The interesting thing here is that the 'SOAPClient' business rule becomes 'async' but the business rules that construct the SOAP messages are 'after'. So putting the messages on the queue should be correct with the correct information. Then it comes down to whether the ECC Queue is processed in the order in which messages are added to it.

This all seems to be very messy. I'd have thought it would be a fundamental requirement to have an event driven system where it was guaranteed that messages went out asynchrously with the correct information in the correct order.

I guess I will spiral in on a solution. I will first try putting the 'SOAPClient' out-of-the-box business rules to 'async'. If that still causes issues (maybe with message sending order) then I will look at workflows. I find that workflows are also a flakey part of the system, so I'd like to avoid them until I have to use them.