Monitoring Web Service Calls


After completing this lesson, you will be able to:

  • Monitoring Web Service calls

Web Service Runtime Monitoring

In the AS ABAP, different tools for monitoring the correct functioning of the Web service runtime are at your disposal. You can deal with any errors that may occur using the tools provided.

Monitoring the Web service runtime is part of the central monitoring operation.

The following tools are provided for monitoring the Web service runtime:

  • Alert Monitor for Web Services

    The Alert Monitor for Web Services triggers an alert if problems occur during the configuration of the Web service runtime, if there are runtime errors of different error categories, and whenever there are performance bottlenecks after certain threshold values have been exceeded.

    Using this monitor, you can check whether the Web service runtime works correctly. The Web Service Monitor triggers an alert if the Web service runtime does not function correctly. The alert monitor consists of two areas:

    • Infrastructure:

      Checks technical background services that are required by the Web service runtime infrastructure to run correctly. Some of the settings relate to the entire system, and some of them are client-specific.

    • Message Processing:

      Displays the most important errors from the Web service error log. For each error category, the information from the error log is displayed for each client.

      If you display an alert for the client you are currently logged on to, you can navigate to the error log directly from the alert monitor. Note that the alert monitor and the error log use different time periods for their analyses. Therefore, the number of entries in the error log and in the alert monitor can differ slightly.

  • Logs and Tracing (in the SOA Manager tool):
    • The logging function provides information on processing steps in the SOAP runtime. With the tracing function, you can analyze errors or performance problems in detail.
    • First, configure the logging and tracing. Configuring Logging and Configuring Tracing.
    • Then, display the information: Displaying Logs and Traces.
    • Changes to the SOA configuration and publications are also logged in addition to this.
  • Web Service Support Utilities:

    The Web Service Support Utilities allow you to observe the processes in the Web service runtime:

  • Monitoring ABAP Web Service Messages.
  • Monitoring Event-Controlled Processing:

    When you are searching for errors, check whether the Task Watcher is being started at regular intervals. This is another prerequisite for reliable message transmission and transaction processing in the SOAP runtime.

  • bgRFC Units Debugging:

    You can debug a Web service with errors on the provider side using units of the bgRFC (Background Remote Function Call).

  • Virus Scan for ABAP Web Services:

    On the provider side, you can use the Web services virus scan to scan incoming messages for viruses. Both the message payload and the message attachments are scanned for viruses at Web service runtime. If a virus infection is detected, message processing is stopped and a system error is displayed in the message monitor (transaction code: SRT_MONI) and in the error log.

ABAP Web Service Messages Monitoring

The SAP ABAP Web Service Infrastructure provides a set of monitors to display information on the different entities involved in Web Service communication. The monitors are connected to the support utilities for Web Services.

You use the ABAP Web Services message monitor to display information about persisted asynchronous messages. You can track the status of messages, find errors that have occurred during processing, analyze what caused them, and perform a search to find messages that match the provided search criteria. You can display individual messages from the list and look at different versions of one message.

Errors that occurred in synchronous messages are logged in the error log.


Since only asynchronous messages are persisted, you can only display information about asynchronous messages in the message monitor.

You are assigned a role with the authorization object: S_SRT_MONI or S_XMB_MONI.

The figure, Monitoring Navigation, shows the possible navigation between the different monitoring views and the connected support utilities. The diagram is a state transition diagram where the round corner nodes represent the states – in this case, views/screens. The sharp corner nodes represent activities triggered from screens. Such activities also exist between two screens – like execution of a query when going from a selection screen to a list screen – but in most of cases, these are not shown to keep the figure simple. The bold arrows represent forward and back (F3) navigation. The thin lined arrows represent navigation paths where one cannot navigate back.

Web Service Utilities: Message Monitor

To start the ABAP Web Services message monitor, use transaction code: SRT_MONI. On the initial screen of the message monitor, you define the selection criteria of the messages you want to display in the message monitor. As an alternative, you can also open the Monitoring tab in the SOA Manager tool.

On the selection screen, you can decide if you want to first display a summary of the messages matching the selection criteria on the bottom part, or if you want to directly display the list of messages. In addition, you can switch between displaying a restricted or an extended set of message attributes in the message list – basic view vs. technical view.

The selection criteria are partitioned into two sets, standard and advanced selection.

On the Standard Selection tab, you can either select messages based on a set of message or sequence IDs, or based on a time range with optional addition of message attribute values. If you do not enter any additional selection criteria, the default time range of one hour back until the end of the day is used. The attributes for time range-based selection are either direct message attributes such as adapter type, user name or sender/receiver party and interface name, or the processing status group.

You can select one of the following adapter types:

  • Mapping

    Web services that originate from mappings.

  • Eventing

    Publish/subscribe mechanism which is based on WS messages.

  • Groupware Scenario

    Web services sent and received within a groupware scenario, where messages from the consumer are "pulled" from the provider.

  • Integration Server

    In an XI environment, messages from integration server.

  • Plain SOAP

    Non-WSRM based SAP reliable messaging.

  • RFC

    Synchronous RFC consumers.

  • Shortcut

    Local Web services that are called in a performance optimized way.

  • Standard Web service

    Native Web Services.

