topic Re: abap in Application Development and Automation Discussions

abap

Former Member — Sun, 04 Feb 2007 11:21:15 GMT

how many types of abap/4 programs?

Re: abap

Former Member — Sun, 04 Feb 2007 12:48:05 GMT

Hi Drash,

Mainly Following types of program are there in ABAP/4:

1) Executable Program

2) Include Program

3) Module Pool Program

4) Subroutine Pool

5) Interface Pool

Reward points if helpful answer.

Ashvender

Re: abap

Former Member — Sun, 04 Feb 2007 13:10:38 GMT

hi good

there are threee type of abap programming

1-Simple Report

2-Interaction

3-Module Pool Programming

Thanks

mrutyun^

Re: abap

Former Member — Mon, 05 Feb 2007 05:39:54 GMT

Hi,

 The following ABAP program types are relevant to application programming:

Type 1

Type 1 programs have the important characteristic that they do not have to be controlled using user-defined screens. Instead, they are controlled by the runtime environment, which calls a series of processing blocks (and selection screens and lists where necessary) in a fixed sequence. User actions on screens can then trigger further processing blocks.

You can start a type 1 program and the corresponding processor in the runtime environment using the SUBMIT statement in another ABAP program. There are also various ways of starting a type1 program by entering its program name. This is why we refer to type 1 programs as executable programs.

When you run a type 1 program, a series of processors run in a particular order in the runtime environment. The process flow allows the user to enter selection parameters on a selection screen. The data is then selected from the database and processed. Finally, an output list is displayed. At no stage does the programmer have to define his or her own screens. The runtime environment also allows you to work with a logical database. A logical database is a special ABAP program which combines the contents of certain database tables. The flow of a type 1 program is oriented towards reporting, whose main tasks are to read data from the database, process it, and display the results. This is why executable programs (type 1) in the R/3 System are often referred to as reports, and why running an executable program is often called reporting.

Since it is not compulsory to define event blocks, you can yourself determine the events to which your ABAP program should react. Furthermore, you can call your own screens or processing blocks at any time, leaving the prescribed program flow. You can use this, for example, to present data in a table on a dialog screen instead of in a list. The simplest executable program (report) contains only one processing block (START-OF-SELECTION).

Executable programs do not require any user dialog. You can fill the selection screen using a variant and output data directly to the spool system instead of to a list. This makes executable programs (reports) the means of background processing in the R/3 System.

You can also assign a transaction code to an executable program. Users can then start it using the transaction code and not the program name. The reporting-oriented runtime environment is also called when you run a report using a transaction code. This kind of transaction is called a report transaction.

It is appropriate to use executable programs (reports) when the flow of your program corresponds either wholly or in part to the pre-defined flow of the runtime environment. Until Release 4.5A, the only way to use a logical database was to use an executable program. However, from Release 4.5A, it is also possible to call logical databases on their own.

Type M

The most important technical attribute of a type M program is that it can only be controlled using screen flow logic. You must start them using a transaction code, which is linked to the program and one of its screens (initial screen). Another feature of these programs is that you must define your own screens in the Screen Painter (although the initial screen can be a selection screen).

When you start a program using a transaction code, the runtime environment starts a processor that calls the initial screen. This then calls a dialog module in the corresponding ABAP program. The remainder of the program flow can take any form. For example, the dialog module can:

• return control to the screen, after which, the processing passes to a subsequent screen. Each screen has a following screen, set either statically or dynamically.

• call other sequences of screens, selection screens or lists, from which further processing blocks in the ABAP program are started.

• call other processing blocks itself, either internally or externally.

• call other application programs using CALL TRANSACTION (type M program) or SUBMIT (type 1 program).

ABAP programs with type M contain the dialog modules belonging to the various screens. They are therefore known as module pools. It is appropriate to use module pools when you write dialog-oriented programs using a large number of screens whose flow logic largely determines the program flow.

Type F

Type F programs are containers for function modules, and cannot be started using a transaction code or by entering their name directly. Function modules are special procedures that you can call from other ABAP programs.

Type F programs are known as function groups. Function modules may only be programmed in function groups. The Function Builder is a tool in the ABAP Workbench that you can use to create function groups and function modules. Apart from function modules, function groups can contain global data declarations and subroutines. These are visible to all function modules in the group. They can also contain event blocks for screens in function modules.

Type K

You cannot start type K programs using a transaction code or by entering the program name. They are containers for global classes in ABAP Objects . Type K programs are known as class definitions. The Class Builder is a tool in the ABAP Workbench that you can use to create class definitions.

Type J

You cannot start type J programs using a transaction code or by entering the program name. They are containers for global interface in ABAP Objects. Type J programs are known as interface definitions. Like class definitions, you create interface definitions in the Class Builder.

Type S

You cannot start a type S program using a transaction code or by entering the program name. Instead, they are containers for subroutines, which you can call externally from other ABAP programs. Type S programs are known as subroutine pools. They cannot contain screens.

Type I

Type I programs - called includes - are a means of dividing up program code into smaller, more manageable units. You can insert the coding of an include program at any point in another ABAP program using the INCLUDE statement. There is no technical relationship between include programs and processing blocks. Includes are more suitable for logical programming units, such as data declarations, or sets of similar processing blocks. The ABAP Workbench has a mechanism for automatically dividing up module pools and function groups into include programs.

Hope this helps.

Reward if helpful.

Regards,

Sipra

Re: abap

Former Member — Wed, 04 Apr 2007 09:42:13 GMT

Dear all,

we have two systems called G9D and GHD, we have remote function module in the G9D with reface call connection name as G9D. i have an account in the above two systems. But when i am trying to access function module from GHD system,i am getting the sort dump in the following way,

Error analysis

An error occurred when executing a REMOTE FUNCTION CALL.

It was logged under the name "RFC_NO_AUTHORITY"

on the called page.

can any body help to solve it out, and also can anybody give the table name where we can maintain the Trusted host names . for accessing the target system to execute the function module.

Re: abap

Former Member — Tue, 11 Sep 2007 14:35:29 GMT

Hi,

Abap/4 Program types

1)Executable Program example Normal report programs. we can represent with type :1.

2) Include Program for exmaple if we want to use same code in multiple progrma then we place code in some include program and we declare this include in our program_2 like Include ZRE_CALCULATION.

so that what ever variables declared in that include ZRE_CALCULATION program we can use in program_2.Main purpose is code reusability and program looks simple and understnadble.

we can represent with type :I.

3)Module pool Program :All the transaction programs like MM01 program any things that works with screen elemenst need to submit some input and after validation wants to update some tables in database means we use module pool programs.

here we have concept Screen number and corresponding flow logic for every screen.we will create transaction code for each module pool program and thru tcode we will execute.

we can represent with type :M.

4) Function Group :collection function modules.so when ever you are calling some function module means all the the functions in that function group will be loaded into our program.

here common varaibles will be declared so that reusability.

function module can be tested independently by giving input thru SE37 tcode.

5)Subroutine pool: collection of subroutines will be written here so that subroutines declared under this will be available to other programs also.

otherwise subroutine is specific to confined to taht program only.other programs cant reuse this subroutine declared under one program in another program.

6)Interface pool : OOPs concept

7) Class pool :again OOPs concept

i think you got some idea

thanks