When we are using TIBCO BW software to develop our integration or processes it is so normal to integrate these processes with a messaging system. TIBCO BW is main to be integrated with an JMS Message systems (specially TIBCO EMS but any system that is JMS complaint will be suitable for the task. Messaging systems have too many advantages to be included in our processes. A few of them are realiability, asynchonous, persistence, priority…
So, the main goal of this post is not to talk about the advatange of these systems becase I guess all of you embrace them at this point but to talk about one the technical aspects of this JMS systems and it is JMS Selectors.
JMS Selectors is like the where clause analogy to a JMS receiver connection. Usually when we established a input connection to a queue we get all the messages for that queue and that’s ok. We are going to be processing these messages as quick as we can. But, what happen is there are messages that are not for us but for other system or app? “No problem” you could think, I use a filter in our process so if the message don’t match with my interface I return it to another queue so the other system could read it from there, and that’s OK, but that is like we are doing so much work for a message that we don’t want.
It’s like if you are quering a database you say: “Ok, no problem I do a full select and then I filtered the rows that I want and discard the rest”. No, you don’t do this kind of statements. Simple, It doesn’t make sense. So, here is the same.
If you use a shared queue between processes or application you should consider including a Message Selector in your JMS input connection. And I was saying before it’s very similar to a WHERE clause in a SQL sentence. So similarities that the syntax it is the same because the JMS selectors use SQL92 to specify them and we can specify a condition about any JMS property we want (standard or event a custom one).
There are some JMS Properties that are mandatory when you send a message to a queue:
Real Use-Case Scenario
Ok, so we are going to define a real use case and see how this things could be done inside our TIBCO BusinessWorks 5.x software.
The use case description is this: “We have a queue that are receiving so many messages form diferente application and we want to recover the messages between a specific time-range and write their contents into a text file.
Ok, we have two different approaches to do that depending on the usage-type of your processes. It is going to be a on-demand process or a daemon? Ok, first of all we are going to assume that is going to be an on-demand process. So we defined a new TIBCO BW process with and start and end activity and We defined our input interface only with two fields: StartDate and EndDate so we can define the time range to the activity.
After that, we use a JMS Get Message Queue activity that have as an input parameter the “message selector”, and we create using the mapping editor the clause similar to this: JMSTimestamp > to_milliseconds(start_date) AND JMSTimestamp < to_milliseconds(end_date).
The first problem there is the date-time format and treatment. We don’t have as an OOTB mapping function the capability to get the miliseconds from a specific date/time object (We could get the miliseconds for the current moment using the timestamp() function but that’s it) so we have to create a Java custom function to be added this capability (We are going to explain how to do that in another post, so don’t worry about it for now).
And that’s it. The rest of the process is to easy for a normal BW developer: We have a grouped activities that include the get message and the write to file, and we specify that the group iterates forever until a exception is raised and we configure the JMS Get Message activity to raise an exception when a specific timeout is reached. We place a Catch Activity to finish the process in a normal way and that’s it!
This is only an example the thing you could do with JMS selectors but you could get so much of it if you work this custom JMS properties. You could use a JMS properties like TargetApplication and get diferent applications reading data of that queue and getting only the messages that are targeting to them.
If your approach is more like a daemon process you should be aware of that the JMS Queue Input Receiver as well as the JMS Topic Suscriber activities has the capability to specify a selector. The main diference with our approach is that this property only could be dynamic at deployment time and not at runtime level as we could do in our example, but the feature is there too.
Source code available
As always I want to share the source code with you, so the could is published in our github repository so feel free to take a look to the code and please give us feedback about what you think about all of this!