As the number of Web users increases, the ITS can be scaled accordingly. The ITS multi-tier architecture offers many options but also demands certain rules to be followed. Here we describe some of the mechanisms that can be used.

Availability is related to scalability, because in order to achieve high availability of your ITS service you avoid situations where the failure of a single component brings down the entire system. This means that you need at least two separate ITS instances. Availability issues are discussed briefly where applicable.

The CPU load on the WGate computer depends mostly on the Web server program, because the WGate processes no data and consumes few CPU resources. For this reason the CGI WGate should not be used for high performance ITS applications. As a general rule, the computer running the Web server and WGate has much less CPU load than the one running the AGate. Of course, if the Web server runs other applications apart from SAP Internet Applications Components, no general statement can be made.

Also note that this statement only holds for the ISAPI and NSAPI Web server extensions. If the CGI WGate is used, the system load used to start a new WGate executable program for every request is very high and exceeds by far the load of the WGate itself.

The AGate performs the actual processing of the Internet Application Components. For that it has to parse Web requests, merge data into SAP screens, open connections and issue requests to the SAP system, interpret and merge HTML templates and other resource files and generate new HTML pages. These tasks can be quite time consuming.

Consult the SAP hardware partners for detailed sizing information.

Multiple WGates running on separate Web server computers can access a single AGate. This is possible because for every request the WGate opens a connection to the AGate. The AGate sends the answer back to the WGate by using the same connection.

Conceptually, when multiple WGates are connected to a single AGate, all belong to the same ITS instance. This can be useful if one ITS serves different networks simultaneously, for example, the Internet and your corporate intranet. The setup is shown in the following diagram:

If a single AGate machine is not capable of handling all ITS users, multiple AGate computers have to be used. In this way ITS applications can be scaled almost without limit, provided the SAP system is able to handle the load.

For every AGate computer a separate Web server is necessary, because currently the WGate can only communicate with one AGate. It can not distribute requests among different AGate computers. The Web servers are accessed by different IP addresses (if located on separate computers) or port numbers or IP names (if you use multiple Web servers on one computer). In order to give the user a single access point, a method must be implemented to distribute incoming requests among these Web servers.

There is one important requirement for this load distribution mechanism: It must make sure that the requests from one user are always directed to the same Web server where he or she started the session. This is necessary because the AGate keeps the state of a user session (for example, login data and the state of the SAP transaction) in the memory. If a subsequent request were routed to a different Web server (see dotted arrows in the figure below), it would end up at an AGate that does not have any information about the session. This would result in an error message.

Most Web services are stateless, in contrast to the ITS. Many products that offer load balancing are not able to handle Web applications with a state. When you plan a large ITS service, make sure to select a technology that works with the ITS. The following sections discuss the options for achieving load balancing that fulfils the ITS requirement.

Another reason for using multiple ITS instances is to increase the availability of the service in case some components fail. We will also discuss the aspect of availability of the different methods.

Round Robin DNS is an easy solution for achieving a limited form of load balancing for network services. The Domain Name System (DNS) is used to map the name of a server to an IP address. Round Robin DNS maps DNS requests to a defined set of IP addresses belonging to the available Web servers in a round robin fashion.

Round Robin DNS works for the ITS because the client makes only one request for the first connection and keeps this information in memory for a time which is typically longer than the duration of a user session. In the event of server failure, a method has to be set up to remove this server from the DNS. Clients will still try to connect to the failed server until the DNS information has timed out on the client machine. In the mean time the clients have no way to connect to the service. Round Robin DNS has no method of performing intelligent load balancing.

One Web server can be used to distribute requests among a set of other Web servers. To do this, users do not call the WGate URL directly but rather issue a request for a CGI program on the Web server. For this, a separate server or one of the WGate servers can be used. The CGI program redirects the request to one of the WGate services. A simple load distribution scheme would be to choose all available WGate servers in a round robin fashion. A more elaborate redirection program could check the availability and load situation of the servers periodically and select the server accordingly.

Redirections are supported by all modern Web browsers. It works transparently to the user in the following way: The browser makes a request to server A. Server A sends a response with a header that contains a redirection for example to server Y. When the browser receives this response it automatically repeats the request, but now to server Y, which in this case would be a WGate server.

The following graphic illustrates the procedure:

The disadvantage of this technique is that the URL displayed in the browser shows that redirection took place. Some users may create bookmarks on a transaction they use frequently and thus undermine the load balancing. To a certain degree this problem can be overcome by use of frames which hide the URL by which the ITS service is called.

Multiplexing requests from one IP address to the servers overcomes this disadvantage, because it is completely transparent to the user. This can be realized by a network device that offers load distribution between the Web servers, for example a programmable router or a special multiplexer device.

If you are going to implement this technique you have to make sure that the device that handles network load balancing is able to fulfil the ITS state requirement described above. One option is to route incoming requests based on the IP address of the client. Another criterion for selecting a product is the ability to allow intelligent schemes for load balancing and high availability.

The following graphic illustrates the technique. To the outside world, the multiplexer has the IP address A. It forwards IP packets to the Web servers X and Y which are completely hidden to the outside world.

The load that Internet Application Components impose on the SAP system is comparable to that of ordinary SAP Transactions. As in the case of normal SAP Transactions the load determines the response time of the system. Formal sizing tests are conducted by the SAP partners.

ITS supports the normal SAP load balancing mechanism which uses the SAP Message Server to distribute the load between multiple SAP application servers. You should set up a separate logon group for Web access which is restricted to a set of application servers. This way you can protect internal users from possible overload from the Internet.

Offering a service in the Internet can lead to problems not usually present in ERP systems. One is that the number of potential users on the Internet is very large and the number of persons that actually use your service may vary quickly. To protect an internal productive SAP System from possible overload from the Internet, we recommend that you use a special login group for Internet access and restrict this login group to a subset of the Application servers.