Processing Status

The processing status describes whether there are problems in the processing of a message. It is a derived message attribute that combines the native message state, the sequence state, and the asynchronous processing queue (bgRFC queue) state. For on-failure, it includes the respective state as well. All of these statuses are considered when making a statement about the overall status of the message.

For easier management of the processing statuses, they are consolidated into the following processing status groups:

  • Application error

    An error that occurred in the application that implements a service provider.

  • System error

    An error that occurred in the message processing infrastructure.

  • Wait for processing

    The message is waiting for processing. The reason for this might be that the message is not the first in the processing queue of a sequence. In that case, all predecessors need to be processed first. It can also indicate an overload situation preventing a fast processing of messages.

  • Cancelled

    The message was manually canceled or it is an automatically annulled compensate message in TUC/C communication.

  • Isolated

    The logical port of the message is isolated. Therefore, the message will not be sent to the service provider system.

  • Erroneous

    A combination of the groups Application error and System Error.

  • Canceled or isolated

    A combination of the groups Canceled and Isolated.

  • Incomplete processing

    A combination of the groups Application error, System error, and Wait for processing.

  • Incomplete (no "pulling"-messages)

    All incomplete messages, but does not include any messages pulled from the consumer by the provider (used in groupware scenarios).

  • Terminated with dump

    An error that produced a short dump during message processing.

  • Finished

    The message was successfully processed.

Advanced Selection

On the Advanced Selection tab, you can define more technical attributes for the message selection query. Note that entries in the Advanced Selection overrules the standard selection. Again, you can select messages using a set of identifiers for the asynchronous processing queue or the message persistence entry. In rare cases, a message ID can actually represent two messages, one at the service consumer side and one at the service provider side, which can both be stored on the same system. A message persistence ID, on the other hand, is a unique identifier for a message. You can also query messages based on a time range, and you can restrict your result set by specifying the SAP passport identifiers root context ID and transaction ID. The SAP passport can be used to identify communication entities in cross-system communication. It can be helpful to get an end-to-end monitoring view in a communication scenario where the message ID cannot be used as a unique ID throughout all systems involved.

Message List Usage

The result of your selection is the message list. In the message list, you have various possibilities to work with the list. You can carry out the following activities:

  • Restarting Messages

    You can restart messages that have an error status. The messages are added to the asynchronous processing queue to be processed again. For example, a restart like this can make sense if the configuration was changed after the last execution trial that produced the communication error.

    To restart more than one message at a time, use the program at: SE38SRT_UTIL_RESTART.

  • Restarting a message with debug

    If you only select a single message with an error, you can restart it and start the debugger in the Web service runtime code. Note that the debugger is not started in the application code.

  • Canceling messages

    You can cancel messages that have an error status. Canceling a message sets it to the final status Cancelled without processing it. In some cases, a message cannot be canceled in the message list screen. It then needs to be canceled from the inconsistent message list screen.

    To cancel more than one message at a time, use the Transaction Code: SE38SRT_UTIL_CANCEL.

  • Consistency check

    The consistency check is only available in the technical view. It checks the consistency between the message status data and the asynchronous processing data. Note that the inconsistencies are only detected after a period of 5 minutes after the activity that led to the inconsistency.

    The consistency check produces the inconsistent message list. This list is similar to the general message list, but it shows some more technical detail information because it is intended for support activities. In the inconsistent message list, you cannot do a general reselection, but you can run a consistency recheck for the displayed messages. You can also enforce the cancelation of selected messages. In this case, the system skips some checks that are carried out if you cancel messages in the general message list.

  • Displaying details of a message

    From the message list and from the inconsistent message list, you can display details for a single message by clicking on the message ID. By default, the payload view is displayed with all message details. A table shows the message payloads. If there was an error, the initial message version and the error versions are available. You can display an XML view of the payload by choosing Original XML in the upper menu. To display more details, such as header information and the message structure, you can change the view of the message detail screen. For example, you can then see if a payload is stored as an attachment to the actual message.

  • Monitoring Sequences

    You can navigate to the sequence monitor from the message list or directly using transaction code: SRT_MONIS. This opens the initial sequence selection screen where you can either enter a list of explicit sequence IDs, or make a selection based on a time range and some sequence attributes. From this selection screen, you enter the sequence list screen.

    A sequence controls the reliable messaging - WSRM or SAP's Plain Soap. In SAP's WSRM implementation, messages with quality of service exactly once (EO) are also sent in the context of a WSRM sequence. In this case, a sequence has only one business message and a technical terminate message. This is why a related sequence exists for all asynchronous messages. The sequences related to a certain message set are displayed in the sequence list. In the sequence list, you again have reselection options.

    You can trigger a soft or a hard termination of a selected sequence. A soft termination closes the sequence on the consumer side for new messages. If the sequence contains unfinished messages, they are processed. After the last message is processed, the sequence is set to the status: Closed. In case of a hard termination, the sequence is terminated immediately and all messages that are not processed yet are canceled. As the message is the central entity, you usually access the sequence list from the message list. In some cases, however, it is useful, or even necessary, to enter the message monitor by selecting a sequence directly. For example, if there are no messages for a persistent WSRM sequence, this sequence can only be found from the message selection entry.

