Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
m_keskin
Advisor
Advisor
2,487
Introduction

This blog post describes the technical background of the SXI_MONITOR Generic Search Framework and explains how to create your own enhanced searches. For more general information on the SXI_MONITOR_GSF please check out Introducing the SXI_MONITOR Generic Search Framework.

The new transaction is available via the following SAP notes:

  • 2971973 - SRT_MONI_GSF Creation of package

  • 3035719 - Generic Search Framework for SXI_MONITOR - Interface Note

  • 3035724 - Generic Search Framework for SXI_MONITOR_GSF - Application Note BP


Content of an XML message

The SXI_MONITOR Generic Search Framework is used to filter XML message based on its content. The following figure shows how an XML message is structured.


Figure 1: Content of a XML Message with Organization Data


An XML message as shown above consists of elements, attributes, their value assignments, and the content of the elements. The fields marked in red in the above example are called "technical names", and the corresponding values marked in green are called "corresponding values".

Technical Background

Before we look at how the extension and enhancement of the SXI_MONITOR Generic Search Framework can be carried out, let's take a closer look at how the algorithm works.


Figure 2: Search Algorithm


The figure above shows the search algorithm in detail. The first step is to filter the XML messages based on the information specified on the user interface and in the constructor of the subclass. The filter consists of various information such as: Date, time, status group or name of the service. The gathered XML messages are then extracted one by one and are filtered by their technical names and the corresponding values. If there is an XML message that fits to the technical names and corresponding values, the message ID is saved. If there is no XML message that not fit to the search parameter, the algorithm ignores the message and goes to the next XML message. All these steps are carried out until all XML messages have been processed. Finally, the XML messages that are found and stored with the message ID are show as a list.

Please be aware that the search can take some time, since the algorithm needs to extract and analyze all messages found after the “Pre-Selection”. It is recommended to narrow down the search criteria as much as possible.

The SXI_MONITOR Generic Search Framework also offers Background Processing as explained in Introducing the SXI_MONITOR Generic Search Framework.

Enhancement of the User Interface

Below you can see the user interface of SXI_MONITOR Generic Search Framework, which can be defined by the user. This includes the two dropdown menus “Search Object” and “Selection Parameter” and the button “Service Selections”.


Figure 3: Enhancement Area of the User Interface


Grouping of technical names

The grouping of the technical names is shown as an example for the “Search Object” Business Partner. In this example the Business Partner has two “Selection Parameters”: ID and Name. Please note that this example is just for demonstration purposes!


Figure 4: Grouping of the Technical Names as an Example for the “Search Object” Business Partner


The “Selection Parameter” ID has three technical names beneath it:

  • ‘PartyID’

  • ‘BusinessPartnerInternalID’

  • RelationshipBusinessPartnerInternalID’

  • The “Selection Parameter” Name has 10 technical names beneath it:

  • ‘Name1’

  • ‘Name2’

  • ‘Name3’

  • ‘Name4’

  • ‘GivenName’

  • ‘SecondName’

  • ‘FamilyName’

  • ‘BirthName’

  • ‘MiddleName’

  • ‘PreferredGivenName’


Please be aware that this example is just to demonstrate that different number of technical names can be assigned to one “Selection Parameter”.

During runtime, the values corresponding to the technical names are compared to the values entered in the field “Value(s)”. It is an select-option field and therefore the input of several values is possible.

Enhancement of the Generic Search Framework

In this part of the blog post we will take a step-by-step look at how to enhance the Generic Search Framework for your own “Search Object”, “Selection Parameter” with corresponding technical names, and “Service Selection”. We tried to make this as user-friendly as possible. The most important prerequisite is that you have imported and implemented at least the mandatory SAP notes mentioned in chapter introduction. This example will create a demo class.

Step 1:

Create a new subclass of CL_SXI_MONITOR_GSF and save it.


Figure 5: Creation of a Demo Class as Subclass of CL_SXI_MONITOR_GSF


Step 2:

Define and implement the constructor of this class by clicking on Constructor.


Figure 6: Definition of the Constructor


Step 3:

In the constructor, maintain the following attributes:

  • IF_SXI_MONITOR_GSF~IDENTIFIER, which defines the name of the “Search Object”



Figure 7: Enhanced Search Object Dropdown




  • IF_SXI_MONITOR_GSF~TECHNICALSEARCHCRITERIA, which defines the name of the “Selection Parameter” and the corresponding technical names



Figure 8: Enhanced Selection Parameter Dropdown


For the correct filling of “Selection Parameter” you can use the method IF_SXI_MONITOR_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC( ). To do so, call the method with the following parameters:

  • Importing Parameter: IV_SELECTION_IDENTIFIER, which specifies the names of the selection identifier

  • Changing Parameter: CT_SEARCH_PARAMETERS, which specifies the names of the technical names


The function must be called once for every entry in the selection parameter dropdown. So, to produce the dropdown as shown in Figure, you must call the method three times

Step 4 (optional):

An optional enhancement can still be added, which can narrow down the search criteria. This is the “Service Selection”, which is also added in the constructor. To do this, the following steps should be carried out:

  • IF_SXI_MONITOR_GSF~SENDERNAMESINGLE, which specifies a single interface sender name (e.g. wildcard ‘*BusinessPartner*’).

  • IF_SXI_MONITOR_GSF~SENDERNAMETABLE, which specifies multiple interface sender names. If this table filled, it is used by default.

  • IF_SXI_MONITOR_GSF~RECEIVERNAMESINGLE, which specifies a single interface receiver name.

  • IF_SXI_MONITOR_GSF~RECEIVERNAMETABLE, which specifies multiple interface receiver names. If this table filled, it is used by default.



