When an SAP NetWeaver AS instance is started anywhere in an SAP system, an entry is made in the table RFCDES with its application server name in the usual format <hostname>_<SID>_<NR>. The table RFCDES is used to store possible logical destinations for RFC calls. The instances within the same SAP system are also called internal RFC destinations.
The application server is used directly for RFC addressing. If configured correctly, the application server name is <virtual hostname>_<SID>_<NR> and virtual addressing provides transparent addressing for RFCs in all switchover situations.
The table RFCDES has the following fields:
? RFCDEST contains a unique name for the logical destination.
? RFCTYPE contains the destination type:
0 I for internal – same SAP system
0 3 for external SAP system
0 2 for external R/2 system
0 T for TCP/IP connections, and so on.
? RFCOPTIONS contains additional information, dependent on the type.
For internal (RFCTYPE=I) destination calls within the same SAP system, RFCOPTIONS contains the IP address or host name and service number of the instance that is to be called. For an internal destination, the RFCDEST field is parsed for the address information before looking into the RFCOPTIONS field. Therefore, the address information in the RFCDEST field overrides the RFCOPTIONS field. Accordingly, in a switchover environment the RFCDEST field should contain <virtual hostname>_<SID>_<NR>.
To access different, external SAP systems, another type of logical RFC destination is used, RFCTYPE=3.
You can choose between addressing a specified host machine directly or with load balancing, where the SAP system chooses the host itself. If you select load balancing in transaction SM59, you do not need to enter a host name as described above – this is the recommended configuration. The procedure for choosing a host is similar to that for logon load balancing where the list of hosts on the message server is accessed.
In the Computing Center Management System (CCMS) you can define operation modes for AS instances. An operation mode defines a resource configuration for the instances in your SAP system. It can be used to specify which instances are started or stopped and how the individual services are allocated to each instance in the configuration. An instance definition for a particular operation mode consists of the number and types of work processes as well as start and instance profiles. CCMS lets you perform profile maintenance from the SAP system.
When you define an instance for an operation mode, you need to enter the host name and the system number of the application server. By using the virtual host name for the host name field, the instance can continue working under control of the CCMS after a switchover without requiring any changes.
If an AS instance is running on a standby node for a CI, DB, or CI/DB instance during normal operation, the AS is normally stopped when the CI or CI/DB is switched over. If so, the control console indicates that the AS instance is not functioning with a red light.
To maintain operation modes in a switchover environment proceed as follows:
? Use the CCMS transaction RZ04 to create operation modes and instances. First create a mode, for example, “Day” for daytime operation.
? After creating an operation mode, maintain the timetable for your modes by defining the time at which the mode is to be activated. When you define the instance, enter the virtual host name in the field host name.
It is difficult to give specific recommendations because the implementations for attaching services to sapcomm depend on the hardware chosen, which means they differ widely.
Attaching services like fax to the sapcomm process is similar to the procedure of attaching printers to the spool service. The basic methods of making a service more failure resilient are described above in the Spool Service and Batch Service.
SAProuter normally runs on a firewall machine:
? Firewalling provides security by protecting your host machines from direct access from the outside WAN for security reasons. Only the firewall machine is visible on the WAN.
? SAProuter allows network traffic for authorized SAP processes to go through the firewall by permitting:
0 WAN access from the SAP system to the outside network
0 Access to the local AS services, for example, front-end connects from the WAN
If the firewall machine running SAProuter fails, any WAN network traffic to or from the local SAP system is impossible.
For more information on SAProuter, see SAProuter.
You can use the following methods to make WAN access failure resilient in the SAP system:
? Provide redundant firewall machines. If the stationary firewall machine fails, reconfigure the standby to take over the task. In most cases it might be sufficient to prepare this takeover and for the administrator to execute it when it is actually needed.
? Provide two firewall machines and configure the SAP system to run one SAProuter process on each machine. If the first firewall crashes, currently active WAN access is interrupted, but can be restarted through the second firewall. Note that the second path must be defined and known to the outside world, that is, to external WAN users.
? If WAN access is vital for the continuation of business, use the standard switchover methods – identity takeover or virtual IP address takeover. In this case, you need to dedicate an entire switchover cluster to the WAN access service.
You might only be able to justify this option if you have very demanding WAN access requirements. Firewalling and switchover software might not be compatible for some products. Consult your switchover software vendor to find out how to best protect the firewall machine against failure.
For security reasons, we do not advise running the SAProuter on the normal instance cluster together with the CI on a CI switchover host. In this case the CI machine with SAP Web AS on it would be visible to the outside WAN. Remember that making AS instances invisible to the outside network was the primary reason for introducing a firewall in the first place.