Parameter wird nicht an FuBa in Background Task übergeben
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Hallo,
ich habe hier zwei Probleme an denen ich gerade verzweifel. Ich ändere gerade in einem Formulardruckprogramm (noch SAPScript leider, nicht von mir, Faktura, VF02 ) den Mailversand. Da gibt es schon einen FuBa, den ich ergänzt habe um einen Parameter für den Namen der Verteilerliste. Dieser FuBa wird "in background task" aufgerufen. Ich kann durch das Setzen eines externen Breakpoints den FuBa auch debuggen, sehe aber, dass der neue Parameter leer bleibt. Die Variable für den Parameter ist global im Druckprogramm definiert, wie auch einige andere Parameter. Ich habe auch schon probiert, den Wert als Literal zu übergeben, dass funktioniert auch nicht. Die Parameter werden als Wert übergeben.
Nun kommt das zweite Problem, und zwar kann ich den Aufruf des FuBa im Formularprogramm nicht debuggen. Ich habe schon normale und externe Breakpoints probiert, System- und Verbuchungsdebugging eingeschaltet, aber er bleibt nicht stehen, auch nicht mit einem expliziten "Break-Point" und auch nicht mit break <username>. Ich habe sogar getestet, ob ich im richtigen Formular bin, indem ich eine message ausgeben wollte, da ist er immerhin mit einem Verbuchungsabbruch ausgestiegen.
Könnt ihr mir da vielleicht weiterhelfen?
VG
Xilukarim
ich habe hier zwei Probleme an denen ich gerade verzweifel. Ich ändere gerade in einem Formulardruckprogramm (noch SAPScript leider, nicht von mir, Faktura, VF02 ) den Mailversand. Da gibt es schon einen FuBa, den ich ergänzt habe um einen Parameter für den Namen der Verteilerliste. Dieser FuBa wird "in background task" aufgerufen. Ich kann durch das Setzen eines externen Breakpoints den FuBa auch debuggen, sehe aber, dass der neue Parameter leer bleibt. Die Variable für den Parameter ist global im Druckprogramm definiert, wie auch einige andere Parameter. Ich habe auch schon probiert, den Wert als Literal zu übergeben, dass funktioniert auch nicht. Die Parameter werden als Wert übergeben.
Nun kommt das zweite Problem, und zwar kann ich den Aufruf des FuBa im Formularprogramm nicht debuggen. Ich habe schon normale und externe Breakpoints probiert, System- und Verbuchungsdebugging eingeschaltet, aber er bleibt nicht stehen, auch nicht mit einem expliziten "Break-Point" und auch nicht mit break <username>. Ich habe sogar getestet, ob ich im richtigen Formular bin, indem ich eine message ausgeben wollte, da ist er immerhin mit einem Verbuchungsabbruch ausgestiegen.
Könnt ihr mir da vielleicht weiterhelfen?
VG
Xilukarim
ECC 6.07
Netweaver 7.40
Netweaver 7.40
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von sap_enthusiast (ForumUser / 95 / 25 /
23
)
»
Moin,
könntest den relevanten Codeteil mitteilen?
So können wir besser helfen :)
Vom Bauch raus würde ich sagen, vlt passt etwas mit der Typisierung nicht?
könntest den relevanten Codeteil mitteilen?
So können wir besser helfen :)
Vom Bauch raus würde ich sagen, vlt passt etwas mit der Typisierung nicht?
Da gibt es nicht viel zu sehen:
Deklaration als globale Variable im Formularprogramm:
Aufruf des FuBa:
Deklaration als globale Variable im Formularprogramm:
Code: Alles auswählen.
data g_mail_ag TYPE adr6-smtp_addr.
...
data distribution_list_name type SO_OBJ_NAM.
data is_private_distribution_list type abap_bool.
Code: Alles auswählen.
form send_mail.
distribution_list_name = 'abcd'.
is_private_distribution_list = abap_false. "Am Breakpoint hier, egal ob intern, extern, mit System-
"und mit Verbuchungsdebugging wird nie angehalten
"g_mail_ag wird vor dem Aufruf der Form gefüllt
CALL FUNCTION 'ZSDxxx' IN BACKGROUND TASK
EXPORTING
nast = nast
email_re = g_mail_ag "sic!
vbeln = vbak-vbeln
distribution_list_name = distribution_list_name.
"distribution_list_name = 'abcd'. "Funktioniert auch nicht
is_private_distribution_list = is_private_distribution_list .
.
Code: Alles auswählen.
FUNCTION ZSDxxx.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(NAST) TYPE NAST "gefüllt
*" VALUE(EMAIL_RE) TYPE AD_SMTPADR OPTIONAL "gefüllt
*" VALUE(VBELN) TYPE VBELN OPTIONAL "gefüllt
*" VALUE(NAME_DISTRIBUTION_LIST) TYPE SO_OBJ_NAM OPTIONAL "leer
*" VALUE(IS_PRIVATE_DISTRIBUTION_LIST) TYPE XFELD OPTIONAL "leer
*"----------------------------------------------------------------------
"Bei externem Breakpoint hier wird angehalten
ECC 6.07
Netweaver 7.40
Netweaver 7.40
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Auszug aus https://help.sap.com/doc/abapdocu_752_i ... d_task.htm
Was das Debugging anbelangt, könnte es sein, dass das Druckprogramm in einem Job bzw. unter einem anderen Benutzer ausgeführt wird. Damit funktioniert dann ein BREAK mit dem eigenen Benutzernamen nicht und ein BREAK-POINT funktioniert auch nur, wenn der ausführende Benutzer die Debug Berechtigung hat.
Natürlich wird der Funktionsbaustein erst bei COMMIT WORK aufgerufen, das heißt ein Debugging Einstieg direkt bei CALL FUNCTION wird nie funktionieren. Ich erwähne das nur, weil in deinem Beispiel die Stelle mit dem COMMIT WORK fehlt.
Alternativ könnte man auch noch STARTING NEW TASK verwenden. Da hätte man dann im Fehlerfall sofort eine Rückmeldung (mittels Exceptions) wenn etwas beim Aufrufen nicht gut gegangen ist. Für die Nutzung der Verbuchungslogik müsste man dann halt noch drum herum einen Verbuchungsbaustein schreiben.Der mit der Anweisung CALL FUNCTION IN BACKGROUND UNIT ausgeführte Background RFC (bgRFC) ist die erweiterte Nachfolgetechnologie des transaktionalen RFC (tRFC) und macht diesen obsolet. Es wird dringend empfohlen, den bgRFC anstelle des tRFC zu verwenden.
Was das Debugging anbelangt, könnte es sein, dass das Druckprogramm in einem Job bzw. unter einem anderen Benutzer ausgeführt wird. Damit funktioniert dann ein BREAK mit dem eigenen Benutzernamen nicht und ein BREAK-POINT funktioniert auch nur, wenn der ausführende Benutzer die Debug Berechtigung hat.
Natürlich wird der Funktionsbaustein erst bei COMMIT WORK aufgerufen, das heißt ein Debugging Einstieg direkt bei CALL FUNCTION wird nie funktionieren. Ich erwähne das nur, weil in deinem Beispiel die Stelle mit dem COMMIT WORK fehlt.
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
Hallo a-dead-trousers,
das Formularprogramm wird leider nicht von unserer Gesellschaft alleine benutzt (wir teilen uns SAP), so dass ich relativ vorsichtig mit Änderungen bin, und ich fühle mich nicht fit genug in der Verbuchungsthematik. Auch wenn es sich hier um eine veraltete Technik handelt ist es schwer für mich nachzuvollziehen, dass eine Variable funktioniert und eine andere an gleicher Stelle deklarierte nicht.
Ich bin noch nur im Entwicklungssystem unterwegs und teste die Programme selber aus, d.h. ich rufe VF02 selber auf und stoße die Nachrichten an. Der Zeitpunkt ist auf "sofort versenden (beim Sichern der Anwendung)" gestellt. Ich bekomme dann ein/zwei Sekunden nach Beenden von VF02 den Debugger innerhalb des FuBa zu sehen. Der Breakpoint in der Formroutine ist auch VOR dem Aufruf des FuBa. Ich habe da sehr großzügig Breakpoints verteilt, die alle nicht ziehen. Wenn es per Job laufen würde, würde dann nicht der Benutzer innerhalb des FuBa derselbe sein, wie der Job-Benutzer?
VG
Xilukarim
das Formularprogramm wird leider nicht von unserer Gesellschaft alleine benutzt (wir teilen uns SAP), so dass ich relativ vorsichtig mit Änderungen bin, und ich fühle mich nicht fit genug in der Verbuchungsthematik. Auch wenn es sich hier um eine veraltete Technik handelt ist es schwer für mich nachzuvollziehen, dass eine Variable funktioniert und eine andere an gleicher Stelle deklarierte nicht.
Ich bin noch nur im Entwicklungssystem unterwegs und teste die Programme selber aus, d.h. ich rufe VF02 selber auf und stoße die Nachrichten an. Der Zeitpunkt ist auf "sofort versenden (beim Sichern der Anwendung)" gestellt. Ich bekomme dann ein/zwei Sekunden nach Beenden von VF02 den Debugger innerhalb des FuBa zu sehen. Der Breakpoint in der Formroutine ist auch VOR dem Aufruf des FuBa. Ich habe da sehr großzügig Breakpoints verteilt, die alle nicht ziehen. Wenn es per Job laufen würde, würde dann nicht der Benutzer innerhalb des FuBa derselbe sein, wie der Job-Benutzer?
VG
Xilukarim
ECC 6.07
Netweaver 7.40
Netweaver 7.40
Dann bau doch eine Endlosschleife mit einer Variablen als Exit-Bedingung ein. Über die SM50 springst du dann in den Debugger des Prozesses, änderst die Variable, so dass die Endlosschleife verlassen wird.
Mal Blind den Code.
Code: Alles auswählen.
data lv_exit type boole_d.
DO.
if lv_exit = abap_true.
exit.
endif.
enddo.
Das war ein guter Tipp mit der Endlosschleife! Das Debuggen hat funktioniert :-)
Ich konnte auch sehen, dass ich selber tatsächlich der Ausführende bin.
Leider bin ich inhaltlich nicht weitergekommen. Meine Variable wird gesetzt wie ich möchte und "verliert" den Wert, wenn der FuBa ausgeführt wird.
Als Workaround setze ich die Verteilerliste aufgrund der Nachrichtenart jetzt im FuBa selber, was ich zwar ziemlich unglücklich finde, aber ich muss da erstmal weiterkommen.
Ich werde den Thread erstmal nicht als "Gelöst" kennzeichnen, da ich nach wie vor großes Interesse an der Ursache des Verhaltens der Variablen habe.
Danke für alle Antworten!
Ich konnte auch sehen, dass ich selber tatsächlich der Ausführende bin.
Leider bin ich inhaltlich nicht weitergekommen. Meine Variable wird gesetzt wie ich möchte und "verliert" den Wert, wenn der FuBa ausgeführt wird.
Als Workaround setze ich die Verteilerliste aufgrund der Nachrichtenart jetzt im FuBa selber, was ich zwar ziemlich unglücklich finde, aber ich muss da erstmal weiterkommen.
Ich werde den Thread erstmal nicht als "Gelöst" kennzeichnen, da ich nach wie vor großes Interesse an der Ursache des Verhaltens der Variablen habe.
Danke für alle Antworten!
ECC 6.07
Netweaver 7.40
Netweaver 7.40
Hast du bei dem Parameter den Haken für "Wertübergabe" gesetzt?
Wenn nein, hätte ich eine Erklärung:
Da du die Referenz auf dein Varibale des rufenden Programms übergibst, ist diese ja im BACKROUND nicht mehr vorhanden und somit leer.
Also so, wie wenn du eine RFC-Fuba hast. Dort muss auch der Haken "Wertübergabe" gesetzt sein, sonst meckert SAP....
Edit:
In deinem Code von oben steht bei dem Parameter "VALUE". Sollte als passen.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Zur Info: SAP würde hier schon beim Aktivieren des Funktionsbausteins "meckern" und nicht erst bei dessen Ausführung.
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
)
»
@Xilukarim
Welcher deiner Parameter wird denn nicht übergeben? Du hast "Verteilerliste" geschrieben, also NAME_DISTRIBUTION_LIST oder? In deinem Aufruf verwendest du aber DISTRIBUTION_LIST_NAME. Das könnte der Fehler sein. SAP prüft beim Aufruf von Funktionsbausteinen NICHT (immer) die korrekte Versorgung von Parametern. Vorallem bei RFCs da hier mit Angabe von DESTINATION ja der Aufruf nicht zwangsläufig auf demselben System stattfinden und daher die Schnittstelle auch nicht bekannt sein muss.
Welcher deiner Parameter wird denn nicht übergeben? Du hast "Verteilerliste" geschrieben, also NAME_DISTRIBUTION_LIST oder? In deinem Aufruf verwendest du aber DISTRIBUTION_LIST_NAME. Das könnte der Fehler sein. SAP prüft beim Aufruf von Funktionsbausteinen NICHT (immer) die korrekte Versorgung von Parametern. Vorallem bei RFCs da hier mit Angabe von DESTINATION ja der Aufruf nicht zwangsläufig auf demselben System stattfinden und daher die Schnittstelle auch nicht bekannt sein muss.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Xilukarim
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 Vielen Dank!!! Das hätte mich bestimmt noch ein paar Tage beschäftigt, Ich bin zu 80% nur noch in OO unterwegs, da gibt es das halt nicht mehr, dass falsche Parameternamen einfach durchrutschen. Und warum nicht zumindest Warnungen bei falschen Parametern in FuBa rauskommen, weiß auch nur SAP.
Weiß einer, ob bei Eclipse Funktionsbausteine besser geprüft werden?
VG
Xilukarim
Weiß einer, ob bei Eclipse Funktionsbausteine besser geprüft werden?
VG
Xilukarim
ECC 6.07
Netweaver 7.40
Netweaver 7.40
Das ist mal wieder ein Beispiel dafür, wie man manchmal zu kompliziert denkt. Ich hatte schon mal ein ähnliches Problem, da war die Lösung, dass die Variable nicht lokal in der Formroutine deklariert sein durfte, sondern global im Programm. Wenn die Funktion nicht im Background Task aufgerufen worden wäre, hätte ich die Lösung vielleicht schneller gefunden....
ECC 6.07
Netweaver 7.40
Netweaver 7.40
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Zur Info:
Die Parameterprüfung bei Funktionsbausteinen ist etwas "schwierig" zu implementieren, da diese im Grund ja dynamisch aufgerufen werden. Daher auch die Hochkommas (') im Befehl CALL FUNCTION. Bei einem "normalen" Funktionsbausteinaufruf (ohne Zusätze DESTINATION usw.) werden die Aktualparamter strikt geprüft und es kommt zu einer Exception wenn ein Parameter angegeben ist, der im aufgerufenen Funktionsbaustein nicht existiert. In alle anderen Fällen (z.B. auch wenn man den Namen des Funktionsbausteins über eine Variable angegeben hat) wird diese Prüfung NICHT durchgeführt.
Die Parameterprüfung bei Funktionsbausteinen ist etwas "schwierig" zu implementieren, da diese im Grund ja dynamisch aufgerufen werden. Daher auch die Hochkommas (') im Befehl CALL FUNCTION. Bei einem "normalen" Funktionsbausteinaufruf (ohne Zusätze DESTINATION usw.) werden die Aktualparamter strikt geprüft und es kommt zu einer Exception wenn ein Parameter angegeben ist, der im aufgerufenen Funktionsbaustein nicht existiert. In alle anderen Fällen (z.B. auch wenn man den Namen des Funktionsbausteins über eine Variable angegeben hat) wird diese Prüfung NICHT durchgeführt.
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
5
Antw.
Antw.
2132
Views
Views
6
Antw.
Antw.
10135
Views
Views
Call Function ... in background task ? Aber wie?
von Nordlicht » 25.03.2015 11:25 • Verfasst in Dialogprogrammierung
von Nordlicht » 25.03.2015 11:25 • Verfasst in Dialogprogrammierung
0
Antw.
Antw.
699
Views
Views
RFC FUBA IN BACKROUNG TASK / STARTING NEW TASK
von EZ09 » 05.02.2023 22:54 • Verfasst in ABAP® für Anfänger
von EZ09 » 05.02.2023 22:54 • Verfasst in ABAP® für Anfänger
6
Antw.
Antw.
3403
Views
Views
FuBa in neuem Task starten "STARTING NEW TASK"
von jan.se » 19.01.2006 11:20 • Verfasst in ABAP® Core
von jan.se » 19.01.2006 11:20 • Verfasst in ABAP® Core
0
Antw.
Antw.
1374
Views
Views
Dynamischer FuBa aufruf - New Task / BG/ RFC
von Mr_Machine » 22.08.2007 16:05 • Verfasst in ABAP® Core
von Mr_Machine » 22.08.2007 16:05 • Verfasst in ABAP® Core
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1156
vor 2 Tagen von DeathAndPain 4 / 1156
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 2 Tagen von DeathAndPain 4 / 1156
vor 2 Tagen von DeathAndPain 4 / 1156