Fehlerhafte XML-Datei
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Hallo,
ich habe ein Problem mit einer fehlerhaften XML-Datei. Vielleicht kann mir jemand einen Hinweis geben, wo ich mit der Fehlersuche ansetzen kann. Bei der Beschreibung des Problems will ich mich erst mal auf eine allgemeine Beschreibung des Problems beschränken.
1) Erstellung einer XML-Datei auf einem Applikationsserver der Firma X
Mit Hilfe eines ABAP-Programms und einer Transformation wird aus einer Struktur (Source) ein XString ( Result) erstellt. Der XString wird dann mit Hilfe von Datei-Operationen (OPEN DATASET..., TRANSFER... und CLOSE DATASET) als XML-Datei auf dem Applikationsserver der Firma X abgelegt. Dort kann man sich die XML-Datei mit entsprechenden Werkzeugen (Filezilla, XML-Editoren, Browser usw) anschauen. Die Datei sieht fehlerfrei aus und zeigt die typische Baumstruktur einer XML-Datei.
2) Per FTP wird die XML-Datei dann auf einen weiteren Server (Axway-Server) der Firma X übertragen
3) Von dort wird die XML-Datei per HTTPS-Stream an die Firma Y übertragen.
Nun hat die Firma X von der Firma Y die Information erhalten, dass sporadisch!!! manche XML-Dateien nicht verarbeitet werden können. Die Firma Y hat uns diese "fehlerhaften" XML-Dateien zur Verfügung gestellt. Wenn man sich die fehlerhaften XML-Dateien anschaut, sieht man, dass nach dem Abschluss-Tag noch irgendwelche zusätzliche Zeichen zu sehen sind (zB das Zeichen NUL, Reste von Tags aus der aktuellen XML-Datei usw.).
Nun meine Frage: Wo kommen diese zusätzlichen Zeichen nach dem Ende der XML-Datei her?
Hat jemand eine Idee, wo auf dem Weg (Erstellung, FTP, HTTPS-Stream) von der Firma X zur Firma Y das passiert sein könnte?
Erschwerend kommt hinzu, dass das nur sehr sporadisch auftritt und die meisten XML-Dateien fehlerfrei von der Firma Y empfangen und verarbeitet werden können.
Mein Verdacht war anfangs, dass Reste des vorhergehenden XStrings im neuen XString landen (Loop-Verarbeitung, fehlende Initialisierung). Aber nach dem Erstellungsprogramm (Schritt 1) sehen alle XML-Dateien auf dem Server gut aus.
Danke und Gruß
einar
ich habe ein Problem mit einer fehlerhaften XML-Datei. Vielleicht kann mir jemand einen Hinweis geben, wo ich mit der Fehlersuche ansetzen kann. Bei der Beschreibung des Problems will ich mich erst mal auf eine allgemeine Beschreibung des Problems beschränken.
1) Erstellung einer XML-Datei auf einem Applikationsserver der Firma X
Mit Hilfe eines ABAP-Programms und einer Transformation wird aus einer Struktur (Source) ein XString ( Result) erstellt. Der XString wird dann mit Hilfe von Datei-Operationen (OPEN DATASET..., TRANSFER... und CLOSE DATASET) als XML-Datei auf dem Applikationsserver der Firma X abgelegt. Dort kann man sich die XML-Datei mit entsprechenden Werkzeugen (Filezilla, XML-Editoren, Browser usw) anschauen. Die Datei sieht fehlerfrei aus und zeigt die typische Baumstruktur einer XML-Datei.
2) Per FTP wird die XML-Datei dann auf einen weiteren Server (Axway-Server) der Firma X übertragen
3) Von dort wird die XML-Datei per HTTPS-Stream an die Firma Y übertragen.
Nun hat die Firma X von der Firma Y die Information erhalten, dass sporadisch!!! manche XML-Dateien nicht verarbeitet werden können. Die Firma Y hat uns diese "fehlerhaften" XML-Dateien zur Verfügung gestellt. Wenn man sich die fehlerhaften XML-Dateien anschaut, sieht man, dass nach dem Abschluss-Tag noch irgendwelche zusätzliche Zeichen zu sehen sind (zB das Zeichen NUL, Reste von Tags aus der aktuellen XML-Datei usw.).
Nun meine Frage: Wo kommen diese zusätzlichen Zeichen nach dem Ende der XML-Datei her?
Hat jemand eine Idee, wo auf dem Weg (Erstellung, FTP, HTTPS-Stream) von der Firma X zur Firma Y das passiert sein könnte?
Erschwerend kommt hinzu, dass das nur sehr sporadisch auftritt und die meisten XML-Dateien fehlerfrei von der Firma Y empfangen und verarbeitet werden können.
Mein Verdacht war anfangs, dass Reste des vorhergehenden XStrings im neuen XString landen (Loop-Verarbeitung, fehlende Initialisierung). Aber nach dem Erstellungsprogramm (Schritt 1) sehen alle XML-Dateien auf dem Server gut aus.
Danke und Gruß
einar
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 / 4281 / 214 /
1140
)
»
Ich kenn das von anderer Stelle:
Oft müssen in SAP die Daten im Speicher vor der Übertragung in Tabellen mit fixer Zeilenlänge aufgeteilt werden (z.B. GUI-Up/Download)
Wenn dann die "Länge" nicht richtig bekannt ist, werden am Schluss der Datei noch Leerzeichen (Nullzeichen) angefügt bis eben das Ende der letzten (eigentlich nur zum Teil gefüllten) Tabellenzeile erreicht ist.
Daher ist es sehr wichtig, nicht auf die Längenangabe zu vergessen. Ich weiß jetzt nicht wie ihr die FTP-Übertragung macht (File generieren und mit PUT übertragen oder per Stream direkt aus dem Speicher senden) aber ich vermute den Fehler bei der richtigen Längenermittlung der Ausgabe. (Da ja am Ende der Datei die Fehler auftreten)
Ansonsten könnte auch ein Unicode- oder generell ein Codepage-Problem zwischen den beteiligten Systemen bestehen.
Auch hatte ich schon mal ein Problem, dass aufgrund einer unterschiedlichen Codepage, schon beim Generieren der XML-Datei aufgetreten ist: Der XML-Documenttyp (IF_IXML_DOCUMENT_TYPE) war auf Unicode eingestellt und ich hab im XHTML-HEAD Abschnitt daber den Document-Type auf ISO-8859-1 gesetzt. Das hat dann nur Probleme verursacht.
lg ADT
Oft müssen in SAP die Daten im Speicher vor der Übertragung in Tabellen mit fixer Zeilenlänge aufgeteilt werden (z.B. GUI-Up/Download)
Wenn dann die "Länge" nicht richtig bekannt ist, werden am Schluss der Datei noch Leerzeichen (Nullzeichen) angefügt bis eben das Ende der letzten (eigentlich nur zum Teil gefüllten) Tabellenzeile erreicht ist.
Daher ist es sehr wichtig, nicht auf die Längenangabe zu vergessen. Ich weiß jetzt nicht wie ihr die FTP-Übertragung macht (File generieren und mit PUT übertragen oder per Stream direkt aus dem Speicher senden) aber ich vermute den Fehler bei der richtigen Längenermittlung der Ausgabe. (Da ja am Ende der Datei die Fehler auftreten)
Ansonsten könnte auch ein Unicode- oder generell ein Codepage-Problem zwischen den beteiligten Systemen bestehen.
Auch hatte ich schon mal ein Problem, dass aufgrund einer unterschiedlichen Codepage, schon beim Generieren der XML-Datei aufgetreten ist: Der XML-Documenttyp (IF_IXML_DOCUMENT_TYPE) war auf Unicode eingestellt und ich hab im XHTML-HEAD Abschnitt daber den Document-Type auf ISO-8859-1 gesetzt. Das hat dann nur Probleme verursacht.
lg ADT
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 ADT,
danke für Deine schnelle Antwort.
Ich werde mir das FTP-Programm (2.Schritt) bezüglich der Längenbestimmung anschauen.
Die Codepage-Problematik werde ich ebenfalls genauer prüfen.
Jetzt fällt mir noch ein wichtiger Hinweis ein. Die fehlerhaften XML-Dateien müssen natürlich nochmals an die Firma Y übertragen werden. "Geheilt" werden die XML-Dateien in der Firma X, indem ein Mitarbeiter die Dateien einmal öffnet und dann gleich wieder schließt (speichert?). Die erneute Übertragung und Verarbeitung erfolgt dann problemlos.
Danke und Gruß
einar
danke für Deine schnelle Antwort.
Ich werde mir das FTP-Programm (2.Schritt) bezüglich der Längenbestimmung anschauen.
Die Codepage-Problematik werde ich ebenfalls genauer prüfen.
Jetzt fällt mir noch ein wichtiger Hinweis ein. Die fehlerhaften XML-Dateien müssen natürlich nochmals an die Firma Y übertragen werden. "Geheilt" werden die XML-Dateien in der Firma X, indem ein Mitarbeiter die Dateien einmal öffnet und dann gleich wieder schließt (speichert?). Die erneute Übertragung und Verarbeitung erfolgt dann problemlos.
Danke und Gruß
einar
Hallo,
hier sind noch ein paar Zusatzinformationen in Form von Code-Schnipseln aus dem Programm (ich habs nicht geschrieben, ich soll nur den Fehler suchen), das die XML-Datei erstellt:
1) Erstellung der XML-Datei auf einem Applikationsserver
1a) Transformation wandelt die Ausgangsstruktur in einen XString um
CALL TRANSFORMATION z_notif
SOURCE rt = p_gs_out_xml <--- Ausgangsstruktur für die Transformation
RESULT XML xml_xstr. <--- TYPE xstring
1b) Konvertierung XString in String
CALL METHOD cl_abap_conv_in_ce=>create
RECEIVING
conv = loc_obj_in_conv. <--- TYPE REF TO cl_abap_conv_in_ce
CALL METHOD loc_obj_in_conv->convert
EXPORTING
input = xml_str <--- TYPE xstring
IMPORTING
data = loc_string. <--- TYPE string
loc_string wird in eine Tabelle pt_out_string gestellt.
1c) Erstellung XML-Datei
* Open dataset
OPEN DATASET pv_ext_path_file <--- Pfad und Dateiname auf dem Applikationsserver
FOR OUTPUT
IN TEXT MODE
ENCODING NON-UNICODE MESSAGE pv_msg.
IF sy-subrc EQ 0.
* Transfer data
LOOP AT pt_out_string. <--- TYPE stringtab (enthält nur eine!!! Zeile, ist aber so gemacht im Programm, siehe Pkt. 1b)
TRANSFER pt_out_string TO pv_ext_path_file.
ENDLOOP.
* Close dataset
CLOSE DATASET pv_ext_path_file.
ENDIF.
Die so erstellte XML-Datei kann man sich nun auf dem Server anschauen.
Sind in der XML-Datei Umlaute enthalten, können Browser (zB Firefox) die XML-Datei nicht darstellen und zeigen die Fehlermeldung, dass die XML-Datei "nicht wohlgeformt" ist.
Mit XML-Utilities (zB notepad++) kann man sich die XML-Datei sehr wohl anschauen und sieht dann zB bei den Umlauten die hexadezimale Darstellung xF6 für ein ö.
Könnte das das Problem sein?
Jetzt würde der 2. Schritt des FTP auf einen anderen Server erfolgen (siehe Ausgangsproblem).
Gruß
einar
hier sind noch ein paar Zusatzinformationen in Form von Code-Schnipseln aus dem Programm (ich habs nicht geschrieben, ich soll nur den Fehler suchen), das die XML-Datei erstellt:
1) Erstellung der XML-Datei auf einem Applikationsserver
1a) Transformation wandelt die Ausgangsstruktur in einen XString um
CALL TRANSFORMATION z_notif
SOURCE rt = p_gs_out_xml <--- Ausgangsstruktur für die Transformation
RESULT XML xml_xstr. <--- TYPE xstring
1b) Konvertierung XString in String
CALL METHOD cl_abap_conv_in_ce=>create
RECEIVING
conv = loc_obj_in_conv. <--- TYPE REF TO cl_abap_conv_in_ce
CALL METHOD loc_obj_in_conv->convert
EXPORTING
input = xml_str <--- TYPE xstring
IMPORTING
data = loc_string. <--- TYPE string
loc_string wird in eine Tabelle pt_out_string gestellt.
1c) Erstellung XML-Datei
* Open dataset
OPEN DATASET pv_ext_path_file <--- Pfad und Dateiname auf dem Applikationsserver
FOR OUTPUT
IN TEXT MODE
ENCODING NON-UNICODE MESSAGE pv_msg.
IF sy-subrc EQ 0.
* Transfer data
LOOP AT pt_out_string. <--- TYPE stringtab (enthält nur eine!!! Zeile, ist aber so gemacht im Programm, siehe Pkt. 1b)
TRANSFER pt_out_string TO pv_ext_path_file.
ENDLOOP.
* Close dataset
CLOSE DATASET pv_ext_path_file.
ENDIF.
Die so erstellte XML-Datei kann man sich nun auf dem Server anschauen.
Sind in der XML-Datei Umlaute enthalten, können Browser (zB Firefox) die XML-Datei nicht darstellen und zeigen die Fehlermeldung, dass die XML-Datei "nicht wohlgeformt" ist.
Mit XML-Utilities (zB notepad++) kann man sich die XML-Datei sehr wohl anschauen und sieht dann zB bei den Umlauten die hexadezimale Darstellung xF6 für ein ö.
Könnte das das Problem sein?
Jetzt würde der 2. Schritt des FTP auf einen anderen Server erfolgen (siehe Ausgangsproblem).
Gruß
einar
Beitrag
von a-dead-trousers (Top Expert / 4281 / 214 /
1140
)
»
Das wäre wesentlich schneller und stabiler:
Stell doch bitte bei deiner Transformation "z_notif" mal den DocTyp auf "ISO-8859-1" ein:
Beim Dateiexport auf das File-System verwendest du nämlich "NON-UNICODE".
lg ADT
Code: Alles auswählen.
CALL TRANSFORMATION z_notif
SOURCE rt = p_gs_out_xml
RESULT XML ld_string.
OPEN DATASET pv_ext_path_file
FOR OUTPUT
IN TEXT MODE
ENCODING NON-UNICODE MESSAGE pv_msg.
TRANSFER ld_string TO pv_ext_path_file.
CLOSE DATASET pv_ext_path_file.Vermutlich wirst du dazu nix finden, da ja eine Datei auf dem Appl.Server abgelegt wird und diese dann mit PUT übertragen wird.einar46 hat geschrieben:Ich werde mir das FTP-Programm (2.Schritt) bezüglich der Längenbestimmung anschauen.
Das klingt schon eher danach, dass dein Problem von der Codepage herrührt.einar46 hat geschrieben:Die Codepage-Problematik werde ich ebenfalls genauer prüfen.
Jetzt fällt mir noch ein wichtiger Hinweis ein. Die fehlerhaften XML-Dateien müssen natürlich nochmals an die Firma Y übertragen werden. "Geheilt" werden die XML-Dateien in der Firma X, indem ein Mitarbeiter die Dateien einmal öffnet und dann gleich wieder schließt (speichert?). Die erneute Übertragung und Verarbeitung erfolgt dann problemlos.
Ich glaub wir haben den Fehler gefunden.einar46 hat geschrieben:Sind in der XML-Datei Umlaute enthalten, können Browser (zB Firefox) die XML-Datei nicht darstellen und zeigen die Fehlermeldung, dass die XML-Datei "nicht wohlgeformt" ist. Mit XML-Utilities (zB notepad++) kann man sich die XML-Datei sehr wohl anschauen und sieht dann zB bei den Umlauten die hexadezimale Darstellung xF6 für ein ö.
Könnte das das Problem sein?
Stell doch bitte bei deiner Transformation "z_notif" mal den DocTyp auf "ISO-8859-1" ein:
Code: Alles auswählen.
<xsl:output encoding="ISO-8859-1" />lg ADT
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
Seite 1 von 1
Vergleichbare Themen
47
Antw.
Antw.
8578
Views
Views
4
Antw.
Antw.
2212
Views
Views
1
Antw.
Antw.
477
Views
Views
Fehlerhafte FAX-Sendungen (SCOT) erneut anstoßen - Job
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger
von f.weissenberger » 23.09.2019 13:03 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
3233
Views
Views
fehlerhafte workflows aus business-workplace entfernen?
von Loki » 20.08.2004 12:27 • Verfasst in ABAP Objects®
von Loki » 20.08.2004 12:27 • Verfasst in ABAP Objects®
2
Antw.
Antw.
6981
Views
Views
analog COGI: Fehlerhafte Warenbewegungen im Hintergrund
von hsiebert » 05.09.2007 11:31 • Verfasst in Material Management & Produktionsplanung
von hsiebert » 05.09.2007 11:31 • Verfasst in Material Management & Produktionsplanung
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.