SAP Zusammenfassung

 

 

 

 

 R/3 Integrationsmodell:

 

·           Offenes System

·           Branchenneutral

·           Multinational

·           Client-Server-Prinzip

·           Alle Unternehmensgrössen

·           Betriebliche Gesamtlösungen

 

Funktionsbereiche:

 

·           Finanz- und Rechnungswesen

·           Service

·           Produktion

·           Marketing/Vertrieb

·           Forschung/Entwicklung

·           Personal

·           Material/Logistik

 

Geschäftsprozesse:

 

·           Auftragsabwicklung

·           Produktentwicklung

·           Kundenservice

·           Finanzreporting

 

 

Das R/3 Integrationsmodell :

           

·           SD            Vertrieb

·           MM           Materialwirtschaft

·           PP                        Produktionsplannung

·           QM           Qualitätsmanagment

·           PM            Instandhaltung

·           HR            Personalwirtschaft

·           FI              Finanzwesen

·           CO            Controlling

·           AM            Anlagenwirtschaft

·           PS                        Projektsystem

·           IS              Branchenlösungen

 

Ein Datenbank steuert das komplette Unternehmen.


 

Kundenanforderungen an R/3:

 

·           Umfassende Betriebswirtschaftliche Funktionalität

·           Durchgängige Prozeßabwicklung

·           Eigene Konfigurierung von Anwendungen

 

Ein vollständiges R/3 System bietet folgende Anwendungsdienste:

 

·           Dialogverarbeitung                    D

·           Verbuchung                                V

·           Sperrverwaltung                         E

·           Hintergrundverarbeitung           B

·           Messagesystem                        M

·           Gatewayserver                           G

·           Spool                                           S

 

 

Message-Server:

Dient zur Kommunikation zwischen den einzelnen Dispatchers und ist Voraussetzung zur Skalierbarkeit der Systeme.

 

Gatewayserver:

Ermöglicht die Kommunikation zwischen MYSAP-Komponenten sowie externen Anwendungssystemen. 1 Gateway pro Dispatcher.

 

Dialog:

            Jeder Dispatcher benötigt mindestens zwei Dialog-Workprozesse.

 

 

Spool:

            Mindestens 1 pro SAP-System, pro Dispatcher sind mehere erlaubt.

 

Buchung:

            Mindestens 1 pro SAP-System, pro Dispatcher sind mehrere erlaubt.

 

Hintergrundverarbeitung:

            Mindestens 2 pro SAP-System, pro Dispatcher sind mehrere erlaubt.

 

Enqueve:

            Pro SAP-System ist nur ein Prozeß nötig.

 

 

 

Instanz:

Ist eine Einheit aus einem oder mehreren Serverdiensten eines Applicationsservers. Der Dispatcher des zentralen Applicationsservers und verwaltet sie über dem Messageserver. Instanzen laufen in der Regel auf eingenen Rechnern , Servern.

 

 

Funktionstastenbelegung:

            F1                               à Hilfesystem

            F4                               à Mögliche Eingabewerte des entsprechenden Feldes

                       

 

 

 

Präsentationsarten:

 

Zweistufige Architektur:

           

            Frontend                                           Applicationsserver

(Pc/xterm)                                         Backupserver

                        Sinnvoll bis max. 200 User.

 

 

           

Dreistufige Architektur:

           

            Frontend                    Applicationsserver               Backupserver

 

            Je nach Leistungsfähigkeit der Hardware können über 5000 Frontend bedient werden.

 

 

Einteilung:

 

            Präsentation/Frontend:

                       

·           SAPGUI   Grafikel User Interface

·           nimmt Benutzer eingaben entgegen  

·           übergibt Sie am Applicationsserver

·           max. 6 SAPGUI pro Rechner und User

·           Ab Version 4.6B steht die SAPGUI für folgende Betriebssystem zur Verfügung:

·           WIN 32 Bit

·           Java

·           HTML

·           Durch das Browserbasierte SAPGUI ist es möglich auf jedem R/3 zu nutzen. Obwohl sich das SAPGUI Primär am Win-Style orientiert sieht es an jedem System gleich aus.

 

 

Applicationsebene:

           

                                  

·           Benutzereingaben werden entgegen genommen

·           Berechnungen, Auswertungen etc. werden durchgeführt

·           Notwendige Daten werden von und zur Datenbank transportiert

·           Zentraler Verarbeitungspunkt des Systems

 

Instanz:

                       

·           Teil der Applicationsebene

Die verschiedenen Prozesse der Applicationsebene werden in Instanzen aufgeteilt und können bei Bedarf ausgelagert werden, so daß im SAP-System mehrere Applicationsserver stehen können die die entsprechenden Aufgaben erledigen.

                        Dispatcher:

                       

·           Hauptbestandteil des Applicationsserver

·           Verteilt in Abstimmung der System Ressourcen die Transkaktionslast auf die Workprozesse

Workprozess

·           Hier findet die eigentliche Arbeit der Applicationsbene statt.

·           Die Arbeitsaufträge werden vom Dispatcher verteilt

 

 

 

            Datenbank:

 

·           Pro SAP-System nur eine Datenbank

·           Name der Datenbank bestimmt immer das gesamte System

·           Informationsaustausch über Applicationsebene verläuft immer über SQL-Schnittstelle

·           Sperrmodi

·           S Share, andere Benutzer können zwar lesen jedoch nicht schreiben.

·           E Exklusiv Andere Benutzer haben keinen Lesezugriff

·           Bei Abgebrochenen Verbuchungen wird der Anwender per Expressmail benachrichtigt.

 

Aufgaben des Datenbankadministrators:

 

 

·           Backup/Restore der Daten

·           Konfigurieren

·           Steuern /Optimieren

·           Speicherverwaltung

·           Re- Organisieren der Datenbestände

·           Software plege installation update etc.

·           Zur Datenbankadministration stellt das SAP-System Tools zur Verfügung

 

 

Daten werden im SAP-System per TCP/IP transportiert. Bytegröße :

           

            SAP-GUI                   à          2        -           4 kb                   ß     Applicationsserver

            Applicationsserver   à        20       -           40 kb              ß        Backupserver

 

Dadurch ergibt sich, das man per V90/ISDN in Sinnvoller Arbeitsgeschwindigkeit auf das System zugreifen kann. Jedoch ergibt es eine Verbindung Applicationsserver Datenbank nur Sinn per Lan-Verbindung. Das R/3-System wird über ein IST-Protokoll mit dem Internet verbunden. Das IST-Protokoll besteht aus einem AGate und einem WGate welche durch TCP/IP miteinander verbunden sind. Das AGate verbindet mit dem R/3-System und das WGate  verbindet mit dem Internet.

 

Stammmandanten (Voreinstellung):

 

Mandantennummer

 

000

·           Releasewechsel, Voreinstellungen,Änderungen

·           Änderungen an diesem Mandanten sind Systemweit gültig

001

·           Kopie des Mandanten 000

·           In der Regel sind auf diesem Mandanten Testdaten gespeichert

 

066

·           Earlywatch

·           Ist für Support seitens SAP vorkonfiguriert

 

 

                                  

 

 

Workbench:

 

            Man unterscheidet zwischen verschiedenen Datenarten:

                        Mandantenabhängige Daten:

Daten auf dehnen nur Mandantenabhängig zugegriffen werden kann (z.B. Belege Materialstämme etc.). Da bei diesen Daten enge Beziehungen bestehen, werden diese schon bei Eingabe auf Customizing Einstellungen geprüft und bei fehlender Konsistenz abgewiesen.

                        Mandantenunabhängige Daten:

Einstellungen die einmal durchgeführt wurden und für alle Mandanten gelten, z.B. Druckereinstellungen.

 

Repository Objekte sind ebenfalls Mandantenunabhängig und werden wenn einmal entwickelt von allen anderen Mandanten des Systems in gleicher Form gewechselt.

 

Ein R/3 System kann (muß) für jeden Kunden neu angepaßt werden (Customizing).

Das Customizing wird nicht im gleichen Mandanten entwickelt und gesteuert indem es genutzt wird. Dadurch sind zur Implementierung eines R/3-Systems mehrere Mandanten notwendig. Bei großen Installationen in einem weiteren Mandanten zu testen. Produktiv wird schließlich im letzten Mandanten gearbeitet.

 

Repository:

·           Möglichkeit der Erweiterung des Kunden (Eigenentwicklung), der SAP-Standart wird durch Kundenobjekte ergänzt.

·           Modifikationen ändern SAP-Objekte, z.b. Tabellenfunktionen/ Programme. Sie müssen beim nächsten R/3 Upgrade abgeglichen werden ( Transport, Servicepacks). Meist mit großem Zeitaufwand verbunden.

·           Es ist nicht möglich Objekte der Repository im Produktivsystem zuverändern, zu groß wäre die Gefahr von Dateninkonsitenz. Gemäß SAP ist es Sinnvoll 2 bis 3 System einzusetzen:

·           Ein Entwicklungssystem  DEV Developing System

·           Ein Test- und Qualitätssystem OAS  Quality Assurance System

·           Ein Produktivsystem PRD Produktion System

 

Entwicklungsarbeiten beim Kunden entstehen im extra Namensraum, das heißt Kundenobjektnamen müssen immer mit Y oder Z beginnen. In jedem System sollte sich jedoch ein Mandant befinden, der die gleiche Kennung hat. Alle Systemerweiterungen und Entwicklungen sollten erst durch das Entwicklung- und Testsystem bevor es am Produktivsystem zum Einsatz kommt

 

 

ABAP

 

Abap-Dictonary

           

·           Hier sind alle SAP-Daten in Betriebswirtschaftlicher und Technischer Hinsicht definiert und beschrieben

·           Dynpro – und Abapinterpreter greifen permanent hierauf zu.

·           Hier werden Tabellen, Sperrobjekte Datenelemente etc. definiert.

·           Dient der Erfassung und Verwaltung von Daten.

·           Wird nur einmal erfasst, ist aber an jeder Stelle im System verfügbar

 

Workplace

 

·           Ab der Version R/3 3.11 ist das System Intra- bzw. Internet fähig. Wichtige Komponenten von Mysap:

·           KW           Knowledge Warehouse

·           BW           Buisness Information Warehouse

·           CRM        Customer Relationship Managment

·           APO         Advanced Planer Optimiezer

·           SEM         Strategic Enterprise Managment

·           CFM         Corporate Finance Managment

·           BBP         Buisness to Buisness Procurement

 

Komponenten im einzelnen:

 

BBP

·           E Commerce Komponete für den Betrieblichen Ablauf

·           Zeitnahe Kommunikation mit den Lieferranten

·           Effiziente Abwicklung von rechnungen und Zahlungen

·           Sicherer Datentransfer

·           Es können verschiedene Szenarien der Anbing an Systemen erfolgen:

·           Klassisch : Komplette Materialwirtschaft läuft in einem oder mehreren externen Systemen

·           Entkoppelt           :Bedarfsanforderungen für nicht Produktionsgebundene Waren werden direkt in das  EC-System weiterverarbeitet und die Bestellung, sowie alle folge Belege werden angelegt. Produktionsgebundene Waren und Dienstleistungen werden weiterhin über ERP System beschaft.

·           Standalone         : Kein Materialsystem ist vorhanden und man nutzt weiterhin die Materialbeschaffung im SAP BBP.

·           Über dem Buisness Connector wird die Bestellung an dem Verkäufer im XML format gesendet.

            KW

 

·           Im Knowledge Warehouse werden Informationen gesammelt und verwaltet. Dort können von SAP erstellte Schulungsunterlagen und Dokumente genutzt werden. Desweiteren kann man sie durch Firmenspezifische Dokumente ergänzen. KW ist an BW angeschlossen, so daß der zugehörige Workflow ausgelöst wird wenn Objekte erstellt oder verändert werden.

·           Jedes KW-System hat mindestens einen Content- und einen Cache-Server. Der Content-Server stellt die Inhalte aus dem KW bereit. Er ist ein Fileserver und enthält die Dateien im Authoringformat (*.ppt und .doc) sowie im Anzeigeformat (.html und *.gif) .  Es werden alle Objekte nur im Anzeigeformat an den Cacheserver verteilt. Der Cache-Server lagert die Dokumente im Anzeigeformat um einen schnellen Zugriff darauf zu ermöglichen.

 

 

APO

            Der Apo ist eine vollständige Lösung für die Logistikkette.

 

            Produktions- und Fertigungsplannung:

·           Erzeugt und Überprüft Produktionspläne unter Einbeziehung der vorhandenen Ressourcen. Wodurch schnelle Lieferzusagen am Kunden möglich werden.

 

Supply Network Planning

·           Gleicht Einkaufs- , Produktions- und Transportprozesse mit dem Bedarf ab. Optimierung der Logistikkette.

 

            Absatzplannung

·           Analysiert Bedarfsmuster und erstellt Prognosen

 

            Supply Chain Cockpit

·           Analysiert die gesamte Logistikkette und bietet dem Benutzer eine Ansicht aller Aktivitäten.

 

CRM

Versetzt Firmen in die Lage Kundenbeziehungen während der gesamten Lebensdauer eines Unternehmens zu pflegen. Gleichzeitig bietet es dem Unternehmen Anforderungen der Kunden nachzuvollziehen. Es unterteilt sich in 4 Bereiche:

 

            Mobile Sales Szenario

·           Zugriffe des Außendienst Mitarbeiters auf für sie wichtige Infos. Laptop wird regelmäßig mit CRM-System abgeglichen.

 

                        Contact Center Szenario

·           Schlüsselkomponete des CRM, hierüber werden alle Kundenkontakte abwickelt und aufgezeichnet.

 

                        Internet Sales Szenario

·           Ermöglicht die Geschäftsabwicklung übers Internet.

·           B2B

·           B2C

 

                        Buisness to Buisness Produrement ( SAPBBC)

·           Lösung für Geschäftsabwicklung zwischen Firmen und Web.

 

           

                       

 

MySAP-Marktplatz

 

            Der MySap-Marktplatz läßt sich in 4 Bereiche unterteilen:

·           Communities

·           Virtueller Zusammenschluß einer Branche

 

·           Content (Inhalte)

·           Hinweise zu Branchenveranstaltungen Branchennews etc.

 

·           Commerce (Handel)

·           Branchenverzeichnis

·           Eingetragene Unternehmen bieten hier Ihre Produkte an

 

Der Marktplatz ermöglicht in einem einzigen Arbeitsgang Waren und Dienstleistungen zu kaufen und zuverkaufen.

 

 

 

 

 

Administration

 

Sicherheitsaspekte:

·           Die SAPGUI prüft bei jedem Start auf Integrität durch Prüfsumme. Dadurch werden Manipulationen (z.B. durch Viren) an der GUI schnell erkannt.

·           Firewall mit SAP-Router schützen das interne Netz vor unberechtigten Zugriffen.

·           Das SAP-Berechtigungskonzept verhindert unerlaubte Zugriffe auf Daten und Transaktionen. Identifikation durch BenutzerID und Paßwort.

·           Internet Sicherheitsstandarts werden unterstützt z.B. HTTPS.

·           Zugriffe außerhalb des Komponetensystems auf die Datenbank sind nur dem Datenbankadministrator möglich.

·           In den Standartmandanten 001 und 000 sind Benutzer ( SAP* und DDIC) mit erweiterten Rechten angelegt, die Standartpasswörter sollten ( müssen) direkt nach der Installation geändert werden.

 

Berechtigungskonzept:

           

Berechtigungen werden in Profilen abgelegt ( Arbeitsplatzbeschreibungen). Profile werden unterzuhilfenahme des Profilgenerators erzeugt. Profile werden als Rollen verwaltet, wodurch sie erweiterte Attribute besitzen z.B. Gültigkeitsdauer. Jeder Benutzer kann einer oder mehreren Rollen zugeordnet sein. Ab Version 4.6 wird eine große Anzahl Rollen vordefiniert ausgeliefert, die dem eigenem Unternehmen angepasst werden können. Seit Version 4.5 ist die Benutzerverwaltung nicht mehr auf einem Systembeschränkt, sondern kann auf weiteren Systemen portiert werden.

 

CCMS Computing Center Management System

 

Mit dem CCMS kann man ein SAP-System komplett überwachen, steuern und konfigurieren.

Grafische Monitore und Verwaltungsfunktionen des CCMS:

 

·           Start und Stop des System

·           System Überwachung und Analyse

·           Melden von Systemalarm

·           Dynamische Benutzerverteilung

·           Systemkonfiguration Bearbeitung der Systemprofile ( nicht Berechtigungsprofile)

·           Verarbeitung und Steuerung von Hintergrundjobs

·           Einplannung von Daten Sicherung

 

 

SAP-Service Marktplatz

           

            Der Service Marktplatz der SAP ist nur für Kunden mit gültiger Kennung. Er bietet folgenden Service:

·           Probleme können direkt nach SAP gemeldet werden.

·           Es gibt eine SAP-Schulungsübersicht

·           Hinweisdatenbank mit Faq

·           Hotnews

·           Hot Packages

·           Etc

 

 

                                  

 

 

R/3 Installation

 

            Manuelle Vorbereitungen:

                        Anlegen von Verzeichnissen:

·          /tmp/install

·          usr/start/trans  wird in /mnt/sap gemountet

·          anlegen der Unix-Nutzer ORA <sid> und & <sid> Admin

·          Einrichten von logischen Diskvolumens und der Dateisysteme

·          Anlegen von Oracle Verzeichnissen

·          Unix-KernelAnpassungen

·          Konfiguration des Swap-Spaces

 

Erfassen von R/3 Konfigurationsparameter

 

·          Abfrage von

·          Datenbanknamen

·          Datenbankrechnern

·          Benutzern

·          TCP/Ip Ports

 

 

 

Start des R/3 Setup auf dem Zielrechner

 

·          Automatische Erzeugung des Startkommandos für den InSTGUI

 

Überprüfen der Voraussetzungen

 

·          Kontakt zum INSTGUI

·          TCP/IP Ports

·          Group-Ids

·          Benutzer-Ids

·          Berechtigung auf Verzeichnisse

·          Links zu Verzeichnissen

·          Kontrolle des Verfügbaren Plattenplatzes

 

Entpacken der Software

 

·          Speicherung in die entsprechenden Verzeichnisse

 

Setzen der Arbeitsumgebung der Benutzer

 

Entpacken der Oracle - Software

 

·          Speicherung in die entsprechenden Verzeichnisse

 

Stop des R/3 Setup

 

Oracle Installation

·          Installation der Oracle-Software

 

Erzeugen der R/3 Datenbank

           

·          Kontrolle der größe der vorgesehenen Datenbank

·          Anlegen einer leeren Datenbank

·          Anlegen der Datenbankuser

·          Import der Daten

 

Import der ABAP

 

Erzeugen einer Temporären Lizenz

 

Manuelle Nachbearbeitung

·          Saplicence – get                        // Seriennummer des Systems

·          Saplicence – install        // Aktivieren der neuen Licence

 

 

 

 

Änderungen am System

 

            Transporte besitzen immer eindeutige Namen. Sie setzen sich zusammen aus:

·          Dreistelliger Systemname

·          Dem Kürzel K9

·          Fortlaufender 5-stelliger Nummer

·          Bsp. Y41k950486

 

 

Mandantenverwaltung

 

Mandanten werden über dreistellige Nummer identifiziert. Man unterscheidet zwischen Mandanten abhängigen und Mandantenabhängigen Daten. Bei Mandanten abhängigen Daten ist die Mandantennummer im ersten Feldnamen (Mnadt) der Tabelle vorhanden, und ist gleichzeitig der erste Teil des Primärschlüssels der Tabelle. Jeder Benutzer hat immer nur Zugriff auf die Daten die dem Mandanten zugeordnet sind in welchem er sich angemeldet hat.

Benutzer und Konfigurationen sind Mandantenabhängig, jeder Benutzer kann nur in dem ihm zugeordneten Mandanten arbeiten. Jeder neue Mandant wird einer Rolle zugeordnet:

·          Produktiv

·          Test

·          Customizing

·          Demo

·          Training/Education

·          SAP-Referenz

 

 

Mandanten können vor dem Kopieren und vergleichen  mit anderen Mandanten geschütz werden, es gibt 3 verschiedene Schutzstufen:

·          Schutzstufe          0          // Keine Beschränkung

·          Schutzstufe          1          // Kein Überschreiben

·          Schutzstufe  2     // Kein Überschreiben Keine Externe Verfügbarkeit

 

Der Sinn dabei ist, gerade im Produktivbereich zu verhindern das der gerade genutzte Mandant versehentlich oder absichtlich überschrieben wird. Ein Mandant der Schutzzone 1 oder 2 kann nicht mehr überschrieben werden. Schutzstufe 2 verhindert darüber hinaus den vergleichenden externen Zugriff auf diesen Mandanten. R/3 bietet ein spezielles Werkzeug zum Vergleichen zweier Mandanten, damit wird z.b. geprüft ob das Customizing zweier Mandanten identisch ist oder welche Abweichung es gibt. Diese Infos sind für den Test wichtig, da die Test- und die Produktionsumgebung immer identisch sein müssen.

 

 

Lokales Kopieren von Mandanten:

Im Transaktioncode sccc gelangt man zum Mandantenkopierer.

Mit Hilfe des Profils selektiert man die zu kopierenden Daten.

Im Menüpunkt Springen à Profil ändern gelangt man in die Profilpflege.

Mandanten sollte immer im Hintergrund kopiert werden, das das Kopieren in Abhängigkeit von der Datenmenge und der Leistungsfähigkeit der Hardware mehrere Stunden dauern kann. Es ist nicht sinnvoll den Kopiervorgang in den Vordergrund laufen zu lassen, da er einen Dialogprozeß blockieren würde.

Mit der Option Testlauf kann der gesamtvorgang zunächst versuchsweise durchgeführt werden.

Um das Fortschreiten des Kopierens zu kontrollierenkann man von jedem anderen Mandanten während des Verlaufs des Kopierens einsicht in die Protokolle nehmen. Bei einem aktiven Kopierverlauf kann ein Monitor zur graphischen Kontrolle eingesetzt werden.

 

Benutzer und Berechtigungen

 

Man unterscheidet im R/3 Umfeld 3 Benutzerarten:

 

·           Benutzer auf Betriebssystemebene

·           Datenbankbenutzer

·           R/3 Nutzer

 

Die Benutzer sind absolut unabhängig von einander. Hier geht es ausschließlich um R/3 Benutzer. Jeder Benutzer hat einen Benutzerstaammsatz:

 

·           Benutzername

·           Zugeordneter Mandant

·           Passwort

·           Firmenadresse

·           Benutzertyp

·           Startmenü

·           Anmeldesprache

·           Persönlichen Druckereinstellungen

·           Zeitzone

·           Aktivitätsgruppe

·           Berechtigungen

·           Verfallsdatum

·           Parametervorbelegung

 

Superuser sind jeweils der Sap* und DdiC.

Sap* verfügt standartmäßig über alle Berechtigungen im Sap-System.

DDIC verfügt Standartmäßig über vollständige Rechte zur Verwaltung des Reporsitorys. Die Nutzung des Transport und Korrekturwesens ist im nur im Anzeigemodus möglich, wodurch Eigenentwicklungen ausgeschlossen sind.

 

Die Benutzerverwaltung erreicht man über Werkzeuge à Administration à Benutzerpflege. Hier sind sämtliche Funktionen zum Anlegen, Ändern, Löschen und zur Eigenschaftenpflege vorhanden.

 

Es gibt bei neuen Benutzern verschiedene Arten der Anmeldearten:

·           Dialog

·           Einem Dialognutzer stehen alle Formen des Sap-Systems offen

·           Hintergrund

·           Ein solcher Benutzer kann lediglich zur Ein plannung und Ausführung von Hintergrundgrundjobs genutz werden. Es ist ihm nicht gestattet sich anzumelden  und im Dialog zu prozessieren.

·           BDC

·           Dem Benutzer BDC ist nur das Ausführen von Batch-Input-Abläufen gestattet.

·           CPIC

·           CPIP-User haben ebensfalls keine möglichkeit im Dialog mit R/3 zu arbeiten. Standartmäßig wird der Benutzer SAPCPIC mit einem neuen System ausgeliefert. ER ist vollkommen Berechtigungslos und wird nur für interne Zwecke gebraucht. Er darf nicht verändert werden.

 

