Configuring Technical Settings (RCCF)

The DS optimizer is typically installed on separate hardware compared to the SAP S/4HANA system. The reason for this is that optimization requires a reasonable amount of computation power and this must not interfere with any processes running for users on the application server itself.

The current information related to the installation of PPO and DS optimization engines is always available in SAP Note 1686826. This note refers to the release-specific installation information and answers the most frequently asked questions around installation.

Before installation, you may be interested in sizing information to determine the right hardware. Sizing information is available in SAP Note 1577112.

Sizing an optimizer is different to well-known approaches, such as sizing a database, where you would, for example, only look at the data in the system and in the database itself. The optimizer sizing sheet estimates the memory consumption per optimization call. The total memory consumption per server is computed by summing up the estimated consumption of each run made in parallel. Generally speaking, the more you split up your scenario (in as many independent subscenarios as possible), the better the result.

Whereas the memory consumption can be derived from the scenario in a robust manner, there is no simple way to estimate the run time. The run time depends very much on details. Internally, each optimization run is a search process. It is very hard to estimate how long you must search until you find a pleasant answer. To give a rough estimation, the sizing sheet contains some input characteristic of productive customers classified by industry. For these examples, the sizing sheet reports their run time. So, you can compare your scenario to similar scenarios of your industry and their run times.

The technical framework that the optimizer runs in, is called the remote control and communication framework (RCCF). There are several transactions available that allow you to configure the optimizer and check the installation.

Transaction RCC_CUST defines the communication type and communication connection to the optimization server. For each destination, you can maintain a maximum number of available slots (Max. Slots). The maximum number of available slots defines a limit for the number of processes that the server can run in parallel for the defined optimization engine. Since each process occupies one CPU core, the maximum number of slots must be equivalent to the allocation that you have on your server. For example, if you want to run two DS optimizer calls in parallel and each call must run with two processes (tab Expert Settings in the optimization profile), you require four slots on the server.

If you use multiple optimization servers, it is important to define a Priority for each destination. The priority allows you to achieve a load balancing between different destinations. Before the optimization run is started, the application checks whether enough slots are currently available on the server. If there are no slots available, the application will check for the next server in sequence of the priority.

The RCC_SESSION transaction allows you to check whether any optimization calls are currently running on the optimization server. In case an optimization run was stuck, you can use this transaction to clear the session and release the slots reserved for this optimization call. To clean up any failed processes automatically, it is recommended to schedule the RCC_CLEANUP report to run daily.

Transaction RCC_VERSION can be used to check, which optimizer version is currently installed in your environment and whether the installation works fine.

For each optimization, run a log entry is created in the transaction RCC_LOG. The log entry can be associated with a specific optimization run by the date and time it was started, the user that has started the run, and the optimization profile that has been used. Should you require SAP support regarding optimization, it is beneficial if you can provide the information to which the optimization log your incident relates.

As a result of a support case, the optimizer logic can get adapted to your specific planning scenario. In general, this is avoided and the optimizer is typically run with a robust parameterization that fits to most customer scenarios. However, sometimes planning scenarios have very specific properties that require an adjustment of the optimizer. In this case, more parameters can be fed to the optimization call using transaction RCC_PARAM.