| Author |
Message
|
| wooda |
 Posted: Mon Jul 05, 2004 3:22 am Post subject: |
 |
|
Master
Joined: 21 Nov 2003
Posts: 265
Location: UK
|
This is a classic case for using multipart messages.
Create a CWF message which models the first 8 bytes and then has embedded message (group of type composition message)
Create separate messages for each of the ten different bodies.
The message will be parsed upto the embedded message until you resolve it in ESQL.
So in a compute node examine the first two integers which will have been parsed then reference the correct sub message to cause the rest of the message to be parsed. |
|
| Back to top |
|
 |
| EddieA |
| Posted: Mon Jul 05, 2004 10:04 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Except that the original post said:
| Quote: |
| size of these messages will differ |
I didn't think that "choice" processing would work with that.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| wooda |
| Posted: Tue Jul 06, 2004 12:51 am Post subject: |
|
|
Master
Joined: 21 Nov 2003
Posts: 265
Location: UK
|
No actually even in CWF embedded messages do not have to be the same length.
If they are not the same length you cannot reference past an unresolved embedded message.
But then in this case the embedded message would be the last thing in the bitstream so this does not matter.
Using embedded messages in this case would be simpler than parsing the first bytes separately to decide which message you have then going back and reparsing the entire bitstream as the chosen message.
However both approaches would be entirely valid. |
|
| Back to top |
|
|
| adoyle65 |
| Posted: Wed Jul 07, 2004 12:26 pm Post subject: |
|
|
Apprentice
Joined: 18 Feb 2004
Posts: 37
Location: Canada
|
Hey Guys,
Not sure I compeletly understood the embedded message idea any further clarification would be good. What I have done, not saying this is the best way is to create an MRM message the has two integer fields and a large binary field. I use this on my input node to get the first two bytes and then I have ten different MRM messages all in the same message set that I reset content to.
One suggestion was to just create an MRM that would only be the first eight bytes. Would I not get an error when a message arrived on that input node that was larger than that defined in the MRM.
Thanks again all for your help |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Jul 07, 2004 2:42 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Would I not get an error when a message arrived on that input node that was larger than that defined in the MRM |
Your Input node would descibe the message as a BLOB. Then you can substring off the 8 bytes, and parse those against an MRM.
I'll leave it to wooda to explain the embedded message concept, as I'm not 100% sure about what he's talking about.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjcarretero |
| Posted: Thu Jul 08, 2004 12:17 am Post subject: |
|
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
Hi,
If you want to use embedded messages, as wooda suggested, you should do the following:
- Create the different messages without including the common fields.
- Create another message with the common fields. Create another field after the common ones. This last field have to be of complex type and in the composition select 'message'.
- Reference the messages from this last field.
You will need a node where you have to code the decision of what message should be parsed after the common bits.
Example:
| Code: |
ParentMessage(Field1,MessageType,Messages)
Message1(Field_A_1,...)
...
Message10(Field_A_10,...)
(You have a RCD = ParentMessage)
IF InputRoot.MRM.MessageType = '1' THEN
SET OutputRoot.XML.Field = InputRoot.MRM.Messages.Field_A_1; -- At this point WBIMB will parse the message according to Message1.
ELSE IF InputRoot.MRM.MessageType = '2' THEN
SET OutputRoot.XML.Field = InputRoot.MRM.Messages.Field_A_2; -- At this point WBIMB will parse the message according to Message2.
...etc |
Hope this helps
Cheers
Felipe |
|
| Back to top |
|
|
| wooda |
| Posted: Thu Jul 08, 2004 1:43 am Post subject: |
|
|
Master
Joined: 21 Nov 2003
Posts: 265
Location: UK
|
An embedded message based solution to this problem is really quite simple.
The advantage over the other solutions mentioned is much simpler ESQL.
The MRM will parse to the point at which you have an group/type of composition message and then stop and wait for you to resolve the "choice" in ESQL. So this is much the same way as choice works in CWF. However unlike choice with type composition message each path does NOT have to be the same length.
EXAMPLE
So take a simple example where we have a message which always contains a 4 byte integer followed by one of two different message bodies.
Let's say the integer tells us which body we have.
So we could model this as 3 messages
mainmsg (message)
msgnumber(integer element)
body(group with type composition=message)
submsg1(message ref)
submsg2(message ref)
submsg1 (message)
field1 (4 character string)
field2 (4 byte integer)
submsg2 (message)
field1 (2 character string)
field2 (4 byte integer)
field3 (10 character string)
So say we want to poarse this message and change some of the values.
We could use Input-Compute-Output
with the following ESQL
CALL CopyMessageHeaders();
SET OutputRoot.MRM.msgnumber = InputRoot.MRM.msgnumber;
IF InputRoot.MRM.msgnumber = 1 THEN
SET OutputRoot.MRM.submsg1.field1 = InputRoot.MRM.submsg1.e1;
SET OutputRoot.MRM.submsg1.field2 = 1234;
ELSEIF InputRoot.MRM.msgnumber =2 THEN
SET OutputRoot.MRM.submsg2.field1 = InputRoot.MRM.submsg2.e1;
SET OutputRoot.MRM.submsg2.field2 = InputRoot.MRM.submsg2.e2;
SET OutputRoot.MRM.submsg2.field3 = 'abcdefghij';
END IF;
I hope you get the idea.
I prefer this as it's a neater solution.
However as you can see there are multiple ways to do it. |
|
| Back to top |
|
|
| adoyle65 |
| Posted: Thu Jul 08, 2004 5:01 am Post subject: |
|
|
Apprentice
Joined: 18 Feb 2004
Posts: 37
Location: Canada
|
Hey Guys,
Thanks for all the suggestions. I tried to create a message using embedded messages but I do not see mention anywhere of a complex type, any clues?
Thanks |
|
| Back to top |
|
|
| wooda |
| Posted: Thu Jul 08, 2004 8:02 am Post subject: |
|
|
Master
Joined: 21 Nov 2003
Posts: 265
Location: UK
|
The indentation went a bit haywire on my example.
In the main message
| Quote: |
mainmsg (message)
msgnumber(integer element)
body(group with type composition=message)
submsg1(message ref)
submsg2(message ref) |
"body" was a group (with "type composition" = "message")inside the main message. This could just as easily have been an element of a complex type with "type composition"="message". There would be no difference excpet an extral level in the ESQL.
It is this group(or complex type if you use an element here) where the "embedded messages" will be inserted. |
|
| Back to top |
|
|
| adoyle65 |
| Posted: Thu Jul 08, 2004 9:09 am Post subject: |
|
|
Apprentice
Joined: 18 Feb 2004
Posts: 37
Location: Canada
|
Once again guys thanks for all your help with this topic. I appreciate it.
I shall try the suggestions and let you know how I make out.
Thanks
AD |
|
| Back to top |
|
|
|
|