Standartmäßig ist in jedem R/§-System die Gruppe Super eingerichtet, in der der auch der User SAP* vorhanden ist. In der Benutzerpflege unter Umfeld à Benutzergruppen können neue Gruppen hinzugefügt werden.

 

 

 

 

 

 

 

 

 

 

 

 

Benutzer sollten, gemäß SAP-Sicherheitsrichtlinie,  immer von 2 Leute angelegt werden:

 

·           Benutzeradministrator              

·           Legt die neue Benutzer an

·           Berechtigungsadministrator

·           Verteilt die Berechtigungen an die entsprechenden Nutzer

 

Durch aufteilung der Benutzerverwaltung wird das Risiko minimiert, das sich ein Benutzer mit allen Rechten ausstatte, und vollen Zugriff auf die Daten hat.

 

Bei Abbruch einer Transaktion aufgrund fehlender Berechtigungen kann mit dem Transaktioncode su53 eine Liste der fehlenden Berechtigungen abgerufen werden.

 

Hintergrundjobs

 

Hintergrundjobs setzen sich aus 3 wesentlichen Aspekten zusammen:

 

·           Allgemeine Angaben

·           Jobname

·           Jobklasse

·           Zielrechner

·           Angaben zum Startzeitpunkt bzw. zum Startereignis

·           Verarbeitung

 

Allgemeine Angaben

·           Jobname

·           Sollte möglichst aussagefähig sein

·           Jobklasse

·           A Höchste Priorität

·           B Mittlere Priorität

·           C Normale Priorität

·           R/3 Anwender nutzen in der Regel jobs der Jobklasse C.

·           Man kann auch die Ausführung eines Jobs einem bestimmten Backround-Service zuweisen. In der Regel wird aber ein Freier Backround-service vom System zugewiesen. Wenn man ein Protokoll erstellt, kann man diese dem Administrator oder dem Benutzer automatisch zuschicken.

·           Startzeitpunkt

·           Der Starttermin wird durch Zeitangabe oder Ereignis gesteuert, Desweiteren kann die Abarbeitung eines Jobs auch in abhängigkeit mit einem bereits definierten Job geplant werden. Er kann auch Statusabhängig definiert werden, das heißt wenn der voherige Job abgebrochen wird startet auch der zweite job nicht.

 

 

Auswertung von Hintergrundprozessen:

 

            Die Auswertung erfolgt mittels Transaktionscode sm37. Die  Jobauswahl erfolgt über Kriterien wie Benutzer, Zeitraum oder Ereignis sowie über den Status. Die Selektionskriterien  können über das Berechtigungskonzept eingegrenzt werden. Eigene Jobs können mittels Stem à Eigene Jobs eingegrenzt werden.

 

Der Jobstatus hat folgende Bedeutung:

·           Geplant

·           Alle Jobdaten wurden gesichert

·           Freigegeben

·           Jobdefinition ist vom System überprüft und Freigegeben worden

·           Bereit

·           Der Job wartet auf Systemressourcen zur Ausführung

·           Aktiv

·           Der Job wird gerade ausgeführt

·           Fertig

·           Der Job wurde Erfolgreich zu ende gebracht

·           Abgebrochen

·           Aufgrund eines Problems wurde die Verarbeitung abgebrochen

 

Mit der Job-Performanceanalyse im CCMS kann man eine zusammenfassung aller ausgewählten Hintergrundjobs hinsichtlich geplanter und tatsächlicher Startzeit anzeigen lassen. Größere Abweichungen lassen sich auf Engpässe bei den Background Prozessen schließen.

 

Verbuchung

 

Hinsichtlich der Verbuchung unterscheidet man zwischen V1 und V2 Verbuchungen. V1 Verbuchungen sind immer Zeitkritisch und primär, sie betreffen Betriebswirtschaftliche Vorgänge z.b. Änderungen am Materialbestand. Daher müssen V1-Verbuchungen immer mit höchster Priorität bearbeitet werden. V2-Verbuchungen dienen meist statistischen Zwecken und sind untergeordneter Natur. Im Standartprofil default.pfl ist durch den Parameter Rdisp/Vbname definiert welcher Applicationsserver für die Verbuchung zuständig ist. Die Obergrenze der Verbuchungen ist von der Leistungsfähigkeit der Hardware abhängig.

 

 

Verbuchungssätze können 4 Statusmeldungen annehmen:

·           Init

·           Wartet auf Verbuchung

·           Auto

·           Ist die Verbuchung aktiv, wird der Satz automatisch verbucht

·           Run

·           Der Satz ist gerade in Bearbeitung

·           ERR

·           Es traten Fehler auf die zum Abbruch führten

 

Ausgabegeräte

 

           

·           Produktivdrucker (Zeitkritische Drucker)       

·           Dienen direkt dem Produktivsystem

·           Sollten lokal am  Applicationsserver betrieben werden

 

·           Massendrucker

 

·           Für Zeitaufwendige Druckjobs gedacht

·           Leistungsfähige Drucker

·           Arbeitsplatzdrucker

·           Standartdrucker

·           Lokal am Arbeitsplatz

·           Für kleinere Drucke geeignet

 

·           Testdrucker

·           Für neue Drucker

·           Änderungen an der Ausgabe Konfiguration

 

 

Koppelarten

 

Koppelarten beschreiben die Methode bzw. das Protokoll, das zur Übertragung der Daten für den Ausgabe Auftrag vom Aufbereitungsserve zum Hostdrucker verwendet wird

 

Lokale Kopplungsarten:

           

·           Koppelart L

·           Die Daten werden mit dem Spoolservice als Datei auf dem Host abgelegt. Von dort werden sie mit den entsprechenden Hostbefehlen gedruckt

·           Print für Win-System

·           LPR für UNIX

·           Koppelart C

·           Hier werden die Daten ohne zwischenspeicherung im Dateisystem unter Verwendung der Programmierschnittstelle an den Druckmanager des Systems übergeben. Funktioniert nur mit WinNt und AS/400.

 

·           Koppelart E

·           Kann nur bei einsatz eines QMS verwendet werden

 

·           Koppelart P

·           Dient der Gleichzeitigen Ausgabe auf mehreren Druckern. Möglichst gleiche Drucker werden zu einem Gerätepool zusammengefasst. Ein Gerätepool kann max. aus 15 im R/3 Systemdefinierten Geräte bestehen.

 

·           Koppelart F

·           Frontend Druck

·           Das Ausgabegerät ist am Frontend des Benutzers angeschlossen.

 

Entfernte Koppelarten

 

Bei den folgenden Koppelarten wird der Druckauftrag übers Netz geschickt, daher reagieren diese Koppelarten sehr empfindlich auf Netzwerkproblemen. Für Produktionsdrucke sollten diese Arten nicht genutz werden, da bei Netzwerkproblemen lange wartezeiten entstehen.

 

·           Koppelart S

·           Diese Koppelart wird genutz für Drucker die als Arbeitsplatzdrucker an Win-System fungieren. Die Daten werden in komprimierter Form über das Netz an das Frontend geschickt.

 

·            Koppelart V

·           Die Koppelart V kann als Protokoll zum Spoolsystem von Unix und OS/2 Systemen dienen. Basiert auf RFC 1179. Kann im Extremfall auch für WIN32 Systeme verwendet werden.

 

Für andere als Druckerausgaben stehen spezielle Koppelarten zur Verfügung.

 

·           Koppelart X

·           Hiermit können SAP-Comm Aufträge als Fax ausgegeben werden.

 

·           Koppelart I

 

·           Dient zur Verwendung bei Sap Archivlink. Das Spoolsystem wird als zwischenspeicher eingesetz. Die Weiterverarbeitung übernimmt Archivlink.

 

 

 

SAP80

 

ASAP

Asap ist die umfassende Lösung für die Implementierung von R/3. Asap beinhaltet :

·           Roadmap

·           Toolkit

·           Service und Support

·           Accelerators

 

Asap ist seit Release 3.1 für alle Berater und Mitarbeiter der Sap verfügbar. Ab Release 4.0 ist Asap generell für alle Verfügbar.

 

R/3 Service Bereiche

·           Supportservice

·           Alle Leistungen sind bereits in der Wartungsgebühr enthalten

 

 

·           Consulting Service

·           Wird von SAP-Spezialisten ausgeliefert

·           Lieferung der Regionale Service Center

·           Basierend auf Service Tools und Prozeduren

 

Customer Competence Center CCC

           

            Aufgabe:

 

·           Technische Unterstützung

·           Buisness Support

·           Projekte und Implementierung

·           Anwender Schulung

·           Informationsmanagment

·           Vertragsadministration

·           Koordination der Entwickler Anforderungen

·           Vertriebsunterstützung

·           First Level Support

 

Remote Verbindungen

 

Viele Leistungen der SAP werden per Remote System zur Verfügung gestellt, dadurch Zeitersparniss und geringere Kosten beim support. Probleme können teilweise direkt übers Netz behoben werden.

 

Remote Verbindung über TCP/IP

           

SAP empfiehlt aus Sicherheitstechnischen überlegungen herraus nur über spezielle Saprouter eine Verbindung übers Netz herzustellen. Sap-Router lassen nur den Datenstrom von Dedizierten IP-Adressen über einen einzigen bestimmten Port zu.

 

Sap-Router

           

·           R/3 Applications-Gateway

·           Lauffähig auf alle R/3 Plattformen und auf NT-Workstation

·           Firewallfunktionen auf Applicationsebene Steuerbar

·           Keine Offiziellen IP-Adressen erforderlich

·           Einfaches Routing

·           Verbindungen werden Protokolliert

 

R/3 Läßt sich Problemlos an Unternehmensweite Sicherheitssysteme anbinden wie z.B. Kerbos5. Sicherheitssysteme müssen von Drittanbietern bezogen werden.

 

Online Service System OSS

Das OSS ist das zentrale Kommunikationsmedium für SAP-Kunden, SAP-Partnern und SAP-Mitarbeitern  und steht 24 Stunden zu verfügung. Dort werden Fragen direkt an SAP gerichtet, oder man kann die Hinweisdatenbank nach Fehlern durchsuchen. Im Abschnitt Hotnews finden sich immer die aktuellsten Infos zu R/3. Man kann sich auch Vorrabkorrekturen über Hotpackages in sein System spielen. Sap-Partner können User im OSS selbständig anlegen. Über Serviceverbindungen hat man die möglichkeit einem SAP-Mitarbeiter den Zugang zum System zuermöglichen (SAP-Router vorrausgesetzt) .

Schulungsinformationen können dort angezeigt werden:

·           Alle Sap-Schulungen sind einsehbar

·           Angezeigt werden

·           Inhalte

·           Dauer

·           Datum

·           Freie Plätze

·           Schulungen können direkt Reserviert werden

·           Hotels und Übernachtungsmöglichkeiten werden angeboten bzw. vermittelt

 

 

 

SSCR

 

Ab Release 3.0A wird ein SAP-Schlüssel benötigt um Änderungen am Sap-System vornehmen zu können. Alle Veränderungen werden bei SAP registriert. Regietriert wird jeder Entwicklungsuser der ändert, löscht und Anlget, sowie die geänderten Objekte und Daten. Aufgrund dieser Informationen können SAP-Support-Mitarbeiter schnell potentielle Fehlerursachen erkennen und beseitigen. Durch den Zwang der Registrierung verringert sich die wahrscheinlichkeit von unbeabsichtigten Modifikationen. Upgrades und Releasewechsel werden erleichtert. Mit der Modifikation von Sap-Sourcen erlischt die Gewährleistungpflicht der Sap. Die Registrierung wird notwendig sobald eine Modifikation begonnen wird.

Die Registrierung wird nicht notwendig bei änderungen an:

·           Matchcode

·           Datenbankindizies

·           Puffereinstellungen

·           Kundenobjekten ( Namensraum des Kunden)

·           Objekten die aufgrund Automatischer Generirung geändert werden, z.b. Customizing.

·           Eigenentwicklungen im Rahmen von User Exit

 

Es Gibt 4 Arten von Änderungen und Anpasssungen des SAP-Systems an den Erfordernissen der Kunden:

 

·           Customizing

Einstellung von Systemparametern über eine eigene Oberfläche. Änderungen sind vorgedacht und vororganisiert. Customizing ist Obligatorisch vor Inbetriebnahme des Systems.

 

·           Modifikationen   

Eingriffe in die SAP-Repositoryobjekte in Form von Kundeneigenen Änderungen. Bei Änderungen durch die SAP muß die Kundenversion mit der SAP-Version manuell abgeglichen werden.

 

·           Erweiterungskonzept

                                   Veränderung von SAP-Repositoryobjekte  durch den Kunden ohne Modifikation.

 

·           Eigenentwicklung

Erzeugung von Kundeneigenenobjekten unter berücksichtigung des Kundennamensraums um Funktionalitäten zuerweitern.

 

User Exit

Anpassung des Sap-Systems an Unternehmens erfordernissen lassen sich mittels UserExit realisieren. Dadurch wird nicht mehr der Orioginalcode modifiziert sondern ein eigener Bereich welcher von der Sap angelegt und mit Standartwerten hinterlegt wurde, Die Erweiterungen können individuell aktiviert werden. Bei Sap-Systemerweiterungen werden Modifikationen am Uder Exit vermieden.

 

SAP-Anwendungserweiterung

Durch Anwendungserweiterungen kann eine Anwendungsfunktion vom Kunden erweitert werden. Anwendungserweiterungen sind zunächst inaktiv  und können vom Kunden aktiviert werden.Eigenschaften der Erweiterung:

·           Je erweiterung steh ein vorgedachter Namensraum zur Verfügung

·           Die Schnittstelle zwischen SAP und Kunde ist klar definiert.

·           Kunde benötigt kuam Kentnisse der SAP-Anwendungssimplementierung

·           Bei einm upgrade ist kein abgleichen mit Sap-weiterentwicklungen erforderlich.

 

Programmerweiterungen sind auf folgenden Ebenen möglich:

 

·           Im Abap/4 Modul (Programmexit)

·           In der GUI-Oberfläche ( Menü exit)

·           In der Dynproablauflogik

·           Mit einblendung eines Subdynpros ( Dynproexit)

·           Durchlauf Kundeneigenes Coding (Feld Exit)

 

            Bis auf Feldexit müssen alle Exits von SAP-Anwendungsprogrammieren vorgedacht werden.

 

ServiceVerbindungen einrichten und öfnnen

           

Im OSS-System können mit der Drucktaste ServiceVerbindungen verschiedene Funktionen durchgeführt werden:

·           Änderung von Technischen Daten z.B.

·           TCP/IP Parameter

·           Hardwareeinstellungen

·           Betriebssystem

·           Datenbanksystem

·           Ansprechpartner

·           Etc.

·           Logische Verbindungen können nach SAP geöffnet und geschlossen werden.

 

 

CSA

 

            Präventive Leistungen des CSA

Das CSA führt regelmäßig Systemüberprüfungen durch. Dadurch werden unregelmäßigkeiten im Sap-System erkannt. Wenn das CSA im Produktiven Bereich Positioniert wird, lassen sich dadurch Waretezeitenbei Automatisierung von Support- und Serviceprozessen minimieren. Kommunikationskosten werden reduziert. Durch das CSA wird Automatisch die zuständige Supportabteilung der SAP informiert, welche sich dann unaufgefordert  mit entsprechenden Lösungsvorschlägen mit dem Kunden in Verbindung setzt.

 

Upgrade auf Release 4.0

           

            Neuheiten

·           Erweiterte Buisness Frame work

·           Eigenständie Einsetzbare Betriebswirtschaftliche Komponenten die über 200 neue Geschäftsprozesse enthalten

·           2 neue Branchenspezifische Lösungen

·           R/3 Retail für den Handel

·           R/3 Public Sector für den öffentlichen Bereich

·           Erweiterte Funktion für die Euroumstellung

 

 

Customer und Partnersysteme

           

Das Customer und Partnersystem ist ein R/3-System mit aktuellsten Releasestand. Hier können sich Kunden und Partner über eine Remoteverbindung einwählen um neue Release zu testen ohne ein System installieren zu müssen.

 

Online Correction Support OCS

 

OCS faßt verschieden Werkzeuge zusammen, die dazu dienen Patches von SAP abzuholen und einzuspielen. Es sind zur Zeit die Patchtypen Hotpackes und CRT ( Conflikt Resolution Protokoll) verfügbar.

           

·           Hot Packages

·           Sammlung von Korrekturen im Repository

·           Können über das OSS bezogen werden

·           Namenskonventionen

·           Sapkh<korrekturstand><laufende Nummer> (10-stellig)

                       z.B. SAPKH31G02

·           Sind immer nur für einen Korrekturstand gültig

·           Müssen zwingend Sequentiell eingespielt werden.

·           Der Sap Patch Manager (SPAM) stellt sicher, das Hot Packages in Sequentieller Folge eingespielt werden., dadurch wird die Konsitenz des Systems Gewährleistet.

·           Es werden nur eine beschränkte Anzahl von Objekttypen transportiert

·           Hot Packages korrigieren nur Fehler die in Programmen auftreten

·           Es werden keine Änderungen im Abap/4 und an der Oberfläche vorgenommen, da es zu Dateninkonsistenz oder auch zu Datenverlust führen könnte.

 

·           CRT

·           Wird nur bei ADD-Ons und IS-Oil verwendet

·           Dienen dazu Konflikte zwischen Hot Packages und ADD-Ons zu beseitigen

·           Werden über OSS verteilt

 

 

Konflikte entstehen wenn ADD-Ons und Hotpackages die gleichen Objekte enthalten. Die Konflikte werden durch CRT Patches gelöst. Ein Patch ist immer nur für eine bestimmte auflösung von Konflikten gedacht z.B.  SAPKIPFE04 ist zur Auflösung von Konflikten zwischen ADD-On IS-IS und Hot Packages SAPKHFE04 vorhanden. CRT sind auch über dem OSS verfügbar, sie werden auch über die SPAM, unter berücksichtigung der Reihenfolge eingespielt.

 

 

            Ziele des OCS

                       

·           Keine Programmänderungen im R/3-System

·           Schnelle Bereitstellung von aktuellen Patches

·           Einfaches Einspielen von Patches

·           Vermeidung von Fehlern beim Übernehmen

·           Transporte brauchen nicht mehr per FTP vom SAP-Server geholt werden.

·           Patches können direkt aus dem OSS ins System gespielt werden, ohne Umweg über das Betriebssystem

 

Legal Change Patches

           

Gesetzliche Änderungen in den Unterstützenden Ländern erfordern Anpassungen an Hot Packages Objekten. Werden wie Hot Packages im Oss abgeholt und im Spam eingespielt. Hot Packages sind Online über das OSS verfügbar und werden periodisch auf CD als Hot Packages Collection versandt. Da die Hot Packages teilweise über 100 MB groß sind, ist es nicht immer  sinnvoll sie sich über das OSS zu laden. Hot Packages sollten aus Sicherheitsgründen immer erst ins Testsystem geladen werden. Es muß eine RFC-Verbindung zwischen dem System und dem OSS bestehen.

 

Einspielen von Hot  Packages:

           

·           Ein Queue wird Definiert

·           Funktion einspielen wählen

·           Protokolle müssen kontrolliert werden

·           Das erforderliche Einspielen der Hot Packages wird bestätigt

 

Der Status wird in der Transaktionspam angezeigt:

 

·           Gelb         Hot Packages wird eingespielt

·           Grün         Hot Packages ist bestätigt

·           Rot                       Einspilen wurde abgebrochen

 

Das Einspielen ins Produktivsystem verläuft analog, jedoch sollte zuerst das Testsystem auf Fehler überprüft werden.

 

Spam

Die Transaktion Spam übersprpft vor dem Einspilen ob alle Reperaturen an SAP-Objekten beendet sind. Nach einem Abbruch setzt die Transaktion in dem Schritt wieder auf in welchem der Fehler stattgefunden hat. Vor dem einspielen eines Patches werden alle betroffenen Objekte durch Export gesichert. Die Sicherung wird bei Bestätigung des einspielenes gelöscht. Konflickte zwischen Add-Ons und Hot Packages werden beim einspielen erkannt.

 

 

 

 

 

 

 

SapNet

            Sapnet ist ein weltweiter Service via Inter- und Intranet für Informationen und Kommunikation. Es ist verfügbar für Sap-Mitarbeiter, Kundenn und Sap-Partner, und basiert auf der R/3 Informationsdatabase. Es versorgt alle Leser zeitnah und Ortsunabhängig in verschiedenen Sprachen. Es ist die zentrale Sap-Info-Quelleweltweit in mehreren Sprachen. Sap-Net bietet:

·           Licence Key Request

·           R/3 Customer Data entry from/first Delivery

·           R/3 Installation Release order for Contrakt

·           Bestellung von Knowledge Produkts

·           Bestellung Multimedialer Schulungen

·           Reservierung von Schulungen

·           Going Live Check

·           Early Watch Service

·           Remote Archivierung

·           Conversions Service

·           ODBD Migrationsservice

·           Installationsanleitungen

·           Informationen zu Hot Packages

 

 

Early Watch

 

            Bietet:

·           Periodische Ferndiagnose des Systems

·           Präventive Analyse aller Wesentlichen Systemkomponenten

·           4,6,12 Untersuchungen pro Jahr inkl. Ausführlichen Bericht

 

            Dadurch

           

·           Vermeidung von Problemsituationen

·           Erhöhung/erhaltung der Systemverfügbarkeit

·           Optimierung der Systemperformance

·           Unterstützung in Kritischen Situationen

 

 

Ablauf einer Early-Watch Sitzung:

                       

·           Kunde öffnet sein System und verbindet sich nach SAP

·           Early Watch Mitarbeiter meldet sich am System an

·           System wird untersucht

·           Im Falle akuter Probleme wird der Kunde sofort informiert

·           Ergebnisse der Analyse inclusive empfehlungen erhält der Kunde in einem Early Watch Report

 

Umfang der Early Watch Analyse

           

·           Server Analyse

·           Datenbankanalyse

·           Sap R/3 Konfigurationsanalyse

·           Sap R/3 Anwendungsanalyse

·           Belastungsanalyse

 

Early Watch nutz einen eigenen Mandanten (066) und ist deshalb getrennt von den Kundendaten.  Das Password des Earlywatch wird durch den Kundengepflegt. Jede Operation des Service Mitarbeiters kann vom Kunden am Monitor verfolgt werden. Der Kunde öffnet kontrolliert und schließt die Verbindung des Early Watch.

 

Sap81

           

OSS Online Service Support

 

Voraussetzung zur Nutzung des OSS:

           

·           Anbindung an das Sap-Netzwerk

·           Verfügbarkeit einer Statischen Offiziellen IP

·           Konfiguration der Netzwerkomponenten (z.B. Sap-Router)

·           Aktuelle Sap-Guiversion

·           Daten der Netzwerkverbindung müssen Sap bekannt sein.

 

Anmeldung am OSS

Nach erfolgreicher anmeldung erhält man ein Pop_up-Fenster mit Aktuellen Neuigkeiten. Alle Neuigkeiten werden solange vorgelegt bis sie gelesen werden, oder mit [Nie wieder Anzeigen] weggeklickt werden. Jeder User hat im OSS eine eigeneInbox. Nach Anmeldung am OSS und Anzeige der Neuigkeiten gelangt man automatisch  in die OSS-Inbox. Jeder User kann nur seine eigene Inbox einsehen, es sei denn ein anderer User hat ihm im Rahmen einer Vertretungsregelung als seinen Vertreter gewählt.

 

Problemmanagment:

Bei Problemen mit dem SAP-System-System sollte zuerst die Hinweisdatenbank über dem entsprechenden Suchformular durchsucht werden.

Sollte keine Lösung gefunden werden, sollte man das Problem direkt, über ein entsprechendes Formular, an Sap senden. Von dort wird dem Kunden schnellstmöglich ein Lösungsvorschlag unterbreitet.

 

OSS Funktionen

 

Service Verbindungen einrichten

Um Sap zugriff auf ein Kundensystem zu ermöglichen muss das System im OSS angelegt sein. Das System wird wird im OSS angelegt über :

[Funktionen Service Verbindungen]à [System Anlegen] jetzt erscheint ein POP-Up-Fenster in welchen die Systemdaten eingetragen werden( z.B. Servername, zu nutzende Funktionen, Ansprechpartner etc.).

Verbindungen müssen immer von Kundenseite geöffnet werden. Um ein entsprechendes System zu öffnen wählt der Kunde sein zuöffnendes System aus und gibt an wie lanbge das System geöffnet wird. Im System-Logbuch kann er sich die eingeloggten Mitarbeiter und deren Aktionen sowie die Dauer der Anmeldung ansehen.

 

 

 

