| Author |
Message
|
| AkaiRyujin |
 Posted: Tue Mar 06, 2012 11:04 am Post subject: Propagating routing slip in MQRFH2 usr folder |
 |
|
Newbie
Joined: 06 Mar 2012
Posts: 7
|
Hi,
We currently have various flows which make use of the routing slip pattern to vary how a message gets propagated between the flows.
At present these flows use a separate queue to pass context data; in most cases just the routing slip.
However I am toying with the idea of moving the routing slip into the MQRFH2 header's usr folder; allowing the routing slip to propagate along with the message.
I have tested with a dummy flow which performs the following,
| Code: |
CREATE COMPUTE MODULE SimplerRoutingSlip_CalculateRouting
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
-- Copy all headers / body to Output
SET OutputRoot = InputRoot;
-- Determine if we have already defined the routing slip
IF FIELDTYPE(InputRoot.MQRFH2) IS NOT NULL THEN
-- Set destination queue to next target
SET OutputLocalEnvironment.Destination.MQ.DestinationData.queueName = InputRoot.MQRFH2.usr.DestinationData.Destination;
-- Remove target from routing slip
SET OutputRoot.MQRFH2.usr.DestinationData.Destination = NULL;
ELSE
-- Create MQMD
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';
SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
SET OutputRoot.MQMD.Format = MQFMT_RF_HEADER_2;
-- Create MQRFH2
CREATE NEXTSIBLING OF OutputRoot.MQMD DOMAIN 'MQRFH2';
SET OutputRoot.MQRFH2.(MQRFH2.Field)Version = MQRFH_VERSION_2;
SET OutputRoot.MQRFH2.(MQRFH2.Field)Format = MQFMT_STRING;
-- Create routing slip
SET OutputRoot.MQRFH2.usr.DestinationData.Destination[] = LIST { 'DUMMY_B', 'DUMMY_C' };
SET OutputRoot.MQRFH2.usr.RequestIdentifier = InputLocalEnvironment.Destination.HTTP.RequestIdentifier;
-- Set destination queue to first target
SET OutputLocalEnvironment.Destination.MQ.DestinationData.queueName = 'DUMMY_A';
END IF;
RETURN TRUE;
END;
END MODULE;
|
And this happily succeeds (MB 7.0.0.2 / MQ 7.0.1.5).
The question therefore is; is this sane or am I abusing the MQRFH2 header?
Any advice greatly appreciated,
Bob
- A mad programmer in an otherwise sane world |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Mar 06, 2012 11:08 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
You can use the RFH2 header for whatever you like, as long as all senders and receivers agree on it. What we've been doing lately is putting such metadata in an XML structure. So we have two parts to the payload, a metadata part and the original payload. Since the content is validatable against an XSD, this solves the problems of having the sender be out-of-sync with the receiver.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 06, 2012 11:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You should completely ignore the fact that Broker v7 still calls this the MQRFH2.
You should think only and exclusively of Message Properties.
Broker will end up writing these onto an MQ v7 and later queue as message properties, anyway, unless you go out of your way to configure the queues to force an RFH2.
NEVER THINK OF MQRFH2 AFTER V6. IT'S NOT AN MQRFH2 any more. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Mar 06, 2012 7:43 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
MQRFH2 is/was known to be the "JMS"-Header. What happened (to MQRFH2 and/or JMS)? I liked it to put trees/xml into the user-container "usr". There wasnt/isnt anything like that on MQMD (is MQMD fixed length btw ?!).
I fear that properties means "name value pairs" (there is an idea like that in JMS, I remember). Allowing tree/xml structure is better.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 07, 2012 2:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| I fear that properties means "name value pairs" (there is an idea like that in JMS, I remember). Allowing tree/xml structure is better. |
It's nice that you think this is better. I might even agree that it would be better.
This doesn't change how the product functions. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Mar 07, 2012 2:43 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| mqjeff wrote: |
| It's nice that you think this is better. I might even agree that it would be better. |
So I am right on (my assumtion) and IBM just closed the gap here. (tree/xml) wasn't ever meant to be in the usr ?!
And right, probably there are good reasons to close options (compatibility with JMS ?!). Thank you for your input mqjeff.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| AkaiRyujin |
| Posted: Wed Mar 07, 2012 3:10 am Post subject: |
|
|
Newbie
Joined: 06 Mar 2012
Posts: 7
|
Attaching "user-data" to the Properties folder seems, unless I am missing something, impossible.
Once the message properties is finalised any custom NameValue pairs added to the header are dropped - not unexpected if the Properties folder has and expects a fixed format.
I was trying to avoid wrapping all our message data into a Metadata/Payload; especially as not all of our messages are XML based - don't want to start storing BLOB data in an XML field; and for a sequence of about 5/6 queue names would seem to be overkill.
Would seem, given that using the RFH2 usr folder is inconsistent with good-practice for MQ7, that passing a correlated 'Metadata' message, what we're currently doing, is the most appropriate option.
Many thanks for all your advice. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 07, 2012 3:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| mqjeff wrote: |
| It's nice that you think this is better. I might even agree that it would be better. |
So I am right on (my assumtion) |
I did not say you are right.
I said that it didn't matter what your opinion was, the product worked the way the product worked. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Mar 07, 2012 4:14 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
I did it wrong: Using the usr to dumb information + jms... that caused me troubles with JMS-Properties... I was wondering "how shall this work".
In the end I skipped using JMS-Properties.
Good to see that they removed the chance to make mistakes there.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 07, 2012 4:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| Good to see that they removed the chance to make mistakes there. |
I repeat.
I did not say that they changed this.
I said that the product works as documented. |
|
| Back to top |
|
|
| ethan_1988 |
| Posted: Thu Apr 09, 2015 4:36 pm Post subject: |
|
|
Novice
Joined: 07 Feb 2014
Posts: 16
|
Hey I m facing similar issue. I am on a migration from WMB7 to WMB8. The first Flow is receiver flow having SOAP input not and the same flow aggrigate msg to three separate flow. before putting a msg on a queue we create MQRFH2.usr and saving two variable. Code is just like
| Code: |
SET OutputRef.Properties = InputRef.Properties;
SET OutputRef.MQMD.Version = MQMD_CURRENT_VERSION;
SET OutputRef.MQMD.MsgType = MQMT_DATAGRAM;
SET OutputRef.MQMD.Format = MQFMT_RF_HEADER_2;
SET OutputRef.MQRFH2.Version = MQRFH_VERSION_2;
SET OutputRef.MQRFH2.Format = MQFMT_NONE;
SET OutputRef.MQRFH2.usr.temp1 = 'xyz;';
SET OutputRef.MQRFH2.usr.temp2 = 'abc'; |
This works fine in WMB7 but in WMB8 the flow picking msg up from the Q doesnt show MQRFH2. It shows MQMD.Format = SOAPRoot evn in RFHutil shows the same.
I wrote the following one but it gives the similar result. I appriciate any help. Thanks
| Code: |
SET OutputRef.Properties = InputRef.Properties;
SEt OutputRoot.Properties.MessageFormat = '';
SEt OutputRoot.Properties.ReplyIdentifier = '';
SEt OutputRoot.Properties.ReplyProtocol = 'MQ';
SET OutputRef.MQMD.Version = MQMD_CURRENT_VERSION;
SET OutputRef.MQMD.MsgType = MQMT_DATAGRAM;
SET OutputRef.MQMD.Format = MQFMT_RF_HEADER_2;
SET OutputRef.MQRFH2.Version = MQRFH_VERSION_2;
SET OutputRef.MQRFH2.Format = MQFMT_NONE;
SET OutputRoot.MQRFH2.Encoding = InputRoot.Properties.Encoding;
SET OutputRoot.MQRFH2.CodedCharSetId = InputRoot.Properties.CodedCharSetId;
SET OutputRoot.MQRFH2.Flags = 0;
SET OutputRoot.MQRFH2.NameValueCCSID = InputRoot.Properties.CodedCharSetId;
SET OutputRef.MQRFH2.usr.temp1 = 'abc' |
[/code] |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Apr 09, 2015 10:02 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| ethan_1988 wrote: |
| Code: |
SET OutputRef.Properties = InputRef.Properties;
SEt OutputRoot.Properties.MessageFormat = '';
SEt OutputRoot.Properties.ReplyIdentifier = '';
SEt OutputRoot.Properties.ReplyProtocol = 'MQ';
SET OutputRef.MQMD.Version = MQMD_CURRENT_VERSION;
SET OutputRef.MQMD.MsgType = MQMT_DATAGRAM;
SET OutputRef.MQMD.Format = MQFMT_RF_HEADER_2;
SET OutputRef.MQRFH2.Version = MQRFH_VERSION_2;
SET OutputRef.MQRFH2.Format = MQFMT_NONE;
SET OutputRoot.MQRFH2.Encoding = InputRoot.Properties.Encoding;
SET OutputRoot.MQRFH2.CodedCharSetId = InputRoot.Properties.CodedCharSetId;
SET OutputRoot.MQRFH2.Flags = 0;
SET OutputRoot.MQRFH2.NameValueCCSID = InputRoot.Properties.CodedCharSetId;
SET OutputRef.MQRFH2.usr.temp1 = 'abc' |
|
I wonder if you are getting confused between OutputRoot and OutputRef?
Where is OutputRef defined?
My next step would be to put a trace node BEFORE the MQOutput node and look at the message tree but I'm just an MQ
so I know nothing about just about everything.
_________________
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 |
|
|
| ethan_1988 |
| Posted: Fri Apr 10, 2015 5:17 am Post subject: |
|
|
Novice
Joined: 07 Feb 2014
Posts: 16
|
| No I m not confused in the Ref.. The references are defined in the same block referrring to InputRoot and OutputRoot..While playing with the properties and headers i didnt used references to get intellisence properties. I didnt paste it coz its not necesary for them who understand ESQL. |
|
| Back to top |
|
|
| ethan_1988 |
| Posted: Fri Apr 10, 2015 5:20 am Post subject: |
|
|
Novice
Joined: 07 Feb 2014
Posts: 16
|
| and the Trace node surprisingly shows the message as expected with MQRFH2 values!!!!!! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Apr 10, 2015 12:10 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
So if the message tree looks good before the MQOutput what does it look like when it is on the Queue?
Have you looked at it with something like RFHUTIL? If the message is correctly formed then youy should see the params you set in the RFHUTIL tab.
_________________
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 |
|
|
|
|
