wir versenden E-Mails mit SO_DOCUMENT_SEND_API1
Anlagen lesen wir aus den TOA Tabellen.
Seit dem Upgrade des Systems auf Unicode funktioniert die Konvertierung der Binärdaten der TOA Tabellen (Type x, 1024) in Char nicht mehr. egal ob Zuweisung an ein Feldsymbol (Dort hat er dann nur noch 512 Zeichen statt 1024) oder Nutzung von SO_SOLIXTAB_TO_SOLITAB, es sieht dann wie im Anhang aus.
(Der ursprüngliche Weg war: lesen der daten aus TOA, Zuweisung an Feldsymbol:
ASSIGN daten to <f> TYPE 'C')
SCMS_BIN_TO_TEXT bringt nur mäßigen Erfolg. Anfangs sieht es gut aus, dann werden die Zeichen auch wieder seltsam. (Siehe ebenfalls Anhang)
Hat hier jemand eine Ahnung was hier getan werden muss?
Danke und Grüße
Ben
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Das ist immer toll wenn man ein System unbedarft auf Unicode umstellt und man dann hinterher auf die Ganzen Fallstricken aufmerksam wird.
Am Besten verwendet ihr die Methode CL_ABAP_CONV_IN_CE=>CONVERT unter Angabe der Codepage unter der ihr die Daten im Archiv abgelegt habt. Standard in non-Unicode ist 1100 (bzw. 1160 für Windows).
Um die Daten im Archiv (in der alten Codepage) abzulegen verwendet ihr am Besten das Gegenstück CL_ABAP_CONV_OUT_CE=>CONVERT.
Falls ihr bereits damit begonnen habt neue Daten produktiv mit einer Unicode-Codierung dort abzulegen, dann viel Spaß die Datenbestände beim Auslesen wieder auseinanderzudividieren. Wir haben da bei uns mit einer Heuristik alle Datensätz einen nach dem anderen durchschauen müssen um zu erkennen ob wir das (einmalig) auf Unicode umstellen müssen oder nicht nur damit wir dann beim Auslesen keine Probleme mehr hatten.
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.
Nachtrag:
Ich seh grad, dass es im konkreten Fall (erster Screenshot) eigentlich um PDFs geht, oder?
Die dürfen doch gar nicht in CHAR umgewandelt werden. Das sind doch quasi "Binärdaten". Auch wenn man Teile davon mit einem Texteditor lesen kann. Wenn ihr hier irgendeine Art von Codepage-Konvertierung macht, zerschießt ihr damit euch die ganzen PDFs. Denn je nach Zeichencode können unterschiedliche Zeichen entstehen die dann nicht mehr interpretiert werden können.
Wenn ihr da z.B. hin zum Archiv eine (implizite) Zeichenkonvertierung gemacht habt (was uns leider bei ARCHIVOBJECT_CREATE_TABLE mit ARCHIVOBJECT anstatt BINARCHIVOBJECT passiert ist) dann habt ihr da im Moment als ISO-8859-1 konvertierte Binärdaten abgelegt. Das haben wir Gottseidank noch rechtzeitig bemerkt und die falsch abgelegten Archivdaten vor der großen Umstellung als Text zurückgelesen und korrekt als Binärdaten abgelegt.
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.
Pfuh... Glück gehabt.
Nein, im dem Fall reicht es wenn du die Daten einfach so verschickst wie du sie vom BO bekommst: Mit CONTENTS_HEX anstatt CONTENTS_TXT/CONTENTS_BIN des SO_DOCUMENT_SEND_API1.
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.
guter Tipp, da hätte ich wahrscheinlich gar nicht geschaut, dass dem FB diese Tabelle übergeben werden kann.
Ich kann aber trotzdem beide übergeben oder?
Da das eigentliche Dokument ja über den OTF stream gewandelt wird und anschließend dann in die BIN gestellt wird.
Nur mit den Anlagen haben wir jetzt solche Probleme.
Verstehe ich das richtig, dass ihr MEHRERE Anhänge zu einer Email habt?
Da auch der umgewandelte OTF Stream im Grund eine Binärdatei (PDF?) ist, würde ich auch diesen über den HEX-Parameter übergeben. Bei jeder Umwandlung könnten nämlich immer Daten verloren gehen oder falsch interpretiert werden.
Eine weitere Empfehlung meinerseits wäre von SO_DOCUMENT_SEND_API1 weg und hin zu CL_BCS zu gehen. Die Klasse CL_DOCUMENT_BCS bietet hier eine viel genauere Möglichkeit der Attachment-Verwaltung je Objekt. Nicht so wie beim Fub, dass man alles in eine Tabelle stopft und dann mittels Index und Länge die Objekte wieder unterscheidbar machen muss.
Anleitungen für CL_BCS sollte es zuhauf im Netz und auch hier im Forum geben.
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.
Ja genau, so ist es.
Die (in diesem Beispiel) Faktura kommt als OTF der Rest wird aus dem Archiv dazu gelesen.
Okay, dann werde ich das für den OTF auch umbauen.
Ja das ist der Plan für die Zukunft dies auf jeden Fall objektorientiert abzulösen.
Danke bis hierhin, ich hoffe damit komme ich jetzt erst einmal weiter.