Im Oss werden folgende Berechtigungen unterschieden:

           

·           Serviceverbindungen öffnen schließen

·           Sap-Meldungen anlegen

·           Meldungen an Sap senden

·           Sap-Meldungen Quittieren

·           Sap-Meldungen wiedereröffnen

·           Patchservice

·           Schulungsinformationen anzeigen

·           Benutzerdatenpflege

·           Produktivdatenpflege

·           Hinweise suchen

·           Registrierung nutzen

·           Konzernmeldungen anlegen

 

Benutzer können im OSS problemloskopiert werde, zu jedem neuen Benutzer wird auch eine Kantaktperson angelegt.

 

Benutzer im OSS anlegen:

Pro Kundenummer wird ein OSS-Administrator durch die Sap angelegt. Im OSS Menü Verwaltung wird unter Neuer Benutzer ein Benutzer mit den entsprechenden Daten ( Name, Telefonummer etc.) angelegt. Dort werden auch die entsprechenden Berechtigungen vergeben.  Neue BenutzerID sind in der Regel in kurzer Zeit verfügbar, sie werden in der Regel innerhalb von 15 min in das Sap-System übertragen, und sind dann Systemweit gültig. Berechtigung kann man im OSS nur ändern, wenn man selbst über die entsprechenden Rechte verfügt. Sinnvoll ist es immer sich Berechtigungsvorlagen zu erstellen und diese dann auf entsprechende  neue Benutzer zu kopieren.

 

Sap Software Change Registration SSCR

 

Bei der SSCR werden alle Änderungen an dem Standart R/3 erfasst. Alle Modifikationen werden hier erfasst, inklusive des Entwicklers welcher die Informationen geändert hat. Da diese Informationen direkt bei der SAP erfasst werden, ist es der SAP bei Problemen schnell möglich Lösungsvorschläge zu erstellen. Das SSCR bietet eine schnelle Übersicht über Änderungsberechtigte User und zur Änderung angefaßte Objekte im Kundensystem. Dadurch werden potentielle Problemquellen, sowie Konflickte beim Einspielen von Hotpackages schneller erkannt.

Es gibt 3 verschiedene arten von OSS-Usern:

 

·           Super Administratoren

·           Super Administratoren sind solche Administratoren die alle Berechtigungsobjekte inkl. Administrationsberechtigungen besitzen

·            

·           Lokale Administratoren

·           Lokale Administratoren verfügen nur über Administrationsberechtigungen  für einzelne Benutzer

 

 

·           First-Level-User

·           First-Level-User zeichnen sich dadurch aus, daß sie Konzernmeldungen zur Bearbeitung entgegen nehmen und an SAP weiterleiten können.

 

·           IT Koordinatoren

·           IT Koordinatoren können Konzernmeldungen erfassen und an den First-Level-Support senden.

 

Administrationskonzepte

 

1.      Schritt      

 

                  Super Administratoren bestimmen

                             Empfehlung: 1 Superadministrator pro Niederlassung

 

2.      Schritt

 

                        Festlegung der Lokalen Administratoren

Empfehluing 1-2 lokale Administratoren pro Niederlassung. Bei wenigen OSS-Usern kann auf lokale Administration verzichtet werden, deren Aufgabe werden dann durch Super Admins übernommen.

3.      Schritt

                        Administration der First Level User          

 

                                   Zentraler CCC First-Level-Support

                                               Administration durch Super Administratoren

                                   Dezentraler CCC First-Level-Support

Administration der First-Level-User durch Lokale Administratoren                                       

4.      Schritt

           

                        Administration der IT-Koordinatoren durch Lokale Administratoren

 

SAP 82

 

Netzwerktechniken

 

3-Stufige Archtiektur

R/3 Systeme sind auf der  Grundlage offener Systeme als echte Client-Server Applicationen Realisiert. Die kommunikation zwischen Client- und Serverprozessen erfolgt über TCP/IP. Dadurch ist eine optimale Grundlage für Skalierbarkeit, Integration in bestehende DV-Lösungen sowie Integration ins WAN gewährleistet. Der Produktive Betrieb von R/3 erfordert die Bereitstellung von Server-Ressourcen über TCP/IP. Die Physikalische und Logische Struktur des Netzwerkes kann der Kundenspezifischen angepaßt werden.

 

 

 

Netzwerkinfrastrukturen

            Mann unterscheidet üblicherweise 2 Kommunikationswege voneinander:

·           Horizontale Kommunikation               

Hier kommunizieren Schichten der gleichen ebene Miteinander. Es handelt sichum eine scheinbare Kommunikation.         

·           Vertikale Kommunikation

Die Vertikale Kommunikation beschreibt den Reallen Weg durch die Netzwelt.

 

Bei R/3 wird von Client und Server ein eigenes Protokoll verwendet, auf der Client-seite wird dies durch den Sap-Gui präsentiert. Der Sap-Gui ist die Schnittstelle zum jeweiligen Betriebssystem. Er wird jeweils für ein Betriebssystem programmiert. Da der Server per TCP/IP mit dem Sap-GUI kommuniziert ist es ihm gleichgültig auf welchem Betriebssystem der Sap-GUI installiert ist. Die Betriebssystem weisen Schnittstellen zu den Transportprotokollen auf. Teilweise sind die Protokolle Betriebssystemtypisch z.B. Appletalk. TCP/IP ist das verbreiteste Protokoll. Transportprotokolle sollen den Datentransport sichern und den Weg unabhängig von der eingesetzten Topologie finden. Die Transportprotokolle weisen Schnittstellen zu den Netzwerktopologien auf, welche die bisher logische Kommunikation in einen Physikalischen Datenstrom umwandeln. Auf dieser Ebene findet auch eine Adressierung von Empfänger und Absender statt. Das Adressierungsschema ist bei allen Topologien gleich, nur die Interpretation der einzelnen Technologien ist anders.. Je nach Topologie wird die Übertragungsrate, die Zugriffsregelung auf die Verkabelung geregelt.

 

Verkabelung (IT-Verkabelungsstrategien)

           

·           Primärbereich (Backbone)

·           Verkabelung zwischen 2 Gebäuden, wird grundsätzlich mit LWL (Licht-Wellen-Leiter) ausgeführt.

 

·           Sekundärbereich (Backbone/Subnetz)

·           Verkabelung im Steigbereich (Vertikale Etagenverkabelung) der Gebäude.

 

·           Tertiärbereich (Subnetz/Traditionelle Verkabelung)

·           Horinzontalverkabelung der Etagen. In der Regel als Sternverkabelung.

 

Der Primär- und der Sekundärbereich bilden in der Regel den Backbone. Der Backbone stellt die Verbindung aller Subnetze dar, und trägt damit die Hauptlast des Netzverkehrs.  Seperate Serverbackbones ermöglichen eine besonderes hohe Verfügbarkeit untereinander, gleichzeitig wird die Sicherheit erhöht, da die User nicht direkt auf die Datenbank zugreifen können. Ein Backbone wird auch als Rückrad eines Netzes bezeichnet. Dadurch ergeben sich verschiedene Forderrungen an das Backbone:

·           Hohe Verfügbarkeit

·           Redundanz

·           Hohe Bandbreite

·           Sicherheit

Die Forderrungen können durch Hard- und Software investitionen als auch durch gute Wartungs- und Inspektionskonzepte erfüllt werden. Um eine hohe Verfügbarkeit der R/3 Systeme zu ermöglichen, wird im R/3 System ein eigener Serverbackbone zur Verfügung gestellt.

 

Merkmale von TCP/IP

           

·           Offene Protokollspezifikationen

·           Aufgrund seiner freien zugänglichkeit ist TCP/IP ideal zum Verbinden unterschiedlichster Hard- und Software.

 

·           Hardware unabhängig

·           Da TCP/IP nicht an bestimmte Hardware gebunden ist, ist es möglich nahezu alle Netzwerktopologien mit TCP/IP zu betreiben.

 

·           Einheitliches Adressierschema

·           Aufgrund des Einheitlichen Adressierschemas läßt sich jeder Rechner im TCP/IP Netz einheitlich adressieren und ansprechen.Dies gilt sowohl im internen Netz als auch im Internet (beachte private und öffentliche IP´s).

     

·           Standartisierte Protokolle

·           Protokolle der höheren Schichten ermöglichen dem Benutzer einheitlich verfügbare Dienste zur Verfügung zustellen.

 

Da die gesamte Kommunikation innerhalb des R/3-Systems erfolgt, ist es zwingend erforderlich das jedes im R/3 eingesetzte System eine eigene IP-Nummer hat. Kommunikation zwischen 2 Rechnern eines Subnetzes ist Problemlos möglich. Für die Kommunikation zwischen unterschiedlichen IP-Bereichen ist ein Router erforderlich.

 

SAP Remote Online Service

           

Beim Onlineservice der Sap gibt es gebührenfreie ( OSS, Hot Packages etc) und gebührenpflichtige ( Early Watch, Remote Support, Consulting) Dienste. Zusätzlichfallen noch die Kosten der Verbindung an. Diese sind je nach Verbindungstyp und Provider entweder zeitabhängig oder Volumenabhängig. Es ist im vorraus nicht zusagen welche art der Verbindung für den Kunden besser ist, da die Nutzzeit des Kunden schwer abzuschätzen ist.

 

 

 

 

Netzwerkcheck im CCMS

           

            /nos01            Lancheck ping

            /nst06             Statistik Lanadapter

            /nsm51           Systemzuordnung

            /nrz06             Schwellwertdefinition          

 

Sicherheitskonzepte

 

Für die Umsetzung eines entsprechenden Sicherheitskonzeptes können R/3 eigene und Systemfremde Mechanismen eingesetzt werden.

 

Allgemeine Empfehlungen der SAP:

·           Serverbetrieb im gesicherten Subnetz

·           Nutzen von vorhandenen Sicherheits Funktionen ( wie z.b. Passwortschutz)

·           R/3-Systeme in Netzwerksicherheitssystemen integrieren.

 

 

SAP 310

 

Beim Start eines SAP-Gui wird über Aufrufparamter mitgegeben ob ein bestimmter Dispatcher Prozeß angesprochen werden soll, oder ob die Anmeldung zur automatischen Benutzerverteilung des Messageservers geht. Bei Anmeldung über automatische Benutzerverteileung gibt der Messageserver die IP- und die Instanznummer eines bestimmten Dispatchers zurück, auf welchen sich der Sap-Gui dann anmelden kann. Wenn die Anmeldedaten mit den gespeicherten Daten übereinstimmen steht der Dispatcher mit seinen Workprozessen zur freien Verfügung.Als Instanz bezeichnet man eine Gruppe von Diensten innerhalb der R/3 Systemlandschaft, die gemeinsam gestoppt und gestartet werden.

Wenn der SAP-Gui eine Verbindung mit dem Dispatcher hergestellt hat, laufen folgende Schritte ab:

           

·           Der Dispatcher klassifiziert die Anfrgae und stellt Sie in die passende Request-Queue.

·           Die Anfrage  werden in der Reihenfolge des Eingangs an freie Dialogprozesse übergeben

·           Der Taskhandler Prozeß ( unterprozeß des Workprozesse) führt die Wiederherstellung des Benutzerkontextes durch.  Hier sind im wesentlichen die Daten aus laufenden Transaktionen des Benutzers und dessen Berechtigungen enthalten.

·           Dadurch wird der Dynpro Prozessor aufgerufen der die Daten in ABAP-Variablen umsetz.

·           Der ABAP-Prozessor arbeitet das Coding des PAI-Moduls  ( Prozess after input), des Vorgänger Dynpro sowie das PBO –Modul (Prozess before output) ab. Bei Bedarf erfolgt eine Kommunikation mit der Datenbank.

·           Der Dynpro-Prozessor setzt anschließend die ABAP-Variablen wieder in Dynprofelder um, und das Taskhandler wird wieder aktiv.

·           Der aktuelle Benutzerkontext wirdvom Taskhandler im Shared Memory abgelegt.

·           Die Ergebnisdaten werden über den Dispatcher an das Frontend zurückgegeben

 

Sollte eine Transaktion aus meheren Dynpros bestehen, so werden die oben dargestellten Prozesse von verschiedenen Dialogprozessen abgearbeitet.

Beim Start des Betriebssystems startet der Startmanager die Dienste der Datenbank.

 

Start einer Oracle-Datenbank auf einem WINNT System:

           

·           Log on am System mit <sid>am

·           Das R/3 System wird gestartet über eine WINNT MMC ( Mikrosoft Managment Console), durch klick auf Systemicon und Start.

·           Das Programm Sapstartsrc.exe sendet eine Nachricht mit der <sid> und der Instanznummer zum System.

·           Der Sap-Service startet und dadurch läuft bei WINNT ein Script ab, welches die Oracle-Datenbank startet.

·           Sobald die Datenbank läuft startet der SAP-Service  den Messageserver ( Msgserver.exe) und den zentralen Dispatcher ( Disp.exe und work.exe)

·           Das das Icon der zentralen Instanz gibt eine von 4 Statusmeldung raus:

·           Grün                     System ist erfolgreich gestartet

·           Gelb                     System wird gerade gestartet

·           Rot                       Startprozess wurde abgebrochen

·           Grau                     Startprozess läuft nicht an

·            Es ist auch möglich das  R/3-System über den NT eigenen AT   Startmanager zu starten.

·           Befehlszeilen

·           Start : startsap name=<SID> nr=<nr> SAPDIAHOST=<hostname>

·           Stop:  stoptsap name=<SID> nr=<nr> SAPDIAHOST=<hostname>

·           Folgende  Dateien  müssen sich im gleichen Verzeichnis befinden:

·           Sapstart.exe

·           sapsrvkill.exe

·           sapntwaitforhalt.exe

 

Funktionen des MMC-Snap-IT des R/3-Systems

           

·           Starten und stoppen des Systems per MausklicK

·           Es zeigt die Prozesse des R/3-Systems an

·           Zeigt die Systemumgebung an

·           Zeigt den aktuellen Alarmstatus des Systems an (Transaktionscode RZ20)

·           Man kann Analysetools für die einzelnen Rechner starten

·           Systemlogs können  einsehen werden (Transaktionscode RZ21)

·            Fernverbindungen zum Applicationsserver können aufgebaut werden.

·           Prozesse und Displaymeldungen können angezeigt werden

 

Der MMC wird je nach Betriebssystem installiert:

           

·           Bei WINNT muß die MMC extra installiert werden.

·           Bei WIN2000 wird das MMC bei der Standartinstallation mitinstalliert.

 

Das Snap-in wird in beiden fällen bei der R/3 Installation mitinstalliert

StartupLogs

 

Alle Logdateien und Fehlermeldungen befinden sich in folgenden Ordnern:

 

            \\<saplocalhost>\saploc\<sid>\Instance\<no>\work

 

Während des Startens des R/3-Systems schreibt der Sapstartsrv.exe folgende Logs in getrennte Dateinen:

·           Datenbankmeldungen                            à       STDERR1

·           Messageservermeldungen       à      STDERR2

·           Dispatchermeldungen                          à       STDERR3

 

Im Instanzenprofil kann man den Profilparameter “rdisp/TRACE“ setzen:

           

            Bei

·           0               werden nur Fehler erfasst

·           1               werden Fehlermeldungen und Warnungen erfasst

·           2               werden Fehlermeldungen und kurze erklärungen erfasst

·           3               werden Fehlermeldungen und umfangreiche erklärungen

                       erfasst

 

Man kann also den Beobachtungsmodus genauso ändern wie man ihn braucht (Transaktionscode SM50). Um alle Start-Logdateien zu sehen klickt man im MMC auf alle alltask à view Developers Traces. Um die Start up Tracefiles zusehen wählt man die passenden Filetypen.

 

Startup Fehlerdiagnose

 

Möglichkeiten des Nichtstartens der Datenbank

           

·           Das MMC Snap-In bekommt keine Verbindung, oder ist nicht richtig konfiguriert.

·           Der R/3 Dienst startet nicht, da er entweder nicht oder falsch konfiguriert ist

·           Der Mißlunge start einer Datenbank kann auch daran liegen, dass Variablen des Startscriptes nicht gesetzt sind, oder das das Filesystem Fehler aufweist oder die Datenbank wurde umbenannt ohne das es dem Betriebssystem bekannt ist.

·           Fehlende Freugabe im NT-Filesystem

·           Falscher Benutzer ist angemeldet oder die rechte des Benutzers stimmen nicht mit den erforderlichen überein.

·           Fehler in der TCP/IP Konfiguration:

·           Falsche IP-Nummern

·           DNS-Server falsch konfiguriert

·           Falsches Gateway

·           Falsche Subnetzmaske

·           R/3 kann so konfiguriert werden, das die Fehlermeldungen des Systems direkt im Ereignismanager von NT erscheinen.

·           Der Systemmonitor  (Transaktionscode RZ20) kann nach erfolgreicher anmeldung zur Fehleranalyse genutz werden.

 

Alle wichtige Systemaktionen,wie z.b. Start Stop der Datenbank, Fehler und LogIns werden im Oracle Logverzeichnis gespeichert.

 

<laufwerksname>:\oracle\<sid>\saptrace\background\<sid>alert.log

 

Detaliertere Informationen werden im Oracle Tracelogfile gespeichert:

 

<laufwerksname>:\oracle\<sid>\saptrace\usertrace\ora<sid>.trc

 

Im R/3 System wird das Programm Sapdba zum Starten,Stoppen und kontrollieren der Datenbank genutzt. Es schreibt beim Start entsprechende Performance Logfiles in folgende Verzeichnisse:

 

·           <laufwerksname>:\oracle\<sid>\sapreorg

·           <laufwerksname>:\oracle\<sid>\sapcheck

·           <laufwerksname>:\oracle\<sid>\sapbackup

 

 

Stoppen des Systems:

 

Bevor ein System gestoppt werden kann sollten folgende Kontrollen durchgeführt werden:

·           Transaktionscode sm35/sm37

 

·           Sind Hintergrundprozesse aktiv oder geplant

·           Hat das R/3-System noch Jobs von anderen Systemen

 

·           Transaktionscode sm66

 

·           Test ob an den Applicationsservern noch Hintergrundprozesse laufen

 

·           Transaktionscode sm35

 

·                 Test ob noch Batch Inputjobs laufen

 

           

·           Transaktionscode  sm13/sm20

 

·           Kontrolle ob gerade ein Update eingespielt wird. Wenn das System während des Einspielens von Updates heruntergefahren wird, wird der gesamte Updateprozess gelöscht, und man fängt beim nächsten mal wieder am anfang an.

 

Wenn einer der o.g. Jobs noch aktiv ist, kann der Administrator ihn beenden, oder warten bis er fertig ist. Es ist immer sinnvoll Systemweit die User zu informieren bevor ein System herruntergefahren wird, das kann durch den Transaktionscode  sm02 passieren.Vor dem endgültigen Herrunterfahren kontrolliert man mit Transaktionscode sm04 welcher User noch angemeldet ist und meldet ihn nach bedarf selber ab.

 

 

Stoppen des Systems

 

Der Applications- , der  Dialogserver und die zentrallen Instanzen müssen zuerst gestoppt werden. Zum Stoppen hat man zwei Möglichkeiten

 

·           Im CCMS des R/3 System

·           Im Snap-In des R/3 auf der MMC. Das MMC sendet dann die Stopmeldung an das System, welches dann mit dem Stoppen der lokalen Instanzen beginnt.

 

·           Der Sap-Dienst wird gestoppt (sapstop)

·           Die Datenbank wird gestoppt

·           Sapdba stoppt über den Oracle-Enterprisemanager die Datenbank

·           Befehl

·           sapdba –shutdown oder

·           oradini80 -shutdown

 

Fehlerbeheben beim Herrunterfahren

 

Mögliche Ursachen warum die Datenbank nicht herrunterfaährt obwohl das R/3-System gestoppt ist:

 

·           Die datenbank spielt die letzte Transaktion zurück die durch dem Herrunterfahren des Systems abgebrochen wurde. Es dauert eine Zeit bis die Datenbank fertig ist.

·           Ein Online-Backup läuft noch, dadurch kann die Datenbank erst herruntergefahren werden wenn es beendet ist.

·           Der Archiver ist voll. Der Inhalt des Archivers sollte zuerst auf ein Band, oder einem Filesystem gesichert werden.

 

Remote Funktionen

 

Alle o.g. Funktionen können  auch Remote über Fernwartungstools wie z.b. PC-Anywhereerledigt werden. Genauso ist es möglich den Rechner über Telnet oderr ssh zu bedienen.

 

System Administrator Assitent SSAA

 

           

Hauptaufgaben des Administrators

           

·           Überwachung der Log-Files

·           Kontrolle der laufenden Backups

·           Ständige Systemkontrolle

·           User Anfragen bearbeiten

 

 

 

 

 

 

Das SSAA gliedert sich in 4 Bereiche

 

1.                  Arbeitsplan

 

·           Anzeige der täglichen Aufgaben

 

2.                  Eröffnungsbildschirm

 

·           Anzeige aller laufenden Task

·           Suche nach bestimmten Task

 

3.                  Auswahlbildschirm

 

·           Displayanzeige nach Funktions- oder Periodischer Ausführung

·           Anzeige aller Task nach Kunden sortiert

 

4.                  Alarmbildschirm

 

·           Anzeige kritischer Anwendungen nach Ausführung der der Task

·           Anzeige aller Anwendungen mit definierten Warnständen

 

Troubleshooting

           

Für Systemproblem hat jedes Systemeine Beschreibungs- und Problemlösungsdatei. Zu finden ist diese unter : System à Troubleshooting à Service und Support à Troubleshooting.

 

 

CCMS            Computermanagment System

Das CCMS ist bestandteil der Sap-Basis. Das CCMS dient zum Überwachen, Steuern, und konfigurieren des Systems. Es stellt folgende Funktionen zur Verfügung:

 

·           Profilpflege

·           Bedienfreie 24h-System-Verwaltung

·           Starten und Stoppen der Instanzen

·           Verarbeitung und Steuerung von Hitntergrundjobs

·           Einplannung von Datenbanksicherungen

·           Automatische Meldungen von Systemalaramen

·           Dynamische Benutzerverwaltung

·           System- und Netzwerküberwachung und Analyse.

·           Das CCMS stellt eine Reihe von Grafischen Monitoren und Verwaltungsfunktionen zur Verfügung.

 

Einrichten des CCMS:

 

·           Pflege der R/3-Profile Die Profile aller aktiven Server einer Datanbank werden exportiert.

·           Mind. 1 Betriebsart wird definiert

·           Für die Instanzen die während der Installation erstellt wurden werden Instanzdefinitionen erzeugt.

·           Falls Erforderlich ordnet man den Instanzdefinitionen Betriebsarten zu und passt sie der verteilung der Workprozesse an.

·           Es werden Zeittabellen für den normal und den 24-Stundenbetrieb definiert.

·           Wenn Betriebsarten nicht richtig definiert sind, zeigt das CCMS keine relevanten Daten an.

 

Mit dem Transaktionscode rz20 kann man sichVerwaltungsdaten der einzelnen Profile anzeigen lassen. Zur bearbeitung von Profilen gibt es 2 Modis:

           

·           Grundpflege

·           Hier werden Parametersätze bearbeite die immer wieder geändert werden müssen. Die Technischen Parameternamen müssen nichtbekannt sein. Parameter werden gemäß Abhängigkeiten automatisch angepaßt.

·              Erweiterte Profilpflege

·             Hier arbeitet man mit einem Editor, alle technischenNamen der Parameter sowie ihre abhängigkeiten müssen bekannt sein.

 

Zusätzlich kann man eine oder alle Personen eines Profils löschen, Profile vergleichen,  Profile verschieden und verschiedene Profilprüfungen durchführen.

 

 

Während der R/3 Installation erzeugt das R/3-Installationsprogramm ( R/3-Setup) automatisch, in Abhängigkeit der Ressourcen (z.b. Ram), die Profilparameter, sowie das Startprofil als auch das Instanzenprofil.

