<![CDATA[Blog]]> https://sap-basis.x10.bz/blog/ DE Wed, 15 Jun 2022 06:07:00 -0400 Incomedia WebSite X5 Evo <![CDATA[ABAP DOC - mit wenig Aufwand Klassen und Methoden dokumentieren]]> imblog Die Einschätzung, wie die Dokumentation eines Programms aussehen sollte, unterlag im Laufe der Zeit immer wieder Schwankungen. Früher galt eine detaillierte (und dadurch auch oft erschlagende) Dokumentation als das Maß der Dinge. Mit "Clean Code" hat sich die Ansicht darüber geändert - anstatt Aufwand in die Dokumentation zu stecken, sollte der Aufwand lieber in den Code gesteckt werden, so dass er leicht verständlich und selbsterklärend ist und dadurch keine ausführliche Dokumentation benötigt - was allerdings nicht heißen soll, dass gar keine Dokumentation mehr erstellt werden sollte.

Ein gewisses Maß an Programmdokumentation ist natürlich nach wie vor sinnvoll - wer mag schon vor einer neuen Bibliothek mit Klassen und deren Methoden stehen, ohne auch nur ein bisschen greifbare Dokumentation zu haben?

Mit ABAP DOC ist eine einfache Dokumentation innerhalb des Sourcecodes möglich, die in Eclipse / ADT hübsch aufbereitet dargestellt wird und - wenn man will - ständig präsent ist.

Hier ein einfaches Beispiel: mit recht geringem Aufwand ist hier die Klasse im Wesentlichen dokumentiert, inkl. Verweisen auf weitere Informationen, darunter die Parameter des Konstruktors sowie eine Kurzbeschreibung der EXPORT-Methode und deren Parameter:


Hat man in Eclipse die View "ABAP Element Info" aktiviert,


bekommt man - wenn der Klassenname oder der Methodenname selektiert ist - eine aufbereitete und leicht lesbare Dokumentation im entsprechenden Fenster.

Hier die Dokumentation, wenn man den Klassennamen im Editor selektiert hat:



Und genauso schön auch bei Methoden:





ABAP Doc-Kommentare werden grundsätzlich durch
"!
eingeleitet, danach folgt der Text.
Hier noch eine Auswahl weiterer Zeichenfolgen:
  • Parameter:
     @parameter name|documentation
  • Klassenbasierte Exception:
     @raising name|documentation
  • Nicht klassenbasierte Exception:
     @exception name|documentation
  • Zeilenumbruch:
     <br/>
  • Absatz:
     <p>…</p>
  • Unsortierte Liste:
     <ul><li>…</li></ul>
     

Hier noch ein paar Links zu dem Thema:
]]> Wed, 15 Jun 2022 10:07:00 GMT https://sap-basis.x10.bz/blog/?abap-doc---mit-wenig-aufwand-klassen-und-methoden-dokumentieren https://sap-basis.x10.bz/blog/rss/000000027 <![CDATA[Nützlich und oft ungenutzt - der Oracle SQL Tuning Advisor]]> imblog Da hat man nun das SQL-Statement identifiziert, das viel zu lange braucht und die ganze Anwendung ausbremst. Aber, wie kriegt man das jetzt flotter?

Die echten Oracle-Experten sehen sich den Ausführungsplan und die Statistiken an, die Indexe und die Distinct-Values der Key-Felder, und dann ist denen alles klar. Wenn man ein Oracle-Experte ist...

Ist man das nicht, kommt bisweilen etwas Hilflosigkeit auf. Es gibt aber ein Tool, das in allen SAP-Systemen mit einer Oracle-Datenbank vorhanden ist, das aber viel zu selten genutzt wird - der "SQL Tuning Advisor".
Die seltene Nutzung liegt allerdings auch daran, dass es gut versteckt ist.
Zu finden ist es in der ST04 > Performance > SQL Statement Analysis:

Oracle SQL Tuning Advisor ST04
Der Menüpunkt zum "SQL Tuning Advisor" in der ST04

Sehen Sie mal nach... wie, der Menüpunkt fehlt bei Ihnen?

Ja, das ist meistens so. Im Standard wird dieses Tool ausgeblendet, aus lizenzrechtlichen Gründen - sollten Sie die Oracle-Datenbank nicht über SAP sondern direkt von Oracle bezogen haben, ist das "Tuning Pack" erforderlich, um den Tuning Advisor nutzen zu dürfen.
Infos dazu finden Sie im SAP-Hinweis 1028068 - Notwendige Oracle Optionen für das DBA Cockpit.
Wenn Sie das "Tuning Pack" lizenziert bzw. die Oracle-DB über SAP bezogen haben, dürfen Sie den Tuning Advisor nutzen.

Im SAP-Hinweis steht auch, was Sie tun müssen, um den Tuning Advisor verfügbar zu machen: einen Eintrag mit "TUNINGPACK" / "X" für das System in der Tabelle ORA_FEAT_USED anlegen.

Tabelle ORA_FEAT_USED
Tabelle ORA_FEAT_USED

In "offenen" Systemen (also in einem Entwicklungssystem) können Sie die SE16 dafür verwenden, um den Satz in die Tabelle einzutragen. In geschlossenen Systemen gibt es die Möglichkeit, den Funktionsbaustein SE16N_INTERFACE zu verwenden (sofern verfügbar) oder den Eintrag mit "Shortcut for SAP Systems" vorzunehmen. Das einfachste wird sein, jeweils einen Eintrag für alle Systeme im Entwicklungssystem anzulegen und die Tabelleneinträge per Transportauftrag in die Systeme zu verteilen.

Sieht man dann in der ST04 erneut nach (einmal die Transaktion neu aufrufen), ist der Menüeintrag wie im Bild oben vorhanden.
Ok, dann wollen wir den Tuning Advisor mal nutzen. Wir haben da z.B. dieses teure SQL-Statement. 2 Ausführungen seit Systemstart, jeweils 40 Sekunden Laufzeit. Die Anzahl der Ausführungen ist hier recht gering, schlechter wäre eine hohe Ausführungszahl und eine lange Laufzeit pro Ausführung.

Teures SQL-Statement
Shared Cursor Cache: ein teures SQL-Statement

Ein Klick auf den "Explain"-Button zeigt den Ausführungsplan. Dort sehen wir auch eine "SQL-ID":

Oracle Ausführungsplan
Shared Cursor Cache: Ausführungsplan

Mit der SQL-ID starten wir nun den Oracle SQL Tuning Advisor.

Oracle SQL Tuning Advisor
Start des Oracle SQL Tuning Advisor

Auch eine Online-Ausführung ist möglich, aber gerade bei größeren Tabellen ist eine Ausführung im Batch vorzuziehen. Den Job finden wir in der SM37:

Batch-Job Oracle SQL Tuning Advisor
SM37: Ausführung des Oracle SQL Tuning Advisor im Batch

Nach der Fertigstellung ist die Auswertung vom Oracle SQL Tuning Advisor in der Spoolliste des Jobs zu finden.

Oracle SQL Tuning Advisor - Output
Ausgabe des Oracle SQL Tuning Advisor

Die Liste sieht nicht ganz vollständig aus, der rechte Rand ist abgeschnitten. Eine Unschönheit beim ABAP-Programm RSORASTS, der längere Zeilen ausgibt, aber keine entsprechende "line-size" nach dem "REPORT"-Statement gesetzt hat. Aber die wesentlichen Informationen sind da: in diesem Fall schlägt der Tuning Advisor einen "Patch" auf das Statement vor, so dass ein anderer Index verwendet wird. Prognostizierte Zeit-Ersparnis: stolze 99,99%. Die Werte sind meistens etwas übertrieben, aber eine Verbesserung ist auf jeden Fall zu erwarten.
In der Liste findet sich der aktuelle Ausführungsplan sowie der Ausführungsplan, wie er nach dem Patch wäre, inkl. einiger interessanter Kennzahlen. Hier schrumpft die Anzahl der beteiligten Tabellenzeilen signifikant, von 12 Mio. auf lediglich 12.

Oft findet sich aber auch die Empfehlung, einen neuen Index anzulegen, wie in diesem Beispiel:

Oracle SQL Tuning Advisor - Output

Auch hier findet sich wieder eine Prognose über eine enorme Laufzeitverkürzung und ein Ausführungsplan vorher / nachher.

Bei der Anlage eines Index ist natürlich zu berücksichtigen, dass entsprechende Lesezugriffe profitieren, aber der Datenbank eine zusätzliche Last bei Änderungen auferlegt wird. Ein Index bei einer Tabelle mit hohem Änderungsvolumen wirkt sich dann positiv auf einen Lesezugriff mit entsprechenden Selektionskriterien aus, kann sich aber auch insgesamt eher negativ auswirken. Vor der Anlage eines Index sollte man daher noch einen Blick in die Tabellenstatistiken (Transaktion ST10) werfen und dort einen Blick auf die Werte bzgl. Tabellenänderungen werfen. Der SAP-Hinweis 912620 - FAQ: Oracle Indizes behandelt das Thema "Index" ausführlich.

Letztendlich ist der Oracle SQL Tuning Advisor aber eine feine Sache: man bekommt schnell und unkompliziert Empfehlungen zur Verbesserung eines einzelnen SQL-Statements. Im Fall der Empfehlung eines Index hat der Tuning Advisor bereits die Selektivität einzelner Felder berücksichtigt und die Reihenfolge der Felder entsprechend optimiert - darüber muss man sich dann keine Gedanken mehr machen.
Man kann vom Tuning Advisor aber auch als Resultat bekommen, dass keine weiteren Optimierungen an dem Statement möglich sind - in dem Fall kann man sich weitere Überlegungen bzgl. Index oder SQL-Patch sparen und Laufzeitoptimierungen sind dann "nur noch" in der Anwendungslogik oder der Formulierung des SQL-Statements möglich.
]]> Tue, 14 Jun 2022 09:06:00 GMT https://sap-basis.x10.bz/blog/?oracle-sql-tuning-advisor https://sap-basis.x10.bz/blog/rss/000000026 <![CDATA[Job-Abbrüche bei Queries nach Upgrade]]> imblog Das SAP-System hat mal wieder einen Upgrade hinter sich. So, nun sehen wir uns mal an, wie es so aussieht im System... hoppla, etliche Job-Abbrüche. Jobs mit Programmen AQ... was ist das denn?
In den Job-Logs sieht man so etwas:


