Observerobjekt am Applikationsserver (erste Schritte in ABAP OO)
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo Experten,
da ich noch nicht viel im OO-Kontext gearbeitet habe krieg ich bei der Umsetzung der nachstehenden (kurz umrissenen) Anforderung einen Knopf im Kopf ...
ich habe (aktuell) etwas mehr als 40 Arbeitsplätze die ich über eine Änderung, die mit der DATA-Klasse durchgeführt werden, informieren muss ("Dashboard" ändern, Listenlayouts ändern,....je nach Transaktion (alle im Kundennamensraum) die ausgeführt wird)...
ich habe eine bestehende Klasse (ZCL_PP_DATA) durch ein Interface erweitert damit sie "überwachbar " wird.
Die Klasse liest/ändert Daten über Public-Methoden, beim Update sollen die Observer informiert werden. In einer Session funktioniert das - ich habe aber n Benutzer die sich bei der Klasse registrieren müssen um die Änderungen in deren Programm(en) bekannt zu machen (z.B. ein "Dashboard", ALV-Liste(n), ....)
Wie kann ich sicherstellen das nur eine Instanz der Klasse am Applikationsserver existiert an die ich mich als Observer anmelde?
Hab verschiedene Ansätze aus dem Forum versucht, komme aber nicht zum gewünschten Ergebnis, bzw. fehlt mir die Erfahrung. :/
Ich hätte an ein SharedMemory-Objekt gedacht in dem die Instanz dieser Klasse erzeugt wird, und diese über eine get-Methode zurückgibt damit ich meine Programme über die Klassenmethode registrieren kann das ich über Änderungen informiert werden möchte?
Geht das überhaupt und wenn ja wie müsste die DATA-Klasse definiert sein damit nur eine Instanz erzeugt werden kann?
Hoffe ich hab das einigermaßen verständlich erklärt was ich benötige bzw. umsetzen muss
In der Theorie klingt das alles ganz einfach, nur bei der Umsetzung fehlt mir die Erfahrung wie ich solche Objekte definieren muss damit das klappt
Wäre für Lösungsvorschläge wirklich sehr dankbar
Beste Grüße
aA
da ich noch nicht viel im OO-Kontext gearbeitet habe krieg ich bei der Umsetzung der nachstehenden (kurz umrissenen) Anforderung einen Knopf im Kopf ...
ich habe (aktuell) etwas mehr als 40 Arbeitsplätze die ich über eine Änderung, die mit der DATA-Klasse durchgeführt werden, informieren muss ("Dashboard" ändern, Listenlayouts ändern,....je nach Transaktion (alle im Kundennamensraum) die ausgeführt wird)...
ich habe eine bestehende Klasse (ZCL_PP_DATA) durch ein Interface erweitert damit sie "überwachbar " wird.
Die Klasse liest/ändert Daten über Public-Methoden, beim Update sollen die Observer informiert werden. In einer Session funktioniert das - ich habe aber n Benutzer die sich bei der Klasse registrieren müssen um die Änderungen in deren Programm(en) bekannt zu machen (z.B. ein "Dashboard", ALV-Liste(n), ....)
Wie kann ich sicherstellen das nur eine Instanz der Klasse am Applikationsserver existiert an die ich mich als Observer anmelde?
Hab verschiedene Ansätze aus dem Forum versucht, komme aber nicht zum gewünschten Ergebnis, bzw. fehlt mir die Erfahrung. :/
Ich hätte an ein SharedMemory-Objekt gedacht in dem die Instanz dieser Klasse erzeugt wird, und diese über eine get-Methode zurückgibt damit ich meine Programme über die Klassenmethode registrieren kann das ich über Änderungen informiert werden möchte?
Geht das überhaupt und wenn ja wie müsste die DATA-Klasse definiert sein damit nur eine Instanz erzeugt werden kann?
Hoffe ich hab das einigermaßen verständlich erklärt was ich benötige bzw. umsetzen muss
In der Theorie klingt das alles ganz einfach, nur bei der Umsetzung fehlt mir die Erfahrung wie ich solche Objekte definieren muss damit das klappt
Wäre für Lösungsvorschläge wirklich sehr dankbar
Beste Grüße
aA
SAP-Basis: 740
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Habe sowas mal mit ABAP Channels umgesetzt.
https://help.sap.com/doc/abapdocu_750_i ... annels.htm
Das OO-Pattern nützt dir in diesem Fall nichts, da jeder Arbeitsplatz seinen eigenen Speicher hat.
https://help.sap.com/doc/abapdocu_750_i ... annels.htm
Das OO-Pattern nützt dir in diesem Fall nichts, da jeder Arbeitsplatz seinen eigenen Speicher hat.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ein SAP-System kann man mit einem Webserver vergleichen:
Es werden immer ganze Seiten ausgeliefert auf denen der Benutzer etwas eingeben/ansehen und mit einem Funktionscode (Tastendruck, Mausklick, etc.) bestätigen kann. Danach werden die Daten wieder an den Server zurückgeschickt, der dann die entsprechende Verarbeitung auslöst und wieder eine (neue) Seite ausliefert.
Ein gemeinsames "Observerobjekt" kann man hiermit schon per Definition nicht einsetzen, weil die Benutzersessions unabhängig voneinander ablaufen. Streng genommen wäre "die Datenbank" oder "eine Datei am Applikationsserver" eine solche gemeinsame "Ressource". Wie rob_abc schon angemerkt hat, hat die SAP hier mehrere Ansätze (versucht) um dieses Dilemma etwas abzufedern:
ABAP Channels - Wobei ich hier nicht sicher bin, dass die über mehrere Benutzersessions funktionieren.
Shared Memory - Guter Ansatz um Daten am Server vorzuhalten und nicht jedes Mal die Datenbank zu "belasten". Besonders für Customzing, das sich nicht oft ändert geeignet. Für Bewegungsdaten eher schlecht geeignet. Hat sich aber meines Erachtens mit HANA erledigt.
Allen Ansätzen gemeinsam ist aber nachwievor das Ur-Patttern: Formular ausliefern > Eingabe von Daten > Formular abschicken > rinse and repeat
Einen "Observer" wird man damit nicht hinbekommen. Was aber ganz gut funktioniert ist ein automatisches "Polling". Sprich die laufende Applikation holt sich in bestimmten Intervallen die aktuellsten Infos von der Datenbank und bringt sie zur Anzeige.
Unter SAPgui (Dynpros) gibt es hierfür die Klasse CL_GUI_TIMER die dafür sorgt, dass der PAI/PBO Lauf kontinuierlich ausgelöst wird.
Unter "WebGUI" (BSP, Webdynpro, UI5, Fiori, etc) kann man das mittels JavaScript erreichen (teilweise out-of-the-box mit SAP Mitteln) um die ganze Seite (Refresh) oder nur einzelene Bereiche ("AJAX") zu aktualisieren
Das muss man dann aber auch so umsetzen, dass Benutzer nicht gleichtzeitig an einem Datensatz (Locking) oder mit veralteten Daten (Refresh vor der Bearbeitung) arbeiten.
P.S.: Ob man das in OO umsetzt oder in einer prozeduralen Anwendung ist Geschmacksache.
Es werden immer ganze Seiten ausgeliefert auf denen der Benutzer etwas eingeben/ansehen und mit einem Funktionscode (Tastendruck, Mausklick, etc.) bestätigen kann. Danach werden die Daten wieder an den Server zurückgeschickt, der dann die entsprechende Verarbeitung auslöst und wieder eine (neue) Seite ausliefert.
Ein gemeinsames "Observerobjekt" kann man hiermit schon per Definition nicht einsetzen, weil die Benutzersessions unabhängig voneinander ablaufen. Streng genommen wäre "die Datenbank" oder "eine Datei am Applikationsserver" eine solche gemeinsame "Ressource". Wie rob_abc schon angemerkt hat, hat die SAP hier mehrere Ansätze (versucht) um dieses Dilemma etwas abzufedern:
ABAP Channels - Wobei ich hier nicht sicher bin, dass die über mehrere Benutzersessions funktionieren.
Shared Memory - Guter Ansatz um Daten am Server vorzuhalten und nicht jedes Mal die Datenbank zu "belasten". Besonders für Customzing, das sich nicht oft ändert geeignet. Für Bewegungsdaten eher schlecht geeignet. Hat sich aber meines Erachtens mit HANA erledigt.
Allen Ansätzen gemeinsam ist aber nachwievor das Ur-Patttern: Formular ausliefern > Eingabe von Daten > Formular abschicken > rinse and repeat
Einen "Observer" wird man damit nicht hinbekommen. Was aber ganz gut funktioniert ist ein automatisches "Polling". Sprich die laufende Applikation holt sich in bestimmten Intervallen die aktuellsten Infos von der Datenbank und bringt sie zur Anzeige.
Unter SAPgui (Dynpros) gibt es hierfür die Klasse CL_GUI_TIMER die dafür sorgt, dass der PAI/PBO Lauf kontinuierlich ausgelöst wird.
Unter "WebGUI" (BSP, Webdynpro, UI5, Fiori, etc) kann man das mittels JavaScript erreichen (teilweise out-of-the-box mit SAP Mitteln) um die ganze Seite (Refresh) oder nur einzelene Bereiche ("AJAX") zu aktualisieren
Das muss man dann aber auch so umsetzen, dass Benutzer nicht gleichtzeitig an einem Datensatz (Locking) oder mit veralteten Daten (Refresh vor der Bearbeitung) arbeiten.
P.S.: Ob man das in OO umsetzt oder in einer prozeduralen Anwendung ist Geschmacksache.
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
Vielen Dank für die Erklärung. Dann war ich doch etwas Milchmädchen als ich mir das zusammengedacht habe. :/a-dead-trousers hat geschrieben: ↑31.07.2024 07:25Ein SAP-System kann man mit einem Webserver vergleichen:
Es werden immer ganze Seiten ausgeliefert auf denen der Benutzer etwas eingeben/ansehen und mit einem Funktionscode (Tastendruck, Mausklick, etc.) bestätigen kann. Danach werden die Daten wieder an den Server zurückgeschickt, der dann die entsprechende Verarbeitung auslöst und wieder eine (neue) Seite ausliefert.
Ein gemeinsames "Observerobjekt" kann man hiermit schon per Definition nicht einsetzen, weil die Benutzersessions unabhängig voneinander ablaufen. Streng genommen wäre "die Datenbank" oder "eine Datei am Applikationsserver" eine solche gemeinsame "Ressource". Wie rob_abc schon angemerkt hat, hat die SAP hier mehrere Ansätze (versucht) um dieses Dilemma etwas abzufedern:
ABAP Channels - Wobei ich hier nicht sicher bin, dass die über mehrere Benutzersessions funktionieren.
Shared Memory - Guter Ansatz um Daten am Server vorzuhalten und nicht jedes Mal die Datenbank zu "belasten". Besonders für Customzing, das sich nicht oft ändert geeignet. Für Bewegungsdaten eher schlecht geeignet. Hat sich aber meines Erachtens mit HANA erledigt.
Allen Ansätzen gemeinsam ist aber nachwievor das Ur-Patttern: Formular ausliefern > Eingabe von Daten > Formular abschicken > rinse and repeat
Einen "Observer" wird man damit nicht hinbekommen. Was aber ganz gut funktioniert ist ein automatisches "Polling". Sprich die laufende Applikation holt sich in bestimmten Intervallen die aktuellsten Infos von der Datenbank und bringt sie zur Anzeige.
Unter SAPgui (Dynpros) gibt es hierfür die Klasse CL_GUI_TIMER die dafür sorgt, dass der PAI/PBO Lauf kontinuierlich ausgelöst wird.
Unter "WebGUI" (BSP, Webdynpro, UI5, Fiori, etc) kann man das mittels JavaScript erreichen (teilweise out-of-the-box mit SAP Mitteln) um die ganze Seite (Refresh) oder nur einzelene Bereiche ("AJAX") zu aktualisieren
Das muss man dann aber auch so umsetzen, dass Benutzer nicht gleichtzeitig an einem Datensatz (Locking) oder mit veralteten Daten (Refresh vor der Bearbeitung) arbeiten.
P.S.: Ob man das in OO umsetzt oder in einer prozeduralen Anwendung ist Geschmacksache.
Der Ansatz mit dem "Polling" war mein erster Gedanke, dachte mir aber das dies kein korrekter Ansatz ist und es anders gelöst werden sollte.
Gruß
Aki
SAP-Basis: 740
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
1255
Views
Views
Nächsten Schritte als ABAP Entwickler
von retsch » 16.05.2023 07:07 • Verfasst in ABAP® für Anfänger
von retsch » 16.05.2023 07:07 • Verfasst in ABAP® für Anfänger
4
Antw.
Antw.
4160
Views
Views
generate_subpool_dir_full, SELECT in Schritte
von m.schwertle » 12.02.2008 09:07 • Verfasst in ABAP® Core
von m.schwertle » 12.02.2008 09:07 • Verfasst in ABAP® Core
4
Antw.
Antw.
3912
Views
Views
Lohnsteuerbescheinigung - erste Tätigkeitsstätte
von Kerstin » 11.12.2015 10:02 • Verfasst in Human Resources
von Kerstin » 11.12.2015 10:02 • Verfasst in Human Resources
1
Antw.
Antw.
1391
Views
Views
2
Antw.
Antw.
2928
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.