SAP R/3 Basissystem

CHECK

SAP has defined some useful aliases, see Tabelle 3.1, „predefined aliases“ for details. You can display an actual list with the command alias when logged in as the sidadm. You may and should add more aliases to ~/.customer.csh oder ~/.customer.ksh. See Tabelle 3.2, „User-defines aliases“ for examples. Don't change the SAP scriptes! Every change you make will give you trouble when you are going to upgrade your sap system.

c11env.cmd, telnet, at/cron

Create a directory where you can store useful scripts. You may even use that to share documentation and informations between admins. Useful scripts are for CD mounting, logfile analysis, and system monitoring. Examples?

OK-Codes are used to do a lot of things in SAP. Most functions can also be started with a mouseclick, but knowing the OK-Code is sometimes much faster. SAP tells that OK-Codes and transactions may eventually die, but I hope they will survive.

Das Zurücksetzen der Puffer mittels /$SYNC sollte normalerweise nicht notwendig sein. Wenn Sie jedoch »merkwürdige Phänomene« haben, dann ist es durchaus möglich, dass durch einen Transport die Puffer etwas durcheinandergeraten sind. Wenn Sie derartiges feststellen, dann wird es Zeit, das SAP R/3 System, genauer die Applikationsserver, mal wieder durchzustarten (Wir tun das alle vier Wochen für eine Offline-Sicherung).

Bei der Verarbeitung von Batch-Input Mappen werden einige weitere OK-Codes verwendet. Das sind einmal Kürzel für die verschiedenen Funktionstasten, alternativ kann auch der entsprechende Funktionscode verwendet werden, wie er im Dynpro (XXX Transaktion) definiert wurde. Außerdem können Sie die Funktion aus dem Menü System+Dienste+Batch-Input mit Hilfe der hier angegebenen Codes ausführen.

Cancel (F12) und Exit (F15) vermerken die Transaktion als gebucht!

Mit Benutzerparametern (Set/Get-Parameter) kann ein Benutzer sich verschiedene Felder mit (fixen) Werten vorbelegen. Verschiedene Transaktionen merken sich in diesen Parametern den zuletzt eingegebenen Wert, z.B. bei einer Kundennummer.

