Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Constructing ABAP statement dynamically...

Former Member
0 Kudos

Hello Gurus,

I have a custom report (ZREPTA) which calls another generic custom program (ZGENERIC) inside. This program is

used by many other custom reports. Now this generic custom program has as a perform routine. The form-endform for this perform is written in the custom report which is calling the generic custom program. Now its not necessary that all custom reports needs the peform routine of generic custom program (ZGENERIC).

My question is how do I build the following ABAP lines of dynamically so that even if other program

say ZREPTC calls ZGENERIC, it won't be a problem even if it does not have form routine defined

since the perform statement in ZGENERIC is build dynamically.

perform post_process tables doc_connect.

Regards,

Jainam.

Edited by: Jainam Shah on Oct 2, 2009 9:08 PM

Edited by: Jainam Shah on Oct 2, 2009 9:08 PM

1 ACCEPTED SOLUTION

Sandra_Rossi
Active Contributor
0 Kudos

Many generic SAP applications implement a callback mechanism (ALV, etc.). You can do the same way, for example:

zrepta :

PERFORM routine IN PROGRAM zgeneric USING 'ZREPTA' '<callback_routine>' ...

zgeneric :

PERFORM (callback_routine) IN PROGRAM (callback_report) TABLES doc_connect IF FOUND.

9 REPLIES 9

Former Member
0 Kudos

Hi,

if you are sure that only ZREPTA will be using that perform routine, then in the ZGENERIC report you may add the condition


 if sy-cprog = 'ZREPTA'.
post_process tables doc_connect.
endif.

By this only if the calling program is ZREPTA, the perform will be executed and for others it will be skipped

Regards,

vikranth

0 Kudos

No I don't want to do like that. Because I am working on module development in whcih there can be 100's of reports from which some will and some won't use that.

There is soemthing called 'GENERATE SUBROUTINE POOL tab name prog', which I guess I can use with append statements to build ABAP code.

Regards,

Jainam.

Edited by: Jainam Shah on Oct 2, 2009 9:26 PM

Edited by: Jainam Shah on Oct 2, 2009 9:28 PM

0 Kudos

Hi Jainam,

be careful, better stay away from GENERATE SUBROUTINE POOL because it causes an implicit database commit. All database modifications done before are not rolled back in cause of subsequent error.

Regards,

Clemens

Former Member
0 Kudos

Avoiding the temptation to use generic subroutines is the best option in my opinion.

> Because I am working on module development in whcih there can be 100's of reports from which some will and some won't use that.

Why dont you create a function mode then which only uses this form if requested to do so). But it also might involve exposing the parameter to it's interface so you need to be carefull if it is remote enabled.

That is what FM's are for -> modularization.

Cheers,

Julius

Edited by: Julius Bussche on Oct 2, 2009 10:01 PM

0 Kudos

Hi julius,

Any cons of using generic subroutines?

кu03B1ятu03B9к

0 Kudos

- bad performance if used repeatedly

- not easy to maintain : you must maintain the generator instead of the code itself

- source disappears when the internal session ends, it's VERY disturbing in case of bug. And there is no cross-ref (where-used list).

- 36 calls maximum by internal session

Sandra_Rossi
Active Contributor
0 Kudos

Many generic SAP applications implement a callback mechanism (ALV, etc.). You can do the same way, for example:

zrepta :

PERFORM routine IN PROGRAM zgeneric USING 'ZREPTA' '<callback_routine>' ...

zgeneric :

PERFORM (callback_routine) IN PROGRAM (callback_report) TABLES doc_connect IF FOUND.

Clemenss
Active Contributor
0 Kudos

Please see documentation on PERFORM ... IF FOUND.

This may solve your question.

Regards,

Clemens

venkat_o
Active Contributor
0 Kudos

<repeat_of_already_provided_answer_removed_by_moderator>

Edited by: Julius Bussche on Oct 4, 2009 7:35 AM