SAP Systemkopien gehören inzwischen zu dem fast alltäglichen Arbeiten einen SAP Basis Mitarbeiters. Inzwischen hat man dafür auch im Normalfall Skripte geschrieben, so dass der Ablauf bis auf einige manuelle Arbeiten weitest gehend automatisch abläuft.

Transaktion secstore, Quellsystemanbindungen etc. gehören zu den wenigen Tätigkeiten, noch manuell durchgeführt werden müssen.

Ein wenig ändert sich das nun wieder, wenn das SAP ChaRM zur Transportsteuerung eingesetzt wird.

Dadurch werden einige Schritte mehr bei den manuellen Vor- und Nacharbeiten notwendig. Diese habe ich in einem HowTo zusammengefasst:

Howto Systemkopie mit ChaRM unter Nutzung eines virtuellen Systems

Wenn man sich mit der Einführung des Change Request Management mit dem SAP Solution Manager beschäftigt, kommt man sehr schnell dazu, die Eingabemasken für die Korrekturen anzupassen. Wie das geht, möchte ich in einem kleinen HowTo exemplarisch darstellen.

Dabei geht es in dem Beispiel darum, einige der Felder für die dringende Korrektur im ChaRM (Transaktion CRMD_ORDER) als Pflichtfelder zu definieren.

Das Customizing erfolgt über die Transaktion SHD0, der Transaktion zum Anlegen und Ändern von Transaktions- und Screenvarianten.

Das HowTo kann man hier finden:

HowTo_CRMD_ORDER

Beim Einspielen von SAP Support Packages bricht die SPAM ab oder der Client verliert die Verbindung zum SAP System.

Das Fehlerbild ist dann abhängig davon, in welcher Phase dies geschehen ist. Mir ist es gerade im Main Import passiert.

Meldet man sich nun wieder am SAP System an, wird man von einer Vielzahl Dumps freundlich begrüßt

Ein Aufruf der SPAM führt ebenfalls zu Dumps (Laufzeitfehler: SYNTAX_ERROR).

Das SLOG (usr/sap/trans/log/SLOG.SID) sah so aus:

STOP MAIN IMPORT <SID> I 20110915141958 SAPUSER <HOST> 20110915123207347

ERROR: stopping on error 12 during MAIN IMPORT

HALT 20110915141958

ERROR: uncaught internal error: ORA-03114: not connected to ORACLE

ERROR: EXIT(16) -> process ID is: 18929

STOP imp all <SID> 0016 20110915141958 SAPUSER <HOST> 20110915123207347

START MAIN IMPORT <SID> I 20110915144329 <SID>adm <HOST> 20110915144329001bdd

START MAIN IMPORT <SID> I 20110915144355 <SID>adm <HOST> 20110915144355001c4a

ERROR SAPKB70207 <SID> I 0012 20110915144630 SAPUSER <SID>adm <HOST> 20110915144355001c4a

STOP MAIN IMPORT <SID> I 20110915144632 <SID>adm <HOST> 20110915144355001c4a

ERROR: stopping on error 12 during MAIN IMPORT

In diesem Fall muss man das Einspielen der Support Packages von Hand über das Betriebssystem vornehmen:

tp R3I all <SID> pf=/usr/sap/trans/bin/TP_DOMAIN_<SID>.PFL tag=spam -Dclientcascade=yes -Dstoponerror=8 -Drepeatonerror=8 -Dsourcesystems= -Dtransdir=/usr/sap/trans

Mit diesem Befehl wird dann die komplette Queue neu importiert.

Bricht der Befehl ab, sollte man ihn zuerst noch einmal wiederholen.

Anschließend kann man die SPAM wieder aufrufen und die Nacharbeiten des Imports ausführen lassen, in dem man die Queue dort wieder einspielt.

Ist der Abbruch nur bei einem Paket passiert, kann man sich auch erst den Buffer anzeigen lassen:

tp showbuffer <SID> pf=/usr/sap/trans/bin/TP_DOMAIN_SCD.PFL tag=spam

und anschließend eben jenes Packet von Hand einspielen:
tp R3I SAPKB70207 <SID> pf=/usr/sap/trans/bin/TP_DOMAIN_<SID>.PFL tag=spam –Dclientcascade=yes -Dstoponerror=8 -Drepeatonerror=8 -Dsourcesystems= -Dtransdir=/usr/sap/trans

Für ein SAP NetWeaver Portal soll SSO eingerichtet werden. Die Userverwaltung (UME) ist dabei an einen ABAP Stack angebunden.

Auf Basis des SPNEGO CONFIGURATION GUIDE der SAP wurde SPNEGO konfiguriert.

