| Author |
Message
|
| jbanoop |
 Posted: Wed Jun 09, 2010 12:55 pm Post subject: Parse Flat File IDOC with WMB 7 |
 |
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
All,
Env:
AIX
WMB 7.0
MQ 7.0.1
We needed to parse IDOCs in the Flat-File format (524 byte control segment, variable length data segment with line delimiters) using WMB.
The message sets created using enterprise Service Discovery (ESD) is apparently expecting the IDOC in the ALE R3 Link format (contagious 524 byte control segment followed by each data record of size 1063 bytes).
Is there a way to accomplish this ?
Any inputs would be really helpful |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jun 09, 2010 8:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Use a BLOB preprocessing stage.
Output each line into it's own format (EDI_DC40 / EDI_DD40) and keep together with a groupid. Assemble the group and you have the IDOC in the expected format... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jun 10, 2010 1:50 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Why can't you parse the variable-length stuff using a TDS message set, and output the fixed-length version using a different TDS message set? |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Jun 10, 2010 6:56 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Kimert and fjb_saper,
The requirement is like this:
there is an application which sends a message to a queue to be processed by WMB. This message is in the flat IDOC format.
Now, I can create the message set (for that particular IDOC type) using the WMB adapter connection (ESD) from ECC. However, this messageset uses the DataObject domain and is expecting an R3Link format for the incoming message and fails with the flat file format of the IDOC.
The two options I could think of were:
1)Pad the IDOC segments with spaces, remove the carriage returns and then parse it using the above created message set.
or
2)Tweak the message set created by ESD, add a TDS wire format and change the properties accordingly to be able to parse the delimited IDOC format.
The con with #1 is that every IDOC we receive from this application would have to undergo this conversion from delimited to R3Link format just so that the generated message set can parse it.
The con with #2 is that each generated message set will have to get manually retrofitted to parse the delimited format.
I was wondering if there was a way of directly generating message sets using ESD or otherwise (support pacs etc) which would be able to parse the delimited format.
Regards,
Anoop |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 10, 2010 12:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Anoop,
I believe the file format drops any trailing spaces.
This means that it could drop more than just the unused space until the end of the segment....
By using a preprocessing method that restores the full length of the IDOC segment and inserts the R3Link header, you ensure that the processing does not get too complex...
By the way, why process from a file and not use ALE for processing those IDOCs?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jbanoop |
| Posted: Thu Jun 10, 2010 1:06 pm Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
fjb_saper,
| Quote: |
| 1)Pad the IDOC segments with spaces, remove the carriage returns and then parse it using the above created message set. |
I just wanted to clarify that your reference to the "preprocessing" approach refered to the statement above.
| Quote: |
This means that it could drop more than just the unused space until the end of the segment....
|
So in this case even SAP would have prolbems trying to parse a file IDOC it creates isnt it ?
I didnt quite understand what you meant by the R3Link header. Is it something other than the DC and the DDs ? I have looked at the IDOC content generated by the adapter node and it looks to be 524 byte DC followed by n*1063 DD segments without delimiters (contagious).
Is this R3Link header something I am missing ?
About your question of why process from a file:
Apparently there exists a legacy system (non-SAP) here which creates files/messages in this (file IDOC) format. We (WMB) needs to parse, transform (to canonical),transform (to target IDOC struct) and then route these messages into ECC.
Am trying to sort my way through a myriad of requirements and working around/ tweaking various functionalities of these adapter nodes. I am also relatively new to working with these adapter nodes and IDOC passhrough concepts and hence might be missing something. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Thu Jun 10, 2010 2:00 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| jbanoop wrote: |
| Apparently there exists a legacy system (non-SAP) here which creates files/messages in this (file IDOC) format. We (WMB) needs to parse, transform (to canonical),transform (to target IDOC struct) and then route these messages into ECC. |
So, as Kimbert said earlier today, why can't you use one message set for the input and the ESD generated message set for the output.
Or just do it all in ESQL maybe 
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| redcherry |
| Posted: Mon Sep 15, 2014 10:56 am Post subject: Idocs as text string |
|
|
Newbie
Joined: 25 Jul 2014
Posts: 4
|
Hi Anoop,
We are facing similar problem. SAP Idocs are received via MQS as Text String.
what approach should we take?
Thanks! |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Sep 15, 2014 11:35 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
redcherry,
You opened an old post. Best to start new. jbanoop has not posted in a very long time, so don't get your hopes up on this post. |
|
| Back to top |
|
|
|
|
