Quellcode im Debugger einschleusen!?
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Hallo ,
ist es möglich im SAP Debugger nicht vorhandenen Quellcode einzuschleusen oder den vorhandenen Quellcode zu manipulieren?
Problem ist, dass ich manche Situationen im Entwicklungssystem nicht nachstellen kann und nicht gefühlte 1000 Transporte auf die Testumgebung schicken möchte um den Fall nachzustellen.
Gruss
DonOssi
ist es möglich im SAP Debugger nicht vorhandenen Quellcode einzuschleusen oder den vorhandenen Quellcode zu manipulieren?
Problem ist, dass ich manche Situationen im Entwicklungssystem nicht nachstellen kann und nicht gefühlte 1000 Transporte auf die Testumgebung schicken möchte um den Fall nachzustellen.
Gruss
DonOssi
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von jensschladitz (Specialist / 417 / 0 /
56
)
»
Sali,
kommt darauf an was du machen willst genau - aber schau dazu mal generate Subroutinen Pool in der Docu an - müsstest also in deinen Programm so etwas einbauen - da kann man schon während der Laufzeit Coding generieren und ausführen - aber wie gesagt - ist abhängig was du echt machen willstund ob da dann der Aufwand lohnt.
Gruss Jens
kommt darauf an was du machen willst genau - aber schau dazu mal generate Subroutinen Pool in der Docu an - müsstest also in deinen Programm so etwas einbauen - da kann man schon während der Laufzeit Coding generieren und ausführen - aber wie gesagt - ist abhängig was du echt machen willstund ob da dann der Aufwand lohnt.
Gruss Jens
thanks Jens
Beitrag
von a-dead-trousers (Top Expert / 4400 / 223 /
1182
)
»
Böse, Böse, Bösedonossi hat geschrieben:Hallo ,
ist es möglich im SAP Debugger nicht vorhandenen Quellcode einzuschleusen oder den vorhandenen Quellcode zu manipulieren?
Problem ist, dass ich manche Situationen im Entwicklungssystem nicht nachstellen kann und nicht gefühlte 1000 Transporte auf die Testumgebung schicken möchte um den Fall nachzustellen.
Richtige Antwortblack_adept hat geschrieben:Nein.
Man sollte niemanden dazu ermutigen zur Bösen Seite der Macht zu wechseln.jensschladitz hat geschrieben:kommt darauf an was du machen willst genau - aber schau dazu mal generate Subroutinen Pool in der Docu an - müsstest also in deinen Programm so etwas einbauen - da kann man schon während der Laufzeit Coding generieren und ausführen - aber wie gesagt - ist abhängig was du echt machen willst und ob da dann der Aufwand lohnt.
Anakin Skywalker ist der beste Beweis dafür.
Besser: Genau überlegen wo der Fehler zustande kommt und dann z.B. ein ASSERT einfügen. Disen kann man dann noch mit einer Check-Point Gruppe versehen.
Die Check-Point Gruppe kann man dann per User/System ein- und ausschalten. Mithilfe des ASSERT kann man die Ausführung des Check-Points einschränken, sodass nur im Fehlerfall z.B. der Debugger aufgeht oder ein Logging passiert.
Die Check-Point Gruppen, ASSERT usw. gibts aber erst seit Basis 7.0
Alternativ kann man auch einen BREAK-POINT verwenden der von einem IF-Statement umgeben ist.
Und ja: Mit generate Subroutinen Pool könnte man natürlich eine Code Injection zur Laufzeit bewerkstelligen. Würde ich aber dringend davon abraten, das GSP überhaupt zu verwenden. Denn jeder der Debug-Berechtigungen hat, könnte damit Code einschleusen. Das ist ein ziemliches Sicherheitsrisiko.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Liihes
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von jensschladitz (Specialist / 417 / 0 /
56
)
»
Sali,
nun das mit dem Bösen etc. - ich mag theatralisches
- aber es ist eine reguläre ABAP Anweisung (noch nicht mal als obsolet oder so gekennzeichnet !) - die in bestimmten Fällen sicher auch (noch) ihre Berechtigung hat und sinnvoll einsetzbar ist - auch wenn es - so wie in der Docu selbst vermerkt - es andere Möglichkeiten der Dynamisierung hat und gibt im SAP Umfeld . Aber ein Call TA mit using BDCTAB - hat ja SAP geschichtlich gesehen eine andere Aufgabe / Einsatz gehabt und es hat in 99% der Fälle heute auch in diesem Bereich viele andere Möglichkeiten dies umzusetzen - aber auch diese Technik wird weiter eingesetzt - warum auch nicht !
Wie gesagt man muss schauen was man will und dann wie man es einfach für sich oder den Kunden lösen kann und wenn es am Ende gut ist - na dann Bestens .
In diesem Sinne - es führen viele Wege nach Rom oder so ...
Gruss Jens
nun das mit dem Bösen etc. - ich mag theatralisches
- aber es ist eine reguläre ABAP Anweisung (noch nicht mal als obsolet oder so gekennzeichnet !) - die in bestimmten Fällen sicher auch (noch) ihre Berechtigung hat und sinnvoll einsetzbar ist - auch wenn es - so wie in der Docu selbst vermerkt - es andere Möglichkeiten der Dynamisierung hat und gibt im SAP Umfeld . Aber ein Call TA mit using BDCTAB - hat ja SAP geschichtlich gesehen eine andere Aufgabe / Einsatz gehabt und es hat in 99% der Fälle heute auch in diesem Bereich viele andere Möglichkeiten dies umzusetzen - aber auch diese Technik wird weiter eingesetzt - warum auch nicht !Wie gesagt man muss schauen was man will und dann wie man es einfach für sich oder den Kunden lösen kann und wenn es am Ende gut ist - na dann Bestens .
In diesem Sinne - es führen viele Wege nach Rom oder so ...
Gruss Jens
thanks Jens
Was für Situationen denn zum Beispiel?donossi hat geschrieben: Problem ist, dass ich manche Situationen im Entwicklungssystem nicht nachstellen kann
Warum meinst du, dass sich der Sourcecode "verwandelt" nur weil du einen Fehler nicht nachstellen kannst?
kannst du dir denn nicht mit einem db dump oder ausm backup vom produktiv system eine virtuelle Sandbox aufbauen ? kann ich jedem empfehlen, SAP System als Server template im XEN oder vmware die grossen DB Disk's als iSCSI target auf irgend nem kleinem Disk array und fertig.donossi hat geschrieben:....
Problem ist, dass ich manche Situationen im Entwicklungssystem nicht nachstellen kann und nicht gefühlte 1000 Transporte auf die Testumgebung schicken möchte um den Fall nachzustellen. ....i
und mal ne entscheidene Frage: wozu habt ihr ein Testsystem wo anscheinend deine gefühlten 1000 Transporte nicht drin sind ?
<:: XING-Gruppe Tricktresor::>
Ich denke, er möchte nicht x mal an einer Codingstelle schrauben, dass ins Testsystem transportieren, dann ausprobieren, die nächste Änderung machen, diese rüberschieben...ratsnus hat geschrieben:und mal ne entscheidene Frage: wozu habt ihr ein Testsystem wo anscheinend deine gefühlten 1000 Transporte nicht drin sind ?
Zumindest rudimentäre Tests sollten auch auf einem Entwicklungssystem möglich sein, gibt aber öfter den Wunsch, das vor zuviel DB-Schrott zu bewahren. (Schöner als ein eigenes Testsystem ist dann ein eigener Testmandant, der hin und wieder neu aufgesetzt wird. Dem muss man zwar noch das Customizing hinterherschieben, aber ansonsten geht's.)
Wenn ich mit meiner Interpretation oben richtig liege, ist dass dann aber Versuch und Irrtum, kann klappen; aber oft ist eine saubere Analyse des Fehlers zielführender. Just my2cents.
(Was man hingegen machen kann, ist per Debugger immer wieder zu bestimmten Anweisungen zu springen. Dann muss man nicht unbedingt immer das Programm bis zu einer Stelle laufen lassen sondern kann sich stärker auf die Fehlerstelle konzentrieren.)
Beitrag
von black_adept (Top Expert / 4100 / 128 /
941
)
»
Aber das ScriptDebugging erlaubt dir m.W. nur Sachen zu machen, die du auch manuell im Debugger machen könntest. Also wenn du Debug/Replaceberechtigung hast könntest du Variablenwerte ändern.Dele hat geschrieben:Noch nicht oft verwendet. Doch mit ABAP Script-Debugging kann man schon einiges anstellen. Allerdings benötigt man glaube ich Debug/Replace Berechtigung dazu.
Aber die ursprüngliche Frage war ja, ob man auch eine Variable, die eine Referenz auf ein Objekt hält, leeren kann. Und das geht m.W. nicht und du wirst da wohl im Scriptdebugging dann auch nichts finden bzw. die Methode, die dich Variablen ändern lässt wird beim Versuch den Namen einer Objektreferenz zu übergeben dumpen.
Weil sie gerechtfertigt sind.deejey hat geschrieben:Verstehe nicht was die Belehrungen sollen, ist doch völlig egal wozu er es braucht
Beitrag
von ralf.wenzel (Top Expert / 3936 / 200 /
281
)
»
Also, wer so arbeitet, ist etwas hinter der Zeit. Es gibt genug Möglichkeiten, Fehler zu analysieren und gezielt zu beheben. Klar kann man Coding am Transportsystem vorbei in ein anderes System kopieren, aber es gibt für die Entwicklung nunmal festgelegte Deploying-Prozesse und die gibt es nicht aus Jux. Das SAP-Transportsystem ist auch deshalb so gut, weil es eben sehr ausgereift ist. Ich jedenfalls habe es zu schätzen gelernt. Und wenn ihr im Entwicklungssystem einen Fall nicht nachstellen könnt, solltest du analysieren, woran das liegt.
Ralf *wer den Unterschied zwischen einem SW-Entwickler und einem Programmierer sehen will, sehe sich diesen Thread an
Ralf *wer den Unterschied zwischen einem SW-Entwickler und einem Programmierer sehen will, sehe sich diesen Thread an
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Wo soll denn das Sicherheitsrisiko angesiedelt sein? Wenn man im Entwicklungs- oder Qualitätssicherungssystem zur Laufzeit herumpfuschelt, hat das keine betrieblichen Auswirkungen. Und im Produktivsystem sollte sowieso niemand Replace-Rechte im Debugger haben, sonst hat man ein Problem auf einer ganz anderen Ebene.adt hat geschrieben:Und ja: Mit generate Subroutinen Pool könnte man natürlich eine Code Injection zur Laufzeit bewerkstelligen. Würde ich aber dringend davon abraten, das GSP überhaupt zu verwenden. Denn jeder der Debug-Berechtigungen hat, könnte damit Code einschleusen. Das ist ein ziemliches Sicherheitsrisiko.
Beitrag
von a-dead-trousers (Top Expert / 4400 / 223 /
1182
)
»
Wenn du genau schaust, wird dir auffallen, dass ich das vor fünf Jahren gepostet habe. Da wusste ich noch nicht, dass die Debug-Ändern-Berechtigung extra vergeben werden kann.DeathAndPain hat geschrieben:Wo soll denn das Sicherheitsrisiko angesiedelt sein? Wenn man im Entwicklungs- oder Qualitätssicherungssystem zur Laufzeit herumpfuschelt, hat das keine betrieblichen Auswirkungen. Und im Produktivsystem sollte sowieso niemand Replace-Rechte im Debugger haben, sonst hat man ein Problem auf einer ganz anderen Ebene.adt hat geschrieben:Und ja: Mit generate Subroutinen Pool könnte man natürlich eine Code Injection zur Laufzeit bewerkstelligen. Würde ich aber dringend davon abraten, das GSP überhaupt zu verwenden. Denn jeder der Debug-Berechtigungen hat, könnte damit Code einschleusen. Das ist ein ziemliches Sicherheitsrisiko.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo,
gefühlte 1000 Transporte? Wird gerade alles im Rahmen eines Projektes umgebaut? Ansonsten sollte D-Q-P den gleichen Stand haben. Und wenn das D System so versaut ist, dann wäre zu überlegen ob man nicht mal vom P nach D transportiert um wieder einen wartbaren Zustand im D zu erreichen.
Wenn gerade alles im Rahmen eines Projektes umgebaut wird, wäre es durchaus legitim den BUG im Q (Besser 2. D-System) zu fixen und von Q nach P zu transporttieren und im D manuell nachzuziehen, muss ja dann sowieso komplett alles getestet werden. Aber wie solche Notfall Korrekturen ablaufen, sollte das Projekt vorher geklärt haben.
Viele Grüße
Alex
Ein Entwicklungssystem hat keine realistischen Testdaten, wenn überhaupt Daten für Tests da sind. Aber dafür gibt es QS Systeme mit (annonymisierten) Produktionsdaten. Wenn es sich im QS System nicht nachstellen lässt, dann muss der FB oder selber die Daten analog Prod anlegen.ralf.wenzel hat geschrieben:Und wenn ihr im Entwicklungssystem einen Fall nicht nachstellen könnt, solltest du analysieren, woran das liegt.
gefühlte 1000 Transporte? Wird gerade alles im Rahmen eines Projektes umgebaut? Ansonsten sollte D-Q-P den gleichen Stand haben. Und wenn das D System so versaut ist, dann wäre zu überlegen ob man nicht mal vom P nach D transportiert um wieder einen wartbaren Zustand im D zu erreichen.
Wenn gerade alles im Rahmen eines Projektes umgebaut wird, wäre es durchaus legitim den BUG im Q (Besser 2. D-System) zu fixen und von Q nach P zu transporttieren und im D manuell nachzuziehen, muss ja dann sowieso komplett alles getestet werden. Aber wie solche Notfall Korrekturen ablaufen, sollte das Projekt vorher geklärt haben.
Viele Grüße
Alex
Folgende Benutzer bedankten sich beim Autor A6272 für den Beitrag:
ralf.wenzel
Seite 1 von 1
Vergleichbare Themen
7
Antw.
Antw.
4678
Views
Views
7
Antw.
Antw.
15681
Views
Views
5
Antw.
Antw.
3788
Views
Views
2
Antw.
Antw.
2762
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.