Das angegebene Programm gibt es gar nicht. Vor dem Upgrade scheint es aber noch vorhanden gewesen zu sein, die Jobs sind auch fehlerfrei durchgelaufen.

Das Problem: hier wurden Queries mit dem ABAP-Programm der zugehörigen Query als Job eingeplant. Das funktioniert leider nicht dauerhaft. Die ABAP-Programme werden in den Query-Transaktionen (SQ01 und Verwandte) generiert. Die Namen dieser generierten ABAP-Programme sind allerdings nicht beständig - ein Transport von Queries aus einem vorgelagerten System oder aber - wie hier - ein SAP-Upgrade kann bewirken, dass die Queries neu generiert werden und dadurch ggf. auch andere Progammnamen erhalten. Dadurch sind im Job-Scheduling ungültige Programmnamen eingetragen und das führt zum Abbruch der Jobs.

Im SAP wird man leider dazu verleitet, Queries auf diese Art und Weise einzuplanen. In der SQ01 ist diese Art der "falschen" Einplanung einer Query ganz normal bei Start der Query und Nutzung der Funktion "Im Hintergrund ausführen" verfügbar. Schnell noch eine tägliche Ausführung angegeben, fertig.


So funktioniert es dann aber leider nur für eine begrenzte Zeitspanne. Insbesondere der normale Anwender kann nicht wissen, dass hier eine Falle lauert.

Wie man es richtig macht, ist im SAP-Hinweis 0393160: SAP Query: Verwendung von Queries beschrieben. Nicht der Name des generierten ABAP-Programmes ist zu verwenden sondern das Programm SAP_QUERY_CALL. Für dieses Programm gibt man die Daten zur aufzurufenden Query an und speichert die Daten als Variante. Im Job wird dann als Programm SAP_QUERY_CALL mit der entsprechenden Variante verwendet - und schon ist man auf der sicheren Seite, dass der Job auch nach einem Transport mit neuen Queries oder einem SAP-Upgrade funktioniert.

In Vorbereitung für den nächsten SAP-Upgrade kann man ja mal prüfen, ob es "falsche" Einplanungen für SAP-Queries im System gibt. Einfach mal die SM37 verwenden, und schon bekommt man die Kandidaten, die nach dem nächsten Upgrade ggf. nicht mehr funktionieren. Diese Jobs sollte man entsprechend umstellen und hat dann für den nächsten Upgrade eine Sorge weniger.


]]> Thu, 09 Jun 2022 08:53:00 GMT https://sap-basis.x10.bz/blog/?job-abbrueche-bei-queries-nach-upgrade https://sap-basis.x10.bz/blog/rss/000000025 <![CDATA[Keine Ansicht eigener Spoollisten möglich]]> imblog
So ein Problem eines Anwenders erreichte mich mal vor langer Zeit - und des Rätsels Lösung ist schon etwas eigenartig.
Der Anwender konnte seine eigenen Spoollisten nicht ansehen. Im Dialog war die ausgegebene Liste ganz normal sichtbar, aber bei Ausführung im Hintergrund... nö, keine Berechtigung. Und das Drucken der im Dialog angezeigten Liste war auch nicht möglich. Fehlermeldung "Fehler eingetreten", PT 118. Sehr vielsagend :-(

Die Ursache:
In den Benutzerparametern (SU3 bzw. SU01, Reiter "Parameter") war beim Anwender ein Parameter "SAU" mit einem Wert gesetzt. Irgendwann hat sich die SAP diesen Parameter mal ausgedacht, um damit eine bessere Steuerung der Einsicht von Spoolaufträgen zu ermöglichen. Der für den Parameter eingetragene Wert wird in das Feld "Berechtigung" der Spoolliste eingetragen. Für das Anzeigen / Drucken muss dann aber auch eine entsprechende Berechtigung (S_SPO_ACT / SPOACTION DISP bzw. PRNT bzw. REPR / SPOAUTH = (Wert lt. "SAU"-Parameter)) vorhanden sein - und die fehlte.

Lösung also:
  • Eine Rolle mit der entsprechenden Berechtigung für S_SPO_ACT zuordnen - das wäre die bevorzugte Lösung
oder
  • In der SU3 (oder SU01) den "SAU"-Parameter entfernen / ändern - das wirkt dann nur für neu erstellte Spoollisten
oder
  • Den Berechtigungswert in den Spoollisten entfernen / ändern - das wirkt dann nur für die jeweiligen Spoollisten

Es scheint nur wenig Dokumentation dazu zu geben. Hier 2 Hinweise, die sich mit dem Parameter befassen:


]]> Fri, 03 Jun 2022 15:23:00 GMT https://sap-basis.x10.bz/blog/?keine-ansicht-eigener-spoollisten-moeglich https://sap-basis.x10.bz/blog/rss/000000020 <![CDATA[Anzeige unter "System" > "Status" ist unvollständig]]> imblog So, der Upgrade hat funktioniert, das System läuft jetzt mit neuem Release-Stand. SAP_BASIS 753, super.
Aber... warum sieht die Anzeige der Release-Daten (im Menü: "System" > "Status...") so lückenhaft aus? An einer fehlenden Berechtigung scheint es nicht zu liegen, die SU53 zeigt nichts an.

Es ist allerdings auch wirklich ein bisschen gemein, dass man sich auf die SU53 nicht immer verlassen kann. Es liegt nämlich doch an einer fehlenden Berechtigung. Seit SAP_BASIS 753 gibt es das Berechtigungsobjekt S_SYS_INFO, und das erlaubt... genau, die Anzeige der Release-Daten.

Aber warum zeigt die SU53 nichts an?

Die Einschränkung in der Status-Anzeige erfolgt im Funktions-Baustein STATUS_ANZEIGEN. Die Berechtigungsprüfung wird allerdings nicht - wie üblich - über das ABAP-Statement AUTHORITY-CHECK sondern über einen Aufruf der Systemfunktion SUSR_USER_BUFFER durchgeführt, die anscheinend direkt im Benutzerpuffer (Tabelle USRBF2) nachsieht. Daher gibt die SU53 keine Auskunft. Gemein, oder?


]]> Fri, 03 Jun 2022 13:59:00 GMT https://sap-basis.x10.bz/blog/?anzeige-unter--system-----status--ist-unvollstaendig https://sap-basis.x10.bz/blog/rss/00000001F <![CDATA[Analyse von Langläufern]]> imblog
Für die Analyse von Langläufern, ob nun im Dialog oder im Batch, gibt es verschiedene Werkzeuge von SAP - und die sind gar nicht mal schlecht!

Der Allrounder schlechthin und meiner Meinung nach erste Wahl für die Analyse der Performance einer Anwendung ist die Transaktion ST12 ("Single transaction analysis"). Lassen Sie sich durch den Begriff "transaction" nicht verunsichern, auch Batch-Jobs - eigentlich alles - ist darüber analysierbar. Mit dem darüber durchgeführten Trace erhalten Sie sowohl Daten zum ABAP-Processing als auch über die Datenbankzugriffe (ein echter Vorteil z.B. gegenüber der Transaktion SAT, die eine weitere Möglichkeit darstellt). Sie können damit auch eingeplante (also derzeit nicht laufende Jobs) analysieren, indem Sie den Trace für den Job einplanen. Läuft der Job los, startet auch (mit einer kleinen Verzögerung) der Trace.
Die ST12 finden Sie nicht zwangsläufig in jedem SAP-System vor. Ihren Ursprung hat sie in den "Service Tools for Application", die von SAP für Dinge wie Early-Watch ausgeliefert werden und eigentlich nur für die Verwendung durch die SAP vorgesehen sind. Wenn Sie aber die Solution Tools installiert haben (ST-A/PI), haben Sie auch die ST12 verfügbar.
U.a. hier http://wiki.sdn.sap.com/wiki/display/ABAP/Single+Transaction+Analysis finden Sie detaillierte Informationen zur ST12.

Alternativ misst die Transaktion SE30 (Laufzeitmessung) die Aufteilung des Zeitverbrauchs in ABAP- und Datenbankaktivitäten, wobei für ABAP-Aktivitäten auch eine Auflistung auf die einzelnen ABAP-Routinen (Forms, Funktionsbausteine etc.) ausgewiesen wird.
Nachfolger der SE30 ist die Transaktion SAT (ABAP Trace). Hier finden Sie einen schön beschriebenen Einstieg in die SAT: https://blogs.sap.com/2011/01/18/next-generation-abap-runtime-analysis-sat-introduction/.
Die ST12 ist zwar umfänglicher, aber die SAT hat den Vorteil, dass sie nicht mit aktivierten Berechtigungstraces kollidiert (ein immer mal wiederkehrendes Ärgernis: man will einen ST12-Trace starten, was einem wegen eines parallel laufenden Berechtigungstrace (ST01) verweigert wird). Sofern man auf den SQL-Teil verzichten kann, ist die SAT dann eine Alternative. Auch Speicherverbraucher lassen sich mit der SAT besser finden (https://blogs.sap.com/2011/01/18/next-generation-abap-runtime-analysis-sat-how-to-analyze-memory-consumption/).

Die Transaktion ST05 (SQL-Trace) gibt Informationen über die Datenbankzugriffe (inkl. SQL Execution Plan, verwendete Indexes etc. - bekommt man in der ST12 aber auch). Gut geeignet, wenn bekannt ist, dass die Probleme bei den Datenbank-Zugriffen liegen.
Über "Trace-Liste" > "Trace nach SQL-Anweisungen verdichten" kriegt man die teuersten SQL-Zugriffe.
Über "Trace-Liste" > "Zusammenfasste Tabellenzugriffe" und anschließender absteigender Sortierung nach "Zugriffszeit" kriegt man die Tabellen mit der größten Verarbeitungsdauer.

Bei Systemen mit mehreren Applikationsservern darauf achten, daß man den Trace auf dem gleichen Server durchführt, auf dem auch der zu untersuchende Langläufer läuft (bei Dialog-Tasks also mit AL08 nachsehen, auf welchem Server der Anwender angemeldet ist, dann mit SM51 auf den gleichen Server wechseln).

Transaktion ST13 (Analyse & Service Tools Launchpad) enthält eine Vielzahl von Tools bzgl. Performance (z.B. BACKGROUND_JOB_ANALYSIS, PERF_TOOL).
Wenn die Transaktionsberechtigung nicht vorhanden ist: Programm /SSA/MXS über SA38 ausführen.

]]> Thu, 02 Jun 2022 09:57:00 GMT https://sap-basis.x10.bz/blog/?analyse-von-langlaeufern https://sap-basis.x10.bz/blog/rss/00000001E <![CDATA[Langläufer-Job - verflixter Zombie!]]> imblog
In der Jobübersicht ist ein Langläufer sichtbar - der läuft schon so lange, man mag es kaum glauben. Und siehe da, in der Workprozess-Übersicht ist er nicht zu finden (der Workprozess kann ja recht leicht über die Job-Details, "Ausführungsserver" / "WP-Nummer / PID" herausgefunden werden). Eine Statusprüfung ("Job" -> "Status") bleibt ohne Wirkung.
Und dann finden sich im Syslog auch noch so eigenartige Meldungen:
E06 Zusicherung Too may DB-rows. in Programm $Id: //b Ort 001 nicht erfüllt
Q0E Signal 6 vom Betriebssystem empfangen                                   
Q02 Stop Workproc 9, Pid 15204606                                           
Für den gleichen Zeitpunkt existiert ein Dump mit Abbruch-ID SYSTEM_CORE_DUMPED.

