Skip to Content

How To Generate a Datasource From a Custom Report In ECC

When more analysis on a custom report in ECC system is required, users ask for a bw report that shows exactly the same data with the custom report in ECC. In standard cases, the rational behavior would be to search for business content if there is any corresponding content for the requirement. Most of the time, we can’t find it in business content (That may be the reason why a custom report is written in ECC J). In such cases we have some alternatives to go with. In this blog I am going to discuss three alternatives, compare the advantages and explain the solution to the one which I mostly prefer.

The information I give does not include any detailed ABAP knowledge, but gives an understanding on how we can handle these types of requirements. I am not an ABAP developer, so, in this blog I will only give the sufficient ABAP code to make changes in necessary spots in your report and function modules.

The Alternative Solutions:

1.     1. Creating a function module:

In this approach, we can write a function module that exactly behaves the same way as the program of the custom report. Then we create a datasource using function module. This approach is nothing different than creating a totally new datasource according to a new requirement. You can only use the logic in the program. You can directly upload your infoprovider using this datasource.

2.     2. Using the program of the custom report to fill in a Z table:

With a minor change in the program, we can add some code to fill in a Z table. Then we can create a datasource with extraction from view.  We use z table as the source. This is an easier way compared to the previous alternative.  You don’t need to write the whole logic once more. Everything is thought once. When a change request in the logic comes from the user, the change is implemented only in the program. As long as the fields of the custom report are not changed, there is no maintenance for change requests (I am assuming full upload to infoprovider). Even if a change in fields arrives, the only thing we need to do would be replicating the datasource and changing the Z table.

3.     3. The final approach I am going to give in detail is changing the report code so that we can call it from another function module. Then we use this function module to create the datasource. This is even better than the second approach. In this approach we don’t need to create a Ztable. So we have some performance related gains. We don’t spend a space in ECC for Ztable. We don’t require the time to write into that table and also read from that table. When the function is called to upload an infoprovider, the code calls the report code to generate the data we require. Now let’s go with the details. I will explain this approach with a sample report where we show a very small information from MARA table.

Detailed Explanation for 3rd Approach:

For the detailed explanation, I got some help from my ABAP developer colleague, Gozde Candan. We have created a very simple program that gets the list of materials according to a material type selected in the selection screen. We also have created a transaction for this program. This is only for illustration. It does not matter how complicated the code is, you can reorganize the code in such a way I describe in this blog. We have written the program with a single select statement, so that it would be easier to show how we change it.

Suppose we have a transaction called ZMATLIST.  This transaction gets the list of materials according to a material type selected.


To find the name of the program behind this transaction, we go to the system menu on top of the screen:


When we select status, a screen appears showing SAP data:


In the field “PROGRAM”, we see the name of the program that we make the changes so that the code inside can be called within a function module.

With the transaction code se38 we can view the code for this program:


For this program,  we have defined a structure zmaterial:


This structure is created with TCODE: SE11. This part is important, because we will use this same structure for the datasource. If the design of the code does not include (most of the time it does, but in some cases it may not include) a structure like this, then it should be changed so that before it flows to the gui screens, an internal table defined by such a structure should be filled with the data .

Now we go on by editing this program. What we are going to do is adding a flag to the program to understand if it is being imported by a function module. In the function module, we are going to set this flag. So we will import the value of this flag from function module to this program. Reading the value of the flag, we are going to export the to the function module. That is; we are doing one import for the flag value (from function module) and one export for the data (to the function module).


The code in rectangles is added to the code.

REPORT zmateriallist.


*pflag is the name of the flag we define. You can give any name.


*This part is the simple selection statement according to the parameter (material type) selected in the

*selection screen of the gui. The data is filled in an internal table called it_mara. For complicated z reports,

*this part can be much more longer. The idea here is filling in the internal table it_mara.

parameter:mtart TYPE maramtart.


*What we do with the below IMPORT statement is that, we get the value of pflag importing from the function

Memory id is a unique id, we can give any name. We will use

*module using memory id ‘ZFLAGFROMBWFM’.

*this same id in the function module to export pflag.


*We add an if statement to make any necessary changes for showing the data.


*In this part, since pflag is not set, we understand that the data generated should be shown in gui screen.

*So any gui related code is written in this part. 

LOOP AT it_mara.
WRITE:/ it_maramatnr, it_maraersda, it_maraernam.


*In this part, pflag is set from the function module as ‘X’. Thus, we export the data from it_mara to the internal

*table defined in the function module with the memory id ‘ZMATERIALLISTTOBWFM’. This unique memory is

*going to be used in the function module to import the material list to i_e_t_data defined in the function module. 


That is all we do in the report code. Now, it is time to create a function module for our datasource. What we need is a function group where LRSAXD01 is included in the top. I will not explain in detail how to create a function module for bw. Though, here are the screenshots of the function module we have created:

