Monitoring Web Service Calls

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.

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.

Prerequisites

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.

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: SE38 → SRT_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: SE38 → SRT_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.

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.

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.