Aufruf RFC/Call Transaction
6 Beiträge
•
Seite 1 von 1
6 Beiträge
Seite 1 von 1
Hallo zusammen.
Habe folgendes Problem:
Aus Java wird ein RFC aufgerufen, der einen PM-Auftrag anlegt (TCode IW31). Erstellt der FB eine Batch Input Mappe, funktioniert alles blendend. Wird dagegen im FB ein Call Transaction aufgerufen, wird eine Fehlermeldung zurückgegeben. Daten für Dynpro.... nicht vorhanden.
Wird der FB aus SAP angestartet, läuft er fehlerfrei durch. Konvertierungskonflikte liegen keine vor.
Hat dafür jemand eine Erklärung?
Gruss
Jürgen
Habe folgendes Problem:
Aus Java wird ein RFC aufgerufen, der einen PM-Auftrag anlegt (TCode IW31). Erstellt der FB eine Batch Input Mappe, funktioniert alles blendend. Wird dagegen im FB ein Call Transaction aufgerufen, wird eine Fehlermeldung zurückgegeben. Daten für Dynpro.... nicht vorhanden.
Wird der FB aus SAP angestartet, läuft er fehlerfrei durch. Konvertierungskonflikte liegen keine vor.
Hat dafür jemand eine Erklärung?
Gruss
Jürgen
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Wird ein eigener RFC aufgerufen, oder ein BAPI im Standard?
Grundsätzlich kann es bei Call Transaction dann zu Problemen kommen (im RFC), wenn versucht wird, Dynpros zu prozessieren (was im RFC auf keinen Fall geht). Möglicherweise liegt es auch daran, daß die Datenübergabe beim Call Transaction nicht vollständig ist. Wie erfolgt der Aufruf?
Hermann
Grundsätzlich kann es bei Call Transaction dann zu Problemen kommen (im RFC), wenn versucht wird, Dynpros zu prozessieren (was im RFC auf keinen Fall geht). Möglicherweise liegt es auch daran, daß die Datenübergabe beim Call Transaction nicht vollständig ist. Wie erfolgt der Aufruf?
Hermann
Es handelt sich um einen eigenen RFC. Call Transaction läuft dunkel ab.
Test des FB ist ok. Aufruf aus anderem ABAP funktioniert auch. Tabelle t_bdcdata korrekt gefüllt.
Datenübergabe aus Java ist auch ok. Zur Kontrolle werden die Daten wieder an Java zurückgegeben.
Batch-Input läuft ja auch.
Jürgen
Test des FB ist ok. Aufruf aus anderem ABAP funktioniert auch. Tabelle t_bdcdata korrekt gefüllt.
Datenübergabe aus Java ist auch ok. Zur Kontrolle werden die Daten wieder an Java zurückgegeben.
Batch-Input läuft ja auch.
Jürgen
Code: Alles auswählen.
CLEAR opt.
MOVE 'N' TO opt-dismode. " dunkel abspielen
MOVE 'S' TO opt-updmode. " synchron
MOVE ' ' TO opt-cattmode. " kein Catt aktiv
MOVE ' ' TO opt-defsize. " Standard-Fenstergröße
MOVE ' ' TO opt-racommit. " kein Ende bei COMMIT WORK
MOVE 'X' TO opt-nobinpt. " kein Batch-Input-Modus
MOVE 'X' TO opt-nobiend. " kein Batch-Input-Modus
CALL TRANSACTION 'IW31' USING t_bdcdata
OPTIONS FROM opt
MESSAGES INTO t_message.
Ist in der Tat seltsam. Wenn ich es richtig verstanden habe, funktioniert der call transaction aus dem ABAP heraus problemlos.
Beim Aufruf von Java, funktioniert es nicht wg. Fehler 'Fehlende Daten ... Dynpro'.
Könnte es am Benutzer liegen (unterschiedliche bzw. fehlende Berechtigung des RFC-Users von Java aus)?
Hermann
Beim Aufruf von Java, funktioniert es nicht wg. Fehler 'Fehlende Daten ... Dynpro'.
Könnte es am Benutzer liegen (unterschiedliche bzw. fehlende Berechtigung des RFC-Users von Java aus)?
Hermann
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
1083
Views
Views
Aufruf meherer CALL TRANSACTION's nacheinander wg. verbuchun
von Michael A. » 20.01.2006 09:57 • Verfasst in ABAP® Core
von Michael A. » 20.01.2006 09:57 • Verfasst in ABAP® Core
5
Antw.
Antw.
3465
Views
Views
Problem bei Aufruf eines Dynpros mit Call Transaction
von Wejbora » 06.03.2006 14:51 • Verfasst in Dialogprogrammierung
von Wejbora » 06.03.2006 14:51 • Verfasst in Dialogprogrammierung
1
Antw.
Antw.
3592
Views
Views
1
Antw.
Antw.
2078
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.