Contents

Technical Setup and reset of the Web Service Runtime

Overview

The Web services runtime is a service layer/framework of SAP_BASIS. It depends on other components (user management, role management, RFC, bgRFC, ICM and ICF), but needs to be configured by settings, parameters and options of these components as well as by settings, parameters and options provided by itself. One of the main settings is the service destination , which is needed for every tenant/client. It allows to enter the specific tenant/client to run tasks by a given function which are tenant/client specific. These tasks are created and started in the (standard) administrative tenant/client named “000”. This is because the system feature AUTOABAP is started and running in tenant/client 000 after system start. The AUTOABAP is a central process which starts other processes as child processes. Beside the task watcher of the Web Service Runtime it also starts the main process of the background RFC ( bgRFC), the scheduler.

To make the technical settings easy to perform, a procedure for an automated set up is provided. This is called by report SRT_ADMIN. The settings can also be done by manual action, especially needed if the user name of the service user should differ from the standard value or if the user set up is not allowed in an specific system ( Central user maintenance).

Automated setup

Some parts of the technical setup have been automated. This is the creation of the service user, the creation of the service destination, the registration of the inbound destination at the bgRFC and the registration/activation of the check class for the bgRFC scheduler at bgRFC. The report SRT_ADMIN provides this procedure when the flag “Automatc Setup” in block “Technical Setup for System” is flaged to ‘X’ and the report run is started (F8). For an easier problem solvement of inconsistencies, a reset (with user deletion and destination deletion) is also available. The report SRT_ADMIN provides the following functions:

Technical setup for System

• Automatic Setup
  • Automated creation of service user and role assignment
  • Automated creation of service destination
  • service user assignment
  • Creation and registration of bgRFC inbound destination
  • Assignment of scheduler destination and check class registtration
  • For systems with customer specific password rules, the password for the service user to be create, can be inserted before the user is created, if the flag “Accept password fir user creation” is set to ‘X’. This password than is assigned to the new user SAP_WSRT. Otherwise the password is generated by the standard rules with the standard function. It value is stored into the secure area (from RFC) and can never been read or display at any UI.
  • If flag “BydLandscape” is available and switched on during the report run, the service user is NOT created by the procedure. It will use the user name SAP_WSRT at the service destination whereby the password is read from the ByD User management (IAM).
• Technical Reset
  • Automated deletion of the service destination
  • automated deletion of the service user which has been assigned at the service destination ( std. SAP_WSRT).

  • If flag “ByDLandscape is available and switched on during the report run, the user at the service destination is NOT deleted.

     The step technical setup in NetWeaver 7.40

     

    Back to top

Manual Setup

• Manual registration of the service destination name
• Manual registration of the bgRFC inbound destination

• Automated registration and activation of ICF nodes

   

  Back to top

Setup Check

This function starts execution of report SRT_ADMIN_CHECK. This program checks all settings which are necessary for the web service runtime and reports the status. The settings considered by the health check are:

• Supervisor destination with attributes (client/tenant of registration, name, status [soastage:operational/ not operational], status text, (error) message text (if any), name of user, user name of last change, date of last change, time of last change).
• Example:

• Task watcher with attributes (tenant [soastage:fix 000], status [soastage:running, starting, , stopping, not running], period [soastage:10] in seconds, user name of last change, date of last change, time of last change])
• Example:

• bgRFC with attributes (client/tenant, status text [soastage:number of schedulers running], status messages)
• Example:

• Service destination with attributes (client/tenant, name, status [soastage:operational/ not operation], technical name, name of service user attached)
• Example:

•  
• Inbound destination with attributes (client/tenant, name, status [soastage:operational/ not operationl], usable [soastage:true/false], name of the registered check class for the scheduler destination, status of the registration of the check class [soastage:active/inactive])
• Example:

• ICF nodes with attributes (client/tenant, status messages, error messages)
• Example:

