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:
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.
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.
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”.
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!
The “Selection Parameter” ID has three technical names beneath it:
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.
Step 2:
Define and implement the constructor of this class by clicking on Constructor.
Step 3:
In the constructor, maintain the following attributes:
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:
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:
You can find the complete constructor of our example class DEMO below:
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.
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.
- SAP Managed Tags:
2 Comments
