Configuring the Web Service Runtime

Objective

After completing this lesson, you will be able to configuring the WS Runtime for WS-RM Usage

Web Service Runtime Configuration for Web Services Reliable Messaging

To use asynchronous Web Services and, therefore, use Web Services with Web Services Reliable Messaging, the Web service runtime must be configured.

You have to perform the following technical configuration in client 000 of your Web Service Provider and your Web Service Consumer system, as well as in each productive client.

Note

The various possibilities of monitoring and tracing are only available for asynchronous communication.

Technical Setup

In each productive client and in client 000, execute the Technical Setup in transaction: SRT_ADMIN . You can choose between the automatic and the manual setup.
Using this report, you create a service destination for communication through RFC and you perform the settings for the bgRFC (Background Remote Function Call).
SOAP requests are processed using the Internet Communication Framework (ICF). The SAP NetWeaver Application Server uses the HTTP protocol of the ICF for communication between the Web service consumer and the Web service provider. The ICF provides the infrastructure for handling HTTP requests in work processes in a SAP system. A HTTP request calls a service in the ICF server. This service contains one or more HTTP request handlers that are responsible for running the ABAP functions.
Using report, SRT_ADMIN, all the following ICF services required for standard functions of the Web service runtime are created:
- /sap/bc/srt/
- /sap/bc/srt/wsil
- /sap/bc/srt/wsdl
- /sap/bc/srt/esf_in
- /sap/bc/srt/xip
- /sap/bc/srt/rfc
- /sap/bc/srt/pm
- /sap/bc/srt/xip/sap
- /sap/bc/srt/lsc
- /sap/bc/srt/scs
The log and trace levels can be selected using the report: SRT_ADMIN, or directly in the SOA Manager tool under Logs and Traces.
Start the background request: SAP_SOAP_RUNTIME_MANAGEMENT for component BC. Call transaction: SM36, and choose Standard Jobs - Standard Scheduling and Schedule Standard Job. You must schedule the job hourly as default scheduling.
If bgRFC has not been used before, set up the bgRFC supervisor destination in transaction: SBGRFCCONF under Define Supervisor Destination. Specify a name and a user and assign it to role: SAP_BC_BGRFC_SUPERVISOR.

Check your configuration in transaction: SE38, running report: SRT_ADMIN_CHECK. The check is performed in three areas:

SRT_ADMIN_CHECK - Test Areas

Area	Check
System-Related Settings	Service Destination bgRFC Settings (inbound destination, supervisor destination) Job Runtime Management Task Watcher Data Collector for Payload Trace ICF node for SOAP runtime
Client-Specific Settings	Service Destinations for All Clients
Client-Specific Functions	Test Execution for Service Destination with Authorization Check

Background Remote Function Call (bgRFC)

The bgRFC allows applications to record data that is received later by a called application. When the data is received, you must ensure that the data was transferred to the receiver either once only in any order (transactional), or once only in the order of creation (queued).

With the bgRFC, therefore, the asynchronies between the caller and the called application can result in the following advantages:

Within a SAP system (same System ID, same client)
Decoupling and (potentially) parallelization are possible. The load is spread across the available application servers for this system. This bgRFC scenario is known as an inbound procedure.
Between two remote SAP Systems
Decoupling and, therefore, the physical segmentation of an application or a business scenario are possible. As a result of the asynchronies, differences in the key features of the application servers for the called and calling applications can be balanced out. The recording is done in the calling system. This scenario is an outbound procedure.
Both procedures can be combined in an out-in procedure.
Here you can take advantage of all the optimization options. However, if you chose to do this, the data is recorded twice, once for the caller (outbound processing) and once for the called application (special type of the inbound procedure). This results in additional load for the database, and for the application server as well due to the scheduler.

The bgRFC organizes the different calls using queues. A call that is placed in several queues at the same time creates a dependency between these queues. This leads to a synchronization point, which is similar to a lock.

The dependent queues can be processed until the entry for processing is at the head of the queue that defines the dependency. This entry can only then be processed if it is at the head of all the queues.

Monitoring bgRFC

The bgRFC monitor is called using the transaction: SBGRFCMON.

Use the bgRFC monitor to display the recorded units of the bgRFC. A unit consists of one or more function modules that need to be processed as an indivisible unit.

The units are stored on the database until they are processed. You can use the monitor to trace the state of the unit, from when it is first recorded, to until it has been processed.

Message Persistency

Configure Message Persistency

From SAP NetWeaver 7.4 Service Package 0, Web services are stored in a Web service-specific persistency (WS persistency). Messages that were created in an older release are stored in the persistency of the SAP Process Integration engine (PI persistency). You can see all messages in the message monitor (transaction code: SRT_MONI) and the column, Persistency, shows where a message is stored.

To configure the Message Persistency, call transaction: SRT_UTIL → Tools → Global Configuration.

Under Message Persistency, you can see where your message is stored. You can specify the retention period for messages in Web service Persistency. The default value is 40 days.

If WS Persistency is displayed, all of your messages are stored in Web service persistency.
IfPI Persistency is displayed, all of your messages are stored in PI Persistency.
If WS and PI Persistency is displayed, both persistencies are in use. This is the case if you have just upgraded your system and still have some older messages in PI Persistency and new ones in the WS Persistency.

Next lesson