• Idem potency with attributes (client/tenant, status text, usable (‘-‘ / ‘X’)
• Example:

The areas of health check are hot spoted. Clicking at the hotspot, the attributes of the specific area object are displayed. In case of the area bgRFC, messages from the health check function of the background RFC are read and displayes. The only health check status which can be taken as an “operational or not” – status ist the number of running inbound schedulers. If the number of running inbound schedulers is zero, the background RFC is not working in this client/tenant.

To run the automated setup, the program checks is the user does have the authorizes to perform all actions. This includes the setup , as well as the reset of the properties. The list of authority objects is as follows:

• S_TCODE with SA38
• S_PROGRAM with action SUBMIT
• S_SRT_ADM with activity 70 ans WSNAME = *
• S_USER_GRP with class * and activities 01, 03 and 06
• S_USER_SAS with activities 01, 06 and 22
• S_USER_AGR with activity 64 and activity group SAP_BC_WEBSERVICE_SERVICE_USER
• S_RFC_ADM with activities 01, 02 and 06 with RFC type “3”
• S_BGRFC with activity 02 and bgRFC type 07

If this authorities are not assigned to the user starting the setup procedure, the program aborts with an error message.

 Output of the report with a correct configuration in NetWeaver 7.40

 

Back to top

The Service User

The service user (once created) is connected to the service destination. Its name is SAP_WSRT. The user type must be of “System” or “Service”, whereby the type “System” is strictly recommended, because a user of type “Servce” is allowed for dialog logon on that system tenant/client he is created in. The user has to be assigned to role SAP_BC_WEBSERVICE_SERVICE_USER. This role contains all authority objects needed to be able to run the back ground tasks.

The user attributes are:

Once the service user has been created, it has to be assigned to the service destination. The creation and the assignment of the service user is part of the automated set up procedure.

The Service User role

This role is shipped as an “productive” role. The list of authority objects is updated in case of new tasks to perform or if new authority objects necessary for already existing tasks. The list of authorities is checked by function module TASK_CHECK_AUTHORITY. This function is used to determine the health status of the service destination.

The current list of authority objects is:

• S_BGRFC with ACTVT = (01, 02, 03, 05, 06, 95), BGRFC_D_IN = ( * ) ,BGRFC_D_OU = ( * ) ,BGRFC_TYPE = (01, 02, 03, 07, 13, 14, 15, 16)
• S_RFC with ACTVT = (16), RFC_NAME = (BGRFC_CONFIGURATION, SENT, SRTUTIL, SRT_PROCESS_DT_CHANGE, SRT_SEQUENCE_REORG, SRT_SEQ_SCD_QRFC_NEW, SRT_SOAP_SEQUENCE_REORG, SRT_SEQ_SCD_QRFC_NEW, SRT_SOAP_SEQUENCE_REORG, SRT_WSP_DT_LINK_API, SRT_WS_UPGRADE_SUPPRT_RFC, SYST, TASK_ADMIN, TASK_LUW, TASK_VITAL, WSRM_SOAP), RFC_TYPE = (FUGR)
• S_RFC_ADM with ACTVT = (01, 02, 03, 06), ICF_VALUE = ( * ) , RFCDEST = ( * ) , RFCTYPE =(G)
• S_SERVICE with SRV_NAME = ( * ) , SRV_TYPE = (WS)
• S_BTCH_EXT with ACTVT = ( * ) , USER = ( * )
• S_BTCH_JOB with JOBACTION = (* ) , JOBGROUP = ( * )
• S_SRT_CF_C with ACTVT = ( * ) , SRT_NAME = ( * )
• S_SRT_CF_P with ACTVT = ( * ) , SRT_NAME = ( * )
• S_SRT_DEST with ACTVT = ( * ) , SRT_NAME = ( * )
• S_SRT_ELOG with ACTVT = (03)
• S_SRT_PROF with ACTVT = ( * ) , SRT_NAME = ( * )
• S_SRT_SCEN with ACTVT = ( * ) , SRT_NAME = ( * )
• S_SRT_UACC with ACTVT = ( * ) , SRT_NAME = ( * )

• S_SRT_UASG with ACTVT = ( * ) , SRT_NAME = ( * ) , SRT_NAME2 = ( * )

   The system user SAP_WSRT with the necessary role in NetWeaver 7.40

   

  Back to top

The Service Destination

The service destination is needed to perform background activities for a specific tenant/client. The service destination is required for tenant/client 000 (as a system service destination), if web services are used in a system. Furthermore it is required for each tenant/client where web services are used. Each service destination has its own service user to logon to the teanant/client and execute a function module via CALL FUNCTION <fct> DESTINATION <service destination>. The list of function modules is restricted by the content of the function group names in the authority object S_RFC. A function module can not be executed if it is not on these list. The RFC destination has the following technical attributes:

Manual setup of the service destination

If the service destination is being set up manually, the user has to be created via transaction SU01 or by an external service (central user management). If one of the attributes shown is not taken into account, the service destination will be set to status “unusable” or “not operational”. Than – by using transaction SM59 - an RFC destination has to be created with the attributes shown above. To register this – customer specific - destination name the report SRT_ADMIN has to be called and the name out into field “Name of ABAP connection” of block “Manual Setup”. After the switch “Register ABAP Connection” has been set to ‘X’ a program run (F8) will register the destination at the runtime property.

The service destination for client 000 in NetWeaver 7.40 as shown in transaction SM59

Back to top

The bgRFC Inbound Destination

The Web service runtime uses the background RFC as scheduler for processing the web service messages. The bgRFC does need some settings to connect/register the web service runtime at the scheduling service. This is a) the bgRFC inbound destination and b) the scheduler destination for registration of the web service runtime check class. In Release 7.* there is only on inbound destination for each system necessary, in release 8.* for any client/tenant an inbound destination is required.

