This page describes a process of creating a custom function module based data collector, building a custom metric and integrating it into System Monitoring, in case the available standard collectors/metrics do not cover some requirements.
It's divided into three main parts:
First step, is the creation of a function module. ABAP language knowledge as well as experience with function groups and function modules are the necessary prerequisites.
The Inbound parameters are realized as nested tables. One request to the data collector can result in various requests, collected in one table.
Starting point is the table “selopt_para”. It contains all requests. Each request has a call ID, which must be unique for every entry. This call ID must be given to the outbound structs for the responses, so that the system can determinate the response for the corresponding request.
The parameters for each request are in the “selection_parameter” table property. Here you can find all the selection parameter for the specific request. Usually, this table contains at least one mandatory parameter named “KEY_FIGURE”. It specifies the type of the call. This parameter will be required later during data provider and metric creation. It's not mandatory to use exactly the same parameter name.
For each type of request, you can have selection ranges in the property “t_ranges”. These are normal ranges like in any other ABAP program. You can give it directly to your selection or process them according to your collector specification.
There are 2 outbound parameters structs.
The first is the “return_status” table. Here you can append all errors.
First you must give the call ID to the table entry, that the system can determinate the return status for the corresponding request. You get the call ID from the “selopt_para” table entry.
The second value is the status number. <has to be defined>
And the last one is the message text. Here you are free to give back any message you want.
The second one is the “result” table. Here you must append all results, if there is no error.
First you must give the call ID to the table entry, that the system can determinate the result for the corresponding request. You get the call ID from the “selopt_para” table entry.
The second value is the data result. Here you can give alle the results. You can also give all the inbound parameters to the result, so that the system can show also the parameters from the request in the result. That's a common practice, but it's not a must.
The workflow is just simple. First you must loop over the “selopt_para” table and read the “selection_parameter” with the param “KEY_FIGURE”, if you use this keyword, like suggested.
The “KEY_FIGURE” now specializes the request. Now you have to decide which values you would like to read from the system. You can realize this with a switch-case or just with if statements. You are totally free how to get all the values.
But you have to respect also the “t_ranges” which can gives you additional filters for your selects.
After you have collected the data for the actual request you must append the results with the given call ID to the “result” table. In this case, everything went well, you don't have to append an entry to the “return_status” table.
If there is any error, while you process the specific request, you must append an entry to the “return_status” table.
If the specific request, “selopt_para” table entry, is done, you can proceed to the next entry.
To get familiar with import/export parameters and to ensure that the created FM is working as expected, the test function module feature can be used.
| CALL_ID | SELECTION_PARAMETERS
| ||||
|---|---|---|---|---|---|
| PARAM | T_RANGES | ||||
| SIGN | OPTION | LOW | HIGH | ||
| 0 | KEY_FIGURE | I | EQ | RANDOM | |
| RANDOM | I | BT | 0 | 1000 | |
Once a function module is providing an expected result, the creation of a data collector in the Data Collector/Provider Maintenance UI will be the next step. To do this, call the transaction MAI_TOOLS, go to Related Links and click on Data Provider Maintenance.
The data collector has to be created under collector type "RFC (Push)".
The mandatory property keys are:
Recommended approach, is to copy one of the existing data collectors and adjust the properties as well as the required parameters available on the next tab.
On the "Parameters" tab the relevant configuration parameters have to be added, which planned to be used as selection parameters on function module side. In addition to that, there is a set of hidden parameters which are part of every RFC collector definition. Do not delete or change them.
Data Collector example:
| Parameter ID | Parameter Name | Description | Type | Ext. Context | Mandatory | Range | Usage | Predefined Value |
|---|---|---|---|---|---|---|---|---|
| KEY_FIGURE | Key Figure | Key Figure | MSO | X | X | CONFIG | RANDOM | |
| RANGE | Range | Range | MSO | X | X | CONFIG |
Last step is the creation of a custom metric by selecting a previously created data collector and maintaining the required parameters like collection frequency, key figure and threshold values.
As of ST-PI 740 SP 22 there is a dummy standard function module/data collector called “/SDF/E2E_STPI_DP_TEMPLATE”.
It can be used to get familiar with the data collector structure and for tests of custom metrics. You can also simply copy this template collector and adjust it to your needs. It shows you exactly how to handle requests and create the results, also it shows how to handle errors.
Note: This data collector can be used as well in lower ABAP releases but it must be adapted to the ABAP features accordingly.
You can use the corresponding data collector "ABAP Dummy DC" located under data collector type RFC Push to create a custom metric in one of the custom ABAP templates. It contains two key figures: static and random. Via parameter 'Range' it is optionally possible to define own range for random case, else a default range will be used.
Note: In case, it's not appearing in the list of available collectors, please perform a monitoring content update.