Dabei ist zu beachten, dass es ab Netweaver 7.01 SP8 ein neueres SPNEGO-Modul gibt
(https://service.sap.com/sap/support/notes/1457499 ).
Nach dem Deployen des neuen Login Modul gab es folgenden Fehler:

Could not validate SPNEGO token. [EXCEPTION]
java.lang.Exception: Checksum error
at com.sap.security.spnego.krb5.crypto.DesCrypto.decrypt (DesCrypto.java:43)
at com.sap.security.spnego.krb5.KrbEncryptedData.decrypt (KrbEncryptedData.java:81)
at com.sap.security.spnego.krb5.KrbApReq.decrypt(KrbApReq.java:67)
at com.sap.security.spnego.SPNEGOLoginModule.parseAndValidateSPNEGOToken(SPNEGOLoginModule.java:234)
at com.sap.security.spnego.SPNEGOLoginModule.processAuthorizationHeader (SPNEGOLoginModule.java:385)
at com.sap.security.spnego.SPNEGOLoginModule.login (SPNEGOLoginModule.java:102)

…

Dieser Fehler taucht auf Grund eines ungültigen Keytab Files auf. Dieses kann man dann nach dem SAP Hinweis 1568553 neu anlegen.

Wichtig ist noch, dass die Einstellung für das SPNEGO Modul im Visual Admin ( unter ticket authentication) richtig vorgenommen wurde:

Visual Admin – Server – Services – Security Provider

“ticket component”

” SPNEGOLoginModule” muss auf REQUISITE und nicht auf SUFFICIENT eingestellt sein.

Immer wieder steht man vor dem Problem, dass das CCMS Monitoring im TREX Umfeld (inklusive dem BWA) nicht genügend Informationen liefert.

Und dann macht man sich auf die Suche nach guten Alternativen. Und dafür sind meistens schon alle benötigten Komponenten in der SAP Landschaft vorhanden, um eine gute Basis für ein vernünftiges Monitoring aufzubauen.

Im verlinkten HowTo zeige ich, wie man mit dem SAP Solution Manager und den entsprechenden Agenten und Tools, im Handumdrehen ein effektives Monitoring für den TREX aufbaut.

HowTo TREX Monitoring mit SAP Solution Manager Diagnostics

Der Adobe Document Service wird im Normalfall mit dem Java WAS mitinstalliert. Für die Konfiguration sind noch einige Schritte zu beachten, diese habe ich in einem HowTo zusammengetragen. dieses findet man hier:

http://blog.mindsquare.de/timm_funke/files/2011/04/How-to_ADS.pdf

Dabei handelt es sich um folgende Systemumgebung:

Adobe Document Services (ADS) ist auf einem JAVA WAS installiert.

Angeschlossen wird der Service an ein SAP ERP System und zwar ohne Verschlüsselung (SSL).

Nach einer Systemkopie werden die URLs für Web Dynpro Anwendungen nicht mehr korrekt generiert.

So wie hier zum Beispiel in der se80 zu sehen:

Zuerst kann man dann die Parameter SAPLOCALHOSTFULL bzw. icm/host_name_full überprüfen. Sind diese gar nicht gesetzt, bleibt noch die Tabelle httpurlloc.

In dem vorliegenden Fall war hier noch das Quellsystem der Systemkopie eingetragen, richtig sieht der Eintrag dann so aus:

Wobei der Eintrag als FQN vorgenommen werden muss.
Siehe auch https://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?numm=805344

Anbei eine Übersicht über die wichtigen Transaktionen für den Betrieb einer Oracle Datenbank unter SAP

Es sind die “alten” Transaktionen angegeben, in neuen Releasen muss teilweise noch ein “old” ergänzt werden, da der Aufruf sonst zum DBACOCKPIT führt (z.B. DB02OLD).

sapevent bekommt keine Verbindung zum SAP System 
Der Upgrade eines BW 70 auf EHP1 ist in den Phasen TABIM_UPG und XPRAS_UPG stehen geblieben.

Leider wurde im Installationstool (hier EHPI) kein Fehler angezeigt, aber die entsprechenden Phasen sind nicht zum Ende gekommen.

Das Programm sapevent versucht über RFC einen Batchjob im SAP(Schatteninstanz) zu starten, dies bricht jedoch mit der Fehlermeldung ab:

received 4 bytes from MSG_SERVER Received opcode MS_DUMP_INFO from msg_server, reply MSOP_ACCESS_DENIED
MsOpReceiveReceived opcode MS_DUMP_INFO failed, reason MSOP_ACCESS_DENIED
MsDump : failed MSOP_ACCESS_DENIED (5)
*** ERROR ***: Get message server parameters, rc = 5″

Dann warte der Upgrade Prozess einige Zeit und versucht es erneut und so weiter und so weiter…

Die Fehlermeldung findet man in der Datei dev_evt im tmp Verzeichnis der Installation, bzw. man kann das sapevent Tool auch manuell mit der Option -t starten, dann wird die Trace Datei im aktuellen Verzeichnis erstellt.

Zu dem Fehler kommt es, weil der sapevent die Profildatei DEFAULT.PFL zur Ermittlung des Ports für den Message Server liest.
In meinem aktuellen Fall wird dieser Port aber durch einen Eintrag im Instanzen Profil überschrieben (rdisp/msserv_internal).
Das heißt, das SAP System laust auf “rdisp/msserv_internal” und sapevent spricht den Message Server Port aus dem Default Profil an und kann so keinen Connect zu dem SAP System bekommen.
Zur Lösung habe ich den Parameter im DEFAULT Profil korrigiert.

Ab und zu kommt es ja doch einmal vor, dass unsere geliebte J2EE Engine nicht mehr starten möchte. Habe ich zumindest mal gehört Und gerade habe ich im Internet einen zwar nicht mehr ganz neuen, aber irgendwie immer noch aktuellen Guide zum Vorgehen zur Analyse von eben diesen Problemen gefunden. Lege ich mal hier ab.