@-Zeichen im RFC-Funktionsbaustein
Hallo zusammen,
ich habe folgendes Problem: ein RFC-fähiger Funktionsbaustein wird von ausserhalb aufgerufen. Der Baustein soll bestimmte Felder im SAP updaten. (Die Felder sind CHAR-Felder). Die neuen Werte kommen als IMPORTING-Parameter an. Wenn der Wert @ ist, erfolgt das Update problemlos. Wenn jedoch der Wert @@ oder @@@ ist (Feld ist CHAR3), sieht man vom rufenden System aus nur die Nachricht "got invalid answer from server 'timeout' " und nichts passiert.
Wenn ich den Baustein im SAP teste (ohne RFC, direkt in SE37), dann kann ich @@ und @@@ auch updaten. Beim externen Aufruf funktionieren @@ und @@@ nicht. Ein @ Zeichen funktioniert. Ich habe nur Hinweis 1451036 gefunden, wusste aber nicht ob das hier überhaupt relevant sein könnte. (Zudem werden meine @@ Werte im SAP auch schön angezeigt).
Man könnte natürlich eine Umschlüsselung einbauen, aber zuerst möchte ich verstehen wie es funktioniert.
Vielen Dank!
scsaba
ich habe folgendes Problem: ein RFC-fähiger Funktionsbaustein wird von ausserhalb aufgerufen. Der Baustein soll bestimmte Felder im SAP updaten. (Die Felder sind CHAR-Felder). Die neuen Werte kommen als IMPORTING-Parameter an. Wenn der Wert @ ist, erfolgt das Update problemlos. Wenn jedoch der Wert @@ oder @@@ ist (Feld ist CHAR3), sieht man vom rufenden System aus nur die Nachricht "got invalid answer from server 'timeout' " und nichts passiert.
Wenn ich den Baustein im SAP teste (ohne RFC, direkt in SE37), dann kann ich @@ und @@@ auch updaten. Beim externen Aufruf funktionieren @@ und @@@ nicht. Ein @ Zeichen funktioniert. Ich habe nur Hinweis 1451036 gefunden, wusste aber nicht ob das hier überhaupt relevant sein könnte. (Zudem werden meine @@ Werte im SAP auch schön angezeigt).
Man könnte natürlich eine Umschlüsselung einbauen, aber zuerst möchte ich verstehen wie es funktioniert.
Vielen Dank!
scsaba
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
moin,
es kann aber auch sein, daß das SAP System gar nicht der Schuldige ist.
Ich würde im aufgerufenen FB einen externen Break point setzen und mal kontrollieren.
gruß Jens
es kann aber auch sein, daß das SAP System gar nicht der Schuldige ist.
Ich würde im aufgerufenen FB einen externen Break point setzen und mal kontrollieren.
gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Hallo Jens,
danke für den Hinweis. Was wir gemacht haben ist eine Umschlüsselung - kommt 1@ an, wird das auf @ umgeschlüsselt, bei 2@ auf @@ und bei 3@ auf @@@.
Ist zwar unschön, sollte aber funktionieren.....
Überraschenderweise wird die Umschlüsselung nicht gemacht.
Ich habe jetzt folgendes drin:
[code]
CASE <i_wert>.
WHEN '1@' OR ' 1@'.
<db_wert> = '@'.
WHEN '2@' OR ' 2@'.
<db_wert> = '@@'.
WHEN '3@' OR ' 3@'.
<db_wert> = '@@@'.
WHEN OTHERS.
<db_wert> = <i_wert>.
ENDCASE.
[/code]
Wenn der Sendersystem eben "2@ " sendet (Feld ist 3 Zeichen lang), dann wird keine Umschlüsselung vorgenommen, sondern auf der SAP-Datenbank auch 2@ gespeichert...
<i_wert> ist der Importparameter, <db_wert> ist was ich dann updaten will.
Ich werde verrückt...
Wie kann ich denn beim Break-Point anhalten? (Ich bin für den ganzen Aufruf nicht zuständig, habe nur Zugriff auf das SAP-System).
Bin für jeden Tipp dankbar...
Grüße,
scsaba
danke für den Hinweis. Was wir gemacht haben ist eine Umschlüsselung - kommt 1@ an, wird das auf @ umgeschlüsselt, bei 2@ auf @@ und bei 3@ auf @@@.
Ist zwar unschön, sollte aber funktionieren.....
Überraschenderweise wird die Umschlüsselung nicht gemacht.
Ich habe jetzt folgendes drin:
[code]
CASE <i_wert>.
WHEN '1@' OR ' 1@'.
<db_wert> = '@'.
WHEN '2@' OR ' 2@'.
<db_wert> = '@@'.
WHEN '3@' OR ' 3@'.
<db_wert> = '@@@'.
WHEN OTHERS.
<db_wert> = <i_wert>.
ENDCASE.
[/code]
Wenn der Sendersystem eben "2@ " sendet (Feld ist 3 Zeichen lang), dann wird keine Umschlüsselung vorgenommen, sondern auf der SAP-Datenbank auch 2@ gespeichert...
<i_wert> ist der Importparameter, <db_wert> ist was ich dann updaten will.
Ich werde verrückt...
Wie kann ich denn beim Break-Point anhalten? (Ich bin für den ganzen Aufruf nicht zuständig, habe nur Zugriff auf das SAP-System).
Bin für jeden Tipp dankbar...
Grüße,
scsaba
Beitrag
von black_adept (Top Expert / 4080 / 125 /
934
)
»
Hallo scsaba,
ad Breakpoint: Bau in den gerufenen FuBa eine Endlosschleife ein " Do. Enddo." und lass ihn dann von außen aufrufen. Danach kannst du dann via SM50 den Prozess debuggen.
Alternatives Vorgehen: Schreibe dir die Parameter die beim FuBa-Aufruf von außen mitgegeben werden in das Testdatenverzeichnis. Dann siehst du zunächst einmal, ob die Daten überhaupt so ankommen wie du glaubst. Und wenn das alles normal aussieht lass den FuBa dann aus der Testumgebung laufen und schau ob er sich dann immer noch inkorrekt verhält.
( Schreiben in das Testdatenverzeichnis --> siehe OSS-Hinweis 866460 )
ad Breakpoint: Bau in den gerufenen FuBa eine Endlosschleife ein " Do. Enddo." und lass ihn dann von außen aufrufen. Danach kannst du dann via SM50 den Prozess debuggen.
Alternatives Vorgehen: Schreibe dir die Parameter die beim FuBa-Aufruf von außen mitgegeben werden in das Testdatenverzeichnis. Dann siehst du zunächst einmal, ob die Daten überhaupt so ankommen wie du glaubst. Und wenn das alles normal aussieht lass den FuBa dann aus der Testumgebung laufen und schau ob er sich dann immer noch inkorrekt verhält.
( Schreiben in das Testdatenverzeichnis --> siehe OSS-Hinweis 866460 )
Hallo Stefan,
vielen Dank, das mit DO-ENDDO scheint der einfacxhste Weg zu sein. Das Schreiben ins Testdatenverzeichnis habe ich nicht gekannt (ich bin ja auch kein Entwickler, sollte das bis jetzt nicht aufgefallen sein, aber der Hinweis 866460 benötigt ja einen Benutzerparameter der in diesem System (ECC 6.0) gar nicht vorhanden ist. Hinweis 871742 beschreibt zwar wie der angelegt werden soll, aber wie ich sehe fehlt in diesem System sogar das Paket (CRM_TOOLS), es ist also etwas umständlich das alles anzulegen nur um diesem sehr interessanten Problem auf die Spur zu kommen.
Ich versuche das erstmal mit DO-ENDDO und melde mich nachher. Danke!
Gruß,
scsaba
vielen Dank, das mit DO-ENDDO scheint der einfacxhste Weg zu sein. Das Schreiben ins Testdatenverzeichnis habe ich nicht gekannt (ich bin ja auch kein Entwickler, sollte das bis jetzt nicht aufgefallen sein
, aber der Hinweis 866460 benötigt ja einen Benutzerparameter der in diesem System (ECC 6.0) gar nicht vorhanden ist. Hinweis 871742 beschreibt zwar wie der angelegt werden soll, aber wie ich sehe fehlt in diesem System sogar das Paket (CRM_TOOLS), es ist also etwas umständlich das alles anzulegen nur um diesem sehr interessanten Problem auf die Spur zu kommen. Ich versuche das erstmal mit DO-ENDDO und melde mich nachher. Danke!
Gruß,
scsaba
Moin,
also damit ein RFC_USER auch Breakpoints verwenden kann, muß der RFC-User zum DIALOG-User (SU01) werden ! (für die Dauer des Testens)
Dann geht man in die Einstellungen der Workbench (E38/SE37/SE80) und setzt den RFC-User auf dem Reiter Debugging ein. (Menu: Hilfsmittel->Debugging)
Ein kleins Testprogramm für RFC gibts hier: http://tricktresor.de/content/index.php ... 87&aID=526
gruß Jens
also damit ein RFC_USER auch Breakpoints verwenden kann, muß der RFC-User zum DIALOG-User (SU01) werden ! (für die Dauer des Testens)
Dann geht man in die Einstellungen der Workbench (E38/SE37/SE80) und setzt den RFC-User auf dem Reiter Debugging ein. (Menu: Hilfsmittel->Debugging)
Ein kleins Testprogramm für RFC gibts hier: http://tricktresor.de/content/index.php ... 87&aID=526
gruß Jens
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Hallo wieder,
DO-ENDDO ist eingebaut. Ich habe sicherheitshalber IF-DO-ENDDO-ENDIF gemacht, damit es nicht grundsätzlich in die Schleife geht. Die IF-Bedingung sollte in Ordnung sein (es prüft für eine bestimmte Kundennr. in einem bestimmten Bukrs ab, die beide als IMPORT-Paremeter definiert sind, also die Schleife wird nur für die Kombination aktiv. Funktioniert im Entwicklungssystem wuderbar, allerdings kann ich dort kein RFC-Aufruf machen, nur SE37 Testen.
[code]
* Temporär: Endlossschleife zum Debugging
IF i_kunnr EQ '3200673400' AND
i_bukrs EQ '6129'.
DO.
IF sy-subrc = 42.
EXIT.
ENDIF.
ENDDO.
ENDIF.
[/code]
Im Testsystem jedoch kann man in der SM50 nichts erkennen. Der AUfruf erfolgt, die Schleife wird offenbar nicht durchgelaufen, der Baustein wird normal ausgeführt - das Ergebnis kann man in der datenbank sehen (bestimmte Felder im Stammsatz der ausgewählten Kunnr im jeweiligen Bukrs sind geändert, Änderungsbeleg geschrieben, etc.)
Es wurde schon 3x mit den Parametern aufgerufen, ohne Ergebnis. SM50 zeigt nichts (bzw. einmal für eine Sekunde
Was nun?
Gruß,
scsaba
DO-ENDDO ist eingebaut. Ich habe sicherheitshalber IF-DO-ENDDO-ENDIF gemacht, damit es nicht grundsätzlich in die Schleife geht. Die IF-Bedingung sollte in Ordnung sein (es prüft für eine bestimmte Kundennr. in einem bestimmten Bukrs ab, die beide als IMPORT-Paremeter definiert sind, also die Schleife wird nur für die Kombination aktiv. Funktioniert im Entwicklungssystem wuderbar, allerdings kann ich dort kein RFC-Aufruf machen, nur SE37 Testen.
[code]
* Temporär: Endlossschleife zum Debugging
IF i_kunnr EQ '3200673400' AND
i_bukrs EQ '6129'.
DO.
IF sy-subrc = 42.
EXIT.
ENDIF.
ENDDO.
ENDIF.
[/code]
Im Testsystem jedoch kann man in der SM50 nichts erkennen. Der AUfruf erfolgt, die Schleife wird offenbar nicht durchgelaufen, der Baustein wird normal ausgeführt - das Ergebnis kann man in der datenbank sehen (bestimmte Felder im Stammsatz der ausgewählten Kunnr im jeweiligen Bukrs sind geändert, Änderungsbeleg geschrieben, etc.)
Es wurde schon 3x mit den Parametern aufgerufen, ohne Ergebnis. SM50 zeigt nichts (bzw. einmal für eine Sekunde
Was nun?
Gruß,
scsaba
[quote="Tron"]Moin,
also damit ein RFC_USER auch Breakpoints verwenden kann, muß der RFC-User zum DIALOG-User (SU01) werden ! (für die Dauer des Testens)
Dann geht man in die Einstellungen der Workbench (E38/SE37/SE80) und setzt den RFC-User auf dem Reiter Debugging ein. (Menu: Hilfsmittel->Debugging)
[/quote]
Gilt diese Voraussetzung (Dialogbenutzer) auch für de nversuch mit DO-ENDDO? D.h. der Aufruf erfolgt natürlich durch RFC_XXX, aber in der SM50 stehe ich mit meinem Benutzer.
Und: muss ich im Reiter Debugging die Einstellung auch vornehmen, damit diese Idee mit DO-ENDDO / SM50 funktioniert?
Danke!
scsaba
Update: eine Umstellung des RFC-Benutzers auf Dialog ist nicht zulässig.
Ich verstehe aber immer noch nicht, wieso beim Aufruf des FuBa die Endlosschleife nicht prozessiert wird. Selbst wenn ein Debugging (mit meinem eigenen Benutzer) nicht möglich ist, sollte doch in der SM50 der Prozess sichtbar sein, und dann zu einem Kurzdump kommen wg. Timeout... oder?
also damit ein RFC_USER auch Breakpoints verwenden kann, muß der RFC-User zum DIALOG-User (SU01) werden ! (für die Dauer des Testens)
Dann geht man in die Einstellungen der Workbench (E38/SE37/SE80) und setzt den RFC-User auf dem Reiter Debugging ein. (Menu: Hilfsmittel->Debugging)
[/quote]
Gilt diese Voraussetzung (Dialogbenutzer) auch für de nversuch mit DO-ENDDO? D.h. der Aufruf erfolgt natürlich durch RFC_XXX, aber in der SM50 stehe ich mit meinem Benutzer.
Und: muss ich im Reiter Debugging die Einstellung auch vornehmen, damit diese Idee mit DO-ENDDO / SM50 funktioniert?
Danke!
scsaba
Update: eine Umstellung des RFC-Benutzers auf Dialog ist nicht zulässig.
Ich verstehe aber immer noch nicht, wieso beim Aufruf des FuBa die Endlosschleife nicht prozessiert wird. Selbst wenn ein Debugging (mit meinem eigenen Benutzer) nicht möglich ist, sollte doch in der SM50 der Prozess sichtbar sein, und dann zu einem Kurzdump kommen wg. Timeout... oder?
Beitrag
von black_adept (Top Expert / 4080 / 125 /
934
)
»
Hallo scsaba,
das hört sich irgendwie seltsam an - das Coding scheint mir schon ok zu sein und wenn die Kundennummer und Buchungskreis tatsächlich so übergeben werden solltest du in der Endlosschleife verharren.
Was mir noch einfällt wäre, dass der Remote-Client eine dauerhafte Verbindung zum SAP hält und evtl. dadurch noch der alte Code des FuBa durchlaufen wird. Starte doch mal den Server durch, von dem aus der Aufruf an das SAP durchgeführt wird, so dass irgendwelche gepufferten Programme definitiv verschwinden und die aktuellste Version verwendet wird.
Ob noch der alte Code durchgeführt wird kannst du auch so erkennen, indem du eine harte A-Meldung am Anfang des FuBa einbaust, die immer ausgelöst wird. Wenn die kommt hast du das aktuelle Coding - wenn die nicht kommt noch ein altes.
das hört sich irgendwie seltsam an - das Coding scheint mir schon ok zu sein und wenn die Kundennummer und Buchungskreis tatsächlich so übergeben werden solltest du in der Endlosschleife verharren.
Was mir noch einfällt wäre, dass der Remote-Client eine dauerhafte Verbindung zum SAP hält und evtl. dadurch noch der alte Code des FuBa durchlaufen wird. Starte doch mal den Server durch, von dem aus der Aufruf an das SAP durchgeführt wird, so dass irgendwelche gepufferten Programme definitiv verschwinden und die aktuellste Version verwendet wird.
Ob noch der alte Code durchgeführt wird kannst du auch so erkennen, indem du eine harte A-Meldung am Anfang des FuBa einbaust, die immer ausgelöst wird. Wenn die kommt hast du das aktuelle Coding - wenn die nicht kommt noch ein altes.
Moin,
1.) Bei RFC-Usern gibt es keinen Time Out.
2.) Die Prozessübersicht (SM50) zeigt alle Prozesse (egal RFC oder Spool et.)
gruß jens
1.) Bei RFC-Usern gibt es keinen Time Out.
2.) Die Prozessübersicht (SM50) zeigt alle Prozesse (egal RFC oder Spool et.)
gruß jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Hallo Stefan,
gute Idee, das lasse ich mal gleich prüfen.
Wenn ich also in der SM50 in der Schleife bin, dann sollte ich (mit dem eigenen Benutzer) auch fähig sein, ins Debugging zu gehen, auch wenn das Programm ja durch einen anderen (RFC) Benutzer gestartet wurde UND der RFC-Benutzer kein Dialogbenutzer ist? Wenn ich aufs Debugging gehe, dann soll dass doch mit dem eigenen Benutzer stattfinden und nicht mit dem RFC-Benutzer - es sollte also ziemlich egal sein ob der Debuggen kann oder nicht... ?! (Ich habe es so verstanden dass für einen extrenen Breakpoint der RFC-Benutzer debuggen können muss, aber für die SM50 doch nicht, oder?
Danke für die Hinweise, wir kommen voran
Grüße,
scsaba
gute Idee, das lasse ich mal gleich prüfen.
Wenn ich also in der SM50 in der Schleife bin, dann sollte ich (mit dem eigenen Benutzer) auch fähig sein, ins Debugging zu gehen, auch wenn das Programm ja durch einen anderen (RFC) Benutzer gestartet wurde UND der RFC-Benutzer kein Dialogbenutzer ist? Wenn ich aufs Debugging gehe, dann soll dass doch mit dem eigenen Benutzer stattfinden und nicht mit dem RFC-Benutzer - es sollte also ziemlich egal sein ob der Debuggen kann oder nicht... ?! (Ich habe es so verstanden dass für einen extrenen Breakpoint der RFC-Benutzer debuggen können muss, aber für die SM50 doch nicht, oder?
Danke für die Hinweise, wir kommen voran
Grüße,
scsaba
[quote="Tron"]Moin,
1.) Bei RFC-Usern gibt es keinen Time Out.
2.) Die Prozessübersicht (SM50) zeigt alle Prozesse (egal RFC oder Spool et.)
gruß jens[/quote]
Hallo Jens,
OK, wenn kein Timeout, umso besser Aber - darf ich mit dem eigenen Benutzer debuggen, oder muss der RFC-Benutzer auch als Dialog-User definiert sein?
Danke,
scsaba
1.) Bei RFC-Usern gibt es keinen Time Out.
2.) Die Prozessübersicht (SM50) zeigt alle Prozesse (egal RFC oder Spool et.)
gruß jens[/quote]
Hallo Jens,
OK, wenn kein Timeout, umso besser
Aber - darf ich mit dem eigenen Benutzer debuggen, oder muss der RFC-Benutzer auch als Dialog-User definiert sein? Danke,
scsaba
Moin,
beim RFC Debuging wird der User auf der Registerkarte eingetragen, der den Break auslösen soll.
Wenn Du die RFC-Berechtigung als Dialoguser hast und Du auf der Client-Seite (ext.Anwendung) auch Deinen Usernamen für die RFC-Anmeldung verwendest, geht das auch.
(Wieso kannst Du den RFC-User nicht zum Dialog User machen?)
Bist Du sicher, das der RFC User sich Anmelden kann und die Berechtigung hat, den Funktionsbaustein aufzurufen ?
(Das würde erklären warum die DO/ENDDO Aktion nicht in der SM50 zu sehen ist.)
Du solltest mit ST01 mal einen Berechtigungstrace durchführen.
http://www.abapforum.com/forum/viewtopi ... ace#p42612
Ein Blick mit RZ11 auf diese Parameter, könnte auch nicht schaden
Was ist das für eine externe Anwendung ?
gruß Jens
beim RFC Debuging wird der User auf der Registerkarte eingetragen, der den Break auslösen soll.
Wenn Du die RFC-Berechtigung als Dialoguser hast und Du auf der Client-Seite (ext.Anwendung) auch Deinen Usernamen für die RFC-Anmeldung verwendest, geht das auch.
(Wieso kannst Du den RFC-User nicht zum Dialog User machen?)
Bist Du sicher, das der RFC User sich Anmelden kann und die Berechtigung hat, den Funktionsbaustein aufzurufen ?
(Das würde erklären warum die DO/ENDDO Aktion nicht in der SM50 zu sehen ist.)
Du solltest mit ST01 mal einen Berechtigungstrace durchführen.
http://www.abapforum.com/forum/viewtopi ... ace#p42612
Ein Blick mit RZ11 auf diese Parameter, könnte auch nicht schaden
http://help.sap.com/saphelp_afs64/helpd ... ontent.htmMit der Pflege der Profilparameter (Transaktion RZ11) können Sie in folgenden Einstellungen am Remote Function Call (RFC) festlegen, welche Systemressourcen der Auftragsgenerierung zur Verfügung stehen
Was ist das für eine externe Anwendung ?
gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Hallo Jens,
der RFC User kann sich auf jeden Fall anmelden und den Baustein aufrufen. Es sind andere Felder (Datumsfelder, Betragsfelder, andere alphanumerische Felder), die problemlos aktualisiert werden können. Es wird dabei auch ein Änderugsbeleg geschrieben, dort ist auch erkennbar, dass der RFC-Benutzer die Änderung gemacht hat. Soweit ist also alles gut.
Probleme bereiten hier die folgenden Konstellationen:
1.
Wie im OP geschildert, kommt für ein CHAR3 Feld der Wert @@ oder @@@, wird der Baustein gar nicht gerufen, sondern es wird dem Aufrufer eine Meldung "Error: got invalid answer from server 'timeout'" gegeben. Mit @ (also nur EIN @) kommt dieser Fehler nicht. Der Fehler kommt bei einem Aufruf aus dem selben SAP-System heraus (SE37 Test) nicht, dort kann man alle Werte updaten.
2.
Um das Problem zu lösen, hat man für eine Konvertierung im FuBa entschieden: 2@ bzw. 3@ sollen auf @@ bzw. @@@ umgeschlüsselt werden. Obwohl das Coding zur Umschlüsselung offensichtlich OK ist, scheinen die mitgegebenen Werte (also 2@ und 3@ nicht umgeschlüsselt zu sein, stattdessen wird 2@ und 3@ auf die Datenbank geschrieben, mit Änderungsbeleg, etc. Nach dem Hinweis oben bin ich mir dann relaktiv sicher, dass der RFC.-Aufruf noch das alte Coding, ohne Umschlüsselung, liest, daher greift diese Änderung nicht. Teste ich in der SE37, wird natürlich umgeschlüsselt. Der Verdacht wird dadurch verstärkt, dass in der Zwischenzeit auch eine temporäre Abhilfe eingebaut wurde: sofort beim Anfang wird der Input-Wert für dieses CHAR3 Feld auf eine neue Z-Tabelle geschrieben, nur um zu sehen was wirklich drin ist. Bein RFC-Aufruf bleibt die Z-Tabelle leer, beim Test in der SE37 nicht. Dieses Coding wird immer ausgeführt, es ist also schwer zu erklären wieso die Z-Tabelle nicht aktualisiert wird (mit welchem Wert auch immer). Die Endlosschleife wird offensichtlich auch nicht prozessiert (obwohl sie ganz eindeutig durchlaufen werden müsste), wenn über RFC gerufen wird, in der SE37 kommt man sofort in die Schleife. Also daraus schliesse ich eindeuitg den Schluss, dass das aktuelle Coding beim RFC-Aufruf noch nicht ausgeführt wird.
Angenommen der RFC-Aufruf arbeitet mit dem aktuellen Coding (das soll am Montag passieren), dann wird ganz bestimmt die Z-Tabelle fortgeschrieben und das Programm kommt auch in die Endlosschleife. Hier verstehe ich immer noch nicht, ob es zum erfolgreichen Debuggen erforderlich ist, dass der RFC-Benutzer, under dessen Namen ja das ganze läuft, debuggen kann, oder es reicht auch aus, wenn ich mit meinem eigenen Benutzer rangehe. Warum der Benutzertyp nicht auf Dialog umgestellt werden kann (für den RFC-User), kann ich nicht sagen, der Kunde hat hier irgendwelche interne Regelung die automatisch auch den selben RFC-Benutzer im Produktivsystem auf Dialog umstellen würde (?), und das möchte man nicht. In diese Richtung kommen wir also nicht weiter, daher ist es für mich kritisch, ob mein eigener Benutzer in der SM50 ausreicht um debuggen zu können.
3.
Es gibt noch ein Thema das mir Kopfschmerzen macht: der Baustein hat auch einen Tabellenparameter der Texte (die zum Kreditlimit-Stammsatz KNKK abgelegt werden können) fortschreiben soll. Wird da eine Zeile (oder mehrere) in dieser Tabelle übergeben, sollen diese neue Zeilen ans Ende ggf. vorhandener Texte eingefügt werden. Gibt es keine bestehenden Texte, sollen sie angelegt werden. Funktioniert alles wunderbar wenn man in der SE37 testet. (Die Tabelle hat die Struktur TLINE). Nun wird beim RFC-Aufruf eine Zeile übergeben, wird diese gar nicht aktualisiert, als wäre nichts da. Wir haben einen ähnlichen FuBa, der von einem anderen externen System gerufen wird (über SAP Java Connector Version 3.0.6, beim anderen weiss ich nichts über das externe System). Hier werden gar keine Texte mitgegeben, und es ist auch OK wenn der Stammsatz auch noch keine Texte hat. Wenn jedoch bereits Texte im SAP vorhanden sind, werden diese irgendwie gelesen und dann doppelt zurückgeschrieben. Ruft man den Baustein für den selben (Test)kunden mehrmals auf, dann können in der Zwischenzeit so viele Texte gespeichert werden, dass die Verarbeitung mit dem Kurzdump EXPORT_TOO_MANY_DATA abgebrochen wird. Vorhandene Texte können dabei NUR dann gelesen werden, wenn in der Tabellenparameter nicht leer (T_TEXLINES[] NOT INITIAL) ist. Es wird aber ganz bestimmt gar nichts übergeben. Trotzdem kommt der baustein in den Zweig zum Update der Texte, die eindeutig obige Voraussetzung hat. Irgendwie habe ich den Eindruck, dass der Inhalt dieser Tabelle (TABLES-.Parameter) zwischen den einzelnen Aufrufen irgendwie nicht gelöscht wird (es gibt auch einen Baustein zum reinen Auslesen der Texte), sonst verstehe ich nicht wie man in den Zweig mit dem Texte fortschreiben kommt. Hier wäre die Möglichkeit zum Debuggen auch Gold wert....
Ich hoffe am Montag sind dann die Endlosschleifen endlich aktiv, und dann stellt sich schnell heraus ob ich (mit dem eigenen Benutzer) den RFC-Prozess auch debuggen kann... Der RFC-Benutzer verfügt schon über Berechtigung zum Debuggen, das konnte ich in der SU01 (nur Anzeigerechte) prüfen.
Vielen Dank nochmals für Eure Hinweise und Tipps. Ich denke am Montag werde ich mich wieder melden...
Gruß,
scsaba
der RFC User kann sich auf jeden Fall anmelden und den Baustein aufrufen. Es sind andere Felder (Datumsfelder, Betragsfelder, andere alphanumerische Felder), die problemlos aktualisiert werden können. Es wird dabei auch ein Änderugsbeleg geschrieben, dort ist auch erkennbar, dass der RFC-Benutzer die Änderung gemacht hat. Soweit ist also alles gut.
Probleme bereiten hier die folgenden Konstellationen:
1.
Wie im OP geschildert, kommt für ein CHAR3 Feld der Wert @@ oder @@@, wird der Baustein gar nicht gerufen, sondern es wird dem Aufrufer eine Meldung "Error: got invalid answer from server 'timeout'" gegeben. Mit @ (also nur EIN @) kommt dieser Fehler nicht. Der Fehler kommt bei einem Aufruf aus dem selben SAP-System heraus (SE37 Test) nicht, dort kann man alle Werte updaten.
2.
Um das Problem zu lösen, hat man für eine Konvertierung im FuBa entschieden: 2@ bzw. 3@ sollen auf @@ bzw. @@@ umgeschlüsselt werden. Obwohl das Coding zur Umschlüsselung offensichtlich OK ist, scheinen die mitgegebenen Werte (also 2@ und 3@ nicht umgeschlüsselt zu sein, stattdessen wird 2@ und 3@ auf die Datenbank geschrieben, mit Änderungsbeleg, etc. Nach dem Hinweis oben bin ich mir dann relaktiv sicher, dass der RFC.-Aufruf noch das alte Coding, ohne Umschlüsselung, liest, daher greift diese Änderung nicht. Teste ich in der SE37, wird natürlich umgeschlüsselt. Der Verdacht wird dadurch verstärkt, dass in der Zwischenzeit auch eine temporäre Abhilfe eingebaut wurde: sofort beim Anfang wird der Input-Wert für dieses CHAR3 Feld auf eine neue Z-Tabelle geschrieben, nur um zu sehen was wirklich drin ist. Bein RFC-Aufruf bleibt die Z-Tabelle leer, beim Test in der SE37 nicht. Dieses Coding wird immer ausgeführt, es ist also schwer zu erklären wieso die Z-Tabelle nicht aktualisiert wird (mit welchem Wert auch immer). Die Endlosschleife wird offensichtlich auch nicht prozessiert (obwohl sie ganz eindeutig durchlaufen werden müsste), wenn über RFC gerufen wird, in der SE37 kommt man sofort in die Schleife. Also daraus schliesse ich eindeuitg den Schluss, dass das aktuelle Coding beim RFC-Aufruf noch nicht ausgeführt wird.
Angenommen der RFC-Aufruf arbeitet mit dem aktuellen Coding (das soll am Montag passieren), dann wird ganz bestimmt die Z-Tabelle fortgeschrieben und das Programm kommt auch in die Endlosschleife. Hier verstehe ich immer noch nicht, ob es zum erfolgreichen Debuggen erforderlich ist, dass der RFC-Benutzer, under dessen Namen ja das ganze läuft, debuggen kann, oder es reicht auch aus, wenn ich mit meinem eigenen Benutzer rangehe. Warum der Benutzertyp nicht auf Dialog umgestellt werden kann (für den RFC-User), kann ich nicht sagen, der Kunde hat hier irgendwelche interne Regelung die automatisch auch den selben RFC-Benutzer im Produktivsystem auf Dialog umstellen würde (?), und das möchte man nicht. In diese Richtung kommen wir also nicht weiter, daher ist es für mich kritisch, ob mein eigener Benutzer in der SM50 ausreicht um debuggen zu können.
3.
Es gibt noch ein Thema das mir Kopfschmerzen macht: der Baustein hat auch einen Tabellenparameter der Texte (die zum Kreditlimit-Stammsatz KNKK abgelegt werden können) fortschreiben soll. Wird da eine Zeile (oder mehrere) in dieser Tabelle übergeben, sollen diese neue Zeilen ans Ende ggf. vorhandener Texte eingefügt werden. Gibt es keine bestehenden Texte, sollen sie angelegt werden. Funktioniert alles wunderbar wenn man in der SE37 testet. (Die Tabelle hat die Struktur TLINE). Nun wird beim RFC-Aufruf eine Zeile übergeben, wird diese gar nicht aktualisiert, als wäre nichts da. Wir haben einen ähnlichen FuBa, der von einem anderen externen System gerufen wird (über SAP Java Connector Version 3.0.6, beim anderen weiss ich nichts über das externe System). Hier werden gar keine Texte mitgegeben, und es ist auch OK wenn der Stammsatz auch noch keine Texte hat. Wenn jedoch bereits Texte im SAP vorhanden sind, werden diese irgendwie gelesen und dann doppelt zurückgeschrieben. Ruft man den Baustein für den selben (Test)kunden mehrmals auf, dann können in der Zwischenzeit so viele Texte gespeichert werden, dass die Verarbeitung mit dem Kurzdump EXPORT_TOO_MANY_DATA abgebrochen wird. Vorhandene Texte können dabei NUR dann gelesen werden, wenn in der Tabellenparameter nicht leer (T_TEXLINES[] NOT INITIAL) ist. Es wird aber ganz bestimmt gar nichts übergeben. Trotzdem kommt der baustein in den Zweig zum Update der Texte, die eindeutig obige Voraussetzung hat. Irgendwie habe ich den Eindruck, dass der Inhalt dieser Tabelle (TABLES-.Parameter) zwischen den einzelnen Aufrufen irgendwie nicht gelöscht wird (es gibt auch einen Baustein zum reinen Auslesen der Texte), sonst verstehe ich nicht wie man in den Zweig mit dem Texte fortschreiben kommt. Hier wäre die Möglichkeit zum Debuggen auch Gold wert....
Ich hoffe am Montag sind dann die Endlosschleifen endlich aktiv, und dann stellt sich schnell heraus ob ich (mit dem eigenen Benutzer) den RFC-Prozess auch debuggen kann... Der RFC-Benutzer verfügt schon über Berechtigung zum Debuggen, das konnte ich in der SU01 (nur Anzeigerechte) prüfen.
Vielen Dank nochmals für Eure Hinweise und Tipps. Ich denke am Montag werde ich mich wieder melden...
Gruß,
scsaba
Moin,
habe ein kleines ToDo zusammengestellt .
"Möge es sich erhellend auswirken."
gruß Jens
habe ein kleines ToDo zusammengestellt .
"Möge es sich erhellend auswirken."
gruß Jens
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Vergleichbare Themen
2
Antw.
Antw.
1736
Views
Views
3
Antw.
Antw.
2111
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 Stunden von DeathAndPain 2 / 111
vor 3 Stunden von DeathAndPain 2 / 111
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 Stunden von DeathAndPain 2 / 111
vor 3 Stunden von DeathAndPain 2 / 111