| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| convert R/3 Link format - Flat File IDOC format |
View previous topic :: View next topic |
| Author |
Message
|
| jbanoop |
 Posted: Tue May 25, 2010 6:36 am Post subject: convert R/3 Link format - Flat File IDOC format |
 |
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Hi,
Env : WMB 7.0 IFIX2, MQ 7.0.1, WinXP SP3
We are receiving IDOCs from SAP using the SAPInput node in the R/3 link format (the format without the line breaks) and being parsed by the DataObject parser using the messageset of the IDOC type (obtained by Enterprise Service Discovery).
Now one of the requirement is to convert this format into the flat file format (which adds carriage returns at the end of each segment) while writing it out to the target.
Is there a simple way this can be achieved without having to create different target message sets with the delimiters.
Regards, |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue May 25, 2010 10:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Create a generic Idoc message set:
1 EDI_DC40
1-n EDI_DD40
add a CRLF at the end of each of those...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jbanoop |
| Posted: Wed May 26, 2010 5:19 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
thanks fjb_saper , I will try that.
for anyone who was wondering (like me) what the format of the R/3 Link IDOC is...
| Quote: |
A flat IDoc is one that is saved to the file system by SAP—for example, when an
IDoc is sent to a Port that has a type of “File”. Its records are delimited by carriage returns, the
DC record always being 524 bytes long and the DD segment records being variable length.
Conversely, an R/3 Link format IDoc is a fixed-length structure containing a 524-byte DC
record followed by one or more 1063-byte DD records. It contains no carriage returns or other
delimiting characters.
|
Regards, |
|
| Back to top |
|
|
| jbanoop |
| Posted: Wed May 26, 2010 7:15 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
I tried the following Msg Set :
| Code: |
File_IDoc (msg)
|
|- DC (Min occurs 1, Max Occurs 1, Fixed Length, Grp Term <CR><LF>)
| |- DCContent (String, Min Occurs 1, Max Occurs 1, Fixed Lengh, 524)
|
|- DD (Min Occurs 1, Max Occurs -1, Fixed Length, Grp Term <CR><LF>)
|- DDContent(String, Min Occurs 1, Max Occurs 1, Fixed Length,1063)
|
Now the MRM is able to parse the ALE IDOC content (I can see the parsed structure corresponding to the model above in the Debugger after the RCD with parse option set to Immediate)
How ever when the Output is being written to the queue, the <CR><LF> terminators are not getting written out. The output data is still in the same format as the input (R3 Link format).
Any inputs on what I could be missing here would be very helpful.
Regards, |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed May 26, 2010 8:36 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
If you haven't changed the message at all, message broker will not ask the parser to write the message - it will just output the input message.
Your parsing should really fail, because the input doesn't contain the <CR><LF> terminators. However, the MRM parser is lax about group terminators, so it doesn't complain.
You should
- add a second TDS physical format to your message set.
- call the existing physical format 'FlatFile' and call the new one 'R3Link'. The 'R3Link' physical format should not have the <CR><LF> terminators.
- change the input node Message Format property to use 'R3Link' instead of 'FlatFile'.
- add this single line of ESQL to your flow:
| Code: |
| SET OutputRoot.Properties.MessageFormat='FlatFile'; |
Now your flow is obviously changing the output format. Message broker will detect that, and will ask the parser to write the message. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Wed May 26, 2010 10:41 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Kimbert,
As always your advice worked. Thanks a lot.
I had a question though. From what I understand about the RCD node, it sets the message properties so that the next time the flow (parser) parses the message it uses those new values to interpret the message.
What happens if the parse timing on the RCD node is set to Immediate.
Does this not cause a parse of the message using the new values on the RCD node itself ?
I was trying to achieve the following :
IDOC specific MsgSet on the input node --> RCD node setting the MsgSet to the Generic IDOC file format (with <CR><LF>. Parse timing Immediate) -> MQ Output
When I debug the flow, I do see the MRM parsed message after the RCD node. So I assumed that the message was reparsed. If it was not parsed, how was the new MRM structure being reflected on the logical message tree ?
Regards, |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed May 26, 2010 1:38 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
So the RCD node is really just doing the same thing as my line of ESQL - it's changing the output physical format. The RCD node is changing the message set rather than the MRM physical format, but the effect is the same.
I suspect that the RCD node is serializing the message, then parsing it with the new settings. You won't be able to detect that using the debugger/Trace nodes because the message tree would be identical before and after the RCD node. I expect Parse Timing is set to 'On Demand' on the input node so the message will not actually be parsed before the RCD node. That means that the 'serializing' step will be a no-op.
If you take a user trace, you will soon find out what the message flow is doing. Sorry to be so predictable, but it's true. |
|
| 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
|
|
|
|
