Fehlersuche wo man nicht debuggen kann
Beitrag
von a-dead-trousers (Top Expert / 4285 / 214 /
1141
)
»
Im Zweifel würde ich immer ein ASSERT einem reinen LOG-POINT vorziehen.
Wenn man den Fehlerzustand kennt, kann man diesen als Bedingung für das ASSERT verwenden und somit auch dessen "Qualität" verbessern.
Dank Checkpoint-Gruppen kann man außerdem ein ASSERT je nach Bedarf in einen BREAK-POINT oder LOG-POINT umschalten.
Wenn man den Fehlerzustand kennt, kann man diesen als Bedingung für das ASSERT verwenden und somit auch dessen "Qualität" verbessern.
Dank Checkpoint-Gruppen kann man außerdem ein ASSERT je nach Bedarf in einen BREAK-POINT oder LOG-POINT umschalten.
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
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Doch, die gibt es! Wenn die Firma es richtig macht, dann gibt es dafür einen Firefighter-User, den man für zwei Stunden nutzen kann.Unit605 hat geschrieben:[
Wenn DAS in einem Produktivsystem moeglich waere:: (dass entsprechende Berechtigungen vorliegen, um den Prozess debuggen zu können und vor allem Werte im Debugging ändern zu können.
kann ein Entwickler im Produktivsystem machen was er will, ohne irgendwelche Spuren zu hinterlassen!!!
Es wird wohl keine Firma geben, wo man so schnell die Berechtigung zum Debuggen UND!!! Aendern von Werte, in einem Produktivsystem, bekommt. Das waere schon grob fahrlaessig.
Danach wird man automatisch abgemeldet und das Kennwort wird zurück gesetzt. Alle Aktionen werden protokolliert.
Damit ist sichergestellt, dass man alle Aktionen nachvollzogen werden können und man trotzdem auch abends um 23:17 Uhr am Samstag die Möglichkeit hat, Schiefstände zu beheben oder Fehlerursachen zu analysieren.
ewx hat geschrieben:Doch, die gibt es! Wenn die Firma es richtig macht, dann gibt es dafür einen Firefighter-User, den man für zwei Stunden nutzen kann.Unit605 hat geschrieben:[
Wenn DAS in einem Produktivsystem moeglich waere:: (dass entsprechende Berechtigungen vorliegen, um den Prozess debuggen zu können und vor allem Werte im Debugging ändern zu können.
kann ein Entwickler im Produktivsystem machen was er will, ohne irgendwelche Spuren zu hinterlassen!!!
Es wird wohl keine Firma geben, wo man so schnell die Berechtigung zum Debuggen UND!!! Aendern von Werte, in einem Produktivsystem, bekommt. Das waere schon grob fahrlaessig.
Danach wird man automatisch abgemeldet und das Kennwort wird zurück gesetzt. Alle Aktionen werden protokolliert.
Damit ist sichergestellt, dass man alle Aktionen nachvollzogen werden können und man trotzdem auch abends um 23:17 Uhr am Samstag die Möglichkeit hat, Schiefstände zu beheben oder Fehlerursachen zu analysieren.
Wenn die Firma es richtig macht, wird sie dem "Firefigter-User" keine Debugger- UND Aenderungsberechtigung im Debugmodus geben.
Ich bin vertraut mit "Firecalls", die gibt es hier *USA* zu genuege und ist immer ein Riesenaufwand und dauert oft Tage, bevor der Firecall genehmigt wird.
Da steht aber bereits fest und es muss erklaert werden, was und wie (mit einem Fixer-Programm) man das Problem behebt. Da fuscht nicht irgendjemand mal mit Debuggerberechtigungen im P-System rum.
Any method established to provide emergency access to a secure information system. In the event of a critical error or abnormal end, unprivileged users can gain access to key systems to correct the problem. When a firecall is used, there is usually a review process to ensure that the access was used properly to correct a problem. These methods generally either provide a one-time use User ID or one-time password.
Hi,
wir haben debug Berechtigung im Produktivsystem, aber dürfen keine Feldwerte überschreiben.
Parallel Firefighter mit Protokollierung.
Hat sich eigentlich bewährt ist halt alles nicht mehr so einfach wie früher
Grüße
Frank
wir haben debug Berechtigung im Produktivsystem, aber dürfen keine Feldwerte überschreiben.
Parallel Firefighter mit Protokollierung.
Hat sich eigentlich bewährt ist halt alles nicht mehr so einfach wie früher
Grüße
Frank
1. hat nicht jeder Berechtigung für die firecall-Transaktion.Unit605 hat geschrieben:Da fuscht nicht irgendjemand mal mit Debuggerberechtigungen im P-System rum.
2. macht man das ja nicht "mal eben so", sondern erst dann, wenn es ein Problem gibt, das anders nicht gelöst werden kann.
3. Hat es nichts mit Pfuscherei zu tun, wenn man in einer Produktivumgebung prüft, ob durch die Änderung einer Variable ein Fehler behoben werden kann, der im QS-System ggfs nicht nachgestellt werden kann.
Aber "jeder" kann die Berechtigung bekommen, der ueberzeugend genug darlegt, das Problem beheben zu koennen.ewx hat geschrieben:1. hat nicht jeder Berechtigung für die firecall-Transaktion.Unit605 hat geschrieben:Da fuscht nicht irgendjemand mal mit Debuggerberechtigungen im P-System rum.
Auch DANN macht man das zu 99,99% bestimmt nicht, mit debuggen und Werte aendern waehrend des debuggens.ewx hat geschrieben:2. macht man das ja nicht "mal eben so", sondern erst dann, wenn es ein Problem gibt, das anders nicht gelöst werden kann.
ewx hat geschrieben:3. Hat es nichts mit Pfuscherei zu tun, wenn man in einer Produktivumgebung prüft, ob durch die Änderung einer Variable ein Fehler behoben werden kann, der im QS-System ggfs nicht nachgestellt werden kann.
Im Produktivsystme "prueft" oder "waehrend des debuggen Werte aendert"?
Mein Grundtenor war und ist: Entwickler mit Debuggerberechtigungen und Aenderungsberechtigungen im Debugger, im Produktivsystem, sind grob fahrlaessig.
Da war auch von einem Firecall noch gar keine Rede. Es gibt wohl immer irgendwelche Ausnahmen geben, bezueglich eines Firecalls oder Fehlerbehebung.
Oder willst Du mir jetzt weissmachen, dass das der uebliche Weg ist, Probleme zu beheben? Firecall, debuggen, Werte aendern...?
Oder, wie oft hast Du schon Fehler im Produktivsystem auf diese Weise geloest?
Ich habe eimal, und das war vor 20 Jahren ("wo alles noch anders war"), einen Schiefstand mit "unerlaubten" Tricks im P-System behoben.
Das war sogar noch mehr, als nur einen Wert im Debugger zu aendern. Heute wuerde ich das wahrscheinlich nicht mehr machen.
Nein, es ist eine Ausnahmesituation und es ist eine Möglichkeit.Unit605 hat geschrieben:Oder willst Du mir jetzt weissmachen, dass das der uebliche Weg ist, Probleme zu beheben? Firecall, debuggen, Werte aendern...?
Mit keiner Silbe habe ich angedeutet, dass es der übliche Weg wäre oder sein sollte.
Deine Antwort auf mein Posting klang da irgendwie anders. Naemlich so, als ob jede Firefighter die Debug-Berechtigungen inklusive Aenderungsberechtigungen bekommt und fuer zwei Stunden nutzen kann.ewx hat geschrieben:Doch, die gibt es! Wenn die Firma es richtig macht, dann gibt es dafür einen Firefighter-User, den man für zwei Stunden nutzen kann.Unit605 hat geschrieben:[
Wenn DAS in einem Produktivsystem moeglich waere:: (dass entsprechende Berechtigungen vorliegen, um den Prozess debuggen zu können und vor allem Werte im Debugging ändern zu können.
kann ein Entwickler im Produktivsystem machen was er will, ohne irgendwelche Spuren zu hinterlassen!!!
Es wird wohl keine Firma geben, wo man so schnell die Berechtigung zum Debuggen UND!!! Aendern von Werte, in einem Produktivsystem, bekommt. Das waere schon grob fahrlaessig.
Danach wird man automatisch abgemeldet und das Kennwort wird zurück gesetzt. Alle Aktionen werden protokolliert.
Damit ist sichergestellt, dass man alle Aktionen nachvollzogen werden können und man trotzdem auch abends um 23:17 Uhr am Samstag die Möglichkeit hat, Schiefstände zu beheben oder Fehlerursachen zu analysieren.
Bei uns gingen die Firecalls so weit, dass man als Entwickler ueberhaupt Zugriff auf das P-System bekommt und dann dort debuggen konnte, aber nichts im Debugger aendern konnte, um das Problem zu finden.
Und evtl. das man transportierte Programm ausfuehren konnte, die das Problem loesen sollten.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Und letztlich kommt man darauf, dass bei einem wirklich kompetenten Entwickler dieser ganze Sicherheitskram nichts bringt, weil er letztlich ohnehin an allen Sicherheitsmaßnahmen umgehen kann. Was er - wenn er wirklich "gut" ist - natürlich nicht tun wird. Das Sicherheitsgedöns erhöht nur die Hemmschwelle und - im besten Falle - den Schwierigkeitsgrad. Verhindern kann man damit nicht, dass jemand Mist baut.
Spätestens, sobald im Systemverbund ein SAP-User zur Verfügung steht, kann man das nicht mehr aufhalten....
SCNR
Spätestens, sobald im Systemverbund ein SAP-User zur Verfügung steht, kann man das nicht mehr aufhalten....
SCNR
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
3
Antw.
Antw.
505
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.