Sobald Profile von verschiedenen Applicationsservern in einem Bild gepflegt werden sollen, müssen ihre Profile in der Datenbank gespeichert sein. Nach der Installation sind sie jedoch nur auf Betriebssystemebene abgelegt. Über Hilfsmittel à importiere Profile à der aktiven Server, werden sieTransportiert. Alle 3 Profiltypen (Instance -, Startup- und Defaultprofile) werden nach einer Prüfung der Parameter importiert. Die Profile werden automatisch in der R/3 Datenbank gesichert. Aktiviert werden sie, indem sie auf Betriebssystemebene zurück geschrieben werden. Einzelne Profile können nur manuell kopiert, geprüft und aktiviert werden. Verschiedene Profile können in der Datenbank unter dem selben Namen gespeichert und gepflegt werden, solange man den jeweiligen Daten verschiedene Versionsnummern zuordnet. Sobald ein geändertes Profil gesichert wird, wird eine neue Version in der Datenbank erzeugt. Dadurch enthält die Datenbank Informationen aus allen bisher erstellten Profildateien inkl. Änderungen. Der Applicationsserver wird immer mit den Profildateien des Betriebssystems gestartet.

Aus R/3-Sicht besteht ein Profil aus zwei logischen Komponenten: Einträgen in Datenbanktabellen und einer Betriebssystemdatei, die im globalen Profilverzeichnis liegt. Wenn Sie ein Profil aktivieren möchten, müssen Sie es auf die Betriebssystemebene schreiben und das R/3-System neu starten. Wenn andere Profildateien mit demselben Namen existieren, müssen Sie bei Aktivierung der Profile in der Datenbank bestätigen, daß die vorhandenen Dateien überschrieben werden sollen. Zusätzlich wird eine Sicherungsdatei erstellt. Bei Aktivierung des Profils wird ein Header mit dem Profilnamen, dem Namen des Änderers, dem Änderungsdatum und der Änderungszeit in der Betriebssystemdatei eingefügt. Es kann immer nur die letzte Version des Profils aktiviert werden.

 

Profile sollten in der Regel nicht geändert werden, bzw Änderungen sollten nur in Abstimmung mit der Sap oder deren Partnern durchgeführt werden. Ändern der Standarteinstellung kann erforderlich sein:

           

·           Zum Starten oder löschen von zusätzlichen Sap-Prozessen z.b. Messageserver

·           Änderungen der globalen Parameter, z.b Änderung der Datenbank auf einem anderen Server

·           Änderung lokaler Systemparameter für eine R/3 Instanz z.B. Anzahl der im Hintergrund laufender Workprozesse

 

Profiländerungen werden automatisch geprüft, bevor die Grundpflege oder die Erweiterte Pflege verlassen wird. Fehler oder Inkonsistenzen werden angezeigt. Parameteränderungen werden Dokumentiert. Änderungen werden nicht sofort wirksam, sondern sie werden erst nach einem Neustart wirksam.  Änderungen der Speicherverwaltungsparameter des Instanzen Profils sind dynamisch und werden deshalb ohne Neustart übernommen.

Man kann für Profile umfassende Prüfungen durchführen. Dazu gehören:

           

·           Syntaxprüfungen

·           Prüfung der Schreibweise bei Parameternamen

·           Sematische Prüfungen

 

Beim Prüfen der einzelnen Profile werden  Parameter in Klassen unterteilt. Für jede Klasse gibt es eine eigene Prüfvorschrift. Wenn alle Profile überprüft werden, kann zusätzlich getestet werden ob die Profile untereinander konsistent sind. So können zum Beispile alle Profile darauf geprüft werden, ob genau ein Messageserver gestartet wird, oder alle Instanzenprofile können darauf geprüft werdenob ein Enqueue Workprozess konfiguriert wurde. Mna kann entweder alle Profile der aktiven Server prüfen oder alle in der Betriebsartverwendeten Profile. Beim Start eines Applicationsservers wird automatisch geprüft ob die Datenbankprofile mit den Betriebssystemprofilen übereinstimmen, im Fall einer Datenunglichheit wird eine Alarmmeldung im Alertmonitor ausgegeben. So kann man feststellen ob Dateien im Betriebssystem manuell geändert wurden.

 

Betriebsarten

 

Konzept der Betriebsarten:

Da Tagsüber mehr Dialogprozesse und nachts mehr Hintergrundprozesse laufen gibt es 2 Möglichkeiten die R/3 Workprozesse auf die verschiedenen Phasen der Systemaktivität einzustellen:

                       

·           Instanzenprofile pflegen und neu starten

·           Betriebsarten definieren und zwischen Ihnen hin- und herschalten.

 

Die Verwendung von Betriebsarten optimiert den Einsatz der Systemressourcen während der verschiedenen Phasen. Durch Betriebsartumschaltung findet eine dynamische Neukonfiguration des Systems statt, d.h.das Instanzenprofil des Servers wird nicht geändert, wodurch keine Ausfallzeiten des Systems entstehen.

Eine Betriebsart konfiguriert den Einsatz der Ressourcen für alle Instanzen im R/3-System anhand zweier Faktoren:

1.      Benötigte Dienste oder Workprozesse

2.      Gewählte Zeitinterwalle

 


Auswahl einer Betriebsart

 

Dialogverarbeitung wird eingesetzt für :

 

·           Interaktive Verarbeitung

·           Buchen von Belegen

·           Anlegen von Kundenaufträgen

·           Senden von Begrenzten Datenvolumen das in der Datenbank angelegt und aktualisiert werden soll

·           Benutzeraktivitäten mit eingeschränkten Transaktionsschritten

·           Zeitkritische Verarbeitungsabläufe

 

Hintergrundverarbeitungsbeispiele:

           

·           Hintergrundabläufe wie Saldenliste und Zahlungslauf

·           Listverarbeitung

·           Periodische Arbeiten

·           Einfügen und Aktualisieren von grossen Datenvolumen

 

Systemadministrations Assistent (Transaktionscode rz04)

 

 

Betriebsarten definieren:

 

Um das CCMS einzurichten, muß mind. Eine Betriebsart definiert werden (rz04).Sollte noch keine Betriebsart definiert sein, so wird automatisch die Betriebsart Dummy angezeigt. Diese wird automatisch konfiguriert, damit Systemfunktionen wie das Controll Panel und die Einplannung von Hintergrundjobs zur Überwachung genutz werden können. Die Betriebsart Dummy kann weder in der Betriebsartumschaltung genutz werden, noch kann sie einer Zeittabelle zugeordnet sein. Betriebsarten können zwischen Test- und Produktivbetriebsarten unterschieden werden., jedoch können nur Produktive Betriebsarten in der Zeittabelle zugeordnet werden. Für jede zugewiesene Betriebsart kann die zugehörige Workprozeß-verteilung dem Instanzenprofil angepasst werden. Es kann nur die zusammen-setzung der Dialog- und Workprozesse geändert werden, nicht jedoch die Gesamtzahl der Prozesse da diese im Instanzenprofil definiert ist. Die Mindestanzahl der der Workprozesse für die Dialogverarbeitung ist immer 2.         

 

Betriebsartenumschaltung

 

Bei der Betriebsartenumschaltung werden nur Workprozesse automatisch neu aufgeteilt.  Prozesse die während der Betriebsartenumschaltung noch Jobs ausführenwerden erst nach beendigung des laufenden Jobs umgeschaltet. Betriebsartenumschaltungen werden im Systemprotokoll aufgezeichnet inkl der alten und neuen Prozeßtypen.

Die automatische Betriebsartenumstellung wird von Zeittabellen gesteuert. Zeittabellen müssen auch für das CCMS Monitoring gepflegt werden. Um die Zeittabelle zu ändern nutz man den Transaktionscode sm63.

Zeittabellen ermöglichen die einplannung von Jobs innerhalb von 15 min intervallen.

Man kann Normal- und Ausnahmebetrieb definieren. Beim Normalbetrieb sollte darauf geachtet werden, das man immer genau einen 24-Zyklus einplannt, da es sonst zu Problemen kommen kann. Im Ausnahmebetrieb werden die für diese Betriebsart definierten Zeitintervalle für einen bestimmten Zeitraum aktiviert, diese besitzen dann auch eine höhere Prioritätals die Zeittabellen für den Normalbetrieb.

Sollte keine Zeitabelle für den Normalbetrieb definiert sein, bleibt die Startkonfiguration gemäß Startprofil aktiv.

Betriebsarten können auch manuell umgeschaltet werden, dies geschieht im Control Panel         (rz03).  Hier können Betriebsarten für einen oder für alle Server umgeschaltet werden. Bevor man manuell umschaltet, sollte man zuerst eine Simulation der Umschaltung durchführen. Die Simulation wird durcggeführt :

Werkzeuge à CCMS à Controllmonitor à Controllpanell à Control à SwitchOpMode à Simulation.

Ein Testprotokoll gibt über eventuelle Fehler auskunft.

Beim Scheitern der Betriebsartenumschaltungliegt in der Regel eine Inkonsistenz im System vor z.B. Diskrepanzen inder der Anzahl der Workprozesse (auf Betriebssystemebene im Instanzenprofil in der Datenbank oder in der Betriebsartendefinition). Es sollte regelmäßig geprüft werden ob die Anzahl laufenden Workprozesse identisch ist mit der Anzahl der angegebenen. Sobald Profile geändert werden müssen  Betriebsarten und Instanzendefinitionen  an den aktuellen Status angepasst werden.

 

sm21 Betriebsarten und Workprozessumschaltung im SystemProtokoll überprüfen

sm 50 Workprozessumschaltung innerhalb Prozeßübersicht überprüfen.

 

Oracle-Datenbank

Sobald eine Oracle-Datenbank gestartet wird, werden 2 Prozesse erzeugt. Ein Bereitschaftsprozess und ein Oracleprozess. Oracle Datenbanken nutzen den WINNT Prozessmanager. Die Oracle-Prozesse warten verteilt im Hintergrund.

Die Oracle-Datenbank speichert Daten in 8 kb grossen Blöcken auf der Festplatte. Zum beschleunigen der Lese- und Schreibzugriffe werden diese Datenbankblöcke im Puffer der Datenbank zwischengespeichert. Änderungen der Datenbank werden in Online Redo Log Files gespeichert. Um eine Datenbank ohneBetriebssystemittel wieder herzustellen, genügt es alle Controllfiles und die Online Redo Log Files wiederherzustellen. Das Datenbanksystem wird dadurch gespiegelt. Das Oraclemanagmentsystem nutz die ausführbaren  SQL-Befehle zum externen zugriff auf die Datenbank, wenn diese Freigegebene Verzeichnisse besitz.

 

Standart R/3 Workprozesse:

 

·           Herstellung von Datenbankverbindungen als SapR/3 User

·           Kommunikation mit verschiedenen Datenbankprozessen

·           Wiederherstellung von Datenbankverbindungen bei Kommunikationsfehlern

·           Verarbeitung von verschiedenen Datenbankusern

 

 

Stoppen und Starten der Oracle-Datenbank

 

            Ein Datenbankstart gliedert sich in 3 Teilen.

 

·           No Mount Phase

 

Die Datenbank baut sich auf. Betriebssystemressourcen werden gemäß Profil der Datei profil<sid>.ora genutzt.

 

·           Mount Phase

 

Die Kontrollfiles der Datenbank werden ausgeführt. Das System liest die Informationen über die Struktur der Datenbank. Daten und Logfiles sind noch geschlossen.

 

·           Openphase

 

Alle Dateien der Datenbank sind geöffnet. Sollte sich die Datenbank in einem Inkonsitenten zustand befinden wird ein Wiederanlauf durchgeführt, damit werden dann Online Redo Log Files genutzt um die Datenbank wieder in einem Konsitenten zustand zu führen.

 

 

Es gibt 3 Kommandos eine Datenbank runterzufahren:

 

·           Shutdown normal

·           Kein neues Einloggen ist mehr möglich. Nachdem alle User ausgelockt sind, schließt die Datenbank Systematisch:

·           Alle Files werden geschlossen

·           Die Datenbank wird Dismounted

·           Instanzen fahren runter

·           Die Datenbank ist nach Abschaltung nicht mehr erreichbar.

 

·           Shutdown immediate

 

·           Nur die aktuellen Kommandos werden ausgeführt. Der PMON-Prozesse beendet alle Sitzungen und führt offenen Transaktionen zurück. Dann fährt die Datenbank Systematisch wie oben beschrieben herrunter. Die Nachbearbeitung der Prozesse PBWR und ARCH kann bis zu einer Stunde dauern.

 

·           Shutdown abort

 

·           Notfallabschaltung. User werden nicht abgemeldet und Transaktionen werden werde zurück noch zuende geführt. Die Datenbank ist nach dem herrunterfahren nicht konsitent. Beim nächsten Start der Datenbank startet automatisch der Fallwiederanlauf der die Datenbank in einem Konsitenten Zustand überführt.

 

Schreiben von Daten und Logfiles:

           

Ein Oracle-Datenksystem hat drei Prozesse um Informationen in eine Datenbank zu schreiben:

                       

·           Der Datenbankwriter (DBWR) schreibt während eines Prüfpunktes die geänderten Daten asynchron in die Datenbank

·           Zum schnellen Schreiben von Prüfpunkten startet der Prüfpunktprozess (CKPT)

·           Der Logwriter (LGWR) schreibt die geänderten Log´s der globalen Freigabe zum aktuellen aktiven online Redo Log File.

 

In einem Produktivensystem muss die Datenbank im Archivelog laufen, und es muss Sichergestellt sein, das der Archivprozess (ARCH) gestartet ist. (init<sid>.ora : log_archiv_strat =True). Arch archiviert complete online Redo log Files in Offline Redo Log Files ins Archivverzeichnis und benennt sie von Log_archiv_dest in Log_Archiv_Format um- Wenn ein Offline Logfile erfolgreich geschrieben ist wird der entsprechende Online Logfile mit  neuen Informationen überschrieben. Dadurch exitieren immer 2 Online Logfiles, eins was gerade geschrieben wird und eins was auf dem Überschreiben wartet.

Wenn auf der Festplatte kein Platz mehr für das Archiv zur Verfügung steht, oder eine Datei mit dem selben Namen schon existiert wird das aktuelle File nicht gesichert.

 

Datenbankkonzepte

 

Eine Datenbank läßt sich in logischen Einheiten, sogenannte Tablesspace zerteilen. Diese lassen sich widerrum in Segmenten (Tabellen und Indizies) zerlegen. Segmente werden in kleinen aufeinanderfolgenden Datenblöcken zerteilt.Jeder Datenbaustein bistz in der Regel 8 kb und ist die kleinste Einheit des In- und Outputs einer Datenbank. Ein Datenblock ein er Oracl-Datenbank besteht aus einer oder mehreren Physikalischen Dateien. Ein Datenfile kann immer nur zu einer Tabelle gehören. Um Tabellen zu erweitern gibt es 2 möglichkeiten:

           

·           Durch Hinzufügen einer Datei wird der Existierende Tabellenplatz erhöht.

·           Man kann auch die größe des Datenfiles erweitern

 

Die Speicherparameter wie zum Beispiel Initial, Next und Maxextents erlauben den Speicherplatz einer Tabelle zu vergrößern.

Die R/3 Namenskonvention einer Tabelle ist wie folgt definiert:

            Psap<Tabellenname><.Erweiterung>

 

Die abkürzung im Tabellennamen ist immer teil des Verzeichnisnamens und vom Dateinamen des Datenfiles. Verzeichnisse und Datenfiles sind nummeriert. Die Ibjekte in der Tabelle mit dem Namen System,Psaproll und psaptemp gehören immer den Datenbankbenutzern Sys oder System. In dieser Tabelle dürfen andere User keine Objekte anlegen oder verändern.

Die Objekte in den anderen Tabellen gehören den Sap-Datenbankuser Sap/3. R/3 Systemuser haben keine Datenbankuser. Das R/3 System und Saptools benötigen die Namenskonventionen. Das Zusammengefasste System ist eine Logische Einheit, welche nicht geändert werden sollte. Auf diese Art kann Sap einen schnellen und effizienten Support gewährleisten.

 

Oracle-Verzeichnis-Strukturen

 

Verzeichnis und Dateinamen sind in der R/3 Umgebung Standartisiert. Es wird empfohlen sich an folgende Standarts zu halten:

 

·           Tabellen sollten sich im Sap-data<n> Verzeichnis befinden

·           Die Online Redo-Files Sollten sich im Orilog und Mirror-Verzeichnis befinden

·           Die Offline Redo Log Files sollten ins Saparch Verzeichnis kopiert werden.

·           Das Profil init<sid>.ora definiert die Instanzen und sollte sich im Verzeichnis Database befinden

·           Das Profil init<sid>.sap konfiguretr die Backuptools BRBackup und BRArchive und ist im Verzeichnis Database

·           Das Profil init <sid>.dba configuriert das Sadba tool und befindet sich ebenfalls im Verzeichnis Database.

·           Die Oracle-Alarmfiles befinden sich im Verzeichnis Saptrace/Background

·           Dateien der Hintergrundprozesse befinden sich im Verzeichnis Saptrace/usertrace.

·           Während der Reorganisation werden exportsätze ins Verzeichnis Sapreorg geschrieben

·           Die Verzeichnise Saparch, Sapcheck, Sapreorg und Sapbackup werden von den Sap Datenbanktoolls genutz.

 

Datenbank-Administrations-Kalender

 

Tägliche Aufgaben des Datenbankadministrators

           

·           Sichern der vollständigen Datenbank

·           Sichern der Offline Redo-Files

·           Erfolgskontrolle der Backups

 

Bedeutung von Datenbankbackups

 

·           Externe Faktoren wie z.b. Physische oder logische Fehler können zum totalen Datenverlust, bis hin zum Systemausfall führen.

·           Eine Effiziente Backup-Strategie und Sicherheitsplannung minimiert das Risiko eines Systemausfalls und des Datenverlustes.

·           Um eine permanete Verfügbarkeit des Systems zu gewährleisten muß eine Backupstrategie sorgfältig geprüft werden.

 

Datenbank-  und Offline Redo Log File Backup

 

Jedes Datenbank ManagmentSystem speichert Daten in verwertbaren Strukturen auf der Festplatte und schreibt Datanbank veränderungenim Datenbank Logfile. Bei der Oracle-RDBMS (Relation Database Managment System):

 

·           Die Dateien werden in Datenfiles der Tabellen gespeichert.

·           Log-Informationen werden bei jeder aktuellen aktion in die Online Redo Log Files geschrieben

·           Administrationsdaten werden in Prameter- und Cotrolldateien gespeichert.

·           Die Datenfiles, das Online Redo-Log-File, die Profile und  eine Contolldatei werden während des Backups gesichert.

·           Sobald ein aktuelles Online-Redo-File voll ist, beginnt Oracle sofort mit dem schreiben eines neuen Files. Das komplette File wird dann in dem Archivverzeichnis verschoben und gesichert.

·           Im Falle von Datenverlust soll die Datenbank möglichst nahe dem Zeitpunkt des Datenverlustes wiederhergestellt werden. Zur Gewährleistung das es auch funktioniert, braucht man ein  aktuellesBAckup und die Offline Redo Files seitdem letzten Backup.

·           Die Logdateien besitzen alle Informationen welche Änderungen an eine Datenbank vorgenommen wurden. In der Regel holt man sich mit den Log-Files alle Informationen seitdem letzten Backup zurück.

 

Fehlervorbeugung

 

·           Eine Backup-strategie sollte das überprüfen beider Sicherungen ( Datensicherung –Datenbanksicherungen ermöglichen)

·           Ein logischer Datenbakcheck überprüft die Konsistenz der Oracle-datenbank:

·           Defekte Datenblöcke ( Fehler ORA-1578) können in der R/3 Datenbank als Ergebnis von Beriebssystem- oder Hardwarefehler auftauchen.

·           Defekte Datenbankblöcke machen eine Sicherung unmöglich.

·           Das erkennen von defekten Blöcken wird erst durch den Leseversuch bemerkt, da ein Zugriffversuch auf defekte Tabellenteile teilweise nur sehr selten bzw. auch nicht erfolgt.

·           Regelmäßig sollte ein logischer Check der Festplatte stattfinden. Für eine optimale Performance sollte bei geringer Systemaktivität ein kompletter Systemtest durchgeführt werden. ( Sap-Hinweis 23345)

 

Bei einem Physischen datencheck ist es sinnvoll die Bänder nach erfolgtem Backup zu überprüfen. Zum Prüfen der physischen korrektheit der Bänder sollten diese nach erfolgtem Backup testweise eingelesen werden.

 

 

Offline Backup

 

Bei einem Offline-Backup ist die Datenbank herruntergefahren und ist während des Backups nicht erreichbar. Die Workprozesse erhalten eine Re-Connect Meldung von der Datenbank. Die Anzahl der Verbindungsversuche, sowie deren und Zeitintervalle lassen sich in der Datei init<sid>.sap einstellen:

                       

·           rsdb/reco_trials  = n                  //  n = Anzahl der Versuche der

Workprozesse einen Connect zur Datenbank zuerhalten.

·           rsdb/reco_sleeptime =n            //  n = Wartezeit der Workprozesse                                                             

zwischen den Verbindungsversuchen.

 

Obwohl das R/3-System während der Datensicherung online ist, ist es für die User nicht erreichbar. Da die Oracle-Dateien während des Offline-Backups sich nicht ändern ist die Datenbank nach dem Backup vollkommen konsistent. Die folgenden Dateien werden bei einem Offline Backup gesichert:

 

·           Die Datenfiles und alle Tabellen die zur datenbank gehören

·           Die Online Redo Files

·           Das Controll File

·           Die Profile :

·           init<sid>.ora

·           init<sid>.sap

·           init<sid>.dba

 

Nach beendigung des Offline Backups müssen noch die Offine Redo Files gesichert werden.

 

Online Backups

 

Während eines Online Backups bleibt das System erreichbar, die Systemleistung wird lediglich ein wenig ruduziert. Die folgenden Dateien werden während eines Online-Backups gesichert:

·           Die Dateien aller aller Tabellen der Datenbank

·           Die Controlldatei

·           Die Profiles:

·           init<sid>.ora

·           init<sid>.sap

·           init<sid>.dba

Da während des Onlinebackups auch Dateien in die Datenbank geschrieben werden, ist ein Online Backup nicht konsitent. Ein Online Backup ist nur Nutzbar in Verbindung mit den Log-Informationen die während der Sicherung gespeichert wurden. Nach einem Online Backupwechselt das Online Redo Log-File und kopiert das Vorherige ins Archivverzeichnis. Die Gesamten Informationen die während des Online Backups erstellt wurden befinden sich in den Offline Redo Log Files. Nach der Online Sicherung müssen deshalb die Offline Redo Log Files gesichert werden. Bei der Durchführung von Online Backups müssen die Online Redo-Log-Files nicht gesichert werden.

 

Offline Redo Log File Backup

 

·           Offline Redo Log Files sind kopien der Online Redo Log Files welche alle Datenbank bewegungen enthalten. Online Redo Log Files werden regelmäßig überschrieben

·           Log Informationen werden permanet in das Log File geschrieben, sobald an der Datenbank änderungen vorgenommen werden. Der Speicherplatz im Archivverzeichnis muß immer groß genug sein, da konstant neue Logfiles in das Verzeichnis hinneingeschrieben werden. Sobald das Archivfile nicht mehr im Stande ist ins Verzeichnis zu schreiben, gibt die Oracle- Datenbank den Fehlercode 257 ( Archiver sitz fest) oder den Fehlercode 255 ( Fehler im Archiver Log). Die Fehlermeldung erscheint im Oracle-Trace-File.

·           Sollten im Falle einer Rücksicherung Offline Redo Log Files fehlen ist in der Regel ein Datenverlust die Folge. Bevor Offline Redo Log Files aus dem Archiv gelöscht werden müssen sie gesichert werden. Aus Sicherheitsgründen sollten immer 2 Kopien der Offline Redo Log Files auf seperaten Bändern gesichert werden.

·           Ein Online Backup ist ohne Logfiles unbrauchbar!

 

Empfohlender Backup Zyklus

 

Es wird ein 4-wöchiger Backupzyklus empfohlen, wofür dann entsprechende Bänder für die Datenbank und die Offline Redo Log Files benötigt werden.. Es sollten immer ca. 30% mehr Bänder als benötigt vorhanden sein. Am ende des Backupzykluses ( 28 tage) können die Bänder wieder verwendet werden. Zusätlich sollte pro Zyklus ein Offline Backup gemacht werden. Die Sicherrung der Offline Redo Log Files muß werktäglich nach jedem Online-Backup durchgeführt werden, dabei sollte Sichergestellt sein, das die Offline Redo Log Files zweimal auf seperaten Bändern gesichert werden bevor sie gelöscht werden. Zum überprüfen des Backups muß die Daten auf logischen Fehlern überprüft werden, und das Datenbank Backup muß auf physischen Fehlern untersucht werden. Einmal pro Sicherungszyklus müßen diese Prüfungen durchgeführt werden, es ist aber sinnvoll die Prüfungen wöchentlich durchzuführen.

