SAP Dispatcher

 The SAP Dispatcher is a foundational component of every SAP application server instance. It acts as the central control program for an individual SAP instance, sitting between the clients (SAP GUI, web browsers, RFC calls) and the work processes. Its primary role is to manage and distribute incoming requests to the available work processes, ensuring efficient processing and overall system stability.

Think of the Dispatcher as a traffic controller for an SAP application server. It receives all incoming requests, puts them into a queue, and then assigns them to the appropriate type of work process that is currently free.

---

Key Roles of the SAP Dispatcher:

1. Request Distribution (Load Balancing within an Instance):

   • The Dispatcher receives all incoming requests (from SAP GUI, RFC, HTTP/HTTPS).
   • It places these requests into a dispatcher queue.
   • It then distributes these requests to the available work processes (dialog, background, update, spool) based on their type and availability, following a specific algorithm (e.g., round-robin, shortest queue).
   • This ensures optimal utilization of work processes and prevents any single work process from becoming overloaded.

2. Work Process Management:

   • The Dispatcher starts, stops, and monitors the work processes (WP) of its instance.
   • If a work process terminates abnormally, the Dispatcher automatically restarts it.
   • It manages the number and type of work processes based on the instance profile parameters.

3. Communication with Message Server:

   • Each Dispatcher registers its instance with the central Message Server.
   • It provides information about its instance's capabilities (e.g., number of dialog work processes, current load) to the Message Server, which uses this information for system-wide load balancing (when users connect via logon groups).

4. Buffer Management:

   • Manages the shared memory buffers used by the instance (e.g., program buffer, CUA buffer, screen buffer, table buffers). This reduces database access and improves performance.

5. Gateway Integration:

   • It communicates with the SAP Gateway process (if running on the same instance) to handle RFC requests.

6. Internet Communication Manager (ICM) Integration:

   • If the instance handles HTTP/HTTPS communication (e.g., for Web Dynpro, BSP, Fiori), the Dispatcher works closely with the Internet Communication Manager (ICM) process, which is responsible for managing internet requests.

---

Dispatcher Configuration in SAP Basis (Profile Parameters)

The Dispatcher's behavior is primarily controlled by parameters in the Instance Profile (managed via RZ10, displayed via RZ11). These parameters determine the number of work processes, memory allocation, timeouts, and other operational aspects.

Key Profile Parameters related to the Dispatcher and Work Processes:

1. rdisp/wp_no_dia:

   • Purpose: Defines the number of dialog work processes.
   • Value: Integer (e.g., 10).
   • Criticality: Crucial for interactive user performance. Too few can lead to long response times.

2. rdisp/wp_no_btc:

   • Purpose: Defines the number of background work processes.
   • Value: Integer (e.g., 4).
   • Criticality: Important for batch job execution.

3. rdisp/wp_no_upd:

   • Purpose: Defines the number of update work processes.
   • Value: Integer (e.g., 2).
   • Criticality: Essential for transactional integrity (LUW - Logical Unit of Work).

4. rdisp/wp_no_enq:

   • Purpose: Defines the number of enqueue work processes.
   • Value: Usually 1 on the Central Instance (or ASCS instance) that runs the Enqueue Server. Other instances have 0.
   • Criticality: Manages the SAP lock table, critical for data consistency.

5. rdisp/wp_no_spo:

   • Purpose: Defines the number of spool work processes.
   • Value: Integer (e.g., 1).
   • Criticality: Handles print requests.

6. rdisp/max_wprun_time:

   • Purpose: Maximum runtime (in seconds) for a dialog work process. If a dialog process runs longer than this, it's typically terminated.
   • Value: Integer (e.g., 600 seconds = 10 minutes).
   • Criticality: Prevents long-running dialog programs from monopolizing work processes. Set carefully, as legitimate long-running reports might be terminated.

7. rdisp/auto_logout:

   • Purpose: Automatic logout time (in seconds) for inactive SAP GUI users.
   • Value: Integer (e.g., 1800 seconds = 30 minutes).
   • Criticality: Security and resource management.

8. rdisp/mshost and rdisp/msserv:

   • Purpose: While these define the Message Server, they are crucial for the Dispatcher to register itself and communicate with the Message Server for system-wide load balancing.
   • Location: Typically in DEFAULT.PFL, but Dispatcher reads them from the effective profile.

9. rdisp/frun_time:

   • Purpose: Maximum time (in seconds) that a work process can be occupied by a single ABAP statement.
   • Value: Integer (e.g., 300).
   • Criticality: Prevents infinite loops or extremely long-running database queries from blocking a work process indefinitely.

10. Memory Parameters (e.g., abap/heap_area_dia, em/initial_size_MB, ztta/roll_area):

    • Purpose: Control how the Dispatcher allocates memory to work processes and overall instance memory.
    • Criticality: Misconfiguration leads to memory dumps (TSV_TNEW_PAGE_ALLOC_FAILED), system instability, and poor performance.

11. rdisp/wp_check_each_dia_inst:

    • Purpose: (Advanced) If set to 1, the dispatcher checks the load on other instances before dispatching a dialog request, even if logon groups are not used.

