Online, Offline, Delta Backups
/IWFND/TRACES SAP-Gateway-Traces
Sie wollten eilig einen Transportauftrag im Qualitätssicherungssystem Ihrer SAP-Landschaft freigeben und haben dabei versehentlich auf "Ablehnen" anstatt "Genehmigen" geklickt? Nun lässt sich der Auftrag nicht weiter transportieren und wird bald per Job aus der Queue bereinigt? Nicht verzweifeln: In diesem Blog-Beitrag schildere ich Ihnen eine einfache Methode, wie Sie abgelehnte Transportaufträge trotzdem in das Produktivsystem transportieren können. Als Leser unseres Blogs interessieren Sie sich sicher für Tricks und Kniffe, die Ihnen die Handhabe Ihres SAP-Systems erleichtern. Vielleicht kennen Sie die Situation, dass Sie nach erfolgter Prüfung einen Transportauftrag schnell genehmigen wollen und sich bei der Freigabe im System verklickt haben. Problem ist nun, dass der Transportauftrag im System nun den Status "abgelehnt" innehat und daher nicht mehr transportiert werden kann. Insgesamt erhält ein Transportauftrag unter Umständen wichtige Änderungen, die Sie gerne ins Produktivsystem transportiert hätten. Vorgehensweise um abgelehnte Transportaufträge freizugeben Der nachfolgende Screenshot zeigt die Situation in der Transaktion STMS, bei der ein Transportauftrag im Qualitätssicherungsbereich ablehnt wurde. Somit ist ein Import in das Produktivsystem nicht mehr möglich. Der Transportauftrag kann entweder manuell oder durch einen Job entfernt werden. Die Frage an dieser Stelle ist jedoch, wie die Änderungen, die fälschlicherweise abgelehnt wurden, in das nachfolgende System transportiert werden können. Ablehnter Transportauftrag Tipp: Lassen Sie den Status auf "abgelehnt" stehen, entfernen sie ggf den abgelehnten Transportauftrag aus der Importqueue und befolgen Sie die nächsten Schritte. Wechseln sie in Ihrem Qualitätssicherungssystem auf die Importqueue. Gehen Sie dort über Zusätze -> Weitere Aufträge -> Anhängen zum modalen Fenster, in dem Sie weitere Schritte durchführen können.
Diese Variante bietet sich an, wenn mehrere Transaktionen gleichzeitig auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin geprüft werden sollen. Bei dieser Variante müssen zunächst sämtliche Rollen ermittelt werden, die dem betreffenden Nutzer bereits zugeordnet wurden. Dies erfolgt in der Transaktion SE16N über Eingabe der Tabelle AGR_USERS. Außerdem lässt sich in diesem Bild die Begrenzung der maximalen Trefferzahl aufheben. Hier muss nun der betreffende Nutzer eingetragen werden. Außerdem sollte die Ausgabe lediglich auf die Rollen beschränkt werden. Nach dem Ausführen der Anfrage werden nun sämtliche Rollen, die dem vorher eingegebenen Nutzer zugeordnet sind, angezeigt. Diese werden nun komplett markiert und kopiert. Anschließend wird in der Transaktion SE16N wieder ein Schritt zurück gegangen und diesmal die Tabelle AGR_1251 gewählt. Hier werden nun sämtliche Rollen, die zuvor kopiert wurden, eingefügt. Zusätzlich wird nach dem Objekt S_TCODE und den Transaktionen, nach deren Zuordnung gesucht werden soll, gefiltert. Achtung: Bei der Eingabe der Transaktionscodes ist auf Groß- und Kleinschreibung zu achten! An dieser Stelle kann außerdem die Ausgabe auf die Rollen und Objektwerte (das sind in diesem Fall die Transaktionen) beschränkt werden. Nach dem Ausführen der Anfrage werden von den eingegebenen Transaktionen nun diejenigen angezeigt, die der Nutzer bereits ausführen kann. Zusätzlich ist ersichtlich, durch welche Rolle die Transaktion zugeordnet wurde. Abschließend ist festzustellen, dass sich die SUIM zur Ermittlung bestimmter Transaktionen mit Nutzerzuordnung nur bedingt eignet. Zwar lässt die Suche über das Berechtigungsobjekt S_TCODE auch die Betrachtung mehrerer Transaktionen zu. Da im Ergebnis allerdings die Zuordnung von betrachteten Transaktionen zu Rollen fehlt, lässt sich die Transaktion SUIM nur dafür sinnvoll nutzen, eine einzige Transaktion auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin zu überprüfen.
WLF_IDOC IDoc-Monitor
Die Anzahl der Sätze, die maximal in einer FETCH-Operation übertragen werden können, wird von der SAP-Datenbankschnittstelle wie folgt ermittelt: Jeder SAP-Workprozess verfügt über einen Eingabe-/Ausgabepuffer für die Übertragung der Daten von der bzw. zur Datenbank. Der SAP-Profilparameter dbs/io_buf_size legt die Größe dieses Puffers fest. Die Anzahl der Sätze, die mit einem Fetch von der Datenbank geholt werden, berechnet sich wie folgt: Anzahl der Sätze = dbs/io_buf_size ÷ Länge eines zu lesenden Satzes in Byte.
Ergänzend ist für alle o. g. Managed Services zu sagen, dass die Supportlevel und deren Umfang meist kundenindividuell festgelegt werden, je nachdem welchen Grad an Mitwirkung sich der Kunde wünscht. Üblich ist eine Einteilung von Supportlevel 1-3 (gelegentlich werden auch 4 genannt).
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Vereinbaren Sie, dass bei Überschreitung des festgelegten Schwellenwertes eine Analyse von allen an der Transaktion beteiligten Personen durchgeführt werden soll.
Das Verständnis für die Struktur und Funktionsweise des Systems ist insbesondere für die IT-Administration wichtig. Nicht umsonst ist „SAP Basis Administrator“ ein eigenes Berufsfeld. Auf der Seite www.sap-corner.de finden Sie nützliche Informationen zu diesem Thema.
Weitere Informationen finden Sie in der SLOGProtokolldatei im Verzeichnis /usr/sap/trans/log (UNIX).