What does *DTAQ mean to a Camel?
If you ever worked with an AS/400 system (aka iSeries, System i, IBM i on IBM Power Systems, ...), you probably know what a *DTAQ is all about. For those that don't: a data queue is a native object on the AS/400 that allow you to set up fast and asynchronous communication between jobs and machines.
Apache Camel now has a component to support AS/400 data queues. An example: to read a message of a data queue named REQUESTS in library ERP and send it to RESPONSES queue, all you have to code is
Moving messages from one queue to the other isn't that spectacular, but you can just as easily replace the to uri to send the message using FTP, HTTP, mail or use any of the other components available in Camel.
It's time to start leveraging all the good code that is available on AS/400 systems all over the world and make that ride the Camel too.
Apache Camel now has a component to support AS/400 data queues. An example: to read a message of a data queue named REQUESTS in library ERP and send it to RESPONSES queue, all you have to code is
<route>
<from uri="jt400://myuser:secretpwd@as400_host/qsys.lib/erp.lib/requests.dtaq"/>
<to uri="jt400://myuser:secretpwd@as400_host/qsys.lib/erp.lib/responses.dtaq"/>
</route>
Moving messages from one queue to the other isn't that spectacular, but you can just as easily replace the to uri to send the message using FTP, HTTP, mail or use any of the other components available in Camel.
It's time to start leveraging all the good code that is available on AS/400 systems all over the world and make that ride the Camel too.
Labels: Camel
posted by Gert Vanthienen at
6:58 AM
2 Comments:
Hi Gert,
does this mean I can read out any IBM MQSeries queue and if yes, how can one retrieve the dtaq uri of a queue?
Also what does it mean with transaction handling and destructive / non-destructive getting?
Regards
Lars
By
Ano, At
September 11, 2008 at 8:34 AM
Hi Lars,
A data queue is a very lightweight async messaging solution, which is available for free on the AS/400 system. It doesn't have all the features of the full-blown WebSphere MQ broker (which does require license fees).
However... a very similar solution also exists for JMS queues. Instead of using the jt/400 component you'll use Camel's JMS component.
Step 1: register the WebSphere MQ ConnectionFactory with the Camel JMS component (cfr. Configuring different JMS providers) and give the bean an id (let's say 'wmq').
Step 2:Create a route that starts with
<from uri="wmq:queue:name.of.the.queue"> and add any parameters mentioned in the JMS component doc page to add transactions, retry, recovery, acknowledgment mode, ...
Regards,
Gert
By
Gert Vanthienen, At
September 11, 2008 at 8:47 PM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home