Configuration in RZ10 (Instance Profile):

1. Select the Instance Profile for the specific application server.
2. Go into Extended maintenance and Change mode.
3. Add/Modify the parameters as required.
4. Save and Activate the profile.
5. Restart the SAP instance for the changes to take effect.

---

Monitoring the Dispatcher and Work Processes (SM50, SM66, DPmon)

1. SM50 (Work Process Overview):

   • This is the most frequently used transaction for Dispatcher and Work Process monitoring.
   • It shows the status of all work processes within the current instance (running, waiting, hold, stopped).
   • You can see the process ID (PID), status, user, client, report, CPU time, and more.
   • From here, you can debug a work process, restart it, or check its trace file (dev_w<XX>).

2. SM66 (Global Work Process Overview):

   • Provides a consolidated view of all work processes across all active application servers in the SAP system.
   • Useful for identifying bottlenecks or issues system-wide.

3. DPmon (Dispatcher Monitor - OS Level):

   • A command-line tool (dpmon pf=<profile_path>) executed at the operating system level (as <sid>adm user).
   • It provides detailed real-time information about the Dispatcher, its queues, and work processes, even if the SAP GUI is not available.
   • Crucial for troubleshooting instance startup issues.

4. dev_disp (Dispatcher Trace File):

   • Located in the instance's work directory (/usr/sap/<SID>/<Instance>/work).
   • This file logs all Dispatcher activities, including work process startups/shutdowns, request handling, and errors.
   • First place to check when an instance fails to start or the Dispatcher is behaving erratically.

5. dev_w<XX> (Work Process Trace Files):

   • One file per work process (dev_w0, dev_w1, etc.).
   • Located in the instance's work directory.
   • Contains detailed logs of what each work process is executing.
   • Essential for debugging ABAP runtime errors, RFC issues, or database connectivity problems within a specific work process.

---

Common Dispatcher Issues and Troubleshooting Steps:

1. Issue: SAP Instance Fails to Start (Dispatcher not running).

   • Reason: Incorrect profile parameters, missing executables, port conflicts, shared memory issues, OS-level problems.
   • Troubleshoot:
     • dev_disp trace file: This is the most important file. Check it for the very first error message. Look for keywords like "FATAL," "ERROR," "abort," "failed," "exit."
     • OS Level: Ensure the sapstartsrv service (responsible for starting SAP) is running.
     • System Logs (OS): Check OS system logs (e.g., dmesg, /var/log/messages on Linux, Event Viewer on Windows) for resource issues or errors.
     • Memory: Check if enough physical RAM and swap space are available on the server.
     • Port Conflicts: Use netstat -an | grep <port> (Unix/Linux) or netstat -ano | findstr <port> (Windows) to see if port 32NN (where NN is instance number, the Dispatcher's default port) is already in use.
     • Profile Parameters: Verify critical parameters in the instance profile (RZ10) for correctness (e.g., DIR_CT_RUN, DIR_EXE).

2. Issue: "No more work processes available" or "Dispatcher shutdown due to no free work processes."

   • Reason: All work processes are busy, often due to long-running dialog processes, stuck background jobs, or database issues.
   • Troubleshoot:
     • SM50/SM66: Identify which work processes are occupied. Look for long-running reports, specific users, or "On Hold" statuses.
     • ST22: Check for ABAP dumps that might indicate a program error or resource issue.
     • DB02/DB01: Check database performance and for any database deadlocks or blocks.
     • Memory Parameters: Ensure memory parameters are sufficient for the workload.
     • Adjust rdisp/wp_no_dia / rdisp/max_wprun_time: Increase number of dialog WPs or reduce max runtime (but be careful not to terminate legitimate processes).

3. Issue: High CPU/Memory Utilization by Dispatcher or Work Processes.

   • Reason: Inefficient ABAP programs, large data volumes, incorrect buffer sizes, database performance issues.
   • Troubleshoot:
     • SM50/SM66: Identify the work processes consuming high CPU/memory. Note the user, client, and report.
     • ST03N (Workload Analysis): Analyze transaction and program workload to find performance bottlenecks.
     • ST02 (Buffer Monitor): Check buffer hit ratios. If they are low, increase relevant buffer parameters in the instance profile (e.g., Program buffer rsdb/obj/max_objects, abap/buffersize).
     • Memory Dumps (ST22): Look for memory-related dumps.
     • dev_w<XX> traces: Check the trace files of the high-consuming work processes for detailed activity.
     • DB02 (Database Performance): Check database performance and resource utilization.

4. Issue: Users getting "time limit exceeded" errors.

   • Reason: rdisp/max_wprun_time is too low for certain transactions or reports.
   • Troubleshoot:
     • SM50/SM66: Confirm if the work process was indeed terminated due to reaching max_wprun_time.
     • Analyze Report: Evaluate if the report genuinely needs more time.
     • Increase rdisp/max_wprun_time: Only if necessary and with caution. Alternatively, advise users to run the report in the background (which uses background work processes and is not subject to max_wprun_time).

By diligently monitoring the Dispatcher and work processes and understanding their configuration, Basis administrators can maintain the health and performance of their SAP application servers.