Klasse in eigener LUW instanziieren
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Moin,
ich möchte gern ein Objekt instanziieren, das in einer eigenen LUW operiert (damit ich ein auf dieses Objekt isoliertes COMMIT WORK auslösen kann). Dazu würde ich die Funktionalitäten der Klasse cl_os_system nutzen, um eine neue Transaktion zu erzeugen und zu starten.
Das muss ich aber vor dem CREATE OBJECT machen, wenn ich das richtig verstehe. Das gefällt mir insofern nicht, als dass ein Aufrufer daran denken muss (das widerspricht meiner Definition von einem in sich geschlossenen Modul, das "für sich selbst sorgt").
Lieber sähe ich das Erzeugen der separaten LUW z. B. im CONSTRUCTOR. Wenn ich im CONSTRUCTOR bin, ist es für das Erzeugen der LUW aber schon zu spät, oder? Wann GENAU wird die Instanz erzeugt / gibt es im CONSTRUCTOR noch einen Zeitraum, zu dem die Instanz noch nicht besteht?
Folgeproblem: Es gibt ja keinen DESTRUCTOR, den ich ausprogrammieren könnte, damit die LUW nicht ohne COMMIT WORK beendet wird (ein einfaches / implizites Abbauen der LUW hat ja keinen COMMIT WORK zur Folge, oder?)....
Ralf *mit Fragezeichen auf der Stirn
ich möchte gern ein Objekt instanziieren, das in einer eigenen LUW operiert (damit ich ein auf dieses Objekt isoliertes COMMIT WORK auslösen kann). Dazu würde ich die Funktionalitäten der Klasse cl_os_system nutzen, um eine neue Transaktion zu erzeugen und zu starten.
Das muss ich aber vor dem CREATE OBJECT machen, wenn ich das richtig verstehe. Das gefällt mir insofern nicht, als dass ein Aufrufer daran denken muss (das widerspricht meiner Definition von einem in sich geschlossenen Modul, das "für sich selbst sorgt").
Lieber sähe ich das Erzeugen der separaten LUW z. B. im CONSTRUCTOR. Wenn ich im CONSTRUCTOR bin, ist es für das Erzeugen der LUW aber schon zu spät, oder? Wann GENAU wird die Instanz erzeugt / gibt es im CONSTRUCTOR noch einen Zeitraum, zu dem die Instanz noch nicht besteht?
Folgeproblem: Es gibt ja keinen DESTRUCTOR, den ich ausprogrammieren könnte, damit die LUW nicht ohne COMMIT WORK beendet wird (ein einfaches / implizites Abbauen der LUW hat ja keinen COMMIT WORK zur Folge, oder?)....
Ralf *mit Fragezeichen auf der Stirn
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
dann baue doch eine Service-Klasse drumherum.
Die Instanzerzeugung der eigentlichen Klasse setzt du auf PROTECTED.
Dann verbindest du Serviceklasse und ausführende Klasse durch FRIENDS.
Damit ist sichergestellt, dass die Instanz nur durch die Serviceklasse erzeugt werden darf.
Die Instanzerzeugung der eigentlichen Klasse setzt du auf PROTECTED.
Dann verbindest du Serviceklasse und ausführende Klasse durch FRIENDS.
Damit ist sichergestellt, dass die Instanz nur durch die Serviceklasse erzeugt werden darf.
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Dann kann ich auch die Indizierung auf PRIVATE setzen und in GET_INSTANCE( ) mit dem Transaktionsgedöns anfangen (GET_INSTANCE( ) setzt ja kein Singleton voraus, ich kann damit auch beliebig viele Instanzen erzeugen). Dann ist aber nicht gesichert, dass die Transaktion auch korrekt abgebaut wird.ewx hat geschrieben:dann baue doch eine Service-Klasse drumherum.
Die Instanzerzeugung der eigentlichen Klasse setzt du auf PROTECTED.
Dann verbindest du Serviceklasse und ausführende Klasse durch FRIENDS.
Damit ist sichergestellt, dass die Instanz nur durch die Serviceklasse erzeugt werden darf.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Nein, kannst du nicht, weil GET_INSTANCE - wie du ja selber geschrieben hast - innerhalb der eigenen Klasse erfolgt. Mit der Serviceklasse kannst du sicherstellen, dass dein CL_OS_SYSTEM verwendet wird.ralf.wenzel hat geschrieben: Dann kann ich auch die Indizierung auf PRIVATE setzen und in GET_INSTANCE( ) mit dem Transaktionsgedöns anfangen (GET_INSTANCE( ) setzt ja kein Singleton voraus, ich kann damit auch beliebig viele Instanzen erzeugen).
Das ist richtig. Ist aber kein Argument gegen meine Lösung für die Kapselung.ralf.wenzel hat geschrieben:Dann ist aber nicht gesichert, dass die Transaktion auch korrekt abgebaut wird.
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Das verstehe ich nicht - wenn ich GET_INSTANCE mit den Methodenaufrufen von CL_OS_SYSTEM beginne und erst dann das CREATE OBJECT mache, hab ich dieselbe Funktionalität wie mit einer Serviceklasse - aber eben ohne Serviceklasse.ewx hat geschrieben:Nein, kannst du nicht, weil GET_INSTANCE - wie du ja selber geschrieben hast - innerhalb der eigenen Klasse erfolgt. Mit der Serviceklasse kannst du sicherstellen, dass dein CL_OS_SYSTEM verwendet wird.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
ok. war ja auch nur eine Idee.
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Wenn du jetzt noch eine hast, die ein definiertes LUW-Ende ermöglicht.... Leider gibt es im ABAP keine Destruktoren, die zwangsweise durchlaufen werden (wie ein Teardown bei Testklassen).
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4134 / 131 /
956
)
»
Doch - die gibt es. Aber da darfst du nichts drin machen, so dass es für dich de facto doch keine gibt ( Versuch doch einfach mal eine Methode mit dem Namen DESTRUCTOR anzulegen und schau was für Meldungen SAP in dem Fall für dich parat hat ).ralf.wenzel hat geschrieben:Wenn du jetzt noch eine hast, die ein definiertes LUW-Ende ermöglicht.... Leider gibt es im ABAP keine Destruktoren, die zwangsweise durchlaufen werden (wie ein Teardown bei Testklassen).
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Als wäre ich nicht schon vor Jahren (als ich aus anderen Gründen einen Destruktor brauchte) schon auf die Idee gekommen 
Was geht: Abstrakte Methode, die implementiert werden *muss*. Dann vergisst der Entwickler das schonmal nicht, sondern wird darauf gestoßen, dass da noch was fehlt.
Besser als nix.
Ralf
Was geht: Abstrakte Methode, die implementiert werden *muss*. Dann vergisst der Entwickler das schonmal nicht, sondern wird darauf gestoßen, dass da noch was fehlt.
Besser als nix.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ich nehme mal an, das hattest Du Dir angeschaut ?
https://help.sap.com/doc/abapdocu_750_i ... n_mode.htm
https://help.sap.com/doc/abapdocu_750_i ... n_mode.htm
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Das ist der Grund meiner Frage 
Zwischen START und END muss ich halt mein Objekt instanziieren, dann soll es was machen und bei das END muss halt zuverlässig ausgeführt werden. Das soll das Objekt idealerweise alles selbst machen, damit der Aufrufer das nicht wissen muss, dass er das managen muss.
Ralf
Zwischen START und END muss ich halt mein Objekt instanziieren, dann soll es was machen und bei das END muss halt zuverlässig ausgeführt werden. Das soll das Objekt idealerweise alles selbst machen, damit der Aufrufer das nicht wissen muss, dass er das managen muss.Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wenn die Transaktion nicht im Kompatibilitätsmodus gestartet wird, sondern als OO Transaktion ist kein explizites Commit Work nötig. Somit benötigst Du auch keinen Destructor. Zumindest, wenn Du Dich mit dem Persistenzdienst rumschlagen willst.ralf.wenzel hat geschrieben:Moin,
ich möchte gern ein Objekt instanziieren, das in einer eigenen LUW operiert (damit ich ein auf dieses Objekt isoliertes COMMIT WORK auslösen kann). Dazu würde ich die Funktionalitäten der Klasse cl_os_system nutzen, um eine neue Transaktion zu erzeugen und zu starten.
Das muss ich aber vor dem CREATE OBJECT machen, wenn ich das richtig verstehe. Das gefällt mir insofern nicht, als dass ein Aufrufer daran denken muss (das widerspricht meiner Definition von einem in sich geschlossenen Modul, das "für sich selbst sorgt").
Lieber sähe ich das Erzeugen der separaten LUW z. B. im CONSTRUCTOR. Wenn ich im CONSTRUCTOR bin, ist es für das Erzeugen der LUW aber schon zu spät, oder? Wann GENAU wird die Instanz erzeugt / gibt es im CONSTRUCTOR noch einen Zeitraum, zu dem die Instanz noch nicht besteht?
Folgeproblem: Es gibt ja keinen DESTRUCTOR, den ich ausprogrammieren könnte, damit die LUW nicht ohne COMMIT WORK beendet wird (ein einfaches / implizites Abbauen der LUW hat ja keinen COMMIT WORK zur Folge, oder?)....
Ralf *mit Fragezeichen auf der Stirn
Zu deinem "selbst sorgenden Modul" ... das hat auch oft Nachteile. Ein implizites Commit work könnte je nach Anwendungsfall zu inkonsistenten Daten führen, ausser die Daten hätten auch einen Sinn, wenn die Rufende Transaktion keinen Anteil daran hat.
"Code lügt nicht ^^"
ralf.wenzel hat geschrieben:Das ist der Grund meiner Frage
Ralf
Du rufst einen OO-Transaktion oder ? Dann passiert das auch so wie Du es möchtest. Nur wenn Du keine OO Transaktion verwendest, ist das explizite Commit Work nötig. Das Beispiel zwischen START und END, findet doch in der Klasse statt, die du über die OO Transaktion rufst.
Wenn Du also aus einer OO Transaktion deine OO Transaktion startetest sollte es passen.
https://rvanmil.wordpress.com/2011/04/1 ... n-service/
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3950 / 202 /
281
)
»
Ich rufe keine OO-Transaktion. Ich möchte einfach einen Prozess in einer eigenen LUW durchführen, um einen vom Hauptprozess unabhängigen commit ausführen zu können.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4451 / 227 /
1197
)
»
Hallo Ralf.
Ich weis nicht ob du das jetzt hören möchtest, aber in solchen Fällen weiche ich immer auf RFC-fähige Funktionsbausteine aus.
Eigentlich bin ich ja auch ein Verfechter der "reinen" Lehre, aber leider hab auch ich bislang in ABAP-OO noch nichts gefunden, was den laufenden Prozess von der LUW "loskoppelt". Wenn ich soetwas brauche kapsle ich meine Datenhaltung immer in eigenen Datenobjekten (DAO). Wenn dann eine Persistierung notwendig wird, rufen diese dann die zugehörigen RFC-Funktionsbausteine mit Destination NONE und somit auf einer anderen LUW als der Hauptprozess auf.
lg ADT
Ich weis nicht ob du das jetzt hören möchtest, aber in solchen Fällen weiche ich immer auf RFC-fähige Funktionsbausteine aus.
Eigentlich bin ich ja auch ein Verfechter der "reinen" Lehre, aber leider hab auch ich bislang in ABAP-OO noch nichts gefunden, was den laufenden Prozess von der LUW "loskoppelt". Wenn ich soetwas brauche kapsle ich meine Datenhaltung immer in eigenen Datenobjekten (DAO). Wenn dann eine Persistierung notwendig wird, rufen diese dann die zugehörigen RFC-Funktionsbausteine mit Destination NONE und somit auf einer anderen LUW als der Hauptprozess auf.
lg ADT
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
Vergleichbare Themen
0
Antw.
Antw.
629
Views
Views
Übernahme von Klassifizierungsdaten von Vorlagematerial beim Instanziieren in CU51
von Max_SAP » 29.05.2020 09:55 • Verfasst in Material Management & Produktionsplanung
von Max_SAP » 29.05.2020 09:55 • Verfasst in Material Management & Produktionsplanung
1
Antw.
Antw.
3594
Views
Views
Lokale Klasse autom. in globale Klasse ändern
von JohnLocklay » 09.01.2019 09:10 • Verfasst in ABAP Objects®
von JohnLocklay » 09.01.2019 09:10 • Verfasst in ABAP Objects®
5
Antw.
Antw.
4722
Views
Views
Klasse soll Typdefinition von anderer Klasse nutzen
von debianfan » 24.05.2017 11:30 • Verfasst in ABAP Objects®
von debianfan » 24.05.2017 11:30 • Verfasst in ABAP Objects®
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.
Aktuelle Forenbeiträge
Unbeantwortete Forenbeiträge
Nutzung UserExit COOM0003 für Abrechnungsvorschriften Aufträge
vor 2 Tagen von fico_fschluesener 1 / 157
vor 2 Tagen von fico_fschluesener 1 / 157