| Author |
Message
|
| mqlover |
 Posted: Tue Jan 22, 2013 7:35 pm Post subject: how to maintain the MsgId end to end of transaction |
 |
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Hi,
I have 3 systems involved in my message flow.
One system initaites the transaction and the ESB picks it up and delivers to the other system say B.
A populates teh msg Id and teh same is passed by ESB to system B by doing
SET OutputRoot.MQMD.MsgId = InputRoot.MQMD.MsgId
After all computations when system B sends the message to System C via ESB, the MsgId is NULL.
How do I maintain the MsgId throughout the transaction from system A to system C. I need not maintain same msgId though.
Is there anything I can do like
If InputRoot.MQMD.MsgId is NULL then
Just need some suggestions on this.
Thanks in advance |
|
| Back to top |
|
 |
| Veera B |
| Posted: Tue Jan 22, 2013 8:00 pm Post subject: |
|
|
Voyager
Joined: 16 Jan 2013
Posts: 76
|
Usually we copy the MsgId to CorrelId while sending msg to other systems, and then copy the correlId back when the response comes.
here in your case .. it can be done like this
System A to B,
SET OutputRoot.MQMD.CorrelId= InputRoot.MQMD.MsgId
System B to C,
SET OutputRoot.MQMD.CorrelId= InputRoot.MQMD.CorrelId
System C to A,
SET OutputRoot.MQMD.CorrelId= InputRoot.MQMD.CorrelId
By doing this you have got the original MsgId to match the msg id and know which transaction has come back. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Tue Jan 22, 2013 8:50 pm Post subject: Re: how to maintain the MsgId end to end of transaction |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| mqlover wrote: |
After all computations when system B sends the message to System C via ESB, the MsgId is NULL. |
On what protocol does System-B send message to System-C? If it is MQ, then the message ID will be there by default. You dont have to do anything.
| mqlover wrote: |
How do I maintain the MsgId throughout the transaction from system A to system C. I need not maintain same msgId though. |
You say you dont need the same MsgID, then why do you need this? If it is MQ based then MsgID will be populated when it comes from the Queue. You do not need to do anything.
| Veera B wrote: |
Usually we copy the MsgId to CorrelId while sending msg to other systems, and then copy the correlId back when the response comes.
here in your case .. it can be done like this
System A to B,
SET OutputRoot.MQMD.CorrelId= InputRoot.MQMD.MsgId
System B to C,
SET OutputRoot.MQMD.CorrelId= InputRoot.MQMD.CorrelId
System C to A,
SET OutputRoot.MQMD.CorrelId= InputRoot.MQMD.CorrelId
By doing this you have got the original MsgId to match the msg id and know which transaction has come back.
|
| mqlover wrote: |
| I need not maintain same msgId though. |
CorrelID can be used only if you need to maintain the same ID throughout the flow of the message. |
|
| Back to top |
|
|
| mqlover |
| Posted: Wed Jan 23, 2013 1:50 am Post subject: how to maintain the MsgId end to end of transaction |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Thanks.
Actually I just came to know that system B does not use any MQ parameters.So how do I maintain the MsgId throughout the transaction i.e from System A to System C.
Thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 23, 2013 2:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You don't say if these are asynchronous processes or synchronous processes - i.e. is the ESB receiving a response from each system, or is each system independently invoking the ESB without regard to the processing that has occcured before hand.
If all of the calls are entirely stateless and entirely independent of each other, then the only thing TO do is make sure you can identify a given message by some unique identifier in the actual business data, and use that to correlate with a datastore that holds the state. |
|
| Back to top |
|
|
| mqlover |
| Posted: Wed Jan 23, 2013 5:33 pm Post subject: how to maintain the MsgId end to end of transaction |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Thanks for the replies.
It is asynchronous transaction.
Here we also found another scenario to add on to it. The system A sometimes generates MsgId sometimes and sometimes it doesnt.
When it does not generate MsgId, how do we populate the MsgId field? How could this be done at ESB done?
Thanks |
|
| Back to top |
|
|
| kash3338 |
| Posted: Wed Jan 23, 2013 10:45 pm Post subject: Re: how to maintain the MsgId end to end of transaction |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| mqlover wrote: |
Here we also found another scenario to add on to it. The system A sometimes generates MsgId sometimes and sometimes it doesnt.
When it does not generate MsgId, how do we populate the MsgId field? How could this be done at ESB done?
|
Its a bit confusing. Can you please clarify,
1. How does System-A/B/C send message, what format?
2. How many Message Flows do you have and how does it look like?
3. Do you need to correlate a single transaction or what is your requirement?
If the message comes from MQ Queue, there will be a MsgID attached to the message. It cannot be blank for some messages. |
|
| Back to top |
|
|
| mqlover |
| Posted: Thu Jan 24, 2013 12:01 am Post subject: how to maintain the MsgId end to end of transaction |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Thanks.
Ya I am aware of the fact that the MsgId field has to be populated.
Actually I received 2 transactions from System A.
In one msg I found that the MsgId was populated.
The second msg I found that MsgId consisted of '404040404040404040404040404040404040404040404040' which is spaces.
I want to handle this situation in ESQL. Please could you let me know how can I handle this?
Thanks once again for your suggestion. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Thu Jan 24, 2013 12:44 am Post subject: Re: how to maintain the MsgId end to end of transaction |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| mqlover wrote: |
Ya I am aware of the fact that the MsgId field has to be populated.
Actually I received 2 transactions from System A.
In one msg I found that the MsgId was populated.
The second msg I found that MsgId consisted of '404040404040404040404040404040404040404040404040' which is spaces. |
Then either System-A sets this kind of MsgID or the system which sends to System-A has this MsgID set. 40Hex is equal to '@' and not space.
You still did not answer the questions which would help to give a better suggestion.
1. How does System-A/B/C send message (transport protocol), what format?
2. How many Message Flows do you have and how does it look like?
3. Do you need to correlate a single transaction or what is your requirement?
This point from mqjeff holds very valid still,
| Quote: |
If all of the calls are entirely stateless and entirely independent of each other, then the only thing TO do is make sure you can identify a given message by some unique identifier in the actual business data, and use that to correlate with a datastore that holds the state.
|
|
|
| Back to top |
|
|
| mqlover |
| Posted: Thu Jan 24, 2013 1:07 am Post subject: how to maintain the MsgId end to end of transaction |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Thanks.
1. System A sends the message in BLOB format.
2. Message flow is quite simple.
System A -> MqinputNode -> Compute -> Mqoutput node.
From here the System B picks the message.
System A is the Adaptor system.
I know, I am matching the msgs with businessId present in the message. So I am not really concerned about the matching the message.
We just have the requirement that MsgId should be populated with unique value. It should not be contain any value like "@" or '0' etc.
Could you please suggest.
Thanks |
|
| Back to top |
|
|
| kash3338 |
| Posted: Thu Jan 24, 2013 1:12 am Post subject: Re: how to maintain the MsgId end to end of transaction |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| mqlover wrote: |
| We just have the requirement that MsgId should be populated with unique value. It should not be contain any value like "@" or '0' etc. |
If your only requirement now is to have a valid MsgID instead of some junk values, you can use the option available in MQOutput node. There is a option for 'New MsgID', just check that. |
|
| Back to top |
|
|
| mqlover |
| Posted: Thu Jan 24, 2013 1:35 am Post subject: how to maintain the MsgId end to end of transaction |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Thanks for the suggestion.
Is it possible to generate MsgId in Compute node using ESQL ?
Thanks |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 24, 2013 1:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Of course. You can also copy it from the inputroot to the outputroot.
Normally in compute nodes, you should uncomment one of the two IBM generated statements. To either copy the msg headers or the entire message.
-- CALL CopyMessageHeaders();
-- CALL CopyEntireMessage();
I have found developers ignoring this (I presume through lack of MQ understanding) and so generate a poor MQMD on the output side - often lacking MQ format values etc.
Always copy MQ headers unless you have a good reason not to. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Thu Jan 24, 2013 2:27 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| mqlover wrote: |
| Is it possible to generate MsgId in Compute node using ESQL ? |
Yes. You can form your MsgId with some combinations like (BrokerName || Flowname || PayloadUniqueId || TimeStamp) and Cast to Blob and set in MQMD.MsgId field.
| zpat wrote: |
Of course. You can also copy it from the inputroot to the outputroot.
....
Always copy MQ headers unless you have a good reason not to. |
Actually the OP needs to change the MsgId that comes as part of InputRoot since it has some junk value in it. Hence he needs to generate his own MsgId. |
|
| Back to top |
|
|
| mqlover |
| Posted: Thu Jan 24, 2013 2:47 am Post subject: how to maintain the MsgId end to end of transaction |
|
|
Disciple
Joined: 25 Jul 2010
Posts: 176
|
Thanks much for your valuable suggestions.
It helps a lot.
Thanks |
|
| Back to top |
|
|
|
|