Sobald Datenbankstrukturänderungen durchgeführt werden oder ein Systemupdate durchgeführt wird sollte ein Offline Backup durchgeführt werden, und diese Bänder sollten sicher gelagert werden.

 

Sap Backuptools

 

Datenbanksicherungen werden Sap-tool BRBackup durchgeführt. Offline Redo Files werden mit dem Sap-Tool BRArchive durchgeführt.

Es gibt 3 Wege um diese Programme aufzurufen:

                       

·           Mit dem DBA Zeitplaner (db13)

·           Mit dem Datenbankadministrationstool SapDBA

·           Direkt auf Betriebssystemebene

 

Die Sap empfiehlt folgenden Weg:

           

·           Plannung mit dem Zeitplanner

·           Zusätzlichen Backups mit SAPDBA durchführen

 

Alle Stufen des Backups werden sowohl in der Datenbank als auch im Betriebssystem protokolliert.

 

Durchführungsfragen:

 

Um die Beste Backupstrategie für sein Unternehmen zu bestimmen muß man folgendes beachten:

 

·           Benötigte Betriebsbereitschaft

·           Benötigte Sicherheit

·           Benötigte und vorhandene Hardware

·           Verfügbarkeit des Systems

 

Zur Einführung einer Backupstrategie gehören:

           

·           Festlegung von Bändern und deren Lagerorten

·           Zeitplannung des Backups

·           Festlegegung der verantwortlichen Personen und deren vertreter

·           Vergeben von R/3 und Systemrechten

·           Einarbeitung aller Personen die mit dem Backup zu tuen haben.

·           Erstellung eines Notfallplanes

·           Festlegung der Kantaktperso für den Notfall

 

Zusätzlich zur Plannung einer Backupstrategie sollte eine beschreibung erstellt werden, in welcher aller Stufen der Backup-prozedur erklärt werden. Es muß sichergestellt sein, das die Beschreibungen immer den Verantwortlichen vorliegen.

 

Backupprofilparameter zur Bandinitialisierung

 

Bevor ein Backup gestartet werden kann, muß das Band initialisiert werden. Das heißt:

·           Die Backup-profil-parameter müssen gesetzt sein.

·           Das Band sollte Etikettiert sein.

 

Das Profil init<sid>.sap setzt die folgenden Parameter:

           

 

Tape_use_count

Definiert wie oft ein Band genutz werden kann.

Expir_period

Definiert die länge des Backupzykluses. Um das Band alle 28 Tage zu nutzen setz man den Wert auf 28.

Backup_dev 

·           Definiert den Backup-typ

 

·           tape                      lokaler Type

 

·           pipe                      remote

 

·           tape_auto            autoloader

 

·           util_file      Backupinterface

 

·           Disk

Volumen_backup    

Definiert welches Band zu welcher Datenbank gehört.

Volumen_archiv

Definiert das Band für die Offline Redo Files

 

Initialisierung der Backupbänder

           

Zur Initialisierung der Backupbänder geht man wie folgt vor:

           

·           Die Werte des Volumen_backups und des Volumen_archives werden gesetzt, z.b.

·           Volumen_archiv             = (<sid>A01, <sid>A02, <sid>A03)

·           Volumen_backup           = (<sid>B01, <sid>B02, <sid>B03)

·           Zum Initialisieren der Bänder nutz man SAPDBA oder BRBackup und BRArchive mit der Option –i force ( i= initialisierung, force = ohne auswertung des Bandlabels). In diesem Beispiel sind die Labels <sid>A01, <sid>b01, <sid>A02, <sid>b02, <sid>A03, <sid>B03.

 

Während der Initislisierung wird das Label .tape.hdr() in das erste File jeden Bandes geschrieben. Das Label wird immer gelesen und übersprüft von BRBarchiv un BRBackup. BRArchivund BRBackup speichern die Tapenutzung im Tapelabel, in den Backuplogs und in der Datenbank. Um Defaultwertde zu überschreiben, ruft man  BRBackup und BRArchiv mit der option –v (Volumen) auf. In aghängigkeit der Backupstrategie sollten genügend Bänder initialisiert werden. Die Anzahl der benötigten Bänder liegt an der Größe der Daten in der Datenbank, die Bandgröße und den Komprimierungsfaktoren, sowie der Anzahl der generierten Log-Informationen. 30 % freier Speicherplatz sollte auf jedem Band zur Verfügung stehen.

 

Datenkompression

 

In der init<sid>.sap läßt sich die Datenkompression einstellen. Wenn das Bandlaufwerk Hardwarekompression unterstützen,  sollte der Parameter Compress auf Hardware gesetz werden. Der Parameter kann auch auf yes für Softwarekompression gesetzt werden oder auf No für keine Kompression. Der Kompressionsfaktor bestimmt den Platzbedarf der Backupdateien. Mit Sapdb läßt sich die Kompressionsrate festlegen. Der Kompressionsfaktor hängt von der Anzahl der Daten ab und sollte regelmäßig überprüft werden.

 

Parameter für das Datenbankbackup ( init<sid>.sap):

           

·           Backup_mode                // Art des Backups all für komplett

·           Backup_type                  // online oder offline Backup

·           Tape_size                       // definiert die Größe welche von BRBackup genutz    

wird.

Sollte mehr als ein Band benötigt werden, fordert BRBackup die Bänder nacheinander an, wie die Parameter im Volumenbackup definiert sind.

Es muß noch ein Parameter für Zurückspulen der Bänder eingegeben werden:

           

            Bei Laufwerken mit Bandrücklauf :           tape_adress

            Bei Laufwerken ohne Bandrücklauf           :           tape_adress_rew

 

Profileinstellungen für Offline Redo Log Files:

           

In der Profildatei init<sid>.sap sind für das Programm BRArchiv folgende Parameter einzutragen:

           

·           archiv_function =                                    copy_delete_save

 

·           erzeugt ein zweites Backup

·           löscht die offline redo files die schon zweimal gesichert sind

·           speichert alle neuen Offline Redo Files

 

·           tape_size_arch =

           

·           Definiert die Bandgrösse, 6000M für 6GB

 

·           Tape_adress_arch und Tape_adress_rew_arch erklärt ob ein Bandlaufwerk zurückspulen kann oder nicht. Sollte nichts eingetragen sein werden die einstellungen von Tape_adress und Tape_adress_rew übernommen.

 

Operationsmonitor (db24)

 

            Der Operationsmonitor zeigt:

           

·           Alle Backupvorgänge

·           Den Status des Datenbank- und Offline Redo File Backups

·           Die Logfiles von BRBackup und BRArchiv

 

Zusammenfassung der Backupstrategien:

           

 

           

·           Bestimmung des Backupzykluses

·           Einschätzung des Datenbedarfs

·           Einschätzung des Platzbedarfes des Backups und der Offline Redo Log Files

·           Bestimmung des Kompressionsfaktors und wahl des Backupprogramms SAPDBA oder BRBackup

·           Einschätzung der Zahl der Bänder ( Sinnvollerweise 30 % mehr)

·           Initialisierung der Backuppläne

·           Plannung regelmäßiger Backups mit Zeitplaner ( db13)

·           Durchführung und Überwachung des Backups

·           Bereitstellung der benötigten Bänder

·           Kontrolle und Überprüfung eines erfolgreichen Backups

·           Test des Backups

·           Kontrolle der Kompressionsrate

·           Überprüfung der Datenbank auf logischen Fehlern

·           Sichere Lagerung der Bänder.

 

 

 

Systemleistungskontrolle

 

Zu Überprüfen der  Performance und zum minimieren von Ausfallzeiten sollte die Oracle-Datenbank täglich kontrolliert werden. Zum Überblick über die Systemleistung sollten folgende Monitore regelmäßig überprüft werden:

           

·           Der Datenbanksystemtestmonitor (db16) zeigt einen Überblick aller Hauptfunktionen und Statusmeldungen der Datenbank

·           Der Backup-Log-Monitor (db12) zeigt Statusinformationen der Datenbank und des Offline Redo Log File Backups

·           Der Tabellen- und Indexmonitor (db02) zeuigt den Satus der Speicherverwaltung der Datenbank und der Datenbankobjekte an.

·           Der Datenbankperformancemonitor (st04) verfügt über einen zentralen Überblick von dem man auf die gesamte Datenbank zugreifen kann, inkl. Allen Log-Files, der Oracle_Datenbank Check und die Statistikanzeoge.

 

Durch die Kontrolle der o.g. Monitore kann man sichergehen das:

                       

·           sich keine veralteten Informationen im System befinden.

·           das System sich nicht zu sehr aufbläht.

·           Platzprobleme nicht aufkommen, bzw frühzeitig erkannt werden.

 

 

Oracle Cost-Base-Optimizer:

 

 

Der Oracle-Basis-System-Optimizer nutz SQL-Befehle um wirkkungsvoll Daten der Datenbank zurückzuholen oder zu ändern. Die verwendetete Strategie hängt von den Informationen in der Datenbank ab:

           

·           Abfrage Tabellen

·           Felder die mit dem Where Befehl ansprechbar sind

·           Definierte Indizies der Abfrage Tabellen.

 

Der Cost-Base-Optimizer vergleicht den Aufwand des Tabellenzugriffs und wählt die Methode mit den wenigsten Datenzugriffen. Um die Zugriffe kalkulieren zu können braucht der Cost-Base-Optimizer Statitische Informationen über die Tabellen und die Indizies der Datenbak, wie z.b.:

           

·           Zahl der Tabellen oder Indexspalten und anzahl der Blocks welche zu einem Objekt gehören

·           Anzahl der Werte in jeder Spalte einer Tabelle

 

Die Statistischen Informationen für eine Tabelle oder Index stehen im Datenverzeichnis der datenbank. Zum Sammeln der Informationen nutz man den SQL-Befehl ANALYSE TABLE. Man muß lediglich beachten, das der Befehl sehr aufwendig ist. Tabellen und Indizies können in der Grösse und der Wertaufteilung varieren.. Wenn die aktuelle sich von der seitdem letzten Analyseprozess unterscheidet, dann wird der Cost-Base-Optimizer, da er ja auf falschen Werten basiert, eine falsche Strategie wählen, wodurch sich Datenbankzugriffe noch verlangsamen können.

 

SAP´s zwei Phasen Strategie

 

Nur mit aktuellen Informationen kann der Oracle Cost-Base-Optimizer denn optimalen Datenzugriff ermöglichen. Sobald System-Statistik aktualisiereungen laufen reduziert sich die Systemleistung erheblich. Deshalb empfiehlt SAP eine zwei Phasen-Strategie:

·           In der ersten Phasefindet das SAP-Tool SAPdba herraus welche Tabellen ein Update benötigen. Der  befehl SAPDBA –checkopt PSAP% stellt fest welche Tabellen-Statistiken veraltet sind und ein Update benötigen und ändert die Controll-Tabelle DBSTATIC dementsprechend.

·           In der zweiten Phasewerden die zur aktualisierung bereitgestellten Tabellen mit dem TODO Befehl in der Controll-Tabelle vermerkt und mit dem SAP-Befehl SAPDBA-Analyse DBSTSTCO aktualisiert.

 

Die zwei Phasen Strategie gewährleistet, das in der Regel alle Tabellen-Statistiken auf einem aktuellen Stand sind und die Analyse Laufzeit sich nicht zu sehr  verlangsamt.

Ab dem SAP Release 4.6B ist der Befehl Sapbda –statistik hinzugekommen, der Befehl ermöglichtbeide Phasen in einem Rutsch abzuarbeiten. Diesem Befehl sollte man mit dem Taskplaner einmal wöchentlich während geringer Systemaktivität einplanen. Beide Phasen werden dann nacheinander abgearbeitet.

Mit dem Befehl PSAP%: all Saptablesspaces stellt man fest, welche Tabellen einen Optimizer Check benötigen.

Will man jedoch alle TODO´s in der DBSTATIC Tabelle aktualisieren wählt man den Befehl DBSTASCO. Für alle markierten Tabellen wählt man den Befehl DBSTAC.

Um Probleme mit zu grossen Datei zu umgehen, hat SAPDBA eine automatische grössen erkennung integriert. Diese Tool sollte reglmäßig ausgeführt werden, um kritische Dateigrößen zu vermeiden. Um das Programm zu starten nutz man den Befehl SAPDBA –Next PSAP%. Die ergebnise dieses Befehls werden in der Datei <DatumUhrzeit>.nxt im sapcheck Verzeichnis gespeichert, und kann im DBA Logging Monitor mit der Funktion ID.nxt kontrolliert werden.

Um bei einzelnen Objekten gespeicherte Voreinstellungen zu ändern nutz man den SAPDBA und wählt d für Reorganisation.

 

Periodischer Monitor bei Speicherplatz Problemen

 

Der Tabellen und Indexmonitor (db02) kann benutz werden um freien Tabellenplatz zu lokalisieren. Er Analysiert den Tabellenplatz um festzustellen wo sich kritische Platzprobleme anbahnen, und testet die Datenträger um festzustellen wann ein kritischer Speicherpunkt erreicht ist.

Der Datenbankmonitor (db16) zeigt ob das System genügend freien Speicherplatz zur Verfügung hat. Sollte zuwenig Speicherplatz vorhanden sein, zeigt der Befehl SAPDBA –check das Problem an.

In der Datei init<sid>.ora definiert der Parameter Name DB_Files die maximale Anzahl der erlaubten Dateien in einer Datenbank. Zusätzlich wird noch ein sogenanntes Hardlimit erstellt (maxdatafiles), welches während der Datenbank installation definiert wird.

 

SAPDBA –Check

 

Mit dem Tool SAPDBA –check kann folgendes getestet werden:

           

·           Die Tabellen und Index Fragmentation

·           Platzbedarf der Tabellen

·           Physikalische Konsitens der Datenbank anhand der :

·           Controll Files

·           Redo Log Files

·           Data Files

·           Serverfehlermeldungen in der Alarmlogs

·           Init<sid>.ora Parameter Einstellungen

·           Datenbankprobleme in der R/3 umgebung

 

Sinnvoll ist es den SAPDBA –check einmal wöchentlich per Zeitplaner einzuplanen, oder man starte das Programm regelmäßig manuell auf Betriebssystemebene. Das Programm erstellt eine Datei mit dem Namen <DatumUhrzeit>.chk ins Verzeichnis Sapcheck. Die Loginformationen können mit dem Systemcheckmonitor (db16) angezeigt werden.

 

Archiver

 

Störung des Archivers:

 

·           Das Datenbanksystem kann nichts mehr in die Online Redo Files schreiben

·           Die Datenbank erlaubt keine änderungen an Ihren Daten

·           SAPDBA erhält keine Verbindung zur Datenbank

 

Wenn der Archiver nicht mehr richtig funktioniert, sollte man zuerst die Fehlermeldungen in den Logfiles kontrollieren. Gründe für funktionsstörungen können sein:

           

·           Die Datenbank ist im Archivmode, aber der Oracle-Archiver läuft nicht. Eine entsprechende Fehlermeldung steht in den Log-Files. Mit SAPDBA wird der Archiver gestartet.

·           Wenn das Archivverzeichnis überfüllt ist, wegen zu großer Datenmengen oder Datenmanipulation. Wenn dieser Fall auftritt muß lediglich der Speicherplatz im Verzeichnis vergrößert werden.

·           Um im Archivverzeichnisfreien Speicherplatz zu erzeugen sichert man de Offline Redo Log Files mit dem SAPDBA Tool auf Band. Nach erstellung doppelter Sicherheitskopien können die Log Files gelöscht werden.

·           Sofern genügend Speicherplaz zur Verfügung steht empfiehlt es sich im Archivverzeichnis einen temporären Ordner zu erstellen und diesen bei Problemen mit dem Archiver einfach zu löschen.

 

 

Datenbank Backup

 

Der Datenbankoperationsmonitor (db24) zeigt alle wichtigen Aktionen des Backups an:

·           Alle BackupAktionen

·           Den Status des datenback- und des Offline Redo Log File Backups

·           Die von BRBackup und BRArchiv erstellten Logfiles.

 

Der  Sap Systemadministrations Assistent (SSAA)

 

Mit dem Systemadministrations Assistent lassen sich alle periodischen Datenbank Aktionen einplanen und anzeigen. Zum Verhindern von datenbankfehlern sollten die folgenden Aktionen und Kontrollen eingefügt werden:

           

·           Kontrolle über den aktuellen Zustand der Statistik

·           Aktualisierung der Statistik

·           Kontrolle der Alram Log Files

·           Kontrolle des Tabellenplatzes und anpassen der aktuellen größe

·           Kontrolle der Tabellen größe und deren Wachstum

·           Kontrolle der Offline Redo Files

 

 

 

Hintergrundjobs

 

Einplannung und Verarbeitung

 

Hintergrundjobs können mit dem Instanzenprofilparameter für jede Instance konfiguriert werden (rdisp/wp_no_btc). Pro Instance müssen mind. 2 Dialogworkprozesse definiert werden:

           

·           Der Hintergrundscheduler benötigt einen Workprozess zur Überprüfung und Einplannung von Hintergrundjobs.

·           Der Benutzer benötigt einen Workprozess zur Dialogverarbeitung.

 

Es gibt keine Mindest. Anzahl für die Anzahl der Hintergrundprozesse, es sei denn das Transportsystem ist im Einsatz, dafür werden mindestens 2 Workprozesse definiert.

Ein Hintergrungjob besteht aus einer oder meheren Stufen. Eine Stufe kann sein:

 

·          Ein Abap-Programm

·          Ein externer Befehl

·          Ein externes Programm

 

Es gibt zwei Arten Hintergrundjobs zu starten:

 

·          Nach Zeitplanung ( vordefiniertes Datum und Uhrzeit)

·          Bei auftreten eines definierten Ereignisses

 

Hintergrundjobs lassen sich in verschiedenen Prioritätsstufen unterteielen:

           

·          Class A    (hohe Priorität)

·          Class B    (mittlere Priorität)

·          Class C    (geringe Priorität)

 

Im Regelfall läuft jeder Workprozess mit Jobs aller Prioritäten, es ist aber auch möglich Workprozesse so zu konfigurieren das darauf nur Class A Hintergrundjobs laufen. Um die Anzahl der Reservierten Workprozesse zu definieren muss im Computing Center Managment System eine Betriebsart definiert werden, in welchem dann die Workprozesse deklariert werden. Bei der definition von Class A workprozessen sollte aber sichergestellt sein, das für andere Jobs noch genügend Workprozesse vorhanden sind.

 

 

 

 

 

 

Erstellen eines Jobs mit dem Job Assistenten

 

Ab Release 4.6A kann der Jobassistent genutz werden.  Er wird in der folgenden Reihenfolge ausgeführt:

 

-          zuerst wird der Jobname, und die Jobklasse bestimmt.

-          Erstellung der Jobstufe

-          Abap Programm

-          Externer Befehl oder Befehlsfolge (Batch)

-          Externes Programm

-          Eventl. Hinzufügen weiterer Stufen

-          Startpunkt (Zeit- oder Ereignisgesteuert)

 

 

Hintergrundverarbeitung

 

Solange Abap-Programme keine Selektionsbilder haben, können Sie im Hintergrund ausgeführt werden, ansonsten sind Sie nur bedingt für Hintergrundjobs einsetzbar. Das R/3-System startet ein externes Kommando in dem es über einen Remote Function Call (RFC) das Serverprogramm auf dem Zielrechner startet. Externe Programme können nur von Benutzern mit der R/3 Berechtigung Hintergrundadministrator ausgeführt werden. Externe Programme werden vom Hintergrundadministrator erstellt und werden dann von Benutzern mit den entsprechenden Rechten ausgeführt. Abap-Programme werden synchron ausgeführt während externe Programme je nach einstellung synchron oder asynchron ausgeführt werden. Alle Job-abläufe werden im Jobprotokoll aufgezeichnet.

 

Startzeitpunpt von Hintergrundjobs

 

            Uhrzeitbasiert

-          Unverzüglich

-          Bei bestimmter Uhrzeit/Datum

-          An bestimmten Tagen

Alle auf Uhrzeit bestimmten Jobs können Periodisch auch eingeplant und ausgeführt werden. Zusätzlich könne auch Ausnahmen eingeplant werden, z.b. für Feiertage. Der Parameter RDISP/BTCTIME definiert den Zeitintervall.

 

 

            Ereignisbasiert

                       

-          After Event          // Der Job wird jedesmal gestartet sobald ein bestimmtes Ereignis aufgetreten ist

-          After Job             //Der Job wird gestartet sobald ein andere Job abgearbeitet wurde.

-          Beim Weschsel der Betriebsart, zum Beispiel beim Wechsel von Tag- auf Nachtbetrieb.

 

Der Parameter RDISP/BTCNAME beschreibt den Ausführungsgrund oder –ereignis des Hintergrundjobs.

 

 

Internes Auslösen von Ereignissen.

 

Manuell löst man ein Ereibnis im Computing Center Managment System  mit folgender Befehlsfolge aus:

 

            Jobs à Raise Event aus.

 

Jetzt wird eine vollständige Liste aller im R/3 definierten Ereignisse angezeigt, hier kann dann der Name oder die Ereignis ID ausgewählt werden. Alle Jobs die auf das Ereignis END_OF_DATA_TRANSFER warten starten nach Ablauf des Ereignisses. Desweiteren können auch ereignisse mit dem R/3 Funktionsbaustein BP_EVENT_RAISE ausgelöst werden (Werkzeuge à Abap Workbench à Funktionsbuilder).

 

Jobstatus

           

Jeder hat enthält eine der folgenden Statusmeldungen:

 

-          Scheduled           Job ist erstellt, hat aber keinen Startzeitpunkt

-          Released             Job ist erstellt, und wartet auf auswahl.

-          Ready                  Job steht zur ausführung bereit.

-          Active                   Job wird in einem Hintergrundprozess ausgeführt

-          Finished              Job wurde erfolgreich ausgeführt

-          Canceled             Job wurde mit Fehlern abgebrochen

 

-          Solange ein Job auf Scheduled oder Released steht kann er noch geändert werden.

-          Wenn ein Job bereits in der Ausführung ist, kann er im Monitor Log Überwacht werden, sollte er Abap-Programme enthalten wird die Ausgabe zusätzlich in Spool-Listen gespeichert.

-          Zum erstellen von neuen Jobs kann auch ein vorhandener Job kopiert und geändert werden.

-          Ab release 4.6A bietet die Jobkontrolle (sm37) erweiterte möglichkeiten zur Kontrolle kritischer Bereiche.

 

Jeder Job kann anhand seiner Stufen kontrolliert werden:

           

-          Die Jobliste zeigt immer den ausgewählten Job im oberen Bereich des Bildschirmes an. Der Abap Listen Anzeiger nutz die Display Anzeige um verschiedene Display Varianten zu erzeugen.

-          Von dem Jobüberblick kann man in verschiedene Detailansichten wechseln:

-          Der JobLogevent erleubt die Kontrolle der durchzuführenden Jobs

-          Die Spool List enthält gegebenenfalls ausgaben der ABAp-Programme

-          Desweiteren findet man hier die Job-Definitionen inkl. Ausführungszeit und Hintergrundprozessnummer

 

 

 

 

Graphischer Jobmonitor

 

Zugriff zum graphischen Jobmonitor erhält man mit rz01 oder im Computing Center Managment System mit der Befehlsfolge Controllmonitoring à job à scheduling Monitor

Die Spalte Jobserver zeigt den jeweiligen Namen des Servers an. Doppelte Namen sind ein zeichen, das verschiedene Workprozesse für den selben Server konfiguriert worden sind. Wenn kein Servername angezeigt wird, ist keine Betriebsart für diesen Server ausgewählt. Class A jobs werde extra gekennzeichnet. Jede zeigt zeigt eine Hintergrundjob inklusiver aller einzelheiten an. Die Funktion beschreibt nicht alle Ausführungsplannungen. Zusätzliche erweiterete Funktionen werden mit dem folgenden Wegen beschrieben:

           

