Design and configuration of SAP Basis

 Designing an SAP BASIS system and understanding its critical configurations is fundamental to ensuring the stability, performance, security, and scalability of an entire SAP landscape.¹ It's not just about installing software; it's about architecting a robust foundation for business operations.

Let's break down the design principles and critical configurations in detail.

Design of an SAP BASIS System

The design of an SAP BASIS system revolves around creating an efficient, reliable, and secure SAP landscape. An SAP landscape is a set of interconnected SAP systems that support the full lifecycle of an application, from development to production.²

1. The Multi-Tier Architecture (The Fundamental Building Block):

While we've discussed this before, it's the core design principle. Each layer can be scaled and managed independently, offering:

• Presentation Layer: User interface (SAP GUI, Fiori, Web browsers).³ Designed for user interaction and minimal processing.
• Application Layer: Business logic, work processes, and services (Dispatcher, Message Server, Gateway).⁴ Designed for high throughput and processing of business transactions. Multiple application servers are common for load balancing and high availability.⁵
• Database Layer: Data storage (SAP HANA, Oracle, SQL Server, etc.). Designed for data persistence, integrity, and fast retrieval.

2. The SAP Landscape Strategy (The Blueprint for Change Management):

A well-designed SAP landscape is crucial for managing changes, ensuring quality, and minimizing risk to the production environment.6 The most common landscape is a 3-system landscape, but variations exist.7

• Development System (DEV):
  • Purpose: The environment where all new SAP functionalities, configurations (customizing), and ABAP developments are initially created and unit-tested.
  • Clients: Typically has multiple clients.
    • Customizing Client (Golden Client): Where configuration settings are made and transported.
    • Sandbox Client: For experimental development or training without impacting core configurations.
  • Key Design Considerations: Must have sufficient resources for developers, version control is critical (managed via Transport Organizer).
• Quality Assurance System (QAS) / Test System:
  • Purpose: A replica of the production system (or as close as possible) used for comprehensive testing, including integration testing, system integration testing (SIT), and user acceptance testing (UAT).
  • Clients: Often multiple clients for different test cycles or specific test data sets.
  • Key Design Considerations: Regular "client copies" or "system refreshes" from Production are vital to ensure realistic test data and environment. Performance testing might also be conducted here.
• Production System (PRD):
  • Purpose: The live system where actual business operations are performed. All business-critical transactions and data reside here.
  • Clients: Usually a single client where all live data and transactions occur.
  • Key Design Considerations: Highest priority for stability, performance, security, and high availability. Minimal direct changes are allowed; all changes must pass through DEV and QAS via transports.
• Other Common Systems (Depending on Business Needs):
  • Sandbox System (SBX): Completely isolated for experimentation, training, or proof-of-concept. No transport connectivity to the main landscape.
  • Pre-Production System (PRE): An exact clone of PRD, used for final dress rehearsals, critical patching, or performance tuning before actual deployment to PRD.
  • Training System (TRN): Dedicated for end-user training. Often refreshed with production data or specific training scenarios.
  • SAP Solution Manager (SOLMAN): A central system for managing the entire SAP landscape.⁸ It's crucial for monitoring, change management (ChaRM), patching, and service desk functionalities. It typically connects to all other systems.

3. Transport Management System (TMS) Design:

• Central Component: STMS (Transaction STMS) is the heart of managing changes across the landscape.
• Transport Routes: Defining the precise path that changes take (e.g., DEV -> QAS -> PRD). This ensures changes are applied in the correct sequence.
• Transport Domain Controller: One system in the landscape (often DEV or SolMan) acts as the central controller for all transport-related activities.⁹
• Purpose: Enforces controlled change management, ensures consistency, provides an audit trail, and minimizes risks associated with direct modifications in productive environments.

4. High Availability (HA) and Disaster Recovery (DR) Design:

