Beginners Guide To ABAP – Module 1 – The SAP Environment For Our ABAP Programs

To continue on with our Beginners Guide to ABAP, today we will move on and have a look at the environment our program is run in. We go over the Work Processes, and then we will move on to the structure of an ABAP program.

SAP Program Types

Within an SAP system or at least what we are looking at, we have two types of programs. We have Reports and we have Dynpros.

Report Programs

The SAP Environment For Our ABAP ProgramsReports are exactly what you may think. They are just programs that generate lists of data with the option of having a minor elements of interactivity. They just supply data to the front-end interfaces, the SAP GUI and so on.
When a user runs a report, they typically get a selection screen. Once they enter their selection parameters and execute the report, they normally cannot intervene in the execution of the program. The program runs and then displays the output.

Dynpro Programs

Dynpro programs are a little bit different. Dynpro’s are dynamic programs. They allow the user to intervene in the execution of the program  and they work by processing a series of screens that we call dialogue screens. The user determines the flow of the program itself by choosing which buttons or fields to interact with on the screen.

Their actions then triggers different functions that have been coded within the flow logic of a program. While we are creating reports, we will be generating interfaces that classed as Dynpro’s for all of our selection criteria. Now don’t fret because most of the work that ABAP programmers do is actually inside report programs. Even though these programs are classed as reports, they don’t always generate output.

The report programs are there to process all the logic together with reading and writing to the database to try to make the system work.

Work Processes

Let’s take a look at work processes. Every program that runs in an SAP system runs in what we call work processes and these actually run on the application server. Work processes themselves work independently of the computer’s operating system and the database that it interacts with. This gives us that program independence that we discussed earlier when looking at the technical architecture of an SAP system.

When an SAP system is initially set up, your Basis consultants (they are the guys who actually install SAP and keep it running, you know, monitor all the memory and so on) configure SAP in such a way that it automatically sets the number of work processes your programs use when they start. It’s the equivalent of setting up a predefined number of channels or connections to the database system itself, each of which tend to have their own different properties and different functions.

The Dispatcher

You might come across something referred to as the dispatcher. Your SAP system has no technical limits on the number of users who can actually log on and use an SAP system.

Generally, the number of users that can access an SAP system is a lot larger than the number of available work processes that your system is configured for. This is because not everybody is sending instructions to the application server at exactly the same time.

It’s a bit like the old mainframe time sharing scenario and because of this, users cannot be assigned a certain number of processes while they are logged on. It is the Dispatcher that controls the distribution of the work processes to the system users.

The dispatcher will keep an eye on how many work processes are available and when a user triggers a transaction, the dispatcher’s job is to say “Here you go, here’s a free work process. Go and use it”.

The dispatcher tries as much as possible to optimize things so that the same work process receives the sequential  dialogue steps of an application. If it can’t do this, let’s say because the user takes a long time between clicking on different aspects of the screen, it will then have to select a different work process to carry on with the processing of the dialogue program.

It is the work process that executes an application and it is the work process that has access to the memory areas that contain all the data and objects that an application uses. It also makes three very important elements available.

  1. The first one is the Dynpro processor. All Dynpro programs have flow and processing logic and it’s the Dynpro processor’s job to handle the processing of this logic. It responds to the user’s interaction and controls the further flow of the program depending on what the user does on the screen.
    one important thing to remember is it cannot perform calculations. It’s just there to manage the flow logic of a program.
  2. The second important element is the ABAP processor and this is responsible for the actual processing logic for our programs. It receives screen entries from the Dynpro processor and transmits the screen output to our program.
    Now, it is the ABAP processor that can perform the logical operation and arithmetical calculations in our programs. It can check authorizations and read and write to the database over the database interface and it’s the database interface that is our third important element.
  3. The Database Interface is actually a set of ABAP statements that are database-independent. What I mean by database-independent is that we can use a set of ABAP statements that in turn can communicate with any type of database that has been installed when our system was set up.
    So whether it is MS SQL Server or an Oracle database, we can use the exact same ABAP statements that together are called Open SQL to control all of our database reading and writing over  the database interface.

ABAP Programs

The great benefit of this means that our ABAP code has encapsulation which means ABAP programmers don’t need to know which physical database system the actual SAP system that they are using actually supports.

There may be times when you  do want to use a specific SQL statement that is native to the database that is installed. To cover this scenario SAP have designed ABAP in such a way that if this type of coding is necessary, you do have that facility. You can directly access the database through your program using native SQL statements. But, it’s not encouraged.

If you are going to make a program in ABAP make sure you use the open SQL because then everybody else that comes and sees your program afterwards they’ll totally understand what you’re trying to do. I’ll just add that normally when systems are set up, your system administrator normally forbids this practice mainly because of the different security risks and stability risks to the system that you may introduce to your programs.

Categories

About the Author:

Pete has been working with SAP technologies for over 10 years. He started out as an ABAP consultant and then moved on to BW where he has worked many different clients covering a wide variety of industries. "I love introducing SAP technology (especially BI) to new clients and showing them how they can go from zero to hero within their business in super fast time". Contact me on twitter @PeterMoxon