Hi Mohammad,
can you also let us know the name of the function module being used here?
Important is also the datatype of the field PDF_CONTENT-TDLINE. I would expect that this field has a binary type (RAW or XSTRING), because PDF is basically a binary format, not a text-based (character) format. Without knowing the datatype, we can't say, whether the data is correct or not. For example, if you dump binary data into an XML file like the one above, the bytes may actually "look like" Chinese characters, even though they are not... So the data may actually be correct, who knows...
In order to take a look at the "real" binary data transferred during the RFC call, you can activate RFC trace for that call and attach the trace file here. (Tools can extract the RAW data from the trace.)
Next I noticed that in every line of the PDF_CONTENT table the field TDFORMAT has a different value. In order to correctly interpret the data, we will probably also need to know, what the meaning of this TDFORMAT field is.
Best Regards, Ulrich
PS: also I'm not sure, whether I already understood the scenario correctly. So in order to clarify: the PDF file currently exists in the SAP system and you are working on the external system, which wants to get this file, correct? Is the external system calling this FM in the SAP system (using NW RFC library, JCo or NCo?!) in order to fetch the PDF file, or is the SAP system calling this FM in the external system in order to send the PDF file?
Message was edited by: Ulrich Schmidt