Beginners Guide to ABAP - Module 1 – SAP System Overview
01.03 SAP Environment For Our ABAP Programs
Now, let’s move on and have a look at the environment our program is run in.
We’re going to discuss the work processes, and then we’ll move on to the structure
of an ABAP program.
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.
Now, reports, it’s pretty obvious, reports are just what it says on the tin.
Reports are just programs that generate lists of data or maybe they’ve got a little bit
of interactivity in them.
But basically, they supply data to the frontend 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.
Dynpros are a little bit different.
Dynpros 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.
There 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 people 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, reading and writing to the database
to try to make the systems work.
Let’s have 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 consultant they are the guys who actually
install SAP and keep it running, you know, monitor all the memory and so on.
They configure SAP in such a way that it automatically sets the number of work processes your programs
use when they start.
That’s the equivalent of like 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.
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, you know, 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.
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 actual flow logic itself.
It responds to the user’s interaction and controls the further flow of the program depending
on the user’s interaction.
What I am trying to say is it is responsible for dialogue control on the screen itself.
But one important thing to remember is it cannot perform calculations.
It’s just there to manage the flow logic of a program.
The next 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.
Now the database interface is actually a set of ABAP statements that are database-independent.
Now, 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 ‘s, you know, Microsoft sequel server or an Oracle database, we can use the
same ABAP statements that is actually called open SQL to control all our database reading
and writing over the database interface.
Now the great benefit of this means that our ABAP code, our ABAP statements have encapsulation
which means our programmers don’t need to know which physical database system the actual
SAP system that they are using actually supports.
Now there are times when maybe you do want to use a specific SQL statement that is native
to the database that is installed.
So 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.
You know, if you 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.