Das R/3 System beinhaltet interne Hilfsfunktionen um einen eigenen Job zu erstellen. Diese Funktionen sind zu finden in den Funktionsgruppen BTCH und BTC2. Mit Hilfe dieser Module können willkürlich komplexe Szenarien erstellt werden. Sap veröffentlich Schnittstellen der Integrierten Computing Center Managment System  umgebung:

-          Das Externe Überwachungsprogramm (XMI-API). Das alle eingeloggten User und laufende Programme anzeigt.

-          Die Schnittstelle der Hintergrundprozesse (XBP-API), welche die Einplanung der externen Hintergrundprozesse erlaubt.

 

Durch diese Tools ist es für jeden möglich Hintergrundprozesse und Zeitplanungen von externen Systemen erledigen zu lassen. (Genau Schnittstellen erläuterungen befinden sich im BC305).

 

Authorization

 

Das Objekt S_BTCH_JOB bestimmt die folgenden Funktionen:

           

-          DELE                        Löscht Jobs von anderen Usern.

-          LIST               zeigt alle Aufzeichnungen von Jobs anderer User an.

-          PROT             zeigt LOG Jobs anderer User an

-          RELE             veröffentlicht eigene Jobs während der automatischen

durchführung

-          SHOW           zeigt die Job-definitionen anderer User an.

 

Das Objekt S_BTCH_NAME zeigt alle autorisierten User an , die einen  Scheduler Job starten können an. Das Objekt definiert den Batchadministrator. Um einen User zum Batchadministrator zu machen gibt man hinter dem Usernamen ein großes Y an. Ohne diese Administrator kennung ist es jedem User nur möglich auf seinem eigenen Client zuarbeiten.

 

Das Objekt S_RZL_ADM wird benötigt zur Rechtevergabe. In Feld ACTVT entscheidet sich die Rechtevergabe anhand folgender Definition:

           

01               komplette Administrations Rechte des Computing Center Managment System

02               Nur Kontrolle des Computing Center Managment System (read only)

 

Das Objekt S_LOG_COM vergibt die Rechte für externe Befehle und Programme. Folgende Felder sind möglich:

           

-          Command          logische Namen der externen Befehle

-          Opsystem           Name des Betriebssystem und der angeschlossenen

Hosts

-          Host                     Host namen der angeschlossenen Systeme

 

 

Softwarelogistik und Transportwesen

 

-          Transport Managment System (Tms)

-          Mandantenkopie und Transport

-          Customizing Organizer (co) und Workbenchanalyser (wbo)

 

Verteilung von Softwarekomponenten im System. Bei den zuverteilenden Softwarekomponeten handelt essich in der Regel um Customizing-Einstellungen oder um Eigenentwicklungen von Kunden die zwischen verschiedenen Systemen transportiert werden sollen.

 

Datenstrukture eines R/3 Systems

           

Man unterscheidet zwischen Mandantenabhängigen und Mandantenunabhängigen Daten. Zu den Mandantenabhängigendaten Daten gehören:

           

-          Betreibswirtschaftliche Anwendungsdaten

-          Custominzing Einstellungen

-          Einstellungen die die Organisationsstrukturen des Kunden festlegen (wie z.B. Vertriebswege, Buchungskreise etc.)

-          Parameter von R/3 Transaktionen von Kundenspezifiesche Betriebswirtschaftliche Daten

 

Zwischen Mandantenabhängigen Daten bestehen enge Beziehungen, z.B. werden Cutomizing Einstellungen schon bei Eingabe von Anwendungsdaten auf Konsitenz überprüft und Notfalls abgewiesen. Daher sind Anwendungsdaten nur im Customizing Umfeld sinnvoll.

Mandantenunabhängige Einstellungen werden einmal durchgeführt und gelten dann für alle Mandanten eines Systems z.B.:

           

-          Custonizing Einstellungen (z.B. Druckereinstellungen)

-          Das R/3 Repository, das alle Objekte im R/3 Dictionary ( Tabellen, Datenelemente, Domänen) sowie alle Abap-Programme, Menüs, Oberflächen etc. enthält.

 

Aufgrund der Mandantenunabhägigkeit ist es möglich das Abap Programme beliebig in allen Mandanten nutzbar sind.

 

Anpassungsarten

 

Da in einem R/3-System verschieden Datenarten sind, gibt es auch unterschiedliche Arten der Änderung und anpassung. R/3 ist eine Standartsoftware und muß deshalb in einer einführungsphase dem jeweiligen Unternehmen angepasst werden. Das nennt man Customizing. Das Customizing beinhaltet alle Änderungen am R/3-System sowhl Mandanten abhängige als auch Mandanten unabhängige. In der Regel sind nach einem Upgrade eines Systemszusätzliche Customizing Änderungen vorzunehmen und das System wieder auf den Idealen Stand für das Unternehmen zu bekommen.

Erweiterungen und Anpassungen sind in der Regel nicht notwendig für den R/3 Einsatz.. Um das R/3 Repository anzupassen kann der Kunde eigenentwicklungen vornehmen. Zusätzlich können Kundenerweiterungen ins R/3 Repository eingebracht werden, wobei Anknüpfungs- und Ergänzungspunkte von der Sap vorgegeben sind.

Programme und Tabellen definitionen können auch direkt geändert werden. Diese Änderungen sind aber beim nächsten R/3 Update wieder abzugleichen. Deshalb emfiehlt  Sap mindestens 2 Sytsemlandschaften, eine zum Testen und Entwickeln und eine für den Produktiven Einsatz. Ideallerweise verfügt man über 3 Systemlandschaften, eine zum Entwickeln, eine zum Test und ein Produktivsystem, damit man bei Updates keine negative Überraschungen erlebt.

 

Customizing Einstellungen müssen zwischen Mandanten kopiert werden.

Repository Anpassung müssen zwischen System Transportiert werden.

 

 

Konzepte des Transport Managment System

 

Ab dem release 4.0 erlaubt das neue tms die zentrale Verwaltung zwischen den Systemen. Das TMS gruppiert das R/3 in 2 teilen:

           

Transportgruppe

 

-          Eine Transportgruppe besteht aus R/3-Systemen die auf ein gemeinsamens Transportverzeichnis zugreifen.

 

Transportdomäne

           

-          Eine Transportdomäne besteht aus einer oder meheren Transportgruppen, dadurch werden Systemlandschaften mit meheren Transportverzeichnissen unterstützt.

 

Wichtig für die Zentralle Verwaltung von Transporten ist das alle System der Tarnsportdomäne von einem dafür bestimmten R/3 System, dem sogenannten Transportdomäncontroller, aus verwaltet werden. Folgende Informationen werden zentral abgelegt:

-          An den Transporten beteiligte Systeme

-          Deren Transportwege

 

Diese Informationen werden über den Transportdomäncontroller per RFC verteilt.

 

 

 

 

 

 

Beim ersten Aufruf des Transport Managment System wird ein Transportdomäncontroller bestimmt. Sobald die domöne angelegt ist, können andere System darauf zugreifen, jedoch ist aus Sicherheitsgründen dafür eine Genehmigung des Transportdomäncontroller erforderlich. Zur aufnahme in die Transportdomäne gibt es 3 Statusmeldungen:

           

-          wartet auf Aufnahme

-          aktiv

-          System für TMS gesperrt

-          System nicht aufgenommen

 

Der Transport zwischen verschiedenen Releaseständen wird von Sap nicht unterstütz. Aufgrund der zentralen Bedeutung sollte der TDC auf einem System mit hoher Verfügbarbeit installiert sein. Transportwege können sowohl in einem Graphischen Editor per Drag and Drop als auch mit einem Texteditor konfiguriert werden. Es gibt zwei arten von Transportwegen:

 

Konsolidierungswege, sie bestimmen das Verhalten beim export. Dafür wird eine Transportschicht verwendet um die Wege vom Entwicklungssystem zum Qualitätsicherungsystem zu definieren.

           

Beliferungswege beschreiben den Import die dem Qualitätssicherungssystemen folgen. Es wird keine Transportschicht verwendet.

 

Nach Konfiguration der Transportwege auf dem Transportdomäncontroller werden sie Domänweit verteilt. Aktiviert werden sie entweder Global oder am Transportdomäncontroller und sind danach nutzbar. Die Versionsverwaltung im TMS speichert dieüberschriebenen Transportwege.

 

Qualitätssicherung des TMS

 

Im Regelfall werden Entwicklungen am Developing system erstellt. Dann zum Qualitätssicherungssystem transportiert. Dort werden dann die Neuentwicklungen getest, und sobald alle Fehler beseitigt sind werden die daten ins Produktivsystem überspielt.

 

Änderbarkeit des Systems

 

Seit Release 4.0 können auch Namensbereiche ausserhalb des Kundennamens-raumes ( Y,Z ), für Kunden und Partner reserviert werden. Die namensräume sind für große Kundenentwicklungen und Add-On-Entwicklungen bestimmt. Für kleinere Entwicklungen sind weiterhin die bisherigen Namensräume ausreichend. Die Syntax für Objekte aus reservierten Namensräumen ist:

           

            /<Namensraum>/<Objektname>

Beispiel

            /abcdef/customer

Die länge des Namensraumes ist auf max. 10 zeichen beschränkt.

Um änderungen durchführen zu können, darf das R/3-System nicht global gegen Änderungen gesperrt sein.

Änderbarkeit von Mandanten

 

Nach der Installation und dem Anlegen der Mandanten muß deren Änderbarkeit in abhängigkeit der Funktion eingestellt werden. An einem produktiv-Mandanten sollten keine Änderungen erlaubt sein. Pro Mandant können Einschränkungen auf verschiedenen Ebenen defniert werden, Folgende Unterscheidungen sind möglich:

           

-          Änderungen nicht zulässig

-          Änderungen sind zulässig dürfen aber nicht Transporttiert werden (Schulungsmandant)

-          Änderungen sind zulässig und dürfen transportiert werden. Hierbei muß noch entschieden werden ob Änderungen automatisch mit dem Customizing transportiert werden oder es Sie nur manuell Transportierbar sind.

 

Zusätzlich muß noch entschieden werden ob die Mandantenunabhängigen Einstellungen geändert werden dürfen. Mittels einer einstellbaren Sicherheitsstufe kann der Kunde festlegen ob der Mandant ducrh Mandantenkopie überschrieben werden darf und ob seine Daten extern verfügbar sind (z.b. für Mandanten oder Customizingvergleiche über Systemgrenzen hinweg). Sicherheitseinstellungen sind für produktive Mandanten unerläßlich.

 

Zusammenfassung der Transportlandschaft:

 

1.      Ein Transportverzeichnis muß auf jedem R/3 System der Transportdomäne verfügbar sein. Pro System ist nur eins erlaubt.

2.      Um das tms zu konfigurieren wird ein Transportdomäncontroller eingerichtet.

3.      Das Transportprogramm tp muß konfiguriert werden:

Die Parameter für das Transportprogramm stehen (tp) stehen in der datei TPPARAM im Verzeichnis /usr/sap/trans/bin. Die Datei muß auf alle System identisch sein, bis auf dem Parameter transdir.

4.      Alle beteiligten System müssen im TP aufgenommen werden.

5.      Die Systemänderbarkeit muß festgelegt werden.

6.      Mandaten und deren änderungsregeln müssen definiert werden.

 

Transporte innerhalb eines R/3-Systems

 

Sobald ein R/3-System mit Mandanten eingerichtet ist, müssen diese angepasst und mit Daten gefüllt werden.  Dabei geht es zuerst um die Datenverteilung innerhalb des Systems, dem sogenannte Customizing. Das Customizing wird in einem eigenen Mandanten vorgenommen und dann in alle Mandanten des Systems verteilt. Bei dem Verteilungsvorgang ist zu unterscheiden zwischen Zielmandanten mit bereits vorhandenen Daten die erhalten bleiben müssen undzwischen leeren Mandanten.

Bei Zielmandanten mit bereits vorhandenen Daten werden die Customizing Einstellungen mit dem Transaktionscode SCC1 verteilt. Damit wird es ermöglicht einzelne Tabelleneinträge zu transportieren ohne den Zielmandanten zu löschen. Bei leeren Zielmandanten empfiehlt sich eine lokale Mandantenkopie, da dadurch alle Einstellungen Problemlos übernommen werden.

 

 

Lokale Mandantenkopie

 

Im Zielmandanten wird im Transaktionscode SCCC mit tools à administrationà administration à client administration à client copie à lokale copie die Mandantenkopie ausgewählt. Der lokale Mandant wird dann mit den Daten des Quellmandanten überschrieben. Die Kopie beinhaltet den kompletten Mandanten inkl. Customizing Einstellungen, Anwendungsdaten und User-Berechtigungen. R/3 erlaubt nicht das kopieren von Anwendungsdaten ohne deren Customizing Einstellungen, das die Daten voneinander abhängen und dadurcg das System nicht mehr konsitens wäre.

Das kopieren der Berechtigungstabelle und der Customizing Daten ist hingegen Problemlos möglich. Beim kopieren von Customizing Daten sollten die entsprechenden Daten zuerst im Zielmandanten gelöscht  werden.

Nachdem alle Daten zum kopieren ausgewählt sind, markiert der Abap-Client alle zu kopierenden Daten und Tabellen. Zum Sicherstellen das keine Daten inkonsitenzen auftreten verhindert das System das sich User während der Kopie anmelden.

Mandantenkopien sind in der Regel, aufgrund der Datenmengen, längere Aktionen sodaß eine Kopie im Regelfall als Hintergrundprozess geplant werden sollte.

 

Bei einer Lokalen Kopie loggt man sich im entsprechenden Mandanten ein. Bei einem neuen (leeren) Mandanten logt man sich mit dem User sap* und dem Password pass ein.

 

Transporte innerhalb der Transportdomäne

 

Transporte innerhalb der Transportdomäne werden in zwei Phasen unterteilt:

 

            Aufbauphase

           

            Pflegephase

 

Aufbauphase:

 

In der Aufbauphase liegen noch keine Relevanten Mandantenabhägigen Daten vor im System vor. Es gibt zwei Werkzeuge zur Mandantenkopie:

 

            Workbench Organizer und Transportsystem

            Remote Mandantenkopie und Mandantentransport

 

Während der Aufbauphase ist zunächst das R/3 Repository abzugleichen. Kundenentwicklungen (z.b. Abap-Programme) müssen mittels Änderungsaufträgen in das neue System integriert werden. Danach werden die Customizing Einstellungen mit den o.g. Werkzeugen in das neue System kopiert.

Mandantentransport und Änderungsaufträge erreichen ihr Zielsystem über das Transportverzeichnis, während Remote Mandantenkopien über eine RFC Verbindung den Datentransport realisieren.

Beide Lösungen sind nicht für die übernahme großer Produktiver Mandanten, oder einer Datenbank gedacht.

 

 

 

Pflegephase

 

Sobald Daten in den Zielsystemen vorliegen und erhalten bleiben sollen dürfen die obigen System nicht mehr eingesetzt werden. Die verteilung weiterer Änderungen geschieht deshalb über den Custominzing Organizer. Dafür muß allerdings die automatische Aufzeichnung von Änderungen eingeschaltet sein. Sowohl der Workbench Organizer allegeänderten Objekte auf.

Beim Customizing handelt es sich primär um Tabelleneinstellungen. Änderungen im R/3 Repositorium und im Mandantenunabhägigen Customizing werden auch weiterhin mit dem Workbench Organizer gemacht. Der Customizing Organizer wird primär für die Verwaltung und Änderung am Customizing genutz, obwohl er auch in der Lage ist Workbenchaufträge zu verwalten. Um eine Sinnvolle Trennung zu erhalten sollte Änderungen am R/3 Repositorium aber vom Workbench Organizer verwaltet werden. Beide ermöglichen den Transport ins lokle Zielverzeichnis, von dort werden dann die Daten mittels Zielsystem ins Transportverzeichnis kopiert.

 

 

Profektentwicklung und Customizing

 

Die R/3-Systementwicklung basiert auf 2 verschidenen Usern:

           

-          Teamleitern

-          Teammitgliedern

 

Jede Usergruppe hat ihren eigenen Bereich der Verantwortung. Diese Strukturen organisieren die gesamte implementierung von R/3 Entwicklungen. Der Teamleiter definiert und koordiniert ein Projekt, während die Projektmitglieder denen ihnen zugewiesenen teil der Projektarbeit erledigen und dokumentieren.

Zum Auswählen von Projektmitgliedern wählt der Teamleiter im Projekt IMG Additional Informationen à Status Informationen à select Team Members.

 

Managment von Transporten in Projekten

Seitdem Release 4.6A kann das Projekt IMG direkt in das Wechsel- und Transportsystem verlinkt werden. Wechselanfragen können direkt während des Projektes für Entwicklung und Customizing aufgezeichnet werden. Das ermöglicht, das alle aktivitäten zusammengefasst werden können. Teammitglieder zeichnen ihre änderungen auf, welche dann vom Teamleiter zusammen gefasst werden. Um Projekte zu definieren nutz man die Transaktion SPRO_ADMIN oder man wählt den weg : Accelerated SAP à Customizing à Projektmanagment. Der Workbench- und der Custominzing Organisier zeichen die Änderungen auf.

Alle Aufgezeichneten Änderungen können nur vollständig in ein anderes Systemtransportiert werden.

 

Sap Software Change Registration (sscr)

 

Entwickler müssen vor jeder bearbeitung der Workbench im OSS registriert sein, zusätzlich muß zur bearbeitung von Objekten ein Objektschlüssel im OSS angefordert werden.

 

 

 

Verwalten von Änderungsaufträgen

 

Workbench Organiser und Customizing Organizer dienen beide zum Aufzeichen von Änderungen und zum Transportieren von Objekten, sowie zur koordinierten Durchführung von Custominzing- und Entwicklungsänderungen. Der Unterschied zwischen den beiden ist hauptsächlich,  das sie zur Aufzeichnung und Verwaltung von verschiedenen Objekte eingesetzt werden.

 

Der Worbench Organiser koordiniert folgende Entwicklungsaktivitäten:

 

-          vollständige Aufzeichnung und Dokumentation von Änderungen

-          Teamarbeit

-          Versionsverwaltung

-          Sperren von Objekten

-          Entwicklungsklassen

-          Angeschlossen an das Transportsystem

 

Der Customizing Organiser koordiniert folgende Entwicklungsaktivitäten:

 

-          vollständige Aufzeichnung und Dokumentation von Änderungen

-          Teamarbeit

-          Tabellenprotokollierung

-          Angeschlossen an das Mandatenkopie- undTransportsystem

 

Repository-Objekte  wie zum Beispiel Abap-Programme oder  Tabellendefinitione haben eine ausgeprägte Struktur. Objekte die beim Customizing geändert werden fehlt diese, deshalb sind funktionen wie Versionsverwaltung, Sperrmöglichkeiten und zuordnung zu Entwicklungsklassen nur für Objekte möglich die vom WBO verwaltet werden. Die Tabellenprotokollierung, zur Aufzeichnung von Änderungen im Customizing, wird mit dem  Profilparameter REC/CLIENT und der Tabellen Historie im Customizing aktiviert. SAP liefert zur Anpassung immer den SAP Referenz impletations Guide (IMG) aus, worin das Customizing aller vorhandenen Module enthalten ist. In der Regel werden bei Einführung eines R/3-System nur bestimmte Module ausgewählt (z.b. FI und CO (Finanzwesen und Controlling)).

Zu beginn der Systemeinführung wird ein Unternehmens IMG generiert, der alle Customizing aktivitäten zusammenfasst. Da hier noch zuviele Transaktionen enthalten sind, wird es nochmalwird es nochmal in Projekt-IMG unterteilt. Alle IMG sind Mandantenunabhängig. Die erfassten Änderungen können zu einem oder mehreren Aufträgen zusammengefasst werden.

 

Ablauf des Customizings

 

-          Mit dem Sichern der Einstellungen durch den Customizing Organiser werden die Einstellungen erfasst

-          Die Änderungen werden einem Auftrag zugeordnet, der bereits existiert aber noch nicht freigegeben ist, oder vom Benutzer angelegt wird.

-          Die in diesem Auftrag erforderlichen Einstellungen werden in der Aufgabe der jeweilegen Benutzer angezeigt. Die Zuordnung geschieht anhand des jeweiligen Benutzernamens.

-          Sobald die erforderlichen einstellungen vorgenommen sind kann die Aufgabe freigegeben werden. Dabei kann und sollte eine Dokumentation über Gründe und Art der Änderung angelegt werden.

-          Nach Freigabe aller Aufgaben kann auch der übergeordnete Auftrag Freigegeben werden, damit ist in der Regel der Export in das Transportverzeichnis verbunden.

-          Beim Export und auch beim Import in das Zielsystem ist immer eine genaue kontrolle der Logs Sinnvoll. Die Bedeutung der ReturnCodes:

-          0 Fehlerlos

-          <=4 Warnungen

-          > 8 Fehler die eine Nachbearbeitung erfordern

 

Ablauf Workbench Entwicklung

 

Die Entwicklung von Repository Objekten verläuft in der Regel analog zum Customizing, nur die Unterschiedliche Art der Objekte bedingt einige besonderheiten der Workbench Entwicklung. Eine Neuentwicklung beginnt  mit dem anlegen eines Objektes z.b. im Abap-Editor oder im R/3 Dictionary. Jedem Projekt muss zunächst eine Entwicklungsklasse zugewiesen werden. Dadurch wird die zugehörigkeit des Objektes zu einem Projekt bestimmt: z.b. Entwicklung für HR. Desweiteren müssen Transporteigenschaften definiert werden:

           

-          Aufzeichnung geschieht wie beim Customizing in Aufträgen und Aufgaben. Danach wird das Objekt gegen Zugriff von nicht nicht Auftragsmitgliedern gesperrt, wodurch eine klar abgegrenzte Projektarbeit möglich wird.

-          Die Freigabe des Auftrages erfolgt nach Freigabe der einzelnenAufgaben, erst dann werden die dazugehörigen Objekte exportiert, Versionen erzeugt und die Sperren gelöscht! Die Objekte sind dann wieder frei für neue Projekte.

-          Sollte es sich nicht um Neuentwicklungen sondern um Änderungen handeln, entfällt die Angabe der Entwicklungsklasse. Hier muß aber entschieden werden, ob das Objekt als Original oder als Kopie im jeweiligen System vorliegt. Ein Beispiel für Kopien in Kundensystemen sind immer Objekte des SAP-Standarts.

 

Transportbuffer

 

-          Der Abschluß beim Transport von Customizing Einstellungen und Workbenchobjekten zwischen verschiedenen R/3-Systemen bildet der Import aus dem Transportverzeichnis in das Zielsystem.

-          Den Import übernimmt das TMS. Im Transportverzeichnis exitiert ein Puffer zum Import der Aufträge in das System. Hier werden die zu Importierenden Aufträge in der Reihenfolge ihrer Freigaben gesammelt. Hier wird also ein geordneter Importqueue implementiert.

-          Im TMS können von jedem System der Transportdomäne alle Import-Queues angezeigt werden.

-          Pro Import-Queue  wird dabei die Anzahl der Aufträge und der Status der Queue angezeigt:

-          offen                     neue Aufträge können hinzugefügt werden.

-          geschlossen        neuhinzugekommene Aufträge werden nicht beim

 nächsten vollständigen Import der Queue importiert

-          In der Queue existieren fehlerhafte oder laufende Importe oder die Quelle kann selbst nicht gelesen werden.

 

 

Die Daten der Import-Queuewerden nicht automatisch aktuallisiert.

 

Importverfahren:

 

Import in das QAS

            Das TMS zeigt nach der Auswahl eines Systems folgende Details an:

 

-          Reihenfolge von Namen und Transportaufträgen

-          Benutzerkurztext

-          Objektliste

-          Dokumentation

-          Transportprotokolle

Alle Aufträge können mittels des TMS in der Transportdomäne frei Transportiert werden. Man kann Transports entweder als gesamte Queue transportieren oder jeder Auftrag kann einzel Transportiert werden. Aufgrund vielfacher abhängigkeiten sollten immer nur mit dem vollständigen Import gearbeitet werden. Da aufgrund der abhängigkeiten sonst Fehlerquellen entstehen würden. Vollständiger Import ist auch die Standarteinstellung des TMS. Das TMS bietet einen Alertmonitor zur überwachung an, desweiteren stehen Transportprotokolle des Betriebssystems zur Analyse bereit.