Nicht alle Felder, tatsächlich sind es eher wenige Felder, können mit Werten vorbelegt werden. Ob das in der aktuellen Transaktion und dem aktuellen Feld möglich ist, sagt die »technische Info« in der Hilfe (mit dem Cursor auf das Feld gehen, F1 drücken und dann den Button technische Info oder F6 betätigen.

Mit der Transaktion SU52 kann jeder Anwender die Benutzerparameter für sich selbst einrichten. Der Benutzerverwalter kann aus der Benutzerpflege (Transaktion SU01) für seine Anwender Benutzerparameter pflegen.

Was sind Varianten-Variablen?

GPA's und RFC-Transaktionen. Bei mir geht's erstmal nicht...

Profilegenerator

Benutzermenüs -> SAPLOGON/Session-Manager?

Tips: Adresse/Telefonnummer pflegen, Kostenstellen und Benutzergruppen verwenden, Gültigkeitsdaten, Vermessungsdaten

Beachten Sie den Hinweis 76829: Möglichst keine Benutzernamen mit Wildcards ("*","_", ".", "%") verwenden. Warum? Suchfunktionen gehen nicht vernünftig oder es gibt Schwierigkeiten im Transportsystem.

Die aktuelle Transaktion findet man unter System -> Status. In das Hauptmenü kommt man immer mit der Eingabe /ns000 im OK-Code. Ab Release 4.6 erreichen Sie das alte Menü mit /ns000_old.

Viele Funktionen zum SAP System Management sind im CCMS (Computing Center Management System) zusammengefaßt. Mit der Transaktion SRZL kann dieses Menü direkt aufgerufen werden.

DB13?

Wozu dient das Monitoring überhaupt? Warum sollte man sich schnell zurechtfinden können? Um im Notfall schnell reagieren zu können.

DB Monitoring

Accounting

stat/tabrec in Instance profile

Bei schwerwiegenden Problemen schreibt das SAP-R/3-System sogenannte Developer-Traces Developer-Traces. Diese Dateien (mit dem Namen dev_*) werden im Work-Verzeichnis bei jedem Systemstart neu angelegt. Sie können sich diese Dateien mit der Transaktion AL11 ansehen oder auf Betriebssystemebene.

Den Trace-Level für einen Work-Prozeß kann man in der Transaktion SM50 erhöhen. In den Traces finden sich Hinweise, wie die SAP Basis bestimmte Fuktionen bearbeitet hat. Besonders nützlich ist der Trace bei RFC-Destinationen, in diesen findet man häufig die Ursache für nicht funktionierende RFC-Funktionen.

Im R/3 werden alle Daten in Tabellen des Datenbanksystem gespeichert. SAP unterscheidet zwischen Anwendungsdaten (Stamm- und Bewegungsdaten), Customizing-Einstellungen und (XXX was noch?). Anwendungsdaten werden mit Hilfe von Transaktionen der Anwendung bearbeitet, Customizing-Einstellungen werden über verschiedene Transaktionen und die Tabellenpflege bearbeitet.

^[1]

Wie Transportiert man Tabelleneinträge?

SE16: Tabellenpflege mit F5 bzw. Satz markieren, /h, Detail-Button, F7, ok-code = "EDIT", F8. Sinn? Gerade beim entwickeln und Debuggen sinnvoll, möglicherweise auch Manipulation von Daten -> erzählen Sie des der Revision besser nicht

Bei großen SAP R/3-Installationen steigen die Anforderungen an Antwortzeiten und Ausfallsicherheit. Für die Zentralinstanz werden häufig High-Availability-Lösungen wie HACMP™ von IBM oder Veritas-HA™ von Veritas eingesetzt. Bei verteilten Systemen mit mehreren Applikationsservern ist es zu aufwendig, dieses Verfahren für jeden Applikationsserver einzusetzen. Eine einfache Abhilfe ist der Einsatz von Logon-Groups.

Eine Logon-Group wird im R/3 definiert und umfaßt eine oder mehr Dialog-Instanzen. Bei der Anmeldung mit SAPLOGONSAPLOGON wird der Benutzer nicht direkt mit einem SAP-Server verbunden, sondern das Programm fragt zunächst den Message-Server, welche Instanzen verfügbar sind und wie deren derzeitige Auslastung ist. Anschließend wird das Programm SAPGUISAPGUI gestartet, das sich mit einem geeigneten Applikationsserver verbindet.

Die Definition und Überwachung von Logon-Groups erfolgt mit der Transaktion SMLG (Werkzeuge -> Administration -> Computing Center -> Management System -> Configuration -> Logon Groups).

Die Verteilung der Benutzer auf die verschiedenen an der Logon-Group beteiligten Rechner erfolgt nach zwei Kriterien: die aktuelle Antwortzeit der Server und der jeweiligen Benutzeranzahl. Thresholds, quasi-statisch

Bei Rechnern, die mehrere IP-Adressen haben (multihomed hosts) ist es in der Dialogbox möglich die IP-Adresse anzugeben, die den Clients übergeben wird. Default ist der Hostname des ApplikationsserversApplikationsserver.

Mit dem Menü Gruppenliste -> Format -> Erweitert wird im Übersichtsbild eine ausführlichere Liste angezeigt, die wesentlich aussagekräftiger ist, als die kurze Liste. Mit dem Menüpfad Springen -> Benutzerliste wird eine Benutzerübersicht über alle Instanzen aufgebaut, und der Pfad Springen -> Lastverteilung zeigt den aktuellen Status aller Instanzen an, die an der Lastverteilung beteiligt sind.

ABAP: RSRZLLG0 steuert die Lastverteilung

Unter Unix: lgtst und eigene Skripte, unter Windows: SAPLOGON kann es.

In den Instanzprofilen (Transaktion RZ10) müssen genügend Prozesse für die Hintergrundverarbeitung eingestellt sein. Es sollte auf jeder Instanz, die Hintergrundprozesse konfiguriert hat mindestens ein Backgroundprozeß für die Jobklasse A reserviert sein. Beachten Sie, dass die Aufteilung der Workprozesse mit BetriebsartenBetriebsart geändert werden kann.

Bis R/3 Release 3.1x muß der Benutzer SAPCPIC mit dem Paßwort ADMIN und dem Profile S_SAPCPIC existieren; sont klappt die Rückmeldung von externen Programmen ins SAP R/3 nicht.

Mit dem Menü Programm -> Im Hintergrund starten kann man innerhalb des Reportings (Transaktion SA38 bzw. SE38) einen ABAP im Hintergrund starten, ohne einen Job anlegen zu müssen. Für einen Job in der Transaktion SM36 bzw. SM37 ist eine VarianteVariante erforderlich.

Varianten sind vorgefertigte Eingaben von Report-Parametern. Varianten können so angelegt werden, dass diese nur für Hintergrund-Jobs verwendet werden können oder dass die Eingabe von einzelnen oder allen Feldern nicht möglich ist. Nützlich sind Varianten bei Reports, die häufig mit denselben Parametern oder bestimmten Variablen gestartet werden sollen.

Mit der Transaktion SE38 bzw. SA38 und dem Menü Springen -> Varianten kann man Varianten auswählen oder erzeugen. Bei der Funktion Programm -> Im Hintergrund ausführen erzeugt das System automatisch eine temporäre Variante.

Viele Online-Listen sind ebenfalls Reports, für die Varianten hinterlegt werden können. Das ist nützlich als Merkhilfe oder Schablone für Parameter, aber auch als Kommunikationshilfmittel zwischen Anwender und Administrator. Mit einer Variante kann man sehr einfach sicherstellen, dass beide dieselben Parameter verwenden.

Externe Programme werden unter Unix™ mit den Rechten des Benutzers sidadm ausgeführt. Damit ist ein sehr weitreichender Zugriff auf die Daten des R/3-Systems möglich. Achten Sie darauf, dass möglichst wenige Benutzer die Berechtigung zum Starten externer Programme haben und diese nach Möglichkeit weiter eingeschränkt wird.

Programme stehen entweder im Suchpfad den sidadm oder müssen mit dem vollen Pfad angegeben werden. Besser ist die Definition von logischen Kommandos mit der Transaktion SM49. Damit kann man Unterschiede zwischen den verschiedenen Betriebssystemen verdecken und die eigentlichen Programme vor den Anwendern verbergen.

Für den Start externer Programme muß bis zum R/3-Release der Benutzer SAPCPIC mit dem Paßwort ADMIN im entsprechenden Mandanten existieren. Andernfalls ist keine Rückmeldung des Jobs in das R/3-System möglich.

Bei Problemen finden Sie Logs und Traces im Systemlog (SM21), in den Developer-Traces (SM51, Springen -> Developer-Traces, Datei dev_cp, dev_xpg bzw. die Workprozeß-Traces) und können mittels SM65 ausführliche Ausgaben anfordern.

Das geprüfte Berechtigungsobjekt ist S_LOG_COM in der Klasse Basis - Administration. Hier kann man die Ausführung von Programmen ja nach Rechner, Betriebssystem und Kommando (real oder logisch?) erlauben.

Hintergrungverarbeitung kann das System stark belasten. Im Gegensatz zur Sanduhr in einem Modi (und irgendwann sind die Modi alle) merkt der Anwender davon zunächst nichts. Wenn Sie ein größeres System mit vielen Work-Prozessen für die Hintergrundverarbeitung haben, dann kann ein Anwender praktisch das gesamte System lahmlegen. Erschwerend kommt hinzu, dass besonders langlaufende und belastende Programme in den Hintergrund geschickt werden.

Abhilfe ist hier nur auf zweierlei Weise möglich: Entweder werden Anwender entsprechend ausgebildet und verhalten sich vernünftig (so vernünftig wie Anwender halt sein können...) oder die Berechtigung zum Start von Hintergrundprogrammen wird allen Anwendern entzogen und Jobs werden zentral verwaltet, eingeplant und überwacht. Auf Großrechnern war das Zweite üblich, heute wohl eher die Verantwortung der Anwender.

SAP R/3 unterstützt viele Plattformen, dabei unterscheiden sich die Namen von Betriebssystem-Dateien und Betriebssystem-Programmen zum Teil drastisch. Mit logischen Namen kann man diese Unterschiede verdecken, damit ist es möglich, ABAPs und Programme auf verschiedenen Plattformen ohne Anpassungen zu verwenden.

Logische Dateinamen bestehen aus drei Teilen: dem logischen Pfad, die Zuordnung des physikalischen Pfades in der jeweiligen Syntax abhängig vom verwendeten Betriebssystem und die Zuordnung eines logischen Pfades zu einem logischen Dateinamen (als Attribut ist hier die Ersetzung des Dateinamens hinterlegt).

Hintergrund-Jobs können nicht nur direkt und zeitgesteuert eingeplant werden, es ist auch möglich, diese nach dem Eintritt eines speziellen Ereignisses starten zu lassen. Ein derartiges Ereignis ist ein SAP-Event, die Startart ist eventperiodisch.

System/Benutzer-Event

Event-Parameter

You may even trigger an event by running the command sapevt, see Abbildung 5.1, „Trigger an event from the operating system level“ for an example. This program is available for all supported plattforms including Windows NT. Be aware, that anybody in your LAN can send events (you only need to now the application server and the instance number your SAP runs on). You won't even know which IP address has triggered the event.

% /sapmnt/SID/exe/sapevt \
    pf=/sapmnt/SID/profile/DEFAULT.PFL \
    Event
hermes09:c11adm 4> sapevt
usage: sapevt event [-p param] [-t]
       pf=<profile> | name=<Name> nr=<nn>
hermes09:c11adm 5> sapevt ZZ_TEST -t -p Jochen_Text pf=/sapmnt/C11/profile/DEFAULT.PFL
hermes09:c11adm 6> sapevt ZZ_TEST -p Jochen_Text pf=/sapmnt/C11/profile/DEFAULT.PFL
hermes09:c11adm 7> sapevt ZZ_DUMMY -p Jochen_Text pf=/sapmnt/C11/profile/DEFAULT.PFL
hermes09:c11adm 8> sapevt ZZ_DUMMY -t -p Jochen_Text pf=/sapmnt/C11/profile/DEFAULT.PFL

Parameter zu events, logging(!)

As described above, you can triggern an event from any host running an operating system supported by SAP. All you need is a profile similar to Abbildung 5.2, „A profile for sapevt“. Make sure that your services file contains the definition of sapmsSID. Look at you central instance if in doubt.

SAPSYSTEMNAME = SID
rdisp/mshost = message server
rdisp/btcname = host_sid_system number
hermes09:c11adm 9> cdpro
hermes09:c11adm 10> sapevt -t ZZ_DUMMY name=C11 nr=11
sapparam(1c): No Profile used.
hermes09:c11adm 11> sapevt ZZ_DUMMY name=C11 nr=11 -t 
sapparam(1c): No Profile used.

Nur der zweite geht...

Aus eigenen ABAPs kann mit dem Funktionsbaustein BP_RAISE_EVENT ein beliebiger Event ausgelöst werden. Gibt es dazu spezielle Berechtigungen?

Die Definition von Jobs ist für viele Fälle zu aufwendig. Mit der Transaktion SE38 Ausführen → Im Hintergrund Starten kann ein ABAP auch ohne eine Variante im Hintergrund ausgeführt werden. Der Jobs wird, sofern der Benutzer ausreichende Berechtigungen hat direkt gestartet. Ein Nachteil ist, dass der Anwender den Zielrechner für diesem Job nicht bestimmen kann.

Auch wenn man ABAPs auch ohne Varianten starten kann, nutzen Sie Varianten! Es ist eine einfache Möglichkeit, sich Parameter für bestimmte Läufe zu merken ohne diese auf Papier aufzuschreiben. Auch für die Kommunikation zwischen Anwendern und Systemverwaltern ist es nützlich, da beide dieselben Parameter verwenden.

Reorg von Job-Protokollen? RSBTCDEL

Die Job-Protokolle werden im Unix-Dateisystem unter /sapmnt/SID/global/MandantJOBLG gespeichert. Es ist ziemlich unangenehm, wenn das Dateisystem voll ist.

Jobs stehen in der Tabelle TBTCO, dort ist auch der Job-Status hinterlegt.

For an SAP upgrade the upgrade procedure stops the planned jobs with the report BTCTRNS1. The jobs are in a special state "stopped during upgrade". After the upgrade you have to use report BTCTRNS2 to reenable the jobs. You can also use the reports to disable jobs for a system copy or during a client copy.

Funktionsbausteine, pflegbar mit SE37, siehe auch Kapitel 9, Development-Tools.

Aufruf im ABAP mit CALL FUNCTION,

After the systemcopy it might be needed to avoid starting background jobs. You have different ways to achieve that:

SAP Systeme sind komplex und damit fehleranfällig. Jede Änderung an Programmen oder Customizing-Einstellungen kann die Stabilität und Verfügbarkeit des R/3-Systemes beeinträchtigen. Daher findet (hoffentlich) die Entwicklung von Programmen, Modifikationen von SAP-Programmen und das Customizing in einem Entwicklungssystem statt. Wenn Bedarf besteht, dann kann zwischen das Produktions- und das Entwicklungssystem noch ein Konsolidierungssystem eingebaut werden, in dem Massentest u.ä. stattfinden können.

Generell sollten Sie versuchen, die Systeme möglichst ähnlich zu halten, das heißt unter anderem, dass Transporte möglichst schnell durch die Systeme geschoben werden sollten. Auch Releasewechsel finden in der Reihenfolge der Systeme statt: erst das Entwicklungssystem, dann das Konsolidierungssystem und erst zuletzt das Produktionssystem.

Praktisch alle Objekte, die Sie im Rahmen des Customizings anfassen, sind transportierbar. Entweder fragt das System direkt beim Speichern nach einer Auftragsnummer, oder die entsprechende Transaktion hat einen Transportanschluß, der z.B. über ein Menü angesprochen werden kann. Nur in seltenen Ausnahmefällen sollten Sie manuell Transporte mit der Transaktion SE01 anlegen (müssen).

E071, TADIR

Organizing transports.

The central point of the transport system is the directory /usr/sap/trans. It is shared between the SAP systems and contains all transports from all systems. The directories need to be writeable by all systems (i.e. the unix group sapsys). The directories are described in Tabelle 7.2, „The directory /usr/sap/trans“.

The directory bin should be empty, except the TPPARAM file. This file contains a description, what systems exist and how the databases are accessible. Beside the real SAP systems, you may add dummy systems that are only a name. See Abbildung 7.1, „The TPPARAM file“ for details.

# Dummy system XXX
DUM/dummy=on

[global]
   workgroup = SAPR3
; Options for handling file name case sensitivity and / or preservation
; Case Sensitivity breaks many WfW and Win95 apps
;   case sensitive = yes
    short preserve case = yes
    preserve case = yes

; Security and file integrity related options
   lock directory = /var/lock/samba
   locking = yes
   strict locking = yes
;   fake oplocks = yes
   share modes = yes
; Security modes: USER uses Unix username/passwd, SHARE uses WfW type passwords
;        SERVER uses a Windows NT Server to provide authentication services
   security = user
; Use password server option only with security = server
;   password server = <NT-Server-Name>

; encryption?
;============================ Share Declarations ==============================
[trans]
   comment = Global /usr/sap/trans
   path = /usr/sap/trans
   read only = no
   public = no

You need to change into /usr/sap/trans/bin before calling tp. tp works with buffers; there is one buffer for each SAP system. Before you can import a transport into a system you must add it to the buffer with the command addtobuffer. See Abbildung 7.3, „Typical tp usage“ for a typical usage.

% cd /usr/sap/trans/bin
% tp addtobuffer transport SID
% tp import transport SID

Tranportorders have a common format: SIDKnumber. If number starts with a nine (9), that is a customer created transport. Otherwise it is an SAP transport. The SID is the SID of the original system.

There are loads of commands for tp. See Tabelle 7.3, „Buffer related tp commands“ for buffer related command.

Achtung: Konsistenz!

getdbinfo, clearold

Belieferungssysteme, automatischer Import, ZCUS

Steps beim Import, Reihenfolge und Idee, /$SYNC

client= or client999, default is 000(yes? no, I think it the export client), Macht das etwas kaputt? weiß nicht.

use another profile with pf=, default= TPPARM (cwd)

Set parameters with "-D buffreset=true", welche Paramter erlaubt?

Passing options to tp or R3trans is sometimes syntactically complicated. The easiest way to do that is to create a new TPPARAM (probably as a copy from your existing configuration) and modify that accordingly.

For a client import we needed to modify tcs, here is what we did.

See OSS note 103582 for details.

Not so typical tp usage: backtransport, reference client

tp calls internally the command R3trans which does the real work. Normally, there is not much need in using R3trans directly. The typical use is copying data between clients where the SAP client copy does not work. Cases are big tables and variants for reports.

R3trans has a couple of options that are useful, even if you do not want to copy some data. The syntax of R3trans is:

Valid options are:

Return codes

R3trans has some restrictions, on what it is allowed to export or import. You may lift some of the restrictions by adding an unconditional mode with the option -u. Tabelle 7.8, „Unconditional R3trans Modes for Export“ and Tabelle 7.9, „Unconditional Modes for R3trans Import“ show the allowed unconditional modes for export and import.

source client=000
target client=100
select * from kna1

% R3trans -V -w /tmp/r3trans.log ./r3trans.control

source client=000
target client=100
select * from VARI
select * from VARID
select * from VARIT

Transactions

transports and remote copy

Verschiedene nützliche Ideen

TOP-OF-PAGE.
    SY-TVARn = Variable.

Leider mal wieder ein eigener Editor, Umschaltbar

SAP R/3 wird mit dem gesamten Quellcode der ABAP/4-Programme ausgeliefert, technisch kann also jeder Kunde diese Programme modifizieren. In einem produktiven System sollte mit Hilfe der Transaktion SE06 die Änderbarkeit von SAP-Objekten im Repository verhindert werden. Bei der Änderung eines Objektes wird ein Schlüssel verlangt, der im SAP-OSS zu bekommen ist (SSCR, ausgeschrieben?). Damit ist die Hotline in der Lage, mögliche Probleme zumindest ahnen zu können.

Grundsätzlich sollte man so wenig wie möglich modifizieren. Besser ist die Verwendung von User-Exits (Transaktion?), eigener ABAPs (evtl. Kopien von SAP-Programmen) und Append-Strukturen. Das teure an Modifikationen ist die Wartung bei Releasewechseln und der damit verbundene neue Test, nicht die erste Erstellung. Besonders wichtig ist die ausführliche Dokumentation der Modifikationen! Insbesondere sollte diese enthalten: Wer, wann und warum die Modifikation durchgeführt hat, welche Programme und Tabellen dabei angefaßt wurden und die entsprechenden OSS-Schlüssel. In den Programmen sollten die modifizierten bzw. eingefügten oder gelöschen (auskommentierten) Zeilen mit einem Kürzel markiert werden. Die Versionsverwaltung ist nützlich beim Releasewechsel, in den verschieden Fenstern kann man sich das Original-Programm, die neue Version und die modifizierten Versionen davon ansehen und mit Hilfe des Clipboards Code kopieren..

Wenn eine Modifikation notwendig ist, dann sollte man einige Regeln beachten: Je weniger Stellen im Programm modifiziert werden, desto besser. Verwenden Sie Includes oder Funktionsbausteine, um dort Ihre Logik unterzubringen. Gerade Funktionsbausteine haben den Vorteil, dass diese automatisch getestet werden können. Markieren Sie jede geänderte oder neue Zeile mit einem Kürzel, damit erkennen Sie sofort, dass diese Zeile aus einer Modifikation stammt.

Die Kosten und der Aufwand für eine Modifikation steckt nicht in der eigentlichen Entwicklung, sondern in der Dokumentation und der Arbeit, die bei jedem Releasewechsel aufgewendet werden muß. Behalten Sie im Auge, dass Modifikationen häufig noch in vielen Jahren aktiv sind und entsprechend dokumentiert werden müssen.

Modifikationen sollten möglichst schnell durch die Systeme transportiert werden. Damit ist der Test im Entwicklungssystem noch aktuell und bei Problemen allen beteiligten Personen präsent, dass eine Modifikation aktiv wird. Wenn eine Änderung lange herumliegt, kann es passieren, dass diese zu einem ungünstigen Zeitpunkt oder unerwünscht aktiv wird.

Häufig erfüllt die SAP-Standard-Software nicht alle Anforderungen, aber doch sehr viele davon. In diesen Fällen kann es notwendig und sinnvoll sein, den SAP-Standard gezielt zu erweitern. Leider funktioniert das nur an den Stellen, die von SAP dafür vorgesehen wurden. Wenn Sie also eine Modifikation an einer Stelle vornehmen, von der Sie erwarten, dass auch andere Kunden dort eingreifen, dann wenden Sie sich mit einem Erweiterungswunsch an SAP.

Erweiterungen können an verschiedenen Stellen vorgenommen werden. Tabellen können mit Hilfe von Append-Strukturen um zusätzliche Felder erweitert werden, manche Programme haben INCLUDEs, in denen Kunden ergänzen dürfen, manche Programme sehen sogenannte User-Exits vor. Global können Field-Exits verwendet werden.

Auf den ersten Blick scheint es viel schneller zu gehen (und damit billiger zu sein), die passenden Tabelle bzw. das passende Programm einfach anzupassen. Spätestens beim nächsten Release-Wechsel schlägt diese Situation ins Gegenteil um. In der Zeit, wo Modifikationen abgeglichen werden, steht das System nicht in vollem Umfang zur Verfügung. Außerdem will jede Anpassung erneut getestet sein.

Auch die Lösung, das Programm als kundeneigenes Programm anzulegen ist nicht sinnvoll. Spätestens beim nächsten Put denkt keiner daran, dass hier Anpassungen notwendig sein könnten. Als Ergebnis kann man beliebig schwer zu findende Fehler haben.

...
   TRANSLATE INPUT USING 'XU'.
   OUTPUT = INPUT.
...  

Welche Berechtigungen sind erforderlich?

SAP R/3 ist ein System, das immer weiter entwickelt wird. Um die Einführung von neuen Versionen auch dann so problemlos wie möglich zu halten sind Namensräume für Kunden reserviert. Wenn man eigene Programme, Tabellen oder Dynpros erstellt, dann sollte man diese in jedem Fall so benennen, dass diese nicht durch eine SAP Version überschrieben werden. In der Regel sind das Namen, die mit 'Y', 'Z' oder '9' beginnen. Genaueres finden Sie im entsprechenden Handbuch. Welches ist das?

ABAP war früher (SAP R/2) die Abkürzung für "Allgemeiner Berichts- (und) Aufbereitungs-Prozessor". Heute steht ABAP für "Advanced Business (and) Application Programming".

SAP R/1 und später SAP R/2 waren Mainframe-basierte Systeme und in Assembler programmiert. Auswertungen waren eine Folge von Assembler-Makros und -Anweisungen. Die Namen der Makros begannen mit einem "Y", so dass sich auch der Name Y-ABAP dafür eingebürgert hat. In diesen Reports konnten nur Daten ausgewertet werden. Für Datenänderungen waren andere Assembler-Programme notwendig.

Die per Assembler erzeugte Ladephase der ABAPs wurde von einem Interpreter im Batch abgearbeitet. Im Online waren diese Auswertungen nicht lauffähig. Das Erzeugen der Listen und Extrakte erfolgte normalerweise in 2 Phasen:

Das Erzeugen der Auswertungen war sehr aufwendig, es musste zunächst ein Job mit zwei Steps (siehe oben) erstellt werden, dieser musste dann aufgrund der Vorgaben der Anwender entsprechend parametrisiert werden und dann zu einer geeigneten Zeit (Auswertungen haben oft das System sehr belastet) gestartet werden. Der Anwender erhielt das Ergebnis in Form von gedruckten Listen.

Daher hat SAP im R/2 (ab Release 4.0 ?) ABAP/3 (bzw. ABAP/III) entwickelt. ABAP/3 Programme bestanden aus Befehlen, die bereits eine gewisse Ähnlichkeit mit ABAP/4 (bzw. COBOL) Befehlen hatten (GET xx., MOVE, COMPUTE, WRITE ...).

Die ABAP/3 Programme wurden durch einen Preprozessor in Assembler-Makros und -Anweisungen konvertiert. Auch diese Programme waren nur im Batch lauffähig ("2 phasiger" ABAP).

Ebenfalls ab R/2 Release 4.2(?) konnten ABAP/4 Programme ("einphasiger" ABAP) entwickelt werden. Diese Programme waren im Online und im Batch lauffähig. Es konnten jedoch nur Listen und Extrakte erzeugt werden.

Erst ab SAP R/2 Release 4.3 konnten in ABAP/4 auch Transaktionen mit Dynpros und Modulpools entwickelt werden. Ab diesem Zeitpunkt hat SAP selber begonnen, seine Anwendungen in ABAP zu entwickeln. Erstes Modul war RP, die Personalabrechnung.

Die Programmiersprache ABAP/4 wurde für R/3 erweitert und der Interpreter in C neu programmiert. Viele R/2 Programm kann man daher mit relativ geringem Aufwand nach R/3 portieren.

Wichtige Vorteile von ABAP/4 gegenüber anderen Programmiersprachen sind:

Did you ever wonder how to send and receive Internet-mail with your SAP R/3 system? Then this might be of help for you. You should first read the SAP documentation for the Internet Mail Gateway and come back later, since this file only describes the sendmail configuration.

From my experience, you should almost immediately remove your vendors version of sendmail and switch to the 'original' sendmail from Eric Allman. You may get it from http://www.sendmail.org. If you really want to know what to do with sendmail, get the 'sendail' book from O'Reilly.

The sendmail configuration is stored in a file called normally /etc/sendmail.cf, some people call it 'catastrophe file' due to its somewhat awkward syntax and high complexity. This is the reason to switch from your vendors version of sendmail to the original and to use the includes m4-configuration. There is a README in /usr/lib/sendmail-cf that describes the basic configuration.

This file describes only the additions needed to get SAP mail delivered, so you might want to read the above file as well.

First, you need to define a name for your SAP system. I use the system-id, appended with the local domain. For the purpose of this readme, the systems are called C11 and C12, the domain is example.org. Add MX records for the systems into your DNS, let them point to the mail gateway you are going to setup.

The basic idea is to generate a local delivery agent in the mail gateway for every SAP system that needs to get mail. This is done in two steps:

You may configure the deliver agents with a fews variables:

Sample Configuration Abbildung 10.1, „Sendmail Example“

# `which operating system is used on the mail hub'
OSTYPE(`aix4')

# `Use the sap r/3 mailer'
FEATURE(`sapr3')

divert(6)
# `And now generate the mailers itself'
SAPMAIL(`c11',`/usr/local/etc/C11_mailconfig')
SAPMAIL(`c12',`/usr/local/etc/C12_mailconfig')

# `generate the normal mailers'
MAILER(local)
MAILER(smtp)
# end of story -- who told about sendmail being hard?

The feature definition Abbildung 10.2, „Sendmail Feature“

divert(`0')
# SAP R/3 internet mail configuration
# Copyright (C) 1998 by Jochen Hein <jochen@jochen.org>
# Version 0.1, 15. March 1998
divert(`-1')
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
# 3. All advertising materials mentioning features or use of this software
#    must display the following acknowledgement:
#	This product includes software developed by the University of
#	California, Berkeley and its contributors.
# 4. Neither the name of the University nor the names of its contributors
#    may be used to endorse or promote products derived from this software
#    without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY JOCHEN HEIN ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# TODO:
# It might be wise to add U=sidadm:sapsys to the mailer deinition so that 
# mlsomail runs as that user 

# declare some variables the user might want to set:
# path to the mlsomail program
ifdef(`SAP_MAILER_PATH',,`define(`SAP_MAILER_PATH',`/usr/local/bin/mlsomail')')
#
# flags that are used in the F= option for the mailer
ifdef(`SAP_MAILER_FLAGS',,`define(`SAP_MAILER_FLAGS',`')')
#
# def. the domain that the SAP systems are in
ifdef(`SAP_MAIL_DOMAIN',,`define(`SAP_MAIL_DOMAIN',`$m')')

# create a mailer and the local rules to call them.  Usage is
# SAP MAIL(SAP_SYSTEM_ID,cfg-File created with mlsoadmin)
define(`SAPMAIL', `divert(7)
# the local delivery agent for the SAP R/3 system $1
Msap$1,P=SAP_MAILER_PATH,F=CONCAT(`DFPlLs',dnl
SAP_MAILER_FLAGS), S=10, R=20/40,T=DNS/RFC822/X-Unix,dnl
A=mlsomail $2 $u'
`divert(6)dnl
# Add the sap administrator ($1adm) as a trusted user
Ct$1adm'
`LOCAL_RULE_0'
# Additions to Ruleset 0: Select SAP system to send to
`R$+<@'$1`>	`$'`#'sap'$1`$:$1	Mail for SAP-R/3 system $1'
`R$+<@'$1`.SAP_MAIL_DOMAIN>	`$'`#'sap'$1`$:$1	Mail for SAP-R/3 system $1')

Die SAP-Benutzer müssen Zugriff auf die Oracle-Datenbank haben, dazu werden einige Umgebungsvariablen verwendet. Diese werden in der Datei ~/.dbenv.csh bzw. ~/.dbenv.sh gesetzt. Sind diese Variablen nicht vorhanden oder fehlerhaft, dann kann sich das SAP-System nicht an die Datenbank konnektieren.

Was steht noch in /usr/sap/trans?

Alle Daten und Programme, die zur Oracle-Datenbank gehören, liegen unterhalb des Pfades /oracle/SID. Laufen auf einem System mehrere Datenbank-Instanzen, die findet man für jede Instanz ein entsprechendes Verzeichnis. In /oracle/stage wird bei einem Releasewechsel oder Datenbank-Upgrade die Installation der neuen Programme vorbereitet.

Alert-Log: $ORACLE_HOME/saptrace/background/alert_SID.log, Insbesondere auf ORA-Meldungen achten, außerdem "Checkpoint not complete". Dafür kann man Shell-Skripte einsetzen... Wenn Trace-Dateien entstehen, dann sind auch die wichtig.

Die Datei startdb.log im Home-Verzeichnis des sidadm enthält möglicherweise Informationen, warum der Start der Datenbank fehlgeschlagen ist. Falls nicht, einfach die Datenbank mit dem Programm svrmgrl starten und auf die Meldungen achten.

SAP-Transaktion ST04 -> Goto -> Activity -> Database Log

Parameter Changes?

saparch, backup, reorg-Logs?

Wie heißt das Oracle-Tool, das Nobby mal benutzt hat?

Puffer

Database Activity? Performance Analyses

Missing Indices

Lock-Dateien: .lock.bra und .lock.brb

Tablespaces in Backup Mode?

grep nach ORA- im Alter-Log

Eine Option, die den Programmen sapdba, brbackup und brarchive gemeinsam ist, ist die Option -u, gefolgt von der Zeichenkette Datenbankbenutzer/Datenbankpaßwort. Damit nicht jeder Unix-Benutzer das Paßwort lesen kann, kann ein sogenannter OPS$-User verwendet werden, als Option ist dann -u / anzugeben.

Die Protokolle der SAP-Programme findet man in den Verzeichnissen $ORACLE_HOME/saparch, $ORACLE_HOME/sapbackup und $ORACLE_HOME/sapreorg. Die Namenserweiterung gibt die Funktion an, die dieses Log erstellt hat, der Name ist mittels Zufallsgenerator vergeben. Man kann sich diese Protokolle bequem mit sapdba oder der Transaktion ???? ansehen. Ich bevorzuge ls -rtl und tail -f im entsprechenden Verzeichnis.

brarchive und brbackup erzeugen Lock-Dateien im Verzeichnis saparch (Dateiname .lock.bra) bzw. sapbackup (Dateiname .lock.brb). Wenn diese Dateien existieren, dann kann keine neue Sicherung gestartet werden, die Programme geben eine entsprechende Meldung aus. Nach einem Abbruch sind diese Dateien möglicherweise zu löschen.

Wann ist was zugreifbar (mount)?

Rollback

Archiver Stuck

begin backup and powerfail

/usr/sap/trans missing, listener missing

unclean shutdown (possibly left running)

Recovery: Was kann sapdba und was nicht?

PSAPTEMP und Index-Reorg

v$recover_file, v$datafile, andere?

siehe Oracle Refcard/Buch

export to /dev/null

Zusätzlich zum R/3 gibt es von SAP und Fremdanbietern Branchenpakete, sogenannte Industrial Solutions™Industrial Solution (IS-PaketeIS-Paket). Diese setzen auf einem bestimmten SAP-Release auf, das vor der Installation verfügbar sein muß.

Ein Upgrade eines IS-Paktes kann innerhalb eines SAP-Releases erfolgen oder einen Releasewechsel des R/3-Systems erfordern. In diesem Fall muß der Upgrade des IS-Paketes in jedem Fall im Rahmen des Upgrades erfolgen. IS-Pakete enthalten nicht nur neue Programme oder Tabellen, sondern ändern auch den R/3-Standard. Bei Hotpackages bzw. Legal Change Patches ist daher die Freigabe für das entsprechende Branchenpaket abzuwarten.