Introduction:
This blog post describes the technical background of the SRT_MONI Generic Search Framework (GSF) and explains how to create your own enhanced searches. For more general information on the SRT_MONI GSF please check out Introducing the SRT_MONI Generic Search Framework.
The transaction is accessible via these SAP notes:
2971973 - SRT_MONI_GSF Creation of package (mandatory)
2972601 - SRT_MONI_GSF Interface Note (mandatory)
2972602 - SRT_MONI_GSF Application Note Business Partner (optional)
2980590 - SRT_MONI_GSF Application Note T100 Messages (optional)
3000261 - Documentation for Report "Web Service Utilities: Generic Search Framework" (optional)
New functionality:
3101750 - The SRT_MONI Generic Search Framework does not offer the sender name of the service as filter criteria
Content of a WS message
The SRT_MONI GSF is used to filter Webservice (WS) messages based on it's content. So let's start by taking a look at how this content is structured (Figure 1) :
A WS message usually is structured very simple, since it just consists of a column called NAME, and a column called VALUE. We will call the values inside the NAME column “technical names” and the values from the VALUE column the “corresponding values”.
Technical Background
Before handing out a step-by-step guide on how to create own enhanced searches it is useful to know how the algorithm works.
In Figure 2, the search algorithm is shown in detail. At first, the messages are selected based on the information extracted from the UI and the constructor of the specific subclass (e.g. time, date, processing status group, webservice name). The gathered messages are then extracted one by one and are filtered by their technical names and the corresponding values. If the search is successful, the message ID is saved, and the next message is analyzed until all messages have been browsed. If either the technical names or the corresponding values do not fit to the search parameters, the algorithm ignores the message, returns, and goes to the next message. After all messages have been analyzed, the saved message IDs are used to show a list of all found messages.
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” (the uppermost box in figure 2). It is recommended to narrow down the search criteria as much as possible.
The SRT Moni Generic Search Framework also offers Background Processing as explained in Introducing the SRT_MONI Generic Search Framework
Figure 3 shows you the area of the UI that can be defined by the user. This includes the two dropdown menus "Search Object" and "Selection Parameter" and the button "Service Selections".
The dropdown menus are used to combine the technical names in logical units. You can find a further explanation to this concept in chapter Grouping of technical names. The button offers the possibility to select from a customized list of webservices. This is further described in chapter Enhancement of the GSF.
Grouping of technical names
The grouping of the technical names is shown in Figure 7 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 two technical names beneath it:
The “Selection Parameter” Name has five technical names beneath it:
Please be aware that this example is just to demonstrate that different quantities (with no limit) 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, when you extend the field.
Enhancement of the GSF
But enough with the background information. Lets have a look at how you can create and implement your own searches. In this chapter you can find a step-by-step guide on how to enhance the GSF to use 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.
Create a new subclass of CL_SRT_MONI_GSF and press Save.
Define and implement the constructor of this class by clicking on Constructor.
In the constructor, maintain the following attributes:
You can use method IF_SRT_MONI_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC( ) to assist with the correct filling of the IF_SRT_MONI_GSF~TECHNICALSEARCHCRITERIA. To do so, call the method with the following parameters:
The constructor is already complete. After saving and activation the class is already usable. However, you can narrow down the search criteria further. This might be useful for certain Webservices. In the constructor, you can maintain optional attributes as shown below:
In this example both IF_SRT_MONI_GSF~RECEIVERNAMESINGLE and IF_SRT_MONI_GSF~RECEIVERNAMETABLE are filled, so the programs logic will only show the values specified inside IF_SRT_MONI_GSF~RECEIVERNAMETABLE.
With SAP Note 3101750 also the sender interface name is introduced. The purpose and usage is analogues to the receiver interface name (e.g. instead of receivernametable use sendernametable). You can find the complete constructor of our example class DEMO below:
Explanation: At first two attributes are declared. Afterwards, the constructor of the superclass is called. Then the name of the “Search Object” is defined, in this case, the name is ‘DEMO’. The dropdown menu “Selection Parameter” is filled by the two method calls. The table LT_TECSEARCH_PARAM is holding the technical names. In this example, the table was filled using an APPEND statement. Inside the method call IF_SRT_MONI_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC this table gets cleared, so it can be reused for the second method call. You can append an unlimited number of technical names to this table. In this state, the constructor will already be working. However, you can optionally fill in the receiver names as demonstrated in the code snippet. Note that there would be no need to fill the “receivernamesingle” here, because the “receivernametable” is filled automatically. By specifying
the Webservice appended to the "receivernametable" will be set to selected by default when starting the transaction.
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_SRT_MONI_GSF~AUTHORIZATION_CHECK and IF_SRT_MONI_GSF~OBJECT_PLAUSIBILITY_CHECK need to be redefined inside the Object Class.
Conclusion
In this blog post, an overview of how to extend the SRT_MONI GSF by customized searches was given. In addition, you learned about the search algorithm that is used by the framework. I hope that the SRT_MONI GSF will assist you when working with ABAP Web Service 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 SRT_MONI Generic Search Framework (GSF) and explains how to create your own enhanced searches. For more general information on the SRT_MONI GSF please check out Introducing the SRT_MONI Generic Search Framework.
The transaction is accessible via these SAP notes:
2971973 - SRT_MONI_GSF Creation of package (mandatory)
2972601 - SRT_MONI_GSF Interface Note (mandatory)
2972602 - SRT_MONI_GSF Application Note Business Partner (optional)
2980590 - SRT_MONI_GSF Application Note T100 Messages (optional)
3000261 - Documentation for Report "Web Service Utilities: Generic Search Framework" (optional)
New functionality:
3101750 - The SRT_MONI Generic Search Framework does not offer the sender name of the service as filter criteria
Content of a WS message
The SRT_MONI GSF is used to filter Webservice (WS) messages based on it's content. So let's start by taking a look at how this content is structured (Figure 1) :
Figure 1 – Content of a WS Message
A WS message usually is structured very simple, since it just consists of a column called NAME, and a column called VALUE. We will call the values inside the NAME column “technical names” and the values from the VALUE column the “corresponding values”.
Technical Background
Before handing out a step-by-step guide on how to create own enhanced searches it is useful to know how the algorithm works.
Figure 2 – Search Algorithm
In Figure 2, the search algorithm is shown in detail. At first, the messages are selected based on the information extracted from the UI and the constructor of the specific subclass (e.g. time, date, processing status group, webservice name). The gathered messages are then extracted one by one and are filtered by their technical names and the corresponding values. If the search is successful, the message ID is saved, and the next message is analyzed until all messages have been browsed. If either the technical names or the corresponding values do not fit to the search parameters, the algorithm ignores the message, returns, and goes to the next message. After all messages have been analyzed, the saved message IDs are used to show a list of all found messages.
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” (the uppermost box in figure 2). It is recommended to narrow down the search criteria as much as possible.
The SRT Moni Generic Search Framework also offers Background Processing as explained in Introducing the SRT_MONI Generic Search Framework
Figure 3 shows you the area of the UI that 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 UI
The dropdown menus are used to combine the technical names in logical units. You can find a further explanation to this concept in chapter Grouping of technical names. The button offers the possibility to select from a customized list of webservices. This is further described in chapter Enhancement of the GSF.
Grouping of technical names
The grouping of the technical names is shown in Figure 7 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 two technical names beneath it:
- ‘----InternalID’
- ‘----ReceiverInternalID’
The “Selection Parameter” Name has five technical names beneath it:
- ‘-------GivenName’
- ‘-------MiddleName’
- ‘-------FamilyName’
- ‘-------AdditionalFamilyName’
- ‘-------BirthName’
Please be aware that this example is just to demonstrate that different quantities (with no limit) 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, when you extend the field.
Enhancement of the GSF
But enough with the background information. Lets have a look at how you can create and implement your own searches. In this chapter you can find a step-by-step guide on how to enhance the GSF to use 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_SRT_MONI_GSF and press Save.
Figure 5 - Creation of a Demo Class as Subclass of CL_SRT_MONI_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_SRT_MONI_GSF~IDENTIFIER TYPE STRING
- Defines the name of the “Search Object" in this case DEMO
Figure 7 - Enhanced Search Object Dropdown
- IF_SRT_MONI_GSF~TECHNICALSEARCHCRITERIA TYPE TT_SRT_MONI_GSF_SEL_IDENT
- Defines the name of the “Selection Parameter” and the corresponding technical names
Figure 8 - Enhanced Selection Parameter Dropdown
You can use method IF_SRT_MONI_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC( ) to assist with the correct filling of the IF_SRT_MONI_GSF~TECHNICALSEARCHCRITERIA. To do so, call the method with the following parameters:
- Importing Parameter: IV_SELECTION_IDENTIFIER TYPE STRING
- Specifies the name of the selection identifier
- Changing Parameter: CT_SEARCH_PARAMETERS TYPE TT_SRT_MONI_TEC_PARAMS
- Specifies the names of the technical names
- TYPE TABLE OF STRING
- The function must be called once for every entry in the selection parameter dropdown. So, in order to produce the dropdown as shown in Figure 8, you must call the method two times.
Step 4 (optional)
The constructor is already complete. After saving and activation the class is already usable. However, you can narrow down the search criteria further. This might be useful for certain Webservices. In the constructor, you can maintain optional attributes as shown below:
- IF_SRT_MONI_GSF~RECEIVERNAMESINGLE TYPE STRING
- Specifies a single interface receiver name (e.g. wildcard ‘BusinessPartner*’)
- IF_SRT_MONI_GSF~RECEIVERNAMETABLE TYPE IF_SRT_MONI_GSF~TT_SRT_MONI_GSF_SERVICE
- Specifies multiple interface receiver names
- If this table is filled, it is used by default. If the table is not filled, the value from IF_SRT_MONI_GSF~RECEIVERNAMESINGLE is used
- Table Type TT_SRT_MONI_GSF_SERVICES
In this example both IF_SRT_MONI_GSF~RECEIVERNAMESINGLE and IF_SRT_MONI_GSF~RECEIVERNAMETABLE are filled, so the programs logic will only show the values specified inside IF_SRT_MONI_GSF~RECEIVERNAMETABLE.
Figure 9 - Enhanced Service Selection Pop Up
With SAP Note 3101750 also the sender interface name is introduced. The purpose and usage is analogues to the receiver interface name (e.g. instead of receivernametable use sendernametable). You can find the complete constructor of our example class DEMO below:
METHOD constructor.
DATA: lt_tecsearch_param TYPE if_srt_moni_gsf~tt_srt_moni_gsf_tec_params,
ls_receivernametable TYPE if_srt_moni_gsf~st_srt_moni_gsf_services.
super->constructor( ).
* Fill value for own name - used in first dropdown
if_srt_moni_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_srt_moni_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_srt_moni_gsf~provide_tecselcrit_to_construc(
EXPORTING
iv_selection_identifier = 'DEMOSelectionParameter2'
CHANGING
ct_search_parameters = lt_tecsearch_param ).
* Fill filter on receiver 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_srt_moni_gsf~receivernamesingle = 'DEMOWebService*'.
ls_receivernametable-name = 'DEMOWebService1'.
ls_receivernametable-selected = abap_true.
APPEND ls_receivernametable TO if_srt_moni_gsf~receivernametable.
ls_receivernametable-name = 'DEMOWebService2'.
APPEND ls_receivernametable TO if_srt_moni_gsf~receivernametable.
ENDMETHOD.Explanation: At first two attributes are declared. Afterwards, the constructor of the superclass is called. Then the name of the “Search Object” is defined, in this case, the name is ‘DEMO’. The dropdown menu “Selection Parameter” is filled by the two method calls. The table LT_TECSEARCH_PARAM is holding the technical names. In this example, the table was filled using an APPEND statement. Inside the method call IF_SRT_MONI_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC this table gets cleared, so it can be reused for the second method call. You can append an unlimited number of technical names to this table. In this state, the constructor will already be working. However, you can optionally fill in the receiver names as demonstrated in the code snippet. Note that there would be no need to fill the “receivernamesingle” here, because the “receivernametable” is filled automatically. By specifying
ls_receivernametable-selected = abap_true.the Webservice appended to the "receivernametable" will be set to selected by default when starting the transaction.
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_SRT_MONI_GSF~AUTHORIZATION_CHECK and IF_SRT_MONI_GSF~OBJECT_PLAUSIBILITY_CHECK need to be redefined inside the Object Class.
Conclusion
In this blog post, an overview of how to extend the SRT_MONI GSF by customized searches was given. In addition, you learned about the search algorithm that is used by the framework. I hope that the SRT_MONI GSF will assist you when working with ABAP Web Service 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:
3 Comments
| User | Count |
|---|---|
| 15 | |
| 13 | |
| 11 | |
| 11 | |
| 11 | |
| 11 | |
| 10 | |
| 9 | |
| 9 | |
| 6 |
