| Author |
Message
|
| jbanoop |
 Posted: Thu Dec 16, 2010 12:32 pm Post subject: Nested MRM structure to be obtained from Flat File Records |
 |
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
All,
The environment we use is:
WMB 7.0.0.1
AIX : 6.0
We have a requirement where in we need to read an input flat file and build a nested MRM structure.
The flat file has the following layout.
| Code: |
A......... <CR><LF>
B........ <CR><LF>
C....... <CR><LF>
B........<CR><LF>
C........<CR><LF>
C.......<CR><LF>
B......<CR><LF>
B......<CR><LF>
|
Basically in the flat file all records occur at the same level. A, B and C can be used as tags to identify a particular record type.
The actual output required is
| Code: |
A....
- B....
- C.....
- B.....
- C.....
- C.....
- B.....
- B.....
|
Basically A is the parent record and B is a child record which can occur any number of times and C is a child for B that could occur any number of times as well...
Is this achievable with MRM?
The records A, B abd C are fixed length as far as their fields are concerned.
Any inputs on the right direction to take would be very helpful.
Regards,
[/code] |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 16, 2010 12:40 pm Post subject: Re: Nested MRM structure to be obtained from Flat File Recor |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jbanoop wrote: |
| Is this achievable with MRM? |
Well it seems to me that the MRM will describe the actual structure of the record, i.e. flat with tagged records, and this is quite easy to achieve.
If whatever logic you're using treats them as children it would be a very simple matter to build a message tree inside broker on that basis, but IMHO you couldn't get a nested message tree directly out of the MRM.
Of course kimbert will be along in a moment with a brilliant suggestion of how to do it with a message set. But I'd build a message set that described the file, and half a dozen lines of ESQL in a Compute node to build a nested tree (I presume you want to iterate round the respective children?)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Dec 16, 2010 1:14 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
You need to use a message set with a TDS physical format. Like this:
| Code: |
element name="flatFile"
complexType DataElementSeparation="Tagged Fixed Length" Delimiter="<CR><LF>" tagLength="1"
element name="Record" Tag="A" minoccurs="0" maxOccurs="unbounded"
complexType DataElementSeparation="Tagged Fixed Length" Delimiter="<CR><LF>" tagLength="1"
element name="subRecord" Tag="B" minoccurs="0" maxOccurs="unbounded"
complexType DataElementSeparation="Tagged Fixed Length" Delimiter="<CR><LF>" tagLength="1"
element name="subSubRecord" Tag="C" minoccurs="0" maxOccurs="unbounded"
|
If it doesn't work, please take a debug-level user trace and post the relevant parts. And, of course, quote any error messages in full. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Dec 16, 2010 2:08 pm Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Vitor,
Thanks for the suggestion. I would not want to have custom logic that interprets child records maintaining counters and references if possible.
That would be a last resort.
Kimbert,
Many thanks for the direction. We will try it out and report. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 16, 2010 2:15 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I guess it's not clear to me from what's been shown that each A, B, C record is actually a fixed length structure. So you might have to switch to tagged/delimited. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Dec 16, 2010 2:28 pm Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Jeff,
The .....'s were for reprsentation.
We are actually trying to get IDOC 'like' flat files as input and need to map some of the fields to the ECC IDOC structure and post them.
Here A is the parent segment while B and C are actually child segments bu these all come out at the same level on the flat file. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 16, 2010 2:51 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jbanoop wrote: |
Jeff,
The .....'s were for reprsentation.
We are actually trying to get IDOC 'like' flat files as input and need to map some of the fields to the ECC IDOC structure and post them.
Here A is the parent segment while B and C are actually child segments bu these all come out at the same level on the flat file. |
Yes.
That's not really relevant.
Are all of the fields of A going to be the same width every time? Are all of the fields of B going to be the same width every time? Are all of the fields of C going to be the same width every time?
If so, you can use tagged/fixed-length as kimbert has shown.
If not, you will need to use tagged/delimited so that you can use the Tag to tell you where, for example, A starts and the Delimiter to tell you where A *ends*. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 16, 2010 6:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jbanoop wrote: |
Kimbert,
Many thanks for the direction. We will try it out and report. |
Said he'd have a brilliant suggestion. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 17, 2010 7:23 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jbanoop wrote: |
Jeff,
The .....'s were for reprsentation.
We are actually trying to get IDOC 'like' flat files as input and need to map some of the fields to the ECC IDOC structure and post them.
Here A is the parent segment while B and C are actually child segments bu these all come out at the same level on the flat file. |
And so they should. The level differentiator is part of the first 63 bytes of the EDI_DD40 record. You need to review with your SAP consultant what the content of the records should be.
There may also be a row number identifier and a parent row number identifier on said EDI_DD40...
Apparently you've been given a task involving an SAP format with very little information about said format. Get back to the SAP team, your requirements seem far from complete to me.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 17, 2010 7:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| jbanoop wrote: |
Jeff,
The .....'s were for reprsentation.
We are actually trying to get IDOC 'like' flat files as input and need to map some of the fields to the ECC IDOC structure and post them.
Here A is the parent segment while B and C are actually child segments bu these all come out at the same level on the flat file. |
And so they should. The level differentiator is part of the first 63 bytes of the EDI_DD40 record. You need to review with your SAP consultant what the content of the records should be. |
That's all well and good, but the physical organization of the flat file is not a determining factor of the logical structure of the message tree. The only thing that determines the logical structure of the message tree is the logical structure of the message model.
I could easily construct a message model that would parse this document as is, but the end result would have record C as a child element of B, but nested 100 layers deep. That is, something like Root.A.B.<1>.<2>......<100>.C, rather than Root.A.B.C.
So stop focusing on whether or not the "..." have any logical or physical meaning.
I don't care that A is a child or parent of B. I just need to know that A is always fixed length, if I want to use Fixed Length to model the record! If I know that A is NOT always going to be the same length, then I CAN NOT use Tagged/Fixed-Length.
And I wouldn't be belaboring the point if it was clear yet that jbanoop understood that, and understood the difference being made. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Fri Dec 17, 2010 7:53 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
fjb_saper,
As I mentioned, it is not an actual IDOC structure. It is very similar to an R/3 IDOC format. The fist 55 characters (which are the control info SEGNUM, PSEGNUM etc) are blanked out in the input file except for TABNAM. The system that generates this psudo IDOC flat files is a non-SAP system.
The objective of the interface is to intepret this flat file, do some cross referencing and then post to ECC as a proper IDOC. To do this we need to be able to logically interpret the flat file (without the PSEGNUM and other referencing fields) so that the right sub segment values are mapped to the outgoing IDOC. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 17, 2010 7:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
All EDI_DD40 are fixed length in a message and variable length (EOR usually LF or CRLF) in a file droping trailing blanks.
The segment name is relevant for the parsing of the segment data but should not be relevant for the structure depth as you could potentially have the same segment at different levels in your IDOC.
You really should read the segment level to determine at which level in the tree you should attach the record. Keeping a running tally of the row# and looking at the parent row# will help too.
This looks to me a little bit as overkill like trying to feed an SAP IDOC file to the broker to load it to SAP. This file should be FTP'd (using MQFTE?) to the SAP server and ingested as an IDOC file. SAP has had for years some very good controls around this type of feed.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 17, 2010 8:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| This looks to me a little bit as overkill like trying to feed an SAP IDOC file to the broker to load it to SAP. This file should be FTP'd (using MQFTE?) to the SAP server and ingested as an IDOC file. SAP has had for years some very good controls around this type of feed. |
Uhm. I'd use the SAPRequest node instead of FTP...
And for the record, whilst MQFTE does likely actually perform FTP, and is in fact a perfectly fine and good replacement for FTP, it DOES NOT implement FTP over MQ. It does File Transfer over MQ, and can be configured to do FTP at an endpoint (I believe... I could be wrong, though) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 17, 2010 8:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sorry I wasn't clear. I meant using MQ-FTE as an alternative to FTP, making sure that the file gets there without truncation...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
