2

Why is queue to queue transfer not supported in MQFTE Monitors ? I have set an monitor for a queue and when any message is dropped in the queue , a transfer from queue to queue must be triggered. But MQFTE doesnt have this option. Is there any other alternative ?

trilawney
  • 1,786
  • 6
  • 28
  • 36
  • I'm not sure I understand the question. Native MQ is designed to do queue to queue transfers. FTE will do queue to file or file to queue or file to file. The question sounds like you want FTE to do what WMQ does natively. Can you update the question with a little more explanation of what you are trying to do? Also, a question about a vendors motives ("why is it like this") has no "right" answer so a moderator would probably close or delete the question. You might want to reword as "How do I configure FTE to do..." – T.Rob Dec 02 '11 at 14:39
  • Whoops - you are correct, it isn't supported. I've deleted my answer. But, I still don't understand the use case. Since WMQ moves queue to queue natively, why would you use FTE agents to do this? – T.Rob Dec 14 '11 at 13:54
  • I am using a monitor for this specific use case. When a particular message is dropped in a queue , a queue to queue transfer must be triggered. – trilawney Dec 15 '11 at 11:41
  • To be more elaborate. I have a queue which should be monitored. When a message is dropped in that queue , a set of transfers must be triggered (Using add to group option). In this set of transfers there are some file to file, queue to file , file to queue and queue to queue. So this is the use case. – trilawney Dec 15 '11 at 11:50

1 Answers1

1

I can't really answer the questions as written - i.e. "why" it works the way it does. I can only speculate that because FTE is written to move files there are file name metadata and semantics in the queue-to-file and file-to-queue that don't make sense in queue-to-queue.

What you can do though is write up your use case in detail and submit a formal requirement. Then at least you have a chance to see that functionality in a future release.

In the meantime what you are doing sounds like a job for triggering. WMQ has the ability to fire an external process on the arrival of a message. Given your requirements, I'd trigger an ANT job to initiate the transfer when the message arrives on the queue. If the queue-to-queue transfer needs to be recorded in the FTE logs then the processing flow would be something like this:

  1. Message arrives on the queue
  2. Trigger monitor starts job
  3. Job browses message on the queue
  4. Job passes message ID to an ANT task
  5. ANT task moves files.
  6. A pre- or post- transfer task uses SupportPac MA01 to move the message in the queue based on MsgID.
  7. Triggered program loops over any messages in the queue and initiates a separate ANT task for each until the queue is empty.

If the queue-to-queue transfer doesn't need to be recorded in the FTE logs, the flow would be similar except that the triggered job would consume the message and move it straight away instead of passing it to the ANT task.

T.Rob
  • 31,522
  • 9
  • 59
  • 103