I have heard about Solace and I'm reading about it but I don't know much yet about it. I have a HashMap:
{Swaps_snaptime=2016-04-26T07:00:00.000Z, Swaps_20Y=2036-04-29 0.004588, Swaps_15Y=2031-04-29}
And I want to publish this to Solace. How do I do that? What are the steps I need to follow? Please help!
You need to execute the following tasks to send a message:
Connect to the Solace Message Router
Create a producer
Create the message object
Send the message
There's a simple example of how to do the above at the Solace website.
Note that the example makes use of TextMessages.
In order to send your map, you can do the following:
Serialize your map, and then send it as part of a BytesMessage.
Place the contents of your map into a MapMessage.
Place the contents of your map into a StreamMessage
Use any message type, and place the contents of your map into the header portion of the message. Refer to How to send the header along with payload in Solace.
Related
I am using Apache Camel and IBM MQ to send messages. I need to receive COA when a message gets delivered to a remote queue. The general picture looks like this:
When the message reaches msg_q2 queue, I should receive the COA back. So, the problem is that I am not able to set the QMGR_REM as reply-to queue manager, which is supposed to produce COA.
https://www.ibm.com/docs/en/ibm-mq/8.0?topic=messages-reply-queue-queue-manager
I tried setting JMS_IBM_MQMD_xxx headers, but for some reason those headers either get omitted or ignored (by Camel?), and the message fails to be put on the queue with the reason that the reply-to queue is not specified. Also, I tried setting JMSReplyTo header as queue://reply-to-qmgr/reply-to-q. In this case the queue:// part gets removed, and the rest is simply set as a reply-to queue name.
I am relatively new to Apache Camel, and IBM MQ, so any input would be very appreciated. Thank you in advance!
In your application, just provide the name of your ReplyToQ as replyToQ1 and leave the ReplyToQMgr field blank. The queue manager will fill it in with the local queue manager name QMGR_LOC for you.
And on QMGR_REC do one of the following:-
If your transmission queue for the channel from QMGR_REM to QMGR_LOC is named exactly QMGR_LOC, you have nothing further to do. When QMGR_REM comes to put the COA onto queue replyToQ1 on queue manager QMGR_LOC, it will resolve it to the transmission queue that has the name QMGR_LOC and the channel will deliver it.
If your transmission queue for the channel from QMGR_REM to QMGR_LOC is not named exactly QMGR_LOC, then make the following definition on QMGR_REM:
DEFINE QREMOTE(QMGR_LOC) RNAME(' ') RQMNAME(QMGR_LOC) +
XMITQ(your-transmission-queue-going-to-QMGR_LOC)
So, basically by trial and error I figured out that adding mdWriteEnabled=true property onCamelJmsDestinationName Camel header made it working as I need.
The code is something like this:
route.setHeader("CamelJmsDestinationName", "queue:///msg_q1?targetClient=1&mdWriteEnabled=true")
Then I set reply-to queue manager via MQMD property
route.setHeader("JMS_IBM_MQMD_ReplyToQMgr", "QMGR_REM")
and reply-to queue
route.setHeader("JMSReplyTo", "replyToQ2")
I have sent the message attribute to AWS sqs along with body using Apache camel below command
to("aws-sqs://{{queue.name}}?amazonSQSClient=#sqsClient&attributeNames=#systemName")
Message sent successfully. Now i want to retrieve the the message attribute systemName using Camel DSL java. But not able to retrieve it. CamelAwsSqsAttributes and CamelAwsSqsMessageAttributes both are coming blank in the header. Below are the code of Consumer
Main main = new Main();
main.bind("sqsAttributeNames", Collections.singletonList("All"));
main.bind("sqsMessageAttributeNames", Collections.singletonList("All"));
from("aws-sqs://a{{queue.name}}?" +
"amazonSQSClient=#sqsClient&attributeNames=#sqsAttributeNames&messageAttributeNames=#sqsMessageAttributeNames")
.log("We have a failed request message in queue ${headers}")
Can someone please help me on this??
The config looks okay, except the Collection should be replaced by comma-separated Strings (make sure there are no space between the Strings).
Also, please mention the attributes that you want. All may not work.
Main main = new Main();
main.bind("sqsAttributeNames", "Attr1,Attr2");
main.bind("sqsMessageAttributeNames", "Attr1,Attr2");
Please follow latest Camel-SQS-Component.
Can anyone please help me in retrieving message headers from the message coming from Websphere IBM MQ ?
We are using JMS OnMessage method to browse the MQ and the type of message received from MQ is "BytesMessage". We want to iterate through the RFH message headers and collect them.
We have tried using MQHeaders to iterate over the MQMessage but could not as it was throwing an exception.
Please advice me.
a good place to start reading is https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q031990_.htm which explains how IBM MQ implements JMS.
Next you should print out your received JMS Message with toString() or iterate through your properties and check the properties you receive. Depending on RFH or RFH2 you will see different fields.
You can find explanations for these fields in https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q032000_.htm
and https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q032060_.htm
I am using a multicast in Camel DSL because I need to send a copy of the same message to two different endpoints. However, it seems that the routes are interfering with each other. Have I got the syntax wrong, or some other issue?
from("{{in.endpoint}}")
.routeId(this.getClass().getSimpleName())
.multicast().parallelProcessing()
.to("{{update.in}}", "{{add.ibmmq.topic}});
where
in.endpoint = seda:addOrder?waitForTaskToComplete=Never
update.in = seda:updateData?waitForTaskToComplete=Never
add.ibmmq.topic = an ibmmq topic
I expect the 'update' route to receive the 'in' message, and the 'ibmmq topic' to receive the same message, presumably cloned. However, in the logs I am getting exceptions like:
Exchange[
Id ID-slon12d10628-1228-1386074869307-0-44746
ExchangePattern InOnly
Headers {breadcrumbId=ID-slon12d10628-1228-1386074869307-0-41682, calendar=null, CamelMyBatisResult=[integration.model.EInquiry#19eb77c, integration.model.EInquiry#12059ce, xxxxxxx
BodyType message.BulkAddOrderMsg
Body message.BulkAddBondOrderMsg#77df22
]
but the EInquiry objects are read in by a completely separate route, nothing to do with this route except it, too, sends messages to 'in.endpoint'.
The other thing is because I read from Tibco and send to IBMMQ, I have to clear the JMS header codes because they are not compatible, so I have put:
exchange.getIn().getHeaders().clear();
in my 'update' route. Could this be clearing Camel's exchange tracing headers and causing this issue, basically like some weird concurrency issue?
Its hard to find the error without full source code, but bear in mind that multicast does not do deep copy.
If you have child objects in the Order object they are not duplicated and they are shared between both SEDA routes.
Probably you will have to make a custom deep clone of the object
The body of your Exchange is a custom POJO: message.BulkAddBondOrderMsg#77df22... which means there is no deep cloning available unless you add it. Same thing would happen if the body were DOM XML node...
Serialize the POJO to a String prior to the multicast so it can be shared across Exchanges.
Suppose both reply and request are being sent to the same topic, and now I'm subscribed to it. How do I identify which of them is which?
Try setting message property on the messages which you publish to the topic. You set a string property on each message, e.g. message_type=”request” or message_type=”response”. When you consume the message on the listener you can read the property to identify if the message is request or response.
Another way of doing it is by starting two listeners with message selector properties. One which will only consume messages with message_type property as “request” and another which will only consume messages with message_type property as “response”.
There is an easy way too: The request comes in first, so I can check for a smaller timestep than the response. Which will identify it as the request.