"parallele Prozesse"
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
hallo zusammen,
ich hab ein kleines problem. ich ruf einen report mittels nachrichtenfindung auf und zwar beim sichern einer faktura. werden nun mehrere fakturen gleichzeitig gesichert (z.b. mittels va05), so wird der report parallel mehrmals aufgerufen. da in diesem report gesammelte daten als attachment per email verschickt werden, kommt es zu problemen. z.b.: werden zwei fakturen gesichert, so erhält man 2 emails;
* eins mit der ersten faktura
* eins mit zwei attachments,
wobei in einem die zweite faktura enthalten ist
und in einem die erste faktura zweimal und die zweite faktura
einmal
ich glaub, dass es sich hier um klassische parallele verarbeitung handelt. nur, wie kann ich das problem mittels ABAP lösen???
es sollte im prinzip der report erst dann ein zweites mal aufgerufen werden, wenn der erste fertig abgearbeitet ist.
vielen dank
andi.
ich hab ein kleines problem. ich ruf einen report mittels nachrichtenfindung auf und zwar beim sichern einer faktura. werden nun mehrere fakturen gleichzeitig gesichert (z.b. mittels va05), so wird der report parallel mehrmals aufgerufen. da in diesem report gesammelte daten als attachment per email verschickt werden, kommt es zu problemen. z.b.: werden zwei fakturen gesichert, so erhält man 2 emails;
* eins mit der ersten faktura
* eins mit zwei attachments,
wobei in einem die zweite faktura enthalten ist
und in einem die erste faktura zweimal und die zweite faktura
einmal
ich glaub, dass es sich hier um klassische parallele verarbeitung handelt. nur, wie kann ich das problem mittels ABAP lösen???
es sollte im prinzip der report erst dann ein zweites mal aufgerufen werden, wenn der erste fertig abgearbeitet ist.
vielen dank
andi.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Bin zwar nicht so sicher, ob ich's richtig verstanden habe, aber meiner Meinung nach müsstest Du Deinen Report über einen Job einplanen. Dann musst Du nur prüfen, ob bereits ein Job mit diesem Report eingeplant ist. In dem Fall wird kein neuer Job gestartet, ansonsten startest Du einen neuen. Hoffe ich habe mich veständlich ausgedrückt.
Hermann
Hermann
Das Problem liegt in der sauberen Trennung der Daten.
Durch die Einschränkung "Report nur einmal starten"
wird das Problem nicht an der Wurzel gelöst,
das ist Bastelei.
Lege die Daten Vorgangsbezogen eindeutig ab
und versende auch so. Nur dann ist z.B. Restart,
Recovery oder Debugging ordentlich möglich.
Gruss
Daniel
Durch die Einschränkung "Report nur einmal starten"
wird das Problem nicht an der Wurzel gelöst,
das ist Bastelei.
Lege die Daten Vorgangsbezogen eindeutig ab
und versende auch so. Nur dann ist z.B. Restart,
Recovery oder Debugging ordentlich möglich.
Gruss
Daniel
ganz hab ich deine antwort noch nicht verstanden. ich möchte ja die daten sofort nach dem sichern versenden und nicht je nach vorgang zwischenspeichern?? könntest du bitte etwas genauer erklären, was du meinst?
vielen dank
andi.
vielen dank
andi.
@Daniel.
Mit Jobs zu arbeiten ist durchaus üblich und hat m.E. nichts mit Bastelei zu tun. Wenn das Programm über einen Job eingeplant wird, habe ich die Möglichkeit vor einem erneuten Einplanen (ausgelöst durch Nachrichtensteuerung) die Möglichkeit abzuprüfen, ob bereits ein Job (und damit der Report der das Sammeln und Versenden durchführt) aktiv ist. Dann besteht nicht die Notwendigkeit einen neuen Job zu starten, d.h. in diesem Fall wird kein neuer Job gestartet (da ja bereits einer aktiv ist, der die Aufgabe übernimmt).
Das müsste meiner Ansicht nach problemlos gehen.
Hermann
Mit Jobs zu arbeiten ist durchaus üblich und hat m.E. nichts mit Bastelei zu tun. Wenn das Programm über einen Job eingeplant wird, habe ich die Möglichkeit vor einem erneuten Einplanen (ausgelöst durch Nachrichtensteuerung) die Möglichkeit abzuprüfen, ob bereits ein Job (und damit der Report der das Sammeln und Versenden durchführt) aktiv ist. Dann besteht nicht die Notwendigkeit einen neuen Job zu starten, d.h. in diesem Fall wird kein neuer Job gestartet (da ja bereits einer aktiv ist, der die Aufgabe übernimmt).
Das müsste meiner Ansicht nach problemlos gehen.
Hermann
Das geht, hält aber die Daten nicht auseinander.
Restart ist kaum möglich, Debugging auch nicht.
(Warum wird bei jedem 107.ten Beleg kein eMail gesendet ? )
Was ist bei VB-Abbruch - senden oder nicht ?
Nach DB-Restart ?
Mail verloren, gezielt wiederholen ?
Ausserden kommt irgendwann die Anforderung, das Mail
in Abhängigkeit von irgendwelchen Belegdaten an einen
oder mehrere andere Empfänger zu senden.
Ansätze dieser Art gehen auf Dauer immer schief.
Gruss
Daniel
Restart ist kaum möglich, Debugging auch nicht.
(Warum wird bei jedem 107.ten Beleg kein eMail gesendet ? )
Was ist bei VB-Abbruch - senden oder nicht ?
Nach DB-Restart ?
Mail verloren, gezielt wiederholen ?
Ausserden kommt irgendwann die Anforderung, das Mail
in Abhängigkeit von irgendwelchen Belegdaten an einen
oder mehrere andere Empfänger zu senden.
Ansätze dieser Art gehen auf Dauer immer schief.
Gruss
Daniel
Also Debugging wäre kein Problem. Das könntest Du ja trotzdem, indem Du in den Report eine Endlosschleife (zu Debuggingzwecken) einbaust und über die SM50 dann debuggst. Das ist zwar umständlicher, aber machbar.
Das Problem mit VB-Abbruch oder DB-Restart hättest Du auch so. Wenn in dem Fall ein Job gerade läuft, dann kannst Du im Falle eines Abbruchs den Job erneut aufsetzen. VB-Abbrüche könnten über die SM13 nachverbucht werden. Das sind aber alles Probleme, die Du im Grunde immer hast (in mehr oder weniger verschärfter Form).
Mail verloren ist ebenfalls ein Problem, das ganz unabhängig von der Verarbeitungsweise auftauchen kann. In dem Fall hilft ohnehin nur nachzuschauen, warum die mail verloren ging. Denn auf dem Weg zum Empfänger gibt es ja etliche Möglichkeiten, dass eine mail verloren geht, die völlig unabhängig vom eigenen System sind.
Aber diese Dinge mal ausser Acht gelassen, wie würde Dein Lösungvorschlag aussehen? (wie würdest Du ungefähr das ganze implementieren?)
Hermann
Das Problem mit VB-Abbruch oder DB-Restart hättest Du auch so. Wenn in dem Fall ein Job gerade läuft, dann kannst Du im Falle eines Abbruchs den Job erneut aufsetzen. VB-Abbrüche könnten über die SM13 nachverbucht werden. Das sind aber alles Probleme, die Du im Grunde immer hast (in mehr oder weniger verschärfter Form).
Mail verloren ist ebenfalls ein Problem, das ganz unabhängig von der Verarbeitungsweise auftauchen kann. In dem Fall hilft ohnehin nur nachzuschauen, warum die mail verloren ging. Denn auf dem Weg zum Empfänger gibt es ja etliche Möglichkeiten, dass eine mail verloren geht, die völlig unabhängig vom eigenen System sind.
Aber diese Dinge mal ausser Acht gelassen, wie würde Dein Lösungvorschlag aussehen? (wie würdest Du ungefähr das ganze implementieren?)
Hermann
In Debugging kommt man natürlich,
aber wenn die Daten nicht zugeordnet werden können
hilft das wenig.
Bei genau zuzuordenden Daten kann VB-Abbruch oder Restart
der Rollback-Logik unterliegen. Das ist ein wesentlicher Unetrschied!
Neu aufsetzten geht immer, aber was wird dann versendet ?
Alles nochmal ? (doppelt ?)
Mail verloren; wenn es aus dem grossen Topf kommt,
findest du kaum raus warum
Eine Wiederholung bedarf zusätzlichen (abweichendes) Coding.
>wie würde Dein Lösungvorschlag aussehen?
Ich würde die Daten Belegweise verarbeiten.
Entweder aus dem verbuchten Beleg nachlesen
(sicher, aber performanceungünstig)
oder Belegweise in den VB-Satz einstellen und per
eigenem FB im VB versenden oder den Report die
Daten aus dem VB-Satz lesen lassen.
Das ist recht einfach zu machen, schnell und sehr sicher.
Vor allem sind alle SAP-Restart und Rollback-Verfahren
damit sichergestellt.
Im Debugging (Fehlersuche) sind immer genau die zugehörigen
Daten (nicht irgendwelche) verfügbar.
Gruss
Daniel
aber wenn die Daten nicht zugeordnet werden können
hilft das wenig.
Bei genau zuzuordenden Daten kann VB-Abbruch oder Restart
der Rollback-Logik unterliegen. Das ist ein wesentlicher Unetrschied!
Neu aufsetzten geht immer, aber was wird dann versendet ?
Alles nochmal ? (doppelt ?)
Mail verloren; wenn es aus dem grossen Topf kommt,
findest du kaum raus warum
Eine Wiederholung bedarf zusätzlichen (abweichendes) Coding.
>wie würde Dein Lösungvorschlag aussehen?
Ich würde die Daten Belegweise verarbeiten.
Entweder aus dem verbuchten Beleg nachlesen
(sicher, aber performanceungünstig)
oder Belegweise in den VB-Satz einstellen und per
eigenem FB im VB versenden oder den Report die
Daten aus dem VB-Satz lesen lassen.
Das ist recht einfach zu machen, schnell und sehr sicher.
Vor allem sind alle SAP-Restart und Rollback-Verfahren
damit sichergestellt.
Im Debugging (Fehlersuche) sind immer genau die zugehörigen
Daten (nicht irgendwelche) verfügbar.
Gruss
Daniel
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
3680
Views
Views
15
Antw.
Antw.
11304
Views
Views
10
Antw.
Antw.
5208
Views
Views
BAPI_DOCUMENT_CHECKOUTVIEW2 erzeugt Massen von Unix-Prozesse
von ralf.wenzel » 19.04.2016 10:35 • Verfasst in ABAP® Core
von ralf.wenzel » 19.04.2016 10:35 • Verfasst in ABAP® Core
4
Antw.
Antw.
4152
Views
Views
0
Antw.
Antw.
1602
Views
Views
parallele Hintergrundjobs mit gleichem Endezeitpunkt
von Timoniac » 20.10.2017 13:18 • Verfasst in Basis
von Timoniac » 20.10.2017 13:18 • Verfasst in Basis
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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.