Web Service Support Utilities

The Web Service Support Utilities allow you to observe the processes in the Web service runtime. The utilities are as follows:

  • Web Service Logging

  • Web service tracing, such as performance tracing, functional tracing, and payload tracing.

The Web service logging utility provides all necessary information about the location and context, and also a recommended action for errors in the Web service runtime. Based on this information, a Web service user or system administrator can try to solve a problem, or contact the affected development department.

The Web service performance tracing utility provides information about the duration details of a Web service operation on the consumer and/or provider side. This information can be used by Web service runtime developers, Web service developers, and Web service users to identify performance problems.

The Web service functional tracing utility provides information about calling details of a Web service operation on the consumer and/or provider side. This utility should only be used by Web service runtime experts to identify problems from within the Web service runtime. Consider that one needs to know well the details of the Web service runtime to be able to analyze the functional tracing data.

The Web service payload tracing utility provides information about data sent and received via the HTTP channel, and also from, and to, the Web service consumer or the Web service provider. This tracing can be used by Web service runtime developers, Web service developers, and Web service users to check the data sent or received via HTTP, and also from, or to, Web service consumer or provider.

When one or more of these traces are activated on the consumer side, tracing information is sent to the provider side via the HTTP header. If the provider system is an ABAP back end with at least release 7.20 or 7.02, and this ABAP back end allows 'remote trace' (profile parameter: rstr/accept_remote_trace = true), the corresponding tracing is also activated on this ABAP back end.

Configure Logging

You can use the error log to receive information about the most important processing steps in the ABAP Web service runtime. The amount of information kept in the log depends on the selected logging level. You can set the desired logging level, as well as the period for which the information is kept in the log. You can also define whether the error log entries should be aggregated in the database according to their error category. This reduces the log size in the database and gives a better overview of the log. However, the detailed error data is only saved for the first occurrence of the aggregated errors.

When you configure the error log, you should consider the following:

  • Once you set a log level, it stays valid until it is changed.

  • The log configuration is client-specific.

Configure Tracing

Functional Trace is a utility that allows you to fully analyze a problem situation with a Web service. When activated, it records different calls from, to, and within the SOAP runtime. The recording is based on the configured trace level. The Payload Trace utility can record the whole SOAP request and response, including application data sending over the HTTP channel. It can be activated by a specified payload trace level.

You can use the tracing functionality to perform a detailed analysis of errors in Web services that were discovered with logging and monitoring. You can activate the tracing and set the desired tracing level for a user, terminal, or request URI:

  • Tracing by user

    You can specify the user ID under which the Web service consumer or provider is running. It is suggested you use tracing by user only if you know there is only one Web service application logging to the ABAP back end for the selected user.

  • Tracing by terminal

    It is suggested you use tracing by terminal instead of by user when there is more than one application running for the same user. When you want to use tracing by terminal, make sure the user has set SAP GUI to send the terminal ID for each request to the back end.

  • Tracing by request URI

    You can specify the request URI, which identifies the Web service endpoint at the provider side. You can use tracing by request URI when conversation security with delay logon is used.

The tracing information is available only in English. The tracing configuration is client-specific.

When you activate functional tracing or payload tracing, the system starts recording tracing information for the specified user, terminal, or request URI for two hours. By default, the system keeps the tracing information for two days. If you need to keep the tracing information, you can set the expiration day individually for each trace entry.

Error Log Display

The error logging function (Transaction Code: SRT_ELOG) provides information about all errors happening during the processing in the SOAP runtime. The system writes an entry in the error log for any Web service error, both for synchronous and asynchronous Web service communication. Note that the log may not contain details on every error if aggregation has been switched on during configuration.

You can use the error log to:

  • Check the recommended action for an entry, and try to solve the problem or ask for help from the administrators or SAP Active Global Support.

  • Use information such as the names of the interface and the operation, the message ID, and the user ID to perform further analyses in the Message Monitor and the Sequence Monitor.

  • Use information such as the names of the interface and the operation, the message ID, and the user ID to perform further analyses in the Message Monitor and the Sequence Monitor.

Consider that the error log contains entries only for errors that occur during runtime. It does not contain information about activities such as changes to the Web service configuration, deletion or cancellation of Web service messages, or termination of Web service sequences. You can find information about these activities using the SOAP Configuration Management tools.

Log in to track your progress & complete quizzes