| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Advice on Message Set Creation |
« View previous topic :: View next topic » |
| Author |
Message
|
| whydieanut |
 Posted: Fri Jun 29, 2012 12:03 am Post subject: Advice on Message Set Creation |
 |
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
I have a few questions on Message Set modelling.
I'd like to know about grouping different logical message types in Message Sets.
Below is my problem; I am looking at the ideal Message Set configuration for it.
I have flows connecting multiple source applications sending data to a single end system. It's a point to point, one way interface design.
Each of the source applications has multiple types of messages (MRM - CSV), with each having different processing requirements.
Some message types are common across different applications. But 2 applications might have slightly different requirements (in terms of mandatory/optional fields, etc.) for the same message type.
Based on this, I have grouped my Message Flows into different Message Flow projects like so:
1 Message Flow Project for each source system, containing multiple Message Flows (containing multiple message flows)
1 Message Flow for each Message type.
Now on to Message Sets...
I had created a Message Set for each Message type, with 1 message definition file each.
The message definition file had 1 message (multiple messages in case a message was common between multiple applications and had different requirements)
So my bar file (1 per flow) creation required including the message flow and the corresponding message set.
Now I am wondering if having multiple Message Sets is required at all, considering that all messages are in the same Physical format.
Can I just have all my messages defined in the same message set, but within different message definition files?
What is the ideal way to group together messages (among Message Sets and Message Definition files) for the scenario described above?
Am I overlooking something important in trying to do this?
(Please let me know if my description above is not clear; will try to explain with some examples) |
|
| Back to top |
|
 |
