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.

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.

Here are the key objects for any XI interface in a runtime environment:

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.

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

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

Create Structure ZSM_OTHER

Create Transparent Table ZSM_DATA.

Create Table Type ZSM_DATA_TAB for Table ZSM_DATA

Create Output Structure ZSM_DATA_OUTPUT

Create Transparent table  ZSM_FILTER

Create Table Type ZSM_FILTER_TAB using ZSM_FILTER

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.

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.

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.

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.

Function Module Source Code attached with the message in xml format(FM.xml).

 

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.

                          (Below is the necessary information to create the screen)

              ALV_GUISTATUS

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 T