Guide towards a simple conversion of an XML file to ABAP Internal table, using XML parsing


5.     Parsing the x string in order to convert the data into an XML table.

In case we have an XML string that needs to be converted into an object, then the XML string needs to be parsed. The parsing would convert the string into a table. The internal table that would be returned is g_t_xml_info. G_t_xml_info is of type SMUM_XML_TB. The structure for SMUM_XML_TB is in the screen-shot below:

The table SMUM_XML_TB has four fields: HIER, TYPE, CNAME and CVALUE. The XML data would be transferred into the four fields.

 Moving forward, we would come to know that how exactly is the data allocated to the fields of this table.


* This function module is used to parse the XML and get the

* data in the form of a table



     xml_input = g_xmldata


     xml_table = g_t_xml_info

     return    = g_t_return


      OTHERS    = 0.

*"If XML parsing is not successful, return table will contain error messages

  READ TABLE g_t_return INTO wa_return WITH KEY type = 'E'.

  IF sy-subrc EQ 0.

    MESSAGE ‘Error converting the input XML file’ TYPE ‘E’.


    REFRESH g_t_return.


6.     Read the XML table to transfer the data into the required table.

We are acquainted with the fields of table g_t_xml_info HIER, TYPE, CNAME and CVALUE.

We now, need to move the data from this table into the required, final table. For instance in the scenario we have been considering, the final table would consist of the three fields HomePernr, UNAME and USERID. The transfer of data from the table g_t_xml_info to our final table would be done in accordance with the values held by the four fields of the g_t_xml_info table.

While parsing, the values are assigned to the table g_t_xml_info. The values are moved depending upon the node being converted to the table.

Let me elaborate about the values held by the table g_t_xml_info.

1.     Values held by the field HIER in XML table

The field ‘Hier’ would hold the value ‘1’ for the element in the root node. Since, Root node is the first level of the XML hierarchy.

‘Hier’ would hold the value ‘2’ for the fields in the Element node, which is at the second level of hierarchy. In our example EmployeeRequests is at the second level of hierarchy.

It would hold ‘3’ for Element nodes at the third level of hierarchy in the XML file that is EmployeeRequest here.

The value would be ‘4’ for all the Value nodes.  Here the value nodes would be HomePernr, UNAME and USERID.

Hence, we conclude that the value of ‘Hier’ depends upon the level of hierarchy that particular node holds in the XML file.

2.     Values held by the field TYPE in XML table

The value that the field ‘Type’ holds for all the elements in the Header of the XML file would be ‘A’. It would be ‘V’ for the value nodes. For all the other nodes, it would hold a blank.

3.     Values held by the field CNAME in XML table

Cname contains the names of the nodes. Hence, considering our example here, if the Hier is ‘2’ the Type would be blank the Cname would be ‘EmployeeRequests’ and the Cvalue would be blank since EmployeeRequests holds no value.

4.     Values held by the field CVALUE in XML table

Cvalue contains the values held by the elements of the various nodes of an XML file.  Taking an example of our case here-

For HIER ‘4’ the Type would be ‘V’, Cname can be ‘HomePernr’, ‘UNAME’ or ‘USERID’ and the Cvalue would be the values held by these records.

Here is a screen-shot of the values contained in the table g_t_xml_info, considering our example.

Now that we are acquainted with the pattern of values contained in g_t_xml_info, we can move these values to the required structure.

We require only the values contained in the value nodes and we have to transfer these to their respective fields i.e. HomePernr, UNAME and USERID. Since, we need the values only for the value nodes we can directly move the values in the final table for a value of HIER equal to ‘3’.

Note: The value of HIER for which we need the data, can be manipulated in accordance with the position of the value nodes in the hierarchy of XML.

We use the following code snippet to move the data:



* Moving the data from the g_t_xml_info table to the required table  

IF NOT g_t_xml_info IS INITIAL.  

  LOOP AT g_t_xml_info INTO    g_s_xml_info WHERE hier EQ 3.  

      tabix = sy-tabix + 1.

      READ TABLE g_t_xml_info INTO g_s_xml_info INDEX tabix.

      g_s_employeerequest-homepernr = g_s_xml_info-cvalue.

      tabix = tabix + 1.

      READ TABLE g_t_xml_info INTO g_s_xml_info INDEX tabix.

      g_s_employeerequest-Uname = g_s_xml_info-cvalue.

      tabix = tabix + 1.

      READ TABLE g_t_xml_info INTO g_s_xml_info INDEX tabix.

      g_s_employeerequest-Userid = g_s_xml_info-cvalue.

      APPEND g_s_employeerequest TO g_t_employeerequest.



Here, the value ‘3’ for the field ‘Hier’ marks the beginning of a new record. Hence, we move the values to the g_t_employeerequest table whenever the value for ‘Hier’ is ‘3’.

This way we get the required values in the internal table g_t_employeerequest.

Thus, we get the values in our desired structure. We populated the final table in accordance with the location

This marks the end of our journey from the XML residing in the application server to the internal table in SAP ABAP.

Advantages/Disadvantages of using the method SMUM_XML_PARSE over XSLT (call transformation id)

1.     As apparent from the description of the entire process, the Function Module SMUM_XML_PARSE is beyond question an undemanding approach towards the XML-ABAP conversion.  SMUM_XML_PARSE is an uncomplicated, unreleased, effortless and undocumented version of the powerful, released and documented iXML.

2.     This function module can be used for complex XML structures by deciding upon suitable ways to segregate the data from the XML table in to the required internal table. This is entirely in our hands since; we are the ones to decide upon the structure of the final internal table required and to decide upon the HIER values of the XML table for which we need the data in the required table..

3.     To turn the XML into an internal table or any other series of ABAP objects we can make use of ABAP’s CALL TRANSFORMATION keyword. Though, this unlike SMUM_XML_PARSE is very well documented in the help documentations and makes use of a XSLT template to transform XML into ABAP objects and vice versa. However, while making use of CALL TRANSFORMATION we need to create the XML schema or the XSLT program in the transaction SE80 which has to be in a definite format, failing which there can be a number of anomalies. Besides, this is a time consuming process. This adds to the complexity quotient of the CALL TRANSFORMATION method.

4.     Quite often, a peculiar problem that occurs while reading the xml file using the CALL TRANSFORMATION method is- 'format not compatible with the internal table'.  Hence, in order to get rid of this particular issue we further need to apply another transformation to convert the data from the internal table into the xml file. Then only, do we get the format of XML which might be utilized for conversion and is compatible with the given internal table. 

Please send us your feedback/suggestions at webmaster@SAPTechnical.COM 

HomeContribute About Us Privacy Terms Of Use • Disclaimer • SafeCompanies: Advertise on SAPTechnical.COM | Post JobContact Us  

Graphic Design by Round the Bend Wizards

footer image footer image