| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to propagate asynchronous messages between WMQI nodes ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Irena |
 Posted: Mon Feb 04, 2002 10:18 am Post subject: |
 |
|
Novice
Joined: 03 Feb 2002
Posts: 11
Location: IBM
|
| Our plugin node can not propagate messages within the "evaluate" function, because it produces messages in the asynchronous mode. Since "propagate" may be called only from the evaluate function, we have a problem how to put our messages to the output terminal at the moment they are ready. Does anybody has any experience with propagation of asynchronous messages within the synchronous WMQI environment ? |
|
| Back to top |
|
 |
| mpuetz |
| Posted: Tue Feb 05, 2002 8:50 am Post subject: |
|
|
Centurion
Joined: 05 Jul 2001
Posts: 149
Location: IBM/Central WebSphere Services
|
Hi Irena,
when you say 'prograte when they are ready',
do you mean that you want to start a thread
within MQSI which then triggers a message
at some later stage, i.e. if the flow for
the initial message already finished ?
If that is what you are trying to do, this
absolutely not supported in the MQSI programming
model. You are violating your support warranty
doing such things.
MQSI flows are meant to be synchronous,
uninterrruptable units of work. Full stop.
So in this case you should rather implement your plugin
as an MQ application or an external MQ adapter for an
application which reads from a queue,
does its job (however long it may take) and
post the result to another queue which may
then in turn be the input for another MQSI flow.
Maybe I misunderstood your intention, so please
be more elaborate about what you are trying to
accomplish.
You may also have a look at the design of
the fan-out and aggregation nodes, which
may give you an idea to circumvent problems
with the MQSI programming paradigms.
_________________
Mathias Puetz
IBM/Central WebSphere Services
MQ/WMQI Specialist
[ This Message was edited by: mpuetz on 2002-02-05 08:53 ] |
|
| Back to top |
|
|
| Irena |
| Posted: Tue Feb 05, 2002 11:16 am Post subject: |
|
|
Novice
Joined: 03 Feb 2002
Posts: 11
Location: IBM
|
Mathias,
As usual, you exactly catch the point.
Our node has a separate thread which makes rather complex analysis of incoming messages and produces output, based on its internal logic and temporal rules. I.e., the node output is a result of processing of a number of input messages (there may be lots of possible input message combinations), thus, we can not propagate it within the context of one specific input message.
We can not be a pure MQ application since our goal is to add our functionality on the WMQI level in the form of a node which can be used in different message flows (for complex message analysis).
We already implemented a "quick & dirty" solution, where our "output" thread writes its messages into the corresponding queue using JMS interface.
But we understand that doing so we mix MQ and MQSI message protocols, the behaviour which is probably "not allowed" to a pure MQSI node.
We looked at the Aggregate nodes architecture as well, but it does not seem to solve our problem "as is". However, maybe a similar approach would work:
- use the "node" part for properties configuration via customizer and getting input messages from other nodes in the "input" flow;
- use "MQ daemon" part for message processing & asynchronous write into the queue, used in the "output" flow;
- transfer messages from the first part to the second part via some interprocess protocol.
Is this approach more "politically correct" than mixing MQSI node & MQ client ?
Thank you,
Irena. |
|
| Back to top |
|
|
| mpuetz |
| Posted: Thu Feb 07, 2002 9:36 am Post subject: |
|
|
Centurion
Joined: 05 Jul 2001
Posts: 149
Location: IBM/Central WebSphere Services
|
Irena,
as far as I understand you, the aggregation node paradigm
may well be suitable for you.
Maybe consider this:
As I understand it you have to wait for a couple of messages
(their number may vary) before you can complete the final
result message. In order to get rid of the "daemon" you
should use database persistence. I.e. when a new message
enters your node, you check you database whether you have
enough enough info for completion. At this point you start
your heavy-weight calculation, return the result through
your standard output terminal which can then be connected
to a MQ output node (or do some further transformation and
processing).From all previous messages you simply store the relevant
information in a database and don't propagate a message,
i.e. effectively terminating that branch of the flow.
This you stay within the programming model of MQSI, but
you have to use database persistence between partial steps.
This is exactly what the same way the aggregate node solves
this.
_________________
Mathias Puetz
IBM/Central WebSphere Services
WebSphere Business Integration Specialist |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Feb 08, 2002 1:03 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If you want to issue a MQ message during a flow OUTSIDE of the unit of work then you can use the MQPUT plug-in node (support pac).
In our application we actually issue a MQPUT and MQGET outside the unit of work to call another application. I know this is not a recommended design but the designers were insistent on a single UOW in the flow. We coded a C node.
Normally you should end a flow when putting a message, and start a new flow when the reply comes back. You can store state data in the message or use a database if needed. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
