Update Dispatching with Load Distribution (SAP Library - Updates in the SAP System (BC-CST-UP))

Update Dispatching with Load Distribution

Several update servers can offer update services in an SAP system. In this case, the SAP system automatically distributes the update requests among the available update servers using a process referred to as update dispatching.

Update processing is triggered by a request from the dialog server on which the update was generated. This request is sent to a specific update server. The dialog server thus decides which update server is to be used for a particular update.

Load distribution is based on a list of the available update servers. This list is stored on each application server and is automatically updated by the message server when a server is started or stopped, or when its configuration changes as a result of a new operation mode being set. You can display this list by choosing Display server.

If there is more than one possible update server for processing an update record, the dialog server selects the server to be used on the basis of a load distribution algorithm.

This load distribution algorithm cyclically assigns update records to the update servers. A server sends update requests consecutively to each update server. If the number of requests sent is the same as the number of update work processes on an update server, the server is removed from the list until the start of the next cycle. Once all of the update work processes have been assigned update requests in this way in the SAP system, the cycle starts again and with all of the update servers.

If a V2 work process Upd2 has been defined, V2 update modules can only be processed by this work process.

If there are no V2 work processes, V2 updates are processed in V1 work processes. A V2 component must, however, wait until all of the V1 update requests have been processed.

The following example illustrates the load distribution algorithm:

Example

This graphic is explained in the accompanying text

Two work processes run on update server 1 for V1 update modules. Update server 2 has one V1 and one V2 update work process. A load distribution cycle for V1 updates, therefore, comprises three update requests. These are distributed as follows:

The first and second update request are sent to update server 1 (number of requests = number of V1 update work processes * rdisp/vb_factor parameter (default value 1; see also Additional System Profile Parameters). Setting the parameter to a value other than 1 is advantageous if an update server is significantly faster and is, therefore, to be assigned more update requests.

The update system chooses update server 2 for the third request. The load distribution cycle is then complete (number of assigned updates = number of update work processes).

V1 update request 4 is sent to update server 1 again and the cycle is repeated.

V2 updates are processed consecutively by the V2 work process.

Reassignment in the Event of an Update Server Failure

If, for some reason, an update server fails, the other update servers in the system perform any updates that the defective server was not able to handle.

If an update server is shut down, for example, the SAP message server establishes that the server is not available on the basis of an error message regarding the missing server connection or on account of the connection checks, which are carried out at regular intervals.

Once the message server has been informed of this, it updates the list of application servers and associated services, and distributes the list to the other application servers.

The first update server on the list automatically assumes responsibility for distributing the update requests of the defective server on the basis of the dynamic update assignment criteria described above.