Ja, was ist denn hier los?

Nach einiger Suche hat sich die Ursache gezeigt:

Der Job hat eine Spolliste erzeugt, deren Speicherbedarf oberhalb der 2GB-Grenze liegt. Der Workprozess bricht dadurch ab.
Die Ursache für so eine große Spoolliste kann darin liegen, daß in den Druckparametern keine Markierung bei "Neuer Spool-Auftrag" gesetzt ist. Dadurch wird die Spoolausgabe an einen vorhandenen passenden Spoolauftrag angehängt.

SM37 > Job auswählen > Step auswählen > Button "Print Data" > Button "Properties" > Output Options > New Spool Request

Ein Seiteneffekt daraus ist auch, daß das Löschdatum immer weiter verschoben wird. So wird bei einem täglichen oder wöchentlichen Ablauf und einer Spoolreorganisation mit Fristen größer 1 bzw. 7 Tage die Spoolliste nie gelöscht und immer weiter vergrößert. Irgendwann wird dann die 2GB-Grenze erreicht.

Die Lösung besteht darin, den Spoolauftrag zu identifizieren und entweder in dessen Kopfdaten eine Markierung bei "Abgeschlossen, kein Anfügen mehr möglich" zu setzen...

SP01 > Spool-Auftrag auswählen > Goto > Request attributes

... oder den Spoolauftrag gleich zu löschen. Wer braucht schon eine Liste mit einem Volumen von 2 GB? Und damit das Problem nicht in einigen Tagen oder Wochen wieder auftritt, sollte die Ursache natürlich auch behoben und im Job in den Druckparametern eine Markierung bei "Neuer Spool-Auftrag" gesetzt werden (siehe Bild oben). Zur Identifikation des Spoolauftrages kann auch das Programm RSTS0014 (Große Spoolaufträge selektieren") genutzt werden.
Den Job-Status des Zombies kann man nur durch manuelles Ändern des Status in Tabelle TBTCO auf "A" (aborted) korrigieren (möglich z.B. mit SE16N (sofern verfügbar) oder mit "Shortcut for SAP Systems"). Die Statusprüfung in SM37 ("Job" -> "Status prüfen") zeigt keine Wirkung.   


]]> Thu, 02 Jun 2022 09:34:00 GMT https://sap-basis.x10.bz/blog/?langlaeufer-job---verflixter-zombie- https://sap-basis.x10.bz/blog/rss/00000001D <![CDATA[Rund um das Thema Jobs / Background-Processing]]> imblog
Das Thema Hintergrund-Verarbeitung kann komplex sein. Das SAP bietet im Standard ein gar nicht mal schlechtes Scheduling-System, das vieles möglich macht. Es gibt aber auch 3rd-Party-Lösungen, mit denen Jobs im SAP eingeplant und überwacht werden können, z.B. UC4.