Figure 9: Enhanced Service Selection Pop Up


You can find the complete constructor of our example class DEMO below:
METHOD constructor.
DATA: lt_tecsearch_param TYPE if_sxi_monitor_gsf~tt_sxi_monitor_gsf_tec_params,
ls_sendernametable TYPE if_sxi_monitor_gsf~st_sxi_monitor_gsf_services,
ls_receivernametable TYPE if_sxi_monitor_gsf~st_sxi_monitor_gsf_services.


super->constructor( ).

* Fill value for own name - used in first dropdown
if_sxi_monitor_gsf~identifier = 'DEMO'.

* Fill value for object specific search values which are checked in the XMLs and group them if necessary

APPEND 'DEMOTechnicalName1' TO lt_tecsearch_param.
APPEND 'DEMOTechnicalName2' TO lt_tecsearch_param.

if_sxi_monitor_gsf~provide_tecselcrit_to_construc(
EXPORTING
iv_selection_identifier = 'DEMOSelectionParameter1'
CHANGING
ct_search_parameters = lt_tecsearch_param ).

APPEND 'DEMOTechnicalName3' TO lt_tecsearch_param.
APPEND 'DEMOTechnicalName4' TO lt_tecsearch_param.
APPEND 'DEMOTechnicalName5' TO lt_tecsearch_param.
APPEND 'DEMOTechnicalName6' TO lt_tecsearch_param.

if_sxi_monitor_gsf~provide_tecselcrit_to_construc(
EXPORTING
iv_selection_identifier = 'DEMOSelectionParameter2'
CHANGING
ct_search_parameters = lt_tecsearch_param ).

if_sxi_monitor_gsf~provide_tecselcrit_to_construc(
EXPORTING
iv_selection_identifier = 'DEMOSelectionParameter3'
CHANGING
ct_search_parameters = lt_tecsearch_param ).

* Fill filter on sender webservice name
* Logic is: If table filter is set, use ONLY these services. If not and single is set, use this one.
* If both are not set, display all
* Using single value only will increase the performance

if_sxi_monitor_gsf~sendernamesingle = 'DEMOSenderService*'.
if_sxi_monitor_gsf~receivernamesingle = 'DEMOReceiverService*'.

ls_sendernametable-name = 'DEMOService1'.
ls_sendernametable-selected = abap_true.

APPEND ls_sendernametable TO if_sxi_monitor_gsf~sendernametable.

ls_sendernametable-name = 'DEMOService2'.
APPEND ls_sendernametable TO if_sxi_monitor_gsf~sendernametable.

ls_sendernametable-name = 'DEMOService3'.
APPEND ls_sendernametable TO if_sxi_monitor_gsf~sendernametable.

ls_receivernametable-name = 'DEMOReceiverService4'.
ls_receivernametable-selected = abap_true.

APPEND ls_receivernametable TO if_sxi_monitor_gsf~receivernametable.

ls_receivernametable-name = 'DEMOReceiverService5'.
APPEND ls_receivernametable TO if_sxi_monitor_gsf~receivernametable.

ls_receivernametable-name = 'DEMOReceiverService6'.
APPEND ls_receivernametable TO if_sxi_monitor_gsf~receivernametable.
ENDMETHOD.

Explanation:

First, two data elements are declared that are necessary for the technical search criteria and for the service selection. Then the constructor of the superclass is called. The next step is to define the name of the search object, in this case the search object has the name DEMO. There are two method calls that are responsible for filling the selection parameters. The associated technical names were added to the table LT_TECSEARCH_PARAM with the APPEND command. In the lower part of the coding you can optionally specify the service selections. With IF_SXI_MONITOR_GSF~SENDERNAMESINGLE and/or IF_SXI_MONITOR_GSF~RECEIVERNAMESINGLE you can define a service. With IF_SXI_MONITOR_GSF~SENDERNAMETABLE and/or IF_SXI_MONITOR_GSF~RECEIVERNAMETABLE you have the possibility to create several services. Besides enhancing the UI and the search criteria in the constructor, you can also implement your own authorization and plausibility checks. To implement a customized authorization or plausibility check, the methods IF_SXI_MONITOR_GSF~AUTHORIZATION_CHECK and IF_SXI_MONITOR_GSF~OBJECT_PLAUSIBILITY_CHECK need to be redefined inside the Object Class.

Conclusion

In this blog post I have given you an overview of how you can expand SXI_MONITOR Generic Search Framework using self-defined search objects. You also saw briefly how the algorithm of the Generic Search Framework works. I hope that the SXI_MONITOR GSF can help you with working with XML messages.

In case an error occurs please raise an incident on application component LO-MD-BP-WS.

We have taken all measures possible to make this post as accurate as possible, but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know.

The above given dates and times might change without notice and/or reflection in this blog post. For latest accurate dates and times, please check out the referenced, and non-referenced information available from SAP.
2 Comments

great blog and nice feature!  thanks! 

but,  why does IF_SXI_MONITOR_GSF only have SENDERNAMETABLE but no table for specifying Inbound (receiver) interfaces when building a custom class?

 

former_member229976
Active Participant
0 Kudos
SAP notes 3090934 and 3091114 should solve that ...