SonicConnect Services: Standalone or in a Process ??

I didn't get a single reply to this post which is unfortunate.  However, in another response several months ago by Peter Easton when I was inquiring about aspects of SonicConnect services, Peter did indicate that SonicConnect invocation services (clients) need to be in processes.  Published SonicConnect services consumed by other clients do not.  This is what I encountered in practice.

There is another aspect to these services I would like someone to address if possible?

I have an itinerary begun by a SonicConnect service which receives a client request and needs to synchronously respond to the client.  In the underlaying itineraries, there are cases where an asynchronous dispatch and synchronous endpoint calls are utilized.  What is the proper method to create or dispatch messages in both cases, asynch dispatch and synch call, such that the esbReplyTo and JMSReplyTo properties are not tied to the reply to associated with the initial SonicConnect service?

The top level esb reply to and JMSReplyTo are the obvious temporary constructs/destinations established to receive the synchronous reply to the client requestor, but messages that get created to dispatch and call endpoints still contain these properties for the top level SonicConnect service.  Ultimately, endpoint calls timeout unless JMSReplyTo passed in is blank or non-existent.  When we dispatch to an address without a JMSReplyTo populated, a severe XQ_ENDPOINT_EXCEPTION message is produced:  [11/03/14 10:50:36] ID=dev_ESBTest (severe) [Dispatch] XQDispatcher for application WSClientControllerService - XQ_ENDPOINT_EXCEPTION error processing message: ReplyTo does not exist for this message.

What is the proper means to use produce a message for an asynch dispatch or a synch call method to not conflict with the top level SonicConnect service reply to properties but also not produce the ReplyTo does not exist message?

I'm attempting this, my overall processing works, but there are still issues (the above exception, and the headers returned in the SOAP resposne to the SonicConnect client contain ESB specific items - undesired):

            /*
             * CREATE A NEW MESSAGE FOR THE INVOCATION OF THE WS CLIENT PROCESS AND POPULATE IT WITH APPROPRIATE INFORMATION
             */
            XQEndpoint xqEndpoint = a_XQServiceContext.getEndpointManager().getEndpoint( Constants.WS_CLIENT_ENDPOINT_ADDRESS ) ;
            XQMessage xqFwdMessage = xqEndpoint.createMessage() ;
           

            XQPart xqMemberPart = xqFwdMessage.createPart( (byte[]) this.getObject( a_XQEnvelope ), XQConstants.CONTENT_TYPE_BYTES ) ;
            xqMemberPart.setContentId( Constants.FORWARDED_MEMBER_CONTENT_ID ) ;
            xqFwdMessage.addPartAt( xqMemberPart, Constants.FORWARDED_MEMBER_PART ) ;
           

                     XQPart xqForwardedRequestPart = xqFwdMessage.createPart( member.getXml(), XQConstants.CONTENT_TYPE_XML ) ;
             xqForwardedRequestPart.setContentId( Constants.FORWARDED_REQUEST_CONTENT_ID ) ;
             xqFwdMessage.addPartAt( xqForwardedRequestPart, Constants.FORWARDED_REQUEST_PART ) ;

            // Set the override WSDL Port Address URL in the message header for the outbound request invocation
            xqFwdMessage.setHeaderValue( Constants.C2C_WEB_SERVICES_R2I2_FORWARDED_HEADER_PROPERTY_NAME_URL, member.getURL() ) ;
           
            /*
             * CALL THE WS CLIENT AND WAIT FOR SYNCHRONOUS RESPONSE TO DISPOSITION
             */
            XQMessage xqResponseMessage = xqEndpoint.call( xqFwdMessage, Constants.FORWARDED_REQUEST_TIMEOUT );
            String forwardedResponse = (String) xqResponseMessage.getPart( Constants.FORWARDED_RESPONSE_CONTENT_ID ).getContent() ;

Hi Chris,

Responses to some of your questions:

> 1. Simply, must a SonicConnect service always be placed inside of a process  in order to be properly configured and handled in the ESB?

mnair: The SC service should be placed in a service for consuming (invoking) REST/SOAP web services. For the use cases related to exposing ESB processes over REST/SOAP you are on-ramping on to the bus via the HTTP(S) transports provided by the SC service and therefore you need to leave it stand alone.

> 2. As a  secondary follow-up question, a process can be defined as a General  process, a REST process, or a Fault Handler process.  Should a  SonicConnect service be placed in a REST process type or is a General  process type sufficient?

mnair: There are no restrictions on the type of process in which you can include the SC service. A REST process type is typically used for ESB processes exposed over REST. A fault handler type is self explanatory. So you could put an SC service in a REST process if you want your REST exposed process to make its own REST invocations. Similary you can perform SC invocations from within a fault handler process.

Thanks

-Mahesh

Hi Chris,

If you are using Endpoint.call from within a process exposed over SC then the framework should handle the setting of a new REPLY_TO destination specifically for the Endpoint.call operation and revert to the original REPLY_TO (in this case set by Sonic Connect) after the call. If you are seeing a different behavior then please go through support to investigate this further.

If you are using async dispatch then try creating a new message using the message factory you obtain from the service context. This should not contain the REPLY_TO in the message arriving in the service method.

Thanks

-Mahesh

Mahesh or others, I am not seeing the expected behavior in the product on creation of new messages as you've stated.

In using the XQServiceContext.getMessageFactory().createMessage(), the message created which I intend to use for asynchronous dispatch still contains the JMSReplyTo and {http://www.sonicsw.con/esb}ReplyTo message headers set with the same values that were present in the message that came into the service.  I would like a clean message and this API is not giving it to me as you suggest it would above.

The XQServiceContext.getMessageFactory().createMessage() does not give me what I'm referring to as a 'clean' message to asynchronously dispatch - not desiring it to reply to the original client.  The only way I've managed to get a clean message is to use the Endpoint API based on the endpoint I am dispatching to.  You suggest this should be used for an XQEndpoint.call() method where I want a synchronous call and response versus the XQServiceContext creation for a XQDispatcher.dispatch() method where I wanted to fire and forget.  The clean message without ReplyTo headers, when used with the XQDispatch.dispatch() API, yields these messages which are probably undesirable as well:

[11/05/19 11:57:13] ID=dev_ESBTest (severe) [Dispatch] XQDispatcher for application WSClientControllerService - XQ_ENDPOINT_EXCEPTION error processing message: ReplyTo does not exist for this message

Can you confirm either what you suggested was backwards or is there a bug in the XQServiceContext.getMessageFactory().createMessage() API when the message inbound is a message received by a SonicConnect service?

Thank you.