| Author |
Message
|
| Sandman |
 Posted: Mon Oct 23, 2006 9:42 am Post subject: Please point me in the right direction? (multipart messages) |
 |
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Hi,
I've not dealt much w/ MRM messages, just usually XML or XMLNS. so I'm hoping someone can give me a nudge.
We have a message that will be structured like this:
- common header/envelope - fixed length
- policy header: summary policy data, as well as indicator for which specific line of business (LOB) data follows
- LOB-specific record - varies in size by LOB
I've been reviewing the Message Modeling manual and some posts out here and would just like some guidance, if you don't mind. Should this be a "multipart message" or should I be reading more about "TDS"? Or some other solution?
Still on v5 for a few more months.
Many thanks,
Sandman
Last edited by Sandman on Tue Nov 14, 2006 8:56 am; edited 1 time in total |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Oct 23, 2006 9:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What is the nature of the "indicator of which specific line of business(LOB) data"?
What is the nature of the LOB data? Is it tagged, or delimited?
You can't use a multi-part message across different MRM parsers - all your parts must be MRM-CWF or MRM-TDS or MRM-XML.
I'm assuming that none of your data is XML, so you can't use MRM-XML. That kind of leaves TDS or CWF. But both TDS and CWF have constraints on what they can and can't model.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Oct 23, 2006 10:11 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
The LOB indicator is a 3-byte character field within the policy header portion of the message that is used to control which subflow to invoke to process the different kinds of records.
The LOB data is not tagged or delimited. This message comes from a COBOL program, and the MRM was imported from a provided copybook. IOW, for each LOB record, we know all of the fields and their positions/lengths.
To be more specific... the common header at the very beginning of this message is something that we would use across many messages (not just these policy ones). So if possible, I'm also looking for a way to not have to redefine this portion in each new message. IOW, if we were to add or change something in this header, we'd want to simply redeploy all message sets that used it instead of having to manually make the change across all message sets.
Thank you. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 23, 2006 4:27 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess the LOB indicator is not the last field in the header? It's somewhere else?
It sounds almost positively that you will need to use CWF for your LOB data - and so if you want to use multi-part messages, you would have to use CWF for that too.
It *is* possible to do strictly fixed-length modelling with TDS - but it also doesn't really sound like you're going to have anything that will take advantage of TDS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Oct 24, 2006 12:56 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Jeff's correct. If you are importing COBOL copybooks, CWF is the way to go.
| Quote: |
| Still on v5 for a few more months. |
That's unfortunate. v6 can parse this very nicely using the LOB indicator as a 'Message Identity' ( see Interpret Value As' field on string elements ).
In v5 I think you'll have to
- Find out what the LOB indicator is
- Use the LOB indicator to select a message definition ( so you will need to create an MRM 'message' for each LOB-specific record )
- Use CREATE FIELD...PARSE with DOMAIN /SET / TYPE / FORMAT to parse against the selected messsage definition.
If the LOB record is at a fixed offset from the start of the message, you can avoid parsing the header, and just extract the LOB record directly ( i.e parse in the BLOB domain and then switch to MRM domain once you know which message type you are dealing with ).
Both approaches require a message definition to be created for each LOB-specific record, but the v6 solution is better because all the information about the message format is in the message set.
You can create a message definition for a LOB record easily enough. If the element which defines the entire LOB record is global, just right-click and select 'Create message from global element'. |
|
| Back to top |
|
|
| Sandman |
| Posted: Tue Oct 24, 2006 9:30 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
No, the LOB indicator is not the last field in the policy header (nor the first).
I believe they already are using CWF for this message, but they take it in as BLOB, then based on the known location of the LOB indicator, they parse it as necessary.
After seeing your response today kimbert, I expedited getting v6 installed in a test environment. The toolkit's installed on my machine now, and I'm just waiting for the broker and config mgr to be setup on a test box. So I s/b up on v6 by tomorrow. I just couldn't see continuing trying to find a way to do this in v5, when I learned that we plan to move all our code to v6 by January 07 anyway. Thanks for the nudge. 
So now, at your recommendation, I will explore Message Identity. Anything else I should be aware of or focus on for this?
I have another requirement that we've danced around in the past, but I'm also wondering if v6 offers a better mousetrap: the equivalent of COBOL's OCCURS DEPENDING ON feature. This same message contains optional repeating fields that in current implementations are just maxed out (in order to avoid the DEPENDING ON part). So if what we really wanted was 0-20 occurrences of a field, it's simply coded as OCCURS 20. The problem w/ this is that we're sending very large messages all the time, when most of the time, there are huge chunks of blanks within.
I know that it's possible to do MIN/MAX, but I was told there were issues w/ doing this more than once within a message. In COBOL, the compiler doesn't like it when the field on which the array DEPENDS is "variably located" (because this array itself is variably located due to being inside a previous/parent array that varies in length). Does this make sense? If so, could you please suggest some features to explore to address this?
Thank you very much,
Sandman |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Oct 25, 2006 1:44 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I'm also wondering if v6 offers a better mousetrap: the equivalent of COBOL's OCCURS DEPENDING ON feature |
Yes it does.
In v5 CWF can handle OCCURS DEPENDING ON, but the repeat count field must be within the same complex type ( structure ) as the repeating element.
In v6, the repeat count field can be anywhere in the message ( but before the repeating element, of course ).
| Quote: |
| In COBOL, the compiler doesn't like it when the field on which the array DEPENDS is "variably located" |
That rule will be enforced by the v6 COBOL importer. If you want to take advantage of the new v6 function, you will have to tweak the message model after importing it. |
|
| Back to top |
|
|
| Sandman |
| Posted: Thu Nov 09, 2006 9:25 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
kimbert:
| Quote: |
| If the element which defines the entire LOB record is global, just right-click and select 'Create message from global element'. |
I can't seem to find this on the menu when I right-click on a global element? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Nov 09, 2006 12:12 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Just right-click on 'Messages' in the Outline view ( bottom left pane) and select 'Add message from global element'. |
|
| Back to top |
|
|
| Sandman |
| Posted: Tue Nov 14, 2006 5:43 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Ok, I've done a lot of reading and some tinkering. Now I could use a little push in the right direction (again).
Message Sets:
Would you recommend one big message set for all of our CWF needs, in which we would maintain message defs for CommonHeader, our primary business objects (Policy, Claim, Party), and each specific integration (i.e. PolicyRetrieveRequest, PolicyRetrieveResponse, AddPartyRequest, etc.)? Or would you suggest that we separate message defs into smaller message sets (likely broken down by the areas above)? If we do the latter, we wouldn't have to get involved w/ Message Set Identities and Project References, right? But are there downsides too to one big message set?
Embedded Messages:
Which of these approaches would be better (or something entirely different?)?
1. "Outside/in": In the outermost CommonHeader message, define a string element to be used as the Message Identity field, then create a message def for each allowable embedded message type (i.e. PolicyRetrieveResponse). In this approach, all of our CWF message flows would use this sole message def. IOW, when we add a new integration, would we have to do anything besides defining the new message def for that integration? Then we would always have our message flows process as if they're only getting CommonHeader messages, and dynamically, the appropriate child message defs would be parsed. Are there maintenance and/or performance issues w/ this approach?
2. "Inside/out": Create specific message defs for each integration and somehow (?) either "base them upon" the CommonHeader or make all of the elements in the CommonHeader "globally-accessible" for inclusion in each specific integration.
What would be the pros/cons of these approaches if we had to make changes to something in the CommonHeader? Even though we don't anticipate having to change this area (as it's a COBOL/flat version of a header that is based upon a pretty static XML schema), if we did change it, our goal would be to minimize impact - i.e. not have to manually change each integration's message def (very bad), or would it simply be a redeploy of each message def that used the CommonHeader?
Much appreciate your help. Thank you. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Nov 14, 2006 2:14 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Good questions. I don't think I'm going to tell you anything that you haven't already worked out for yourself, but here goes anyway.
- if you are very keen to have multiple message sets, you will need to add a fixed string to the CommonHeader structure. In the message model it will have 'Interpret Value As' == 'Message Set Identity'. The other message set will use that same fixed string as its Message Set Alias.
If you don't like that approach, use a single message set. I don't think it will be too painful.
-Outside/in would be my recommended approach. The alternative is to use the complex type extension mechanisms in XML Schema to extend CommonHeader for each message type. Both approaches solve the maintainability problem but I don't recommend using complicated schemas for modeling non-XML data. It's just hard enough without that. |
|
| Back to top |
|
|
| Sandman |
| Posted: Wed Dec 13, 2006 6:32 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Well, I got the multipart message working.
Now I have another question: once I've defined an embedded message (and using the Message Identity technique to parse, based on the contents of a preceding field), am I then required to ALWAYS provide an embedded message (and set the identity field to the name or alias of the message)? IOW, if the embedded piece is optional, I had hoped to simply leave the identity field blank and it would stop parsing at that point?
I tried setting the complex type whose composition property is "Message" to "Min Occurs 0", but that didn't work either. I get this error: CheckedVector::error - vector index out of range.
Any thoughts?
Thank you. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Dec 13, 2006 1:12 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Code: |
| I had hoped to simply leave the identity field blank and it would stop parsing at that point? |
I don't blame you for hoping, but it does not work that way. If the message model contains an embedded message ( i.e. a structure with Composition='Message') then the most-recently-parsed Message Identity is used to identify it. If that MI happens to be the empty string, the MRM parser will give up trying to identify the message and report an error.
| Code: |
| I get this error: CheckedVector::error - vector index out of range. |
Oh dear! That's a defect. |
|
| Back to top |
|
|
| Sandman |
| Posted: Thu Dec 14, 2006 5:18 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Thanks kimbert.
Any suggestions on how to achieve this "dynamic existence" behavior I'm aiming for regarding the embedded message (IOW, sometimes it'll be there, sometimes not, but when it is, it can be either message A, B, C, etc.)?
Also, the defect you mention... do you mean "product" or "MY code"?
Thank you. |
|
| Back to top |
|
|
| Sandman |
| Posted: Wed Dec 20, 2006 11:29 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Just bumping up to see if I might get a response.  |
|
| Back to top |
|
|
|
|