• HA (within a single data center): Focuses on minimizing downtime for planned and unplanned outages.
  • Redundant Application Servers: Multiple application servers per system, with load balancing (via Message Server and Logon Groups) to distribute user sessions.
  • Central Services Cluster: For the ABAP ASCS (ABAP SAP Central Services - contains Message Server and Enqueue Server) and ERS (Enqueue Replication Server).¹⁰ These are often clustered using OS-level clustering technologies (e.g., Microsoft Failover Cluster, Pacemaker for Linux) to provide automatic failover.
  • Database HA: Database-specific clustering or replication technologies (e.g., HANA System Replication, Oracle Data Guard, SQL Server AlwaysOn Availability Groups) to ensure continuous database availability.¹¹
• DR (across geographically separate data centers): Focuses on recovering the system in the event of a catastrophic failure at the primary data center.
  • Data Replication: Asynchronous replication of the database and shared file systems to a remote DR site.
  • DR Site Setup: A complete, ready-to-go SAP landscape at the DR site.
  • RTO (Recovery Time Objective) and RPO (Recovery Point Objective): Defined targets for how quickly the system must be restored and how much data loss is acceptable. These drive the choice of DR technologies.

5. Sizing and Performance Design:

• SAPS (SAP Application Performance Standard): A key metric used to estimate hardware requirements (CPU, memory, I/O) based on user numbers, transaction volumes, and data growth.¹²
• Initial Sizing: Uses tools like SAP Quick Sizer based on business processes and user profiles.¹³
• Ongoing Monitoring & Tuning: Design incorporates robust monitoring tools (SAP CCMS, Solution Manager, OS-level tools, database-specific tools) to track performance and identify bottlenecks. This informs continuous optimization.

6. Security Design:

• Segregation of Duties (SoD): Designing roles and authorizations to prevent a single individual from performing conflicting critical business functions. This requires close collaboration with business process owners.
• Role-Based Access Control (RBAC): Users are assigned to roles, and roles are granted specific authorizations, ensuring users only have access to what they need for their job function.¹⁴
• Network Security: Implementing firewalls, network segmentation (e.g., placing the database on a separate secure subnet), and secure communication protocols (HTTPS, SNC for RFC).
• Vulnerability Management: Regular security audits, patch management, and adherence to SAP security best practices.¹⁵

Critical SAP System Configurations

These are the core settings that a BASIS administrator directly configures and manages, often using specific SAP transaction codes or at the operating system level.

1. Profile Parameters (Instance and Default Profiles):

These are text files (instance.pfl, default.pfl) that control the behavior of the SAP kernel and work processes.16 Incorrect settings here can severely impact performance or lead to system instability.

• Memory Management:
  • ztta/roll_area, rdisp/ROLL_SHM, rdisp/ROLL_MAXFS: Control roll memory (user context data).¹⁷
  • em/initial_size_MB, em/max_size_MB: Size of Extended Memory (main memory for user contexts).¹⁸
  • abap/heap_area_total, abap/heap_area_dia, abap/heap_area_nondia: Control ABAP Heap Memory (private memory for specific processes).¹⁹
• Work Process Configuration:
  • rdisp/wp_no_dia, rdisp/wp_no_btc, rdisp/wp_no_upd, rdisp/wp_no_enq, rdisp/wp_no_spo: Define the number of each type of work process.²⁰ Crucial for matching system capacity to workload.
• Buffer Sizes:
  • abap/buffersize: Size of the ABAP program buffer.²¹
  • rsdb/cua/buffersize: CUA buffer for user interface elements.²²
  • rtbb/buffer_length: Table buffer.²³
  • Properly sized buffers reduce database load and improve response times.
• Logging and Tracing:
  • rsau/enable = 1: Enables the Security Audit Log (SM20).²⁴
  • rstr/monitor_mode: Controls monitoring behavior.
• Security Parameters:
  • login/no_automatic_user_sapstar = 1: Prevents automatic login of SAP* user after a clean client.²⁵ CRITICAL SECURITY SETTING.
  • login/min_password_lng, login/password_history_size, login/fails_to_lock: Password policy parameters.²⁶
  • login/system_client: Forces users to log into a specific client initially.

2. Client Administration (Transaction SCC4):