Import tab:


Tables tab:




And the source code is:



  DATA: l_s_select TYPE srsc_s_select.
STATICS: s_s_if              TYPE srsc_s_if_simple,
           s_counter_datapakid TYPE
           i_e_t_data          TYPE
zmaterial OCCURS 0
ls_rsselect TYPE rsselect.

*We need to define pflag here, too. 

  DATA: pflag(1).

*This part is standart for all bw functions, lr_mtart is defined to enable      

*the material type for selection. ‘ZBW_MATLIST’ is the name of the datasource

*we will define.
RANGES:lr_mtart FOR zmaterialmatnr.
IF i_initflag = sbiwa_c_flag_on.
CASE i_dsource.
t_select[] = i_t_select[].
‘E’ ‘R3’ ‘009’ i_dsource ‘ ‘.
RAISE error_passed_to_mess_handler.
requnr    = i_requnr.
dsource   = i_dsource.
maxsize   = i_maxsize.
APPEND LINES OF i_t_select TO s_s_ift_select.
i_t_fields TO s_s_ift_fields.

    s_counter_datapakid = 0.
s_counter_datapakid = 0.


      LOOP AT s_s_ift_select INTO ls_rsselect.
MOVE-CORRESPONDING ls_rsselect TO lr_mtart.

*In this part, we do everything necessary to for loading data. As an initial

*step, we need to send the value of our flag to the report code so that it can

*export the data to this function. Remind that we use the same memory id in

*report code to import the value for pflag. With this EXPORT statement, in

*memory to a space called ‘ZFLAGFROMBWFM’, the value of pflag is written as

*‘X’. The IMPORT statement has to be called from the report code with the same

*memory id, to get the value of pflag.     

pflag = ‘X’.

*Now, the value of pflag is exported to the program ZMATERIALLIST. When we

*submit, the report code is called. We also need to send the required

*selections in this submit command. If no selection is required for BW data

*upload, then in this part, we can remove the assignment of material type. But

*in this case, we need to add some extra code to the selection statement in

*the report code.
SUBMIT zmateriallist  WITH mtart = lr_mtartlow AND RETURN.

*And as the final step, we import it_mara from ZMATERIALLIST program to our

*internal table i_e_t_data with this unique memory id: ‘ZMATERIALLISTTOBWFM’.     


    IF i_e_t_data[] IS INITIAL.
RAISE no_more_data.

    DO i_maxsize TIMES.
= s_counter_datapakid + 1.
READ TABLE i_e_t_data INDEX s_counter_datapakid.
sysubrc NE 0.
CLEAR i_e_t_data[].
i_e_t_data TO e_t_data.


Finally we create our datasource using extraction by FM. We use ZBW_MATERIAL_LIST function, we created. And as the structure we select ZMATERIAL which we used in both report code and the function module itself.

As a result, this approach uses the same code for both ECC and BW reports, thus, helping prevent the repetitive software development. One more advantage is that, when a change request arrives from the users, it is only done in report code. No extra effort is spent for BW side. In this blog I gave a sample using import and export statements. There may be other methods that uses this idea. I tried to explain the one I know 🙂

I hope, this blog to be helpful for both BW experts whom are not familiar with ABAP and ABAP developers whom are not familiar with BW codes.



