The service metering feature allows SAP NetWeaver components involved in the provisioning and consumption of Web services to collect information about which client components are consuming which Web services. This feature is technically enabled for mediated as well as for point-to-point Web services communication. In service metering enabled environments, the service provisioning side collects technical information about the caller and stores the metering data. The information collected in the SOA back-ends can be read via Early Watch and analyzed with the purpose of optimizing the offered SOA scenarios and the enterprise services.
For each service called, the service consuming application provides caller information. This data is provided by the SOA infrastructure, which by default adds the data to the HTTP header of the service call, and only in special cases to the SOAP header. For service consuming applications running on SAP systems you can choose the amount of caller information sent and the header (SOAP or HTTP) in which this information is transferred.
The request message transfers the calling information to the service provisioning system using XI or Web service protocol in a point-to-point or mediated way. In a mediated scenario, the integration server does not store service metering data.
The SOA runtime infrastructure (Java and ABAP) on the provider side receives the message. It extracts the caller information, adds the name of the called service interface and operation and stores them all as a service metering record. The aggregation period is one calendar month (UTC) and the data is kept in the system for a predefined period of five months, after which it is deleted. The stored information could be retrieved via Early Watch. The SOA runtime infrastructure on the provider side performs these actions automatically and requires no configuration.
The service metering feature is designed and implemented in a way that it has minimal effect on the performance of the service consumer and service provider sides.
The configuration of the amount of service metering data sent to the provider side requires careful evaluation of the security implications. When choosing the amount of service metering data you should consider the trustworthiness of the Web service provider:
If you don't have information on where and how the Web service is provided you should choose the Minimal Data Transfer level.
When you are sure that the Web service is provided by a trustworthy party you can increase the service metering level. For example, you can do this for service providers residing in your internal network.
For more information about configuring service metering when using non-SAP service consumers, see Service Metering for Non-SAP Service Consumers .
The service consuming side can provide the caller information attributes described below. You can choose which of them should be sent via the request message by configuring the corresponding physical destination, provider system, or consumer proxy.
Calling Application Type
Only set by service consumers based on SAP NetWeaver. The first character denotes the company (for example S for SAP) and the second character denotes the platform (for example, A for ABAP, J for Java, N for .NET)
For consumers based on SAP NetWeaver, the software component version of the proxy (for ABAP), and if available, also for Java. For third-party consumers, registered partners cam provide an ID of the calling component.
Calling Application ID
For consumers based on SAP NetWeaver, the application component (for ABAP), or the application name in the J2EE Engine (for Java). For third party consumers, registered partners can provide an application ID supplied by SAP.
Calling Company ID
For consumers based on SAP NetWeaver, the installation number of the consumer system. For third party consumers, registered partners can provide an ID of the calling company.
Calling System ID
Provides information about the system from which the service call is done.
The service metering data can be transported in the SOAP or HTTP headers:
The advantage of the SOAP header is that third party consumers can more easily add the service metering data. In addition, the information in the SOAP header has higher chance to remain unchanged when it passes hardware and software hubs on its route to the provider. Although this is a standard procedure from SOAP perspective, third party service providers may experience issues when they try to process the optional metering fields.
The advantage of the HTTP header is that it already contains proprietary data, and service providers can easily accept the addition of metering data. The HTTP header has the disadvantage that it can be harder for third party service consumers to add service metering data. In addition, the information in the HTTP header has lower chance to remain unchanged when it passes hardware and software hubs on its route to the provider.