Is it possible to do content-based filter with JMS?
IBM MQ publish/subscribe seem to allow content-base filtering
https://www.ibm.com/support/knowledgecenter/en/SSKM8N_8.0.0/com.ibm.etools.mft.doc/bq13460_.htm
https://www.ibm.com/support/knowledgecenter/en/SSKM8N_8.0.0/com.ibm.etools.mft.doc/bq13360_.htm
I've tried to find a way with my JMSListener to filter on a Body elment but I couldn't manage to make it work..
IBM MQ can not directly filter based on the body, only based on message properties. IBM states that a extended message selection provider can do message selection based on the message payload, but as far as I know the only extended message selection provider available is ACE/IIB/WMB.
Please review IBM Knowledge Center page IBM MQ 9.1.x>IBM MQ>Developing applications>Developing JMS and Java applications>Using IBM MQ classes for JMS>Writing IBM MQ classes for JMS applications>JMS messages>Message selectors in JMS:
A property value might duplicate a value in a message body. JMS does not define a policy for what might be made into a property. However, application developers must be aware that JMS providers probably handle data in a message body more efficiently than data in message properties. For best performance, applications must use message properties only when they need to customize a message header. The primary reason for doing this is to support customized message selection.
A JMS message selector allows a client to specify the messages that it is interested in by using the message header. Only messages with headers that match the selector are delivered.
Message selectors cannot refer to message body values.
A message selector matches a message when the selector evaluates to true when the message header field and property values are substituted for their corresponding identifiers in the selector.
A message selector is a String, with syntax that is based on a subset of the SQL92 conditional expression syntax. The order in which a message selector is evaluated is from left to right within a precedence level. You can use parentheses to change this order. Predefined selector literals and operator names are written here in uppercase; however, they are not case-sensitive.
Please also review IBM Knowledge Center page IBM MQ 9.0.x>IBM MQ>Developing applications>Application development concepts>IBM MQ messages>Selecting messages from queues>Selecting on the content of a message
It is possible to subscribe based on a selection of message payload content (also known as content filtering), but the decision about which messages should be delivered to such a subscription cannot be performed directly by IBM® MQ; instead an extended message selection provider, for example IBM Integration Bus, is required to process the messages.
Related
I am working on receiving mails in my springboot application. In order to fetch and store the receive mails. I am using imap mail listener. There are two types of mails which I am storing. One is multipart payload type and the other is string payload type.
After receiving mail I am trying to send an auto-generated mails using java mail.
The issue which I am facing is worst case scenario of generating auto-reply from my application i.e infinite loop.
Can someone help ow can I differentiate between a normal mail received and auto-reply received in my mail box and generate auto-replies from my system only for those mails which are not auto-reply type.
It would be nice if explained via code for headers check. I came across through few headers like x-Autosubmitted. But they are returning null if I am trying to print the values in console.
The auto-submmitted markers are described below that you may find helpful:
auto-generated - Indicates that a message was generated by an automatic process, and is not a direct response to another message.
auto-replied - Indicates that a message was automatically generated as a direct response to another message.
auto-notified - Indicates that a message was generated by a Sieve notification system.
no - Indicates that a message was NOT automatically generated, but was created by a human. It is the equivalent to the absence of an Auto-Submitted header altogether.
The RFC 2822 states the following:
Though optional, every message SHOULD have a "Message-ID:" field.
Furthermore, reply messages SHOULD have "In-Reply-To:"
So, you may check for the "In-Reply-To:" value in the header.
Also you may add your own value to the outgoing email, so you may distinguish between an automatically generated reply from your system and manually created.
I am getting the following error when I try to do a Fan-In using aggregate node in IBM integration bus.
( T24_Integ_Node.default ) The Aggregation Reply node has received a reply message which has a blank reply ID: ''.
This is not allowed because the reply ID is needed so that a reply message can be matched to the original request message. If you are using WebSphere MQ to send and receive aggregation requests, the reply ID must be stored in the correlation identifier (CorrelId) field of the message descriptor (MQMD) and it must be set to the value of the message ID in the request message's MQMD
The message flow is like below:
FILE<1> -->AggregateControl<1>-->FAN-OUT-COMPUTE-NODES<1,2,3> -->FILE-OUTPUT-NODES<1,2,3> --> AGGREGATE-REQUEST-NODES<1,2,3> --> AGGREGATE-REPLY-NODE<1> --> FAN-IN-COMPUTE-NODE<1> --> FILE-OUTPUT-NODE<1>
Please note I am not using MQ nodes
Kindly suggest.
What you are attempting will not work because you are not using a request/reply protocol on the inside of the aggregation. As stated in the Knowledge Center article at this link, "The aggregation nodes work correctly only for transports that use a request/reply model", and writing to and reading from files does not fulfill that requirement. Some nodes that do fulfill this requirement are the MQ nodes, the SOAP Asynchronous nodes, and the HTTP Asynchronous nodes. Additionally, you need to use an AggregateControl node to mark the start of the fan-out, and I do not see an AggregateControl node in your flow sketch.
I suspect that you want to submit files to an external application(s), have that application(s)'s instances run independently and in parallel, receive response files, then group the response files based upon a flag(s) in the files' names or in the files' content. If so, use the Collector node.
An alternative would be to use the aggregation nodes with MQ nodes inside of the aggregation, with these MQ nodes feeding an intermediate flow that changed the fan-out protocol from MQ to file, then conversely, the fan-in protocol from file to MQ. See IIB's web services aggregation sample for an example of this technique.
I am currently writing an application in java using the the JAIN SIP library, I've been trying for the past couple of days to implement presence using SUBSCRIBE and NOTIFY messages. I currently have NOTIFY messages which has a content type of "message/sipfrag;version=2.0", and need this to be XML and PIDF.
I'm aware I need to use an event header with "presence", and also a content type header.
Are there any places I can go to where there is information on this or are there any other specific headers or classes and/or methods needed to make this work? I already have a client which I can make calls on, but need to implement presence now.
FYI, rfc3863 only defines the basic structure/semantics of a presence document. PIDF establishes a rudimentary presence document to be a status - with optional contact info, and other info (defined per the PIDF schema). PIDF does not really prescribe presence protocol. For those you need to review [RFC3265][1] and the details of the presence event package [RFC3856][2]. If we stick to a non-IMS network, the usual call-flow involves:
SIP registration to the SIP/REGISTRAR user-agent-server (UAS) accessible to the client. This also establishes the presence-entities (presentity) AoR (Address of Record) - who you are and how you can be reached - i.e. assuming you want to be contacted.
SIP:PUBLISH - with 3 very key parts. Firstly, an 'Event' header indicating support for the presence package, the content-type appropriately set to PIDF MIME-type and the correct body.
PUBLISH sip:bob#example.org SIP/2.0
...
Event: presence
Content-type: application/pidf+xml
Content-length: xyz
open
Once you have successfully published, you can then try a SUBSCRIBE method - to try and obtain status of another presence entity (e.g. user jane#example.org). For a SIP SUBSCRIBE the minimal is defining an appropriate presentities SIP/URI and specifying the correct 'event-package'. Look closely at the indicated RFCs - 3265 / 3856 will help guide you on basic behavior.
Best of luck.
[1]: https://www.rfc-editor.org/rfc/rfc3265#section-4
[2]: https://www.rfc-editor.org/rfc/rfc3856#section-5
There is more than one way to do presence in SIP. If you are sure PIDF is used then you should just use the RFC as reference https://www.ietf.org/rfc/rfc3863.txt. JSIP will work just fine as far as the SIP headers go, it will construct and parse the SIP messages correctly. The actual SIP message content parsing/construction is responsibility of the app. Jitsi is an open source client that has presence if you want to peek at some example code, but it may be totally different from your case.
I'm trying to understand why serialized objects are being stripped out when received.
Here is the general layout :
1. Produce JMS messages and send to a topic on an external ActiveMQ broker. The code is based off the Spring boot JMS message and can be viewed at http://bit.ly/QECQ21 . In my example, I generate various types of messages (text , POJO, Map)
2. I have 2 JMS consumers that subscribe to this topic.
a. One is a java client. This client correctly identifies all the various message types.
b. The 2nd client is a javascript client based on websockets + stomp.js . This correctly identifies text messages but not messages that contain POJOs generated by my producer.
Here is the sample output from the web client (source at http://bit.ly/Od0noF ) .
What am I doing wrong? Something wrong with the the addressing or something else in the code? Something about the way I'm using (or misusing) STOMP? I had to use "tcp://localhost:61616" in the Application.java class to correctly contact the broker.
Thanks
MESSAGE priority:4 persistent:true subscription:sub-0 expires:0 timestamp:1396418227090 destination:/topic/greetings message-id:ID:blackbox-53461-1396418226684-1:1:2:1:1 content-length:4 ping
Body:ping
MESSAGE priority:4 persistent:true subscription:sub-0 expires:0 timestamp:1396418227117 destination:/topic/greetings message-id:ID:blackbox-53461-1396418226684-1:1:2:1:2
Body: ======> missing body
MESSAGE priority:4 persistent:true subscription:sub-0 expires:0 timestamp:1396418227122 destination:/topic/greetings message-id:ID:blackbox-53461-1396418226684-1:1:2:1:3
Body: ======> missing body
MESSAGE priority:4 persistent:true subscription:sub-0 expires:0 timestamp:1396418227125 destination:/topic/greetings message-id:ID:blackbox-53461-1396418226684-1:1:2:1:4 content-length:5 close
Body:close
No answers yet so I'll add my findings. STOMP is a text based protocol and as such the body needs to be converted to a text format (such as JSON). In my case, this can be done using the spring websockets framework (which internally uses Jackson) or by explicitly coding the object into JSON using Jackson and them transmitting as a text message
After checking out mq series docs and white paper I have got the architecture for MQ messages ie Message descriptor (Message header)
Application data (Message body) and its details here
But I want to know what is the format (xml,binary,text...) in which quemanager of MQ series stores the messages.
The format of the payload is decided by the application, not MQ. You can send messages in whatever format you want. As mentioned in the developersWorks article, MQ has some predefined formats such MQFMT_STRING which means the format of the payload is text. This format is typically used for XML, text message body. These are the predefined list of message formats.