Summary
The document shows you a way to fetch the XI monitoring data from the various standard SAP tables. In this I will show a way to fetch the PI monitoring data (accessed via transaction SXMB_MONI) from the various standard tables, save these data in a customizing transparent table and a report that recover the saved data and shows the payload in a HTML viewer control application. It also includes data conversion from XML (payload) to ALV report where user can search data using ALV filters i.e. shows the ability to search based on data from payload in ALV display.
Introduction
Business always cares about a status of the messages flowing through XI. SAP Exchange Infrastructure has been known for many of its dazzling features and one of them is the effective and efficient message tracing facility through the transaction - SXMB_MONI. The transaction provides a detailed tracing information for each and every XI interfaces.
Sometimes it’s necessary to fetch some PI monitoring messages accessed via transaction SXMB_MONI (to show them over a Portal or in another system for example). Here, I will show in few steps how to recover these data, save it in a custom transparent table and a small application that shows these data based on radio button selected whether you want to see a payload message in a HTML viewer control (XML Format) when some line is double clicked or all the data from XML(Payload) file in ALV format which user can filter based on his requirement.
Introducing the Important XI Tables
Here are the key objects for any XI interface in a runtime environment:
- Inbound message Interface
- Outbound message Interface
- Interface namespace
- Sending Business System
- Receiving Business System
- Interface Mapping
- Message Payload
- Message status
The SAP XI stores the monitoring trace data in the multiple tables. Before I go further, I would like to give some overview on the tables which I have used to fetch the basic XI interface monitoring data.
- SXMSPMAST: (Integration Engine: Message Queue (Master)) The table is the master table for the monitoring information. You can get the timestamp, interface status, message id, and many more information.
- SXMSPEMAS: (Integration Engine: Enhanced Message Queue (Master)) The table provides the namespaces, the business systems and message interfaces involved in the interface.
- SXMSMSTATT: (Exchange Infrastructure: Message Status Description) This table provides a message status description.
- SXMSMSTAT: (Exchange Infrastructure: Message Status) This table is helpful if you want to show the process status icon for the corresponding message state.
- SMPPMAP3: (Mapping Runtime: Mapping) The above table gives you the mapping name (if any) used in the interface. It also provides the details on the type of mapping (ABAP mapping, Java mapping, Generated Mapping, XSLT java mapping, XSLT ABAP mapping) used for an interface.
- SMPPREL3: (Mapping Runtime: Mapping Relation) the table gives an interface mapping details for an interface and its corresponding message interface.
Note: For more information consider the following tables:
• SXMSPERROR: XML Message Broker: Message Queue (Incorrect Entries)
• SXMSCLUP: XMB: Property Cluster
• SXMSPVERS: Integration Engine: Message Version
• SXMSAGGRAW: SAP XI Status Overview: Integration Engine Raw Data
• SXMSALERTLOGGER: XI Alert Logs
• SXMSAEADPMODCHN: XI: Adapter Module Chains
• SMPPSPLIT : XI Mapping: Merge and Split
Step 1: Create Transparent Tables/Structure/Table type using SE11
First of all, it’s necessary to create a transparent table to store the monitoring messages and the payload recovered from the standard tables. This transparent table (ZSM_DATA) is composed by the structure that contains the keys for the message (ZSM_KEY) and the structure that contains the data fields (ZSM_OTHER).
Create Structure ZSM_KEY
![1.jpg]()
Create Structure ZSM_OTHER
![2.jpg]()
Create Transparent Table ZSM_DATA.
![3.jpg]()
Create Table Type ZSM_DATA_TAB for Table ZSM_DATA![4.jpg]()
Create Output Structure ZSM_DATA_OUTPUT
![6.jpg]()
Create Transparent table ZSM_FILTER
![7.jpg]()
Create Table Type ZSM_FILTER_TAB using ZSM_FILTER
![9.jpg]()
![8.jpg]()
Step 2: Create Function Module “ZSXMB_MONI_EXTRACT” using SE37
The function is responsible to fetch the data from the standard SAP monitoring tables (including the messages payloads) and export them as a table. I used a remote enabled function module (RFC) because with this option it’s possible to call it from others systems and save the fetched data remotely on the caller systems.
Importing Parameters
The importing parameters are:
I_DATE_FROM The initial execution date;
I_TIME_FROM The initial execution time;
I_DATE_TO The final execution date;
I_TIME_TO The final execution time;
IT_FILTER A filter table based on the ZSM_FILTER structure where is defined the field and the conditions that this field must respect. The field is one or more of the SXI_MSG_SELECT structure and the value is the desired condition. An example of how to fill this table will be showed in the report that’s used to recover the monitoring data.
Exporting Parameters
The exporting parameter is:
ET_DATA The table that contains the message data including its payload. This table is based on the structure ZSM_DATA (which include the structures ZSM_KEY – with the key fields for the messages and ZSM_OTHER – that contains the data.
![11.jpg]()
Exceptions
The exceptions are:
INVALID_DATES The date and time passed as importing parameters are invalids (date and time from greater than the date and time to, for example);
NO_DATA There’s no PI monitoring messages for the conditions passed in the importing parameters.
![12.jpg]()
FM Source code
Function Module Source Code attached with the message in xml format(FM.xml).
Application to Fetch & Show the Fetched Monitoring Messages data
After the creation of the function module it’s necessary to create a way to call it, fetch the data and store these data in a transparent table and display in an ALV table. When you double click one of the monitoring messages displayed it displays the payload related to the message in a HTML viewer control or After selecting multiple or single row on ALV display and clicking the button ‘Payload’ on ALV Output the data from payload is displayed in ALV format.For this will be created a report that calls the function module, shows a small summary of the processing status, store the fetched data in a transparent table, Extract data from payload to display in ALV format.
A. This program is composed of 3 Screens
(Below is the necessary information to create the screen)
- Create one screen that has a container(CC_SXMB) used to shows the initial Display of all the messages as per selection criteria in ALV Format.
- Second Screen that has a container(CC_PL) used to shows HTML viewer control.
- Third Screen that has a container (CC_ALV)used to shows extract form XML (payload) data in ALV format.
![ff.jpg]()
B. GUI Status/GUI Title.
ALV_GUISTATUS
C. Create Selection Screen as below
![24.jpg]()
D. Declaration for all the variables/Internal Tables/Types
Following are the declarations for all the variables/Internal Tables/Types to be used in the code snippets throughout the document. This would help us avoid all the confusion pertaining to the type of variables used.
*----------------------------------------------------------------------
* C O N S T A N T D E C L A R A T I O N
*----------------------------------------------------------------------
CONSTANTS:
BEGIN OF gc_log,
success TYPE symsgty VALUE 'S',
warning TYPE symsgty VALUE 'W',
error TYPE symsgty VALUE 'E',
END OF gc_log,
gc_exit TYPE sy-ucomm VALUE 'EXIT',
gc_canc TYPE sy-ucomm VALUE 'CANC',
gc_back TYPE sy-ucomm VALUE 'BACK',
gc_a TYPE char01 VALUE 'A',
gc_xmld TYPE char04 VALUE 'XMLD'.
*----------------------------------------------------------------------
* T Y P E D E C L A R A T I O N
*----------------------------------------------------------------------*
TYPES :
ty_zsm_key TYPE SORTED TABLE OF zsm_key WITH UNIQUE DEFAULT KEY.
TYPES:
BEGIN OF ty_zsm,
msgguid TYPE zsm_data-msgguid,
pid TYPE zsm_data-pid,
msgstate TYPE zsm_data-msgstate,
exetimest TYPE zsm_data-exetimest,
adminuser TYPE zsm_data-adminuser,
ob_system TYPE zsm_data-ob_system,
ob_ns TYPE zsm_data-ob_ns,
ob_name TYPE zsm_data-ob_name,
ib_system TYPE zsm_data-ib_system,
ib_ns TYPE zsm_data-ib_ns,
ib_name TYPE zsm_data-ib_name,
END OF ty_zsm,
ty_t_zsm TYPE SORTED TABLE OF ty_zsm WITH NON-UNIQUE KEY msgguid pid,
ty_t_output TYPE STANDARD TABLE OF zsm_data_output
WITH NON-UNIQUE KEY msgdate msgtime msgguid pid.
*----------------------------------------------------------------------
* I N T E R N A L T A B L E D E C L A R A T I O N
*----------------------------------------------------------------------*
DATA :
it_payload TYPE zsm_data_tab,
it_zsm_data TYPE ty_t_zsm,
it_output TYPE STANDARD TABLE OF zsm_data_output,
wa_payload TYPE zsm_data,
wa_output TYPE LINE OF ty_t_output.
*----------------------------------------------------------------------
* V A R I A B L E D E C L A R A T I O N
*----------------------------------------------------------------------*
DATA:
gv_error TYPE char01,
gv_log TYPE num5,
gv_ucomm TYPE sy-ucomm,
gv_lines TYPE int4.
*----------------------------------------------------------------------
* A L V D E C L A R A T I O N
*----------------------------------------------------------------------*
* ALV Internal Table Declaration
DATA: it_cellstyle TYPE STANDARD TABLE OF lvc_s_styl,
it_fieldcat TYPE STANDARD TABLE OF lvc_s_fcat,
it_exclude TYPE ui_functions,
it_row_no_top TYPE TABLE OF lvc_s_roid INITIAL SIZE 0,
wa_row_no_top TYPE lvc_s_roid.
* ALV Work Area Declaration
DATA : wa_fieldcat TYPE lvc_s_fcat,
wa_layout TYPE lvc_s_layo,
wa_result TYPE string.
DATA:
gv_layout TYPE disvariant.
*----------------------------------------------------------------------
* X M L To Internal Table Conversion D E C L A R A T I O N
*----------------------------------------------------------------------
* Declaring the table to contain the parsed data
DATA: it_xml_info TYPE STANDARD TABLE OF smum_xmltb.
* Declaring the work area for the internal table containing the parsed data
DATA: wa_xml_info TYPE smum_xmltb.
* Declaring the table to contain the returned messages from the parsing FM
DATA: it_return TYPE STANDARD TABLE OF bapiret2.
* Declaring the work area for the return table
DATA: wa_return TYPE bapiret2.
DATA :
it_fieldcatxml TYPE lvc_t_fcat,
gref_table TYPE REF TO data,
gref_line TYPE REF TO data.
DATA : gv_count TYPE int4.
FIELD-SYMBOLS : <fs_table> TYPE STANDARD TABLE,
<fs_tabletmp> TYPE STANDARD TABLE,
<fs_line> TYPE any,
<fs_t> TYPE any,
<fs_s> TYPE any.
E. Retrieve Data by calling FM ZSXMB_MONI_EXTRACT and passing Selection Screen
parameters.
CONSTANTS:
BEGIN OF lc_field,
field1 TYPE zsm_filter-field VALUE 'SENDER_RECEIVER-OB_NAME',
field2 TYPE zsm_filter-field VALUE 'SENDER_RECEIVER-OB_NS',
field3 TYPE zsm_filter-field VALUE 'SENDER_RECEIVER-IB_NAME',
field4 TYPE zsm_filter-field VALUE 'SENDER_RECEIVER-IB_NS',
END OF lc_field.*
DATA: lit_filter TYPE zsm_filter_tab,
lwa_filter TYPE zsm_filter,
lv_num TYPE num03.*
IF NOT p_infsnm IS INITIAL.
lv_num = lv_num + 1.
lwa_filter-filternum = lv_num.
lwa_filter-field = lc_field-field1.
lwa_filter-value = p_infsnm.
APPEND lwa_filter TO lit_filter.
ENDIF.
IF NOT p_infsns IS INITIAL.
lv_num = lv_num + 1.
lwa_filter-filternum = lv_num.
lwa_filter-field = lc_field-field2.
lwa_filter-value = p_infsns.
APPEND lwa_filter TO lit_filter.
ENDIF.
IF NOT p_infrnm IS INITIAL.
lv_num = lv_num + 1.
lwa_filter-filternum = lv_num.
lwa_filter-field = lc_field-field3.
lwa_filter-value = p_infrnm.
APPEND lwa_filter TO lit_filter.
ENDIF.
IF NOT p_infrns IS INITIAL.
lv_num = lv_num + 1.
lwa_filter-filternum = lv_num.
lwa_filter-field = lc_field-field4.
lwa_filter-value = p_infrns.
APPEND lwa_filter TO lit_filter.
ENDIF.
** Call FM ZSXMB_MONI_EXTRACT for Extracting SXMB_MONI Data.
CALL FUNCTION 'ZSXMB_MONI_EXTRACT'
EXPORTING
i_date_from = p_exedat
i_time_from = p_exetim
i_date_to = p_exe2da
i_time_to = p_exe2ti
it_filter = lit_filter
IMPORTING
et_data = it_payload
EXCEPTIONS
invalid_dates = 1
no_data = 2
OTHERS = 3.
IF sy-subrc = 2.
MESSAGE i007(sabapdocu) DISPLAY LIKE gc_log-error.
ELSE.
SORT it_payload BY msgguid pid.
ENDIF.
F. Update Data to custom table ZSM_DATA from data retrieved in step E
DATA: lit_zsxmb_moni TYPE STANDARD TABLE OF zsm_data WITH NON-UNIQUE DEFAULT KEY,
lwa_zsxmb_moni TYPE zsm_data,
lref_payload TYPE REF TO zsm_data.
LOOP AT it_payload REFERENCE INTO lref_payload.
MOVE-CORRESPONDING lref_payload->* TO lwa_zsxmb_moni.
APPEND lwa_zsxmb_moni TO lit_zsxmb_moni.
ENDLOOP.
IF lit_zsxmb_moni IS NOT INITIAL.
DELETE FROM zsm_data.
MODIFY zsm_data FROM TABLE lit_zsxmb_moni.
ENDIF.
G. Retrieve Data From Custom Table
SELECT msgguid pid msgstate exetimest adminuser ob_system
ob_ns ob_name ib_system ib_ns ib_name
FROM zsm_data INTO TABLE it_zsm_data.
IF it_zsm_data IS INITIAL.
MESSAGE i007(sabapdocu) DISPLAY LIKE gc_log-error.
ENDIF.
H. Process data for ALV Output
DATA:
lref_zsxmb_moni TYPE REF TO ty_zsm,
lwa_output TYPE LINE OF ty_t_output,
lit_sxmsmstat TYPE sxmsmstat_attr_t,
lref_sxmsmstat TYPE REF TO sxmsmstat_attr.
LOOP AT it_zsm_data REFERENCE INTO lref_zsxmb_moni.
CLEAR lwa_output.
lwa_output-msgguid = lref_zsxmb_moni->msgguid.
lwa_output-pid = lref_zsxmb_moni->pid.
lwa_output-ob_system = lref_zsxmb_moni->ob_system.
lwa_output-ob_ns = lref_zsxmb_moni->ob_ns.
lwa_output-ob_name = lref_zsxmb_moni->ob_name.
lwa_output-ib_system = lref_zsxmb_moni->ib_system.
lwa_output-ib_ns = lref_zsxmb_moni->ib_ns.
lwa_output-ib_name = lref_zsxmb_moni->ib_name.
lwa_output-adminuser = lref_zsxmb_moni->adminuser.
CONVERT TIME STAMP lref_zsxmb_moni->exetimest TIME ZONE sy-zonlo
INTO DATE lwa_output-msgdate TIME lwa_output-msgtime.
IF msgstate IS NOT INITIAL
CALL FUNCTION 'SXMB_GET_STATUS_ATTRIBUTES'
EXPORTING
im_langu = sy-langu
im_msgstate = msgstate
im_icon_convert = space
IMPORTING
ex_msgstate_attr = lit_sxmsmstat
EXCEPTIONS
msgstate_not_found = 1
OTHERS = 2.
IF sy-subrc <> 0.
ENDIF.
READ TABLE lit_sxmsmstat INDEX 1 REFERENCE INTO lref_sxmsmstat.
IF lref_sxmsmstat IS NOT INITIAL.
msgstate_icon = lref_sxmsmstat->icon_id.
ENDIF.
ENDIF.
APPEND lwa_output TO it_output.
ENDLOOP.
I. Display Data in ALV on Screen 100 Container using Internal Table based on selection
screen data
![25.jpg]()
J. View Payload in payload viewer on Double Clicking on any line in Step I Output.
CONSTANTS:
lc_type TYPE char50 VALUE 'application',
lc_subtype TYPE char50 VALUE 'octet-stream',
lc_512 TYPE int4 VALUE 512.
DATA:
lv_length TYPE int4,
lv_len TYPE int4,
lv_offset TYPE int4,
lv_len_tmp TYPE int4,
lv_url TYPE char255,
lit_raw_lines TYPE sxmsraw512lines,
lwa_raw_line TYPE LINE OF sxmsraw512lines.
* Creating Objects
IF gref_ccontainerpl IS NOT BOUND.
CREATE OBJECT gref_ccontainerpl
EXPORTING
container_name = 'CC_PL'.
CREATE OBJECT gref_html_viewer
EXPORTING
parent = gref_ccontainerpl
EXCEPTIONS
cntl_error = 1
cntl_install_error = 2
dp_install_error = 3
dp_error = 4.
IF sy-subrc = 0.
cl_gui_cfw=>flush( ).
ENDIF.
ENDIF.
*
**Creating URL for Payload
*
lv_length = xstrlen( wa_payload-payload ).
lv_len = lv_length.
lv_offset = 0.
lv_len_tmp = lv_len.
IF lv_len_tmp > lc_512.
DO.
lwa_raw_line = wa_payload-payload+lv_offset(lc_512).
APPEND lwa_raw_line TO lit_raw_lines.
lv_offset = lv_offset + lc_512.
lv_len_tmp = lv_len_tmp - lc_512.
IF lv_len_tmp < lc_512.
EXIT.
ENDIF.
ENDDO.
ENDIF.
IF lv_len_tmp > 0.
lwa_raw_line = wa_payload-payload+lv_offset(lv_len_tmp).
APPEND lwa_raw_line TO lit_raw_lines.
ENDIF.
gref_html_viewer->load_data(
EXPORTING
type = lc_type
subtype = lc_subtype
size = lv_length
IMPORTING
assigned_url = lv_url
CHANGING
data_table = lit_raw_lines
EXCEPTIONS
dp_invalid_parameter = 1
dp_error_general = 2
OTHERS = 4 ).
IF sy-subrc <> 0.
ENDIF.
gref_html_viewer->show_url( url = lv_url ).
REFRESH: lit_raw_lines.
CLEAR : lv_url,lwa_raw_line,lv_len_tmp,lv_length,lv_len.
After double click one of the messages the payload will be displayed like follows:
K. On Selecting a row or multiple row and clicking Button
or selecting radio Button ![32.jpg]()
XML data is converted to internal table which is displayed in ALV format. Steps to do the same are in Step L
below.
![27.jpg]()
L. Process XML data to dynamic internal table and display in ALV.
**Prepare XML Data
REFRESH it_fieldcatxml[].
CLEAR :gv_count,gv_lines.
DESCRIBE TABLE it_output LINES gv_lines.
LOOP AT it_output INTO wa_output .
READ TABLE it_payload INTO wa_payload WITH KEY
msgguid = wa_output-msgguid
pid = wa_output-pid
BINARY SEARCH.
IF sy-subrc = 0.
a) 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 it_xml_info. It_xml_info is of type SMUM_XMLTB. The structure for SMUM_XMLTB is in the screen-shot below:
![28.jpg]()
The table SMUM_XMLTB has four fields: HIER, TYPE, CNAME and CVALUE. The XML data would be transferred into the four fields.
** This function module is used to parse the XML and get the data in the form of a table
CALL FUNCTION 'SMUM_XML_PARSE'
EXPORTING
xml_input = wa_payload-payload
TABLES
xml_table = it_xml_info
return = it_return
EXCEPTIONS
OTHERS = 0.
*If XML parsing is not successful, return table will contain error messages
READ TABLE it_return INTO wa_return WITH KEY type = 'E'.
IF sy-subrc EQ 0.
MESSAGE 'Error converting the input XML file' TYPE 'E'.
ELSE.
REFRESH it_return.
b) Read the XML table to transfer the data into the required table.
We are acquainted with the fields of table it_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 are creating dyanamic final Internal based on the interface data. The transfer of data from the table it_xml_info to our final table would be done in accordance with the values held by the four fields of the it_xml_info table.
While parsing, the values are assigned to the table it_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 it_xml_info.
i. Values held by the field HIER in XML table
a. 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.
b. ‘Hier’ would hold the value ‘2’ for the fields in the Element node, which is at the second level of hierarchy. In our example Header is at the second level of hierarchy.
c. The value would be ‘3’ for all the Value nodes. Here the value nodes would be NotificationNumber, OrderNumber …etc.
d. Hence, we conclude that the value of ‘Hier’ depends upon the level of hierarchy that particular node holds in the XML file.
ii. Values held by the field TYPE in XML table
a. 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.
iii. Values held by the field CNAME in XML table
a. 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 ‘Header’ and the Cvalue would be blank since Header holds no value.
iv. Values held by the field CVALUE in XML table
a. Cvalue contains the values held by the elements of the various nodes of an XML file.
b. For HIER ‘3’ the Type would be ‘V’, Cname can be ‘NotificationNumber’, ‘OrderNumber’ ….Etc. and the Cvalue would be the values held by these records.
c. Here is a screen-shot of the values contained in the table it_xml_info, considering our example.
![29.jpg]()
Now that we are acquainted with the pattern of values contained in it_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 of final internal table. 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:
IF gv_lines >= 1.
ADD 1 TO gv_count.
wa_fieldcat-col_pos = gv_count.
wa_fieldcat-fieldname = 'MSGGUID'.
wa_fieldcat-scrtext_l = 'Message ID'(h04).
wa_fieldcat-intlen = 255.
APPEND wa_fieldcat TO it_fieldcatxml.
ADD 1 TO gv_count.
wa_fieldcat-col_pos = gv_count.
wa_fieldcat-fieldname = 'MSGDATE'.
wa_fieldcat-scrtext_l = 'Execution Date'(h01).
wa_fieldcat-intlen = 255.
APPEND wa_fieldcat TO it_fieldcatxml.
ADD 1 TO gv_count.
wa_fieldcat-col_pos = gv_count.
wa_fieldcat-fieldname = 'MSGTIME'.
wa_fieldcat-scrtext_l = 'Execution Time'(h02).
wa_fieldcat-intlen = 255.
APPEND wa_fieldcat TO it_fieldcatxml.
ADD 1 TO gv_count.
wa_fieldcat-col_pos = gv_count.
wa_fieldcat-fieldname = 'ADMINUSER'.
wa_fieldcat-scrtext_l = 'User Name'(h03).
wa_fieldcat-intlen = 255.
APPEND wa_fieldcat TO it_fieldcatxml.
LOOP AT it_xml_info INTO wa_xml_info WHERE hier EQ 3.
ADD 1 TO gv_count.
wa_fieldcat-col_pos = gv_count.
wa_fieldcat-fieldname = wa_xml_info-cname.
wa_fieldcat-scrtext_l = wa_xml_info-cname.
wa_fieldcat-intlen = 1024.
APPEND wa_fieldcat TO it_fieldcatxml.
ENDLOOP.
* Create the structure
CALL METHOD cl_alv_table_create=>create_dynamic_table
EXPORTING
it_fieldcatalog = it_fieldcatxml
IMPORTING
ep_table = gref_table
EXCEPTIONS
generate_subpool_dir_full = 1
OTHERS = 2.
IF sy-subrc = 0.
* build the dynamic table.
ASSIGN gref_table->* TO <fs_table>.
IF <fs_table> IS ASSIGNED.
CREATE DATA gref_line LIKE LINE OF <fs_table>.
ASSIGN gref_line->* TO <fs_line>.
ENDIF.
ENDIF.
CLEAR gv_lines.
ENDIF.
SORT it_xml_info BY cname.
LOOP AT it_fieldcatxml INTO wa_fieldcat.
ASSIGN COMPONENT wa_fieldcat-fieldname OF STRUCTURE
<fs_line> TO <fs_t>.
IF sy-subrc = 0.
READ TABLE it_xml_info INTO wa_xml_info WITH KEY cname = wa_fieldcat-fieldname.
IF sy-subrc = 0.
<fs_t> = wa_xml_info-cvalue.
ENDIF.
IF wa_fieldcat-fieldname = 'MSGGUID'.
READ TABLE it_output INTO wa_output WITH KEY
msgguid = wa_payload-msgguid
pid = wa_payload-pid.
IF sy-subrc = 0.
<fs_t> = wa_output-msgguid.
ENDIF.
ELSEIF wa_fieldcat-fieldname = 'MSGDATE'.
READ TABLE it_output INTO wa_output WITH KEY
msgguid = wa_payload-msgguid
pid = wa_payload-pid.
IF sy-subrc = 0.
<fs_t> = wa_output-msgdate.
ENDIF.
ELSEIF wa_fieldcat-fieldname = 'MSGTIME'.
READ TABLE it_output INTO wa_output WITH KEY
msgguid = wa_payload-msgguid
pid = wa_payload-pid.
IF sy-subrc = 0.
<fs_t> = wa_output-msgtime.
ENDIF.
ELSEIF wa_fieldcat-fieldname = 'ADMINUSER'.
READ TABLE it_output INTO wa_output WITH KEY
msgguid = wa_payload-msgguid
pid = wa_payload-pid.
IF sy-subrc = 0.
<fs_t> = wa_output-adminuser.
ENDIF.
ENDIF.
ENDIF.
AT LAST.
APPEND <fs_line> TO <fs_table>.
ENDAT.
ENDLOOP.
REFRESH :it_xml_info.
CLEAR : wa_xml_info,wa_fieldcat,wa_output.
ENDIF.
ENDIF.
CLEAR :wa_output,wa_payload.
REFRESH :it_xml_info.
ENDLOOP.
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 FM SMUM_XML_PARSE over XSLT.
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.
Output Screen for XML data converted to ALV
![30.jpg]()
Complte Source Code
Complete source code is attached with the message in .xml format.(SourceCode.xml)