Author |
Message
|
ayanc |
Posted: Wed Oct 17, 2007 2:26 pm Post subject: MB 6 - Publish Multiple Topics using PROPAGATE |
|
|
Voyager
Joined: 15 Nov 2004 Posts: 88
|
Hi,
I have an input message that needs to be sent to a list of destinations. I am not using a destination list as the destinations may increase which will necessitate change of code. So, I decided to publish the message under different topics qualified by the destination name.
I am using a WHILE loop and simple PROPAGATE statement to publish the messages.
The scenario is as follows:
Input Msg --> Generic Pub Flow --Topic A --> Publication Flow --Multiple Topics--> Multiple flows
I have tested the flow in 3 different environments with different results!!!
My test input message contains only two destinations.
Environment 1:
Local Machine - Windows XP. Full MB 6 set up. Toolkit 6.0.2 and Broker and ConfigMgr 6.0.0.1
Result - Working Fine . Two messages are published and they are reaching their respective subscribers correctly.
Environment 2:
Dev Server - Toolkit (local Windows XP machine) 6.0.2, ConfigMgr (Windows 2000 Server) MB 5.0, Broker (SuSe Linux 9) MB 6.0.0.3
Environment 3:
QA Server - Toolkit (local Windows XP machine) 6.0.2, ConfigMgr (Windows 2000 Server) MB 6.0.0.3, Broker (SuSe Linux 9) MB 6.0.0.3
Results for both Environment 2 & 3
First message is being published correctly. The second message is being published against the same topic as the input message topic (Topic A in the above schematic representation). This is causing an infinite loop as the message is again transferred to the Publication flow input node.
Code: |
CALL CopyMessageHeaders();
-- Create and set the MQRFH2 header
SET OutputRoot.MQMD.Format = 'MQHRF2 ';
SET OutputRoot.MQRFH2.(MQRFH2.Field)Version = 2;
SET OutputRoot.MQRFH2.(MQRFH2.Field)Format = 'MQSTR ';
SET OutputRoot.MQRFH2.(MQRFH2.Field)Encoding = InputRoot.MQMD.Encoding;
SET OutputRoot.MQRFH2.(MQRFH2.Field)CodedCharSetId = InputRoot.MQMD.CodedCharSetId;
SET OutputRoot.MQRFH2.(MQRFH2.Field)Flags = 0;
SET OutputRoot.MQRFH2.(MQRFH2.Field)NameValueCCSID = 1208;
SET OutputRoot.MQRFH2.psc.Command = 'Publish';
SET OutputRoot.MQRFH2.psc.Topic = 'Hard Coded String' || CH_RootTag || '/' || UPPER(CH_Destination);
-- Converting message to bitstream
SET OutputRoot.MQRFH2.mcd = NULL;
SET OutputRoot."BLOB"."UnknownParserName" = '';
SET OutputRoot."BLOB"."BLOB" = ASBITSTREAM(REF_InRootTag, OutputRoot.MQMD.Encoding, OutputRoot.MQMD.CodedCharSetId,'','','',FolderBitStream);
|
Now if I modify the code as follows:
Code: |
SET OutputRoot.Properties = InputRoot.Properties;
SET OutputRoot.MQMD = InputRoot.MQMD;
SET OutputRoot.MQMD.Format = MQFMT_RF_HEADER_2;
SET OutputRoot.MQRFH2.(MQRFH2.Field)Version = 2;
SET OutputRoot.MQRFH2.(MQRFH2.Field)Format = MQFMT_STRING;
SET OutputRoot.MQRFH2.psc.Command = 'Publish';
SET OutputRoot.MQRFH2.psc.Topic = 'Hard Coded String' || CH_RootTag || '/' || UPPER(CH_Destination);
SET OutputRoot.XML = InputBody;
|
In this case for environment 3 (not tested in env 2) ... the topic being published is the same as Topic A, but the message is not being sent to the input queue again and hence there is no infinite loop.
I am not sure what is going on. Please do share your ideas on this matter. I am extremely confused as to what is happening here.
Thanks in Advance.
Ayan. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Oct 17, 2007 2:41 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
you might want to look up the propagate command with all its arguments...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Oct 17, 2007 3:02 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
...
I'm really confused by both ayanc's two examples, and by F.J's response.
I'm sure this is just because of that last glass of Sangiovese.
The two pieces of code that ayanc posted are superficially the same, but at the same time structurally very different and built on very different assumptions. And, so, likely, they produce very very different output trees.
Also, I don't see any use of PROPAGATE in here at all.
Thirdly, if ayanc has a documented case of the same ESQL producing different results on different platforms (and, to be clear, the code does not use HARDCODED CCSID and Encodings that may not match the platform deployed to)... then ayanc should open a PMR ... immediately. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Oct 17, 2007 3:20 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
My assumption was just that for whatever reason the multiple calls to publish did not publish the same message with just a different topic. The most likely culprit would have been to omit a parm on the propagate statement...
I (shame on me) did not bother to check his code as I did not see any Propagate statement in it...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
ayanc |
Posted: Wed Oct 17, 2007 3:53 pm Post subject: |
|
|
Voyager
Joined: 15 Nov 2004 Posts: 88
|
Hi Jeff & FJ,
Thanx for your prompt response. I am sorry that I was not able to clarify it in the first place.
Let me elaborate on the code that I have written. The logic for the code is as follows:
-- Start procedure
-- Validate specific input fields
-- Loop over list of destinations
-- IF specific destination
-- Call function to validate some additional fields
-- End if
-- Call procedure to create topic and publish (This procedure code is pasted in my earlier post)
PROPAGATE;
-- Move reference to next destination repeat type name
-- End loop
-- Validate that atleast one destination exists
-- End procedure
Additionally let me mention one more observation. I took a user trace for the flow and have come up with the following observations:
Environment 1:
Neat and clean ... as desired. No anomaly as expected.
Environment 2 & 3:
The topic for the first message is being set. A publication destination is being added (a valid and desired destination) and the message is propagated.
During the creation of topic for the second message, the correct topic is being assigned to OutputRoot.MQRFH2.psc.Topic. A publication destination is being added (the destination this time is the input queue for the publication node itself) and the message is being propagated.
I am as confused as you are Jeff.
FJ ... do you want me to add DELETE DEFAULT and FINALIZE DEFAULT explicitly? As per the trace (and as expected) it is already taking that. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Oct 17, 2007 5:20 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
So, in general, the difference is between Broker 6.0.0.1 and Broker 6.0.0.3 in the different environments? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Oct 17, 2007 6:24 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
jefflowrey wrote: |
So, in general, the difference is between Broker 6.0.0.1 and Broker 6.0.0.3 in the different environments? |
If that is the case the Publish functionality reacts differently. Especially if the message was sent from a qmgr that is not the broker's... I'd say you need to be at least at 6003 if you want to do pub/sub and sleep easy...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
ayanc |
Posted: Wed Oct 17, 2007 6:33 pm Post subject: |
|
|
Voyager
Joined: 15 Nov 2004 Posts: 88
|
Yes the broker versions are different, the platforms are also different (Windows and Linux).
Quote: |
Especially if the message was sent from a qmgr that is not the broker's |
The message is being directly sent to the broker qmgr via RFHUTIL Client.
Quote: |
say you need to be at least at 6003 if you want to do pub/sub and sleep easy |
I would love to ... FJ. However it is the 6001 that is working for me ... and not the 6003.  |
|
Back to top |
|
 |
