Author |
Message
|
Sridar |
Posted: Tue Sep 16, 2008 5:33 am Post subject: CopyEntireMessage() |
|
|
Acolyte
Joined: 14 May 2006 Posts: 72 Location: Chennai, India
|
Hi
I want to know if anyone has tried to reference these default procedures CopyMessageHeaders() and CopyEntireMEssage() from a common location?
Should these(one of these) be always declared for each module or
Can we have single declaration for an esql file or
Can we have a single decalration for the entire MessageFlow or Project.
The contents of the procedure is going to be the same wherever it is being called. _________________ Thanks and Regards
Sridar |
|
Back to top |
|
 |
sridhsri |
Posted: Tue Sep 16, 2008 6:12 am Post subject: |
|
|
Master
Joined: 19 Jun 2008 Posts: 297
|
|
Back to top |
|
 |
broker_new |
Posted: Tue Sep 16, 2008 7:40 am Post subject: |
|
|
 Yatiri
Joined: 30 Nov 2006 Posts: 614 Location: Washington DC
|
Iam curious to know the correct reasonable answer for this....
As a best practice everyone says that whether we use those routines or not don't touch them...is it true...what would happen if we delete the CopyMessageHeaders() and directly assign the headers with two simple statements(assign MQMD and properties tree)....instead of finding CARDINALITY for each message which is a performance overhead.
DECLARE J INTEGER CARDINALITY(InputRoot.*[]); |
|
Back to top |
|
 |
sridhsri |
Posted: Tue Sep 16, 2008 12:11 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008 Posts: 297
|
Nothing would happen. There is a reason CopyMessageHeaders is written that way. You are assuming that only MQMD and Properties are present. Your message could have a MQRFH2. Your message need not come from MQ at all. There are any number of possibilities. The code there supports all those. If you know your message will always come from MQ and will NOT contain a MQRFH2 Header, then by all means use to two lines you mention. |
|
Back to top |
|
 |
broker_new |
Posted: Tue Sep 16, 2008 12:39 pm Post subject: |
|
|
 Yatiri
Joined: 30 Nov 2006 Posts: 614 Location: Washington DC
|
Thats true...
But still CARDINALITY is a pain we are still using CopyMessageHeaders() to copy the message headers for each time ......I think moving these procedures to a common place and calling them is the right way to reduce the code redundancy... |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Sep 16, 2008 12:50 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
broker_new wrote: |
Thats true...
But still CARDINALITY is a pain we are still using CopyMessageHeaders() to copy the message headers for each time ......I think moving these procedures to a common place and calling them is the right way to reduce the code redundancy... |
You have also to take into account that the procedures won't work as they are if you put them into a common broker schema.
The scope of InputRoot and OutputRoot is the problem here. You will have to work with references...
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Sridar |
Posted: Tue Sep 16, 2008 9:05 pm Post subject: |
|
|
Acolyte
Joined: 14 May 2006 Posts: 72 Location: Chennai, India
|
Hi
fjb_saper wrote :
Quote: |
You have also to take into account that the procedures won't work as they are if you put them into a common broker schema.
The scope of InputRoot and OutputRoot is the problem here. You will have to work with references...
|
This is exactly why i wanted to check with because i once tried to have it in a common schema but the inputroot and outputroot did not work directly and i ahd to declare In and Out Variables and i had to do some more changes and it did not finally work for me. _________________ Thanks and Regards
Sridar |
|
Back to top |
|
 |
mgk |
Posted: Wed Sep 17, 2008 1:34 am Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
Quote: |
it did not finally work for me |
I would guess that is because you did not create the parsers. A reference to OutputRoot does NOT behave the same as OutputRoot itself, and the difference is that the real OutputRoot will automatically create parsers to own the children (Properties, MQMD, XMLNSC etc) where as the reference will not. You have to create the parsers yourself when using references. I have posted code to do this a LONG time ago on this forum if you want to search...
Regards, _________________ MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
Back to top |
|
 |
|