Community
Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

cl_xml_document and type RAW on Unicode systems?

Former Member

‎2008 Feb 18 3:02 PM

0 Likes
1,093

Cheers guys,

I'm using a cl_xml_document for exporting data from but000 to an XML file. Works fine, except for the PARTNER_GUID which seems to be interpreted as chars (it's raw bytes), eg. the GUID "0E1E1FFCF746D14CADEF2D3EBEAEB21B" becomes "Dh4f/PdG0Uyt7y0+vq6yGw==". This is a very serious prob for us because it also occurs with other fields/tables and makes the whole XML thing pretty much useless.

Is there any known workaround for this?

Thx in advance!

Cheers guys,

I'm using a cl_xml_document for exporting data from but000 to an XML file. Works fine, except for the PARTNER_GUID which seems to be interpreted as chars (it's raw bytes), eg. the GUID "0E1E1FFCF746D14CADEF2D3EBEAEB21B" becomes "Dh4f/PdG0Uyt7y0+vq6yGw==". This is a very serious prob for us because it also occurs with other fields/tables and makes the whole XML thing pretty much useless.

Is there any known workaround for this?

Thx in advance!

Reply
3 REPLIES 3
Read only

Former Member

‎2008 Feb 18 4:33 PM

0 Likes
886

Addition: the root of problem is the form Value_to_string (LSDIXMLF01) where RAW data gets converted to a string - this form is called from the SDIXML_DATA_TO_DOM function. I'd clearly say this is a bug (why would anyone want to apply a hex to string conversion to a GUID?), but I can't find anything about it on the OSS...

Read only

athavanraja
Active Contributor
In response to Former Member

‎2008 Feb 19 10:32 AM

0 Likes
886

i tried to simulate your case and the finding is that if the source field data type is RAW (type BU_PARTNER_GUID) it behaves the way as you had explained.

however if you change the source field type(temporarily store them in a string field) to type string, it retains the format.

check this sample program.


data: l_xml  type ref to cl_xml_document  ,
     if_xml type ref to if_ixml_document ,
     node type ref to if_ixml_node  .
data: myguid type standard table of BU_PARTNER_GUID ,
      wa_guid type BU_PARTNER_GUID .
data: smyguid type standard table of string ,
      swa_guid type string .

data: xml_out type string ,
      xxml_out type xstring .
     wa_guid = '0E1E1FFCF746D14CADEF2D3EBEAEB21B' .
    append wa_guid to myguid .

swa_guid = '0E1E1FFCF746D14CADEF2D3EBEAEB21B' .
    append swa_guid to smyguid .

create object l_xml.
l_xml->set_data(
*    NAME        = 'DATA'
*    ALIAS       = ALIAS
    dataobject  = smyguid
*    PARENT_NODE = PARENT_NODE
*    CONTROL     = CONTROL
       ).


clear xml_out .
l_xml->render_2_xstring(
  EXPORTING
    PRETTY_PRINT = 'X'
  IMPORTING
*    RETCODE      = RETCODE
    STREAM       = xxml_out
*    SIZE         = SIZE
       ).

l_xml->render_2_string(
  EXPORTING
    PRETTY_PRINT = 'X'
  IMPORTING
*    RETCODE      = RETCODE
    STREAM       = xml_out
*    SIZE         = SIZE
       ).

call method l_xml->parse_string
  exporting
    stream = xml_out.
call method l_xml->display.

Read only

Former Member

‎2008 Feb 19 10:39 AM

0 Likes
886

Hi, thx for the code, I'll try it ASAP and it looks like a good workaround. Still, I actually consider this behaviour a bug, but using a workaround is usually more effective than opening a case in SDN...