Transportprotokolle werden nicht in eine andere Transportgruppe transportiert. Um die Transportprotokolle eines Systems zu analysierern muß immer das jeweilige TMS verwendet werden.

 

Import in ein Produktivsystem:

 

Nachdem Änderungen ausgibieg getestet wurden, sind sie bereit für den Import in das Produktivsystem. Mit dem TMS können alle Aufträge in der korrekten Reihenfolge in das Systemgespielt werden.. Zur Sicherstellung das die aktivitäten des Produktivsystems nicht gestört werden ist es zwingend notwendig, das  das Importqueu in der richtigen Reihenfolge abgearbeitet wird.

Die wichtigsten Importierungswerkzeuge zur Durchführung der Importqueue des TMS sind die Importwarteschlangen die auf die Importpuffer des Betriebssystems zugreifen. Das Importqueue zeigt die zu importierenden Importe in korrekter Reihenfolge an.

 

Um einen Überblick über die Transporte zu gewinnen nutzt man im STMS die Funktion overview à imports. Hier wird der Status aller transportsysteme in der Transportdomaine sichtbar. Um die Performance zu überprüfen werden Daten beim 1. Aufruf des TMS nur gelesen. Danach werden die Imformationen angezeigt die zwischen gespeichert wurden. Die Zeitangabe zeigt an wie aktuell die daten sind.Täglich um 00:00 Uhr wird der interen Puffer geleert. Zum aktuallisieren nutz man die Funktion Edit à Refresh. Zur Erhöhung der Performance ist es sinnvoll den Refresh regelmäßig durchzuführen.

Um unbeabsichtigte Änderungen zu verhindern emphielt SAP den Importqueue vor dem Transport zu schliessen- Um alle angezeigten Queue zu importieren wählt man Queueà Start Import und beantwortet die Dialogbox mit continue.

Der Transportqueue kann von jedem anderen System der Transportdomaine gestartet werden. TMS startet dann das Transportprogramm tp im Zielsystem. Parameter stellen fest ob das Transportprogramm Synchron oder asynchron gestartet wird. Bei der Asynchronen übertragung läuft TP im Hintergrund und blockiert keinen Workprozess.Nachdem Transport öffnet sich die Queue und die Endmarkirung wird verschoben. Nachdem die Änderungen Transportiert wurden, werden Ssie markiert zum Transport in andere Systeme. Die Transportroutenkonfiguration legt fest, welche Änderungen automatisch in andere Systeme weitergeleitet werden. Unaktive Aufträge werden im System erkannt und verworfen. Da alle zu ändernde Objekte ältere Änderungsdaten haben müssen, ist es nahezu ausgeschlossen, das veraltete Aufträge transportiert ins Produktivsystem transportiert werden. Für jedes System kann der Import mit dem Parameter NO_IMPORT_ALL im tp deaktiviert werden.Zum Import von einzelenen Aufträgen dient die Funktion tp import <Transport request>. Die Qualitätskontrolliste des STMS wird angezeigt mit overviewà Imports à goto qa Worklist. Im Kopf der Anzeige wird Angezeigt :

           

-          letztes Update

-          wieviel Aufträge noch verarbeitet werden müssen

 

Die Liste bietet zwei Ansichten:

 

-          approval Steps                           //alle stufen

-          selected appoval Steps            // Stufen geodnet nach Eigentümern

 

Bevor eine Queue ins Produktivsystem eingespielt werden darf, muss es erfolgreich getestet werden. Wenn eingige Aufträge eines übergeordneten Auftrages nicht erfolgreich getestet wurden, kann der gesamte Auftrag nicht ins Produktivsystem integriert werden.

 

Import von kompletten Projekten

 

Es ist durch setzen eines Filters möglich nur Aufträge eines bestimmten Projektes zu importieren. Filtersetzen durch edit à filter. Dann wird der Import-Request nur das entsprechende Projekt transportieren.

 

 

Benutzer / Berechtigungskonzepte

 

Es können drei Benutzergruppen unterschieden werden:

           

-          BetriebssystemUser

-          DatanbankUser

-          R/3-SystemUser

 

Hier geht es lediglich um die R/3 systemUser, sie sind nur innerhalb des Systems bekannt und können nur dort genutz werden.

 

Berechtigungskonzept:

           

Berechtigungen werden über Profilen den Benutzerstämmen zugeordnet. Bei jeder Transaktion prüft das System ob der User die entsprechenden Rechte und zugriff auf die benötigten Objekte hat. Jedem user ist eine Spezielle Rechte Tabelle zugeordnet. Diese Rechte Tabelle beinhaltet eine eine Sammlung von verschiedenen Profilen zur Vergabe der rechte. Profile und rechte können mit verschiedenen Methoden vergeben werden:

 

-          Profilgenerator

-          Manuell

Berechtigungen gehören immer zu dem Berechtigungsobjekt in dem Sie erstellt wurden. Sie werden in der Regel in Objektklassen gruppiert, welche wiederum nach Geschäftsbereichen Organisiert sind. Das Berechtigungskonzept dient als Schablone sowohl für die Berechtigungspflege als auch für die Berechtigungsprüfung im Programm. Um Berechtigung anzuzeigen und zu pflegen müssen bestimmte Werte in Feldern des Berechtigungskonzeptes eingetragen werden. Berechtigungen werden in Transaktionen und Reports geprüft. Berechtigungen sind immer Positiv ( z.b. Leserecht).

Bei der Anmeldung am System werden Berechtigungendes Users in den Benutzerpuffer des Users übernommen. Vor ausführung einer Transaktion o.ä. werden dann die erforderlichen Rechte mit denen im Benutzerpuffer des Systems verglichen. Danach erfolgt dann eine abarbeitung oder eine Fehlermeldung des Auftrages.

 

Profilgenerator

 

Der Profilgenerator erleichtert die zuordnung von Berechtigungen und Usern. Transaktionen die aus Unternehmenssicht zusammen gehören werden in Aktivitätsgruppen zusammengefasst. Die so erstellten Aktivitätsgruppen können dann entsprechenden Benutzern zugeordnet werden. Jeder user kann mehrern Aktivitätsgruppen zugeordnet sein. Der Profilgenerator wird mit TRCPFCG oder mit Tools à Administration à User Maintenance à  Aktivity Groups à User Rolls gestartet.

Der Profilgenerator bietet 2 Ansichten:

 

-          Basisansicht

-          Die Basisansicht bietet dem Admin an Gruppen zuerstellen und zu ändern. Hier können User ihren Gruppen zugeordnet werden. Änderungen sind sowohl für ganze Gruppen als auch für einzelne User möglich.

-          Erweiterte Ansicht

-          Die erweiterte Ansicht erlaubt die Gruppenerstellung mit einem Grafischem Hilfsprogramm. Die grafische Ansicht kann die komplette Unternehmensstruktur abbilden. Hier können auch querverbindungen erstellt werden.

 

Um Benutzer mit dem profilgenerator zu erstellen geht man wie folgt vor:

           

-          Aktivitäten und Transaktionen die der User beseitzen soll werden festgelegt.

-          Ein oder mehrer Authorisationsprofile werden erstellt.

-          Rechte werden in Aktionsgruppen hinzugefügt

-          User Master Tabellen werden verglichen.

 

Für weitere Informationen:

            Online Help BC Basis Components Computing Center Managment  Center à User Authorisation.

 

Gruppenrechte

 

Sobald eine neue Gruppe erstellt ist, muß entschieden werden welche Transaktionsrechte diese Gruppe benötigt. Diese werden dann aus dem Firmenmenü, einer anderen aktiven Gruppeoder dem globalen Menü zugeordnet. Wenn einmal Transaktionen einer aktiven Gruppe zugeordnet sind, setzt der Profilgenerator automatisch die erforderlichen Rechte und Transaktionen zusammen. Die Verbindung zwischen Transaktionen und benötigten Objekten sowie deren Defaultwerten sind in den Tabellen USOBT und USOBX von Sap definiert. Zum Anzeigen von Tabelleninhalten nutz man die Transaktion su22.

Direkt nach der R/3-Installation sollten die Grundeinstellungen der Tabellen USOBT und USOBX mit der Tansaktion su24 (Tabellenkopieren) nach USOBT_C und USOBX_C kopiert werden. SU24 zeigt die Tabellen USOBT_C und USOBX_C an und läßst auch Änderungen zu. Der Profilgenerator nutz die Tabelle USOBT_C und USOBX_C um Authrisationen und und Transaktionszugriffe zu erstellen.

Nachdem im Profilgenerator alle entsprechenden Felder ausgefüllt sind, und die Profilampel grün zeigt kann das Profil generiert werden.

 

Benutzerstammsatz

 

Ein Benutzerstammsatz setzt sich aus 4 Obergruppen zusammen:

           

1.      Festwerte:

-          Druckereinstellungen

-          Spoolaufträge

-          Anmeldesprache

-          Datumsformat

-          Etc.

 

 

2.      Adresse

-          Vollständiger Name

-          Adresse

-          Etc

 

 

3.      Parameter

-          Vorschlagswerte für R/3 Felder

 

 

4.      Benutzerdaten

 

-          Profile

-          Aufgabenprofile

-          Benutzertyp

-          Initialkennwort

 

Eigene Daten von Benutzern können über System à Benutzervorgaben à Eigene Daten geändert werden.

 

Zentrale Userverwaltung

 

Benutzerverwaltung quer durch Systemlandschaften kann ein sehr komplexe Aufgabe sein. Ein Zentrale Userverwaltung hat viele Vorteile:

           

-          Überblick über alle User

-          Überblick über alle Gruppen

-          Systemweite Definition der Systemgruppe

-          Aktuelle Gruppen

-          Alle User arbeiten in den gleichen Systemen mit gleichen rechten

-          Jede User ID ist überall im System verfügbar

-          Der Administrationsaufwand und das Synchronnisieren der Userdaten verringert sich erheblich.

-          Die komplexität der Systemlandschaft spielt bei der Userverwaltung eine Rolle

 

Der Transaktionscode scum ermöglich die Zentralle Useradministration. Weitergehende Infos über BC305 Advanced Administration.

 

Einstellung der Systemprofilparameter:

           

Gemäß Sap-Anforderung müssen alle SystemProfiparameter mit login/ beginnen.

Wichtige Parameter:

           

            Login/ Fails_to_user_lock

 

Erlaubte Fehlversuche, um Mitternacht werden alle User entsperrt.

 

            Logn/Failed_User_auto_Unlock

                                  

                                   Die Automatische entsperren um Mitternacht wird deaktiviert.

(OSS 66533).

Um Benutzer zu Sperren entsperren oder zum zuweisen neuer kennwörter wird die Transakion su01 verwendet.

 

Kennwortregeln:

           

-          Kennwort darf nicht Identisch mit den letzten 5 sein

-          Darf nicht mit den ersten 3 Buchstaben des Usernamens beginnen.

-          Darf nicht pass oder sap lauten

-          Darf nicht mit frage- oder ausrufezeichen beginnen.

 

 

 

 

Standartbenutzer:

 

Mandant

000

001

066

Neu

Benutzer

sap*

ddic

earlywatch

sap*

Initialkennwort

06071992

19920706

support

pass

 

 

Die Initialkennwörter müssen sofort nach der Installation geändert werden. Der User Sap* ist in jedem neuen Mandanten mit allen rechten vorhanden. Der Benutzer kann verwendet werden um neue User anzulegen. Um diesem Benutzer zu deaktivieren nutz man den Profilparameter:

            Login/no_automatic_user_sapstar (oss 68048).

 

Informationssysteme

Das Informationssystem ermöglicht Benutzerstammsätze und Profile anhand Ihrer Berechtigungsobjekten auszuwählen. Darüber hinaus stellt es eine Änderungshistorie aller Änderungen an Kennwörtern, Benutzertypen, Benutzergruppen und Benutzerberechtigungen zur Verfügung. Es wird mit dem Transaktionscode  suim aufgerufen.

 

Berechtigungs-Traces

 

Das R/3 System ermöglicht es herrauszufinden welche Berechtigungen erforderlich sind wenn ein bestimmtes Programm benutz wird. Um die  Systemtrace aufzeichnung zu nutzen wählt man Werkzeuge à Administrationà Monitor à Trace à Systemtrace. Der Transaktionscode  su53 zeigt die fehlenden Berechtigungen weshalb eine Transaktion abbricht.

Der Transaktionscode  su53 zeigt den eigenen Berechtigungspuffer.

           

Spool-Systeme

 

Im R/3-System gibt es über ein internes Spoolsystem verschiedene Möglichkeiten der Informationsausgabe.

Wenn Benutzer verschiedene Aktionen ausführen, wie zum Beispiel Bestellungen anlegen, wird ein Ausgabe Formular erzeugt. Hier werden die Informationen der Bestellung über ein bestimmtes Medium (Fax, Email, Druck etc) an einem Dritten übergeben. Das Dokument stellt eine Nachricht dar. Wenn eine Nachricht angelegt worden ist, wird sie in den Spooler gestellt und dort bei Bedarf freigegeben.

           

Zusätzlich zur Nachrichtensteuerung wird ein Ausgabedokument aus einer Kombination zwischen Druckprogramm und Sapscriptformular erzeugt! Das Druckprogramm erzeugt dabei die Daten aus der Datenbank und das Sapscript ist für das Layout zuständig. Desweiteren gibt es noch ausgabedokumente in Form von Reports und Abap-Programmlisten. Diese Dokumente werden über Druckfunktionen der Menüleisten oder des Systemmenüs ausgegeben! Damit eine einheitliche Schnittstelle für die Spool-Dienste verschiedener Betriebssysteme angeboten werden kann enthält das R/3-System ein internes Spool-system. Es erzeugt eine druckfertigen Ausgabestromfür das jeweilige Betriebssystem! Dadurch ist das R73-System nicht auf die Formatirungsdienste des jeweiligen Betriebssystemes angewiesen. Die Spool- und Druckdienste werden nur benötigt um den Datenstrom zu den jeweiligen Ausgabegeräten zu übergeben.

Überblick über dem Profilgenerator

 

Der Profilgenerator (Transaktionscode pfcg) ist eine einfache möglichkeit zum erstellen von Benutzerprofilen, welche dann entsprechenden Gruppen im Unternehmensprofil zugeordnet werden. Zu den erstellten Gruppen können dann entsprechende User hinzugefügt werden. Jeder User kann zu einer oder meheren verschiedenen Gruppen gehören.

Der Profilgenerator erkennt automatisch welche Transaktionen zu den entsprechenden Objekten gehören die den entsprechenden Gruppen zugeordnet sind und erteilt sie. Der Profilgenerator wird vom Administratorin folgender Reihenfolge bedient:

 

-          Organisatorische Unternehmenseinheiten müssen gebildet werden, hier werden alle Mitarbeiter  in entsprechende Gruppen einsortiert

-          Die vom System vorgeschlagene Rechtevergabe muss überprüft und gegebenenfalls korrigiert werden

-          Felder die nicht zur Organisatorischen Einheit des Systems gehören werden bei der Rechteverbage außeracht gelassen.

-          Für alle ausgewählten Gruppen werden Profile generiert. Die benötigten Berechtigungen werden vom Profilgenerator erstellt.

-          In der jeweiligen User-Master-Tabelle werden die entsprechenden Rechte vom Profilgenerator eingetragen.

 

Es ist nicht möglich verschiedenen Gruppen mit genug identischen Rechten zuerstellen. Änderungen an Userrechten werden erst bei Neuanmeldung des Users wirksam. Wenn eine Transaktion im Profilmanager hinzugefügt wird wird direkt getestet ob alle erforderlichen Berechtigungen vorhanden sind, die Anzeige teilt sich in 3 Bereiche:

 

1.      Bereich

-          Hier sind die Informationen über die Objektklassen enthalten.

 

2.      Bereich

-          Hier sind die benötigten Transaktionen nach Kundengeordnet, inklusive der Profilrechte

 

3.      Bereich

-          Alle berechtigungen sind hier in kleinste Teile zerlegt.

 

Die angegebenen Werte müssen vom Administrator überprüft werden. Die Berechtigungen jeder einzelnen Spalte sollten überprüft werden. Ein Ampel zeigt bei neuhinzugekommenen Transaktionen ob die erforderlichen Rechte ausreichen.

 

Mit dem Transaktionscode su35 werden alle, wegen fehlender Berechtigung, abgebrochenen Verbindungen  angezeigt inklusive der fehlenden Berechtigung. Wenn die Berechtigungen nicht angezeigt werden sollten die folgenden Punkte überprüft werden:

 

-          Berechtigung wurden seitdem letzten LogIn geändert, sodaß sie noch nicht übernommen wurden.

-          Der User Speicher ist zu klein, er muß im R/3 Profilparameter Auth_number_in_Userbuffer erhöht werden.

-          Wenn Berechtigungen durch das Transportsystem verändert oder neuertielt wurden. Der Buffer wird aktualisiert mit Transaktionscode su01 Enviroment Mass Changes Reset all Buffers.

 

Im Bereich der Benutzerverwaltung gibt es 3 Standartgruppen im Sap-System:

 

            SAP_ADM_AU        Authorisations Administrator (Hauptauthorisation)

            SAP_ADM_PR        Profiladministrator (Erstellung von Profilen)

            SAP_ADM_US        User Administrator (Haupt R/3 Systemuser)

 

Gruppen sollten im entwicklungssystem erzeugt und verwaltet werden. Das berechtigungskonzept wird im Qualitätssystem getestet. Im Produktvsystem werden dann User mit den Berechtigungsvorlagen des Qualitätssystems erstellt. Ein R/3 User mit Entwicklungsberechtigungen kann, in der Standartkonfiguration  Berechtigungsprüfungen umgehen, das sollte im Produktivsystem auf jedenfall verhindert werden.

 

R/3 Spool und Drucksystem

 

In einem R/3-System gibt es verschiedene möglichkeiten zur Informationsausgabe. Vom User erstellte Dokumente müssen ausgegeben werden, das geschieht in der Regel per Drucker, Fax, Email etc.. Die Nachricht wird dann durch das R/3-Spool-System an die entsprechende Ausgabe weitergeleitet. Der Ausdruck entsteht durch eine Kombination aus Datenbank und Sapscript. Die Datenbank ist für den Inhalt verantwortlich und das Sapscript für das Layout. Die so erstellte Seite wird dann zum Betriebssystemspooler geleitet, wo sie grdruckt wird. Eine andere Form der der Datenausgabe sind R/3 Reports und Abap-Programmlisten, welche in der Regel durch Bedienung des Systemmenüs grdruckt werden. Das R/3-System nutzt ein universelles Interfaces damit Betriebssystemdrucker unabhängig vom eingesetzten Betriebssystem angesprochen werden können. Das Dokument wird komplett vom R/3 System erzeugt und dann über die entsprechenden Treiber ins Spoolsystem des des Betreibssystems transferiert. Das R/3 System braucht also nur den Betriebssystemspooler um den Weg zu den angeschlossenen Druckern zu finden. Der Betriebssystem-Spooler erledigt dann die Druckausgabe.

Der Spoolprozess startet sobald ein Dokoument erfolgreich erstellt wurde in folgender Reihenfolge:

 

1.      Ein Spool-Request wird erstellt sobald ein Dokument zum Drucken geschickt wird. Daten die aus verschiedenen Quellen kommen ( Abap Report, Sap-Script etc.) werden hier in ein universelles Format umgewandelt. Danach werden die Daten zum Output-Request weitergeleitet.

2.       Der Output-Request  sendet die Daten dann entsprechend dem jeweiligen Format zum Betriebssystemdrucker. Es können auch verschiedene Output-Request vorhanden sein, z.b. für verschiedene Druckertypen, Anzahl Kopien etc. .

 

 

 

Das R/3 Spool System speichert die Antragsinformationenin der R/3 Datenbank:

 

-          Original Mitteilung

-          Erstelldatum

-          Ersteller

-          Logischer Druckername

-          Client Nummer

-          Spool-Daten

 

Das Spoolsystem speichert die Druckdaten zusätzlich in einer Datenbank namens Tempse ( Temporäe Sequentielle Datenbank). Tempse kann die Daten in der Datenbank oder auf Betriebssystemebene speichern. Um Festzulegen wo die Daten gespeichert werden wird der ParameterRSPOLLSTORE_LOCATION entweder auf db (Datenbank) oder auf g (Betriebssystemdatei) festgelegt! Output Request werden nur als Datenfiles gespeichert, da der Druckbare Teil gerätespezifisch ist.

 

Spool Workprozess

 

Sobald ein Dokument gedruckt wird,wird ein gerätespezifischer Datenstrom erzeugt, der die Daten über einen Workprozess in den Betriebssystemspooler sendet. Eine Kopie des Spoolauftrages wird als Spoolrequest in der Tempse gespeichert. Sobald eine Instanz des R/3 Systems läuft wird mind. 1 Workprozess benötigt! Sie Aufgabe eines Workprozesses besteht darin :

 

-          Die R/3 Daten in gerätespezifischen Daten unzuwandeln

-          Druck

 

 

Lokales Drucken

 

Das R/3 System sendet eine Druckeranfrage , sowie eine Zugriffsanfrage zum Betriebssystem. Im Falle des lokalen Druckens  wird die Zugriffsmethode lokal Printing genutz. Lokales Drucken ist die schnellste, sicherste und zuverlässigste Drcukmethode. Lokales Drucken heißt das der Betriebssystemspooler lokal verfügbar ist, der physische Drucker kann woanders stehen.

Wenn beim R/3 System ein Ausgabegerät definiert wird, muß direkt eine Zugriffsmethode angegeben werden. Abhängig vom Betriebssystem nutzt R/3 folgende Methoden:

 

-          L Nutzung des lokalen Unix-Spoolers lp oder lpr

-          C Nutzung des Win-Spoolers mit Nutzung von WinNt API.

 

 

 

 

 

 

 

 

 

 

Remote Druck

 

Beim Remote Druck ist der Betriebssystemspooler auf einem anderen Host. Der Transfer wird über dem Netzwerk zum entsprechenden Host gesendet. Dort wird dann gedruckt sofern das entsprechen Programm (lpd line Printer Dämon/Unix SAPlD /Windows) läuft, bzw das entsprechende Druckprogramm (WIN) wird automatisch gestartet. Die Zugriffsmethoden lauten hier :

           

-          U   Remote Unix

-          S   Remote Windows

 

 

 

Aus Performance Gründen empfiehlt es sich die Remote Access Methode nur für Lans anzuwenden. Der Transaktionscode spad ist für die Spooladministration zuständig. Er ist in 3 Bereichen unterteilt:

 

-          Simple Administration

-          Erweiterte Administration

-          Volle Administration

 

 

Die Simple Administration wird genutzt für:

 

-          Erstellung und Einstellung der Ausgabegeräte

-          Administration  der Spoolserver ( Erstellung, Ändern, Löschen)

-          Auflisten der Zugriffsmethoden für Drucker

-          Auflisten der Host mit angeschlossenen Druckern

-          Beibehaltung der Spoolrequest ( Reorganisierung der Tempse und der Consistence der Spoolobjekte)

-          Ein Drucker wird mit Output-Request definiert

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Definitionsparameter von lokalen, Remote und Frontend Druckern

 

 

 

Parametername

Lokaler Drucker

Remote Drucker

Frontend Drucker

Output Device

Druckername der im R/3 System genutz werden soll

Short Name

Kurzname welchen das System im Spoolsystem nutzt, kann automatisch generiert werden.

Device Type

Drucker Type

Spoolserver

Applicationsserver welcher die Dateien umwandelt und zu den entsprechenden Druckern sendet

 

Spoolserver und Hostspooler müssen am selben Host sein.

 

 

Hostname

Wird automatisch vom System erzeugt

Hostprinter

Druckername auf Betriebssystem ebene ( Case-Sensitive)

Device Class

Art des Gerätes Drucker, Fax etc.

Access Methode

Art des Datentransfers zum Host

L Unix

C Windows

U Unix

S Windows

F Win / Unix

Destination Host

 

Name des Host zu dem die Daten gesendet wurden, wenn ein Name und keine IP eingetragen sind, muß sichergestellt sein das die IP-Auflösung im Netzwerk funktioniert.

 

Frontenddruck

 

