Invalid character in xml transformation output file

[Former Member]

While creating xml file using xml transformation(STRANS) I am getting illegal character for which our customer is not able to process the file in their system.

Following is the code for transforming internal table using STRANS.

<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:sap="http://www.sap.com/sapxsl" xmlns:asx="http://www.sap.com/abapxml" exclude-result-prefixes="asx" version="1.0">

  <xsl:output indent="no"/>

  <xsl:strip-space elements="*"/>

  <xsl:template match="/asx:abap/asx:values/CONFIRM">

    <Order xmlns="urn:carrier:names:specification:ubl:schema:xsd:CarrierPOResponse-2.0" xmlns:cac="urn:oasis:names:draft:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:draft:ubl:schema:xsd:CommonBasicComponents-2" xmlns:xsi=

"http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:carrier:names:specification:ubl:schema:xsd:CarrierPOResponse-2.0 ../../src/xsd/runtime/maindoc/UBL-&#xA;CarrierPOResponse-2.0.xsd">

      <xsl:for-each select="*">

        <xsl:if test="ID !=''">

          <cbc:ID>

            <xsl:value-of select="ID"/>

          </cbc:ID>

          <cbc:CopyIndicator>

            <xsl:value-of select="COPYINDICATOR"/>

          </cbc:CopyIndicator>

        </xsl:if>

      </xsl:for-each>

and xml output of the file is:

<?xml version="1.0" encoding="utf-8"?><Order xmlns="urn:carrier:names:specification:ubl:schema:xsd:CarrierPOResponse-2.0" xmlns:cac="urn:oasis:names:draft:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:draft:ubl:schema:xsd:CommonBasicComponents-2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:carrier:names:specification:ubl:schema:xsd:CarrierPOResponse-2.0 ../../src/xsd/runtime/maindoc/UBL-CarrierPOResponse-

In the output file there is special character between encoding="utf-8"?>and<Order xmlns=" ( see the first line of output file, and position 38) which is causing issue in reading the file in our customer's system.

Please help me to get rid of this special character from the xml output file. Let me know if you need any more information. We are using SAP ECC 6.0.

[former_member16322]

Quick question, is there supposed to be a Carriage Return Line Feed between "utf-8"> and <Order?

Is it possible only the Carriage Return or Line Feed has been added to the end of the line; and the program throwing the error does not know know how to process it on it's own?

I know when generating files, I sometimes have to manually add the other byte to the CrLf.

Just a shot in the dark.

Do you have an Hex Editor you could use to examine the file and see what byte is between the two ><?If you see what the Hex code for that byte is, it may point you in the correct direction.

Edit - In Hex CrLf is usually 0d0a; so if you see either of those there in the hex editor, it is possibly what I described above.

[Former Member]

Thanks for your response. I see OA in the hex editor for the special character. Not sure how it's getting into the file and prevent SAP from putting the special character.

[former_member16322]

If you have a test environment for this other program, I'd recommend inserting the 0d in front of the 0a and seeing if you can run the file through. FYI - That is Zero A, not O A; if you try to insert a O in Hex, I'm not sure what would happen.

Unfortunately, I am not familiar with STRANS, so I don't know why it would be leaving off the other half of the CrLf; I just know I had to do the same when writing my own files.

It maybe a code page issue for the file STRANS is creating. I only have this problem when creating an ASCII file in ABAP.

Edit - Oh yeah, it may be 0a0d or 0d0a or either one for CrLf; can't remember.

[Former Member]

I am not inserting this special character(which is 0A in hex editor) in the xml output file but SAP is doing it. I want to remove this character from the output file.

[former_member16322]

Yes, this special character, 0a, is being inserted by SAP; this special character is a line feed; SAP for certain code pages does not appear to create the whole CrLf pair 0d0a.

What I was suggesting, to prove the point, was to insert the other half, 0d, and test it.

You can test this yourself without running through the program that processes that output file. If you open you output file in notepad, there will not be a new line between ><order; however, if you make the full 0d0a pair, by inserting the 0d manually yourself, then open the file in notepad, <order should appear on a new line.

As I stated, this is for testing and proof of concept.

So knowing this, you have 2 options to correct:

1. Figure out why SAP is only using half of the CrLf pair; which is probably a code page issue for the output file being created. Then correct that problem.

2. Remove the new line between > and <order. What ever generates the output file, remove the new lines from it, your output file will be one long line then; but should work.

For either option, I am not familiar with STRANS, so not sure how to go about doing either; but at least you know the exact problem now.

Edit - Simply cleaned it up a bit.

[Former Member]

Thanks for your response. I really appreciate you trying to help me.

I tried putting 0d and 0D but it did not put line break. Now, when I put od or OD and save the notepad and when I try to open the file in browser, it says there is error in file.

I am still trying to break the line in XML. Do you know command which breaks line in xml for SAP?

[former_member16322]

Did you try the 0d both before and after the 0a? I can't remember the exact order it needs to be in.

I find it weird notepad would not be able to interpret 0d0a or 0a0d, which ever it is, since that is the CrLf Hex for windows systems.

Unfortunately, I do not know how the new lines are being added, I tried playing with STRANS to see if I could understand it better and help more, however, I still do not understand how it works.

I apologize for not being more help, I hoped the experience I had with ABAP and this hex code would be beneficial; apparently I hoped wrong.

Good luck with this, hopefully someone on the boards will see this that knows STRANS better.