Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

Re: Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

Also, du solltest dich mal damit auseinandersetzen, was an beiden Anweisungen so alles dranhängt, dann weißt du, dass auch ein COMMIT die schlechteste aller Möglichkeiten ist. Zudem bin ich entsetzt, dass gerade du dich solcher Methoden zulasten aller anderen auf dem System bedienen willst, deinen Dialog-Prozess am Laufen zu halten. Um es deutlich zu sagen: Wer soll denn einen Entwickler ernst nehmen, der sich solcher Frickelei bedient? Gestern habe ich einen mit Ducktape („Panzerband“) geklebten Mercedes gesehen (Kotflügel angeklebt), so etwa wirkt das auch.

Nimm wenigstens den SAPGUI Progress Indikator, wenn du dich solch zweifelhafter Mittel schon bedienen willst (was meist nicht notwendig ist). Aber selbst in unserem OO-basierten Modul für Blutspendedienste, das unter Berücksichtigung der enormen Datenmengen eigentlich sehr langsam sein müsste (wenn man deinen Ausführungen folgt) hatten wir solche Aktionen nicht nötig.


Ralf

Re: Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

Da er nichts anderes geschrieben hat, gehe ich davon aus, dass das Programm von ihm selbst ist. Und dann liegt der Designfehler bei ihm selbst, dann sollte er sich was einfallen lassen, warum das so lange läuft (er scheint ja über Laufzeiten und deren Ursache einiges zu wissen.

Man kann Vieles machen, wenn man das Programm kennt. Das ist bei mir nicht der Fall. COMMIT WORK ist einfach, aber normalerweise nicht notwendig und arbeitet zum Schaden anderer. Ich hab z. B. schon Teile von Programmen in den Hintergrund verlagert. Das wäre ggf. eine Alternative, die in jedem Falle besser ist.

Ralf

Re: Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

Solche Andorderungen sind sehr, sehr selten und zumeist technisch fehlerhaft. Und selbst dann gibt es bessere Möglichkeiten.

Eine Möglichkeit habe ich genannt: Progress Indikator. Soweit ich weiß, hilft der auch.


Ralf

Re: Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

Den FuBa kenne ich, aber solange ich nicht ganz genau weiß, was der wie tut, rühre ich den nicht an.

Ralf

Re: Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

Erst mal vielen Dank für die Antworten.

@Ralf: Das Programm ist nicht von mir, aber ich habe es vor einigen Jahren von der externen Beraterfirma, die es einst programmiert hat, geerbt und betreue es seitdem. Es berechnet die Datenausgabe an einen externen Lohndatenabrechner. Zu diesem Zweck rennt es durch den ganzen Personalstamm und berechnet für jeden Mitarbeiter die auszugebenden Daten. Dabei muss es Stammdaten, Zahlungsdaten, Abwesenheitsdaten usw. ausgeben mit der Maßgabe, dass nur Daten ausgegeben werden sollen, die sich seit dem letzten Lauf geändert haben, so dass ein umfangreiches Logging der eigenen Ausgabe erforderlich ist. Bei vielen Daten ist dabei noch Detailcoding vorhanden. Das Ganze hat einen erheblichen Komplexitätsgrad.

Der Code war sehr mies strukturiert. Es handelt sich um ein OO-Programm, bei dem das OO darin besteht, dass ein einziges Objekt erzeugt wird und im Constructor der gesamte Nutzcode steht. Anstelle von Formroutinen werden lokale Methoden verwendet. That's OO for you. Auch sonst fand ich den Code alles andere als dolle, und gerade angesichts der Komplexität des Ganzen ist gute Strukturierung durchaus wichtig. Deswegen habe ich den Code grundlegend überarbeitet, musste dabei aber immer vorsichtig sein, denn es ist aus offensichtlichen Gründen (Gehälter sind in HR das Herzblut) ein sehr kritischer Report, der funktionieren muss, was er inzwischen auch ganz gut tut.

Du wirst lachen: Eine Hintergrundverarbeitung habe ich vor zwei Jahren oder so auch eingebaut, nebst der Möglichkeit, auf die Ergebnisse früherer Programmläufe zuzugreifen und sich die (geloggten) Ergebnisse derselben zu ziehen. Dies ist notwendig, da die Sachbearbeiter das Programm händisch starten und die Ergebnisdateien auf ihre lokalen PCs herunterziehen. Bei einem im Hintergrund, also ohne GUI, laufenden Programm geht das nicht, und meine Lösung besteht halt darin, dass sie nach Ende des Programmlaufs dieses erneut im Vordergrund starten und dann das zuvor berechnete Ergebnis herunterladen können. Hat nebenbei auch den Vorteil, dass bei ihnen nicht ewig ein SAPGui-Modus blockiert ist und sie nicht von vorne rechnen müssen, wenn mal nach erfolgten Berechnungen die Datenübertragung von Server zu SAPGui auf die Nase fällt (das hatten wir früher alles).

Über den ganzen Prozess kann man sicherlich diskutieren, aber: Never change a running system.

Die Ausführung im Vordergrund hat allerdings den Charme, dass man hinterher nicht nur csv-Dateien hat, die man sich in Excel zurechtformatieren kann, sondern auch komfortabel zwischen mehreren ALVs (einem pro Ergebnisdatei; es entstehen immer mehrere) blättern und die Daten darin durchsehen kann. Für Testläufe, also solche ohne Datenausgabe und Logging, ist dies sehr attraktiv, und im Personalwesen braucht man eigentlich immer Testläufe vor jeder Abrechnung, weil es immer irgendwelche fehlerhaften Personaldaten gibt, die man glattziehen muss, bevor man das wirklich in die Abrechnung gibt.

Um dies grundsätzlich möglich zu machen, habe ich gesagt, dann soll er im Testlauf halt regelmäßig einen COMMIT WORK machen. Da der Testlauf nichts macht, macht auch der COMMIT WORK nichts. Wir haben genug Serverleistung, und dann können die Sachbearbeiter nach einer Stunde oder wie lange das Ding läuft ihr Ergebnis anschauen. Die produktiven Daten rechnen sie dann über Nacht im Hintergrund (da will ich keine Zwischen-COMMITs haben, denn falls während des Programmlaufs irgendwas schiefgeht - und sei es, dass der Server mal abschmiert - will ich keine halb berechneten Lohnausgaben haben, da man die nie vernünftig ergänzt bekommt).

Nun musste ich aber feststellen, dass auch im Testlauf bestimmte Logänderungen vorgenommen werden, so dass Testläufe nachfolgende Produktivläufe verfälschen. Dies programmtechnisch zu ändern wäre nicht trivial, und die Gefahr wäre groß, dass ich mir bei den entsprechenden Umbauten neue Bugs einfange, die ich in diesem Programm aus offensichtlichen Gründen so gut wie möglich vermeiden möchte. Da war meine Idee, ob man das nicht einfach lösen kann, indem ich statt regelmäßiger COMMIT WORKs einfach regelmäßige ROLLBACK WORKs mache. Im Testlauf soll sich auf der Datenbank ja nichts verändern.

Mittlerweile kann ich sagen, dass ROLLBACK WORK den Timeout nicht zurücksetzt. So einfach geht es also nicht. Was ich aber jetzt im Testlauf mache, ist ein ROLLBACK WORK und gleich danach ein COMMIT WORK. Das funktioniert natürlich.

black_adept hat geschrieben:Bitte ausprobieren - das hängt vom System ab. ( -> https://archive.sap.com/discussions/thread/1620838.

Also soweit ich das diesem Thread entnehme, ging das allenfalls bis Release 7.00 und ist insofern heute keine Option mehr.

larsi hat geschrieben:Ich habe mir bislang immer mit der Klasse CL_SWF_UTL_TIMEOUT_SERVICE beholfen - die erreicht das nämlich ohne Verwendung von COMMIT WORK oder ROLLBACK.

Also wenn ich mir diese Klasse so in der SE24 anschaue, dann kann ich das kaum glauben. Die kann man ja mit einem Blick überschauen; die besteht ja nur aus wenigen Methoden, die jeweils nur wenige Befehle enthalten. Diese Befehle kommen mir zudem noch recht sinnlos vor (vor allem die Methode ON_TIMEOUT), aber gut, die Klasse ist nicht dokumentiert; ihr Autor wird sich schon was dabei gedacht haben.

Re: Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

Vielen Dank.

@Ralf: Etwas Recherche hat ergeben, dass der Funktionsbaustein TH_REDISPATCH durchaus dokumentiert ist, und zwar in Hinweis 25528.