| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Additional folder on OutputRoot |
« View previous topic :: View next topic » |
| Author |
Message
|
| goffinf |
 Posted: Sat Jan 14, 2012 8:16 am Post subject: Additional folder on OutputRoot |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
I was experimenting today adding a folder and some content to OutputRoot and then sending that message out thru an MQOUtput node.
Actually I was trying to see if I could construct a message similar to that provided by the EmailInput node in Message Broker version 8. We currently use v6.1 but will be moving in that direction at some point and, since we have need of a flow that accepts emails NOW I wanted to see if I could prepare the way for when we make the switch. Anyway the v8 EMailInputNode outputs an EmailInputHeader structure as an immediate child of OutputRoot :-
Root
- std folders
- EmailInputHeader
To
From
ReplyTo
Subject
Size
SentDate
- MIME
....
In my test flow I had no problem creating and populating EmailInputHeader BUT, when I sent the message out thru the MQOutput node it was NOT present in the message on the queue (its still there after the MQOutput).
I suspect this behaviour is as expected, but I just wanted to make sure.
Can anyone confirm whether you can send out an arbitrary folder like this and expect them to appear in the MQ message, or is that not possible ?
Cheers
Fraser |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sat Jan 14, 2012 10:52 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
MQ can have a number of different headers before the actual payload.
The MQ spec allows for them to be daisychained together.
In most cases, the most you need is
MQMD
One Optional header . eg MQRFH2
Data Payload.
The MQMD.Format value tells MQ what the next header is. In this case, the RFH2 Header.
The RFH2.Format value tells MQ what the next header is. (see a pattern here?). In this case, it is MQSTR. That tell MQ that the next 'thing' is the actual data.
So in your case, you can add your custom headers but you are going to 'fool' mq into accepting them. You won't be able to use a Header (aka a Broker Folder like an EmailHeader) as such.
You may have to serialize the data and the custome header then concantenate them together.
I am sure there are many other ways but my advice would be to look at the various MQ Headers and go from there.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| goffinf |
| Posted: Sat Jan 14, 2012 11:43 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Thanks for your advice. I had considered using the MQRFH2 usr folder to pass these as simple name/values, and I still might yet. At present I am sending them as an XML structure in the first part of the multipart MIME message.
Both of these approaches work, but both require me to add a bit of code to take them from either location and put them in some standard place and/or maybe provide some standards ESQL accessor functions. No big deal I know I was just trying to be greedy and do it all in my EmailInput flow so that the message that turns up in the flow that wants to consume the emails has a starting point the same as the v8 EmailInput node.
Actually the more I consider the accessor functions the more I think that is the way to go since then it makes the location of the email input header data transparent and thus if in the future we use a different approach, the impact will be minimal.
I think I'll go for usr folder values and a few bits of ESQL to get at them.
Thanks for prompting me to work thru this one.
Fraser. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Jan 14, 2012 1:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In MQ v7, you will find that any MQRFh2 headers are mapped into message properties instead.
In broker v7, at least, you will find that you still have to write code that pretends they are set in the MQRFH2. |
|
| 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
|
|
|
|
