• Reports are ABAP/4 programs.
• You use reports to evaluation data from database tables. The results of such an evaluation can be displayed on the screen or printed form.
• Reports are stand-alone programs.
• The user can execute reports directly via the program name, for example, by choosing System ® Utilities ® Reporting.
• A report program contains a collection of processing blocks for different events that are always triggered externally. In a report, you can react on events by programming the corresponding processing blocks or ignore the events by not writing the corresponding processing blocks. A report itself never creates events.
• Reports can use logical databases or select statements defined by developer.
• For each application, SAP supplies logical databases. Or you can easily create logical database yourself.
• Event control of a report corresponds to a certain scheme:
When a report is executed, the ABAP/4 processor creates together with the logical database used (if any) a sequence of certain events for which you can program processing blocks. The chronology of the events is (more or less)
Steps involved in creating a Report:
1. Processing the selection screen
After starting a report, the selection screen allows the user to enter limits or control values for further report processing. The report can contain several processing blocks for events during selection screen processing, for example, for checking the input values.
2. Reading the database
After selection screen processing come the events for reading the database. Either the report reads data from relational databases it using the corresponding ABAP/4 statements (open SQL) or leaves this task to a logical database. In the latter case, the logical database creates a sequence of events to allow the report to copy the data.
3. Evaluating data and creating lists
During or after reading the database the report creates the output list. During list creation, several events allow you to layout the output list (for example, layout the page header).
4. Outputting a list
The last part of the processing sequence controlled by the ABAP/4 processor is the list output on the screen or printer. When displaying the list on the screen, user can trigger other reports, that are interactive and are event driven. For example, by clicking the mouse. By programming processing blocks for these events, you change a normal report to a so-called Interactive report. If a report does not contain event keywords, the entire coding of the report belongs to a single processing block, which is called by a standard event. This standard event is triggered directly after processing the selection screen.
DIALOG PROGRAMS
• You use dialog programs to execute transactions. The users of dialog programs in dialog sessions read and change database tables. Apart from the actual data processing (Open SQL), update and enqueue concepts are of great importance when programming dialogs.
• Dialog programs are not stand- alone
• To execute dialog programs, they must be linked to at least one screen that itself is linked to a transaction code. The transaction code determines the initial screen with which the dialog session starts.
• Dialog programs are controlled by screen flow logic
• The actual ABAP/4 dialog program is a so-called module pool. A module pool contains a collection of dialog modules that are called by the screen flow logic.
• To each module pool, at least one, but usually several screens are allocated. Each screen has flow logic. The flow logic consists of PBO (process Before output) and PAI (process After Input) blocks. This flow logic does not use the ABAP/4 programming language and the ABAP/4 Editor tool, but a special statement set and the Screen Painter tool, which you also use to layout screens. The flow logic mainly contains the chronologically ordered calls of the modules in the corresponding module pool.
• The collection of PBO flow logic, screen, and PAI flow logic is called Dynamic program (Dynpro). A module pool must have at least one dynpro. Each screen of a dialog session thus is the visible part of a dynpro, to which also the flow logic belongs. The processing logic of a dialog session is stored in the corresponding module pool in the form of ABAP/4 modules.
• The ABAP/4 modules in the module pool are separated into PBO and PAI modules. The PBO or PAI blocks of the flow logic of each dynpro of a module pool can call each PBO or PAI module of this module pool.
• You can use ABAP/4 statements in the processing logic of the module pool to control the chronology of the different dynpros. After starting a dialog session via the transaction code, which is firmly connected to a dynpro of the module pool, the screen flow logic passes user entries to the processing logic in the ABAP/4 module pool. The processing logic processes the user entries (database accesses) and, if required, defines the appropriate subsequent screens.
No comments:
Post a Comment