SonicConnect Service Response Behavior

Posted by cwiseman on 28-Feb-2011 10:58

I'm using a SonicConnect service to represent an entity which publishes a web service that my product will consume - I'm the client.  The SonicConnect service operation maps to a process containing a single, custom service step.  The custom service step has to callout to one of several custom, standalone services which could get called based on the message received by the published SonicConnect service.

I started by using the endpoint.call() function in the SonicConnect custom service to call out to the specialized standalone services because I need the response to return it back to the SonicConnect service requestor.  When using the endpoint.call() method in the service step in the SonicConnect service's process, the proper result gets back to the requestor of the SonicConnect service.  However, the endpoint.call() takes the XQEndpointTimeoutException.  The SonicConnect service gets the response from the service called-out to, but the call() method does not get the response.  This worked because there really did not need to be any post-processing performed on the response from the standalone service before responding to the SonicConnect requestor.

In examining the message created in the SonicConnect service custom service from the service context to use to performed the call(), it became clear that the message headers created included the ESBHeader and JMSHeaders required to ensure that the replyTo got back to the SonicConnect listener.  Why is this the case?  Shouldn't the call() method over-write or preserve headers such that the response from the call() returns synchronously to the call() method and not to the SonicConnect context?  Here were the pertinent headers in the new message:

2011/02/25 13:03:44.187 [DEBUG] <JMS Session Delivery Thread - SonicESB/esb/Domain1/dev_ESBTest/dev_ESBTest/jms_defaultConnection$SESSION$59:-566174459939394231> (C2CAgencyEmulatorProcessCustomService.processEnvelope:142) - ***** Forwarded Message Headers:
XQMessage Headers::[
    Header:
        name = "{http://www.sonicsw.com/esb}ReplyTo"
        class = "java.lang.String"
        value = "ENDPOINT:EmulatorWebServiceSonicConnectService.Connect.AsynchTmp
    Header:
        name = "JMSReplyTo"
        class = "progress.message.jclient.Topic"
        value = "EmulatorWebServiceSonicConnectService.Connect.AsynchTmp
]

I attempted to change the SonicConnect custom service to use the XQDispatch.dispatch() API to issue the callout to the standalone custom services and the whole thing stopped functioning altogether.  Used with dispatch(), the SonicConnect service never got the response to send back to the client, even with the same message headers confirmed as in the call() method.  I wasn't quite sure what was happening or why the different behavior.

Graphically, here's the flow:

This works but the underlying call() method takes an XQEndpointTimeoutException:

SOAP Request -> SonicConnect Service -> SonicConnect Service Process -> SonicConnect Service Process CustomService call() to standalone Java Service Type

SOAP Response <- SonicConnect Service <- standalone Java Service Type Outbox REPLYTO endpoint <-

This doesn't work at all.  The SonicConnect Service doesn't get any response at all:

This works but the call() method takes an XQEndpointTimeoutException:

SOAP  Request -> SonicConnect Service -> SonicConnect Service Process  -> SonicConnect Service Process CustomService dispatch() to standalone  Java Service Type

Yields no response at the SonicConnectService


All Replies

Posted by cwiseman on 28-Feb-2011 14:24

I answered my own question after studying the com.sonicsw.xq.XQEndpoint object API at bit closer.

I was creating a new message to pass as an argument of the call method.  The message was being created out of the service context.  This obviously was creating a message with the intention to reply utlimately to the over-arching SonicConnect service.  I instead, used the endpoint itself to create the new message I would pass into the call() method.  It does not populate the reply to and allows the call method underlying logic to handle this.

This thread is closed