Wegen Formularspoofing wurde eine neue Kontaktmöglichkeit geschaffen.

Codings gesucht, die NICHT im SDN stehen.

Sicherlich kommt man als ABAP-Entwickler auch ohne "Basis"-Wissen zurecht, insbesondere bei großen Kunden, wo es eigene Basis-Betreuer gibt. Bei 'kleineren' Kunden aber, oder wenn die Basisbetreuung ausgelagert ist, ist man oft auf sich selber angewiesen. Dann sollte man wissen wie man sich helfen kann.

Man könnte auch fragen 'was treiben die denn den ganzen Tag so?'. Der leicht voreingenommenen Unterton der Frage tut den Kollegen (ja, ganz ganz selten nur Frauen) natürlich unrecht. 'Die Basis' ist - wie der Name es schon sagt - der Unterbau des gesamten SAP-Systemes. Hier werden so entscheidende Sache gemacht wie Updates (Patches) einpflegen, Berechtigungen vergeben, User eingerichtet, Passwörter zurückgesetzt, Server installiert, Transporte organisiert, Systeme gespiegelt, Datenbanken getunt, Fehleranalyse betrieben und und und. Die Aufgaben eines Basisbetreuers sind umfangreich und (meistens) nie langweilig.

Der Basisbetreuer ist also nicht nur für die Hardware sondern im weit zeitaufwendigeren Maße auch für die Grundfunktionen der Software zuständig. Als Entwickler benötigt man nicht nur einige weitgehende Berechtigungen im System (die der Basisadministrator zuteilen darf), sondern auch einen Entwicklerschlüssel [eine 30 stellige Zahlenkombination, die einmal je System einzugeben ist] der einen dazu überhaupt erst in die Lage versetzt Programme anzulegen etc., manchmal einen OSS-Zugang (Online-Support-und-Services) der kundenindividuell [wenn man als Berater arbeitet hat man ja mehrere SAP-Systeme, auf denen man arbeitet] ist und ganz häufig einen oder mehrere "Transporte" vom Entwicklungssystem ins Konsolidierungssystem.

Dieses 'Transportwesen' ist der Basisbereich, mit dem der Entwickler nahezu täglich konfrontiert wird. Es ist eigentlich nichts geheimnisvolles dahinter. Die Idealkonstellation einer SAP-Umgebung sieht drei verschiedene Systeme vor: Entwicklungssystem - Konsolidierungs(Test)system und Produktivsystem. Die (ABAP) Software wird grundsätzlich im Entwicklungssystem geschrieben. Von hier aus kann sie nur über einen 'Transport' in das Konsolidierungssystem [oder gar in das Produktivsystem] gelangen. Der Entwickler muss seinen 'Transport' dazu mit einer speziellen Transaktion (z.B: SE09) freigeben. Je nach Organisationsstruktur muss er sich dann an die *Basis* wenden um diesen Transportauftrag auch zeitnah in das Konsolidierungssystem zu bekommen wo es dann getestet werden soll. Ist dieser Test erfolgreich verlaufen wird über einen weiteren Transport dieses Programm nun in das Produktivsystem transportiert und steht damit dann allen 'normalen' Usern zur Verfügung.

Nicht nur neue Programme und Programmänderungen werden auf diese Wiese transportiert. Auch alle Customizingeinstellungen und alle neuen Objekte des Data-Dictionarys (z.B. eine neue Tabelle) werden auf diese Weise transportiert.

Natürlich ist diese Idealszenario so nicht bei jedem Kunden implementiert. Vor allem wird bei den wenigsten Kunden auch ernsthaft im Konsolidierungssystem getestet. Es gibt auch Kunden bei denen automatisch ins Konsolidierungssystem transportiert wird, d.h. nach der Freigabe ist nahezu zeitgleich das Programm auch im Konsolidierungssystem testbar. Bei anderen Kunden wiederum muss/kann der Entwickler sogar eigenständig den Transport in das Produktivsystem durchführen. Es gibt alle Zwischentöne in der Welt da draußen. So kann es auch schon mal zwei Tage dauern bis man das eben fertiggestellte Programm auch richtig testen kann, da im Entwicklungssystem noch nicht mal ein Materialstamm vorhanden ist, das Transportsystem aus Sicherheitsgründen ganz 'vorbildlich' benutzt wird [z.B. nur vormittags :-))] und das Konsolidierungssystem einen wirklichen Test nicht ermöglicht, da es keine aktuellen Daten enthält oder nicht buchbar ist. Das ist aber die absolute Ausnahme. Meistens geht das ganz fix.

 

Ein guter Entwickler muss also auch immer eine ganze Menge 'Basis'-Wissen haben. Also z.B. User-Verwaltung, Berechtigungen etc.