SAP ABAP Training - SAP Environment For Our ABAP Programs Video Lecture - IT & Software

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.