You must be Logged on to comment or reply to a post.
  • Hi Yasemin,

    Good approach and nice explanation. Bit tricky to understand code as bw cosnultant but worthy one. Good job. Thanks for your efforts and sharing.



  • This is simply superb Yasemin..I need to go through it again to get complete understanding of the process you followed.But i must say its worth reading.

    Thanks for sharing this approach,will definitely come handy someday for sure.



    • Hi Anshu,

      Thank you for your very nice comment. I used this procedure a few times, always getting the help from ABAP developers. Writing this document even made me better understood what we were doing 🙂

    • Hi Purushothama. Thank you for the feedback. I tried to make it easy to understand, as much as I could. Though, since we are not ABAP developers, every subject related with ABAP comes difficult to us 🙂 Please let me know the parts which you had difficulty, I will try to change those parts to make it more understandable.



      • Hi Yasemin,

        I truly agree with you.Can you do a favor to us by putting some more light on the concept of Memory id as i am not aware of it.

        May be some link or some concrete example.I hope its not going off the track.. 😐



        • Hi Anshu,

          When I get some more feedback, I will go through all comments and update with a new version of this document. I will add some usefull links to make it more clear. About memory id, ,t ,s used with the IMPORT and EXPORT statements in ABAP. When you EXPORT some parameter or table, it needs a place in memory. Memory id is simply the address of that place. You can give any name. And there is no maintenance for that. You don’t create it by using some customizing or setting. Just in the code, you give something unique. And it becomes the address for any import statement in any other ABAP code. I will search for usefull links for the use of memory id, too. Hope it gives an idea.



          • Thanks yasemin for your time and effort and taking the pain to explain me the concept of memory id.Now at least i got some clue on the same and probably when i use them somewhere in the code,ll have more precise idea.



          • Your welcome Anshu 🙂 I am glad that it has been worth to post this 🙂 Again thank you for your feedback and comments. Cheers…

  • Hello Yasemin ULUTURK,

    Perfect document to understand the concept of  “How To Generate A Datasource From A Custom Report In Ecc”. Very nicely written article. It has been summarized very nicely with step by step procedure. . 

    Dealing with Datasouce is very critical activity during any implementation project. Thanks for the screen shots, Code and real time examples used. . .

    The message was very useful. I learnt the key views. . .

  • Hi Yasemin

    Woooooooow  🙂 very useful document.  Nicely explained all step by step approach and how to design the datasource and the source code in FM.  Great Job.  Really thanks a lot for sharing this to all of us.


    Krishna Chaitanya.

  • Hi Yasemin,

    Gr8 job … nice, well drafted document with clear explanation.

    Like the idea and your approach to get the data into BW.

    Thanks for your effort once again and thanks for sharing.

    Rated the Blog and bookmarked the blog… 🙂 😎



  • Good effort Yasemin. Also I appreciate the energy levels of Raman and Suman for their contribution not just answering queries but also contributing ..keep going guys



  • Hi, Yasemin,

    It looks your 3rd solution is something like comination of 1st(one generic FM without detail logic) and 2nd solution(use memory instead of table).

    Nice try.


    • Hi Bright,

      In fact the proposed solution is not a combination of the first two. Because in first two alternatives, the code has to be written from scratch. The third solution offers using the written code in ABAP report. Thank you for your comment.



  • Hello Yasmein,

    I like your approaches. We follow first approach in our organization. Your whole idea is good. This gives some confidence to BWer to develop custom data sources with the help of ABAPer with minimal code. 3rd one is bit tough for BWer but easier for ABAPer, though it is good. Thanks for sharing your and your colleague’s thoughts. Great efforts..

    When you edit the ABAP report code, does it impact the ABAP report in ECC? What needs to be taken care after editing?



    • Hi Suman,

      Thank you for your feedback. As always you, Raman and Anshu spent your precious time on reading and giving very nice feedback. Editing the ABAP code does not impact the ABAP report. It just requires the diversion to be made between the if and else statements. For example if some other logic is included in ABAP report, then it should be handled within the if and else statement of the flag variable. It sometimess get more difficult when there are many selection criteria in ABAP report but no selection criteria in BW. In these situations some more code may have to be added to deal with the selection variables. We use this scenario in very complicated reports. Because it may require a great deal of effort when writing from scratch.



          • Yes, in that case the only alternative is going with approach 1. But normally ABAPers would want to deal with approach 3, because the testing of the new function would require much more effort. Both reports should match exactly, in complex scenarios it may be too difficult to match both reports. As I mentioned the advantages of the third approach in the blog, an ABAPer will know the advantage of this approach. When a change request in the report arrives, normally ABAPers will have to do changes in both report code and bw function code if they use the first approach. And there will be another cost of writing the code from scratch in the first approach.

  • Hi Yasemin,

    Today I had a chance to look at your document. I was wondered that how a non Abaper can prepare such a marvelous document. It’s truly professional and helpful to most of the functional consultants like me. In addition it also boosts our interest to try and develop some tiny programs to gain the time.

    Great job! Keep sharing such a wonderful and unique documents for the benefit of the SAP Community 🙂

    Kind regards,


    • Hi Raj,

      Thank you very much for your very nice comment. Since we face such requests often, we decided to find a generic solution that will have an easy way to manage the changes. When the report and BW datasources are managed seperately, the change requests made for ECC report may not be reflected in BW reports (This may occur since the users of ECC and BW reports may differ; if a user only uses the ECC report and need some change, s/he opens a change request for ECC report and as a result the change is not reflected in BW). Vice versa is also possible. This arises the complaints such as “the report results are not the same, one of them is wrong” from the users that both use ECC and BW. That is why we developed this approach. As I have mentioned in my blog, I got help from my ABAPer colleague Gozde Candan. I am very glad that functional consultants can also use this approach 🙂

  • Thank you so  much for this great article. I am facing a similar issue where I need to extract SAP report S_ALR_87012936 (program RASIMU02) to BW as a snapshot each quater. The code in RASIMU02 is quite challenging and since I am no APAB expert (and do not have access to any ABAP expert) I do not really know how to move on… there are no simple, defined structure for output in the program and I am not quite sure how to move on… any suggestions?

    I have posted this issue at SCN aswell, but have not yet received any helpful answers…

    Thanks in advanced.


    Sofie H