Skip to Content

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.

resim1.JPG

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

resim2.JPG

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

resim3.JPG

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:

resim4.JPG

For this program,  we have defined a structure zmaterial:

resim5.JPG

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).

resim6.JPG

The code in rectangles is added to the code.

REPORT zmateriallist.
TABLES:mara.

DATA:it_mara TYPE zmaterial OCCURS 0 WITH HEADER LINE.

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

DATA:pflag(1).

*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.

SELECT * FROM mara INTO CORRESPONDING FIELDS OF TABLE it_mara WHERE mtart = mtart.

*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.

IMPORT pflag FROM MEMORY ID ‘ZFLAGFROMBWFM’.

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

IF pflag IS INITIAL.

*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.
 
ENDLOOP.

ELSE.

*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. 

EXPORT it_mara[] TO MEMORY ID ‘ZMATERIALLISTTOBWFM’.
ENDIF.

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:

resim7.JPG

Tables tab:

resim8.JPG

Exceptions:

resim9.JPG

And the source code is:

resim10.JPG

resim11.JPG

  DATA: l_s_select TYPE srsc_s_select.
 
STATICS: s_s_if              TYPE srsc_s_if_simple,
           s_counter_datapakid TYPE
sytabix,
           i_e_t_data          TYPE
zmaterial OCCURS 0
                              
WITH HEADER LINE.
  DATA:
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.
     
WHEN ‘ZBW_MATLIST’.
        s_s_if
t_select[] = i_t_select[].
      WHEN
OTHERS.
        log_write
‘E’ ‘R3’ ‘009’ i_dsource ‘ ‘.
       
RAISE error_passed_to_mess_handler.
   
ENDCASE.
    s_s_if
requnr    = i_requnr.
    s_s_if
dsource   = i_dsource.
    s_s_if
maxsize   = i_maxsize.
   
APPEND LINES OF i_t_select TO s_s_ift_select.
    APPEND LINES OF
i_t_fields TO s_s_ift_fields.

    s_counter_datapakid = 0.
 
ELSE.
    IF
s_counter_datapakid = 0.

      REFRESH:lr_mtart.

      LOOP AT s_s_ift_select INTO ls_rsselect.
        CASE
ls_rsselectfieldnm.
          WHEN
‘MTART’.
           
MOVE-CORRESPONDING ls_rsselect TO lr_mtart.
            APPEND
lr_mtart.
        ENDCASE
.
     
ENDLOOP.

*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’.
     
EXPORT pflag TO MEMORY ID ‘ZFLAGFROMBWFM’.

*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’.     

IMPORT it_mara = i_e_t_data[]   FROM MEMORY ID ‘ZMATERIALLISTTOBWFM’.
   
ENDIF.

    IF i_e_t_data[] IS INITIAL.
     
RAISE no_more_data.
    ENDIF
.

    DO i_maxsize TIMES.
      s_counter_datapakid
= s_counter_datapakid + 1.
     
READ TABLE i_e_t_data INDEX s_counter_datapakid.
      IF
sysubrc NE 0.
       
CLEAR i_e_t_data[].
       
EXIT.
     
ELSE.
       
APPEND
i_e_t_data TO e_t_data.
      ENDIF
.
   
ENDDO.

  ENDIF.

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.

Regards

Yasemin ULUTÜRK

To report this post you need to login first.

58 Comments

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

  1. Raman Korrapati

    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.

    Thanks

    Raman

    (0) 
  2. Anshu Lilhori

    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.

    Regards,

    AL

    (0) 
    1. Yasemin ULUTURK Post author

      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 🙂

      (0) 
    1. Yasemin ULUTURK Post author

      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.

      Regards

      Yasemin…

      (0) 
      1. Anshu Lilhori

        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.. 😐

        Regards,

        AL

        (0) 
        1. Yasemin ULUTURK Post author

          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.

          Regards

          Yasemin…

          (0) 
          1. Anshu Lilhori

            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.

            Regards,

            AL

            (0) 
  3. Ashok Babu Kumili

    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. . .

    (0) 
  4. Krishna Chaitanya

    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.

    Regards,

    Krishna Chaitanya.

    (0) 
  5. Prashanth konduru

    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… 🙂 😎

    Regards

    KP

    (0) 
  6. Rajeev Parimi

    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

    regards

    Raj

    (0) 
  7. Bright Wang

    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.

    Bright

    (0) 
    1. Yasemin ULUTURK Post author

      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.

      Regards

      Yasemin…

      (0) 
  8. Suman Chakravarthy K

    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?

    Regards,

    Suman

    (0) 
    1. Yasemin ULUTURK Post author

      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.

      Regards

      Yasemin…

      (0) 
          1. Yasemin ULUTURK Post author

            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.

            (0) 
  9. Raj Gopal

    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,

    Raj

    (0) 
    1. Yasemin ULUTURK Post author

      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 🙂

      (0) 
  10. Sofie Havgård

    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.

    Regards

    Sofie H

    (0) 
  11. Ahmed S

    Appreciate. Your time and effort. I’m one among who got really good & right info from your posting.

    (1) 

Leave a Reply