• Client Definition: Creating new clients with unique numbers (e.g., 100, 200, 800).
• Client Role: Assigning a role (e.g., 'Production', 'Customizing', 'Test') which determines default settings and behavior.
• Changes and Transports for Client-Specific Objects: Defines if changes are allowed directly (Changes without automatic recording, No changes allowed) or must be transported (Changes are allowed, no transports allowed). For production clients, this is almost always set to No changes allowed.
• Cross-Client Object Changes: Controls changes to objects affecting all clients (e.g., logical systems, global settings).²⁷ Also usually set to No changes allowed for production.
• Protection Level: Crucial for preventing accidental client overwrites during client copies. Setting to Protection: No Overwriting for production clients is highly recommended.

3. User and Authorization Management (Transactions SU01, PFCG):

• User Master Records (SU01): Creation, modification, locking/unlocking of individual user accounts.²⁸
• Roles (PFCG): The definition and maintenance of authorization roles.²⁹ This involves:
  • Adding Authorization Objects with specific field values (e.g., object S_TCODE for transaction codes, S_RFC for RFC function modules, S_TABU_DIS for table access).
  • Generating Authorization Profiles from roles.
  • Assigning roles to users.
• Authorization Concept: Implementing a well-defined authorization concept is paramount for security and compliance. This prevents unauthorized access to sensitive data and functions.

4. Transport Management System (TMS - Transaction STMS):

• TMS Domain Configuration: Setting up the central TMS domain controller and integrating all systems into it.³⁰
• Transport Routes (STMS_PATHS): Defining the consolidation routes (e.g., DEV to QAS) and delivery routes (e.g., QAS to PRD) for transport layers.³¹
• Import Strategy: Configuring how transports are imported into target systems (e.g., "Import All" for daily mass imports, "Single Import" for emergency transports).³²
• Background Jobs: Scheduling regular background jobs for TMS (e.g., RDDIMPDP for automated import processing).

5. Database Administration (DBACockpit, DB02, DB13):

• Tablespace Management: Monitoring free space, extending tablespaces, and reorganizing database objects to ensure optimal performance and prevent outages due to full tablespaces.
• Backup Strategy: Scheduling and monitoring database backups (full, incremental, differential) and ensuring offsite storage.³³ Absolutely critical for disaster recovery.
• Restore/Recovery Testing: Regularly testing database restores to validate the backup strategy.
• Database Parameters: Tuning database-specific parameters for memory allocation, buffer sizes, and I/O.
• Database Statistics: Ensuring database optimizer statistics are up-to-date to allow the database to create efficient execution plans for queries.

6. Spool and Print Administration (SPAD):

• Printer Definitions: Configuring output devices (printers) in SAP, including access methods (e.g., L: Local, U: UNIX, C: Windows UNC).³⁴
• Spool Servers: Assigning output devices to specific application servers as spool servers for load balancing.
• Spool Retention: Configuring how long spool requests are kept in the system.

7. System Monitoring and Alerting (Solution Manager, RZ20, SM21, ST22, ST03N, SM50):

• Configuring Alerts: Setting up alerts for critical system events (e.g., file system full, work process restarts, database errors, ABAP dumps).³⁵
• Central Monitoring (CCMS/Solution Manager): Integrating systems into a central monitoring tool for a holistic view of the landscape's health.³⁶
• Logs and Dumps: Regular review of system logs (SM21), short dumps (ST22), and developer traces for proactive issue identification.

8. RFC Connections (SM59):

• Defining RFC Destinations: Configuring connections between SAP systems (e.g., for TMS, Solution Manager, ALE/IDoc communication) and external systems.³⁷
• Security: Ensuring secure RFC communication using SNC (Secure Network Communications) where possible.
• Authorizations: Ensuring the RFC user has only the necessary authorizations in the target system.

In summary, the design of an SAP BASIS system is a strategic undertaking that lays the groundwork for the entire SAP implementation. The critical configurations are the tactical levers that BASIS administrators use daily to ensure this foundation is stable, performant, secure, and aligned with the business's operational needs.