The
Generic Request and
Message Generator (GRMG) is a SAP NetWeaver technology for monitoring the
availability of SAP and non-SAP web sites. This problem analysis scenario
(PAS) explains how to analyze the failure of a GRMG monitoring scenario to run
successfully.
In general, errors in GRMG itself are not at fault when a GRMG monitoring scenario does not run correctly. Rather, configuration errors, problems in the dispatching of CCMS Monitoring Infrastructure data supplier methods, or connectivity problems with web servers are at fault.
●
In the central
monitoring system, where GRMG runs, in transaction GRMG the Run Status column contains a
icon (red cross) or a
icon (gray cross) or is empty.
● In the Alert Monitor of the central monitoring system (transaction RZ20), monitoring collection SAP CCMS Monitor Templates, monitor Availability and Performance Overview, the GRMG-Tested Availability (Web Components) subtree or particular scenario subtrees therein have one of the following characteristics:
○ There are no subtrees under GRMG-Tested Availability
○ Subtrees for particular GRMG scenarios are present but are white (inactive)

○ Subtrees are present and red, but in the GRMG monitoring subtree only the Self-Monitoring: Scenario <scenario name> subtree has been created, or only the Self-Monitoring subtree is actively receiving data (other portions of the monitoring tree are green or white).

|
Scenario Type: |
Error analysis |
|
NetWeaver Component: |
SAPWeb AS ABAP |
|
Valid for: |
SAP NetWeaver 04 as of SP Stack 12 However, most of the analytic tools and procedures can also be used to analyze problems in GRMG in SAP Web AS Release 6.20 as well. |
● Transaction GRMG
● CCMS Alert Monitor (transaktion RZ20)
The GRMG scenario has not yet been run or no subtree for the scenario has been created. Most likely the scenario has not yet been run the first time or some problem in the CCMS Monitoring Infrastructure is preventing the correct execution of the GRMG scenario.
...
1.
Try starting the
scenario in transaction GRMG. Mark the scenario and then choose
Start. If the scenario Run Status changes to
(green check), then the scenario ran
successfully. Let the scenario run for at least 10 minutes to make sure it
stays in that status. If so, you are done with the problem analysis.
2.
If the Run Status field for the scenario remains
empty, then there is most likely a problem in the CCMS Monitoring
Infrastructure itself, such as inadequate space in shared memory. Look for
errors in the
CCMS Selfmonitoring
Monitor for Instance-Specific Data and in the
CCMS Selfmonitoring
Monitor for System-Wide Data.
3.
Check for error
messages from GRMG: In the central monitoring system, start transaction RZ20,
open monitor collection SAP CCMS Technical Expert
Monitors, monitor CCMS Selfmonitoring. Find
the MoniInfra subtree of the application server at
which you just started the GRMG monitoring scenario. Open the MoniInfra subtree to reach the DataSupplier ® Log
log attribute. Mark the
attribute and select
(Display Details)
in the tool bar to display messages in the log. You can have more messages
displayed by changing the properties of the Log
MTE. You can also change to the Open Alerts view to
see if there are relevant alerts in the MoniInfra subtree as a whole.
Correct the problem in the Monitoring Infrastructure so that GRMG can run correctly.
The GRMG scenario in question has been run in the past but has stopped executing and has become inactive. This situation may be caused by a configuration problem in the GRMG monitoring scenario, by a problem in running GRMG, or by problems in running data supplier methods in the CCMS Monitoring Infrastructure.
...
1.
Try starting the
scenario in transaction GRMG. Mark the scenario and then choose
Start. If the scenario Run Status changes to
(green check), then the scenario ran
successfully. Let the scenario run for at least 10 minutes to make sure it
stays in that status. If so, you are done with the problem analysis.
2. If the Run Status field for the scenario remains gray, then you will need to determine where the error lies.
3. Does the error lie in the execution of GRMG scenarios?
a. Start transaction RZ20 and open monitor collection SAP CCMS Monitor Templates, monitor Availability and Performance Overview. Open GRMG-Tested Availability and the complete Self-Monitoring Scenario: subtree of the relevant GRMG Scenario.
b. Choose Views ® Data supplier status.
c. Check the data supplier status information of the self-monitoring MTEs for a red FATAL_ERROR status. If found, note the time and date of the fatal error. This status indicates that the GRMG data supplier did not execute correctly. It either ran so long that it timed out or it ended with an ABAP short dump.
d.
If no FATAL_ERROR was found, then check for the RUN_REQUIRED status. If found, this status indicates that there
is a problem with the dispatching of data suppliers in the CCMS Monitoring
Infrastructure. A READY status also
suggests a dispatching problem; in both cases you should look for errors in
the
CCMS
Selfmonitoring Monitor for Instance-Specific Data and in the
CCMS Selfmonitoring
Monitor for System-Wide Data.
e. If a FATAL_ERROR was found, then switch to transaction ST22 and search for a short dump at the time and date indicated in the FATAL_ERROR notice. Correct the problem that caused the short dump.
4. Does the error lie in GRMG scenario configuration?
a. Compare transaction GRMG and transaction RZ20. Is there in transaction GRMG a scenario definition that matches in the GRMG description the name of the scenario subtree in RZ20? If not, then the scenario definition has been deleted without successful deletion of the matching RZ20 monitoring tree.
b. Compare transaction GRMG and transaction RZ20. Is there in transaction GRMG only one scenario definition with the name of the scenario subtree in RZ20? Can you attest to the fact that no other scenario definition with the same scenario description has existed, and has perhaps been recently deleted?
Configuration
errors such as these result in errors in the CCMS Monitoring Infrastructure
and inactivation of the monitoring subtrees of the affected GRMG scenarios.
Correct the scenario configuration in transaction GRMG, then delete the
affected monitoring trees using option 4 (see
Deleting and Restoring
Nodes in the Alert Monitoring Tree), and restart the scenarios in
transaction GRMG.
Affected GRMG scenarios are being dispatched correctly by the CCMS Monitoring Infrastructure. However, GRMG is not able to run the scenarios successfully. In GRMG Classic mode (for SAP software components), GRMG is not able to exchange data successfully with the GRMG application at the web server.
Note that in GRMG
Lite scenarios (see
Monitoring Web Pages
with GRMG Lite), you will usually not see the status
(red
cross). This is because GRMG Lite does not require the return of a valid GRMG
XML response in order to interpret availability results.
...
1. Check the GRMG run status message. Start transaction RZ20. Open the monitor collection SAP CCMS Monitor Templates and monitor Availability and Performance Overview. Under GRMG-Tested Availability, open the Self-Monitoring: Scenario <scenario name> subtree of the affected scenario.
Most likely, the run status message will be one of the following:
○ HTTP communication failure
In this case, GRMG could not establish a viable session with the URL specified in the monitoring scenario definition (visible in transaction GRMG). The causes of the problem may range from an incorrect host/port number, or extension in the URL to the failure of a network link or host, to a processing error in the server (HTTP 500 status code). In any case, continue the analysis with step 2.
○ No response for any component in request
In this case, GRMG received a response from the web server, but it was not in the form of a valid GRMG XML response. Most likely, the server returned an HTML page describing an error of some sort in the GRMG request, such as an invalid password or non-existent page. In any case, continue the analysis with step 2, however, step 3 may bring the most information.
2.
Check the response
headers, if any, reported by GRMG. In the event of a scenario execution error,
GRMG reports any HTTP response headers that are available to the HTTP client
into the Self-Monitoring: Scenario
<scenario name>
subtree. You can view the headers by marking the Run Status/Error Messages MTE and selecting
(Display Details) in the tool bar.
Often, the HTTP status code and status reason headers will tell you what you need to do to correct the scenario execution problem, regardless of whether it is an HTTP communication error or an invalid GRMG response. Frequent status codes are as follows:
Status Code |
Description |
3xx Redirection |
the GRMG HTTP client is not able to process re-directs in GRMG Classic mode. Modify the scenario definition to use the final URL if possible, or monitor the web service with GRMG Lite instead of GRMG Classic. GRMG Lite lets you accept a 3xx code as a successful HTTP ping. |
401 Unauthorized |
The GRMG scenario
could not log on or otherwise authenticate itself to the web server. Correct
the authentication data in the GRMG scenario definition in transaction GRMG.
You can access standard GRMG properties with the Edit function in transaction GRMG (see
If your central system runs SAP NetWeaver 04, be aware that all encrypted passwords must be uploaded in and/or maintained in client 000. Otherwise the GRMG data supplier cannot access the encrypted passwords. See SAP note 786971 for more information. |
403 Forbidden |
The GRMG HTTP client is not allowed to access the web service identified in the URL. |
404 Not found |
The GRMG URL cites a web service that could not be found at the responding server. This error may also be returned if GRMG was not able to contact the web server at all. Correct the URL in the GRMG scenario definition in transaction GRMG. |
500 Internal error |
The server could not process the GRMG request. For example, the GRMG application may have thrown an exception. Check the GRMG application in the web server. |
503 Not ready |
The web server encountered a timeout while accessing some other service requested by the GRMG application. Check the GRMG application in the web server. |
3.
Often, the HTTP
status code will not fully clarify the scenario execution problem if GRMG
reports No response for any
component in request. You
can often get more information on the problem by tracing the execution of the
scenario in the
Internet Communication
Manager at the central monitoring system.
Do the following:
a. Log on the central monitoring system and start transaction SMICM.
b. Turn on tracing by selecting Goto ® Trace level ® Set. In the pop-up, set the trace level to 3.
c. Start another session with transaction GRMG. In GRMG, start the problem scenario.
d. Return to transaction SMICM and choose Goto ® Trace level ® Default to turn off tracing.
e. Display the trace file by choosing Goto ® Trace file ® Display all or Display end.
f. Search for the problem scenario by searching for the string SCEN or for the technical scenario name.
Analysis:
...
a. If you can see the GRMG request being sent in the trace, this then establishes that the HTTP session could be created and any authentication was successful.
b. If you do not see the GRMG request text in the trace, then look for problems in the trace in host name or service resolution or in establishment of a session with the web server (authentication problems).
c. The response text from the web server (if any) will generally be in HTML form and may detail the problem that the web server encountered. For example, the web server may explain an authentication problem or return an exception thrown by the GRMG application.
The logs and
traces of the web server may also provide valuable information on errors in
running a GRMG monitoring scenario. If the web server is a NetWeaver Java Web
AS, then you can view the logs and traces in the
Visual
Administrator or
NetWeaver
Administrator. You will find alerts for error messages from logs and
traces in transaction RZ20 of the central monitoring system as
well.
Correct the problems that you identify in the ICM trace and start execution of the GRMG monitoring scenario again.
GRMG always writes error messages in the CCMS data supplier log. However, you can activate more detailed tracing of GRMG scenario execution, which is reported into the data supplier log as well.
To activate tracing of scenario execution, do the following:
...
1. In your central monitoring system, start transaction RZ21.
2.
In the Methods frame, select Method definitions, and then
Display overview.
3. Open method GRMG_TRIGGER for editing.
4. Switch to the Parameters tab and set the TRACE parameter to the value X.
Tracing will start with the next execution of the GRMG data supplier, typically within five minutes.
5. Deactivate tracing by clearing the value of the TRACE parameter.
To display GRMG traces, do the following:
...
1. In your central monitoring system, start transaction RZ20.
2. Open monitor collection SAP CCMS Technical Expert Monitors.
3. Open monitor CCMS Selfmonitoring.
4. Open the MoniInfra subtree of each application server on which GRMG scenarios are processed.
Typically, scenarios are processed only on the central server, the server on which the CCMS_Selfmonitoring context resides (check in transaction RZ21, Context overview). However, if GRMG scenarios have been started interactively in transaction GRMG or have been moved away from the central server, then GRMG will run on more than one application server. More than one MoniInfra subtree may then contain trace messages from GRMG.
5. In each MoniInfra subtree open the DataSupplier subtree and display the Log MTE.
6.
Display the log
messages by marking Log and selecting
(Display Details) in the tool bar.
7. If you are looking for problem messages, then switching to the view Open alerts and displaying alerts for the entire CCMS Selfmonitoringmonitor may help you, since GRMG triggers alerts for serious problems, and alerts are persisted longer than log entries.
Since log messages are quickly displaced by new messages, you will only see trace activity from recent GRMG runs. If too few messages are displayed in the log, you can increase the size of the log within bounds by increasing the setting of the field Maximum number of lines to be saved in the Log MTE properties in RZ20. The value 1.000, for example, holds 1000 lines in the Log at one time, or as many as fit in shared memory.
You can debug GRMG by starting the GRMG data supplier interactively. The data supplier will then run as though the CCMS Monitoring Infrastructure were in start-up mode. All scenarios will be run, regardless of whether a refresh of monitoring data is due for a particular scenario or not.
To start the data supplier interactively, do the following:
...
1. In the central monitoring system, start transaction SE37.
2. Enter GRMG_START_SCENARIOS and activate Test mode.
3. Run the function module in debug mode without making any changes in the parameters.
