Skip to Content

Hi Guys!

During one integration project I met a customer requirement to process fixed length flat files and transform them into IDocs in target R/3 system. Usually this is not a big deal, unless your files contain objects, which may consist of one, but also of multiple lines of the file. So let’s imagine, our source file looks like following:

PO25685644DocumentNo1Item1  95320022008USER1                                          
PO25685644DocumentNo1Item2  95020022008USER1                                          
PO25685645DocumentNo2Item1  80020022008USER1                                          
PO25685645DocumentNo2Item2  92020022008USER1                                          
PO25685645DocumentNo2Item3  92120022008USER1                                          
PO25685646DocumentNo3Item1  01220022008USER1

with this structure:


  • Document ID (10)
  • Text (18)
  • Quantity (3)
  • Date (8)
  • Username (8)

Here we can see, that the first document consists of 2 lines, 2nd of 3 lines and the 3rd one of 1 line. So it is clear, that we can not use standard file conversion, because we won’t be able to collect appropriate lines to one target idoc. This would be possible, only if each line would be one IDoc or entire file would be one. File sender adapter has no possibility to differentiate documents based on some changing values (document id in this case). But what the file sender adapter can, is to separate data into multiple recordsets using keyFieldValue parameter. Unfortunately, we don’t have in our source file any value, which could be used for this purpose. Creating such a field by changing the content of a source message will solve our problem.

So when we change the source message content to look like the one below, we will have our key field and we can create separate recordset for each IDoc and it doesn’t metter, if one document consists of 1 or 100 lines, each line will be added to the right target IDoc. Everything we need to do to achieve this is to develop an adapter module, which adds this new field to our source message.

This is how the source message could look like after transformation by adapter module:

—-PO25685644DocumentNo1Item1  95320022008USER1                                          
—-PO25685644DocumentNo1Item2  95020022008USER1                                          
—-PO25685645DocumentNo2Item1  80020022008USER1                                          
—-PO25685645DocumentNo2Item2  92020022008USER1                                          
—-PO25685645DocumentNo2Item3  92120022008USER1                                          
—-PO25685646DocumentNo3Item1  01220022008USER1

With this structure will the adapter be able to create separate recordsets – each new recordset (and IDoc document) begins with key field value equal to “++++”.

So let’s help the adapter to produce such a document using custom adapter module. If you are not familiar with adapter module development. this document will help you. As a transformation routine you can use following code. It is a simple method, which transforms a string parameter into desired structure. Just add this method to your adapter module code.



As you can see from the code, the adapter module uses 2 parameters: keyFieldStartIndex and keyFieldLength. This allows you to use it for different file structures, where the key field (document number in our case) can be in the middle of line, for example and not just in the beginning. In our case we will use for the parameters values 0 (keyFieldStartIndex) and 10 (keyFieldLength).

After you have developed and deployed the adapter module, configure the sender file adapter parameters which ensure appropriate message processing.

Sender File Adapter Configuration: 

First, you must add the developed adapter module to the 1st place in the Processing Sequence of the communication channel, so your sequence could look like below (depends on the JNDI name of your adapter module).

NOTE: Since you need to run the custom adapter module before the standard conversion module, you must use as a Message Protocol (Parameters tab on the Communication Channel) File instead of File Conversion and set up file conversion  module and parameter values explicitly. So the configuration could look like this:


Order of processing adapter modules




Repository Objects Configuration:
Source Message Data Type:

Data Type must of course match the source message, but its design must meet the structure after file is being processed by adapter modules. So in my case would the Data Type look like below. Notice please, that occurences of Recordset and IDocItem elements are unlimited.



Message Mapping:

And finally, create proper message mapping. To be able to create multiple idocs in target system, read please Michal’s The specified item was not found.. When you have modified IDoc’s XSD, import it into Message Mapping’s Target Message using the “pick-up” question mark on the right.




When IDoc’s XSD imported, select the source message MT_Orders (if not done yet) and create the mapping. Notice, that every Recordset is a separate IDoc document and you can map items to IDoc segments. Mapping of these two elements could look like this (just example to explain the occurence):




Well, and that’s it! Now you can process files and will see incoming IDocs in R/3. Of course, in real world there is a lot of possible source file structures and a lot of possible ways to modify them using adapter modules, so use please this blog just like an idea, how it could be done.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Denise Glancy
    Peter, thank you for sharing this great idea on SDN!
    My one comment though is that you should not use such strong statement as “it is clear, that we can not use standard file conversion, because we won’t be able to collect appropriate lines to one target idoc”.
    In fact I did such message mapping, it is no big deal to use a flat input structure like yours and manipulate the context change to generate multiple IDocs with header(s) and line items.
    Otherwise thanks again for the excellent blog!
  2. VR krishnaraju mudunuri

    Good blog, but we can achieve the above kind of scenarios without using adapter modules.

    Instead, we will create recorset for every line in the file. Then, by using node functions Format by example and sort by key and split by value we can create the multiple idocs based on the PO number.



Leave a Reply