| kimbert |
| Posted: Fri Jun 29, 2012 1:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Some comments from a purely technical perspective. Others on this forum may have different advice, backed up by years of practice...
| Quote: |
| Some message types are common across different applications. But 2 applications might have slightly different requirements (in terms of mandatory/optional fields, etc.) for the same message type. |
There are two ways to look at this.
a) you have two different message types. They just happen to use the same fields.
b) you have a single message type in which the varying fields are optional. One of the applications contains some validation logic that applies stricter rules.
If there are many fields that differ then I would argue that it is a) because it is not ideal to have a lot of custom validation logic in your message flow. If it is only one or two fields that vary, you could get away with b).
| Quote: |
| I had created a Message Set for each Message type, with 1 message definition file each. |
I think you know this already, but you can have as many message definition files as you like in a message set.
| Quote: |
| Now I am wondering if having multiple Message Sets is required at all, considering that all messages are in the same Physical format. |
That sounds like jumping to the opposite end of the see-saw. Maybe the sweet spot is somewhere in between?
| Quote: |
| Can I just have all my messages defined in the same message set, but within different message definition files? |
You can. I don't know whether that would be the best solution for you. Here are some things to think about:
- A message set is loaded into memory by the execution group when it is first used. All of the message definitions are loaded, even if only one of them was required.
- Is there any possibility that your applications will be put into different execution groups? If so, then you probably will not want all of the message defs in a single message set.
I expect there are subsets of the applications that are related to one another, and are likely to be co-located when deployed. I would group the message definitions according to those subsets, and have a single message set per subset. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Fri Jun 29, 2012 1:32 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| Quote: |
| I expect there are subsets of the applications that are related to one another, and are likely to be co-located when deployed. I would group the message definitions according to those subsets, and have a single message set per subset. |
Aah, the sweet spot...
So there is no harm in having each message type in a message set of its own...
I figured having ALL of them in the same Message Set would have some repercussions.
Now imagine, I do have it that way; and I have 3 flows referring the Msg Set in an EG.
At any given point there is only one copy of the Msg Set in the EG.
Now I if need to alter the Msg Set to change the definition for a single message type (that is not relevant to the other 2 flows in the EG), what happens when I deploy the changed flow with the new Msg Set?
Will it affect the other 2 flows which require different Msg stypes in the same Msg Set?
I think having all in one will eventually cause problems...
Also not yet sure how I'll be grouping the flows into different EGs. Think its best to go with individual Msg Sets.
Also, if going with individual Sets, for a message type that might have slightly different versions for 2 applications, is ti better to have different message defnition files OR just different message types created in a single message definition file.
Very basic question, but what exactly is the purpose of having msg def files? :-\
One last thing,
I might have some kind of header segments that will be common across all message types. Anyway I can define it in a common Msg Set and have the individual Msg Sets refer this common Msg Set? |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Jun 29, 2012 1:40 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| for a message type that might have slightly different versions for 2 applications, is ti better to have different message defnition files OR just different message types created in a single message definition file. |
Neither is better - it's like asking whether to split up your xsd into a number of smaller xsds. You are free to do whatever makes sense for your project.
| Quote: |
| what exactly is the purpose of having msg def files? |
Well, a message definition file is the 'source file' for a message definition. It's generally a good thing to allow multiple source files. Programming languages allow it. XML Schema allows it. Message sets allow it.
If you have more than one namespace being used in a message set then you will be forced to use multiple message definition files - because you will need at least one mxsd per target namespace. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 29, 2012 2:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Remember that each message set is a separate eclipse project, which means that it's a separate container under source control.
It's also a separate deployable container. And, particularly, it's a separate entry on mqsicreatebar's command line.
All of this is to say that it's better to have fewer message sets with more message definitions each than to have more message sets with fewer message definitions each.
Again, we come back to "what makes sense for your project". We're talking about what makes sense based on the messages themselves. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Fri Jun 29, 2012 2:24 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Thanks a lot kimbert!
@mqjeff,
What you're implying is that it is more of pain maintenance wise?
Given that there aren't too many different message types involved, I feel multiple Sets can be easily maintained...
Any comment on the below?
| Quote: |
| I might have some kind of header segments that will be common across all message types. Anyway I can define it in a common Msg Set and have the individual Msg Sets refer this common Msg Set? |
Another thing I am curious about:
Suppose I have 3 flows referring to the same Msg Set but using different Message types in it, deployed to the same EG;
Now I have to alter the Msg Set for a single message type (used by one of the 3 flows) and redeploy the message flow with the changed message type, how does it affect the other 2 flows deployed in the EG, considering that only one copy of the Msg Set is maintained in an EG? |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Jun 29, 2012 3:12 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I might have some kind of header segments that will be common across all message types. Anyway I can define it in a common Msg Set and have the individual Msg Sets refer this common Msg Set? |
Usually, message sets are completely independent. This is by design, btw. So you cannot import or include message definition files from other message sets.
However, there *is* a way to define your message definition so that the header comes from one message set and the body comes from another. Look up 'multipart' and 'message alias' in the info center. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Fri Jun 29, 2012 3:16 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Thanks, will do...
And this last bit?
| Quote: |
Another thing I am curious about:
Suppose I have 3 flows referring to the same Msg Set but using different Message types in it, deployed to the same EG;
Now I have to alter the Msg Set for a single message type (used by one of the 3 flows) and redeploy the message flow with the changed message type, how does it affect the other 2 flows deployed in the EG, considering that only one copy of the Msg Set is maintained in an EG? |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 29, 2012 3:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| Quote: |
| I might have some kind of header segments that will be common across all message types. Anyway I can define it in a common Msg Set and have the individual Msg Sets refer this common Msg Set? |
Usually, message sets are completely independent. This is by design, btw. So you cannot import or include message definition files from other message sets. |
My memory on this was fuzzy and I didn't want to double-check so I didn't comment. One can use multi-part as mentioned, or one can also just make every message set a derived message set from a common parent.
Multi-part messaging is the preferred method, for a number of reasons. But other methods are indeed possible.
| whydieanut wrote: |
Thanks, will do...
And this last bit?
| Quote: |
Another thing I am curious about:
Suppose I have 3 flows referring to the same Msg Set but using different Message types in it, deployed to the same EG;
Now I have to alter the Msg Set for a single message type (used by one of the 3 flows) and redeploy the message flow with the changed message type, how does it affect the other 2 flows deployed in the EG, considering that only one copy of the Msg Set is maintained in an EG? |
|
The same thing that happens when you redeploy the message set when all three are changed. each of the message flows reloads the necessary definitions the next time a new instance of that message flow starts.
That is to say "It just works!".
| whydieanut wrote: |
@mqjeff,
What you're implying is that it is more of pain maintenance wise?
Given that there aren't too many different message types involved, I feel multiple Sets can be easily maintained... |
It's more of a pain maintenance wise, yes. It's also more of a pain Governance wise.
It's not a significant issue for 5 or six message sets. But if you have 10, you need to be using the same procedures that will work for hundreds, or you'll run into growing pains when you hit 30 or so. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
