RFC FuBa Call - Korrupte Daten
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Beitrag
von der_neuling (ForumUser / 87 / 17 /
3
)
»
Hallo an alle,
derzeit sitze ich vor einem Problem. Ich rufe einen Z-FuBa aus einem anderen System auf (der kapselt wiederum Standard FuBa, man kennts).
Die originale Tabellendefinition ist nur auf dem Quellsystem vorhanden, deswegen wurde diese manuell ins Zielsystem kopiert.
Die Daten kommen nur leider korrupt am Zielsystem an. Auf der Quellseite ist noch alles i.O.
Da die Daten erst ab ca. der Hälfte kaputt gehen keimt der Verdacht auf, dass die Strukturen nicht zusammen passen, ich habe das aber geprüft und Feldname sowie Datentyp sind auf ganzer Strecke i.O. (siehe angehängtes .txt File).
Der Einzige Unterschied ist, dass am Zielsystem die Struktur keine .Includes, sondern nur die Felder an sich enthält, könnte es daran liegen?
Das Quellsystem ist in der SM59 als Unicode System konfiguriert.
Folgende Beobachtung konnte ich im Debugger machen: Der absolute Wert für ITM_TYPE ist in beiden Fällen null, es unterscheidet sich aber der hexadezimale Wert.
Im Quellsystem ist das Feld mit einem Standarddatenelement versehen, in der kopierten Struktur mit dem zugrundeliegenden elementaren Datentyp (CHAR4):
derzeit sitze ich vor einem Problem. Ich rufe einen Z-FuBa aus einem anderen System auf (der kapselt wiederum Standard FuBa, man kennts).
Die originale Tabellendefinition ist nur auf dem Quellsystem vorhanden, deswegen wurde diese manuell ins Zielsystem kopiert.
Die Daten kommen nur leider korrupt am Zielsystem an. Auf der Quellseite ist noch alles i.O.
Da die Daten erst ab ca. der Hälfte kaputt gehen keimt der Verdacht auf, dass die Strukturen nicht zusammen passen, ich habe das aber geprüft und Feldname sowie Datentyp sind auf ganzer Strecke i.O. (siehe angehängtes .txt File).
Der Einzige Unterschied ist, dass am Zielsystem die Struktur keine .Includes, sondern nur die Felder an sich enthält, könnte es daran liegen?
Das Quellsystem ist in der SM59 als Unicode System konfiguriert.
Folgende Beobachtung konnte ich im Debugger machen: Der absolute Wert für ITM_TYPE ist in beiden Fällen null, es unterscheidet sich aber der hexadezimale Wert.
Im Quellsystem ist das Feld mit einem Standarddatenelement versehen, in der kopierten Struktur mit dem zugrundeliegenden elementaren Datentyp (CHAR4):
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
.INCLUDE ist in SAP/ABAP kein (physischer) Bestandteil einer Struktur.
Der Wechsel zwischen UNICODE und NON-UNICODE ist das Problem.
Wie erfolgt die Datenübergabe? Als RFC Aufruf oder per String bzw. (Text-)Datei?
Der Wechsel zwischen UNICODE und NON-UNICODE ist das Problem.
Wie erfolgt die Datenübergabe? Als RFC Aufruf oder per String bzw. (Text-)Datei?
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 der_neuling (ForumUser / 87 / 17 /
3
)
»
Aufruf per RFC Baustein. Das aufgerufenen System ist wie folgt definiert in SM59:a-dead-trousers hat geschrieben: ↑17.04.2024 23:22Der Wechsel zwischen UNICODE und NON-UNICODE ist das Problem.
Wie erfolgt die Datenübergabe? Als RFC Aufruf oder per String bzw. (Text-)Datei?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
Hab deine Vergleichs-Screenshots nochmal angesehen:
Du scheinst doch eher einen "Dreher" zwischen BE (Big Endian) und LE (Little Endian) zu haben.
2000 ist ein Leerzeichen in LE
0020 ist ein Leerzeichen in BE
Versuch mal bei der RFC-Verbindung eine fixe Codepage (die aus dem Quellsystem) zu hinterlegen, anstatt "aus der Anmeldesprache".
Du scheinst doch eher einen "Dreher" zwischen BE (Big Endian) und LE (Little Endian) zu haben.
2000 ist ein Leerzeichen in LE
0020 ist ein Leerzeichen in BE
Versuch mal bei der RFC-Verbindung eine fixe Codepage (die aus dem Quellsystem) zu hinterlegen, anstatt "aus der Anmeldesprache".
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 der_neuling (ForumUser / 87 / 17 /
3
)
»
Hab ich probiert, alle Codepages die wir verwenden habe ich in der SM59 erzwungen, keine Veränderung.a-dead-trousers hat geschrieben: ↑18.04.2024 08:59Du scheinst doch eher einen "Dreher" zwischen BE (Big Endian) und LE (Little Endian) zu haben.
Versuch mal bei der RFC-Verbindung eine fixe Codepage (die aus dem Quellsystem) zu hinterlegen, anstatt "aus der Anmeldesprache".
Was mir noch aufgefallen ist: Der Beginn wo alles schief wird ist das Feld ICC_BR_STEUC (char16). Ich habe nun mal im Quellsystem das eigentlich leere Feld komplett befüllt mit '2111111111111112'. Wenn ich nun wieder im Zielsystem bin sieht man, dass SAP das Zeichen '#' einfach reinschiebt, und alles darunter verschiebt sich dann logischerweise:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
Du könntest beim Funktionsbaustein noch "basXML" einstellen. Dann müssen die Strukturfelder nicht nur von der Position sondern auch vom Namen her übereinstimmen. Vielleicht gibts dann eine aussagekräftige Fehlermeldung, wenn vom Aufruf her Strukturgrenzen nicht eingehalten werden.
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 / 4287 / 214 /
1142
)
»
Oder ist irgendwas zwischengeschalten? Ein Proxy vielleicht?
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 der_neuling (ForumUser / 87 / 17 /
3
)
»
Kein Proxy dazwischen. Den Fehler konnte ich inzwischen durch einen Workaround lösen. Das DTEL ist irgendwas spezifisches zu Mercosur Ländern. Da ich dieses Feld nicht brauche habe ich den Z-Fuba statt der Standard Tabelle mit einer Z-Tabelle ohne dieses Feld bestückt, nun funktioniert es wieder.a-dead-trousers hat geschrieben: ↑18.04.2024 17:13Oder ist irgendwas zwischengeschalten? Ein Proxy vielleicht?
Warum das initial den Fehler überhaupt verursacht hat ist aber weiterhin unklar...
Seite 1 von 1
Vergleichbare Themen
8
Antw.
Antw.
2410
Views
Views
1
Antw.
Antw.
2248
Views
Views
FuBa: Importparamter an Dynpro übergeben / Call Screen
von Thendic » 20.01.2006 08:44 • Verfasst in ABAP® Core
von Thendic » 20.01.2006 08:44 • Verfasst in ABAP® Core
2
Antw.
Antw.
1547
Views
Views
1
Antw.
Antw.
2153
Views
Views
5
Antw.
Antw.
767
Views
Views
FUBA mit FUBA RSPO_OUTPUT_DEVICEDATA eine Liste ausgeben
von Thomas E » 06.05.2021 12:49 • Verfasst in ABAP® Core
von Thomas E » 06.05.2021 12:49 • Verfasst in ABAP® Core
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.