The bgRFC inbound destination has to be registered together with five different prefixes which are used to create bgRFC queue names. These prefixes are:

PERSC_    to build names for consumer queues for external persistent sequences

PERSP_    to build names for provider queues for external persistent sequences

SRTQC_   to build names for consumer queues for external transient sequences

SRTQP_    to build names for provider queues for external transient sequences

SRTQS_    to build names for queues for shortcut sequences

The name of the bgRFC inbound destination and its prefix set ups are registered via transaction SBGRFCCONF. After the inbound destination nad its prefixes has been registered at the bgRFC, the name of the inbound destination has to be registered at the web service runtime properties. Call report SRT_ADMIN and put the name into field “Name of inbound destination” flag the switch “Register name og inbound destination” to ‘X’ and execute the report (F8).

To supress the possibility to restart or delete unit’s of the web service runtime at the bgRFC Monitor (avoid inconsistencies between web service sequence handling and bgRFC queue/unit handling) register the name of the inbound destination at the bgRFC as an scheduler destination. Once added, use the class name “CL_SOAP_QUEUE_BGRFC_MON_CB” as an check class for the scheduler destination and set this name as “active”.

These settings for inbound destination and check class registration is processed automatically, if you use the automated set up procedure by report SRT_ADMIN.

The bgRFC supervisor destination

If the bgRFC has not been used before (the web service runtime is just one participant), the bgRFC supervisor destination has t be set up. This is also necessary, even if the web service runtime technical set up has been processed manually. The supervisor destination is maintained via transaction SBGRFCCONF in tab “Define Supervisor Dest.”. It requires a name and a user with assignment to role SAP_BC_BGRFC_SUPERVISOR. An automated set up is provided, where the user and the destination is created in background.

Idem Potency

See SAP Note 1097348

ICF nodes

The web service runtime needs to have some icfnodes in status activated. The names of this nodes are:

These nodes are generated and activated by report SRT_ADMIN when switching to “Manual Setup”, flag switch “Make Settings in Block “Web Service-Specific ICF Settings” to ‘X’ and run the report (F8).

Please also consider SAP Note 1043195.