Perform Synchronized
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Hallo @ all,
kann man in SAP ein Form synchronized aufrufen?
Das bedeutet SAP soll schauen ob diese Form bereits ausgeführt wird wenn ja soll SAP warten bis sie fertig ist und dann erst die Form ausführen.
Sowas benutzt man in JAVA bei multithreading.
Vielen Dank und Grüße
Adrian
kann man in SAP ein Form synchronized aufrufen?
Das bedeutet SAP soll schauen ob diese Form bereits ausgeführt wird wenn ja soll SAP warten bis sie fertig ist und dann erst die Form ausführen.
Sowas benutzt man in JAVA bei multithreading.
Vielen Dank und Grüße
Adrian
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
hallo Adrian,
mit Form meinst du eine Routine, welche du im ABAP mit PERFORM aufrufen würdest? In diesem Fall kommt man eventuell mit Sperreinträgen weiter, müsste man aber selbst ausprogrammieren. Oder meinst du etwa Smartforms?
mit Form meinst du eine Routine, welche du im ABAP mit PERFORM aufrufen würdest? In diesem Fall kommt man eventuell mit Sperreinträgen weiter, müsste man aber selbst ausprogrammieren. Oder meinst du etwa Smartforms?
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Ich glaub du suchst nach CALL FUNCTION ... STARTING NEW TASK PERFORMING ... ON END OF TASK
Warten auf die fertige Abarbeitung kannst du dann z.B. mit WAIT UNTIL ...
Ein kleines Beispiel findet sich in der ABAP-Hilfe.
lg ADT
Ich glaub du suchst nach CALL FUNCTION ... STARTING NEW TASK PERFORMING ... ON END OF TASK
Warten auf die fertige Abarbeitung kannst du dann z.B. mit WAIT UNTIL ...
Ein kleines Beispiel findet sich in der ABAP-Hilfe.
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
Wenn ich CALL FUNCTION ... STARTING NEW TASK PERFORMING ... ON END OF TASK,
wartet der eine Task dann darauf wenn aus einem anderen Programm auch CALL FUNCTION ... STARTING NEW TASK PERFORMING ... ON END OF TASK gemacht wurde und dieser fertig ist ?
Irgenwie schwer zu erklären.
Grüße Adrian
wartet der eine Task dann darauf wenn aus einem anderen Programm auch CALL FUNCTION ... STARTING NEW TASK PERFORMING ... ON END OF TASK gemacht wurde und dieser fertig ist ?
Irgenwie schwer zu erklären.
Grüße Adrian
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ne, das nicht.
Du hast ja nach FORM gefragt und die gibt es nur innerhalb eines Programms.
Und da du multithreading erwähnt hast, dachte ich du suchst nach dem Pendant dazu in ABAP.
Genauer funktioniert es so:
Mit CALL FUNCTION ... STARTING NEW TASK PERFORMING ... ON END OF TASK wird ein neuer Arbeitsprozess gestartet.
Hier ist wichtig zu erwähnen, dass die Anzahl dieser Prozesse davon abhängig ist, wieviele Modi die Benutzer gleichzeitig am System öffnen dürfen (meist 5)
Nachdem das CALL FUNCTION abgesetzt wurde, startet ein neuer Modus (Ein Dynpro muss nicht zwingend angezeigt werden)
Da man nur eine bestimmte Anzahl aufbauen darf, erhöhe ich danach meist eine Zählvariable.
Das WAIT UNTIL mach ich dann im Anschluss meist auf LD_COUNT < 5. Heißt solange die Zählvariable unter 5 bleibt wird die Verarbeitung fortgesetzt und unter Umständen weitere Modi mit CALL FUNCTION ... STARTING NEW TASK aufgerufen.
Die Form-Routine die bei PERFORMING ... ON END OF TASK angegeben wurde, wird nach Abschluss der Verarbeitung in der aufgerufenen CALL FUNCTION aufgerufen.
Hier verrigere ich die Zählvariable wieder und hole wenn notwendig das Ergebnis der Ausführung mit RECEIVING RESULTS FROM ... ab.
Bevor das Programm fertig ist kommt noch ein WAIT UNTIL LD_COUNT = 0 damit auch wirklich alle SubProzesse vor Beenden des Hauptprogramms abgeschlossen sind.
lg ADT
Du hast ja nach FORM gefragt und die gibt es nur innerhalb eines Programms.
Und da du multithreading erwähnt hast, dachte ich du suchst nach dem Pendant dazu in ABAP.
Genauer funktioniert es so:
Mit CALL FUNCTION ... STARTING NEW TASK PERFORMING ... ON END OF TASK wird ein neuer Arbeitsprozess gestartet.
Hier ist wichtig zu erwähnen, dass die Anzahl dieser Prozesse davon abhängig ist, wieviele Modi die Benutzer gleichzeitig am System öffnen dürfen (meist 5)
Nachdem das CALL FUNCTION abgesetzt wurde, startet ein neuer Modus (Ein Dynpro muss nicht zwingend angezeigt werden)
Da man nur eine bestimmte Anzahl aufbauen darf, erhöhe ich danach meist eine Zählvariable.
Das WAIT UNTIL mach ich dann im Anschluss meist auf LD_COUNT < 5. Heißt solange die Zählvariable unter 5 bleibt wird die Verarbeitung fortgesetzt und unter Umständen weitere Modi mit CALL FUNCTION ... STARTING NEW TASK aufgerufen.
Die Form-Routine die bei PERFORMING ... ON END OF TASK angegeben wurde, wird nach Abschluss der Verarbeitung in der aufgerufenen CALL FUNCTION aufgerufen.
Hier verrigere ich die Zählvariable wieder und hole wenn notwendig das Ergebnis der Ausführung mit RECEIVING RESULTS FROM ... ab.
Bevor das Programm fertig ist kommt noch ein WAIT UNTIL LD_COUNT = 0 damit auch wirklich alle SubProzesse vor Beenden des Hauptprogramms abgeschlossen sind.
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
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Was du suchst ist glaub ich eine Art "Worker"-Programm das im Hintergrund gestartet wird und sich selbst immer wieder einplant.
Nur wenn Daten in einer bestimmten Tabelle drinnenstehen, soll eine Verarbeitung stattfinden, ansonsten wird nichts gemacht und in 5 min das Programm nochmal per Jobeinplanung ausgeführt.
Du kannst dann auch mehrere "Worker" arbeiten lassen, die müssen dann nur anhand sog. Sperrobjekte abfragen, ob es ihnen erlaubt ist im Moment etwas zu arbeiten, oder ob ein anderer Prozess gerade mit der Verarbeitung dran ist.
lg ADT
Nur wenn Daten in einer bestimmten Tabelle drinnenstehen, soll eine Verarbeitung stattfinden, ansonsten wird nichts gemacht und in 5 min das Programm nochmal per Jobeinplanung ausgeführt.
Du kannst dann auch mehrere "Worker" arbeiten lassen, die müssen dann nur anhand sog. Sperrobjekte abfragen, ob es ihnen erlaubt ist im Moment etwas zu arbeiten, oder ob ein anderer Prozess gerade mit der Verarbeitung dran ist.
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
Wenn man mit Hintergrundjobs abreitet kann man sich das mit den Sperreinträgen 'sparen'.a-dead-trousers hat geschrieben:Du kannst dann auch mehrere "Worker" arbeiten lassen, die müssen dann nur anhand sog. Sperrobjekte abfragen, ob es ihnen erlaubt ist im Moment etwas zu arbeiten, oder ob ein anderer Prozess gerade mit der Verarbeitung dran ist.
Wir setzen hier einen Z-Report ein, der immer als Step1 ausgeführt wird und checkt ob bereits ein Job mit demselben Namen aktiv ist. Dabei geben wir dann vor ob ers nach n Sekunden nochmal versuchen soll oder den Job sofort abbrechen.
Relevante Tabellen: tbtco, tbtcp ==> tbtco~status = 'R'.
Mit dieser Lösung kann man für jegliche Programme verhindern, dass sie 2x paralell laufen - z.B. wenn ein 5-Minütiger Intervall-Job mal "etwas länger" läuft
Freundliche Grüsse
Reto
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hmmm... was aber wenn der Job nicht denselben Namen hat.Somani hat geschrieben:... und checkt ob bereits ein Job mit demselben Namen aktiv ist. ...
Oder noch schlimmer: Irgendwer hat einen anderen Job angelegt der gleich heißt.
Oder es soll der Job tatsächlich mehrmals ausgeführt werden, aber jedes zu bearbeitende "Objekt" darf nur einmal behandelt werden.
Die "per Name" Lösungen sind vielleicht schnell und leicht umsetzbar, werden aber bei größeren Systemen mitunter sehr unübersichtlich.
Mit "per Objekt" (z.B. Sperrobjekt) Lösungen ist man immer auf der sicheren Seite.
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
Ja da hast du sicher recht. Die sicherste Variante ist natürlich der Sperreintrag; das hätte ich dazuschreiben sollen bzw besser formulieren können.a-dead-trousers hat geschrieben:hmmm... was aber wenn der Job nicht denselben Namen hat.Somani hat geschrieben:... und checkt ob bereits ein Job mit demselben Namen aktiv ist. ...
Oder noch schlimmer: Irgendwer hat einen anderen Job angelegt der gleich heißt.
Oder es soll der Job tatsächlich mehrmals ausgeführt werden, aber jedes zu bearbeitende "Objekt" darf nur einmal behandelt werden.
Wollte lediglich einen alterativ-Weg aufzeigen der ja je nach Situation geeignet ist.
Wir setzten die "Name"-Variante klassischerweise bei Jobs ein die nicht manuell eingeplant werden. Solche die ganze Prozessabläuffe ausführen mit 20 oder mehr Steps. Die können sehr unterschiedliche Laufzeiten haben.
Seite 1 von 1
Vergleichbare Themen
6
Antw.
Antw.
1717
Views
Views
2
Antw.
Antw.
1638
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 3 Tagen von DeathAndPain 4 / 1224
vor 3 Tagen von DeathAndPain 4 / 1224
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 3 Tagen von DeathAndPain 4 / 1224
vor 3 Tagen von DeathAndPain 4 / 1224