SAP Basis Introduction
A SAP system administrator ensures that the Basis components of the
SAP system and their functionality are working correctly, this then
allows products such as Financial's, Material Management and Sales and
Distribution to work smoothly. SAP Basis could include the following
- SAP Instance
- SAP database (Oracle, MaxDB, DB2, etc)
- SAP user and authorization management
- SAP system monitoring and performance
- Backup and Restores (generally these are only the database and not the O/S)
- Assist ABAP/JAVA developers
The various SAP components that belong to the application layer, such
as Customer Relationship Manager (CRM), Advanced Planning &
Optimization (APO) and SAP Netweaver Business Warehouse (BW) are all
based on a shared Basis layer, the tasks and tools are all the same to
the administrator. In my Basis section I will only be covering the ABAP layer of the SAP system.
I will try and do my best to explain everything using screenshot's
and a detailed explanation, the SAP systems that I will using are both
work and an IDES
solution that we have configured, however you can download the freely
available SAP Netweaver application server trail from SAP to learn SAP
Basis. I will be only covering databases very lightly, I have other
sections on Oracle (Oracle RAC) and MaxDB.
I will be covering some of the configuration that a Basis would get
involved in like the Transport Management System (TMS), SAP Router, etc
in other sections.
There are many tasks involved with maintaining a SAP solution,
| Task |
Basis Function
|
description |
| SAP System Administrator |
X
|
Monitors the SAP system performance, keeps the system tuned and running |
| User Administrator |
X
|
Creates and manages user accounts |
| Authorization Administrator |
X
|
Creates and manages SAP roles and profiles |
| Security Administrator |
X
|
Guarantees the security of the SAP system, monitors for any intrusion or security breaches |
| Transport Administrator |
X
|
Copies changes between systems and manages change requests. |
| Background Job Administrator |
X
|
Schedules, monitors and manages background jobs |
| Data Backup Administrator |
X
|
Schedules, performs and manages backups and restores in all the related SAP filesystems |
| Disaster Recovery Administrator |
X
|
Creates, tests and plans disaster recovery of the SAP servers |
| Programmer | Create and manages ABAP/Java programs | |
| Database Administrator |
X
|
Manages the specific database (Oracle, MaxDB, DB2, etc) |
| Operating System Administrator | Manages the operating system required for the hardware (Linux, Solaris, AIX, Windows Server, etc) | |
| Network Administrator | Manages network access and guarantees that users and SAP can communicate with each other | |
| Desktop Support Specialist | Manages the desktop used by the user, this also includes the SAP GUI, Database tools which are used to maintain the SAP systems. | |
| Printer Operator | Manages network and desktop printers | |
| Facility Manager | Manages the technical/physical infrastructure (data center, comm's suites, power supply, air conditioning, etc) |
Depending on the size of the environment tasks could even be
performed by one person, I have highlight the common Basis functions
that a SAP system administrator would be required to perform. The main tasks of a SAP administrator is, keep the system running,
make sure its secure and make sure that you have backups, it would not
be a good career move if you cannot restore a corrupted SAP system, and
make sure that you periodically test your backups either on a spare
system or during DR testing. With any solution try and keep the SAP
configuration as simple as possible, try to use standard methods for
example try to use standard backup tools, stand database configuration,
this will help when you may require SAP support, complex solutions will
only cause delays, plus if only specific personnel know the complex
solution what happens when they leave the company. SAP in this regard
will advise you on how a SAP solution should be installed and
configured, they even offer a service to validate your solution making
sure that it meets SAP requirements and that they can fully support your
solution.
You should document all processes, procedures, hardware changes,
configuration changes, checks, problems errors and so on, because SAP is
so large and complex you cannot know everything or remember everything,
documentation comes in handy when you are called in the middle of the
night and are half asleep, it makes life so much easier just to pickup a
documented process and follow that then to try and think on your feet,
plus documented processes have the backing from your management team
which should have been involved in authorizing the process. Management
should insist on documentation with today's high turnover of staff, key
people may have left the company meaning skills that were involved in
the building of the SAP environment have now gone. The problem with
documentation is keeping it up to date and this also includes DR
documentation, a process should be in place to make sure that the
documentation is refreshed regularly.
I use checklists or a change control to make sure that every step in a
change is processed, this should include a work plan, test plan and a
back out plan, the reason is two fold, firstly not only you can run a
checklist or a change control, if it is document well then any other
administrator should be able to run the checklist/change control on your
behalf, secondly you get to think about what you are actually doing,
you could get someone else to review the checklist/change control and
they might pickup a missed task. In some of the sections I will add my
own checklists, feel free to use or modify them for your own
environment.
When building the SAP environment you should think about single
points of failure, which could lead to a service outage, try to consider
the below points
- Make sure that backups are taken regularly and that database archive logs are shipped to the DR system.
- Ensure hardware redundancy is in place for example, dual power, data is mirrored between sites, dual networking, etc
- Keep hardware replacements at hand, invoking DR is a major decision try to fix the environment first
- Ensure that you have all the contacts ready in case of problems and that the system knowledge is available (online)
- Make sure that you cross-train staff, be prepared for any staff member to leave the company
- Consider outsourcing, not a popular topic but it an option.
Before we start looking at the SAP system here are a few technology terminology
| Database Server | This contains the SAP components and the database (Oracle, MaxDB, DB2, etc). An important point to remember is that the database server determines the time of the SAP application. |
| Application Server | This server contains the SAP application, in systems with two layers this server forms part of the database server, application servers can be setup for online users, for background processing or for both |
| Instance | An instance refers to an installation of SAP on a server, we can distinguish between a central instance and a dialog instance.
|
| System | The system is the complete SAP installation for a System ID (SID), a system logically consists of a SAP central instance and the dialog instances for the SID. Physically it comprises of the database server and the application servers. |
| Client | See client in SAP Basis Introduction for more details. |
A typical SAP configuration would be something like below
| Layer |
Physical Device
|
SAP Instance
|
What runs on this layer |
| Display (presentation) |
Desktop/Laptop
|
None
|
SAP GUI |
| Application |
Several Application Servers
|
Dialog
|
SAP |
| Database |
A single database server
|
Central
|
Database (Oracle, MaxDB, DB2) |
With a two layer configuration both the dialog and central instances are run on a single server.
I will touch lightly on the SAP architecture, first lets us discuss
the overall picture, as I mentioned above the environment will consist
of a presentation layer this generally means the SAP GUI, the
application layer (SAP processes) and the central database, this can be
seen below, the application and database could reside on the same server
or different servers.
A user will use the SAP GUI to communicate to the SAP application,
they connect to the dispatcher, the dispatcher connects the user to a
work process which then communicates with the database, this can be seen
as below
A high level picture looks like below, the central instance contains
a dispatcher which communicates with a number of work processes, there
is also a message server, SAP gateway, SAP buffers, etc.
A work process can be divided into different types, the type of work
process determines the kind of task for which it is responsible in the
application server, the individual tasks are distributed to the work
process by the dispatcher. You can determine how many work processes SAP
will have and what their types will be. The dispatcher starts the work
process and only assigns them to tasks that correspond to their type.
This means that you can distribute work process types to optimize the
use of the resource on your application servers. The various types of
work processes are
| Process |
SM50 entry
|
Description |
| Dialog work |
DIA
|
deals with requests from an active user to execute dialog steps ( I will discuss this in more detail below) |
| Update |
UPD
UP2 |
executes database update requests, Update requests are part
of an SAP Logical Unit of Work (LUW) that bundle the database operations
resulting from the dialog in a database LUW from processing in the
background. There are two processes that are related to the update process
|
| Background |
BGD
|
process programs that can be executed without user interaction (background jobs) |
| Enqueue |
ENQ
|
administers a lock table in the shared memory area, the lock table contains the logical database locks for the SAP system and is an important part of the SAP LUW concept. There is only one lock table, you may therefore also only have one application with enqueue work process (I will discuss this in more detail below) |
| Spool |
SPO
|
passes sequential datasets to a printer or to optical archiving, each application server may contain only one spool work process |
Lets have a look at the dialog work process in detail, the process consists of two software processors and a database interface
 |
There is a difference between user interaction and processing logic, the user interaction is controlled by screens which also consists of a flow of logic, SAP contains a special language for programming screen flow logic, the screen processor executes the screen flow logic, via the dispatcher it takes over the responsibility for communication between the work process and the SAP GUI. |
 |
The actual processing logic of an application is written in ABAP, SAP's own programming language. The ABAP processor executes the processing logic of the application program and communicates with the database interface. |
 |
The database interface provides the following
Open SQL statements are a subset of standard SQL that is fully integrated in ABAP, they allow you to access data irrespective of the database system. Open SQL consists of the Data Manipulation Language (DML) basically insert, update, delete and select. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) are performed by the ABAP dictionary and the authorization system. Native SQL is loosely integrated into ABAP and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted but instead are sent directly to the database system. |
The task of the message server is to inform all the servers
(Instances) belonging to the SAP system of the existence of the other
servers, details such as system load, enqueue status, update services
are communicated about each instance.
The enqueue service is used to manage locks, below we can see two
instances that may require the same object, to prevent corruption,
logical locks are used to protect data, and locks are released when a
process has finished with it. The enqueue work process manages the
central lock table of the entire system in its memory, you can use
transaction code SM12 to see the locks. Note that SAP locks are
different to database locks that are used by a specific database as each
have there own way to deal with locks at the database level.
Behind the scenes a number of operating system processes are running
which relate to the above, you can use transaction code SM50 to view the
process from SAP point of view (see below for a screenshot of this),
the below screenshot details the processes running on a linux server
Below are the processes running on a windows server
Here is a process overview screenshot (tcode SM50), you can clearly see the processes we have been talking about above.
The client is probably as far as the system administrator will dive
into the SAP FI world, you are expected to administer clients which
includes creating, copying, deleting and configuring. I kinda think of a
client as a self contained system on its own when it comes to
administration however I will briefly describe what a client is and what
it does.
A client is by definition an organizationally and technically
self-contained unit within SAP, so for an example, if you had two
totally different business related companies you will probably have two
clients one for each business, all the business management data is
protected here because other clients data cannot be accessed. Althrough a
client has access to all the tables the tables can be either
- client dependant
- client independant
If the table has a MANDT field the table is said to be a client
dependant table, which means that a client can only access data in that
table that is related to that client, client dependant tables will
always contain a MANDT field and will contain the client ID as we will
see in the table T000 later. MANDT is short for MANDANT which is client
in German.
You can view the table DD02L (use transaction code SE16) to find out if a table is client dependant or independant, look at the column clidep, if it has a X then the table is client dependant.
A client is identified within a system by a unique three-digit code
(MANDT), try avoiding letters as this limits the functionality of the
client to a considerable degree (in relation to transports and certain
application modules). Three clients are normally delivered with the
system
- 000 - contains the default settings with no application data, you should never make changes to this client and it can be used to create other clients but generally you customerize 001 to your own evironment, it is also used as a working client only for support pack upgrades or ABAP load generations (SGEN) and implementing other languages.
- 001 - is the same as 000 but generally you customize it for your own environment and thus you use this client when copying for new clients as it contains your environment settings, some users never touch this client and use it as a backup to 000, some may not have client 001
- 066 - early watch client is purely a service client that enables SAP to access remotely the customer system with regard to analyzing errors and performance, you must not change or delete this client.
Generally when SAP sets up a system they may setup additional
clients, here are a few examples of a typical development SAP system
- 200 - customizing and development
- 210 - sandbox client
- 300 - reference client for integration and training
- 310 - training client
When you login to a SAP system you have to give the client ID this
makes sure that you only have access to that clients data. You can
obtain client information either by looking at transaction code SCC4 or a table called T000, first lets have a look at the transaction code SCC4, you can see that I have a number of clients configured on my system.
As mentioned above client information is stored in table T000, notice the MANDT which is the client ID.
Lastly I just want to talk about currency, when you configure a
client you have to specify the currency, the FI department may mention
something called a "Group Currency", the group currency is actually
taken from the client currency. You should not change a clients currency
once a client is in full use as this may have a big impact of existing
data in the system. I will talk about currencies in much more detail in
my FI section.
I have a administration section which details how you create, delete and configure clients.
