| Author |
Message
|
| Adreno |
 Posted: Tue Mar 25, 2008 7:01 am Post subject: Use MQMD.ApplIdentityData for output routing |
 |
|
Acolyte
Joined: 05 Jul 2007
Posts: 71
|
Hey Dudes,
I got a question regarding the use of the ApplIdentityData field within the MQMD header. We need to transport an additional information from one message broker flow to another and store this information in this field.
Now this field gets erased wile the message is passed by the MQOutput node, even pass all is set on this.
Any suggestions how to protect this field so that is not erased within the mqput and mqget actions?
_________________
There are two kinds of people in this world: people who s***, and Chuck Norris... |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Mar 25, 2008 7:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There is no field in the MQMD that is a good choice for storing business level context information.
Use an MQRFH2 and a field in the usr folder.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Adreno |
| Posted: Tue Mar 25, 2008 7:09 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 71
|
There´s no opportunity to use the RFH2 Header instead. The message structure needs to match rpg strutures at an i-series backend.
These structures can´t be manipulated from our side so we just got the message data and the MQMD Header.
Is there a way to prevent the ApplIdentityData from getting erased during mqput and mqget?
_________________
There are two kinds of people in this world: people who s***, and Chuck Norris... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 25, 2008 7:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm really confused where RPG comes in.
You said "pass information between one message flow and another".
There's no reason to keep the data in RPG format until it's going to the remote side for RPG invocation.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Adreno |
| Posted: Tue Mar 25, 2008 7:23 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 71
|
Well let me tell you a bit more details.
The first flow provides webservice funtionality to an php frontend and consumes data in xml format, transforms this data into flatfile and passes this to an rpg backend.
The backend processes the message and sends it back to the second flow, which performs the http reply. Within this backend processing we need to transport some informations regarding the message set, so that we can match the right one within the reply flow.
This information needs to be stored within a field in the header. Is there a field to store this in the MQMD (Even i´m also convinced that this isn´t a good choice!  )
_________________
There are two kinds of people in this world: people who s***, and Chuck Norris... |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 25, 2008 7:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Adreno wrote: |
Within this backend processing we need to transport some informations regarding the message set, so that we can match the right one within the reply flow.
|
The <mcd> section of the RFH2 header is specifically intended to be used for this purpose. If these fields are set in an RFH2 on the message, the broker will automatically pick it up and use it.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Tue Mar 25, 2008 7:37 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 25, 2008 7:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
ApplIdentity is a really bad choice for this.
Use an MQGet node to receive the reply from the backend processing in the same scope as the request from the front-end flow.
Or use a mechanism to store the necessary state in the backend flow where it will be available and can be correlated with the reply message - if the backend has to be asynchronous.
It's a really poor design to use MQMD for this in any meaningful way.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Adreno |
| Posted: Tue Mar 25, 2008 7:45 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 71
|
So guys,
i´m totally convinced that the use of the MQMD header for business logic data is really aweful and so we will use the usr section within the MQRFH header and force the rpg guys at costumer side to build a struct that is matching this.
_________________
There are two kinds of people in this world: people who s***, and Chuck Norris... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 25, 2008 7:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Use msgid/correlation ID, if you have to carry this through.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fde |
| Posted: Tue Mar 25, 2008 7:51 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
| jefflowrey wrote: |
| Use an MQGet node to receive the reply from the backend processing in the same scope as the request from the front-end flow. |
This sounds pretty interesting. Is there a scope, which I can use, that streches over the requestflow to the replyflow, even if there is a MQOutput and a MQInput Node in between?
And more important, is it a per-request scope, which lifes only for the request and the reply flow? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 25, 2008 8:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can use ESQL shared row to carry data between invocations of the same node or the same flow.
You can use a variety of other techniques to carry state between two message flows.
Using the MQMD to do is not the best way in the book.
It is always better to not share data at all, and keep everything within the same invocation.
An interesting way to do this would be to use a Collector node to connect the request with the reply. In a larger case (more than one reply), using Aggregation might be better.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
