Abfangen von /h

Abfangen von /h

ist es eigentlich möglich, daß Einschalten des Debugging über /h oder übers Menü als solches abzufangen?

Man hat hier die glorreiche Idee, das zu tun, um den Anwender auf sein schändliches Tun in Prod.-Systemen hinzuweisen.

jau, würde ich ja auch gerne so sehen, aber man meint die Berechtigung zum Debuggen soll generell erhalten bleiben (braucht man ja manchmal). Allerdings soll das dann generell protokolliert werden.

Ich dachte eigentlich, es gabe ein Möglichkeit, die ohne irgendwelche Eingriffe in den Standard zu realisieren, habs auch noch nicht ganz aufgegeben.

SAMMSSY3 ist schon mal gut. Allerdings würde ich dann eher im Fuba SYSTEM_DEBUG_AUTHORITY_CHECK eingreifen wollen, wenn es sich denn gar nicht vermeiden lässt.

Nichts ist schlimm am debuggen (meistens )

Aber des Kunden Wunsch ist sein Himmelreich, nicht wahr. Debuggen mit Feldwertänderung wird eh im Syslog protokolliert.

Und da hier etliche Programmierer regen Gebrauch vom debuggen in Prod.-Systemen machen, will man damit wohl ein wenig auf Abschreckung setzen.

ähhh versteht mich nicht falsch. Ich hab nix gegen debuggen, auch braucht man das hie und da im Prod-System. Man will das ja auch nicht unterbinden, aber aus Revisionsgründen zumindest protokollieren.

Moinsen nochmal.

Ich würde da eine organisatorische Regelung durchsetzen:
- Programmierer haben im Prod-System einen User ohne Debug-Berechtigung.
- Es gibt einen User *mit* Debug-Berechtigung, dessen Passwort nur einer "übergeordneten Stelle" bekannt ist; genau der Stelle, die die Debugging-Tätigkeit kontrollieren will.
- Wenn debuggt werden muss bekommt der verantwortliche Programmierer das Passwort des Debug-Users. Dieses Passwort wird natürlich anschließend wieder zurückgesetzt.

Es kann dann natürlich passieren, dass ein Fehler nicht sofort behoben werden kann, weil er nur mit Nutzung des Debuggers gefunden werden kann und die entsprechende Abteilung schon Feierabend hat. Darauf würde ich es aber ankommen lassen.

Gruss,
Haubi

/edit:
@Revision: wenn es eigentlich darum geht, dass die Personengruppe "Entwickler" z.B. keine HR-Daten sehen darf ist ein Debug-Verbot sowieso der falsche Ansatz. Da hilft dann nur der Einsatz eines Verschlüsselungstools...

Hi,

es gibt doch die Varianten debugging mit aktiviertem Stift (dann kann ich auch Tabellen ändern und mit SE16N
&sap_edit arbeiten) und debugging, wo der Stift nicht funktioniert.

Die erste Variante ist für Entwicklungssystem, die andere ist für Qualitätssicherungs-, Abnahme und Produktion.

Ich glaube das hängt am Berechtigungsobjekt S_DEVELOP.
02 für änderndes debugging
03 für nicht änderndes debugging.

@babap: Theoretisch hast du ja völlig recht - aber du gehst von der Annahme aus, dass im Testsystem überhaupt Daten zum Testen vorhanden sind bzw. der Kunde bereit und/oder in der Lage ist, relevante und hinreichend diverse Situationen abbildende Testdaten aufzubauen.

Und nach meinen Erfahrungen kann man sich darauf nicht per se verlassen.

babap hat geschrieben:Debugbetrieb im Produktivsystem belegt immer 2 Workprozesse pro Debugperson

Nein. Wie kommst Du darauf?
Es gibt einen Unterschied zwischen Debugging in Produktiv- und Testsystemen. Im Prod wird immer verhindert, dass der Debugg-Prozess wie ein normaler Dialog-Prozess behandelt wird man beim Debuggen die ber�hmte Meldung "COMMIT WORK vom System erzwungen" sieht.
Wenn das nicht geht, weil nicht gen�gend DIA-Prozesse frei sind, wird Debuggen im Produktivsystem nicht erlaubt.
Details dazu sind zu finden auf help.sap.com, bei der Beschreibung des Profile-Parameters rdisp/wp_dbug_max_no (wird in Produktivsystemen ignoriert und zieht nur f�r Testsysteme.)

und behindert durch das "verbrennen" der Rechnerzeit doch die Performance schon ziemlich.

Rechenzeit wird da nicht verbrannt.
Es wird nur der DIA-Prozess f�r die Debug-Session reserviert, damit der Roll-Out (und damit das implizite DB-Commit bei jedem Dialogschritt) verhindert werden kann.
Solange noch DIA-Prozesse frei sind (Status "wartet" in der SM50), hat das auf die Performance des Systems und die Wartezeit der User wenig Einfluss.

Bitte nicht �belnehmen, aber ein reger Debugbetrieb im Produktivsystem ist doch ein erster oder auch ernster Hinweise auf Qualit�tsm�ngel bei den verwendeten Programmen.
Programme sollten doch eigentlich erst ins Produktivsystem gespielt werden, wenn sie ausgiebig getestet und "gedebugt" worden sind ...

Sag das mal SAP.
Da habe ich seit Upgrade von 4.6C auf 6.20 schon einige SNOTE-Orgien hinter mir.
Und es gibt immer Konstellationen, die man in der Testphase nicht hatte.
Vorabkorrekturen, die neue Fehler einbauen und dann durch neue Hinweise verbessert werden, die wieder Fehler enthalten ...

Nat�rlich sollte man in den meisten F�llen in der Lage sein, die Fehler in einem Testsystem zu reproduzieren.
Und auch da, wo es nicht geht, halte ich von Debugging mit Berechtigung, Feldwerte im Debugger zu ändern (ACTVT = '02'), nicht viel.

PS.
abapforum.com mag mich heute nicht.
Die Umlaute sind schon wieder vermurkst (zumindest in meinem Browser).