SAP System-Analyse
ABAP Code Security – SAP Code Vulnerability Analyzer / Virtual Forge CodeProfiler for ABAP
Im 1st-Level-Support wird eine Anfrage angenommen. Bekannte Fehler werden entweder direkt beantwortet und gelöst oder qualifiziert und an den zuständigen 2nd-Level-Support weitergeleitet (z. B. HW-Technik, SAP-Basis oder SAP-Anwendung). Dieser führt eine erweiterte Analyse durch und kann entweder die Lösung selbst bereitstellen oder leitet es an den 3rd-Level-Support weiter. Hier wird es dann von Spezialisten mit tiefen Kenntnissen der Lösungsarchitektur bearbeitet. Mit ihren speziellen Werkzeugen kommen sie den Fehlern in technischen Komponenten oder im Softwareprodukt auf die Spur. Dieses Supportlevel wird oft als Hersteller- oder Entwicklersupport bezeichnet.
Als Eingaben für das durchsatzbasierte Sizing dienen Angaben über das sogenannte Mengengerüst. Dies sind Angaben über die Anzahl der Geschäftsprozesse, die in bestimmten Zeitfenstern bearbeitet werden sollen. Dies können z. B. Angaben über die Anzahl von Kundenaufträgen, Lieferungen und Produktionsaufträgen oder gedruckte Dokumente sein. Dieser Ansatz hat den Vorteil, dass auch die Datenübernahme in Hintergrundprozessen (z. B. durch Batch-Input oder Application Link Enabling, ALE), die tageszeitliche Verteilung des Belegdurchsatzes und ein Sizing für Spitzenlastzeiten berücksichtigt werden. Der durchsatzbasierte Ansatz muss zwingend immer dann gewählt werden, wenn eine maßgebliche Last durch Hintergrundprozesse oder Schnittstellen erfolgt. Beispiele dafür sind SAP-for-Retail-Lösungen (Übernahme von Verkaufsdaten im Point-of-Sales Inbound-Processing) oder Banking-, Utilities- oder Telekommunikationslösungen. In der Praxis wird normalerweise eine Kombination beider Formen des Sizings gewählt. Beim durchsatzbasierten Sizing wird im Quick Sizer mit einer CPU-Zielauslastung von 65 % gerechnet.
SM58 Transaktionaler RFC
Eine automatische Fehlerbehandlung bei Abbruch eines Jobs ist in den meisten Fällen wünschenswert und sinnvoll. Die bewusste Verarbeitung und Berücksichtigung von Fehlersituationen in Jobketten – auch auf Stepebene – kann den manuellen Aufwand verringern helfen. Fehlersituationen sollten abfangbar sein: Handelt es sich um nicht kritische Elemente, kann der folgende Job vielleicht trotzdem gestartet werden. Bei kritischen Fehlern soll ein neuer Versuch unternommen werden oder eine Alarmierung erfolgen, damit ein Administrator manuell eingreifen kann. Hierzu sind einfache Batch-Jobs in der Regel nicht in der Lage. Ziel einer automatisierten Umgebung ist es, nicht auf jeden fehlerhaften Job manuell reagieren zu müssen.
Legen Sie zunächst die Anzahl der Rechner fest. Dies wird in der Regel in Zusammenarbeit mit Ihrem Hardwarepartner geschehen, denn die Entscheidung, auf wie viele Rechner Ihr SAP-System verteilt werden soll, hängt wesentlich von der gewählten Hardwareplattform ab.
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Der Memory Inspector ist insbesondere dann hilfreich, wenn Benutzer Transaktionen lange verwenden, wie dies z. B. in einem Customer Interaction Center der Fall ist.
Für die Verteilung der Applikationsebene auf Instanzen gilt also die Regel, dass so viele Instanzen wie nötig, aber so wenige wie möglich installiert werden sollten.