| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Modeling and optional records |
« View previous topic :: View next topic » |
| Author |
Message
|
| jefflowrey |
 Posted: Mon Apr 07, 2003 9:09 am Post subject: Message Modeling and optional records |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm trying to model a flat file document that consists of a header, a body and a trailer.
The body consists of a set of groups of records. Each record can be one of about 8 different types. Each group starts with a type one record, and the rest of the record types are optional (although I believe there has to be at least one other record of another type).
So, it kinda looks like this:
HeaderRecord
TypeOneRecord
TypeTwoRecord
TypeFourRecord
TypeOneRecord
TypeEightRecord
TrailerRecord
I've got all my elements defined, and compound types defined for each record type. The first field in each of my records is a record type identifier. Fields are fixed length strings and numbers - nothing fancy.
I'd like to be able to create a message that will reliably allow me to separate each group of records out, and parse each record based on type.
Should I be using CWF, or TDS? Can I model this is such a way that I don't have to parse each record after doing ESQL work to identify it? Should I be looking at multi-part messages?
Any suggestions would be appreciated. |
|
| Back to top |
|
 |
| kirani |
| Posted: Mon Apr 07, 2003 8:44 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
We use MRM-CWF to model such messages. Are you familiar with REDEFINES in COBOL? You can rearrange your record layout to use REDEFINES and import it into MRM. WMQI will create CHOICE compound types for these redefines. You can then create your input/output message of this compound type.
For example,
Let's say your copybook layout is as follows,
| Code: |
01 RECORD-LAYOUT.
03 REC-ID PIC X(1).
03 HDR-REC.
05 H-ELE1 PIC X(2).
05 ...
03 DTL1-REC REDEFINES HDR-REC.
05 DTL1-ELE1 PIC X(2).
05 ...
03 DTL2-REC REDEFINES HDR-REC.
05 DTL2-ELE1 PIC X(2).
05 ...
03 DTLN-REC REDEFINES HDR-REC.
05 DTLN-ELE1 PIC X(2).
05 ...
|
When you import this copybook into your Message set, it will create all elements with appropriate data types and compound types. Define your message (m_Record) of type RECORD_LAYOUT_TYPE.
Use this message(m_Record) to parse your input data. Within your message flow based on the REC-ID field you will decide, which record type to refer to. For example,
| Code: |
-- Check for incoming record type
IF ( InputRoot.MRM.REC_ID = 'H' ) THEN
-- Record is HDR-REC
-- Use InputRoot.MRM.xxxGROUPXX.HDR_REC.H_ELE1;
....
ELSEIF ( InputRoot.MRM.REC_ID = '1' ) THEN
-- Record is DT1-REC
-- Use InputRoot.MRM.xxxGROUPXX.DTL1_REC.DTL1_ELE1;
...
ELSEIF ( InputRoot.MRM.REC_ID = '2' ) THEN
-- Record is DT2-REC
...
....
....
END IF;
|
Hope this helps.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 08, 2003 5:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
My message set was actually created from a copybook laid out similar to what you describe.
It looks like it created my RECORD_LAYOUT_TYPE (albeit by a different name) as an open sequence instead of a choice.
In addition, I'm not sure the ESQL you show would work. Each message on the queue is going to consist of several records, the first record is going to be a header, the last record is going to be a trailer. I don't see anything that indicates that.
The logical structure of the message should end up being kinda like
HeaderRecordTypeOneRecordTypeSevenRecord
TypeFourRecord TrailerRecord
And I need to break out each set of records associated with each TypeOne.
If possible, I would like to have all of the grouping and record identification happen inside the model, and not have to write ESQL that says 'If the record code is H, then parse the next chunk as a header record'. It would be feasible to do that, as there are only about 10 record types, but it makes everything more complicated.
I heard Matt Lovett talk about using data patterns to resolve choices at the conference, but don't know enough about MRM modeling to feel confident that I can do that. |
|
| Back to top |
|
|
| kirani |
| Posted: Tue Apr 08, 2003 5:51 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I think, you need to first tell WMQI how many records are present in the input message. You need to have some counter prefix to these records, so your copybook layout will change.
For example,
| Code: |
01 RECORD-LAYOUT.
03 REC-CNT PIC 9(4).
05 RECORD OCCURS DEPENDING ON REC-CNT.
10 REC-ID PIC X(1).
10 HDR-REC.
15 H-ELE1 PIC X(2).
15 ...
10 DTL1-REC REDEFINES HDR-REC.
15 DTL1-ELE1 PIC X(2).
15 ...
10 DTL2-REC REDEFINES HDR-REC.
15 DTL2-ELE1 PIC X(2).
15 ...
10 DTLN-REC REDEFINES HDR-REC.
15 DTLN-ELE1 PIC X(2).
15 ...
|
After you import this, it will create a high level compound type RECORD_LAYOUT_TYPE (Type Composition: Sequence). There will be another type element RECORD_TYPE_GROUP0001, whose Type Composition will be set to Choice. This type element will have elements for each of these record type. Since your REC_ID element is outside the Choice, you can use it to determine the type of Input record.
Your choice will be resolved only when you refer to any inner element within that choice type (I guess this is what Matt Lovett was talking about).
We use this type of message modeling all the time and I find it very eay to work with.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 09, 2003 5:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I can't change the record layout at all. It's an industry standard, and we need to process messages from external parties.
That said, it's possible that there is already a 'record count' field inside the header. I don't know the details of the fields very well, as I work in infrastructure rather than business development. At first glance, I don't see any names in the header fields that suggest there is a record count. There are some summary fields in the trailer, but that doesn't help.
I will follow up on the ibm newsgroup (where I know Matt Lovett lurks) about using data patterns to resolve choice. |
|
| 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
|
|
|
|