Frontend Druck nutz die Access to Host Spool Methode F. Wenn der Frontend drucker ein WinPc ist, wird die Ausgabe direkt in das Programm SAPLPD gesendet, dieses wird bei Bedarf gestartet. Im falle eines Unix Frontend Druckers wird über dem Line Printer Daemon LPD gedruckt. Da bei Unix kein Standartdrucker exitiert, werden die Daten zum definierten Drucker gesendet. Beim Frontenddruck wird immer ein Dialogworkprozess belegt, der bis zum Druckende genutz wird, was zu performance Problemen führen kann.

 

R/3 Spoolserver

 

Logische Spoolserver stellen eine neue Schicht der Spool-Server-Architektur dar. Logische Spoolserver erledigen folgende Aufgaben:

           

-          Empfang von verschiedenen

-          Transportirbarkeit zwischen Systemen

-          Sicherheit gegenüber Abstürzen

-          Ausgleich zwischen reallen Spoll-Servern

 

Ein logischer Spoll-Server kann eine Abbildung eines reallen Spoolservers sein. Ein Realler Spoolserver ist ein R/3-Applicationsserver mit mind. 1 Spool Workprozess welcher den Output erzeugt. Ein logischer Spoolserver kann eine Instanz eines reallen Spoolservers sein.

 

Spoolserver Switch Over

 

Wenn ein Outputgerät einen Logischen Spollserver nutz kann dieser zwischen  reallen Spoolserver wechseln. So kann ein logischer Spoolserver sofort reagieren wenn ein realler Spoolserver ausfällt. Um dieses zuermöglichen müssen beide reallen Spool-Server am jeweiligen Host angeschlossen werden.

 

Definierung eines logischen Spoolservers:

 

Ein logischer Spoolserver wird mit dem Transaktionscode spad definiert:

 

-          Systemname

-          Logischer Name

 

-          Logischer Server

-          Hacken bei definition als Logischer Spoolserver

 

-          Mapping

-          Name des Servers der angemeldet wird.

 

Erweiterte Informationen wie Service Classes etc. sind im Basistraining BC505 zu finden.

 

Transportieren der Drucker Architektur

 

Logische Server unterstützen eine einfache Methode zum Transport komplexer Druckerstruckturen durch die Systemlandschaft. Im Regelfall werden die Drucker-strukturen im Qualitätssicherungesystem erstellt und werden dann, nach erfolgreichen Test, ins Produktivsystem überspielt. Danach müssen nur noch die Servernamen im Produktivsystem angepasst werden.

 

Managen der Spool-Antworten

 

Bei der Spooladministration gibt es in der Regel 2 Rechtestufen:

 

            End User

 

-          Kontrollle/Löschen der eigenen Spooljobs

-          Ändern der Attribute der eigenen Spooljobs

-          Drucken der eigenen Daten

 

            SpoolAdmin

                       

-          Löschen, Verändern, Kontrollieren aller Spooljobs

-          Test der Funktionen des Spoolers

-          Löschen veralterter Spoolaufträge

Die Transaktionscode sp01 zeigt alle Spoolaufträge inklusive der Spoolrequestnummer und des Erstellungsdatums an.

 

Spool-Request-List

 

Der Status jedes einzelnen Auftrages wird in der Spool-Request-Liste angezeigt. Für jeden nicht erfolgreich abgeschlossenen Auftrag wird eine Log-Datei angelegt, welche mit Doppelklick zu öffnen ist. Hier sollte mit der Fehleranalyse begonnen werden.

 

Löschen von alten Spool-Request

 

Spool-Request können auf 2 Arten gelöscht werden:

 

-          Transaktionscode spad

 

-          Hier ist es möglich in der Bildschirmansicht alle Spool-Request zu löschen. Aus Sicherheitsgründen ist die Löschfunktion nur auf den Client möglich auf welchem sapd gestartet wurde

 

 

-          Programm RSPO0041

 

-          Diese Programm wird als Hintergrundjob gestartet, nachdem eine Variante erstellt wurde. Das Programm erlaubt quer durch die Systemlandschaft Dateien zu löschen.  Es müssen folgende Parameter eingestellt werden:

 

-          Verfallsdatum

-          Minimale Lebensdauer in Tagen

-          Ziel Client

 

Consistents Check der Spool-Datenbank

 

Um die Consitens einer Datenbank zu testen nutzt man entweder den Transaktionscode spad oder man erstellt einen Periodischen Zeitplan mit dem Programm RSPO0041. Der Consistentcheck stellt sicher, das die Tabelleninhalte des Spool Request, des Output Request und der Output Daten sich untereinander consitent verhalten.

 

 

 

 

 

 

 

 

 

 

 

 

 

Fehleranalyse im Spooler:

 

 

 

 

Wenn ein Dokument nicht gedruckt wurde sollten folgende Tests durchgeführt werden.

 

-          Stimmt das Device-Format (z.B. Ausgabe als Postscript, Drucker kann kein Postscript)

-          Der Drucker ist falsch eingestellt z.b. durch fehlende Schriftarten und Formate

-          Transaktionscode sm21  erlaubt die Kontrolle der Syslogs

-          Transaktionscode sp01 ermöglicht die Anzeige der Qutput Request Logs

-          Transaktionscode st22 erlaubt die Kontrolle der Abap-Dump-Analyse

-          Transaktionscode sm50  erlaubt den Prozessüberblick und Anzeige der Prozess Trace Files

 

 

 

 

 

 

 

 

 

 

Spool und Druckauthorisation

 

Normale Benutzer  haben in der Regel immer volle Kontrolle über die von ihnen verschickten Spool-Aufträge. In den Authorisationsobjekten S_SPO_ACT und S_ADMIN_FCD erfolgt die Rechtevergabe in den folgenden Objekten:

 

Object

Feld

Mögliche Werte

Erklärung

S_SPO_ACT

(Spoolaktion)

SPOACTION

base

Anzeige der Spoolliste

prnt

Einmaliger Druck

repr

Druck wiederholung

redi

Umleiten

dele

Löschen

disp

Anzeige

auth

Wechsel der Berechtigungen

attr

Wechsel der Attribute

 

 

 

 

S_ADMI_FCD

(SystemBerechtigungen)

S_ADMI_FCD

sp01

Bearbeitung aller Clients

sp0r

Bearbeitung des eigenen Clients

spad

Spooladministration alle Client

spar

Client abhängige Spooladministration

spaa

Definition eines output Devices

spab

Definition der Reallen und Logischen Spooldevices

 

 

spac

Erhaltung der Devicetypen und deren Jobs

 

 

spam

Administration aller Spool Request (all Client)

 

 

sptd

Tempse Administration all Clients

 

 

sptr

Tempse Administration eigener Clients

 

 

 

Einstellung der Hardware Devices

 

 

 

Object

Feld

Mögliche Werte

Erklärung

S_SPO_DEV

(Geräte Auth.)

SPODEVICE

Value

Name des Ausgabegerätes

S_SPO_PAGE

(Max Anzahl Seiten)

SPOPAGE

Value

Anzahl erleubter Seiten

Zusammenfassung der gebrauchten Transaktionscode:

 

à Tools à CCMS à Spooladministration à (spad)

à SystemàServices àOutputcontrollerà (sp01)

à Tools à Administration à Monitor à DumpAnalyse à (st22)

à Tools à Administration à Monitor à Systemlog à (sm21)

à Tools à Administration à Monitor à DumpAnalyse à (st22)

 

 

 

Daten Archivierung

 

Nur Daten die in der Archivierungsbeschreibung stehen können Archiviert werden. Ein Archivobjekt beinhaltet folgende Hauptelemente:

 

-          Informationen über die zu Archivirenden Tabellendaten

-          Ein Programm welches die Daten auswählt und sie in das Archivefile schreibt

-          Ein Löschprogramm welches die Archivierten Daten mit den Daten in der Datenbank vergleicht und dann die Quelldaten löscht.

 

Der Transaktionscode sara ermöglicht die Datenarchivierung. Daten der Datenbank werden im regelfall um Faktor 5 verkleinert. Die Datenarchivierung kann paralell zum normalen arbeiten erfolgen. Die Performance wird nur leicht beeinträchtigt wenn sowohl ein User als auch dasArchivprogramm auf die selben Daten zugreifen. Wenn automatisches Löschen aktiviert ist, wird nach dem vergleichvorgang sofort gelöscht! Diese 2-Stufen-Sicherung garantiert ein höchstmaß an an Datansicherheit.

 

Archiv Developing Kit (ADK)

 

Das Archiv Developing Kit ist die Schnittstelle zwischen dem Archivierungsprogramm der Anwendung und den Archivdaten. Das Archivprogramm nutzt die Funktionalität des Archiv Developing Kit (in Form von Funktionsmodulen) um ins Archivdata zu schreiben. Das Archiv Developing Kit  kann die zu Archivierenden Daten auch in verschiedenen Dateien aufspalten. Sobald die SAP-Archiv-Schnittstelle zum Speichern der Archiv Daten genutz wird, transportiert das Archiv-Programm die Daten ins Archivlink Verzeichnis. Sollte ein Abap-Programm aufs Archivefile zugreifen, gewährleistet das Archiv Developing Kit das die Datenim richtigen Format zurückgeschrieben werden. Diese Funktion ist unabhängig von der verwendeten Hardware. Mit dem Archiv Developing Kit  können eigene Archivobjekte erstellt und genutz werden. Akd sollte nur benutzt werden um eigen erstellte Daten (Tabellen etc.) zu archivieren, es sollte nicht genutzt werden um Sap eigene Daten zu Archivieren.

 

Zugriff auf Archivdaten

 

-          In der Regel haben alle Archivprogramme ein eigenes Analysetool zum lesen und kontrollieren der Archivdaten

-          Bei einigen Archivprogramme ist es möglich eine simultane Analyse zwischen den Datenbankdaten und den Archivierten Daten durchzuführen. Alle Programme beziehen ihre Daten von der logischen Datenbank brf, und kann im automatischen Zugriff die Daten vergleichen. Dafür ist keine spezielle Software notwendig.

 

Auf folgenden Daten kann direkt zugriff genommen werden:

 

-          FI-Dokumente                 beschränkt auf €-Umstellung

-          SD Documente              laden vom Modul SD im System bis 4.0 wird nicht mehr supported

 

 

Vorbereitung zur Datenarchivierung

 

Die Archivierung kann aus 2 verschiedenen Blickwinkel gesehen werden

           

-          Blickwinkel der Application

-          Nach einer bestimmten Zeit werden Daten nicht mehr dringend benötigt

-          Für den SYS / Datenbank – Administrator wird eine Datenarchivierung nötig um das Regelbackup schneller erledigen zu können. Vor der Datenbank aktivierung sollten alle verfügbare Dokumentationen durchgearbeitet werden:

 

-          Online Dokumentation

-          Informationen der Transaktionscode SARA, speziell für die einzelnen Objekte

-          OSS-Hinweis für die Applicationen BC-CCM-ADK BC-SRV-ARC

-          Um die Tabellengrößen erfassen zu können, können alle Tabellen definitionen und größen in dem Transaktionscode db15 geschaut werden.

 

 

Einstellung zur Definition der Archiveobjekte:

 

-          Zeitangabe wann Archivierungsdaten aus der Datenbank gelöscht werden

-          Größe des zu schreibenden Archivafiles

-          Nummer der Datentabellen in jedem File

-          Start des Löschprogramms automatisch/manuell

-          Test und Produktiv varianten

-          Wenn das Löschprogramm automatisch läuft müssen dafür 2 Workporzesse reserviert werden.

-          Das Schreibprogramm muß auf dem Datenbankserver laufen

 

 

Ein Archivejob ist erst vollständig erledigt, wenn das Löschprogramm die Daten aus der Datenbank gelöscht hat. Zur erstellung der logischen Filenamen und –wege nutzt man den Transaktionscode sf01. Zum wieviel freier Festplattenplatzes zur Archivierung zur Verfügung steht, startet man den Test ohne schreibfunktion in einer Datenbank.

 

 

 

Schritte der Datenarchivierung

 

Eine Archivierung sollte entweder vom Admin in Absprache mit der für die Datenverantwortlichen Person oder von den entsprechenden Abteilungen selber erfolgen, welche dann mit den entsprechenden Rechten ausgestattet sein müssen.

 

Für jeden Durchlauf muss eine Programmvariante vorhanden sein, die unter anderen definiert welche Daten archiviert werden. Abhängig vom Archivobjekt müssen bestimmte Parameter beachtet werden.

 

Kontrolle des Archivvorganges

 

-    sm37 Kontrolle der Hintergrundprozesse ( Kontrolle der Grundeinstellungen)

-          Der Managmentdesktop des Transaktionscode sara zeigt grössen und path angaben und anzahl der Files an.

 

Fehler bei der Ausführung der Archvierung

 

Es gibt drei Arten von Aussagen des Archiv-vorganges:

 

-          Alle Daten wurden erfolgreich Archiviert

-          Datenarchivierung brach vor löschen der Datenbankdateien ab

-          Löschjobs wurden nur teilweise ausgeführt

 

Bei aufgetretenen Fehlern sollten empfielt sich folgende behandlung:

 

-          Wenn ein Archivfile nicht ganz geschrieben werden konnte, sollte von dem geschriebenen eine Sicherheitskopie erstellt werden, und dann sollte es gelöscht werden und die Aktion kann neu gestartet werden.

-          Sollte alle Dateien geschrieben worden sein, der Löschjob aber nicht gelaufen ist, sollte dieser manuell gestartet werden.

-          Sollte der Schreibvorgang abgebrochen sein und der Löschjob zum manuellen Start konfiguriert sein, löscht man die Archivdaten und startet den Vorgang neu.

 

Berechtigungen

 

           

-          Das Objekt S_ARCHV ist die Hauptberechtigung des Systems für die Datenarchivierung. Im S_Archiv wird exakt definiert welche Optionen zur Datanarchivierung erlaubt sind. Zum Sicherstellen das ein maximunm der Daten archviert wird, benötigt der Archviere die entsprrechenden rechte. In der Dokumentation der Archivprogrammes sind die entscheidenen Objekt Namen erläutert. Da Datenarchvirung als Hintergrundjob läuft, ist auch die Berechtigung zur erstellen von Hinergrundjobs erforderlich.

 

 

 

 

 

 

Systemkontrolle

 

Alle Komponenten eines R/3 Systems, sowohl Hard- als auch Software müssen regelmäßig auf ihre funktionstüchtigkeit überprüft werden. Hauptziele der Überwachung:

           

-          Das System vor stillstand bewahren

-          Analysieren und verbessern von Fehlern

-          Zum überprüfen der Performance bietet das R/3 System erweiterte Möglichkeiten

-          Systemkontrollen können von verschieden Personen gemacht werden, solange sie in ihrem Bereich die entsprechenden Berechtigungen besitzen

-          R/3 Systemadministratoren sind für die Sicherstellung der R/3 Performance zuständig.

-          Datenbankadministratoren sind für die Konsitenz der Datenbank, sowie für deren Wiederherstellung bei Datenverlust oder Dateninkonsitens verantwortlich

-          Betriebssystemadministratoren überwachen die physiche verfügbarkeit der Hardware

-          R/3-Systemkontrollen sollten täglich durchgeführt werden.

 

Kontrollkonzepte

 

Ab Release 4.0 werden alle Objekte zur Kontrolle der Systemleistung in einer Baumstruktur erfasst. Jede Komponente wird von einem Monitorobjekt gezeigt. Die Objekte haben unterschiedliche Attribute. Man nutz diese Informationen zum Anzeigen des aktuellen Status sowie zur Controlle der History und evntl. Systemalarme. In der Gesamtansicht des Systems ist es möglich Kontrollobjekte zu definieren sowie bestimmte Alarmmeldungen zu definieren und diese dann z.b. als Email zu versenden. Im folgenden Releases wird die Monitor Infrastruktur auch eine Überwachung der Transportdomaine ermöglichen. Da die Monitorstruktur in C Implementiert ist, und deren Schnittstellendefinition veröffentlicht ist, ist es problemlos möglich extern erstellte Monitortools hinzuzufügen.

 

 

 

 

Vorbereiten der Monitoreinstellungen

 

Für jede Klasse der Monitorbaumstruktur können die folgenden Einstellungen vorgenommen werden:

 

-          Beschreibung

-          Wahl der Sichtweise (Operator/Normal)

-          Priorität der Alarmmeldungen

 

 

 

 

 

Diese Einstellungen müssen für alle MTE’S (Objekte) einer klasse identisch sein, damit sie zusammen gefasst werden können. Es können mit den folgenden Einstellungen Gruppen zusammen gefasst werden:

           

-          Schwellgrenze

-          Erstellmodus (z.b. Einstellung zum Ändern der Schwellwertes)

-          Alarmtext (wenn gewünscht)

 

Nachdem konfigurieren der Systemalarmmeldungen können Tools dem MTE hinzugefügt werden. Diese Tools sammeln Daten, die nicht direkt zum R/3-System gehören, und Melden wenn es zu Porblemen kommt. Die Aufgaben der Zusatztools werden entsprechend definiert:

                       

-          Am MTE Class Level

 

-          Beim definieren der Tool fürs MTE muss Sichergestellt sein, das sie zur gleicehn MTE-Klasse gehören

-          Standartmäßig vererben sich Klassen. Der Vererben spart einen Großteil des der arbeit beim definieren von neuen Jobs in der Systemumgebung. Diese Funktion kann abgeschaltet werden.

 

-          Für einzelne MTE

 

-          Zum hinzufügen von neuen Tools müssen einstellungen der alten Klasse geändert werden.

 

Vorgang um Tools hinzuzufügen

 

Tools sind in der Regel vordefiniert. Zum Hinzufügen von neuen Tools müssen die folgenden Parameter gesetzt werden:

 

-          Typ des Tools

-          Report

-          Funktionsmodul

-          Transaktion

-          Logisches Commando

-          Etc

 

-          Start Ort

-          Auf welchen Servern das entsprechende Tool laufen soll

 

-          Betriebsart

-          Zum Beispiel ob das Tool im Hintergrund laufen soll, oder ob es manuell gestartet wird

 

-          Freigabe des Tools zum

 

-          Das heißst zum Beispiel, das die selbe Transaktion in verschiedenen Task angezeigt werden kann.

 

-          Auftrag des Tools

 

-          Hier wird das Tool verzeichnis gezeigt und festgelegt ob es sich um ein single MTE oder um den Teil einer klasse Handelt

 

Es ist auch möglich keine Tools dem MTE hinzuzufügen. Die von der Sap vorgefertigetn Tools nutzen das CCMS als Namensvorzeichen, Kundenprogramme sollten mit Y/Z anfangen.

Im Systemmonitor ist es auch möglich verschiedene Ansichten zu speichern, sodaß dann jeder nur den Berecih zu sehen bekommt der für ihn wichtig ist. Jeder Monitor gehört zur Monitorsammluing für die er kreirrt ist. Technisch gesehen ist ein neuer Monitor als Klasse anzusehen. Um einen neuen Monitor zuerstellen wählt man die entsprechenden MTE‘s aus  und speichert sie als neuen Baum. Alle einstellungen und hinzugefügten Tools werden mitkopiert. Genauso kann die Sichtweise und Tiefe definiert werden, da z.b. Entwickler und Administratoren andere Informationen des Systems erhalten müssen.

 

R/3 System Log

 

Im Alarmmonitor wird jeder Applicationsserver sepperat angezeigt. Sie haben alle die gleiche Struktur und unterscheiden sich maximal in den folgenden Punkten:

 

-          Betriebssystem

-          Datenbank

-          R/3 Service/Workprozess

-          R/3 Basissystem

-          R/3 AbAp

-          R/3 Systemlogs und wichtige Nachrichten die gespeichert werden.

 

 

Details des R/3 Systemlogs

 

Die Systemloginformationen werden in folgenden Kategorien unterteilt.

 

-                S         à        Start und Stop des Systems und der Workprozesse

à                Betriebsartwechsel

-               W        à         Rollbackgeschwindigkeit

-               K          à        Kernellprogramm fehler

-               T          à        Abap-programm fehler welche in Kurzdumps zusammen

gefasst sind

à                Die Informationen zeigen folgendes an :

-          Zeitstempel

-          Client

-          User

-          Transaktionscode

-          Kurztext

-          Zusätzlich werden noch der Workprozess mit der Fehlermeldung gespeichert.

 

Das R/3 Systemlog muß beim WinNt-System  separat für jeden Applicationsserver angezeigt werden. Eine zusammenfassung der Systemlogs ist nur in Unix-systemen möglich.

 

 

Kontrolle des R/3 Servers

 

Der Transaktionscode sm51 erlaubt einen Überblick aller vorhandenen Server. Diese Transaktion kann genutzt werden zur:

 

-          Untersuchung der Prozesse aller eingelogten Server

-          Anzeige

-          Sys-Log

-          aller System User

-          R/3 Version

-          R/3 Kernellversion

-          Datenbankversion

-          Betriebssystemversion

-           Betriebssystemdateien

-          Dynamischen Wechsel zu anderen Servern

-          Freigabeberichte und Transaktionsanzeige

 

 

Anzeige R/3 Workprozesse

 

Transaktionscode sm50 und sm66 erlaubt einen Überblick über den Workprozess am Applicationsserver, von welchem man gerade eingeloggt ist, oder des gesamten R/3 Systems. Auf diesen Bildschirmen wird angezeigt :

           

-          Type des Workprozesses

-          Sein Status

-          Zeit Verbrauch

-          Aktueller User

-          Client

 

Mit dem Transaktionscode sm04/al08 ist ein überblick über alle User möglich, die am System angemeldet sind.

 

Update Tabellen Prozess

 

Sperrmechanismen können auf relativinen Datenbanksystemen nicht für komplizierte Geschäftsobjekte, wie zum Beispiel Lieferrantenbestätigungen über meheren Tabellen, angewendet werden.

Der Enqeue-prozess koordiniert den Paralellen Zugriff auf die Workprozesse. Die Sperranfragen werden von den Enqeue-Workprozessen in einer Sperrtabelle gespeichert. Diese Tabelle ist permanet im Hauptspeicher des entsprechenden Servers verfügbar. Sobald eine Sperre erwünscht ist, wird die Sperrtabelle getestet ob dort schon entsprechende Sperren vorhanden sind. Sollte entsprechende Sperren vorhanden sein, wird der User darüber informiert und die anfrage abgelehnt. Der Messageserver sorgt für die Kommunikation wenn der Enqeue-Server und der Dialogserver nicht auf dem selben System vorhanden sind. Es gibt 2 Modies für Lockobjekte :

 

-          S   Shared                       // Leserecht

-          E   Exclusiv                     // Schreibrecht         

 

Ein Update im R/3 System ist immer Asynchron, das heißst Informationen werden immer in mehren Tabellen geschrieben. Das Tabellenupdate erfolgt immer erst wenn die Transaktion beendet ist. Es wird dabei unterschieden zwischen V! und V2 Transaktionen. V1 Transaktionen sind immer zeitkritisch, wobei V2 Verbuchungen meist der Statistischen erhebeung dienen und deshalb keine große Priorität geniessen.

Ein Tabellenupdate wird am ende einer Transaktion durch den internen Befehl Commit Work nötig. Standartmäßig wird das nach jeder Transaktion ausgelöst, es ist aber auch möglich ein update vorher ausführen zu lassen.

 

Ablauf eines Updates:

 

-          Tabelle wird gesperrt

-          Der Updateprozess liest die Daten der entsprechenden Tabellen ein, und führt die entsprechenden veränderungen in den Tabellen ducrh.

-          Wenn das Update funktioniert hat werden die Einträge in die Datenbank zurückgeschrieben und der Sperrsatz der wird in der Sperrtabelle gelöscht.

 

Sollte ein Fehler passiert sein und die Einträge, und die Einträge in der Sperrtabellegelöscht worden sein ohne das das Tabellenupdate durchgeführt wurde, wird der User per Expressmail informiert.

Das Asynchrone Update ist Implementiert mit dem Abap Schlüsselwort in Update Task. Es ist möglich ein Synchrones Update durchzuführen, mit dem Abap-Zusatz for Spezial Cases Only.

 

 

Kontrolle der R/3 Sperren

 

Kontrolle der aktuellen Datenbanksperren sind mit dem Transaktionscode sm12 möglich. Hier werden folgende Informationen angezeigt:

 

-          Der User der die Sperre verursacht hat

-          Der Client des Users

-          Die gesperrte Tabelle

-          Das Sperrargumen

 

Hier kann auch eine sperre gelöscht werden, was bei unvorsichtiger Nutzung zu Datenbak inkonsistenz führen kann. Vorm löschen sollten folgende Punkte beachtet werden: