E-Mail versenden ohne COMMIT?
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Halo an Alle,
ich suche eine Funktion oder statische Methode zum Versenden einer E-Mail aus SAP, welche keinen KOMMIT absetzen.
Der Grund dafür ist, dass in einigen Fällen eine E-Mail während einer Verbuchung oder bei der Verarbeitung von Batch-Input Mappen versendet werden soll. In diesen Fällen führt ein COMMIT zum Abbruch / Beenden der Verarbeitung und darf ausserdem nicht abgesetzt werden, weil ein ROLLBACK gemacht werden soll.
Bis jetzt wird der FuBa 'SO_NEW_DOCUMENT_SEND_API1' verwendet.
Hat jemand eine schlaue Idee, wie man den COMMIT umgehen könnte und die E-Mail trotzdem sicher versendet wird?
Grüße
Frog
ich suche eine Funktion oder statische Methode zum Versenden einer E-Mail aus SAP, welche keinen KOMMIT absetzen.
Der Grund dafür ist, dass in einigen Fällen eine E-Mail während einer Verbuchung oder bei der Verarbeitung von Batch-Input Mappen versendet werden soll. In diesen Fällen führt ein COMMIT zum Abbruch / Beenden der Verarbeitung und darf ausserdem nicht abgesetzt werden, weil ein ROLLBACK gemacht werden soll.
Bis jetzt wird der FuBa 'SO_NEW_DOCUMENT_SEND_API1' verwendet.
Hat jemand eine schlaue Idee, wie man den COMMIT umgehen könnte und die E-Mail trotzdem sicher versendet wird?
Grüße
Frog
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4117 / 130 /
953
)
»
Hallo Frosch,
Ruf den Baustein SO_NEW_DOCUMENT_SEND_API1 doch asynchron mittels des Zusatzes "STARTING NEW TASK" auf.
Oder die andere Variant mit "BACKGROUND TASK"
Allerdings müsstest du noch mal nachschauen, ob das nicht evtl. implizit ein Commit absetzt.
Ruf den Baustein SO_NEW_DOCUMENT_SEND_API1 doch asynchron mittels des Zusatzes "STARTING NEW TASK" auf.
Oder die andere Variant mit "BACKGROUND TASK"
Allerdings müsstest du noch mal nachschauen, ob das nicht evtl. implizit ein Commit absetzt.
Hallo,
vielleicht interessiert sich jemand, wie ich das Problem mit dem störenden Commit beim Batch-Input und bei der Verbuchung beim Versenden der E-Mail gelöst habe. Die Lösung war wie immer trivial und einfach, habe zufällig einen OSS-Hinweis (717265) dazu gefunden.
Man musste nur den Funktionsbaustein FRC-fähig machen (das war er auch schon) und den per RFC aufrufen mit der DESTINATION 'NONE'. Der Commit wird dann in einem neuen Prozess abgesetzt.
Frog
vielleicht interessiert sich jemand, wie ich das Problem mit dem störenden Commit beim Batch-Input und bei der Verbuchung beim Versenden der E-Mail gelöst habe. Die Lösung war wie immer trivial und einfach, habe zufällig einen OSS-Hinweis (717265) dazu gefunden.
Man musste nur den Funktionsbaustein FRC-fähig machen (das war er auch schon) und den per RFC aufrufen mit der DESTINATION 'NONE'. Der Commit wird dann in einem neuen Prozess abgesetzt.
Frog
Hallo Frog,
leider klappt es bei mir nicht.
Ich rufe per RFC den Fuba auf mit Destination 'NONE'. Trotzdem werden die geänderte Daten auf der Datenbank festgeschrieben.
Testprogramm:
Es sieht so aus, als ob der RFC-Aufruf bereits den COMMIT im aufrufenden Programm auslöst. 
Kannst Du mal Deinen Code posten, bei dem kein COMMIT beim Aufrufer erfolgt?
Danke!
MfG
Thomas R.
leider klappt es bei mir nicht.
Ich rufe per RFC den Fuba auf mit Destination 'NONE'. Trotzdem werden die geänderte Daten auf der Datenbank festgeschrieben.
Testprogramm:
Code: Alles auswählen.
REPORT zrttest2 .
PARAMETERS:
p_m1 TYPE i DEFAULT 2,
p_m2 TYPE i DEFAULT 3,
p_commit AS CHECKBOX DEFAULT SPACE'.
START-OF-SELECTION.
PERFORM s_o_s.
FORM s_o_s.
DATA:
lv_custom TYPE ycustom,
lv_string TYPE string,
ltab_documents TYPE /escher/email_documents_tab,
ltab_recipients TYPE /escher/email_recipients_tab.
FIELD-SYMBOLS:
<ls_document> LIKE LINE OF ltab_documents[],
<ls_recipient> LIKE LINE OF ltab_recipients[].
* Werte
lv_string = p_m1 * p_m2.
WRITE sy-uzeit TO lv_custom-class.
lv_custom-attrib = p_m1.
lv_custom-value = lv_string.
lv_string = lv_custom.
* Protokollausgabe
WRITE:
/ lv_custom.
* Eintrag in DB
INSERT INTO ycustom VALUES lv_custom.
* Adress- und Dokumentdaten
INSERT INITIAL LINE INTO TABLE ltab_recipients[]
ASSIGNING <ls_recipient>.
<ls_recipient>-emailaddress = 'Vorname.Nachname@firma.de'.
<ls_recipient>-express = 'X'.
INSERT INITIAL LINE INTO TABLE ltab_documents[]
ASSIGNING <ls_document>.
<ls_document>-type = 'TXT'.
<ls_document>-subject = lv_string.
* Aufruf RFC
CALL FUNCTION 'ZTEST' DESTINATION 'NONE'
EXPORTING
im_documents_tab = ltab_documents[]
im_recipients_tab = ltab_Recipients[]
im_commit = 'X'.
* Weiter im Programm
IF p_commit IS INITIAL.
ROLLBACK WORK. "Daten dürfen in DB nicht festgeschrieben werden
ELSE.
COMMIT WORK."Festschreiben der Daten
ENDIF.
ENDFORM. "s_o_sKannst Du mal Deinen Code posten, bei dem kein COMMIT beim Aufrufer erfolgt?
Danke!
MfG
Thomas R.
Hallo Thomas,
es ist auch nicht so gemeint, dass du erst ein Commit absetzen kannst, danach ein Rollback machst und das funktioniert. Ich habe es auch getestet, es geht nicht.
Kannst du die FRC-Funtion in deinem Progrtamm erst nach dem Rollback aufrufen?
Grundsätzlich habe ich die Funktion der Senderschnittstelle per RFC nur dann aufgerufen, wenn noch keine Änderungen auf der Datenbank erfolgt sind (z. B. in der Überprüfungsphase für Belege).
Mein Problem in diesem Posting war eigentlich, dass ich nach einer Lösung gesucht habe, wie ich beim Batch-Input ein Commit fürs Versenden einer Mail absetzen kann, ohne dass die Batch-Input-Verarbeitung falsch beendet wird. Die endet eigentlich automatisch bei einem Commit bzw. Rollback. Da die Mails auf jeden Fall versendet werden sollten, habe ich das Senden aus dem Verbuchungsfunktion rausgenommen.
Gruß
Frog
es ist auch nicht so gemeint, dass du erst ein Commit absetzen kannst, danach ein Rollback machst und das funktioniert. Ich habe es auch getestet, es geht nicht.
Kannst du die FRC-Funtion in deinem Progrtamm erst nach dem Rollback aufrufen?
Grundsätzlich habe ich die Funktion der Senderschnittstelle per RFC nur dann aufgerufen, wenn noch keine Änderungen auf der Datenbank erfolgt sind (z. B. in der Überprüfungsphase für Belege).
Mein Problem in diesem Posting war eigentlich, dass ich nach einer Lösung gesucht habe, wie ich beim Batch-Input ein Commit fürs Versenden einer Mail absetzen kann, ohne dass die Batch-Input-Verarbeitung falsch beendet wird. Die endet eigentlich automatisch bei einem Commit bzw. Rollback. Da die Mails auf jeden Fall versendet werden sollten, habe ich das Senden aus dem Verbuchungsfunktion rausgenommen.
Gruß
Frog
Hallo Frog,
z.Z. mache ich es auch so, dass ich den Sendeauftrag erstelle (mit oder ohne COMMIT je nach Situation). Ich träume noch von einer "idiotensicheren" Methode, bei der ich in JEDER Situation eine Email absetzen kann, die dann auch ankommt, egal ob ich irgendwann später ein ROLLBACK oder ein COMMIT für die Daten machen muss.
D.h. ich will den Versand "einfach" an einen separaten Prozess übergeben, der seinen Job zuverlässig erledigt. Aber dies scheint nur ein schöner Traum zu sein.
MfG
Thomas R.
z.Z. mache ich es auch so, dass ich den Sendeauftrag erstelle (mit oder ohne COMMIT je nach Situation). Ich träume noch von einer "idiotensicheren" Methode, bei der ich in JEDER Situation eine Email absetzen kann, die dann auch ankommt, egal ob ich irgendwann später ein ROLLBACK oder ein COMMIT für die Daten machen muss.
D.h. ich will den Versand "einfach" an einen separaten Prozess übergeben, der seinen Job zuverlässig erledigt. Aber dies scheint nur ein schöner Traum zu sein.
MfG
Thomas R.
Dann ruf doch den Mail-Fuba einfach in einem neuen Task auf:Thomas R. hat geschrieben: D.h. ich will den Versand "einfach" an einen separaten Prozess übergeben, der seinen Job zuverlässig erledigt. Aber dies scheint nur ein schöner Traum zu sein.
Code: Alles auswählen.
* Aufruf RFC
CALL FUNCTION 'ZTEST' STARTING NEW TASK taskname
EXPORTING
im_documents_tab = ltab_documents[]
im_recipients_tab = ltab_Recipients[]
im_commit = 'X'.
Gruß Hendrik
Hallo Hendrik,
danke für Deinen Vorschlag. Bei meinem Testbeispiel würde auch hier ein nicht gewünschtes Ergebnis entstehen, da der Aufruf als eine neue Task ein implizit ein
COMMIT WORK absetzt.
MfG
Thomas R.
danke für Deinen Vorschlag. Bei meinem Testbeispiel würde auch hier ein nicht gewünschtes Ergebnis entstehen, da der Aufruf als eine neue Task ein implizit ein
COMMIT WORK absetzt.
Hinweise
Beachten Sie, daß mit einem RFC unter Umständen ein Datenbank-Commiterfolgt. Daher darf zwischen Open-SQL-Anweisungen, die einen Datenbank-Cursor öffnen bzw. schließen (z.B. SELECT...ENDSELECT), kein RFC-Aufruf gesetzt werden.
MfG
Thomas R.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
1280
Views
Views
E-Mail-Anhang aus Verzeichnis per Mail versenden
von Patrick1982 » 22.11.2023 15:19 • Verfasst in ABAP® für Anfänger
von Patrick1982 » 22.11.2023 15:19 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
4801
Views
Views
Mail aus PA30 senden (Fehler da kein COMMIT WORK)
von Dyrdek » 02.06.2017 14:48 • Verfasst in ABAP® Core
von Dyrdek » 02.06.2017 14:48 • Verfasst in ABAP® Core
1
Antw.
Antw.
1610
Views
Views
Mail senden ohne Commit (weil im User-Exit)
von ralf.wenzel » 03.06.2015 13:31 • Verfasst in ABAP® Core
von ralf.wenzel » 03.06.2015 13:31 • Verfasst in ABAP® Core
5
Antw.
Antw.
3669
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.