topic Re: DIALOG PROGRAMMING in Application Development and Automation Discussions

DIALOG PROGRAMMING

Former Member — Mon, 25 Feb 2008 07:59:37 GMT

hiii,

can any body give me any PDF or any LINKS relating to introduction to the dialog programming.

Re: DIALOG PROGRAMMING

Former Member — Mon, 25 Feb 2008 08:07:44 GMT

Hi,

try with the below link

http://sap.mis.cmich.edu/sap-abap/abap09/index.htm

Re: DIALOG PROGRAMMING

Former Member — Mon, 25 Feb 2008 08:16:04 GMT

Module pool (type M)

For a type M program to be executable, you must create at least one transaction code for it (in which

you specify an initial screen). You can control the subsequent screen sequence either statically (in the

screen attributes) or dynamically (in the program code).

You assign a dialog transaction to a module pool. The following steps occur when you run a dialog

transaction:

First, the LOAD-OF-PROGRAM event is triggered. Once this event block has been executed, the ABAP

processor passes control to the screen processor. For an example of how to use this new event, refer to

the example in the Function Groups and Function Modules unit.

The screen processor processes the intial screen specified in the transaction definition. The initial

screen can be a selection screen (regardless of the program type). The PROCESS BEFORE OUTPUT

event is triggered and control passes to the ABAP processor, which processes the first PBO module.

The ABAP processor executes the processing block and returns control to the screen processor. Once

all PBO modules have been processed, the contents of any ABAP fields with identically-named

corresponding fields on the screen are transported to the relevant screen fields. Then the screen is

displayed (screen contents, active title, active status).

Once the user has chosen a dialog function (such as ENTER), the contents of the screen fields are

transported back to the corresponding identically-named fields in the ABAP program, and the processing

blocks that belong to the PROCESS AFTER INPUT event are processed. The system then continues

by processing the next screen.

The only processing logic that is processed in a dialog transaction are the statements belonging to the

LOAD-OF-PROGRAM event and those occurring in the various modules.

However, you can also use the statement LEAVE TO LIST-PROCESSING. This makes all of the list

processing events available to you.

Download ABAP books from here.

abap online links

http://www.esnips.com/web/SAPAbapCertificationDocs/

http://www.esnips.com/web/SAPABAP

http://www.esnips.com/web/saparun-ebooks

http://www.esnips.com/doc/2a4c274b-b5b9-46b7-8ab5-5af47700a6c7/Command-List

http://www.esnips.com/doc/6bdb820f-f533-4517-a043-b64641b00490/TABC43-Data-Transfer

http://www.esnips.com/_t_/abap

Regards,

Chandru

Re: DIALOG PROGRAMMING

Former Member — Mon, 25 Feb 2008 08:16:37 GMT

Hi,

Dialog Programming :

This is a classical programming method that is based on dynpros and dialog transactions.

Classic Application Programming:

Separating the application layer from the presentation layer means that when you run an ABAP application program requiring user interaction, control of the program is continually passed backwards and forwards between these layers. While a screen is ready for input, the corresponding SAP GUI of the presentation layer is active. During this time, the application layer is not active for the application program. Therefore, the ABAP application servers are free for other tasks. Once the user has entered data on the screen, program control passes back to the application layer. Now, the presentation layer is inactive. The SAP GUI is still visible to the user during this time, and it is still displaying the screen, but it cannot accept user input. The SAP GUI does not become active again until the application program has called a new screen and sent it to the presentation server.

Consequently, if you use this method, you need to divide dialog programs into single dialog steps, with each of these steps comprising the programming logic between two successive screens.

Dispatching Dialog Steps:

The number of users logged onto an ABAP application server is often many times greater than the number of available work processes. Furthermore, it is not restricted by the SAP NW AS ABAP architecture. Furthermore, each user can run several applications at once. The dispatcher has the important task of distributing all dialog steps among the work processes on the ABAP application server.

1. The dispatcher receives the request to execute a dialog step from user 1 and directs it to work process 1, which happens to be free. The work process addresses the context of the application program (in shared memory) and executes the dialog step. It then becomes free again.

2. The dispatcher receives the request to execute a dialog step from user 2 and directs it to work process 1, which is now free again. The work process executes the dialog step as in step 1.

3. While work process 1 is still working, the dispatcher receives a further request from user 1 and directs it to work process 2, which is free.

4. After work processes 1 and 2 have finished processing their dialog steps, the dispatcher receives another request from user 1 and directs it to work process 1, which is free again.

5. While work process 1 is still working, the dispatcher receives a further request from user 2 and directs it to work process 2, which is free.

From this example, we can see that:

· A dialog step from a program is assigned to a single work process for execution.

· The individual dialog steps of a program can be executed on different work processes, and the program context must be addressed for each new work process.

· A work process can execute dialog steps of different programs from different users.

The example does not show that the dispatcher tries to distribute the requests to the work processes such that the same work process is used as often as possible for the successive dialog steps in an application. This is useful, since it saves the program context having to be addressed each time a dialog step is executed.

Dispatching and the Programming Model

As already mentioned (see Database Connection section), a work process can only make database changes within a single database logical unit of work (LUW). The contents of the database must be consistent at its beginning and end. The end of such an inseparable sequence of database operations is defined by a commit command to the database system (database commit). During a database LUW, that is, between two database commits, the database system itself ensures consistency within the database. In other words, it takes over tasks such as locking database entries while they are being edited, or restoring the old data (rollback) if a step terminates in an error.

A typical SAP application program extends over several screens and the corresponding dialog steps. The user requests database changes on the individual screens that should lead to the database being consistent once the screens have all been processed. However, the individual dialog steps run on different work processes, and a single work process can process dialog steps from other applications. It is clear that two or more independent applications whose dialog steps happen to be processed on the same work process cannot be allowed to work with the same database LUW.

Consequently, a work process must open a separate database LUW for each dialog step. The work process sends a commit command (database commit) to the database at the end of each dialog step in which it makes database changes. These commit commands are called implicit database commits, since they are not explicitly written into the application program.

These implicit database commits mean that a database LUW can be kept open for a maximum of one dialog step. This leads to a considerable reduction in database load, serialization, and deadlocks, and enables a large number of users to use the same system.

Check this link----

http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb2d40358411d1829f0000e829fbfe/content.htm

Cheers,

vasavi.

kindly reward if helpful.