In the context of a Sonic Custom Service, I need to read messages from a designated queue and dispatch these messages asynchronously to a known entry endpoint of another process altogether. I'm using the SonicMQ API to read the messages from the designated queue and using the XQInitContext and XQDispatcher API to attempt to dispatch the messages asynchronously to the correct endpoint address. The result is a java.lang.ClassCastException because the QueueReceiver processing the messages on the queue receives a MultipartMessage and the XQDispatcher API wants an XQMessage.
Is there some legitimate translation between the SonicMQ API where JMS messages are concerned and the SonicESB (XQ) API for ESB messaging? Is that even necessary - it does feel like there should be a bridge between MQ and XQ within the context of a custom ESB service given the ESB services sit atop the MQ messages. Thanks.
Can you please post the exception and the OnMessage code on your queue receiver?
MQ JMS API supports Multipart messages. Maybe you cast it to a XML/Textmessage?
Stefan, I'm not implementing onMessage(). I use a simple QueueReceiver.receiveNoWait() to pick messages off the queue and then attempt to dispatch them. The task which picks the messages off the queue wakes every 30 seconds from slumber (bootstrapped by a custom ESB service through its init() and start() methods).
I have a progress.message.jimpl.xmessage.MultipartMessage coming off the queue. I need to pass this message to the entry endpoint (queue) of the process that I want to process this message (again) after it failed previously (I have processed it through fault handling, etc. prior to the reattempt and am controlling the business logic).
I tried using XQ API to get the MultipartMessage then using XQInitContext and Address/Endpoint/Dispatcher to dispatch again, but this needs an XQMessage.
It seems I need to simply use a QueueSender to place the message back into the destination queue I want to resubmit it to vs. trying to use the ESB XQ API. Do you agree?
Sorry, I still don't get it.
Inside a ESB service you should use the ESB apis.
You can use temporary/dynamic endpoints to receive from a queue.
And then dispatch the message.
Out side teh ESB (in a JSM client) use the MQ Api.
If not clear, you may open a support call and we can discuss further. Might be easier via phone/webex ;-)
Hello Chris, I agree with your suggestion and that's what I would do. However, I don't think you have any advantage by doing this in a custom ESB service. It could be easily done in a Windows service with the C++ or C# API.
Hello Chris,
I think that the scheduler Service is already doing what you want to do.
This service uses the ESBApi to retrieve messages from an endpoint in a cron fashion.
Regards
Chan Jérémy
Jeremy, I'll take a look at this. The benefit of using an all XQ API on the messages is the ability to manipulate properties and work within the services API. Thank you for the reply.
Is the scheduler service type part of the core ServiceTypes? I don't have that type in Sonic v8.0 SP1
Jeremy, I found a serviceType which was at least at one time available in the CodeShare and is based on the Quartz scheduler.
This is the same pattern I'm using - establish all of the initialization in the init()/start() methods of the service and perform scheduling and job detailing there. There is no work being performed at all in the service() method because this service is not triggered by messages delivered to it's entry endpoint.
Is there another Scheduler Service Type you might have been referring to? I'm using a custom scheduler service, but it's all initialized in init() and start(). When the scheduled job runs, it's not receiving the messages in XQ API through it's own service() method, but rather needs to build the JMS components to receive from a queue specifically - the resulting messages are MQ/JMS messages, not XQ messages.