Die hier aufgeführten Notizen beziehen sich auf das SAP-eigene Job-Scheduling-System.
Standard-Jobs anlegen / verwalten
-> Button "Standardjobs" in der SM36 bzw. "Job-Repository" in der SM36 (= Transaktion SJOBREPO) in HANA-Systemen. Weiterhin gibt es in HANA-Systemen die Transaktion SJOBREPO_STEPUSER, mit der Systemuser für die Standardjobs angelegt und zugeordnet werden können.
Massenänderung von Jobs
mit Programm BTC_MASS_JOB_CHANGE
Abgebrochenen Job debuggen
in SM37 Job markieren und im OK-Feld JDBG eingeben. Warnung: der Job wird dann im Debug-Mode wiederholt, inklusive aller Updates!
Jobs zu gelöschten Benutzern finden
Jobs nach ihrer Häufigkeit auflisten
Warum startet ein eingeplanter Job nicht?
Wie kann ich herausfinden, wer einen Job gelöscht hat?
Mehrfache Ausführung eines Jobs verhindern
Das geht über die Programme RSBTONEJOB bzw. RSBTONEJOB2.
RSBTONEJOB prüft, ob ein Job (dessen Name als Eingabeparameter anzugeben ist) bereits läuft. Also: "eigenen" Jobname angegeben -> werden mehrere Jobs dieses Namens gefunden, bricht die Ausführung ab.
RSBTONEJOB2 prüft und führt - wenn der Job nicht läuft - Programm und Variante anschließend aus.
Periodische Jobketten mit Vorgänger-Nachfolger-Beziehung
Dafür kann Programm BTC_EVENT_RAISE verwendet werden. Siehe SAP-Hinweis 0919458: Das Programm 'BTC_EVENT_RAISE'.
Wait-Time zwischen 2 Steps einplanen
Programm RSBTONEJOBWAIT oder RSWAITSEC
Job Scheduling Monitor
Transaktion RZ01
Etliche Hilfsprogramme zu Jobs
BTCAUX01  Jobs mit fehlenden Druckparametern anzeigen und reparieren
BTCAUX02  Jobs mit gelöschtem Drucker anzeigen
BTCAUX03  Hilfsprogramm zum Archivieren von Joblogs
BTCAUX04  Mehrfach eingeplante periodische Jobs identifizieren
BTCAUX05  Jobs zu Spoolaufträgen selektieren
BTCAUX06  Protokollierung für Joblöschung einschalten
BTCAUX07  Status von aktiven Jobs überprüfen
BTCAUX08  Anfang oder Ende eines Joblogs anzeigen
BTCAUX09  Jobs mit gelöschten Benutzern identifizieren
BTCAUX10  Job mit letztem Ausführungstermin bzw. mit Zeitfenster einplanen
BTCAUX11  Beispielprogramm zum Erzeugen eines Jobs mit Spoollistenempfänger
BTCAUX14  Hintergrund-Jobs nach ihrer Häufigkeit auflisten
BTCAUX18  verschiedene Überprüfungen von Jobs und ihren Protokollen
BTCAUX20  Löschen obsoleter Einträge aus BTCOPTIONS
BTCAUX21  Nach Jobprotokollen mit nur einer Meldung suchen
Konfiguration für Hintergrundverarbeitung (Batch) prüfen
-> Transaktion SM65


]]> Thu, 02 Jun 2022 08:57:00 GMT https://sap-basis.x10.bz/blog/?rund-um-das-thema-jobs---background-processing https://sap-basis.x10.bz/blog/rss/00000001C <![CDATA[Rund ums Thema Berechtigungen]]> imblog
Hier verschiedene über Jahre hinweg gesammelte Informationen, mehr oder weniger geordnet. Los geht's...
Welche Berechtigungen benötigt Transaktion xyz?
Das können Sie über die Transaktion SU22 herausfinden. Mit Transaktion SU22 werden einer Anwendung die Berechtigungsobjekte einer Anwendung zugeordnet und die Vorschlagswerte (für den Profilgenerator (PFCG)) verwaltet.
Berechtigungstrace:
Für den Berechtigungstrace gibt es mehrere Transaktionen:
  • ST01 -> Berechtigungsprüfung. Beachten: der Trace ist nicht systemweit sondern wirkt nur auf der Instanz, unter der der Trace gestartet wurde! Also: Anmeldung auf dem gleichen Server, auf dem die Session des zu tracenden Anwenders läuft! In den Details einer Berechtigungsprüfung im Trace (Doppelklick) findet sich auch ein Verweis auf das Programm und die Sourcecode-Zeile, in der die Berechtigungsprüfung erfolgte.
    Bei der Auswertung: keine Sternchen im Feld für die User-ID verwenden, das wirkt in der ST01 nicht wie man erwarten könnte. Eine Angabe von z.B. "ABC*" führt dazu, dass für den User "ABC*" die Trace-Daten ausgewertet werden - und nicht für alle mit "ABC" beginnenden User.
  • STAUTHTRACE: Erweiterte Version von ST01 für den Trace von Berechtigungen (ab SAP_BASIS 7.00 SP26). Ab Gültigkeit lt. SAP-Hinweis 1707841 (STAUTHTRACE: Systemweite Traceauswertung) wird auch das Starten des Traces auf Appl.-Servern unterstützt. Liefert - bei gesetzter Markierung bei "Extended Passport auswerten" - auch einige nützliche Statistikdaten, z.B. bei RFC-Aufrufen (aufrufendes System/Mandant, Batch-Job, Transaktionsname). Darstellung der Trace-Daten in einem ALV-Grid, Sprungmöglichkeit zum jeweiligen ABAP-Sourcecode.
  • STUSOBTRACE: Setzen der Filter für den Berechtigungstrace (ab SAP_BASIS 740?). Abhängiger Profilparameter: auth/authorization_trace.
  • STRFCTRACE (aus SAP-Hinweis 2080378: Analyse RFC-Kommunikation, ähnlich der Funktion im "UCON" ("Unified Connectivity", http://help.sap.com/saphelp_nw74/helpdata/de/ab/35e1c69f744d69a4fcf4ca93284e0c/content.htm))
Ausschalten von Berechtigungsprüfungen
Transaktionen AUTH_SWITCH_OBJECTS, SU24, SU25
-> durch Profilparameter auth/object_disabling_active verhinderbar (sollte in P-Systemen auf N gesetzt sein!)
Kurze Beschreibung / Abgrenzung der Transaktionen SU22, SU24, SU25 (aus der Online-Doku zu SU22 übernommen):
Mit Transaktion SU22 ordnen Sie als Entwickler einer Anwendung die Berechtigungsobjekte der Anwendung zu und bearbeiten die Berechtigungsvorschlagswerte der Berechtigungsobjekte. Die Berechtigungsobjekte und deren Vorschlagswerte kann der Berechtigungsadministrator des Kunden mit Transaktion SU25 übernehmen und mit Transaktion SU24 anpassen. Diese kundenseitig angepassten Daten verwendet der Profilgenerator (Rollenverwaltungswerkzeug, Transaktion PFCG) bei der Erstellung von Rollenberechtigungen. In der PFCG kann der Rollenadministrator des Kunden die Berechtigungswerte noch weiter nachbearbeiten, z.B. um den Buchungskreis anzugeben.
Die SU25 dient für die Initialisierung des Profilgenerators nach Upgrade bzw. Erstinstallation.
Weitere Programme in dem Umfeld: SU2X_CHECK_CONSISTENCY, SU24_AUTO_REPAIR.
Berechtigungsfelder, Ausprägungen / Wertetabellen
Transaktion SU20
Für Transport: Objektkatalogeintrag ist folgendermaßen
R3TR AUTH (Berechtigungsobjekt)
Dabei dann aber auch an verwendete Datenelemente und Domänen denken!
R3TR DTEL (Datenelement)
R3TR DOMA (Domäne)
SUIM: Suchen nach Gesamtberechtigung ('*')
Ein in den Feldwerten für Berechtigungen eingegebener * bewirkt, dass nach beliebigen Ausprägungen in dem Feld gesucht wird. Will man auf die Gesamtberechtigung abfragen, muss #* eingegeben werden (siehe SAP-Hinweise 1267608: SUIM| RSUSR030 Suche nach Gesamtberechtigung und 1259329: SUIM| Suche mit dem Suchmuster #**).
Reiter "Berechtigungen" fehlt in PFCG
-> Profilparameter auth/no_check_in_some_cases enthält nicht "Y". Siehe SAP-Hinweis 416016: Profilparameter auth/no_check_in_some_cases.
Deklaration eines Feldes als Organisationsebene (in PFCG)
SAP-Hinweise
Zusammenspiel PFCG - HR-Org.Management
-> indirekte Rollenzuordnung. Indem User einer "Planstelle" zugeordnet werden, erhalten sie dann auch die zu einer Planstelle zugeordneten Rollen.
Dokumentation in der SAP-Bibliothek dazu:
Eine Rollenzuordnung über HR-Org.Management ist u.a. am Flag "ORG_FLAG" in der Tabelle AGR_USERS erkennbar.
Voraussetzung ist u.a. ein Eintrag in Tabelle PRGN_CUST (HR_ORG_ACTIVE "YES").
Beteiligte Tabellen, Transaktionen etc.: Tabellen T77AW (WEGID = US_ACTGR), Transaktion PPOME. Liste der Besetzung von Planstellen: Transaktion S_AHR_61016503. Allgemeines Auswerteprogramm: RHSTRU00
SAP-Hinweise mit Informationen dazu:
Profile SAP_ALL und SAP_NEW
Für beide gibt es Generierungsprogramme:
RSUSR406 für SAP_ALL
REGENERATE_SAP_NEW für SAP_NEW
Mit dem Programm REGENERATE_SAP_APP kann man auch ein "SAP_APP"-Profil und/oder eine "SAP_APP-Rolle" generieren, in dem z.B. Basis- und HR-Objekte ausgeschlossen werden können. Anders als SAP_ALL und SAP_NEW existiert das Profil im Standard nicht, wenn man es über REGENERATE_SAP_APP generiert.
Rollen: Massengenerierung von Profilen
Tx. SUPC bzw. Programm SAPPROFC_NEW. Für Ausführung von SAPPROFC_NEW wird allerdings auch die Transaktionsberechtigung für SUPC benötigt (wird bei Programmstart geprüft). Wenn man die nicht hat (und auch nicht die für Ausführen der Generierung in PFCG), kann man für Generierung von Profilen einzelner Rollen auch noch auf den Funktionsbaustein SUPRN_PROFILE_BATCH ausweichen (SE37, Parameter: ACT_OBJID = Rollenname). Interessanterweise scheinen dabei keine Änderungsbelege erzeugt zu werden.
Massenlöschung von Rollen
Statusübersicht über Rollen (Profil / Profilgenerierung aktuell, Benutzer zugewiesen etc.)
Programm PRGN_STATUS_ALL
Rollen: Massenfunktion für Aufnahme in Transportauftrag
Programm PFCG_MASS_TRANSPORT
Rollen in andere Systeme verteilen
Transaktion PFCGROLEDIST
Rollenvergleich
SUIM -> Vergleiche -> Rollen (bzw. Transaktion S_BCE_68001777 bzw. Programm RSUSR050).
Rollen: Anpassen und Generieren von abgeleiteten Rollen
Programm SUPRN_REGENERATE_DEPENDENT -> geht aber nur für einzelne Mutterrollen (Name der vererbenden Rolle muss im Selektionsbildschirm angegeben werden).
Berechtigungen: Ein-/Ausschalten Transaktionsberechtigung bei Aufruf aus einer anderen Transaktion (CALL TRANSACTION...)
Transaktion SE97 / Tabelle TCDCOUPLES für Berechtigungsprüfung Transaktionsaufruf aus einer anderen Transaktion
In welchen Sammelrollen ist eine Rolle enthalten?
über SE16 -> Tabelle AGR_AGRS, Rolle in CHILD_AGR eintragen.
Welche Transaktionen hat Benutzer x im Zeitraum y - z verwendet?
ST03N -> auf "Experte" umschalten -> Appl-Server auswählen (nicht TOTAL!) -> Zeitraum auswählen -> im unteren Bereich  "Anwender- u. Abrechnungsstat." -> "Anwenderprofil" -> Doppelklick auf Benutzer x
Refresh der Benutzerpuffer (Berechtigungen)
in SU01 im Kommandofeld (egal, welches Dynpro) "RSET" eingeben
oder
Report RSUSR405 ausführen
oder
Funktionsbaustein 'SUSR_USER_BUFFER_AFTER_CHANGE' ausführen (Wert für Parameter PROFILE: 4. Siehe auch SAP-Hinweis 452904: Verlust der Berechtigung nach Profilgenerierung)
oder
Funktionsbaustein 'SUSR_RESET_ALL_USER_BUFFERS' ausführen
Auch für einen einzelnen User kann der Benutzerpuffer zurückgesetzt werden: SU56 > "Berechtigungswerte" > "Anderer Benutzer / Berechtigungsobjekt" > User angeben > "Berechtigungswerte" > "Benutzerpuffer zurücksetzen".
Problem "Überlauf des Benutzerpuffers"
In Releases < SAP_BASIS 750 gibt es eine "harte" Grenze von 312 Profilen, die ein Benutzer haben kann. Wird diese Grenze überschritten, klappt der Benutzerabgleich nicht (rote Ampeln).
Die Benutzer, bei denen so ein Überlauf vorliegt, kann man über SE16 / Tabelle USR04 herauskriegen. Im Feld PROFS stehen die zugeordneten Profile, im Feld NRPRO die Anzahl der belegten Bytes in dem Feld. Der Profilname ist 12 Zeichen lang, 2 Bytes werden noch zusätzlich für ein Änderungskennzeichen benötigt. Also: (NRPRO - 2) / 12 = Anzahl Profile. Bei Wert > 3740 liegt ein Überlauf im Benutzerpuffer vor.
SAP-Hinweise dazu:
Meldung "Keine Berechtigung zum Lesen der Datei usr/sap/trans/sapnames/USERNAME"
Ein paar ggf. nützliche Programme
PRGN_STATUS_ALL Übersicht Rollen (Profil generiert, User zugeordnet etc.)
PFCG_ADD_MINIAPP Hinzufügen einer MiniApp
PFCG_AGRS_WITH_MANUAL_S_TCODE Auflisten aller Rollen mit manueller S_TCODE Berechtigung
PFCG_COMPARE_ROLE_WITH_TEMPL Report PFCG_COMPARE_ROLE_WITH_TEMPL
PFCG_MASS_DOWNLOAD Massen-Download von Rollen
PFCG_MASS_IMPORT Massenimport von Rollen
PFCG_MASS_TRANSPORT Massentransport von Rollen
PFCG_MODAUTH Ändern von Berechtigungen einer Rolle von „Standard“ zu „Manuell“
PFCG_ORGFIELD_CREATE Profilgenerator: Neues Org.-Ebenen Feld anlegen
PFCG_ORGFIELD_DELETE Profilgenerator: Neues Org.-Ebenen Feld wieder löschen
PFCG_ORGFIELD_ROLES Rollen mit Orgebenendefinition synchronisieren
PFCG_ORGFIELD_UPGRADE Profilgenerator: Anpassung nach Upgrade für neue Org.-Ebenen Feld
PFCG_SET_ACTGROUP_TIMESTAMP Programm PFCG_SET_ACTGROUP_TIMESTAMP
PFCG_SET_PROFILE_NAMERANGE Nummernbereich für den Namensvorschlag bei Profilen setzen
PFCG_START_PFCG Programm zum Starten der PFCG
PFCG_TIME_DEPENDENCY Report zum Einplanen für Zeitabhängigkeit der Rollen
PFCG_UPDATE_ALL_ROLES Nachgenerieren aller Rollen
SUPRN_PRINT_COMPLETE_AGR Druckaufbereitung aller Daten einer Rolle
SUPRN_REGENERATE_DEPENDENT Anpassung abgeleiteter Rollen
Berechtigungen für Tabellen
Berechtigung für alle Tabellen einer Berechtigungsgruppe
Über Berechtigungsobjekt S_TABU_DIS. Die Berechtigungsprüfung für S_TABU_DIS erfolgt sowohl in den "generischen Tabellenzugrifftools" (SE16, SM30...) als auch in vielen Anwendungsprogrammen.
Berechtigung für einzelne Tabellen
Das ist steuerbar über die Berechtigungsobjekte S_TABU_DIS (Ziel: erfolglose Berechtigungsprüfung für Berechtigungsgruppe der Tabelle) und S_TABU_NAM (Ziel: erfolgreiche Berechtigungsprüfung für die Tabelle).
In den "generischen Tabellenzugriffstools (Transaktionen SE16, SE17, SM30, SM31 und SM34) und allen weiteren Anwendungen die den Funktionsbaustein VIEW_AUTHORITY_CHECK zur Berechtigungsprüfung nutzen" wird zunächst S_TABU_DIS mit der Berechtigungsgruppe der Tabelle geprüft. Schlägt diese Berechtigungsprüfung fehl, wird anschließend die Berechtigung für S_TABU_NAM mit dem Tabellennamen geprüft. Ist diese erfolgreich, ist der Zugriff auf die Tabellendaten möglich. In vielen Anwendungsprogrammen erfolgt diese Methodik der Berechtigungsprüfung aber nicht, d.h. funktioniert für einen Anwender in den Transaktion SE16, SM30, ... der Zugriff auf die Tabelle aufgrund fehlender Berechtigung für S_TABU_DIS und vorhandener Berechtigung für S_TABU_NAM, wird ihm der Zugriff in den Anwendungsprogrammen auf die gleiche Tabelle ggf. verwehrt.  
Berechtigung für einzelne Zeilen von Tabellen
Über Berechtigungsobjekt S_TABU_LIN.
In dem Zusammenhang auch noch sinnvoll: Eine Parametertransaktion für SM30 mit dem Tabellennamen, Pflege in SU24 für diese Parametertransaktion.
Sperrung eines Systems gegen den Import von Benutzerzuordnungen von Aktivitätsgruppen
Wenn Sie ein System gegen den Import von Benutzerzuordnungen von Aktivitätsgruppen grundsätzlich sperren wollen, so können Sie dies in der Customizing Tabelle PRGN_CUST angeben (Pflege mit der Transaktion SM30). Geben Sie dazu eine Zeile mit der Bezeichnung USER_REL_IMPORT und dem Wert NO ein.
Sicherheitsrichtlinien / Security Policies
AB SAP_BASIS 731. Die Sicherheitsrichtlinien lösen etliche Profilparameter bzgl. Definition von Passwortregeln, -änderungen und Anmelderestriktionen ab. In der SU01 (Reiter "Logondaten") kann man Benutzer einer Sicherheitsrichtlinie zuordnen. Die Sicherheitsrichtlinien werden in Transaktion SECPOL gepflegt.
Ist bei einem User keine Sicherheitsrichtlinie eingetragen, sind die Regeln lt. Profilparameter gültig.
Änderungen an problematischen Profilparametern (wie z.B. login/password_downwards_compatibility) können darüber eingeführt werden, ohne dass man ein Risiko bei den Systemusern eingeht, wenn diese einer Sicherheitsrichtlinie zugeordnet sind, die ältere Regeln definieren.
Hinweis: mit Einführung der Sicherheitsrichtlinien sind die Passwortregeln nun auch für Servicebenutzer gültig!
Kritische Berechtigungen / kritische Kombination von Berechtigungen
Ab Release 7.52 gibt es mit dem Report RSUSR_UP_AND_DOWNLOAD_FOR_CA die Möglichkeit, die Definition der Regelwerke in Excel vorzunehmen. (In älteren Releases kann der Report selbst angelegt werden, der ABAP Code ist hier: https://wiki.scn.sap.com/wiki/download/attachments/491918787/Z_USCRAUTH.txt zu finden). Mit diesem Report können die bestehenden Regeln aus dem System im passenden Format nach Excel exportiert und dort angepasst / ergänzt werden. Anschließend kann das Excel wieder hochgeladen werden. Weitere Infos dazu gibt es im SAP-Hinweis 2785076: SUIM| Neue Funktionalitätten in RSUSR008_009_NEW.
Tabelleninhalt eines anderen Mandanten einsehen
  • über Transaktion ST04, dort findet sich ein SQL-Editor
  • über Programm ADBC_QUERY. Nur den Tabellennamen eingeben (DB-Verbindungsname und Datenbankschema kann leer bleiben), nachfolgend ggf. Spalten auswählen, anschließend bekommt man die Daten aller Mandanten im System.
Änderungsbelege zu Usern
Tabellen:
USRSTAMP Zeitstempel für alle Änderungen am Benutzer
USH02 Änderungshistorie f. Logon-Daten und Security Policy
USH04 Änderungshistorie Berechtigungen
CDHDR: OBJECTID = Username, und wie üblich haben die zugehörigen Sätze in Tabelle CDPOS die gleiche CHANGENR.




]]> Thu, 02 Jun 2022 07:34:00 GMT https://sap-basis.x10.bz/blog/?rund-ums-thema-berechtigungen https://sap-basis.x10.bz/blog/rss/00000001B <![CDATA[Probleme mit dem TMS]]> imblog
Im Laufe der Jahre bin ich immer mal über Probleme mit dem Transportsystem gestoßen. Hier sind meine gesammelten Notizen dazu, die ebenfalls über etliche Jahre hinweg zusammengestellt wurden. Daher treten ggf. einige Probleme nicht mehr auf, und ggf. gibt es für einige Probleme auch inzwischen andere Lösungen.
Wie auch immer, wenn Sie auf eines der hier genannten Probleme stoßen sollten oder eine bestimmte Fragestellung zum TMS haben, können Ihnen die Information hoffentlich nützlich sein. Los geht's...
Konflikt CTC=1 / clientALL
Der Support Package Manager stellt Transporte mit clientALL in die Importqueue. Diese können bei gesetzter CTC-Option (mandantenspezifische Importqueue) manuell nicht wieder aus der Importqueue gelöscht werden.
Lösung: über RSBDCOS0 tp-Aufruf mit temporärer Überlagerung des CTC-Paramters ("-D CTC=0"):
tp delfrombuffer SAPKIPZE43 <SID pf=<Domänenprofildatei> "-D CTC=0"
TMS bleibt stehen
Wenn das TMS "stehenbleibt" (z.B. beim Lesen der Importqueue, beim Weiterleiten eines Auftrages, beim Löschen eines TA aus der Importqueue oder beim Prüfen kritischer Transportobjekte): TP-Systemprotokoll einsehen. Dort sind vermutlich solche Meldungen vorhanden:
WARNING: \\....\<SID>.LOB is already in use (118), I'm waiting 5 sec (20200823110008).
(z.B. beim Weiterleiten eines Auftrages)
oder
WARNING: /usr/sap/trans.<SID>/tmp/<TA-Nr.>.<SID> is already in use (8), I'm waiting 5 sec ....
(beim Prüfen kritischer Transportobjekte)
Entweder ist die Datei eine Leiche aus einem vorangegangenen abgebrochenen tp-Prozess oder es laufen mehrere konkurrierende Prozesse gleichzeitig. Die Prozess-ID steht in der Datei. Wenn der Prozess noch läuft, sollte im Transportmonitor und im Transportverzeichnis (\tmp\) geprüft werden, ob der Prozess tatsächlich noch etwas tut. Wenn sich weder im Transportmonitor noch im tmp-Verzeichnis etwas tut, kann der Prozess abgebrochen werden, anschließend kann die Datei gelöscht werden. Siehe auch SAP-Hinweis 12746.
TA lässt sich nicht importieren: RC 242, "Because of serialization..."
Bei einem Abbruch des vorigen Transportes bleibt ggf. eine Semaphoren-Datei liegen. Die ist zu finden im Verzeichnis <DIR_TRANS>/serial mit dem Name <SID>SEMA.GLB. In dieser Datei ist die Prozess-ID des tp-Prozesses enthalten, die die Semaphoren-Datei erzeugt hat. Sollte der Prozess nicht mehr laufen, kann die Semaphoren-Datei gelöscht werden.
Überprüfung, ob der Prozess noch läuft:
Unix: auf BS-Ebene mit "ps -ef |grep <PID>"
NT / Win2K: da weiß ich nichts besseres als ST06 -> "Erste 40 CPU-Prozesse"
Sollte der Prozess noch laufen (neuerer Zeitstempel in der Semaphoren-Datei? Bewegung im tmp-Verzeichnis?), aber anscheinend nichts mehr tun, muss er beendet werden, anschließend kann die Semaphoren-Datei gelöscht werden.
Transport hängt ewig / bricht ab mit RC 12 im Schritt "Move Nametabs"
Sollte der Schritt "Move Nametabs" ewig laufen, sollte zunächst geprüft werden, ob der Job tatsächlich noch läuft (Job RDDMNTAB -> in SM37 den Status prüfen). Ggf. ist der Prozess inzwischen gestorben.  
Zunächst gilt es, den verursachenden Transport herauszufinden. Nachdem das Serialisierungs-Problem (voriges Problem) behoben ist, müssen die Transportaufträge in kleinen Portionen eingespielt werden. Bei einem TA tritt das Problem dann ggf. wieder auf. Ggf. tauchen im SysLog ORA-0060-Meldungen auf (Deadlock auf Tabelle D010...).
Die Ursache liegt vermutlich darin, dass der Transport eine Struktur oder Tabelle ändert, die an zahlreichen bzw. zentralen Stellen verwendet wird. Welche Strukturen / Tabellen das sind, kann evtl. über Einsicht in die Datei "P<JJMMDD>.<SID>" im \tmp-Verzeichnis in DIR_TRANS ermittelt werden. Der Import führt dazu, dass zum einen der Transportprozess, aber auch etliche Anwender, die ein abhängiges Objekt gerade in der Anwendung verwenden, eine Neugenerierung / Aktivierung veranlassen. Hier ist die Gefahr eines Deadlocks entsprechend gross. Abhilfe kann schaffen, die Strukturen / Tabellen des Transportauftrages in der SE11 manuell zu aktivieren. Auch hier können jedoch Deadlocks auftreten -> neu versuchen.
Import bricht ab mit RC=234 ("uncaught internal error")
OSS-Hinweise 526600 und 0400042 treffen nicht zu.
Im TP-Syslog taucht folgende Meldung auf:
HALT 20031125140801
ERROR: uncaught internal error in database interface
ERROR: EXIT(16) -> process ID is: 242654
Ursache: ein zu importierender Transportauftrag ist in der Importqueue doppelt vorhanden. Das kann durch irrtümliche Ablehnung im QA-Arbeitsvorrat und anschließender Weiterleitung ans Zielsystem passieren.
Lösung: doppelte Einträge in Importqueue entfernen.
Meldung "transport order ... exists already with different contents."
Meldung "ERROR <Transportauftrag> <SID> I 0016 20200209210918 ..." im TP-SysLog bzw. im Transportprotokoll durch Meldung
transport order ... exists already with different contents.                          
===> HALT: If you are sure that this is ok, use umode 1 to overwrite it. Please contact the SAP support.
Ursache: vermutlich wurden bereits früher Transporte gleichen Namens, aber mit anderen Inhalten in das System importiert.
Lösung: tja, was Besseres weiß ich nicht:
Entweder den Ratschlag mit umode 1 befolgen (also Import auf BS-Ebene mit tp import) oder aber die E07*-Tabellen um den / die angemeckerten TA(s) bereinigen (löschen). Die Tabellen sind diese:
E070, E070A, E070C, E070CREATE, E070DEP, E070L, E070M, E070P, E070TC, E071, E071C, E071E, E071K, E071KF, E071KFINI, E071L, E07T.
Die Tabellen sind nicht direkt verwaltbar, aber mit Tools wie "Shortcut for SAP systems" ist es möglich.
Im TMS fehlt der Import-Button
Vermutlich existieren Transportaufträge ohne Zielmandant in der Importqueue. Diese markieren und einen Zielmandanten zuweisen.
Importmonitor voller Leichen
Kann beim Abbruch von tp entstehen. Wenn man riesige Mengen von Transporten gestartet hat, findet sich im Importmonitor für jeden TA ein Eintrag, die nur mühsam auf manuellem Wege gelöscht werden können.
Lösung: die zugrundeliegende Tabelle ist "TPSTAT". Über SE14 kann man die Tabelleninhalte löschen  (Datenbanktabelle löschen, Datenbanktabelle anlegen). Die SE14 ist immer etwas heikel. Mit "Shortcut for SAP systems" ist es ebenfalls, und auch mit etwas mehr Kontrolle und Flexibilität möglich.
Bei TMS-Konfiguration falsche Domäne angeben, System wartet jetzt irrtümlicherweise auf Aufnahme in Domäne
TMS-Konfiguration kann jetzt im Dialog nicht mehr gelöscht werden. Ehe man jetzt lange wartet, dass derjenige, der die fälschlicherweise angegebene TMS-Domäne verwaltet, einen wieder rausschmeißt: Eintrag in Tabelle TMSMCONF löschen (mit "Shortcut for SAP systems" leicht möglich). Dann kann man das TMS wieder neu konfigurieren.
Transportaufträge verbleiben mit Status "Import läuft" (LKW-Symbol) oder mit Status "Import eingeplant" (Uhr-Symbol), obwohl kein Transport läuft. Erneutes Importieren ist nicht möglich (Fehlermeldung "Transport läuft bereits", CREATE_ENQUEUE_FAILED).
Dieser Fehler kann auftreten, wenn a) ein schwerwiegender Fehler beim Import aufgetreten ist oder b) Transporte per Batch eingeplant wurden, der Job ("TMS...") aber nicht oder nicht fehlerfrei gelaufen ist.
In der Tabelle TMSTLOCKP und/oder TMSTLOCKR wurden a) vom Import-Prozess oder b) zum Zeitpunkt der Einplanung des Batch-Jobs Sperreinträge für die eingeplanten Transportaufträge eingestellt, die nur durch den Import der jeweiligen Transportaufträge aus der Tabelle wieder entfernt werden.
Lösung: mit "Shortcut for SAP systems" die Tabelleninhalte löschen.
Transportschritte laufen nicht an / laufen endlos. Im TP-Syslog stehen Fehlermeldungen mit "Background jobs cannot be started.".
ERROR: System <SID>. Warning.        20011030140113 :
ERROR:       The following call returned with exit code 4:
ERROR:        sapevt.exe SAP_TRIGGER_RDDIMPDP -t name=<SID>
ERROR:       Background jobs cannot be started.
ERROR:       Please check trace file dev_evt.
ERROR:       (This warning is harmless if no further warnings follow.
Wahrscheinlich trifft hier SAP-Hinweis 449270 zu. Eine schnelle Umgehung des Problems wäre die Durchführung der Transporte (bzw. das Einspielen der Support Packages bzw. PlugIn's) auf dem Server, der die Batch-Prozesse zur Verfügung stellt (also gezielt auf dem Server anmelden).  
Im QA-Arbeitsvorrat fehlen die Schaltflächen für Genehmigen und Ablehnen
In dem Fall gibt es Transportwege mit unterschiedlichen Mandanten. Wenn man einen Filter auf den zu bearbeitenden Mandanten setzt, stehen die Schaltflächen für Genehmigen und Ablehnen wieder zur Verfügung. Wenn man mal richtig die Augen aufmacht, sieht man auch einen entsprechenden Hinweis in der Fußzeile (hatte aber diverse Male anscheinend die Augen nicht richtig offen... ).
Abbruch (Returncode 12) im Schritt "Tabellenumsetzung"
Ursache ist eine Änderung in einer Tabelle, bei der die Daten nicht umgesetzt werden konnten.
Die betroffene Tabelle bekommt man über das Einsehen der Transportprotokolle heraus. Dort sieht man dann z.B. so etwas:
  Auftrag: Umsetzen Table ZSD_IQ_WVE (DDIC/14.01.19/13:48)
  Programm wurde abgebrochen (Job: RDDGEN0L, Nr.: 13480201)     
Im Datenbank-Utility (SE14) für die Tabelle sieht man dann die abgebrochene Umsetzung ebenfalls. Dort kann man dann eine Fortsetzung der Umsetzung versuchen und bekommt auch etwas mehr Informationen. Ggf. hilft auch ein Blick in die für die Umsetzung angelegte Kopie (Tabellenname mit Prefix "QCM8"). Nachdem die Umsetzung erfolgreich war, muss der Transportauftrag nochmal eingespielt werden (wobei vorher wahrscheinlich noch das Problem "TA lässt sich nicht importieren: RC 242, 'Because of serialization...'" auftritt, -> siehe weiter oben). Durch die vorweggenommene Umsetzung muss (für die Tabelle) dann nicht nochmal eine Umsetzung erfolgen.
Das Löschen abgelehnter Transporte aus der Importqueue funktioniert nicht
Das geht nicht über die normale Löschfunktion sondern nur über "Zusätze" -> "Importierte Aufträge löschen". Da werden dann aber auch alle importierten Aufträge gelöscht (auch die mit Status "steht nochmal zum Import an").
Weiterleiten eines Auftrages funktioniert nicht
Verschiedene Fälle, treten auf bei Systemen mit unterschiedlichen Transportgruppen / Verzeichnissen / Betriebssystemen:
1.: Meldung "Transportqueue muss abgeglichen werden"
Ursache ist wohl ein Schiefstand in der Importqueue bzw. in der internen Abbildung der Importqueue in den einzelnen Systemen.
Vorgehensweise zur Behebung:
    1. TMS-Konfiguration auf Domäne neu verteilen und aktivieren
    2. Transportwege-Konfiguration auf Domäne neu verteilen und aktivieren
    3. Auf allen beteiligten Systemen: "Zusätze" -> "Alle Importqueues aktualisieren"
2.: Transport erscheint in Ziel-Importqueue, aber data- und cofile werden nicht übertragen
Für die Feststellung, ob Dateien übertragen werden müssen, wird anscheinend nicht die Existenz im Filesystem sondern ein Flag in der Importqueue des Zielsystems geprüft. Auch hier ist ein Schiefstand der Importqueue die Ursache. In dem Fall müssen data- und cofile manuell ins Zielverzeichnis kopiert werden.
3.: Beim Import in ein vorgelagertes System werden keine / nicht alle Transportaufträge in die Importqueue des Folgesystems gestellt.
Das vorgelagerte System hat eine andere Version der Importqueue des Folgesystems als das Folgesystem. Das lässt sich auch daran feststellen, dass die Dateien in den buffer-Verzeichnissen unterschiedlich sind (unterschiedliche Länge).
Behebung: Dateien auf dem vorgelagerten System phyikalisch aus dem buffer-Verzeichnis löschen, anschließend "Zusätze" -> "Alle Importqueues aktualisieren".
tp-Befehle (addtobuffer etc.) scheitern mit Fehlermeldung "invalid syntax for tp-call"
Das kann auch daran liegen, dass entweder der einzufügende TA in der Importqueue schon vorhanden ist oder aber der nach "after" bzw. "before" angegebene TA in der Importqueue nicht vorhanden ist.
-> ein Blick ins TP Systemlog ist hilfreich. Dort taucht dann ggf. so etwas auf:
ERROR: Inserting an already existing buffer entry is not supported!
oder
ERROR: Corresponding entry (<Transportauftrag>,<Mandant>) not found.  
tp-Befehle (addtobuffer etc.) scheitern mit Fehlermeldung "missing param"
Ein tp-Befehl scheitert mit dieser Fehlermeldung:
TOOLS: Highest return code of single steps was: 0
ERRORS: Highest tp internal error was: 0208       
tp finished with return code: 208                 
meaning:                                          
 error in TPPARAM (param missing, unknown,...)   
Leider schweigt sich die Fehlermeldung über den fehlenden Parameter aus. Wenn das Anhängen von Transporten / Weiterleiten über das STMS funktioniert, sollte man einen Blick in die Datei <TRANSDIR>\log\ULOG* werfen, dort werden die tp-Befehle protokolliert. Ggf. werden dort weitere Parameter mitgegeben. Wenn man das beim tp-Befehl genauso macht, klappt es. In diesem Beispiel hier wird explizit der Parameter transdir noch mitgegeben.
tp addtobuffer <Transportauftrag> <SID> client=<Mandant> pf=\\...\sapmnt\trans\bin\TP_DOMAIN_<TMS-Domäne>.PFL -dtransdir=<Transportverzeichnis gemäß DIR_TRANS>
Import bricht ab beim Schritt "Import anwendungsdefinierter Objekte"
Im Importprotokoll wird ein Abbruch von Programm RDDDIC1L ausgewiesen, und im Jobprotokoll, auf das verwiesen wird, steht folgendes:
Job wurde gestartet
Step 001 gestartet (Programm RDDDIC1L, Variante , Benutzername DDIC)
Programm RDDDIC1L läuft im Mandanten <Mandant>
Keine Berechtigung zum Lesen der Datei /usr/sap/trans..../data/<Datafile>
Job wurde abgebrochen
-> das heißt, im Mandanten fehlt dem DDIC-User die Berechtigung für S_DATASET. Tja, der DDIC sollte und muss halt SAP_ALL haben, und all die Bemühungen der Sicherheitsfanatiker, SAP_ALL auf Teufel komm raus zu eliminieren, scheitern spätestens beim DDIC.
Import hängt beim Schritt "Import anwendungsdefinierter Objekte"
Im TP-Syslog steht ständig folgendes:
ERROR: System <SID>. Warning.        20180213194537 :                                          
ERROR:       Background job not running properly. Function: D  Jobcount: 19383701  Status: P.
ERROR:       Please check the system. Use transactions SM21, SM37, SM50.                     
ERROR:       (This warning is harmless if no further warnings follow.)
Der Job RDDDIC1L (zuständig für den Import anwendungsdefinierter Objekte) läuft überhaupt nicht los. Ein erneutes Einplanen der TMS-Jobs mit RDDNEWPP bringt eine Fehlermeldung, und im Syslog taucht dann der entscheidende Tip auf:
EF2 BP_STEPLIST_EDITOR: ungueltige Stepwerte ( Step 1 ) entdeckt. Grund:
EFV > Benutzer DDIC ist auf Grund seines Typs nicht einplanbar          
EFN BP_JOB_EDITOR: Job RDDIMPDP_CLIENT_011 ist ungültig. Grund:         
EFT > Step 1 enthält ungültige Werte
Der Benutzertyp des DDIC war auf "Kommunikation". Die Änderung auf "System" hat Abhilfe geschaffen. Eigenartigerweise ist der DDIC in allen anderen Systemen / Mandanten ebenfalls vom Typ Kommunikation, ohne dass Probleme auftraten.
Dieser Fehler tauchte bei einem System mit neuerem Support Package Stand (51) als den anderen auf, ggf. gibt es durch das Support Package das Problem.
Import von Transporten läuft nicht, TMS-Monitor zeigt dauernd "Initialization complete, start working now"
Das TMS-Systemlog bringt keinerlei neue Einträge, auch nicht von den letzten Importversuchen.
-> In AL11 mal nachsehen, ob im log- oder im tmp-Verzeichnis eine Datei "SLOG<MMDD>.<SID>.LOC" mit älterem Zeitstempel liegengeblieben ist. Das scheint eine Sperrdatei für das TMS-Systemlog zu sein. -> Löschen
Import-All bricht ab mit Fehlermeldung "Internal error getting container, RC= 4"
Das einmalige Aufsetzen eines Import-All-Jobs mit anschließender Änderung auf einen periodischen Job über die SM37 funktioniert so nicht. Die Periodizität muss direkt bei der Einplanung im STMS gesetzt werden. Siehe auch SAP-Hinweis 398589.
Importierte Workbench-Objekte sind trotz erfolgreichem Import nicht in den Entwicklungsklassen sichtbar
Jobs EU_PUT und EU_REORG nochmal laufen lassen bzw. die entsprechenden Programme nochmal starten. Die laufen i.d.R. 1x täglich. Ein Lauf nach dem Import sollte den Effekt bereinigen.
Weitere Ansätze zur Fehlerhebung:
Importqueue:
  • Importqueue prüfen
  • Transport-Tool prüfen
  • TMS-Konfiguration:
  • Transportgruppen prüfen

Weiterhin gibt es etliche Log-Dateien, in denen ggf. auch noch nähere Infos zu Fehlern enthalten sind.
  • TP-Systemlog (<Transportverzeichnis>\log\SLOG*)
  • TP-Alerts
  • <Transportverzeichnis>\log\ALOG*
  • <Transportverzeichnis>\log\ULOG*
  • <DIR_HOME-Verzeichnis>\dev_tp (Einsehen sinnvoll z.B. bei Meldungen wie "ERROR: see tp's stdout (Standard Out may not be available)")

Es gibt auch noch den SAP-Hinweis 13807, der generelle Informationen zur Analyse von Problemen des TMS beinhaltet.
Tabellen im TMS-Umfeld:
  • TRJOB Jobkennung für Koordination Batch-ABAP/UNIX für Transporte
  • TBATG Steuertabelle für Tabellenumsetzung in Batch
  • TRBAT Kommunikationstabelle für Transportsteuerung
  • TMSBUFREQ TMS Manager: Transportaufträge in Transportpuffer
  • TMSTLOCKR TMS TP: Sperrtabelle für Einzelimporte -> LKW-Symbol in Importqueue
  • TMSTLOCKP TMS TP: Sperrtabelle für Projektimporte -> LKW-Symbol in Importqueue
  • sowie weitere TMS*-Tabellen
Löschen von ggf. hängengebliebenen Einträgen in Tabelle TBATG:
Auf keinen Fall in SE14 über "Datenbanktabelle löschen" und "Datenbanktabelle anlegen"! In der SE14 wird die TBATG gelesen (egal welche Tabelle man damit bearbeiten will). Ist die Tabelle gelöscht, bricht die SE14 mit Kurzdump ab, und das war's dann mit der TBATG - keine neue Anlage der Tabelle mehr möglich, weil die SE14 immer abbricht.
-> Stattdessen Löschen von Sätzen der TBATG über den Menüpunkt "DB-Aufträge" -> "Per Import erstellte". Oder "Shortcut for SAP systems" verwenden.
Umsetzung von Pool-Tabellen in Transparente Tabellen:
In den technischen Eigenschaften (SE13) gibt es dafür das Flag "Transform to transparent table“. Setzt man das und sichert/aktiviert die Tabelle, wird nach einem Transportauftrag verlangt, in den der Objektkatalogeintrag LIMU TABT (Tabellenname) reingeschrieben wird.
Das reicht aber nicht aus, damit die Tabelle in nachgelagerten Systemen dann nach dem Import auch umgesetzt wird! Dafür muss die Tabellendefinition (R3TR TABL (Tabellenname)) in den Transportauftrag eingehängt werden.
Periodischer Import All in einen Mandanten
Sollte nicht ins Quellsystem der Transporte durchgeführt werden (die Idee existiert immer wieder mal für eine Belieferung eines Sandbox-Mandanten auf dem Entwicklungssystem). Begründung: Workbench-Objekte, die sich derzeit wieder in Arbeit befinden, werden durch Import freigegebener TA's mit älterem Stand überschrieben. Und irgendwelche anderen Effekte gibt's dann auch noch.
Einplanung: über "Import All" Button in der Importqueue. Funktioniert nur, wenn TMS-Parameter NO_IMPORT_ALL != 1 für das System definiert ist. Ggf. umschalten, verteilen, Job einplanen, wieder zurückschalten. Über SM36, Report TMS_BCI_START_SERVICE geht's nicht, weil der Import-All bestimmte Einträge in TMS-Steuertabellen voraussetzt (TMSBCIJOY).
Oder aber (z.B. wenn die TMS-Konfiguration nicht in eigener Hand liegt): der STMS-Transaktion einen nicht gesetzten TMS-Parameter NO_IMPORT_ALL vorgaukeln. Dazu in STMS vor dem Aufruf der Importqueue (oder vor dem Auffrischen der Importqueue) das Debugging einschalten, dann im Debug-Mode einen Breakpoint bei Unterprogramm STATUS_IMPORT_QUEUE in Programm SAPLTMSU_IQ setzen. Dort dann Einzelausführung bis zur Abfrage von Feld gs_impbuf-no_imp_all, den Feldinhalt dann löschen. Dann erscheint der "Import All" Button und kann verwendet werden.
Übrigens kann man einen Import-All auch auf einen Mandanten und/oder ein CTS-Projekt einschränken: in der Importqueue einen entsprechenden Filter für die Anzeige setzen und dann den Import-All einplanen.
Die Periodizität muss übrigens direkt hier gesetzt werden. Eine einmalige Einplanung eines Import-All mit anschließender Änderung auf einen periodischen Job über die SM37 führt zum Abbruch mit Joblog-Meldung "Internal error getting container, RC= 4". Siehe dazu SAP-Hinweis 398589.
Periodischer Import All bei vorgeschaltetem QA-System
Das funktioniert nicht ohne eine spezielle Konfiguration mit einem virtuellen System (Import_all scheitert, weil Transporte in der Importqueue noch nicht genehmigt sind). Lösung: siehe SAP-Hinweis 313991.
Löschung von TA's eines oder mehrerer Projekte aus der Importqueue
geht mit Programm RSTMS_DEL_PROJECT_FROM_QUEUE (sollte auch im Batch funktionieren).
Weiterleitung von genehmigten TA's
Programm RSTMS_DIST_APPROVED_REQUESTS
Wer hat einen bestimmten Transportauftrag importiert?
Das (u.a.) steht in der Tabelle TPLOG, Einsicht über SE16. Selektion: SYDATE von / bis, CLIENT = Importmandant, CMDSTRING = "IMPORT*<TA-Nummer>*"
Oder: mit AL11 in DIR_TRANS/log/ALOGjjkw.SID nachsehen.
Oder: in der Importhistorie "Bearbeiten" -> "Mehr anzeigen" wählen.
Welcher Transportauftrag hat Tabelleneinträge geändert / gelöscht?
Transaktion SE03, "Objekte in Aufträgen/Aufgaben suchen". Dann mehrere Möglichkeiten abklappern:
R3TR TDAT (Tabellenname) Customizing: Tabelleninhalte
R3TR TABU (Tabellenname) Tabelleninhalt
R3TR VDAT (Viewname) Viewpflege: Daten
Bei der Suche nach Daten aus Viewpflege müssen die Views nacheinander abgeklappert werden, in denen die Tabelle verwendet wird (Verwendungsnachweis in SE11 -> Verwendung in Views).
Erklärung der tp-Fehlercodes
Aufruf von tp mit EXPLAINRC <RC> pf=<TMS-Parameter-Datei>, also z.B. so für Erklärung tp-Fehler 152:
/...sapmnt/exe/tp explainrc 152 pf=/...trans/bin/TP_DOMAIN_<SID>.PFL
Statusanzeige Transportsystem
Transaktion SE07
(Automatische) Übertragung der Transportdateien zwischen Transportgruppen (Queue-Abgleich)
mit Report RSTMSTIQ. Nur nötig, wenn das vorgeschaltete System einer anderen Transportgruppe zugeordnet ist.
Parameter: Transportgruppe des in der TMS-Konfiguration vorgelagerten Systems eintragen und alle Markierungen setzen.
Variante SAP_LOC_GROUPS tut's i.d.R. aber auch.
Änderung eines bereits freigegebenen Transportauftrages
mit Report RDDIT076
Massenfunktion für Rollentransport:
(Aufnahme von Rollen in Transportaufträgen)
Programm PFCG_MASS_TRANSPORT
Weitere ggf. nützliche Programme:
(im Einzelfall zu prüfen, etliche Programme werden im STMS-Umfeld über die entsprechenden Funktionen aufgerufen)

  • /SDF/CMO_TR_CHECK   Prognose von transportbezogenen Fehlern, bevor die Aufträge in ein Zielsystem importiert werden. -> siehe SAP-Hinweis 2475591 - Report für Transportprüfung.
  • RDDKOR60  Anzeige von After-Import-Methoden (entweder für einen einzelnen Auftrag oder für alle Objekte). Die Methoden sind auch in Tabelle OBJM ersichtlich, oder in Transaktion SOBJ > BC-Set-Kompatibilität.
  • RSTMS_ACTIVATE_ALL_REQUESTS TMS: inaktive Aufträge einer Importqueue aktivieren
  • RSTMS_CHANGE_DOMAIN_NAME TMS: Name der Transportdomäne ändern
  • RSTMS_DEL_PROJECT_FROM_QUEUE TMS: Alle Aufträge zu einem Projekt aus Importqueue löschen
  • RSTMS_DISPLAY_CTS_ALERTS TMS: CTS-Alerts anzeigen
  • RSTMS_DIST_APPROVED_REQUESTS TMS: Genehmigte Aufträge Weiterleiten
  • RSTMS_IMPORT_MONITOR TMS: Importübersicht anzeigen
  • RSTMS_IMPORT_OVERVIEW TMS: Importübersicht anzeigen
  • RSTMS_IMPORT_QUEUE TMS: Importqueue anzeigen
  • RSTMS_IMPORT_TRACKING TMS: Importübersicht anzeigen
  • RSTMS_ORGANIZER_WEBUI TMS: Start Transport Organizer Web UI
  • RSTMS_QUALITY_ASSURANCE TMS: QA Arbeitsvorrat anzeigen
  • RSTMS_SYSTEM_OVERVIEW TMS: Systemübersicht anzeigen
  • RSTMS_TRANSPORT_PATH TMS: Importübersicht anzeigen
  • RSTMS_UPLOAD_TP_PROFILE TMS: tp-Profil lesen und Konfiguration am Controller anpassen
  • RSTMS_WORKFLOW_INBOX TMS: Importqueue anzeigen
  • RSTMSAMO TMS: Alert Monitor
  • RSTMSCBU TMS: Importqueue prüfen
  • RSTMSCDI TMS: Transportverzeichnis prüfen
  • RSTMSCOL TMS: Importqueues in lokale Puffer lesen
  • RSTMSCON TMS: RFC-Verbindungen monitoren
  • RSTMSDIC TMS: Konfiguration anzeigen
  • RSTMSIMP TMS: Aufträge der Importqueue importieren
  • RSTMSQADEL TMS: Korrekturprogramm für QA-Vorrat (siehe SAP-Hinweis 716009 - TMS-QA: Löschen von Aufträgen aus dem QA-Arbeitsvorrat)
  • RSTMSTIQ TMS: Importqueue aus fremder Gruppe übertragen
  • RSTMSTOC TMS: Transport-Objektlisten prüfen
  • RSTMSTPL TMS: tp-Systemlog anzeigen
  • RSTMSTPP TMS: tp-Parameter anzeigen
  • RSTMSTPT TMS: tp-Schnittstelle prüfen
  • RSWBO_ADJUST_REQUEST_TARGETS Korrigiert Auftragsziele nach Umbau der Systemlandschaft
  • RSWBO_AUX_PROJECT Arbeiten mit CTS-Projekten ohne IMG
  • RSWBO_CHECK_TLOCK Konsistenzprüfung der Sperrtabelle
  • RSWBO_CURRENT_PROJECT Arbeiten mit CTS-Projekten ohne IMG
  • RSWBO_DELETE_SAPNAMES oder RSWBOSOS SAPNAMES-Datei eines Benutzers löschen
  • RSWBO_OBJCAT Objektkatalogeinträge ändern
  • RSWBO004 Systemänderbarkeit setzen
  • RSWBO005 Globales Customizing Transport Organizer
  • RSWBO0052 Globales Customizing Transport Organizer
  • RSWBO006 Auftragsattribute anzeigen/ändern
  • RSWBO010 Selektion von Objekten
  • RSWBO011 Freigabe im Hintergrund (wahlweise mit Objektprüfungen)
  • RSWBO019 Modification Browser
  • RSWBO020 Reparierte Objekte anzeigen
  • RSWBO040 Objekte in Aufträgen/Aufgaben suchen
  • RSWBO050 Objekte in Aufträgen/Aufgaben analysieren
  • RSWBO051 Objektkatalogeinträge von Objekten eines Auftrags ändern
  • RSWBO052 Objektkatalogeinträge ändern
  • RSWBO053 Objektkatalogeinträge von Objekten eines Auftrags anzeigen
  • RSWBO054 Umzugstransport rückgängig machen
  • RSWBO055 Pakete anzeigen/ändern
  • RSWBO060 Objekte in einen Transportauftrag aufnehmen
  • RSWBO070 Objektlisten vereinigen
  • RSWBO071 Aufträge mergen (für Hintergrundverarbeitung)
  • RSWBO072 Objektlisten vereinigen (Darstellung als Liste)
  • RSWBO080 Aufruf der erweiterten Tabellenpflege für Namensraumtabellen
  • RSWBO081 Namensräume anzeigen/ändern
  • RSWBO084 Anpassung der Namensraumrollen für SAP-interne Systeme
  • RSWBO085 Namensraum: Direkte Aktivierung (Übernahme in Laufzeittabelle)
  • RSWBO088 Selektion von unbestätigten Reparaturen (zu freigegebenen Aufträgen)
  • RSWBO095 Protokolle CTO anzeigen
  • RSWBO099 Objekte entsperren (Expertentool)
  • RSWBO111 Aufruf der erweiterten Tabellenpflege für Namenskonventionen (V_TR
  • RSWBO112 Namenskonventionen anzeigen/ändern
  • RSWBO113 Namensraum-Infosystem
  • RSWBO113_DATA Namensraum-Info-System, Include globale Daten
  • RSWBO113_LISTE Namensraum-Infosystem, Include Objektliste
  • RSWBO113_NAME Namensraum-Infosystem, Include Objektnamen
  • RSWBO113_NCONV Namensraum-Infosystem, Include Namenskonventionen
  • RSWBO113_NSPACE Namensraum-Infosystem, Include Namensräume
  • RSWBO114 Aufruf der Viewpflege für Namenskonventionen (CTRESNAME)
  • RSWBO230 Löschen von Upgrade Commandfiles (Release 3.0 und höher)
  • RSWBO301 Nummernvergabe bei Aufträgen: Freies Intervall suchen
  • RSWBODBC Installationsnachbereitung Datenbankkopie
  • RSWBODVC Pakete suchen
  • RSWBOINS SE06 für Installation im Batch
  • RSWBOINST_CLEAN Initialization of CTS
  • RSWBOSDR Aufträge suchen
  • RSWBOSOS Hotline Tools (Auftragskopf bearbeiten, Objekte entsperren, ADO-Import ausführen, SAPNAMES-Datei eines Benutzers löschen, Noteditor, Namensräume anzeigen/ändern (erweitert))
  • RSWBOUP1 Eigene Upgrade-Phase für WBO-Anpassungen
QA-Arbeitsvorrat
steht in den Tabellen TMSQWLF, TMSQNOTES, TMSQWL, TMSQLASTWL
Wird der QA-Vorrat aus einem Nicht-QA-System heraus aufgefrischt, erscheinen inzwischen (im QA-System) gelöschte Transporte erneut. Dafür gibt es ein Korrekturprogramm (siehe SAP-Hinweis 716009 - TMS-QA: Löschen von Aufträgen aus dem QA-Arbeitsvorrat).
Bei einem System-Refresh sollten solche Tabellen aber ohnehin vorher gesichert und nachher wieder eingespielt werden - entweder per PCA-Tool oder mit "Shortcut for SAP systems".
Auftragsattribute verwalten (Definition, als obligatorisch bestimmen etc.)
Programm RSWBO006



]]> Wed, 01 Jun 2022 12:23:00 GMT https://sap-basis.x10.bz/blog/?tms https://sap-basis.x10.bz/blog/rss/00000001A