SOAP Web Service Error
Due to errors in the SOAP Web Service, the user is unable to establish a working Web Service communication. It is mandatory to set up the Web Service Runtime, prior to using the Web Service communication
Precondition:
The appropriate configuration of the underlying bgRFC environment (TA: SBGRFCCONF), is a precondition for the configuration of the SOAP Web Service Runtime.
Introduction and Overview
The accurate processing of asynchronous Web Services calls necessitates the configuration of few critical system components, which are all involved in the process, e.g. RFC, bgRFC and ICF.
This configuration can be duly performed by utilizing the transaction SRT_ADMIN. Additionally, the transaction can be utilized for resetting the configuration or for checking the present configuration.
Please note: Not all the releases of "NetWeaver" and "Business By Design" have the above-mentioned transaction and their functionalities. There are many differences in the program functions and their display (message display). Within this SAP Note, we have explained the transaction for the Release 7.5 and higher.
All the three functionalities of the transaction SRT_ADMIN will be explained in detail. The solution section is structured as follows:
- Check the Technical Configuration
- Technical Configuration
- Reset the Technical Configuration
Check Technical Configuration
User Selects the radio button ‘Technical Configuration’ in the beginning screen of the transaction SRT_ADMIN. Later, user obtains a screen with many options for filtering the results of the check report:
1) Input field Client: User selects a specific tenant, where he wants to check the WS Setup. In case of an empty entry, he receives the WS Setup information of all clients.
2) Input field Administration Task: Filter between the various Admin tasks all related to the WS Setup. The options are listed below:
- Delay Logon User (WS Security): The check routine reports the status of the 'Delay Logon User'. It also verifies the consistency of the Service user, the configuration for WS Security logon along with the the Delay Logon User is operational, if any.
- ICF nodes: The check routine provides reports on the activation state of the ICF nodes, e. g.
/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
oIdempotency: verifies if the idempotency of the service is operational or not. If its not operational but required by the application a manual configuration of the idempotency is required.
- Service RFC Destination and User: For this Admin Task the check produces the technical attributes of the present service destination (client, activation state, name of the RFC destination, technical name of the destination, as well as the name of the user on the service destination).
- Task Watcher: For this Admin Task the check program reports the present state of activation.
- obgRFC Supervisor: This Admin Task is an important prerequisite for operating the Web Service Runtime. The check routine provides report on the present state of this setting (existence, active or inactive state).
- obgRFC Inbound Destination: The check routine reports the state of the inbound destination to the bgRFC (operational, non-operational, error messages usability, the name of the check class and the status of the check class).
- WSRM Event Handler: The check routine provides a report incase the WSRM event handler process has been activated. The functionality of the WSRM Event Handler is not required any longer because of a change in the coding of the SOAP runtime Therefore, the check is positive incase the WSRM Event Handler is not functioning.
3) Radio-buttons: The user can control incase the check is only listing errors or also warnings or all information, through the three radio-buttons.
Technical Configuration
Following are the precondition for the Technical Configuration:
1) To ensure a successful configuration of the SOAP Web Service Runtime the setup is performed in all relevant clients. It is advised to perform the setup at first in client 000, as many mandatory cross-client routines are executed (e.g. clean-up jobs) in client 000. Later, the technical setup should be executed in each client which would be able to utilize the Web Service infrastructure.
2) The user must ensure that he has ample of administrative authorizations to the for performing the configuration. The steps listed below for following authorization objects are essential for these users:
- S_TCODE with SA38
- S_PROGRAM with the action SUBMIT
- S_SRT_ADM with activity 70 and WS_NAME "*"
- S_USER_GRP with the class * and activities 01, 03, and 06
- S_USER_SAS with activities 01, 06, and 22, as well as the activity group SAP_BC_WEBSERVICE_SERVICE_USER
- S_USER_AGR with activity 64 and the activity group SAP_BC_WEBSERVICE_SERVICE_USER
- S_RFC_ADM with activities 01, 02, and 06 and RFC type "3"
- S_BGRFC with activity 02, bgRFC type 07
Documentation of activities in the automatic setup
The Technical Setup is implemented in an automated way. However, we have explained in detail all the various underlying administration tasks which are all impacted by the setup:
Cross-client Administration Tasks
These tasks are impacted by the initial Technical Configuration in client 000.
bgRFC Inbound Destination
A background RFC (bgRFC) inbound destination is created. This destination is required to use the scheduler for asynchronous WS messaging. As the inbound destination is essential only once for each system it is therefore configured in client 000 of the system. For dividing the messages in various processing queues many prefixes are introduced. The names of the prefixes of the inbound destination are listed below:
- SRTQC_
- SRTQP_
- SRTQS_
- PERSP_
- PERSC_
The registration of the bgRFC inbound destination to the Web Service Runtime can be performed only once. This cannot be reset. The naming of the bgRFC inbound destination can be reckoned out by transaction SBGRFCCONF (see tab 'Define Inbound Dest.'). If there are more than one inbound destination available in this view, then the user can determine the Web Service Runtime related inbound destination by double clicking the several items. The one which has the five prefixes from above in the 'Queue Prefixes' overview is the correct right inbound destination.
In addition, a technical ABAP class is registered to the inbound destination of the bgRFC, which generally regulates the deletion of units from the Web Service runtime.
Please note: The Check Class in the scheduler destination is not reset by the technical reset of transaction SRT_ADMIN.
Task Watcher
The Task Watcher is initiated In the final step for the technical configuration in client 000. The Task Watcher performs the following steps In the background the Task Watcher performs the following steps:
1. Monitoring the logical units of work (LUWs) that execute a Web Service which encompass a TUCC pattern in all clients.
2.Synchronizing runt time, the design-time, and configuration changes in the various clients.
Client-dependent Administration Tasks
The following administrative tasks are impacted In each client where the Web Service functionality is configured by the automatic Technical Configuration of transaction SRT_ADMIN:
RFC Service Destination and Associated User
Within the Web Service Runtime a service destination is required for many background activities (e.g. clean-up jobs). A prerequisite is a User, which is automatically created during the setup. This User has the following list of properties:
- User-Name: SAP_WSRT. In some cases, e.g. update from older releases, this name can vary. In case of a new setup the user name is always SAP_WSRT
- User-Type: System
- Alias: Created
- State: Activated
- Validity period: Dec. 31st,9999
- Password: Generated by internal system routine or by specification of the User of SRT_ADMIN
- Roles: SAP_BC_WEBSERVICE_SERVICE_USER is assigned
The created service destination is a RFC destination with the type ‘ABAP Connections’. The name of the destination is generally WS_SRV_<User-Name><Client>. The user can obtain information regarding the attributes of this connection by transaction SM59. Also the name of the Destination is stored in the global properties of the SOAP runtime.
Incase the user or destination exists already, they will be re-used. In case of re-use of the user, the password should be clearly specified in SRT_ADMIN. For creating the service destination, the password is required.
Example for a new setup in client 123:
First the setup verifies incase the destination WS_SRV_SAP_WSRT123 already exists. If yes, the destination is re-used. If the destination does’nt exist, the setup checks if there’s already an user SAP_WSRT. If the user already exist and the password has been specified in SRT_ADMIN, the service destination is then created by utilizing the existing user SAP_WSRT.
Note: If a new Service User and Service Destination is created by the automatic setup the naming convention is always, as listed below:
WS_SRV_SAP_WSRT<CLIENT> (e.g. WS_SRV_SAP_WSRT123)
Manual naming of the Service User and Service Destination as in Releases earlier than the 7.50 version is no longer provided, because of the fully automatic character of the setup.
Activation of ICF Nodes
- In default state all the ICF Nodes are inactive. During the Technical Setup each Node is activated.
Delay Logon User
During the Technical Setup the WS Security Setup is executed and it generates the Delay Logon User.
Perform Technical Configuration
For performing the (automatic) Technical Setup, user selects the Radio-button 'Run Technical Setup'. In the sub-block 'Password for Service User' decide whether he wants to auto-generate the password or he wants to specify it for the created User (see section RFC Service Destination and associated User). Later, user presses the Execute-button (F8) for initiating the process.
Reset the Technical Configuration
For reversing the Technical Setup, the use can run a Technical Reset. Almost all settings are undone by this option, except the registration of the inbound destination of the bgRFC and the check class to the scheduler destination. This irreversibility has been reasoned by the fact that the bgRFC queue is possible but not empty.
User has the following two options, by the two radio-buttons:
- Local and Cross-Client: Resetting the technical settings for the client, the user is logged on with and reversing the cross-client settings.
- Local Client only: Resetting only the technical settings in the present client.