AkankshA |
Posted: Wed Oct 17, 2007 7:56 pm Post subject: |
|
|
 Grand Master
Joined: 12 Jan 2006 Posts: 1494 Location: Singapore
|
i am sorry but i am still confused with what exectly is the desired output and what are we getting..  plzzzzz explain a lil more..
may be i can also contribute..!
Quote: |
During the creation of topic for the second message, the correct topic is being assigned to OutputRoot.MQRFH2.psc.Topic. |
so we have no issues with the topic field..
Quote: |
A publication destination is being added (the destination this time is the input queue for the publication node itself) and the message is being propagated. |
Are you looking for some other destination...?
i am sorry as these questions might irritate.. but i am lost and am just trying to know what is wrong exactly.... _________________ Cheers |
|
Back to top |
|
 |
ayanc |
Posted: Thu Oct 18, 2007 4:04 am Post subject: |
|
|
Voyager
Joined: 15 Nov 2004 Posts: 88
|
Hi Akanksha,
It is good that you are asking for clarification. Thanx for that.
Let me explain:
There are two aspects to this behaviour and they are as follows:
1. The topic being assigned from the second message onwards
2. The publication destination that the broker adds from the subscribers list.
As per the trace it "seems" that the topic is being assigned correctly because the trace records show it that way. However if I assume that the topic has been correctly assigned, then the publication destination should match with the expected subscriber. However that is not the case here. The publication destination being added is the input queue for this publication flow. This is causing the message to go into an infinite loop as the publication flow is apparently subscribing to its own publications.
Let me explain with an example:
Once again look at the message flow schematic diagram
Input Msg --> Generic Pub Flow --Topic A --> Publication Flow --Multiple Topics--> Multiple flows
Let me assume that Topic A has the following structure: ABC/123/DEF/456/IJK/789
Let the Publication Flow input queue name be VALIDATE.PUB.IN
The queue VALIDATE.PUB.IN is subscribed as ABC/+/DEF/+/IJK/#
The publication flow itself publishes messages in the following format:
ABC/123/PQR/IJK/DEST1 ; ABC/123/PQR/IJK/DEST2; ABC/123/PQR/IJK/DEST3 ... and the downstream subscriber flows are subscribed as ABC/+/PQR/IJK/DEST1; ABC/+/PQR/IJK/DEST2; ABC/+/PQR/IJK/DEST3 ...
Let us assume that the input queue for the subscriber to the second message is GET.DEST.IN
Now as per the trace file from the second message the assignment for the field OutputRoot.MQRFH2.psc.Topic = ABC/123/PQR/IJK/DEST2
Then logically the publication destination must be GET.DEST.IN. However strangely the publication destination is instead VALIDATE.PUB.IN. This is causing an infinite loop.
If I replace the publication node with an output queue, I find the topic assigned in the second message is ABC/123/DEF/456/IJK/789. which is the same as the message input to this publication flow. Some how it is retaining the old topic and overriding the fresh topic assignment.
I have tried deleting the entire MQRFH2 header, setting the topic to NULL before reassignment ... but without any success.
I believe looping through a single input message and reassigning different topics to the same message through a publication node is creating this problem. However it is working in 6001 Windows. I am not sure what is happening in 6003 Linux. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Oct 18, 2007 11:41 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Do you have a getNode in the publication flow? I have seen early on 6.0.0.1 cases where the get result in windows and Unix where different... You may be taking advantage of a flaw that has been plugged in a later release...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
ayanc |
Posted: Thu Oct 18, 2007 12:48 pm Post subject: |
|
|
Voyager
Joined: 15 Nov 2004 Posts: 88
|
Hi FJ,
No we do not have any MQGet Node in the flow.
The types of nodes being used are:
MQInput, Compute, Publication, TryCatch & MQOutput |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Oct 18, 2007 2:51 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
ayanc wrote: |
Hi FJ,
No we do not have any MQGet Node in the flow.
The types of nodes being used are:
MQInput, Compute, Publication, TryCatch & MQOutput |
Have you tried to debug and check exactly why the old topic was retained?
6.02 ifix09 and broker 6.0.0.3 should allow you to debug quite nicely. _________________ MQ & Broker admin |
|
Back to top |
|
 |
ayanc |
Posted: Thu Oct 18, 2007 6:49 pm Post subject: |
|
|
Voyager
Joined: 15 Nov 2004 Posts: 88
|
No we do not have RAC installed yet. Actually we were initially on HP UX. Linux is new and we have migrated our stuff there.
I have asked for the RAC ... but it would be a while before the admin team gets that set up. So, I had no choice but to use User Trace.  |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Oct 18, 2007 8:05 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Trace is nice and it will help you identify the culprit (node).
However only debug will show you exactly where in the compute node your error is...
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|