weird sonic connect behaviour when invoking an external webs

Posted by cipdwak on 08-Jun-2011 08:25

An ESB process is using a sonic connect service step to call upto 4 different operations from the same webservice.

The ESB proces calls the four different operations in a row, al steps using the same connect service instance.

The first call works as expected, but the next three steps are calling the first operation again, allthough the ESB camel Bean ID is set to the correct operation.

So instead of four different operations, we end up calling four times the first operations.

Does anyone have any idea or experienced the same behaviour?

All Replies

Posted by cipdwak on 09-Jun-2011 03:01

We found the problem:

It was caused by certain JMS properties (operation and SOAPAction), used als HTTP headers.

The first call sets the initial values but these headers are not automatically updated with the next call(s). So the next step had the proper configuration & message payload but was directed to the wrong webservice operation).

Our solution was to remove these headers before invoking the next call. If the headers do not exist, they will be set (again) by the connect service.

Posted by cwiseman on 10-Jun-2011 10:17

Koen, good find.  Does this mean you could override the designated SonicConnect Client service step ESBCamelBeanId by essentially manipulating the header values in the JMS messages?

Posted by cipdwak on 15-Jun-2011 03:45

So it seems. I'm not sure of it's by design or unexpected beheviour.It could easily be the other webserver, because the JMS properties are automatically translated to HTTP headers and then send.

I assumed that each time you used a connectservice call, the applicable JMS properties would be updated to the correct settings. But apparently, if a header allready existed, say 'SOAPAction', it is left allone (instead of updated).

In this particular scenario, we could fix it with the removal of the JMS properties. If they didn't exist, they where created automatically.

But it's essentially a hack and therefore only used with utmost care. Certainly not a best practice, I think :-).

This thread is closed