| Author |
Message
|
| jonesn |
 Posted: Sun Jan 29, 2006 8:55 am Post subject: How to create a new message component with structure |
 |
|
Apprentice
Joined: 09 Jan 2002
Posts: 47
|
Chaps,
I have a WBIMB 5 message flow that reads a SWIFT message from its input queue parsing against the SWIFT message set. A subset of the SWIFT elements need to be included in my outbound message.
I have created a message set to model my outbound message but do not know what eSQL to use to create it in my compute node.
I plan to move the SWIFT message to the environment then create an MRM child with the structure of my outbound modeled message then complete the missing fields from my saved SWIFT message.
I can create an output message by simply issuing commands like the following but this does not make use of the model I have created as I want to use the default & fixed values to reduce the amount code.
set OutputRoot.MRM.Field1 = 'Hello';
set OutputRoot.MRM.Field2 = Environment.SWIFT.something;
The documentation on the create function allows you to create an element & parse a blob (or such like) against message set but I want to create the tree & then fill in the blanks.
This seems to be a simple thing to want to do in the broker but I cannot find the bit of the manual telling me how.
Any help gratefully accepted.
_________________
---
Nick Jones
IBM Certified Solutions Expert (WebSphere MQ Integrator) |
|
| Back to top |
|
 |
| kimbert |
| Posted: Mon Jan 30, 2006 1:46 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| as I want to use the default & fixed values to reduce the amount code. |
Default/fixed values will only be used by the MRM when the Data Element Separation is 'Fixed Length' or 'Variable Length Elements Delimited'. They are automatically inserted by the writer to preserve the structure of the output bitstream (so they never appear in the message tree). Default/fixed values are never used when parsing.
| Quote: |
| I want to create the tree & then fill in the blanks. |
So you want the broker to create a 'skeleton message' from an MRM message definition? Sorry - this is not possible. I can see why it would be useful in your case, but it's actually a hard problem to solve in the general case. I think you're going to have to write that ESQL ( unless someone else can come up with an ingenious solution ). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 30, 2006 7:41 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kimbert wrote: |
| So you want the broker to create a 'skeleton message' from an MRM message definition? Sorry - this is not possible. |
I think it could be very easily done... just head out to Create Field... Parse.
Or did I mean route 66?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 31, 2006 1:50 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Hi Jeff,
I think jonesn wants the skeleton message to be populated with default and fixed values - i.e. he wants the overall hierarchy of the message (all the mandatory fields which have defaults, perhaps) to be created auto-magically from the message definition. That's not possible, even with Create Field...Parse.
Or maybe I've misunderstood the requirement. |
|
| Back to top |
|
|
| jonesn |
| Posted: Tue Jan 31, 2006 2:30 am Post subject: |
|
|
Apprentice
Joined: 09 Jan 2002
Posts: 47
|
Kimbert,
You are correct, that is exactly what I wanted to do. I would think that creating a skeleton message & only replacing a subset of fields would be a pretty standard requirement.
Is it really that difficult?
_________________
---
Nick Jones
IBM Certified Solutions Expert (WebSphere MQ Integrator) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 31, 2006 2:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I was thinking that using Create Field... Parse to parse a dummy message, that contained default and fixed values would create an entire message tree, with predetermined values that could then be overwritten.
Like, for a very simple Tagged/FixedLength message,
-Message
--H(tag)
---H1(char, length 1)
--B(tag)
---B1 (integer, length 1)
--T(tag)
---T1 (char, length 1)
Then you could use Create Field ... Parse with an input of "HAB0TB", and generate the message tree, where the single Header field would contain "A", the body field 0 and the trailer field "B". And then ESQL could be used to set the Body Field to 2, for example.
But in a general way, this can't be done, I agree. It requires that you know what the message data should look like, and have a dummy record that matches it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 31, 2006 4:09 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Is it really that difficult? |
Maybe, maybe not. There are certainly some tricky edge cases to consider (what about optional elements, optional groups which contain mandatory elements etc) but it might be possible to come up with some sensible rules. The fact is, you are the first person to ask for this (as far as I'm aware, anyway), which I must admit is rather surprising.
Jeff: Default values are only ever used by the MRM when writing fixed-length data. i.e. they are only used in situations where not using them would create a badly-structured bitstream. We're aware that this is a problem to some users. |
|
| Back to top |
|
|
| jonesn |
| Posted: Tue Jan 31, 2006 7:47 am Post subject: |
|
|
Apprentice
Joined: 09 Jan 2002
Posts: 47
|
Thanks for the responses, I have resigned myself to writing the eSQL, it is not that hard anyway.
_________________
---
Nick Jones
IBM Certified Solutions Expert (WebSphere MQ Integrator) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 31, 2006 8:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kimbert wrote: |
| Jeff: Default values are only ever used by the MRM when writing fixed-length data. i.e. they are only used in situations where not using them would create a badly-structured bitstream. We're aware that this is a problem to some users. |
My example should have been a little more clear than that. I meant use Parse to build a message tree from a fully specified message bytestream, where the bytestream had default values. I did not mean taking default values from the message model.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 31, 2006 8:59 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Ok - I understand now. Very innovative. Not sure about maintainability, though  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 31, 2006 8:25 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kimbert wrote: |
| Ok - I understand now. Very innovative. Not sure about maintainability, though |
Well, sure!
But jonesn didn't mention maintainability! 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
