SAP BASIS

REAL-TIME SCENARIOS
50 Complete Scenarios with Expert Explanations

For Experienced SAP Basis Consultants

System Admin | Security | Performance | Transport | DR | S/4HANA
RFC | IDocs | Fiori | BTP | HANA | Cloud Connector

Interview Preparation & On-the-Job Reference Guide

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 1 of 47

About This Document
This comprehensive guide covers 50 real-time SAP Basis scenarios encountered in enterprise
SAP implementations, support projects, and senior-level technical interviews. Each scenario
describes a real business or technical challenge followed by a detailed, step-by-step resolution
with commands, T-codes, and best practices.

Topics Covered
Chapter 1: System Administration & Landscape Management
Chapter 2: User Administration & Security
Chapter 3: Background Jobs & Batch Processing
Chapter 4: Performance Monitoring & Tuning
Chapter 5: System Maintenance & Patching
Chapter 6: RFC, Interfaces & Integration
Chapter 7: High Availability, DR & System Operations
Chapter 8: Advanced Topics (Fiori, CCMS, Archiving, SolMan, BTP)
Chapter 9: Advanced Scenarios (S/4HANA Migration, Sizing, Emergency Transports)
Chapter 10: Top Interview Questions & Complete T-Code Reference

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 2 of 47

Chapter 1: System Administration & Landscape
Management
Scenario 1: SAP System Landscape: DEV-QAS-PRD Setup
Q: Your client is setting up a new SAP implementation. Management wants to understand the
recommended three-system landscape. Explain the architecture, purpose of each system, and
how transports flow between them.
Answer & Explanation:
A three-system SAP landscape is the industry standard for enterprise SAP implementations. It provides
clear separation between development, testing, and production activities.
System Landscape Architecture:
DEV (Development System): The sandbox where all configuration, customization, and ABAP development
occurs. Each functional consultant and developer works here. Multiple clients are maintained: 000 (Master),
001 (Template), 100 (Development), 200 (Sandbox). Changes are captured in Workbench and Customizing
Requests via the Change and Transport System (CTS).
QAS (Quality Assurance / Testing System): All transport requests from DEV are imported here first.
Functional testing, integration testing, user acceptance testing (UAT), and regression testing happen in
QAS. This system mirrors PRD in terms of configuration. No direct development is allowed. Business users
and test teams access this system.
PRD (Production System): The live system used by end users for actual business operations. Only fully
tested and approved transports are imported here. Access is strictly controlled. No development or direct
configuration changes are allowed. High availability (HA) and disaster recovery (DR) measures are active.
Transport Flow (CTS - Change and Transport System): DEV --> QAS --> PRD
Steps: 1. Developer/Consultant makes changes in DEV. The system automatically records changes in a
Transport Request (TR). 2. TR is released in SE10 by the developer/consultant. 3. Basis team exports the
TR: tp export <TR_number> <SID> (or via STMS). 4. TR is imported into QAS via STMS (Transport
Management System). 5. Testing completed and signed off in QAS. 6. Basis team imports TR into PRD via
STMS, typically during a maintenance window.
STMS Configuration (Transaction STMS): - Domain Controller: One system manages the entire transport
domain (usually DEV). - Transport Routes: Configured as consolidation route (DEV to QAS) and delivery
route (QAS to PRD). - Import Queues: Each system has an import queue. Basis reviews and imports from
here.
Key T-Codes: STMS, SE10, SE09, SCC4 (Client Administration), SCC8 (Client Export), SCC7 (Client
Import) Best Practice: Never import directly from DEV to PRD. Always follow the three-system path.
Use go-live checklists and change freeze periods before PRD imports.

Scenario 2: Client Administration and Client Copy

Q: A new project requires a fresh Quality Assurance client to be set up, refreshed from the
Production client. Walk through the client copy process in SAP Basis.
Answer & Explanation:
Client Copy is one of the most critical SAP Basis activities. It allows you to copy the configuration and/or
data from one client to another, within the same system or across systems.
Types of Client Copy:
1. Local Client Copy (SCCL): Copy within the same SAP system. Source and target client are on the same
server. Suitable for creating test clients from within the same system.
2. Remote Client Copy (SCC9): Copy from a source client in a remote SAP system to a target client in the
current system. Used to refresh QAS from PRD. Requires RFC connection (SM59).
3. Client Transport (SCC8 + SCC7): Export client data to a transport file and import it into another system.
Best for copying across a transport route where remote copy is too slow.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 3 of 47

Step-by-Step Remote Client Copy (SCC9) - Refreshing QAS from PRD:
Pre-requisites: - Target client must exist (create via SCC4 if needed). - RFC destination must be configured
pointing from QAS to PRD (SM59). - Sufficient disk space in target system. - All users in target client
should be locked. - Schedule during off-peak hours.
Steps: 1. Log into QAS system as Basis admin. 2. Transaction SCC4: Create target client (e.g., 300) if not
existing. Set client role to "Test". 3. Transaction SCC9: Start remote client copy. - Source Client: PRD client
number - Source System: PRD system ID (via RFC destination) - Profile: SAP_ALL (all data), SAP_CUST
(customizing only), SAP_APPL (application data) - Select profile: SAP_ALL for full refresh 4. The copy runs
in the background. Monitor via SCC3 (copy log). 5. After completion: Check SCC3 for errors. Perform post-
copy activities.
Post-Copy Activities: - Lock all copied production users (SU10 - mass user lock). - Change passwords for
service accounts. - Disable or reconfigure interfaces and IDocs. - Reconfigure background jobs (SM36) for
test environment. - Notify functional teams to re-test. - Adjust RFC destinations to point to test systems.
Key T-Codes: SCC4, SCCL, SCC9, SCC8, SCC7, SCC3 (Client Copy Log), SM59, SU10 Important:
Always lock production users immediately after a client copy to prevent test users from
accidentally accessing PRD-like data with incorrect passwords.

Scenario 3: Transport Management System (STMS) - Import Issues

Q: A transport request imported into QAS has failed with return code 8. The functional team is
waiting for the configuration to be available. How do you diagnose and resolve this?
Answer & Explanation:
Transport Return Codes in SAP indicate the severity of issues during import. Understanding these codes is
fundamental for SAP Basis consultants.
Return Code Reference: - RC 0: Successful, no warnings. - RC 4: Successful with warnings (usually safe to
proceed). - RC 8: Failed - errors occurred. Objects may not have been imported correctly. - RC 12: Serious
errors - import was aborted. - RC 16: Critical failure - major system issues.
Diagnosing RC 8 in STMS:
Step 1: View Transport Logs (STMS): - Go to STMS > Import Overview > Select system (QAS). - Find the
failed transport in the import queue. - Double-click to see the return code. - Click on the log icon to view
detailed import logs.
Step 2: Analyze Log Files: - Look for lines starting with 'E' (Error) or 'W' (Warning). - Common error types:
a. Object Locked: Another transport has the same object locked. b. Syntax Error: ABAP code has a syntax
error in target system. c. Missing Prerequisite: A dependent transport was not imported first. d. Activation
Error: Repository objects failed to activate. e. Database Error: Table does not exist or has a different
structure.
Step 3: Resolution Based on Error Type:
A) Missing Prerequisite Transport: - Check the transport's prerequisites in SE10 (source system). - Import
the missing prerequisite transport first. - Then re-import the failed transport.
B) Object Already in Another Request: - Check which transport has the object locked using SE03
(Transport Organizer Tools). - Coordinate with the team to release the conflicting transport.
C) Activation Errors: - In the target system, go to SE80 or SE11 to check the object. - Try to manually
activate the object (if ABAP, use SE38; if table, use SE11). - Check SE91 (message maintenance) for
specific error messages.
D) Re-Import: - In STMS > Import Queue > Select the failed TR > Re-import (unconditionally if needed). -
Use "Import all" option with caution; prefer individual re-import.
Additional Tools: - SE01/SE10: Transport Organizer - view request status, objects. - SE03: Transport
Organizer Tools - object search, unlock objects. - /nSE09: Workbench requests. /nSE10: Customizing
requests. - tp showlog <TR_number> <SID>: Command-line log viewing. - /usr/sap/trans/log/: OS-level
transport log directory.
Key T-Codes: STMS, SE10, SE03, SE38, SE11, SM21 (System Log) Best Practice: Always import
transports in the correct order. Maintain a transport log spreadsheet for large projects. Never skip
QAS testing by importing directly to PRD.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 4 of 47

 Scenario 4: System Log Analysis and Error Investigation
Q: End users are reporting intermittent performance issues and unexpected dumps in the
production system. As a Basis consultant, how do you systematically investigate using system
logs?
Answer & Explanation:
System Log and ABAP dumps analysis is a core daily activity for SAP Basis consultants. Multiple tools are
available for investigation.
Primary Investigation Tools:
1. SM21 - System Log: The system log records all system-level messages: errors, warnings, logons,
logoffs, crashes, and security events. - Go to SM21 > Select time range > Execute. - Filter by: Severity (E =
Error, W = Warning, I = Information), User, Terminal. - Look for: DIA (dialog work process errors), BGD
(background errors), UPD (update task errors), ENQ (lock service issues). - Common serious entries: Work
process restarts, database connection errors, memory exceeded.
2. ST22 - ABAP Runtime Error Dump Analysis: - ST22 shows all ABAP dumps (short dumps) - program
crashes with full diagnostic information. - Open ST22 > Select date/time/user > Analyze dump. - Key
information in dump: Error type (DBIF_RSQL_SQL_ERROR, MEMORY_NO_MORE_PAGING, etc.),
program name, include, line number, active call stack, system snapshot. - Resolution: Fix the ABAP code,
apply OSS notes, increase memory parameters, or fix data issues.
3. SM50 / SM66 - Work Process Monitor: - SM50: Work processes on current application server. - SM66:
Work processes across ALL application servers. - Check for: Processes in PRIV mode (hogging memory),
long-running jobs, deadlocks, processes waiting on locks. - Action: Kill hanging work processes if
necessary (right-click > Cancel with Core, or Cancel without Core).
4. AL11 - SAP Directory Browser: - Browse OS-level files including trace files. - Navigate to
/usr/sap/<SID>/D<xx>/work/ for work process trace files. - dev_w0, dev_w1... are work process trace files
with detailed error info.
5. SM13 - Update Records: - Check for failed update records (document postings that failed in the update
task). - Identify: user, transaction, error message. - Action: Inform users, fix the issue, and manually
reprocess or delete old update records.
6. DSWP / Solution Manager Alerts: In managed landscapes, check Solution Manager for centralized alerts
across all systems.
Performance Investigation Add-ons: - ST05: SQL Trace - trace database calls. - SM12: Lock Entries -
check for blocking locks. - AL08: All Logged-on Users - see who is active and consuming resources.
Key T-Codes: SM21, ST22, SM50, SM66, SM13, AL11, ST05, SM12, AL08 Best Practice: Set up
proactive monitoring using CCMS (RZ20) and configure email alerts for critical errors. Review SM21
and ST22 daily in production environments.

Scenario 5: SAP Instance and Profile Parameter Management

Q: After a system upgrade, users are experiencing memory errors
(MEMORY_NO_MORE_PAGING). You need to review and adjust instance profile parameters.
How do you do this safely in SAP?
Answer & Explanation:
SAP Profile Parameters control the behavior of the SAP instance, including memory allocation, work
process configuration, and buffer sizes. Incorrect parameter settings cause performance issues and system
instability.
SAP Profile Types: 1. [Link]: System-wide defaults, applies to all instances. 2. Instance Profile
(e.g., <SID>_DVEBMGS00_<hostname>): Instance-specific settings. Overrides [Link]. 3. Start
Profile: Controls how the SAP instance starts (mostly OS-level settings).
Investigating Memory Issues:
Step 1: Check Current Memory Settings (RZ11): - RZ11: Maintain Profile Parameters. - Enter parameter
name: abap/heap_area_total (total extended memory). - View current value, description, and allowed
ranges. - Key memory parameters: ztta/roll_area: Roll memory per work process. abap/heap_area_total:
Total heap memory for all work processes. abap/heap_area_dia: Heap memory per dialog work process.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 5 of 47

em/initial_size_MB: Extended memory (EM) size. phys_memsize: Physical memory size (auto-detected, do
not change).
Step 2: Review Parameter History (RZ10): - RZ10: Edit Profile Parameters. - Select profile type: Instance or
Default. - View all current parameter values. - Compare with SAP recommended values from OSS Note
88416.
Step 3: Making Changes Safely: 1. Go to RZ10: Select the instance profile. 2. Click 'Edit' - Extended
Maintenance. 3. Find the parameter to change (e.g., em/initial_size_MB). 4. Change value: Increase from,
say, 512 to 1024 (MB). 5. Save and ACTIVATE the profile (key step - activation writes to the file). 6. Restart
the instance for changes to take effect. 7. Monitor after restart: Check SM50 for work process stability and
AL08 for active users.
Important Memory Parameters for MEMORY_NO_MORE_PAGING: - Increase em/initial_size_MB:
Extended memory (primary fix). - Check abap/heap_area_total: If too small, program cannot allocate heap.
- ztta/roll_extension: Roll area extension per user. - Review OS swap space: Must be at least 2x physical
RAM.
Step 4: Dynamic Parameter Changes (No Restart): Some parameters can be changed dynamically without
restart: - RZ11: Find parameter > Check if dynamic change is supported. - If yes: Change in-memory profile
(takes effect immediately). - If no: Requires instance restart.
Key T-Codes: RZ10, RZ11, SM50, SM66, AL08, OS06 (OS monitor), ST06 (OS monitor) Rule of
Thumb: em/initial_size_MB should be ~40-60% of physical RAM. ztta/roll_area should be at least
4MB per expected concurrent users.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 6 of 47

Chapter 2: User Administration & Security
Scenario 6: User Creation, Roles, and Authorization Concepts
Q: A new finance manager has joined and needs access to run financial reports, post journal
entries, and view vendor master data in SAP. Walk through the complete user setup process.
Answer & Explanation:
SAP user administration is built on a role-based access control (RBAC) model. Authorization objects
control what users can see and do within SAP transactions.
SAP Authorization Concept: Authorization Check Flow: Transaction > Authorization Object > Authorization
Field Values > User Master > Profile > Role.
User Types in SAP: - Dialog (A): Normal interactive user. Subject to password policy and logon checks. -
System (B): For RFC/background jobs. No interactive logon. No password expiry. - Communication (C): For
RFC connections without dialog mode. - Service (S): Shared service accounts (e.g., internet users).
Minimal authorizations. - Reference (L): Template for creating other users. Cannot log in.
Step-by-Step User Creation (SU01): 1. Transaction SU01 > Create new user. 2. Address Tab: Full name,
department, email, telephone. 3. Logon Data Tab: - User Type: Dialog (A) for regular users. - Initial
Password: Set a temporary password. - Valid From/To: Set validity period. - Lock: Initial lock status. 4.
Roles Tab: - Assign composite roles or single roles. - For finance manager: SAP_FI_AP_ACCOUNTANT
(Accounts Payable), SAP_FI_AR_ACCOUNTANT (Accounts Receivable), custom Z_FI_REPORT_USER
role. 5. Profiles Tab: Profiles are automatically added when roles are assigned (via role's authorization
profile). 6. Parameters Tab: Set user-specific parameters (e.g., default plant, company code). 7. Save the
user.
Role Assignment and Authorization: - PFCG (Profile Generator): Create and manage roles. Single Role:
Contains specific transactions and authorization objects. Composite Role: Groups multiple single roles
together. - Creating a Role (PFCG): 1. Enter role name > Create. 2. Menu tab: Add transactions to role
menu. 3. Authorizations tab: Maintain authorization object field values. 4. User tab: Assign users to the role.
5. Generate the authorization profile (critical step).
For Finance Manager Access: - FBV2 (Post Parked Document): Needs authorization for F_BKPF_BUK
(company code) and activity 01. - FK03 (Display Vendor Master): F_LFA1_BUK with company code,
activity 03. - F.01 (Financial Statements): S_TCODE + report authorization objects.
Post Creation Steps: - SU53: Check failed authorization - user can use this to see which authorization
object caused an access denied. - SU24: Maintain check indicators for transactions (which auth objects to
check). - SUIM: User Information System - search users by role, profile, authorization value.
Key T-Codes: SU01, PFCG, SU10 (Mass user changes), SU53, SUIM, SU24, AGR_1251 (Role menu)

Scenario 7: Password Policy and Account Lockout Management

Q: Multiple users are locked out of SAP after entering wrong passwords. Your security policy
requires: minimum 8 characters, at least one uppercase, one number, password expires every
90 days. How do you configure and manage this?
Answer & Explanation:
SAP password policies are configured via profile parameters and are critical for security compliance (SOX,
GDPR, ISO 27001).
Password Policy Configuration (RZ10 or RZ11):
Key Profile Parameters for Password Policy: login/min_password_lng: Minimum password length. Set to 8.
login/password_expiration_time: Days until password expires. Set to 90. login/password_max_new_digits:
Maximum number of digits allowed. login/password_max_new_letters: Maximum letters.
login/password_change_waittime: Days before a changed password can be changed again.
login/password_history_size: Number of previous passwords stored (prevents reuse). Set to 5-10.
login/failed_user_auto_unlock: 0 = Stay locked; 1 = Auto-unlock at midnight. login/fails_to_user_lock:
Number of failed attempts before lockout. Set to 5 (standard). login/fails_to_session_end: Failed attempts
before session termination.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 7 of 47

Complex Password Requirements (S/4HANA / Newer Systems): From Basis 7.40+, use transaction
SECPOL (Security Policy) for more granular control: - Create a Security Policy: Z_FIN_POLICY. - Set:
Minimum length, character complexity rules, expiry, history. - Assign the policy to specific users or user
groups.
Unlocking Users (SU01 / SU10): Individual User Unlock: 1. SU01 > Enter username > Change. 2. Logon
Data tab > Remove the Lock (uncheck "Lock"). 3. Check the lock reason: Incorrect logon, password expiry,
admin lock.
Mass User Unlock (SU10): 1. SU10 > Select users (by group, role, or manually). 2. Execute > Lock/Unlock
option. 3. Useful for unlocking multiple users after an incident.
Automated Unlock Configuration: - login/failed_user_auto_unlock = 1: Users locked due to wrong password
are automatically unlocked at midnight. This is convenient but less secure. - For production: Set to 0 and
require Basis team or helpdesk to manually unlock.
Password Reset Best Practices: - Never share passwords over email in plain text. - Use SAP Self-Service
Password Reset (if configured) - SU3 allows users to reset own password. - Enable HTTPS for password
transmission. - Log all password resets for audit purposes (SM20 - Security Audit Log).
Key T-Codes: RZ10, RZ11, SU01, SU10, SU3, SECPOL, SM20 Compliance Note: Enable Security
Audit Log (SM19/SM20) to record all logon attempts, password changes, and user administration
actions. This is required for SOX and ISO 27001 compliance.

Scenario 8: Role Design and Segregation of Duties (SoD)

Q: During an audit, it was found that some users can both create purchase orders and also
approve vendor payments. This is a Segregation of Duties conflict. How do you identify and
resolve SoD conflicts in SAP?
Answer & Explanation:
Segregation of Duties (SoD) is a core internal control principle that prevents a single person from having
end-to-end control of a critical business process. In SAP, SoD conflicts arise when a user has
authorizations for conflicting activities.
Common SoD Conflicts in SAP: - Create PO + Approve Payment (Procurement fraud risk) - Create Vendor
+ Release Vendor Payment (Fictitious vendor risk) - Post Journal Entry + Approve Journal Entry (Financial
fraud risk) - Create User + Assign Roles (IT fraud risk) - Initiate Wire Transfer + Approve Wire Transfer
(Treasury fraud risk)
Identifying SoD Conflicts:
Method 1: SUIM (User Information System): - SUIM > Users by Complex Selection Criteria. - Query: Show
users who have BOTH Transaction X and Transaction Y. - Example: Find users with both ME21N (Create
PO) and F110 (Payment Run).
Method 2: SE16 / SE16N Table Analysis: - AGR_USERS: Role-to-user mapping. - AGR_1251: Role
authorization data. - Cross-reference to identify conflicting role combinations.
Method 3: GRC Access Control (SAP GRC): SAP Governance, Risk, and Compliance (GRC) tool
specifically designed for SoD: - Access Risk Analysis: Automatically scans all users and roles for SoD
violations. - Rulebook: Predefined SoD rules (procure-to-pay, record-to-report, etc.). - Remediation
Workflow: Automatically routes violations to role owners for correction. - Mitigation Controls: For
unavoidable SoD violations, document compensating controls.
Resolving SoD Conflicts:
Step 1: Review the business need for each conflicting access. Step 2: Remove the less critical access from
the user's roles. Step 3: If both accesses are business-critical, implement a compensating control: -
Manager review of all POs created by users who also have payment access. - Periodic audit reports (via
SUIM) to monitor for new violations. Step 4: Update role design in PFCG to restrict conflicting transaction
combinations. Step 5: Document all SoD exceptions with risk acceptance signatures.
Role Redesign Best Practices: - Follow Principle of Least Privilege: Give users only the minimum access
needed. - Create functional roles (Z_FI_AP_INVOICE_PROCESSOR) not person-based roles. - Use role
naming conventions consistently. - Review roles at least annually or when job responsibilities change.
Key T-Codes: SUIM, PFCG, SU01, SU53, SE16N (table browser), SM20 (audit log) Governance:
Maintain a Role Ownership Matrix. Each role should have a named business owner who approves
membership changes.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 8 of 47

 Scenario 9: Security Audit Log Configuration
Q: The compliance team requires that all critical SAP activities - logons, failed logons, user
master changes, and transaction starts - be logged for 90 days for audit purposes. How do you
configure and use the Security Audit Log?
Answer & Explanation:
The SAP Security Audit Log (transaction SM19/SM20) records security-relevant events in the SAP system.
It is mandatory for SOX compliance, GDPR, and ISO 27001 certifications.
Configuration (SM19 - Security Audit Configuration):
Step 1: Activate Audit Logging: - Profile parameter: rsau/enable = 1 (Enable Security Audit Log). -
rsau/max_diskspace/local: Maximum disk space for audit files. - rsau/selection_slots: Number of filter
profiles (default: 2, max: 5).
Step 2: Define Audit Filters (SM19): - Select "Change Active Configuration". - Create filters for what to log:
Filter 1 (Critical Users - All Events): - Client: * (all clients) - User: DDIC, SAP*, BASIS_ADMIN (service
accounts) - Audit Classes: All (Dialog Logon, RFC Logon, Transaction Start, Report Start, User Changes) -
Event Severity: All
Filter 2 (All Users - Critical Events Only): - Client: * (all clients) - User: * (all users) - Audit Classes: Dialog
Logon Failure, User Locks, User Creation/Deletion, Role Changes - Event Severity: Critical and Important
Step 3: Activate the Configuration: - Save and activate the audit profile. - Changes take effect immediately
(no restart needed for basic activation).
Audit Events Recorded: - AU1: Successful and failed dialog logon. - AU2: RFC/RFC call logon. - AU3:
Transaction start (by audit users). - AU6: User master record changes (create, modify, delete user). - AU7:
Role/profile assignment changes. - AU8: Authorization failures. - AUB: Report start.
Viewing Audit Logs (SM20): - SM20 > Select date range, client, user. - Filter by event class. - Export to
spreadsheet for compliance reports. - SM20N (newer version): More user-friendly interface with better
filtering.
Retention and Archiving: - Default audit files are in /usr/sap/<SID>/D<xx>/log/ directory. - Automate
archiving via AL11 or OS-level scripts. - Archive to secure, tamper-proof storage (required for compliance).
- Retention period: Minimum 90 days online, 1-7 years in archive (per regulations).
Key T-Codes: SM19, SM20, SM20N, RZ10 (rsau parameters), AL11 (file browser) Compliance:
Ensure audit logs cannot be modified by anyone including Basis admins. Use separate storage with
access controls.

Scenario 10: Emergency User Access (Firefighter / Super User)

Q: During a critical production issue at 2 AM, a developer needs temporary access to
production to apply a fix, but they do not have production access. How do you handle this
securely using SAP GRC Firefighter or manual emergency access?
Answer & Explanation:
Emergency access management (also called Firefighter or Super User Privilege Management) provides
controlled, time-limited, monitored access for critical situations without permanently granting high-privilege
access.
SAP GRC Access Control - Firefighter (GRAC_SPM): This is the SAP standard tool for super user access
management.
Firefighter Process: 1. Firefighter ID (FF ID): Pre-configured, high-privilege user IDs maintained by Basis
team. Not assigned to anyone permanently. Named: FF_DEV_01, FF_PROD_01, etc. 2. Firefighter Owner:
Business/IT manager who approves FF ID usage. 3. Firefighter Controller: Compliance officer who reviews
FF ID usage logs.
Emergency Access Process: Step 1: Developer submits emergency access request in GRC Access
Control. Step 2: FF Owner receives notification and approves or rejects with reason. Step 3: Upon
approval, developer logs into SAP using the FF ID credentials. Step 4: System automatically logs ALL
activities performed under the FF ID. Step 5: After fix is completed, developer logs out and notifies owner.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 9 of 47

Step 6: Controller reviews the FF log within 24-48 hours. All actions are documented. Step 7: GRC
generates a report of all transactions, objects accessed, and data viewed.
Manual Emergency Access (Without GRC): If GRC is not available, use a manual process: 1. Formal
approval email from IT Manager and Business Owner. 2. Basis admin temporarily assigns the required role
to the developer's user ID. 3. Assign with a time-limited validity (SU01 > Roles tab > Valid To: today's date).
4. Developer performs the fix. Basis admin monitors SM20 (Audit Log) during the session. 5. After fix:
Immediately remove the role from the user (SU01). 6. Document the incident: Who accessed, when, what
was done, approval reference. 7. Review SM20 audit log and attach to incident ticket.
Manual Log Review (Without GRC): - SM20: Security Audit Log - shows all transactions started under the
FF ID. - SM21: System Log - shows system events. - ST05: SQL Trace - if database queries need to be
audited.
Best Practices: - Change FF ID passwords immediately after each use. - Never share the FF ID
password electronically; use a physical envelope or password vault. - Always require a change
request or incident ticket number before granting emergency access. - Perform quarterly review of
all FF ID usages.
Key T-Codes: SU01, SM20, SM21, PFCG, GRC transactions (GRAC_*) Governance: Emergency
access must always be exception-based, time-limited, monitored, and reviewed. Never leave
elevated access permanently in production.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 10 of 47

Chapter 3: Background Jobs & Batch Processing
Scenario 11: Background Job Scheduling and Management
Q: The finance team needs a report (F.01 - Financial Statements) to run automatically every
Monday at 6 AM before business starts. How do you schedule and monitor this background
job?
Answer & Explanation:
Background job scheduling in SAP is done via transaction SM36. Background jobs run without user
interaction, using a dedicated background work process.
Background Job Concepts: - Job Steps: Each job can have multiple steps - ABAP programs, external
commands, or external programs. - Job Classes: A (Highest priority), B (Normal), C (Lowest). Class A jobs
get immediate processing. - Job Status: Scheduled, Released, Ready, Active, Finished, Cancelled.
Creating a Background Job (SM36):
Step 1: Basic Job Information: - Job Name: FI_FINANCIAL_STATEMENTS_WEEKLY (use meaningful
naming conventions). - Job Class: B (Normal for scheduled reports). - Target Server: Optionally specify a
server for jobs that should run on a specific host.
Step 2: Define Job Steps: - Step 1: ABAP Program. - Program Name: RFBILA00 (Financial Statements -
underlying program for F.01). - Variant: FI_MONTHLY (pre-created variant with selection parameters). -
User: A background processing user (type B user with appropriate authorizations).
Step 3: Define Start Conditions: - Start Condition > Date/Time. - Scheduled Start Date: Next Monday's
date. - Scheduled Start Time: 06:00:00. - Periodic: Yes (weekly). - Period Values: Weekly on Mondays.
Step 4: Save and Release the Job: - Save the job - it is in "Scheduled" status. - The job will move to
"Released" status automatically at the scheduled time. - System processes it when a background work
process is available.
Creating Variants (SE38 / SA38): - Before scheduling, create a variant for the report with the required
parameters. - SE38 > Enter program name > Variants > Create. - Save selection parameters as a named
variant. - This variant is referenced in the job step.
Monitoring Jobs (SM37): - SM37: Job Overview. - Filter by: Job Name, User, Status, Date. - Select: All
jobs, or filter by status (Finished, Cancelled, Active). - Check finished jobs: Status = green (Finished
successfully). - Check cancelled jobs: Read the job log for error messages.
Job Log Analysis: - In SM37: Select a job > Job Log. - Look for error messages in the log. - For spool
output: SM37 > Select job > Spool (to view the report output).
Common Issues: - Job Not Starting: Check background work process availability (SM50), job start time. -
Job Cancelled: Check SM37 job log, SM21 system log, user authorizations (SU53). - Spool Full: Check
SP01 spool, clean up old spools via SP12.
Key T-Codes: SM36, SM37, SE38, SA38, SP01, SP12, SM50 Best Practice: Use a dedicated
background user (type B) for scheduled jobs. This user should have a non-expiring password and
only the authorizations needed to run the specific programs.

Scenario 12: Batch Job Failure Investigation and Resolution

Q: A critical nightly payroll batch job (scheduled at 11 PM) failed last night. Users are reporting
that salary data has not been updated. How do you investigate and recover from this failure?
Answer & Explanation:
Batch job failure investigation requires a systematic approach covering multiple SAP tools and potentially
OS-level analysis.
Immediate Response Steps:
Step 1: Check Job Status (SM37): - SM37 > Select job name "PAYROLL_NIGHT_RUN" > Status =
Cancelled. - Check the Scheduled Start Time vs. Actual Start. - Did the job start but fail, or did it not start at
all?

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 11 of 47

Step 2: Read the Job Log: - SM37 > Select failed job > Job Log. - Read all log entries from top to bottom. -
Look for: Authorization errors, database errors, lock conflicts, memory issues, program exceptions. -
Example error: "Table PERNR locked by another user" = lock conflict. - Example error: "ABAP dump
occurred" = short dump in a job step.
Step 3: Check ABAP Dump (ST22): - If job log references an ABAP dump: Go to ST22. - Select the job's
background user and the time of failure. - Read the dump text: Error type, program, line number. - Common
dumps in batch: DBIF_RSQL_SQL_ERROR (database issue), MEMORY_NO_MORE_PAGING (memory
issue).
Step 4: Check System Log (SM21): - SM21 > Select time range around job failure. - Look for: Database
timeouts, work process errors, system overload.
Step 5: Check Lock Entries (SM12): - If the job failed due to a lock conflict: Check SM12 for the blocking
lock. - If the lock owner is a long-running dialog transaction: Investigate and potentially release the lock
(with caution).
Recovery Actions: A) If Job Failed Due to Temporary Issue (DB Timeout, Lock): - Wait for the blocking
condition to clear. - Re-run the job: SM37 > Select Job > Release Job (to run immediately) or reschedule.
B) If Job Failed Due to Data Error: - Fix the data issue in the affected records. - Re-run from the failed step
or re-run the entire job.
C) If Partial Completion: - Check which payroll runs (employees) were processed before failure. - Run only
the incomplete employees to avoid double processing.
Restarting the Job (SM37): - SM37 > Select cancelled job > Copy (to create a new instance) > Release
Immediately. - Or use SM36 to schedule a new one-time execution.
Post-Recovery Actions: - Notify payroll and HR team. - Document the failure root cause and resolution. - If
recurring: Apply OSS note or schedule a review of the job configuration.
Key T-Codes: SM37, SM36, ST22, SM21, SM12, SM50, SMLG (Logon Groups for load balancing)

Scenario 13: Spool Administration and Output Management

Q: Users are complaining that they cannot print from SAP. The system administrator also
notices the spool is consuming too much space. How do you manage SAP spool and resolve
printer issues?
Answer & Explanation:
SAP Spool Management is handled via the spool work process (SPO). Understanding spool architecture is
essential for resolving print and output issues.
SAP Spool Architecture: - Spool Request: Created when a user prints or schedules a report with print
output. - Spool Work Process: Dedicated work process that handles print formatting. - TemSe (Temporary
Sequential): Database table or filesystem storage for spool data. - Output Device: Configured printer in
SAP (SPAD).
Diagnosing Print Issues:
Step 1: Check Spool Requests (SP01): - SP01: Spool Overview (user-level). - SP00: All system spool
requests (admin view). - Filter by user, date, output device. - Check Status: "Waiting" (queued),
"Processing", "Error", "Completed". - Select a failed request > Read the error message.
Step 2: Check Output Device Configuration (SPAD): - SPAD: Spool Administration. - Output Devices tab:
List of all configured printers. - Select the problematic printer > Check: - Device Type: Must match the
printer driver (HPLJIIID for HP, ZPL for Zebra, etc.). - Host Spool Access Method: G (Unix), L (Local), E
(External), C (SAP Spool via SAPSprint). - Host Printer Name: The OS-level printer name (must match
exactly).
Step 3: Test Print from SPAD: - SPAD > Select output device > Test Print. - If test print fails: Check OS-
level printer configuration. - If test print succeeds but SAP print fails: Application-level issue.
Step 4: Check Spool Work Process: - SM50: Check if SPO (Spool) work process is running and not stuck. -
If SPO is in error state: Restart the spool work process from SM50 or via sap restart.
Spool Space Management:
Check TemSe Usage: - SP12: TemSe Administration. - View database and filesystem usage for TemSe. -
If near capacity: Delete old spool requests.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 12 of 47

Spool Reorganization (SP12): - SP12 > Reorganization: Delete spool requests older than X days. - Set
appropriate retention: 7 days for most requests, 30 days for compliance-relevant outputs.
Automate Spool Cleanup: - RSPO0041: Report for spool job reorganization. - Schedule as a background
job (SM36) to run nightly. - Set deletion criteria: Age, status, output device.
Profile Parameter for Spool: rspo/store_location: Defines where TemSe is stored (database "db" or
filesystem "G"). rspo/spool_id: Number range for spool IDs.
Key T-Codes: SP01, SP00, SPAD, SP12, SM50, SE91 (messages), RSPO0041 Best Practice:
Schedule automatic spool cleanup via background job. Monitor SP12 weekly to prevent TemSe
overflow, which can cause system performance issues.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 13 of 47

Chapter 4: Performance Monitoring & Tuning
Scenario 14: Workload Analysis and System Performance Investigation
Q: Users report that SAP is very slow during 9 AM to 11 AM. Finance and logistics users are
both affected. How do you use SAP tools to identify the root cause?
Answer & Explanation:
Performance analysis in SAP requires a structured approach using the SAP CCMS (Computing Center
Management System) tools. Performance issues typically fall into four categories: CPU bottleneck, memory
pressure, database performance, and network latency.
Step-by-Step Performance Investigation:
Step 1: Workload Overview (ST05 / SM66): - SM66: Global Work Process Overview. Check during the slow
period: Are many work processes in "Running" state? Are any in PRIV mode? Any waiting for locks or
database?
Step 2: System Workload Analysis (ST03N / STO3): - ST03N: Workload Monitor. - View: Response times
by hour. Compare 9-11 AM to normal periods. - Metrics: Average response time, database time, CPU time,
wait time. - Identify: Is the bottleneck in DB Time (database), CPU Time (application server), or Wait Time
(locks/queues)?
Step 3: Database Performance (ST05 / DB02): - ST05: SQL Trace - capture slow SQL statements. - DB02:
Database Performance Monitoring. - Check: Missing indexes, table statistics, buffer hit ratios. - Look for:
Tables with full table scans, buffer hit rate < 95% (concern). - For HANA: HANA Studio or HANA Cockpit for
in-memory analysis.
Step 4: Memory Analysis (OS07/ST06): - ST06: OS Monitor. - CPU utilization: Should be < 80% sustained.
- Physical memory: Available memory % - if < 20%, paging is occurring. - Disk I/O: High disk read/write
may indicate memory paging.
Step 5: Buffer Analysis (ST02): - ST02: SAP Memory Buffer Status. - Check: Program Buffer, CUA Buffer,
Table Buffer, Repository Buffer. - Swaps: High number of buffer swaps indicates buffer is too small. - Buffer
hit rates should be > 98%.
Step 6: Expensive SQL Statements (SE30 / STAD): - STAD: Statistical Records for Workload Analysis. -
Find the slowest dialog transactions during the problem period. - Click on individual requests to see: DB
calls, DB read time, CPU time. - Identify the most expensive programs/transactions.
Resolution Based on Finding: - DB Time High: Optimize SQL, create missing indexes, update statistics. -
CPU High: Scale out (add more application servers), optimize programs. - Wait Time High: Check SM12 for
lock entries, review SNC/enqueue configuration. - Memory Swapping: Increase extended memory (RZ10),
add RAM.
Key T-Codes: SM66, ST03N, ST05, DB02, ST06, ST02, STAD, AL08, SM12 Golden Rule: Always
analyze with data before changing parameters. Blind parameter tuning can make things worse. Use
baseline comparisons (normal vs. problem periods).

Scenario 15: Database Monitoring and HANA Administration

Q: Your SAP S/4HANA system's database (SAP HANA) is showing memory alerts. How do
you monitor and manage HANA database health from an SAP Basis perspective?
Answer & Explanation:
SAP HANA is an in-memory database. Unlike traditional disk-based databases, HANA keeps most data in
RAM. Memory management is therefore the most critical aspect of HANA administration.
SAP HANA Monitoring from Basis Perspective:
1. HANA Studio / HANA Cockpit (Primary Tools): - HANA Studio: Eclipse-based administration tool. -
HANA Cockpit: Web-based monitoring dashboard (recommended for S/4HANA 1909+). - Both show:
Memory usage, CPU, disk I/O, active sessions, alerts.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 14 of 47

2. DB02 (Database Performance Monitor - SAP GUI): - DB02 > Physical Memory Allocation. - Shows: Total
HANA memory used vs. allocated vs. available. - Missing table statistics alerts. - Large tables requiring
optimization.
3. HANA Memory Architecture: - Column Store: Primary storage for most SAP tables (compressed in-
memory). - Row Store: Used for configuration tables, metadata. - Heap Memory: Working memory for
processes. - Total Memory Used = Column Store + Row Store + Heap + Code.
Memory Troubleshooting:
Issue: Memory Alert in HANA Cockpit: Step 1: Check memory usage breakdown in HANA Studio >
Performance > Memory. Step 2: Identify the largest consumers (typically column store tables). Step 3:
Check if tables have been loaded unnecessarily: Run HANA "Unload" for infrequently used tables. SQL:
ALTER TABLE <table_name> UNLOAD; (frees column store memory). Step 4: Check for memory leaks:
Large heap allocators that are not releasing memory. Investigate via HANA trace files. Step 5: Trigger
memory cleanup: HANA automatic resource manager handles this, but can be triggered manually.
HANA Backup Monitoring (Basis Responsibility): - HANA Studio > Backup Catalog: View all backup history.
- Verify: Daily full backups are completing. Delta/log backups are running every 15-30 minutes. - Check
backup destination: NFS mount, dedicated backup server. - Backup command: BACKUP DATA USING
FILE ('backup_prefix'); or via HANA Cockpit.
HANA Indexserver Restart (Critical Process): - If HANA indexserver crashes: Data reload is needed (HANA
restarts and reloads from disk). - Monitor: HANA Cockpit > Services > All service processes should show
"running". - OS check: hdbnsutil -sr_state (check system replication status).
HANA System Replication (HSR): - For high availability: Primary and secondary HANA nodes. - Check
replication status: SELECT * FROM M_SERVICE_REPLICATION; (HANA SQL). - Failover: hdbnsutil -
sr_takeover (manual failover command).
Key Tools: DB02, HANA Studio, HANA Cockpit, DBACOCKPIT (SAP GUI), SM21 Command Line:
hdbsql, hdbnsutil, sapcontrol for HANA management from OS level.

Scenario 16: Lock Entry Management and Deadlock Resolution

Q: Users are reporting that certain transactions are hanging indefinitely. Investigation reveals
lock entries are preventing other users from accessing the same records. How do you identify
and resolve locking issues in SAP?
Answer & Explanation:
SAP uses an Enqueue (lock) service to prevent simultaneous write access to the same data object. Lock
entries in SM12 are normal during active transactions but can become problematic when sessions
disconnect abnormally or hang.
Understanding SAP Locks: - SAP Application Locks: Managed by the Enqueue work process (ENQ).
Stored in a shared memory area. - Database Locks: Row-level or table-level locks at the database layer. -
For distributed systems (ASCS/ENQUE): Standalone enqueue server.
Lock Entry Management (SM12):
Step 1: View Current Locks: - SM12: Select All Entries > Execute. - Columns: Lock owner (user), client,
lock object, key, time created. - Look for: Old locks (created hours ago), locks from disconnected sessions.
Step 2: Identify Problematic Locks: - A lock is problematic if: Created a long time ago AND the user is not
actively working (check AL08 for active sessions), OR the holding user is a background job that has
completed. - Cross-reference with AL08: Is the lock owner still logged in and active?
Step 3: Resolving Lock Issues: Option A - Wait: If the lock owner is actively working, they will release the
lock when they save or cancel. Option B - Contact User: Call the user to complete or cancel their
transaction. Option C - Delete Lock (Use with extreme caution): In SM12, select the lock entry > Delete.
WARNING: Only delete a lock if you are certain the lock holder has abandoned the transaction. Deleting
active locks can cause data inconsistency. Option D - Work Process Restart (Last resort): If a work process
is hung holding a lock, restart it in SM50. This releases all locks held by that work process.
Deadlock Analysis: A deadlock occurs when: User A holds Lock 1 and waits for Lock 2. User B holds Lock
2 and waits for Lock 1. Neither can proceed.
SAP handles database deadlocks automatically (one transaction is rolled back). For application deadlocks,
review SM21 (system log) for deadlock messages and trace the transactions involved.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 15 of 47

Enqueue Server Issues: - In ABAP stack: /nSMICSNINS to check enqueue server. - For ENSA2 (new
enqueue service in S/4HANA): Check via sapcontrol. - If enqueue server is not running: All lock-based
transactions will fail.
Automated Lock Cleanup: - RSENEQOO: Report to clean up old, orphaned lock entries. - Schedule this
report in SM36 to run periodically (off-peak hours).
Key T-Codes: SM12, AL08, SM50, SM66, SM21 Best Practice: Never routinely delete lock entries.
Always investigate why a lock is old before deleting. Document any lock deletions for audit
purposes.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 16 of 47

Chapter 5: System Maintenance & Patching
Scenario 17: Support Package and SAP Kernel Upgrade
Q: SAP has released a critical security patch (Support Package Stack). You need to apply it to
the production system. Walk through the complete patching process and best practices.
Answer & Explanation:
SAP system patching involves applying Support Packages (SPs) which contain corrections, security fixes,
and new features. This is one of the most critical and risk-prone Basis activities.
SAP Patching Terminology: - Support Package (SP): A bundle of corrections (notes/patches) for a specific
software component (e.g., SAP_BASIS, SAP_APPL). - Support Package Stack: A set of SPs for all
components released simultaneously as a consistent level. - SAP Kernel: The core executable files of the
SAP system. Updated separately from SPs. - SPAM/SAINT: SAP Patch Manager and Add-On Installation
Tool.
Pre-Patching Steps:
1. Impact Analysis: - Download the SP from SAP Marketplace ([Link] > Software Downloads). -
Check the Support Package Release Note for: New/changed transactions, parameter changes, required
pre-requisites. - Check compatibility with installed add-ons and custom developments.
2. System Health Check: - SM21: No critical errors in system log. - SM37: No stuck background jobs. -
SM12: No old lock entries. - Backup status: Recent full backup exists. - Disk space: At least 3x the SP size
available in transport directory (/usr/sap/trans/).
3. Sandbox/DEV First: - ALWAYS apply patches to DEV first, then QAS, then PRD. - Allow adequate
testing time in QAS before PRD.
Patching Process (SPAM Transaction):
Step 1: Upload SP files: - Copy the SP files (*.SAR, *.CAR format) to /usr/sap/trans/EPS/in/ directory. - In
SPAM: Load Packages > From Application Server. - SP appears in the queue.
Step 2: Define SP Queue: - SPAM > Display/Define Queue. - Select the SPs to apply (maintain the correct
order). - Run queue definition to check prerequisites.
Step 3: Apply Patches: - SPAM > Apply Support Packages. - The process runs through phases:
PREPARE: Checks system health and prerequisites. IMPORT_1: First import of corrections.
DDIC_IMPORT: Data dictionary changes (table structures). ABAP_IMPORT: ABAP program corrections.
IMPORT_2: Second import phase. AFTER_IMPORT: Post-import steps. MAKE: Compilation of programs.
ACTIVATE: Activation of objects. MODPROF: Profile modifications. RUN: Post-processing programs.
CLEANUP: Final cleanup. - Each phase can be monitored via SPAM.
SAP Kernel Upgrade: 1. Download new kernel from SAP Marketplace (same OS/DB version). 2. Stop the
SAP system. 3. Backup old kernel files: cp -r /usr/sap/<SID>/exe /usr/sap/<SID>/exe_backup. 4. Unpack
new kernel files to /usr/sap/<SID>/exe/. 5. Set correct permissions: chown -R <sidadm>:sapsys
/usr/sap/<SID>/exe/. 6. Start SAP system. 7. Verify kernel version: /usr/sap/<SID>/exe/disp+work -version.
Post-Patching: - Verify system start (SM21 - no new errors). - Run regression tests in QAS. - Monitor
production system closely for 48 hours after PRD patching.
Key T-Codes: SPAM, SAINT, SE16 (check DD table), SM21, ST22 OS Commands: SAPCAR (unpack
SAR files), disp+work -version (check kernel)

Scenario 18: ABAP Workbench and Custom Development Transport

Q: A developer has created a custom Z-report in DEV to automate a month-end process. This
report needs to be moved to QAS for testing and then to PRD. Walk through the complete
transport process.
Answer & Explanation:
Moving custom ABAP developments from DEV to QAS to PRD is done through the Change and Transport
System (CTS). Understanding this process thoroughly is essential for Basis consultants.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 17 of 47

Development Objects and Workbench Requests:
When a developer creates a Z-report in SE38/SE80: 1. SAP automatically prompts: "Create/Assign to
Workbench Request." 2. Developer either creates a new Workbench Request or uses an existing one. 3.
The request captures: ABAP program, includes, variants, text elements, messages, and any other objects.
Transport Request Types: - Workbench Request (K): For repository objects (ABAP programs, function
modules, classes, tables, etc.). System-independent. - Customizing Request (W): For client-dependent
configuration (IMG settings, configuration tables).
Request Management (SE10): - SE10: Transport Organizer (displays all requests for the logged-in user). -
SE09: Workbench-specific requests. - Request statuses: Modifiable (still being worked on), Released
(ready for transport), Transported (exported), Imported (in target system).
Releasing a Transport Request (SE10 or SE09): 1. Developer goes to SE10 > Find the relevant request. 2.
Review objects in the request (ensure all objects are included). 3. Add any missing objects manually (if
needed): Drag from repository to request. 4. Select the request > Release (truck icon with R). 5. System
checks for: Syntax errors, lock conflicts, empty requests. 6. After release: Request is exported to the
transport directory (/usr/sap/trans/).
Importing into QAS (STMS): 1. Basis team opens STMS in QAS system. 2. STMS > Import Overview >
Select QAS system. 3. The released transport request appears in the import queue. 4. Verify: Is the request
in the queue? Check "Added" date vs. release date. 5. Select request > Import (or import all from queue). 6.
Monitor import: Return codes 0 or 4 = OK, 8 or higher = errors (investigate).
Troubleshooting Common Transport Issues: A) Objects Missing from Transport: - Developer forgot to add
objects to the request. - Solution: In DEV, use SE03 > Search for objects > Move to the correct transport
request.
B) Transport Contains Old Objects: - Request contains objects modified earlier and re-modified. - Solution:
Review transport history (SE01), use "Transport of Copies" if specific version is needed.
C) Request Not Visible in QAS Queue: - RFC connection between DEV and domain controller may be
broken. - Check STMS > Check CMS connectivity. - Manually add transport to queue: STMS > Import
Queue > Add > Enter TR number.
D) Imported but No Effect: - Wrong client: Ensure the import target is the correct client (customizing
requests are client-dependent). - Activation errors: Some objects need manual activation after import (SE11
for tables, SE38 for programs).
Key T-Codes: SE10, SE09, SE03, STMS, SE38, SE80 Important: After importing to PRD, always
perform a smoke test on the affected transactions to ensure everything is working correctly.

Scenario 19: System Refresh and Homogeneous Copy

Q: QAS needs to be refreshed with the latest PRD data to enable realistic UAT testing. The
systems are on the same OS and DB type. How do you plan and execute a homogeneous
system copy?
Answer & Explanation:
A System Refresh (Homogeneous System Copy) replaces an existing SAP system with a copy from
another system. This is commonly done to refresh QAS from PRD for accurate UAT testing.
Homogeneous System Copy Overview: Homogeneous = Same OS, same database type, same SAP
version. Heterogeneous = Different OS or different database type (more complex, requires additional tools
like SWPM/R3load).
Methods for System Refresh:
Method 1: Database Backup/Restore (Most Common): 1. Take a full database backup of PRD (HANA:
BACKUP DATA, Oracle: RMAN backup). 2. Restore the backup to QAS server. 3. Post-restore: Adjust
system settings for QAS.
Method 2: HANA System Replication Detach (for HANA systems): 1. Use HANA System Replication to
create a standby copy of PRD. 2. Detach the standby and use it as QAS after adjustment. 3. More complex
but faster for large databases.
Method 3: SAP SWPM (Software Provisioning Manager): SWPM provides a guided wizard for system
copies. 1. Download SWPM from SAP Marketplace. 2. On target server: Run SWPM > System Copy >
Source: PRD, Target: QAS. 3. Provide backup file location, DB credentials. 4. SWPM automates the copy,
post-processing, and adjustments.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 18 of 47

Post-Copy Activities (Critical): These must always be performed after a system copy to "de-couple" QAS
from PRD:
1. Client-Level Post-Copy (SCCL / SCC7): - Apply client-specific settings.
2. User Administration: - SU10: Lock ALL users copied from PRD (prevents confusion/unauthorized
access). - Change all service account passwords. - Unlock only the required test users.
3. RFC Destinations (SM59): - Review all RFC connections. - Redirect connections pointing to PRD to QAS
equivalents. - Test all critical RFC connections.
4. Background Jobs (SM37/SM36): - Cancel or deactivate all background jobs. - Reconfigure jobs to point
to QAS parameters. - Ensure no jobs will trigger PRD processes (e.g., no live payment runs).
5. Print/Output Configuration (SPAD): - Redirect printers to "test" printers or null device. - Prevent test
prints from going to production printers.
6. IDocs and Interfaces (WE20/BD54): - Disable or redirect all external interfaces. - EDI partners should
point to test trading partner environments.
7. Email Configuration: - SCOT: Change email routing to use a test email relay. - Prevent test emails from
reaching real customers/vendors.
8. License Key (SLICENSE): - QAS requires a separate SAP license after system refresh. - Generate a
hardware key (SLICENSE > Hardware Key). - Submit to SAP for a new QAS license key.
Key T-Codes: SLICENSE, SM59, SU10, SM37, SPAD, SCOT, WE20, BD54, SCC4

Scenario 20: SAP License Administration

Q: SAP license audit is coming up next month. You need to ensure the SAP system has valid
licenses and that the named user counts are within the contracted limits. Walk through license
administration in SAP.
Answer & Explanation:
SAP licensing is based on User Types and the total number of named users. SAP conducts periodic
license audits (SLAW - SAP License Audit Workbench), and non-compliance results in significant additional
costs.
SAP User Types for Licensing: - Professional User: Highest license; full access to all SAP functionality. -
Limited Professional User: Access to a subset of functionality. - Employee User (ESS/MSS): Self-service
HR transactions only. - Casual/Limited User: Specific limited usage scenarios. - Developer User: Dedicated
for ABAP development work. - Test User: For approved testing environments (not licensed separately in
most contracts).
License Management (SLICENSE):
Step 1: Check Current License: - SLICENSE: Display current SAP license. - Shows: System ID, Installation
Number, expiry date, licensed user counts by type.
Step 2: Check Actual User Counts (USMM): - USMM: System Measurement (License). - This transaction
counts active users by type. - Run USMM to see: Current user count vs. licensed count. - Comparison:
Actual users > Licensed users = Audit risk.
Step 3: Generating a License Key: - New or expired license: SLICENSE > Generate Hardware Key. - Send
Hardware Key to SAP (via SAP ONE Support Launchpad > License Keys). - SAP provides a license file
(contains installation number, user counts, expiry). - Import the license file back in SLICENSE.
Step 4: Pre-Audit Cleanup: - Identify inactive users: SUIM > Users > By Logon Date. - Delete or lock users
who have not logged in for 6+ months. - Verify user types are correctly assigned (many organizations
assign "Professional" when "Employee" would suffice). - Correct user types in SU01 > Logon Data > User
Type. - This can significantly reduce license cost exposure.
License Audit Process (SLAW): - SAP may request an audit via email. - Run USMM in production > Export
the measurement file. - Submit to SAP via SAP License Audit Workbench portal. - SAP compares against
contract. If over-licensed: Invoice for additional users.
LAW (License Administration Workbench - for Consolidated Measurement): - For companies with multiple
SAP systems, LAW consolidates usage across all systems. - Prevents double-counting users who have
access to multiple systems. - Configure LAW to collect data from all system IDs.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 19 of 47

Key T-Codes: SLICENSE, USMM, SUIM, SU01, SU10 Cost-Saving Tip: Conduct quarterly user
access reviews. Remove inactive users promptly. Ensure user types accurately reflect actual
usage. Named user licenses can cost thousands per user annually.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 20 of 47

Chapter 6: SAP Basis – RFC, Interfaces &
Integration
Scenario 21: RFC Connection Setup and Troubleshooting
Q: A new interface needs to be set up between SAP ECC and an external system (e.g., a third-
party WMS). How do you create and test RFC connections in SAP?
Answer & Explanation:
RFC (Remote Function Call) is SAP's proprietary protocol for communication between SAP systems and
between SAP and external systems. It is the backbone of most SAP integrations.
RFC Types: - Type 3 (ABAP Connection): Connection between two ABAP-based SAP systems (ECC to
S/4HANA, ECC to BW, etc.). - Type H (HTTP Connection): For web service calls, REST/SOAP interfaces. -
Type L (Logical Destination): Points to another logical destination (for load balancing). - Type G (HTTP to
External Server): For HTTP connections to external web services. - Type I (Internal): Used for internal
processing within the same system.
Creating an RFC Connection (SM59):
Step 1: Open SM59 and Create New Destination: - SM59 > Create > Select connection type (e.g., Type 3
for ABAP-to-ABAP).
Step 2: Technical Settings Tab: - Target Host: Hostname or IP address of the target SAP system. - System
Number: SAP instance number (e.g., 00). - IP Address: Can be specified instead of hostname.
Step 3: Logon & Security Tab: - Client: Target client number. - User ID: A dedicated RFC user (type S or B)
in the target system. - Password: RFC user's password. - Language: EN.
Step 4: Save and Test: - Save the RFC destination. - Test > Connection Test: Verifies network connectivity.
- Test > Authorization Test: Verifies the RFC user has logon authorization. - Test > Unicode Test: Verifies
character set compatibility.
RFC User Setup in Target System: - Create a Communication user (type C) in SU01. - Assign: SAP_ALL
(for initial setup) or specific RFC execution roles. - Ensure the user's password does not expire (or manage
password rotation carefully).
Troubleshooting RFC Errors:
Error: "Connection timed out": - Check network: Can the source server ping the target server? - Check SAP
gateway: Is the gateway (gwrd) running on the target? (SM59 > Remote Logon > Ping). - Check firewall
rules: SAP ports 32xx (ABAP dispatcher) and 33xx (gateway) must be open.
Error: "Authority check failed": - The RFC user in the target system lacks required authorizations. - Check
SU53 (using the RFC user ID) or SM59 > Authorization Test for details. - Add missing authorization objects
to the RFC user's role.
Error: "No more resources": - Target system is overloaded or has no free dialog/background work
processes. - Check SM66 in the target system.
Load Balancing RFC (Type L): - Points to a message server rather than a specific application server. -
More resilient than hard-coded server connections. - Configure: Logon Groups (SMLG) in the target
system.
Key T-Codes: SM59, SMLG, SU01, SM50, SM66 Security Best Practice: Use dedicated RFC users
with minimal required authorizations. Never use SAP* or DDIC for RFC connections. Rotate RFC
user passwords regularly.

Scenario 22: SAP Gateway and Web Services

Q: A mobile app developer needs to connect to SAP S/4HANA via OData services to retrieve
sales order data. As a Basis consultant, how do you configure and manage the SAP Gateway?
Answer & Explanation:
SAP Gateway is the platform for exposing SAP backend data and functionality as RESTful OData services,
enabling consumption by mobile apps, Fiori, and external web applications.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 21 of 47

SAP Gateway Architecture: - Embedded Gateway (recommended for S/4HANA): Gateway is embedded
within the S/4HANA ABAP stack. No separate gateway server needed. - Hub Deployment: Separate
Gateway server acts as an intermediary. Used in ECC landscape.
SAP Gateway Configuration:
Step 1: Activate Gateway Services (SPRO / /IWFND/MAINT_SERVICE): - /IWFND/MAINT_SERVICE:
Activate and Maintain Services. - This is the central transaction for managing which OData services are
active. - Find the required service (e.g., API_SALES_ORDER_SRV for sales orders). - Add System Alias:
Point to the backend system where data resides. - Activate the service.
Step 2: System Alias Configuration: - /IWFND/MAINT_SERVICE > System Aliases. - Create alias pointing
to the backend ABAP system via RFC destination. - Test the alias connection.
Step 3: ICM (Internet Communication Manager) Configuration: - SMICM: Internet Communication Manager
Monitor. - Check: HTTP and HTTPS services are started. - Gateway URL format:
[Link]
Step 4: SAP Fiori Launchpad Configuration: - /UI2/FLP_CONF_DEF: Fiori Launchpad configuration. -
Assign Fiori apps to business roles. - Tile/catalog assignment for user access.
Monitoring Gateway Services: - /IWFND/ERROR_LOG: Gateway error log (check for service failures). -
/IWFND/TRACES: Gateway trace configuration. - SMGW: Gateway Monitor (check connections and active
sessions). - SMICM: ICM Monitor (HTTP/HTTPS connections).
Troubleshooting OData Service Issues: Error: "Service not found (HTTP 404)": - Service not activated in
/IWFND/MAINT_SERVICE. - Correct: Activate the service and add system alias.
Error: "Unauthorized (HTTP 401)": - OData user lacks authorization for the OData service or business
objects. - Check: User role assignment, /IWFND/MAINT_SERVICE user authorization. - Check SU53 for
the calling user.
Error: "Service unavailable (HTTP 503)": - ICM not running: Check SMICM. - Backend RFC destination
broken: Check SM59.
SSL/HTTPS Configuration: - STRUST: SSL Server Certificate Management. - Import SSL certificates for
HTTPS communication. - Ensure the system's SSL certificate is trusted by clients.
Key T-Codes: /IWFND/MAINT_SERVICE, SMICM, SMGW, STRUST, /IWFND/ERROR_LOG, SM59

Scenario 23: SAP PI/PO Interface Monitoring

Q: A critical interface between SAP and a third-party ERP system via SAP Process Integration
(PI/PO) has failed. Orders are not flowing from the external system. How do you monitor and
troubleshoot SAP PI/PO?
Answer & Explanation:
SAP PI (Process Integration, also known as PO - Process Orchestration) is SAP's middleware for
connecting SAP and non-SAP systems. Message failures in PI/PO must be investigated from both the
PI/PO side and the connected system sides.
SAP PI/PO Architecture: - Sender System: Sends messages (e.g., external ERP). - PI/PO Integration
Engine: Routes, transforms, and maps messages. - Receiver System: Receives the processed message
(e.g., SAP ECC/S4).
Monitoring Tools:
1. SAP PI Message Monitor (SXMB_MONI): - SXMB_MONI: Integration Engine - Monitor. - View all
messages: All statuses (Success, Error, Processing, Cancelled). - Filter by date, sender, receiver,
interface. - Select a failed message: Read the error details. - Key message statuses: System Error (runtime
issue), Application Error (data/logic issue), Successful.
2. PI Web UI ([Link] - Operations > Message Monitor: Web-based monitoring for
PI 7.1+. - Shows detailed message flow: from adapter to mapping to routing to receiver adapter. - Each
step shows success/failure with payload details.
3. Adapter Framework Monitoring (SXMB_MONI in PI or Adapter Engine): - Check adapter-specific logs:
HTTP adapter, JDBC adapter, File adapter. - Adapter errors typically relate to: Connection failure,
authentication, data format.
Common Error Scenarios and Resolutions:

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 22 of 47

A) Sender Adapter Error (Message not received by PI): - Symptom: No message visible in SXMB_MONI. -
Check: External system connectivity to PI. File/FTP pickup path (for file-based integration). HTTP endpoint
URL. - Resolution: Restore connectivity, check adapter configuration in Integration Directory.
B) Mapping Error (Message fails at transformation): - Symptom: Message in SXMB_MONI with status
"Mapping Error." - Check: Message payload (sender format). Mapping program (Enterprise Service
Builder). Mandatory fields missing. - Resolution: Fix source data or correct the mapping logic. Re-process
the message from SXMB_MONI.
C) Receiver Adapter Error (Delivery to SAP fails): - Symptom: Message successfully mapped but failed at
delivery. - Check: RFC destination to SAP. SAP system availability. SAP receiver program logic. -
Resolution: Fix RFC connection, restart SAP, or fix the BAPI/function module being called.
Re-Processing Failed Messages: - SXMB_MONI: Select failed messages > Re-Process. - For bulk re-
processing: Use "Restart All Errors in Queue" option.
Channel Monitoring (Communication Channels): - PI Web UI > Channel Monitoring: View status of all
sender/receiver channels. - Red = Down, Green = Active. - If a channel is red: Check adapter logs,
network, external system.
Key T-Codes/URLs: SXMB_MONI, SMGW, PI Web UI, SM59, SXI_CACHE (Integration Cache Refresh)

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 23 of 47

Chapter 7: High Availability, DR & System
Operations
Scenario 24: SAP High Availability Architecture
Q: Your client's production SAP system must achieve 99.9% uptime. Explain the High
Availability (HA) architecture components and how SAP achieves HA in an S/4HANA
landscape.
Answer & Explanation:
High Availability (HA) in SAP aims to eliminate single points of failure. If any component fails, the system
continues operating with minimal or no disruption to users.
SAP HA Architecture Components:
1. ASCS (ABAP Central Services): Contains: Message Server + Enqueue Server (lock management). If
ASCS fails: ALL users are disconnected; no new sessions possible. HA Solution: Cluster the ASCS using
OS-level clustering (RHEL/SUSE with Pacemaker or Windows Server Failover Clustering). A standby
ASCS instance on another server takes over automatically.
2. Application Servers (Dialog Instances - DI): Multiple application servers provide load distribution and
redundancy. If one DI fails: Users are redirected to other active DIs (via SAP logon groups - SMLG). No
single point of failure if 2+ DIs exist.
3. Database (SAP HANA): HANA System Replication (HSR): Primary and secondary HANA nodes.
Replication modes: - Sync (synchronous): No data loss on failover (lowest RPO). Performance impact. -
Async (asynchronous): Minimal performance impact but potential data loss. - Syncmem: Synchronous in
memory only. Compromise between sync and async. Failover: Pacemaker or SUSE HAE triggers
automatic failover to secondary HANA.
4. Shared Storage / NFS: - Sapmnt (/sapmnt/<SID>) and profile directories must be accessible by all
servers. - NFS or cluster file system (OCFS2, GPFS) used for shared storage HA.
5. SAN (Storage Area Network): - Enterprise storage with RAID, dual controllers, and dual paths.
Typical S/4HANA HA Landscape: - Node 1: Primary ASCS + Primary DI + Primary HANA DB. - Node 2:
Failover ASCS + Failover DI + Secondary HANA (HSR). - Pacemaker Cluster: Manages automatic failover
for ASCS and HANA. - Virtual IP Addresses: Clients always connect to a virtual IP (VIP) that moves with
the active node.
Testing HA (Disaster Recovery Test): - Simulate ASCS failure: Stop ASCS on primary, verify automatic
failover to secondary. - Simulate HANA failure: Stop primary HANA, verify HSR takeover. - Document RTO
(Recovery Time Objective) and RPO (Recovery Point Objective) test results. - SAP goal: RTO < 5 minutes
for planned failover, < 30 minutes for unplanned.
Key Tools: sapcontrol, hdbnsutil, Pacemaker (crm_status), SMICM, SM50 SAP Note 1820529:
Recommended HA configuration for HANA. SAP Note 2382421: HANA system replication guide.

Scenario 25: System Start/Stop Procedures

Q: You need to perform a planned maintenance window requiring a full system shutdown and
restart. What is the correct sequence for stopping and starting an SAP S/4HANA system?
Answer & Explanation:
Knowing the correct start/stop sequence is fundamental for Basis consultants. Starting or stopping in the
wrong order can lead to data loss, lock issues, or startup failures.
Pre-Shutdown Checklist: 1. Notify all users: Broadcast system message using SM02 (Send system
message to all users). 2. Verify no active batch jobs: SM37 > Check for actively running jobs. Allow them to
complete or cancel gracefully. 3. Check active users: AL08 or SM04 (users on current server). 4. Confirm
database backup is recent and complete. 5. Confirm change freeze: No transports being imported.
SHUTDOWN SEQUENCE (Most Critical - Wrong Order = Data Loss):

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 24 of 47

Step 1: Lock new logons (SM01): - SM01: Lock new logons on all servers. - This prevents new users from
starting sessions.
Step 2: Wait for / End active users: - SM04: View active users > Send message, then forcefully end
sessions if needed. - Wait for pending update records: SM13.
Step 3: Stop Background Job Scheduler: - SM61 / btctrns: Pause the background job scheduler to prevent
new job starts.
Step 4: Stop the SAP Application Layer: Using SAP Management Console (MC) or sapcontrol: Command:
sapcontrol -nr <instance_number> -function Stop Or from UNIX/Linux shell (as <sidadm> user): stopsap r3
(stops the ABAP instance).
For each application server (start with DIs, then ASCS last): - /usr/sap/<SID>/D<xx>/exe/sapcontrol -nr
<xx> -function Stop
Step 5: Stop the Database (After SAP Application Layer is fully stopped): For SAP HANA (as <sid>adm
user): HDB stop (graceful shutdown of HANA). Verify: hdbnsutil -sr_state shows "stopped."
For Oracle: sqlplus /nolog > connect / as sysdba > shutdown immediate.
START SEQUENCE (Reverse of Shutdown):
Step 1: Start the Database First: For HANA (as <sid>adm): HDB start Wait for HANA to fully start before
proceeding. Check: hdbnsutil -sr_state (primary is running).
Step 2: Start ASCS (Central Services): sapcontrol -nr <ASCS_instance_number> -function Start Verify:
Message server and enqueue server are running.
Step 3: Start Primary Dialog Instance (and other DIs): sapcontrol -nr <DI_instance_number> -function Start
For multiple DIs: Start sequentially or in parallel.
Step 4: Verify System Health: - SM50: All work processes in "Waiting" state. - SM21: No critical errors in
system log. - SM37: Background jobs starting as expected. - AL08: No ghost sessions from before
shutdown.
Step 5: Unlock new logons (SM01): - Enable logons for all users. - Send "System is available" broadcast
(SM02).
Key Tools: sapcontrol, HDB commands, SM01, SM02, SM04, SM13, SM37, AL08 Note: On S/4HANA
embedded deployment, SAP and HANA run together. Always start HANA before SAP and stop SAP
before HANA.

Scenario 26: Disaster Recovery Testing and Planning

Q: Your client's DR policy requires a quarterly DR drill. Their SAP production system
(S/4HANA) needs to be able to start within 4 hours at the DR site from the point of disaster.
How do you plan and execute a DR test?
Answer & Explanation:
Disaster Recovery (DR) for SAP is the ability to restore critical SAP operations at an alternate site when the
primary site is unavailable. DR planning and regular testing are critical for business continuity.
DR Architecture Options:
1. Warm Standby (HANA System Replication + Cloud): - Secondary HANA instance continuously replicates
from primary. - RPO: Near zero (sync replication) or minutes (async). - RTO: 30 minutes to 2 hours (SAP
restart + verification). - Cost: High (dedicated standby hardware).
2. Backup-Based DR: - Regular full + differential HANA backups copied to DR site. - RPO: Last backup
(typically 24 hours or less with log shipping). - RTO: 4-8 hours (restore time + SAP start). - Cost: Lower (no
dedicated standby hardware needed).
3. Cloud-Based DR (Azure/AWS/GCP): - Backups to cloud, or cloud replication. - More cost-effective,
scalable. - RTO can be configured based on instance size at DR site.
DR Test Planning:
Phase 1: Pre-Test Preparation (2-4 weeks before): - Document the current DR procedure (runbook). -
Verify the DR site: Hardware ready, OS patched, network configured. - Verify latest HANA backup is at the
DR site. - Identify participants: Basis team, network team, business team. - Define success criteria: System
starts, users can log in, key transactions work.
Phase 2: DR Test Execution:

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 25 of 47

Notify stakeholders and start the test clock.
Database Restore at DR Site: 1. Verify backup files available at DR site. 2. Install HANA at DR site (if not
already there) using HANA SWPM. 3. Restore HANA: RECOVER DATABASE UNTIL TIMESTAMP
'<timestamp>' USING SOURCE '<backup_path>'; 4. Wait for restore to complete. Monitor HANA Studio >
Recovery dialog.
SAP Application Start: 1. Copy/verify SAP profiles from backup to DR server. 2. Verify /sapmnt directory is
accessible. 3. Start SAP system using sapcontrol or startSAP. 4. Check SM21, SM50 for clean start.
Application Verification: 1. Log in as a test user. 2. Run key smoke test transactions: ME23N (PO display),
FB03 (FI document), VA03 (Sales Order). 3. Verify output: Correct data is accessible. 4. Run a non-
destructive test transaction (read-only).
Phase 3: Post-Test Documentation: - Record: Start time, completion time, any issues encountered. - Actual
RTO vs. target RTO. - Issues list with corrective actions. - Update the DR runbook with lessons learned.
Key Success Metrics: - RTO Achieved: System operational within 4 hours. - RPO Achieved: Data loss
within acceptable limits (last backup). - Data Integrity: Key business data accessible and correct.
Key T-Codes: SM21, SM50, SM37, SM01, SLICENSE (new license for DR system) Critical: DR
systems require separate SAP licenses. Always generate a DR-specific license key (temporary
licenses available from SAP for DR testing).

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 26 of 47

Chapter 8: SAP Basis – Advanced Topics
Scenario 27: SAP Fiori Configuration and Activation
Q: A client wants to roll out SAP Fiori for their S/4HANA system. End users need access to
Fiori apps for purchase order approval, leave requests, and sales dashboards. How do you set
up Fiori?
Answer & Explanation:
SAP Fiori is the UX framework for SAP S/4HANA, providing role-based, responsive web-based
applications. Basis is responsible for the technical infrastructure, while functional teams configure the
business content.
Fiori Architecture in S/4HANA (Embedded): - ABAP Frontend Server: Hosts the Fiori Launchpad (FLP) and
OData services. - ICM (Internet Communication Manager): Handles HTTP/HTTPS requests. - OData
Services: Expose backend business logic as RESTful APIs. - UI5 Applications: JavaScript-based frontend
apps running in the browser.
Fiori Activation Steps:
Step 1: Activate Technical Foundation: - /UI5/APP_INDEX_CALCULATE: Rebuild the UI5 application index
(run after new transports). - /UI2/PAGE_BUILDER_CONF: Configuration of Fiori Launchpad page builder. -
Activate ICM in SMICM: Ensure HTTP (port 80xx) and HTTPS (port 443xx) are running.
Step 2: Activate OData Services (/IWFND/MAINT_SERVICE): - For each Fiori app, activate the
corresponding OData service. - Example: For "My Purchase Orders" app, activate
API_PURCHASEORDER_PROCESS_SRV. - Add System Alias pointing to the backend. - Test the service
via the service URL.
Step 3: Create and Assign Fiori Business Roles (PFCG): - SAP delivers standard Fiori roles (e.g.,
SAP_BR_PURCHASER for procurement). - Create a composite role combining relevant business roles. -
Assign the role to users (SU01 > Roles tab). - Generate authorization profiles (PFCG > Generate).
Step 4: Fiori Catalog and Group Assignment: - /UI2/FLP: Launch the Fiori Launchpad and verify tile
visibility. - /UI2/SEMOBJ: Semantic object configuration. - Assign catalogs to roles: PFCG > Menu tab >
Fiori Tile Catalog. - Assign groups (tiles grouped on homepage) to roles.
Step 5: End User Testing: - User accesses:
[Link] - Tiles should appear
based on role assignment.
Common Fiori Issues:
Issue: Blank Launchpad / No Tiles: - Check: OData service activated? Role assigned? User logged in with
correct client? - Check: /UI5/APP_INDEX_CALCULATE was run after transport imports.
Issue: "Unauthorized" Error When Opening App: - SU53: Check what authorization object is failing. - Add
missing authorization object to the Fiori business role.
Issue: App Shows No Data: - Check OData service backend system alias is correct. - Check backend user
(associated with the OData service) has data access. - Test OData service directly: Access the service
URL in browser with user credentials.
Fiori Launchpad Designer: - /UI2/FLP_CONF: Customize the Fiori homepage layout. - Add custom tiles,
change logo, customize groups.
Key T-Codes: /IWFND/MAINT_SERVICE, SMICM, PFCG, /UI2/FLP, /UI5/APP_INDEX_CALCULATE,
SU01, SU53

Scenario 28: CCMS Monitoring and Alert Configuration

Q: Management wants proactive monitoring with email alerts when: CPU usage exceeds 85%,
any background job fails, or disk space on the SAP server drops below 10%. How do you
configure CCMS alerts?
Answer & Explanation:

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 27 of 47

CCMS (Computing Center Management System) is SAP's integrated monitoring framework. RZ20 provides
the central alert monitor, and various methods exist for configuring thresholds and sending alerts.
CCMS Architecture: - Monitor Trees (MTE - Monitor Tree Elements): Hierarchical collection of monitoring
objects (system availability, buffer, workload, jobs, etc.). - Alert Methods: Define what happens when an
alert is triggered (auto-reaction methods). - CCMS Agents: Collect monitoring data from SAP and OS
systems.
Setting Up Monitoring (RZ20):
Step 1: Open Alert Monitor (RZ20): - RZ20: CCMS Monitor Sets. - Default monitors: SAP CCMS Monitor
Templates > Entire System. - View the monitoring tree with current alert states: Green/Yellow/Red.
Step 2: Configure Thresholds (RZ21): - RZ21: CCMS Monitoring Infrastructure Settings. - Navigate to
specific MTE (e.g., CPU Utilization). - Set threshold: Warning at 80%, Alert at 85%. - Similar for disk space:
Warning at 15%, Alert at 10%.
Step 3: Define Auto-Reaction Methods (RZ21 / SMSY): Auto-reaction methods execute when an alert is
triggered. Options: - Send email notification (standard method CCMS_SEND_NOTIFICATION). - Execute
ABAP function module. - Call external program.
Configure Email Alert: 1. RZ21 > Define Methods > Select CCMS_SEND_NOTIFICATION. 2. Configure
email recipient(s): basis_team@[Link]. 3. Set SMTP: Ensure SCOT is configured for email
sending. 4. Assign the method to the specific MTE (CPU, Disk, Jobs).
Step 4: Assign Alert Methods to MTEs: - In RZ20: Navigate to the MTE (CPU Utilization node). - Right-click
> Properties > Assign Method. - Assign the email notification method. - Set trigger conditions: When alert
level goes to RED.
Background Job Failure Alerts: - In RZ20: Navigate to Background Processing > Job monitoring. - Set up
alert for "Job cancelled" events. - Assign email notification method.
SAP Solution Manager Monitoring (For Enterprise): For larger landscapes, SAP Solution Manager
(SolMan) provides centralized monitoring: - DSWP: SAP Solution Manager Workcenter. - Configure:
System Monitoring, Job Monitoring, Interface Monitoring. - SolMan agents (diagnostics agents) installed on
each SAP system send data to SolMan. - Dashboard: Real-time status of all systems in the landscape. -
Alert Inbox: All alerts in one place with acknowledgment workflow.
Additional Monitoring Setup: - OS-Level: Set up OS monitoring (Nagios, Zabbix, SolarWinds) for
infrastructure alerts. - Database: HANA Cockpit alerts for HANA-specific issues. - Application: CCMS for
SAP application-level monitoring.
Key T-Codes: RZ20, RZ21, SCOT, SMSY (for SolMan), DSWP (SolMan)

Scenario 29: SAP Archiving and Data Volume Management

Q: The production database has grown to 5TB and performance is degrading. The client wants
to archive old data while keeping it accessible for reporting. How do you implement SAP data
archiving?
Answer & Explanation:
SAP Data Archiving moves completed business objects from the database to archive files, reducing
database size while maintaining data accessibility for legal/reporting purposes.
SAP Data Archiving Concepts: - Archiving Objects: SAP-defined units of data that can be archived together
(e.g., FI_DOCUMNT for FI documents, MM_MATBEL for material documents, SD_VBRK for billing
documents). - Archive Files: Sequentially written files on filesystem or external storage. - Archive
Information System (AS): Allows access to archived data without bringing it back to the database.
Data Archiving Process (SARA):
Step 1: Check Archivability: - SARA: Archive Administration. - Enter archiving object: FI_DOCUMNT. - Run
"Check Program" to see which documents are eligible for archiving. - Eligibility depends on: Retention
period, document status, open items.
Step 2: Configure Archiving: - SARA > Customizing: Set archive file path, file size, and number of data
objects per file. - Also configure: Logical file name and path (in FILE transaction).
Step 3: Write Phase (Creating Archive Files): - SARA > Start archiving. - The write program selects eligible
data, writes to archive files, and marks records in the DB. - Runs as a background job. - Output: Archive
files in the configured path.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 28 of 47

Step 4: Delete Phase (Removing from Database): - After write phase: Run the delete program. - Removes
successfully archived records from the database. - THIS IS IRREVERSIBLE - always test thoroughly in
DEV/QAS first. - Note: Write and delete are separate steps intentionally - allows verification before deletion.
Step 5: Store Archive Files: - Move archive files to long-term storage: NAS, SAP Content Server, AWS S3,
etc. - SAP Content Server integration via CSAD transaction. - Ensure archive files are backed up and
retained per legal requirements (typically 7-10 years).
Accessing Archived Data: - Archive Information System (AS): /SDF/SARA > Archive Info System. - Create
archive infostructures for the archiving object. - Allows search and display of archived documents without
database restore. - Integrated with SAP Document Access (formerly DART) for external access.
Near-Line Storage (NLS) - Advanced: - SAP HANA Native Storage Extension (NSE): Keep data in HANA
but on cheaper disk tier. - SAP Data Tiering: Move cold data to SAP IQ or Sybase IQ while keeping it
accessible via standard SAP transactions. - Typical result: 40-60% database size reduction after archiving
3+ years of old data.
Key T-Codes: SARA, FILE, CSAD, /SDF/SARA, DB02, DB13 (Database Administration) Compliance
Note: Define archiving retention policy with Legal and Finance teams before archiving. Prematurely
archived data cannot be easily restored.

Scenario 30: SAP Solution Manager Configuration Basics

Q: Your project requires setting up SAP Solution Manager (SolMan) for technical monitoring of
the SAP landscape. What are the key configuration areas and how does SolMan support the
Basis team?
Answer & Explanation:
SAP Solution Manager (SolMan) is the central platform for managing the SAP landscape, including
technical monitoring, change management, service desk, and test management.
Key SolMan Capabilities for Basis:
1. System Landscape Directory (SLD / LMDB): - All SAP systems register in SolMan's LMDB (Landscape
Management Database). - Configuration: T-code SMSY or new LMDB. - Each SAP system has a
registered system ID, product version, and role. - Pre-requisite for all other SolMan functionality.
2. Technical System Monitoring (DSWP): - Central monitoring dashboard for all managed systems. -
Monitors: System availability, CPU/memory/disk, job monitoring, interface monitoring. - Configuration: Run
the "Guided Configuration" wizard in SolMan > Technical Monitoring. - Requires: SAP Diagnostics Agent
installed on each monitored system.
3. Change Request Management (ChaRM): - Replaces manual transport management with a governed
workflow. - Change types: Normal Change (tested), Emergency Change (for critical fixes), Maintenance
Change. - Integration with STMS: ChaRM controls which transports can be imported to each system. -
Approval workflow: Request > Development > Testing > Approval > Production Import. - Basis role:
Configure transport routes and import rules in ChaRM.
4. Service Desk (Incident Management): - Integrated incident management ticketing system. - End users
create tickets in SolMan. - Auto-routes to support teams based on component/system. - Integration with
SAP Support: Submit OSS messages directly from SolMan ticket.
5. Early Watch Alert (EWA): - Weekly automated health check report for each managed SAP system. -
Covers: Performance, security, database, and configuration issues. - Transaction: DSWP > EarlyWatch
Alert. - Schedule and review EWA reports monthly as a Basis best practice.
6. Maintenance Optimizer (MOPZ): - Calculates the correct Support Package stack for system upgrades. -
Avoids SP compatibility issues by considering all installed components. - Required before downloading SPs
for major upgrades.
SolMan Setup for New System: 1. Register system in LMDB. 2. Install Diagnostics Agent on managed
system. 3. Connect Diagnostics Agent to SolMan. 4. Run Technical Monitoring configuration wizard. 5.
Verify system appears green in Technical Monitoring dashboard.
Key T-Codes: SMSY, LMDB, DSWP, SOLAR01 (Solution Documentation), SOLMAN_SETUP Best
Practice: Every SAP landscape should have a SolMan instance. It is free with SAP contracts and
provides significant value for proactive monitoring and governance.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 29 of 47

Chapter 9: SAP Basis – Advanced Interview
Scenarios
Scenario 31: SAP System Copy for Migration to S/4HANA
Q: Your client wants to migrate from SAP ECC 6.0 to SAP S/4HANA 2023 using the System
Conversion approach. What is the Basis consultant's role in this migration?
Answer & Explanation:
S/4HANA conversion is one of the most significant SAP projects. The Basis consultant's role is critical in
the technical preparation and execution phases.
S/4HANA Conversion Approaches: 1. System Conversion (Brownfield): Convert existing ECC system to
S/4HANA. Preserves customizations and data. Uses the SUM (Software Update Manager) tool. 2. New
Implementation (Greenfield): Fresh S/4HANA install. Start clean. High cost, long project. 3. Selective Data
Transition (Bluefield): Migrate only selected data/processes to new S/4HANA. Uses SAP Data Migration
tools.
Basis Role in System Conversion:
Phase 1: Pre-Conversion Assessment: - Run Maintenance Planner (MOPZ) to generate the conversion
stack (list of SPs and packages needed). - Run SAP Readiness Check 2.0: Identifies: Custom code that
needs adaptation, deprecated transactions, missing prerequisite SPs, database compatibility. - Run SGEN
(Generate ABAP Programs): Pre-generate all ABAP loads to reduce downtime. - Hardware check:
S/4HANA on HANA requires significant more RAM than AnyDB ECC. Typical: 4-8x more RAM.
Phase 2: System Setup: - Install SAP HANA database (if migrating from Oracle/DB2/SQL Server). - If
migrating database: Use DMO (Database Migration Option) within SUM tool. DMO migrates DB and
upgrades SAP in a single downtime window. - Prepare the target server with correct OS, HANA, and
kernel.
Phase 3: Conversion Execution (SUM Tool): - SUM (Software Update Manager): The primary tool for
S/4HANA conversion. - Download SUM from SAP Marketplace. - Run SUM on the SAP system: it guides
through phases: PREPARE: System checks, pre-import preparation. PREPROCESSING: SPDD/SPAU
checks (modification adjustments needed). IMPORT: Core import of new SAP software.
POSTPROCESSING: Activation, migration cockpit (FIORI), ABAP code adaptation. - During downtime
window: MAIN_SWITCH phase where all users must be disconnected. - Basis manages the SUM run,
monitors logs, resolves errors.
Phase 4: Post-Conversion: - Verify S/4HANA version: SM51 > System Information. - Run SICK (Installation
Check) transaction. - Verify HANA statistics and indexing. - Update SAP Kernel to S/4HANA compatible
version. - Reconfigure Fiori (new Fiori is central in S/4HANA). - Verify all interfaces and RFC connections. -
Performance testing: Run workload tests to verify HANA performance.
Key Tools: SUM, MOPZ, Maintenance Planner, SAP Readiness Check, SWPM, HANA Studio
Important: Always perform at least 2-3 trial conversions in DEV/QAS before the production
conversion. Document downtime accurately.

Scenario 32: Kernel and Patch Strategy for Production

Q: Explain how you build and maintain a SAP kernel patching strategy for a production
landscape to stay current with security patches while minimizing risk.
Answer & Explanation:
A structured SAP kernel patching strategy balances security compliance, stability, and minimal production
downtime. The SAP kernel is the core executable layer of SAP.
SAP Kernel Overview: The SAP kernel consists of: Dispatcher (disp+work), Gateway (gwrd), ICM (icman),
Message Server (msg_server), Enqueue Server (enserver), and various other executables. The kernel is
specific to: OS + DB + SAP version.
Patching Strategy Framework:

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 30 of 47

1. Patch Classification: - Security Patches (SAP Security Notes): Immediate priority. Apply within defined
SLA (typically 14-30 days for critical). Check SAP Security Patch Day (second Tuesday of each month). -
Bug Fix Patches: Apply quarterly or as needed based on encountered issues. - Feature Updates: Apply
during major upgrade cycles.
2. Kernel Version Policy: - Stay within 2 patch levels of the latest stable kernel release. - Don't always apply
the "latest" kernel on day of release. Wait 2-4 weeks for community feedback. - Reference: SAP Kernel
Patch Level (KPL) on [Link].
3. Patching Schedule: - DEV: Every month (keep current, test new patches first). - QAS: Every quarter or
before major testing cycles. - PRD: Every 6 months or when a critical security note mandates it.
Execution Steps (Kernel Upgrade): 1. Download kernel from [Link] > Software Downloads >
Kernel. 2. Select: Correct OS (Linux x86_64), DB (HANA), kernel version (e.g., 7.89). 3. Stop the SAP
system (sapcontrol stop or stopsap). 4. NEVER stop the database for a kernel-only update. 5. Backup old
kernel: cp -rp /usr/sap/<SID>/exe /usr/sap/<SID>/exe_old_YYYYMMDD. 6. Unpack new kernel: SAPCAR -
xvf SAPEXE_xxx.SAR -R /usr/sap/<SID>/exe. 7. Set permissions: chown -R <sidadm>:sapsys
/usr/sap/<SID>/exe. 8. Start the SAP system. 9. Verify: /usr/sap/<SID>/exe/disp+work -version | head -5.
10. Check SM21 for any new errors after startup.
Security Note Application (SNOTE): - SNOTE: SAP Note Assistant. - Used to apply individual SAP
correction notes to the system. - Download .txt note file from [Link] > upload to SNOTE > Apply.
- Note: SNOTE applies code corrections. Some notes require manual configuration steps.
Version Management: - Maintain a version tracker: System > Current Kernel > Next Planned > Last
Updated. - Use SAP Maintenance Planner (MOPZ) to validate kernel compatibility with SP stack.
Key T-Codes: SNOTE, SPAM (for SP patches), SM21, AL11 OS Commands: SAPCAR (unpack),
disp+work -version, sapcontrol SAP Note 19466: Kernel version and maintenance schedule
reference.

Scenario 33: Troubleshooting User Login Issues

Q: Multiple users from a specific department are unable to log into SAP this morning. Other
users in different departments are logging in successfully. How do you systematically diagnose
and fix this?
Answer & Explanation:
Login issues can have many causes. A systematic diagnosis approach prevents wasted time and ensures
the right fix is applied.
Immediate Triage:
Step 1: Gather Information: - How many users affected? Same department = common role/system issue. -
What error message are they receiving? (Collect exact error text + message number). - When did it start?
Any changes last night? (Transports, password policy changes, patches). - Are they using SAP GUI or
Fiori? What server/client are they pointing to?
Common Error Messages and Diagnoses:
A) "Client <xxx> does not exist": - Wrong client entered in SAP GUI. - Check SCC4: Verify the client exists
and is active. - Solution: Tell user the correct client number.
B) "Name or password is incorrect": - Wrong password or username. - Check SU01: Is the user locked? Is
the password expired? - Check if a transport was imported that changed user records. - Solution: Unlock
user (SU01), reset password.
C) "User is locked after too many incorrect logon attempts": - login/fails_to_user_lock parameter threshold
exceeded. - Check SM21 for the exact time of lockout. - Solution: SU01 > Unlock user. Investigate why.
D) "You do not have authorization to access client <xxx>": - The user's authorization does not include
access to that client. - Check SCC4: Client access permission (Protection level). - Check user's profile:
Does the user have cross-client access?
E) Login Hangs / Times Out: - SAP system overloaded: Check SM66 / SM50. - All dialog work processes
busy: Check SM50 for stuck processes. - Logon group misconfigured: Check SMLG.
F) "System is currently being updated" (Update module running): - Check SM13 for update records being
processed. - If backlog is severe: SM13 > Delete old/failed update records (with caution).
Department-Specific Issue Investigation: Since only one department is affected: - Check if a role was
accidentally removed: SUIM > Users > By Role. - Check if a transport was imported that changed

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 31 of 47

authorizations. - Check if the users' validity period expired: SU01 > Logon Data tab. - Check if a new
password policy was applied to a specific user group: SECPOL.
After 1-2 users are fixed, apply the same fix to all affected users via SU10 (mass change).
Preventive Actions: - Maintain a test user in each department to quickly verify login status. - Configure
CCMS alerts for user lockout events. - Review SM20 (Security Audit Log) for patterns of failed logins.
Key T-Codes: SU01, SU10, SM04, SM21, SM20, SUIM, SCC4, SMLG, SECPOL

Scenario 34: IDOC Processing and Monitoring

Q: Sales orders from an external e-commerce platform are not being created in SAP. The
interface uses IDocs to send order data. How do you investigate and resolve IDoc processing
failures?
Answer & Explanation:
IDocs (Intermediate Documents) are SAP's standard data containers for EDI and ALE (Application Link
Enabling) integration. When IDoc processing fails, business transactions are not created in SAP.
IDoc Architecture: - Inbound IDoc: External system sends data to SAP (e.g., sales orders from e-
commerce). - Outbound IDoc: SAP sends data to external system (e.g., shipping confirmations). - IDoc
Type: Defines the structure and segments (e.g., ORDERS05 for purchase orders, DESADV1 for delivery
notifications). - Message Type: Business context (e.g., ORDERS, DESADV, INVOIC). - Partner Profile:
Defines how IDocs are processed for each trading partner.
Diagnosing Inbound IDoc Failures:
Step 1: IDoc Monitor (WE02 / WE05): - WE02: IDoc List (all IDocs). - Filter by: Direction (Inbound), Status,
Date/Time, Message Type (ORDERS). - IDoc Status Codes: 02: IDoc passed to application (success). 51:
Application document not posted (application error - most common issue). 53: Application document posted
successfully. 56: IDoc with errors added to the error queue. 64: IDoc waiting to be transferred. 65: Error
when processing (technical error).
Step 2: View IDoc Details: - WE02 > Select a failed IDoc > Double-click. - IDoc Overview: Shows all
segments with data. - Status Records tab: Shows each processing step and error message. - For status 51:
Read the application error message. Often refers to missing master data (e.g., material not found, customer
not found).
Step 3: Resolve Application Errors (Status 51): - Missing Material: Material number in IDoc does not exist in
SAP. Verify in MM03. Create or map to correct material. - Missing Customer: Customer number not found.
Check XD03. Maintain customer or correct the customer ID mapping. - Mandatory Field Missing: IDoc
segment missing required data. Check partner profile configuration in WE20. - Posting Errors: FI posting
failed (wrong account, period closed). Fix the underlying condition.
Step 4: Reprocess IDoc: - After fixing the root cause: WE19 (Test Tool for IDoc Processing) for individual
IDocs. - BD87: Process Inbound IDocs. Select failed IDocs by: Date, message type, partner. Execute: Start
immediate processing. System re-processes the IDocs.
Step 5: Partner Profile Check (WE20): - WE20: Maintain Partner Profiles. - Select partner (e.g., the e-
commerce platform's partner ID). - Inbound Parameters tab: Verify Message Type (ORDERS), Process
Code (ORDE - standard for sales orders), and processing mode (Trigger immediately vs. Collect IDocs).
Monitoring Setup: - WE06: Set up active IDoc monitoring with automatic alerts. - Schedule BD88/BD87 as
background job to process queued IDocs regularly. - Set CCMS alerts (RZ20) for IDoc error threshold.
Key T-Codes: WE02, WE05, WE20, WE19, BD87, BD88, SM58 (tRFC error monitoring)

Scenario 35: SAP Logon Groups and Load Balancing

Q: Your SAP production system has 3 application servers. Users connecting to a single server
are experiencing slow response times, while the other servers are underutilized. How do you
configure load balancing?
Answer & Explanation:
SAP Load Balancing distributes user sessions across multiple application servers to optimize resource
utilization and provide better performance. This is configured through Logon Groups.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 32 of 47

SAP Load Balancing Architecture: - Message Server: Central component that knows the capacity of all
application servers. - Logon Group: A named group of application servers. Users connect to a group (not a
specific server). - SAP GUI Login: User specifies the Message Server and Logon Group, not a specific
application server. - Dynamic Assignment: Message Server assigns the user to the application server with
the most free capacity.
Configuring Logon Groups (SMLG):
Step 1: Create Logon Groups: - SMLG: Maintain Logon Groups. - Click "Create Entry." - Group Name:
DIALOG (default), or custom names: FI_USERS, PRODUCTION, HR, etc. - Assign Application Servers:
Select which servers belong to this group. - Add all 3 application servers to the DIALOG group.
Step 2: Set Capacity Weights (Optional): - If servers have different hardware capacities: Set relative
weights. - Example: Powerful server = weight 3; weaker server = weight 1. - More sessions are assigned to
higher-weight servers.
Step 3: Configure User Login: - SAP GUI: In login entry, change "Application Server" to "Message Server."
- Server field: Enter Message Server hostname. - System ID field: SID. - Logon Group field: DIALOG (or
the specific group). - Users are now load-balanced automatically.
Step 4: Monitor Logon Distribution (SMGW / AL08): - AL08: All logged-on users across all servers. -
Shows: Per-server user count, active sessions. - Verify balanced distribution after changing login
configuration. - SM66: Work process utilization per server.
Background Job Load Balancing: - SM61: Background Processing Server Groups. - Create server groups
for background jobs: BG_JOBS_GROUP. - Assign servers to the background group. - In SM36, assign jobs
to specific server groups.
Additional Load Balancing Considerations: - Dedicated Servers: Consider a dedicated application server for
batch jobs (type B work processes only) to prevent batch jobs from consuming dialog work processes. -
SMLG for RFC Load Balancing: RFC clients can also use logon groups for load-balanced RFC connections
(Type L RFC destination in SM59). - Monitor regularly: Use ST03N workload monitor to see per-server load
distribution.
Expected Result After Configuration: - Users distribute across all 3 servers automatically. - No single server
is overloaded. - Response times improve due to better resource utilization. - Provides redundancy: If one
server is stopped for maintenance, users are re-assigned to remaining servers.
Key T-Codes: SMLG, AL08, SM66, SM50, ST03N, SM61 (Background Groups)

Scenario 36: Database Backup Strategy for SAP HANA

Q: Define a comprehensive HANA database backup strategy for a production SAP S/4HANA
system. What types of backups are needed, and how do you verify backup health?
Answer & Explanation:
A robust HANA backup strategy is critical for data protection and disaster recovery. HANA backup is
different from traditional databases due to its in-memory architecture.
HANA Backup Types:
1. Full Data Backup: Backs up all data currently in the HANA database. Frequency: Daily (during low-usage
period, e.g., 11 PM). Duration: Depends on DB size. A 1TB DB typically takes 30-90 minutes. Command:
BACKUP DATA USING FILE ('daily_full_YYYYMMDD'); Or via HANA Studio: Backup > Create Backup.
2. Incremental Backup: Backs up only data pages changed since the last full backup. Frequency: Every 4-6
hours (or as needed based on change rate). Faster than full backup; smaller files. Command: BACKUP
DATA INCREMENTAL USING FILE ('incremental_HH');
3. Delta Backup: Backs up changes since the last full OR incremental backup. Faster than incremental;
smallest files.
4. Log Backup (Transaction Log / Redo Log): CRITICAL: Backs up the HANA redo logs (write-ahead log
segments). Frequency: Every 15-30 minutes (configured as automatic in HANA). Required for: Point-in-
time recovery. Without log backups: Recovery is only possible to the last full/incremental backup.
Configuration: HANA Studio > Configuration > [Link] > [persistence] > log_backup_interval_mode =
auto.
Recommended Backup Schedule: - 11:00 PM Daily: Full data backup to primary backup storage
(NAS/SAN). - Every 6 hours: Incremental or delta backup. - Every 15-30 minutes: Automatic log backup. -

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 33 of 47

Weekly: Copy full backup to DR site or cloud (AWS S3, Azure Blob). - Monthly: Full backup to long-term
archive storage.
Backup Verification (Critical but Often Overlooked):
1. HANA Backup Catalog (HANA Studio / HANA Cockpit): - View all backup history: start time, end time,
size, location, status. - Success indicator: All backups should show "successful." - Failed backup: Shows
"failed" with reason code.
2. Alert for Failed Backups: - Configure HANA Cockpit alerts for backup failures. - Email notification to
Basis team if any backup fails.
3. Restore Test (Monthly/Quarterly): - CRITICAL: Verify backups by actually restoring to a test system. -
Many organizations back up but never verify the restore works. - Run RECOVER DATABASE from the
backup catalog. - Verify data integrity after restore. - Document RTO (recovery time) for planning purposes.
4. DB13 (DBA Planning Calendar - for Oracle/AnyDB): For non-HANA databases: DB13 manages backup
schedules and shows history.
Key SQL Commands for HANA Backup: BACKUP DATA USING FILE ('path'); -- Full backup
BACKUP DATA DIFFERENTIAL USING FILE ('path'); -- Differential SELECT * FROM
SYS.M_BACKUP_CATALOG; -- View backup history RECOVER DATABASE UNTIL TIMESTAMP
'<ts>' USING BACKUP PATH '<path>'; -- Recovery
Key Tools: HANA Studio, HANA Cockpit, DB02, AL11 (backup path verification)

Scenario 37: SAP Single Sign-On (SSO) Implementation

Q: Your client wants users to be able to log into SAP without entering separate
username/password after logging into their Windows workstation. Explain how to implement
SAP SSO.
Answer & Explanation:
SAP Single Sign-On (SSO) allows users to access SAP systems using their Windows (Active Directory)
credentials, eliminating the need for separate SAP passwords. This improves user experience and security.
SAP SSO Methods:
1. Kerberos / Active Directory SSO (Most Common): - Uses Windows Kerberos tickets for authentication. -
Users log into Windows once; SAP GUI or Fiori uses the Windows ticket. - Requires: SAP Cryptographic
Library, GSS-API integration.
2. SAML 2.0 SSO (For Web/Fiori): - Uses Security Assertion Markup Language (SAML). - Identity Provider
(IdP): Azure AD, Okta, ADFS. - Service Provider: SAP NetWeaver/S/4HANA. - Ideal for Fiori and web-
based access.
3. X.509 Client Certificates: - Digital certificates stored on workstation. - SAP authenticates the certificate
instead of password.
Kerberos SSO Implementation Steps:
Step 1: Prerequisites: - SAP Cryptographic Library ([Link]) must be installed. - SAP kernel version
must support GSS-API. - Active Directory domain environment. - SAP system must be registered as a
Service Principal Name (SPN) in AD.
Step 2: Configure SAP Cryptographic Library (STRUST): - STRUST: SSL/TLS and Kerberos Trust
Manager. - Configure: GSS-API method with Kerberos. - Import: Kerberos realm information from AD.
Step 3: Register SPN in Active Directory: - On Windows DC: setspn -A SAP/<SID>
<domain><sap_service_account> - This allows Kerberos tickets to be issued for the SAP system.
Step 4: Configure Login Module (NetWeaver AS ABAP): - SPNEGO (Simple and Protected GSSAPI
Negotiation Mechanism) configuration. - Transaction: SPNEGO. - Configure Kerberos realm and keytab
file.
Step 5: Profile Parameters (RZ10): - login/ticket_only_by_https = 1 (for security). - icm/HTTPS settings
must be active.
Step 6: User Mapping: - Each SAP user must have a corresponding UPN (User Principal Name) or SID
mapped. - SU01 > Alias tab: Map the Windows UPN to the SAP user. - Or use LDAP synchronization
(LDAP Connector - LDAP transaction) for bulk mapping.
Step 7: Test SSO: - Log into Windows workstation. - Open SAP GUI or Fiori URL. - System should log in
automatically without password prompt.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 34 of 47

SAML 2.0 for Fiori (Simpler for Web): 1. In Azure AD: Register S/4HANA as an Enterprise Application. 2.
Download Federation Metadata XML from Azure AD. 3. In SAP (SAML2 transaction): Import IdP metadata,
configure trust settings. 4. Map SAML attributes (email) to SAP user names. 5. Test: Access Fiori URL -
redirected to Azure AD login - SSO works.
Key T-Codes: STRUST, SPNEGO, SAML2, LDAP, SU01 Security Benefit: SSO eliminates
shared/weak SAP passwords. All authentication is managed by Active Directory with stronger
password policies and MFA.

Scenario 38: SAP Router Configuration

Q: Your client needs to allow SAP support engineers remote access to the production system
for maintenance, but cannot open direct firewall ports. How does SAP Router provide secure
remote access?
Answer & Explanation:
SAP Router is a standalone program that acts as a secure proxy/relay for SAP-specific traffic. It is SAP's
standard mechanism for allowing SAP Support to securely connect to customer systems over the internet.
SAP Router Overview: - Acts as a firewall-friendly application proxy. - Only opens TCP port 3299 (SAP
Router default port) or 443 (HTTPS). - All traffic is routed through the SAP Router. - SAP Router enforces
access control via the Route Permission Table (saprouttab).
SAP Remote Access Topology: External SAP Support ([Link]) <--> Internet <--> Customer
SAPRouter <--> Internal SAP System.
Installation: 1. Download SAP Router from [Link] > Tools > SAP Router. 2. Install on a DMZ
server (between external internet and internal SAP network). 3. Configure: Standalone executable niusers
(SAP Router binary). 4. Registration with SAP: Register your SAP Router at SAP Support Portal to
establish the secure tunnel.
Configuration - Route Permission Table (saprouttab): The saprouttab file controls which connections are
allowed through the router. Format: P/D <source_host> <source_port> <target_host> <target_port>
[password] P = Permit; D = Deny.
Example entries: P * * <SAP_server_IP> 3200 (allow SAP GUI connections to production) P * *
<SAP_server_IP> 3300 (allow RFC connections) D * * * * (deny all others - default deny)
Starting SAP Router: Command: saprouter -r -R /usr/sap/saprouter/saprouttab & -r: Run as router. -R: Path
to route permission table.
Connecting via SAP Router (SAP GUI): Connection string:
/H/<router_IP>/S/3299/H/<sap_server_IP>/S/3200 /H/ = Host, /S/ = Service port.
SNC Integration: - Secure Network Communications (SNC) encrypts all traffic through SAP Router. -
STRUST: Configure SNC partner for SAP Router. - Provides end-to-end encryption even if the underlying
network is not encrypted.
Monitoring SAP Router: Command: saprouter -s (status - show active connections) Log file:
/var/log/[Link] or configured path. AL11: View router log files from SAP GUI.
Key Files: saprouttab (route permission), saprouter (binary), [Link] Key Commands:
saprouter -r (start), saprouter -s (status), saprouter -p (stop) Security: Regularly review saprouttab.
Remove old/unused routes. SAP Router access should be logged and periodically audited.

Scenario 39: Batch Input and LSMW Data Migration

Q: For a new plant rollout, 5,000 material masters need to be created in SAP. The data comes
from an Excel spreadsheet. How do you handle this mass data load as a Basis consultant?
Answer & Explanation:
Mass data loading for SAP implementation projects is typically handled using LSMW (Legacy System
Migration Workbench) or SAP Data Services. As a Basis consultant, you support the technical
infrastructure and troubleshoot errors.
Data Migration Methods in SAP:

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 35 of 47

1. LSMW (Legacy System Migration Workbench): Built-in SAP tool for migrating legacy data using: Direct
Input, Batch Input (BDC), BAPI, or IDoc. No additional license required. Best for: Simple to medium
complexity data loads.
2. Batch Data Communication (BDC / Session Method): Records keystrokes in a SAP transaction, replays
them with real data. Susceptible to screen changes between releases. Used by LSMW underneath for
many scenarios.
3. BAPI (Business Application Programming Interface): Standard SAP function modules designed for
external data input. More stable than BDC (not dependent on screens). Example:
BAPI_MATERIAL_SAVEDATA for material master creation.
4. SAP Data Services (DS) / SAP Migration Cockpit: For S/4HANA: SAP Migration Cockpit (LTMC) is
recommended. Provides pre-built migration objects for master data and transactional data. No custom
ABAP coding needed.
LSMW for Material Master Creation:
Step 1: Create an LSMW Project: - LSMW: Legacy System Migration Workbench. - Create Project >
Subproject > Object. - Select Method: BAPI for material master (BAPI_MATERIAL_SAVEDATA).
Step 2: Define Field Mapping: - Map source Excel columns to SAP field names. - Example: Excel
"Description" column -> SAP MAKTX (material description) field. - Handle transformations: Data type
conversions, default values for empty fields.
Step 3: Read Data: - Import the Excel data (saved as .txt/CSV). - LSMW converts it to SAP internal format.
Step 4: Execute in Test Mode: - Run in simulation mode first: No actual records are created. - Review error
log: Mandatory field errors, invalid values, duplicate materials. - Fix source data issues.
Step 5: Execute in Live Mode: - After successful test: Run live. - Monitor: Number of records created,
errors. - Review results: SE16 > MARA table to verify materials were created.
SAP Migration Cockpit (LTMC - For S/4HANA): 1. LTMC: Migration Cockpit. 2. Select migration object:
"Materials". 3. Download template (Excel format). 4. Populate template with material data. 5. Upload >
Simulate > Migrate. 6. Monitor migration results. Fix errors in the Excel and re-upload.
Basis Role in Data Migration: - Configure LSMW/LTMC technical settings. - Monitor system performance
during mass uploads (can impact production if run during business hours). - Schedule uploads during off-
peak hours via background jobs. - Monitor database growth during large data loads. - Ensure transport
requests for LSMW projects are correctly handled across landscape.
Key T-Codes: LSMW, LTMC (S/4HANA), SM37 (monitor background jobs), SE16 (verify data)

Scenario 40: System Monitoring Dashboard and Proactive Basis

Q: Describe how you set up a proactive Basis monitoring routine for a 24/7 production SAP
system. What do you check daily, weekly, and monthly?
Answer & Explanation:
Proactive monitoring prevents issues from becoming outages. A structured monitoring routine is the
hallmark of a mature SAP Basis operations function.
DAILY MONITORING CHECKLIST:
System Availability (5 minutes): - SM51: Check all application servers are running and showing green. -
SMICM: ICM services (HTTP/HTTPS) active. - DB02 / HANA Cockpit: Database is running, no critical
alerts.
Error Log Review (10 minutes): - SM21: System log from last 24 hours. Look for: Red entries, work process
restarts, database errors. - ST22: ABAP dumps. Review any new dumps. Are they occurring for many
users? Same program repeatedly? - SM13: Update records. Any records stuck in error status?
Background Job Review (5 minutes): - SM37: All scheduled jobs. Status of last 24 hours. Any failed jobs?
Investigate immediately.
Performance Quick Check (5 minutes): - ST06: OS-level CPU and memory. Any spikes? - SM66: Any work
processes in PRIV or long-running state? - AL08: Number of logged-in users (normal vs. anomaly).
Spool / Print (5 minutes): - SP01/SP00: Any spool requests in error? Spool overflow? - SP12: TemSe
usage. Near capacity?
Security (5 minutes): - SM20: Security audit log. Any suspicious logon attempts? User changes? - SM12:
Long-standing lock entries.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 36 of 47

WEEKLY MONITORING CHECKLIST:
Performance Trend Review (30 minutes): - ST03N: Workload analysis. Average response times trend. Is
performance degrading week-over-week? - DB02: Database growth. Table size analysis. Any unexpectedly
large tables?
Transport Review (15 minutes): - STMS: Pending transports in QAS and PRD queues. Any failed imports?
- SE10: Open transport requests. Are developers leaving requests unfinished?
Disk Space (10 minutes): - AL11: Check all SAP directories. Transport directory (/usr/sap/trans/). Archive
logs. Backup directory. - ST06: OS-level disk usage per filesystem.
User Review (15 minutes): - SU10: Any users not logged in for 30+ days? Consider locking. - Newly
created users: Verify correct role assignments.
Interface Monitoring (15 minutes): - SM58: tRFC error queue (failed RFC calls). - WE02: IDoc errors from
last week. - PI/PO: Message Monitor for interface errors.
MONTHLY MONITORING CHECKLIST:
License Check (30 minutes): - USMM: Run system measurement. Compare against licensed quantities.
Security Review (1 hour): - SUIM: Users with SAP_ALL or critical profiles. SoD conflicts check. - SNOTE:
New security OSS notes published. Plan application.
Performance Baseline (1 hour): - ST03N: Monthly performance report. Create baseline document. -
Compare against previous month's metrics.
Backup Verification (2 hours): - Review backup logs for the entire month. - Perform a test restore to verify
backup integrity. - Check DR site backup copies.
EarlyWatch Alert (SolMan - 30 minutes): - Review monthly EWA report in Solution Manager. - Address any
recommended actions.
Key T-Codes: SM21, ST22, SM37, ST06, SM66, SM51, DB02, STMS, SU10, USMM, RZ20 Best
Practice: Create a Basis Operations Wiki or SharePoint page documenting all monitoring
procedures, escalation contacts, and known issues. Automate as much monitoring as possible via
CCMS and SolMan.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 37 of 47

Chapter 10: Advanced Scenarios & Interview
Preparation
Scenario 41: Critical Situation: Production System Down
Q: You receive a call at 3 AM that the production SAP system is completely down. End users
cannot log in. Walk through your complete incident response procedure.
Answer & Explanation:
A production system down is the highest-priority incident for a Basis consultant. A structured, calm, and
systematic response is required.
IMMEDIATE RESPONSE (First 5 Minutes):
Step 1: Verify the Issue: - Can YOU log in to SAP? Try from a different machine/network. - Is it a complete
outage or specific users/transactions? - Check SAP system from the server OS level: Are SAP processes
running?
From OS (as <sidadm>): sapcontrol -nr <instance_number> -function GetSystemInstanceList If SAP is
down: You will see "GRAY" status or empty output.
Step 2: Check Database First: HANA: su - <sdbadm>; HDB info (see if HANA processes are running) If
HANA is down: This is the primary cause. Start HANA: HDB start Wait for HANA to fully start before
starting SAP application layer.
Step 3: Check SAP Application Layer: If HANA is running but SAP is not: Start SAP: sapcontrol -nr
<instance_number> -function Start Or: /usr/sap/<SID>/<instance>/exe/startSAP
Step 4: Check OS Resources: df -h: Disk space. Is any filesystem 100% full? A full filesystem causes SAP
to crash. free -m: Memory. Is swap full? top: CPU usage. Any runaway processes?
INVESTIGATION PHASE (Next 15 Minutes):
Step 5: Read System Logs: - SM21 (once SAP starts): Check for the error before shutdown. -
/usr/sap/<SID>/D<xx>/work/dev_disp: Dispatcher trace file. -
/usr/sap/<SID>/D<xx>/work/dev_w0...dev_wN: Work process trace files. HANA:
/usr/sap/<HANA_SID>/HDB<instance>/trace/nameserver_alert_<host>.trc
Step 6: Identify Root Cause: Common Causes: A) Disk full: /usr/sap/trans/ directory full. Solution: Delete
old transport files. B) HANA out of memory: HANA was killed by OOM killer. Solution: Restart HANA,
increase swap, unload tables. C) ASCS failure: Message server or enqueue server crashed. Solution:
Restart ASCS, check cluster status. D) Network outage: SAP server lost network to database. Solution:
Check network with ping, call network team. E) Kernel crash (OS level): Server rebooted unexpectedly.
Check OS logs: /var/log/messages (Linux).
COMMUNICATION (Throughout): - Within 5 minutes: Notify IT manager and business stakeholders. -
Every 30 minutes: Update status to incident ticket. - Document every action taken with timestamp.
RESOLUTION AND POST-INCIDENT: - Once system is running: Monitor closely for 1-2 hours. - Perform
root cause analysis: Why did it fail? - Implement preventive measures. - Write an incident report: Timeline,
root cause, resolution, prevention.
Key Files/Commands: sapcontrol, dev_disp, dev_w0, HDB commands, df -h, top, /var/log/messages
Golden Rule: Stay calm, communicate clearly, and be systematic. Jumping to conclusions wastes
time. Log everything.

Scenario 42: SAP Note Implementation and OSS Process

Q: A critical security vulnerability has been reported for your SAP system (CVSS score 9.8).
SAP has released a security note. How do you assess, plan, and implement the SAP security
note?
Answer & Explanation:
Security Notes implementation is an urgent and critical Basis activity. A structured approach ensures the fix
is applied correctly and quickly while minimizing risk.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 38 of 47

Understanding SAP Security Notes: - SAP releases security notes typically on the second Tuesday of each
month (SAP Security Patch Day). - CVSS Score: Common Vulnerability Scoring System. 9.8 = Critical. 7-
8.9 = High. - SAP Notes are available on: [Link] > My SAP Notes & KBAs.
Step 1: Impact Assessment: - Read the note description: What component is affected? (e.g., SAP_BASIS,
SAP_HR). - Is my system affected? Check: Note's Prerequisites section lists affected versions. - In the SAP
system: Run SNOTE > Note Analyzer, or check directly in SM59 > About system > Component versions. -
If your component version is in the affected range: You ARE vulnerable.
Step 2: Understand the Fix: - Read the "Solution" section of the note. - Correction type: Manual steps,
SNOTE (code correction), SP (Support Package), or configuration change. - Manual Steps: Often involve
SPRO configuration or parameter changes. - SNOTE: Automatic code patch applied via Note Assistant.
Step 3: Plan the Implementation: - Download the note from [Link]. - DEV first, then QAS, then
PRD. - Schedule emergency change request if CVSS 9+ (within 24-48 hours for production). -
Communicate planned downtime (if restart is required).
Step 4: Apply in DEV (SNOTE): - SNOTE: SAP Note Assistant. - Notes > Download SAP Note: Enter note
number. - Notes > Implement: System downloads and applies the correction. - Review: Objects modified by
the note. - Test: Verify the affected functionality works correctly.
Step 5: Apply in QAS and PRD: - If SNOTE: Apply same process in QAS and PRD. - If SP required: Apply
Support Package via SPAM (follow the SP patching process). - If manual config: Follow the exact steps
documented in the note.
Step 6: Verify Implementation: - SNOTE: Note should show status "Implemented" (green checkmark). -
Test the vulnerability: Many security notes have a test procedure in the note. - Check SM21 after restart for
any new errors.
Step 7: Document and Close: - Update the change request with: Note number, systems patched, date,
tester, results. - Track in security patch log maintained by Basis team. - Report to CISO/Security team:
Critical vulnerability remediated.
Emergency Note Application (CVSS 9+): - Get emergency change approval. - Apply directly to PRD with
minimal DEV testing if urgency demands. - Post-implementation: Follow up in DEV/QAS to ensure
consistency.
Key T-Codes: SNOTE, SPAM, SM21, ST22 SAP Resource: [Link] > Security Notes.
Subscribe to SAP security alerts email.

Scenario 43: SAP Basis Sizing and Hardware Recommendations

Q: Your client is procuring new hardware for a greenfield S/4HANA implementation for 500
users (350 dialog, 150 background). How do you perform SAP sizing?
Answer & Explanation:
SAP Sizing determines the hardware requirements (CPU, RAM, disk) for a new SAP implementation.
Correct sizing ensures performance without over-provisioning.
SAP Sizing Methods:
1. SAP Quick Sizer (Primary Tool): Available at: [Link] Web-based tool that
calculates hardware requirements based on: - Number of users by type (dialog, background, batch). -
Business transaction volumes. - Selected SAP applications (ERP, BW, etc.). - Output: Required SAPS
(SAP Application Performance Standard) and RAM.
2. Reference System Sizing: If migrating from existing system: Analyze current system performance
(ST03N, ST06) and size the new system proportionally.
Key Sizing Concepts:
SAPS (SAP Application Performance Standard): - 1 SAPS = ability to process 2,000 fully business-
processed Sales Order line items per hour (SD benchmark). - Used to compare hardware capability from
different vendors. - Example: HP ProLiant DL580 Gen10 = 60,000 SAPS (varies by configuration).
RAM for SAP HANA: Unlike traditional databases (where data is on disk), HANA keeps most data in RAM.
RAM must be large enough to hold: - Column Store: All active tables (compressed). Typical: 40-80% of
uncompressed table size. - Row Store: SAP system tables (~10-20 GB typically). - Heap Memory: Working
memory for processes (~50-100 GB for large systems). - Buffer Pool: Query result cache. Total RAM
Estimate: Compressed HANA data size + 30% overhead. Rule of thumb for 500 users: Start with 512 GB
RAM as a baseline. Use SAP sizing tools for exact numbers.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 39 of 47

CPU Sizing: - For 500 dialog users: Typically 4-8 physical CPU sockets with 10-20 cores each. -
Background jobs: Additional 20-30% CPU capacity. - HANA scales well with multi-core CPUs.
Disk Sizing: - HANA Data Volume: 3x expected RAM size (for data persistence and backups). - Log
Volume: 50% of data volume (for HANA redo logs). - Backup Volume: At least 3x data volume. - Use high-
performance SSDs (NVMe preferred) for HANA data and log volumes.
SAP HANA Certified Hardware: - SAP maintains a list of certified hardware:
[Link] - Always use certified hardware for
production HANA installations. - Uncertified hardware is not supported by SAP.
Sizing for 500 Users (Estimated): - RAM: 512 GB - 1 TB (HANA in-memory). - CPU: 2x Intel Xeon Platinum
(24-32 cores each) or equivalent. - SSD: 10-15 TB total (data + log + backup). - Network: 10 Gbps Ethernet
minimum; 25 Gbps recommended.
Key Resources: SAP Quick Sizer, SAP HANA Hardware Directory, SAP Note 1999997 (HANA sizing)

Scenario 44: Transport of Copies and Emergency Transport to Production

Q: A critical production bug needs an ABAP code fix immediately. The normal transport
process through QAS would take too long. How do you handle an emergency transport to
production?
Answer & Explanation:
Emergency transports to production (bypassing QAS) are sometimes necessary for critical production
bugs. However, they must be handled with strict controls to prevent introducing new issues.
When Emergency Transport is Justified: - Production system is completely unusable for critical business
operations. - Data loss or financial impact is occurring. - Normal QAS testing cycle cannot be completed in
time. - Management has formally approved the bypass.
Emergency Transport Process:
Step 1: Create a Hot-Fix in Production Clone or DEV: - Developer creates the fix in DEV. - If possible:
Apply the fix to a PRD clone first for verification. - Get development manager sign-off on the fix.
Step 2: Create a "Transport of Copies" (SE01/SE10): - Use "Transport of Copies" instead of standard
transport. - Purpose: Copies the objects into a new transport request without changing the original object's
assignment. The original development can still follow the normal path through QAS.
How to Create Transport of Copies (SE01): 1. SE01: Create a new transport request. Type: Transport of
Copies. 2. Add the objects to the request. 3. Release the request. 4. In STMS: The transport of copy
appears in the import queue. 5. Import directly into PRD (with proper approval and change request
reference).
Step 3: Formal Approval (Mandatory): - Change Management ticket with: Problem description, fix
description, risk assessment, approvals from: IT Manager, Business Owner, Change Advisory Board (CAB)
if applicable. - Document: Transport number, objects included, developer name, approver, date/time.
Step 4: Import into Production (STMS): - Basis admin imports the transport: STMS > PRD Import Queue >
Select TR > Import. - Monitor the import closely. - Return Code 0 or 4: Proceed. - Return Code 8+:
Investigate before proceeding (or rollback).
Step 5: Post-Import Verification: - Functional team performs a quick smoke test immediately after import. -
Verify the bug is fixed. - Monitor SM21 and SM37 for any new issues.
Step 6: Follow-Up (Within 48 Hours): - The same fix MUST also be imported into QAS and DEV to keep
systems in sync. - Document the deviation in the change log. - Update the transport tracking spreadsheet.
Risk Mitigation: - Always create a backup point (snapshot/backup) before emergency transport. - Have a
rollback plan: Can you reverse the transport (MR8M / SE03 unlock + reimport old version)? - Limit
emergency transports: They are exceptions, not routine practice.
Key T-Codes: SE01, SE10, STMS, SM21, SM37 Governance: Emergency transports to PRD without
QAS sign-off must be rare exceptions. Track all occurrences and review monthly in change
management forums.

Scenario 45: SAP Cloud Integration (BTP) – Basis Perspective

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 40 of 47

 Q: Your client is implementing SAP Business Technology Platform (BTP) integration with their
on-premise S/4HANA. What are the Basis responsibilities for SAP BTP connectivity?
Answer & Explanation:
SAP Business Technology Platform (BTP) is SAP's cloud platform for extensions, integrations, and
analytics. Basis consultants need to understand the connectivity between on-premise S/4HANA and BTP.
SAP BTP Architecture: - BTP Subaccounts: Organizational units in BTP. Each has its own resources,
services, and users. - BTP Services: Integration Suite, Extension Suite, Analytics Cloud, HANA Cloud, etc.
- Connectivity: On-premise S/4HANA connects to BTP via SAP Cloud Connector.
SAP Cloud Connector (SCC):
The Cloud Connector is installed on-premise and creates a secure tunnel to BTP. No inbound firewall ports
are required (tunnel is outbound).
Installation Steps: 1. Download SCC from [Link]. 2. Install on a dedicated on-premise server
(e.g., Linux/Windows). 3. Default port: 8443 (HTTPS admin portal). 4. Access admin UI:
[Link]
Cloud Connector Configuration: 1. Subaccount Configuration: Connect SCC to the BTP subaccount. - BTP
Cockpit > Connectivity > Cloud Connectors: Shows connected SCCs. - SCC Admin UI > Add Subaccount:
Enter BTP region, subaccount ID, user/password.
2. System Mapping (Exposed Backend Systems): - SCC Admin UI > Cloud To On-Premise > Add System
Mapping. - Internal Host: S/4HANA hostname (internal). - Virtual Host: A virtual hostname BTP will use
(hides real hostname from cloud). - Protocol: HTTP, HTTPS, RFC, LDAP. - Backend Type: SAP
NetWeaver Application Server ABAP.
3. Resource Access (URLs/RFCs to expose): - Under each system mapping, define which OData service
paths or RFC function modules are accessible. - Principle of least access: Only expose what is needed.
4. RFC Connections (For ABAP-based integrations): - Expose specific RFCs or BAPIs for BTP to call. -
Test connectivity from BTP Integration Suite.
S/4HANA Configuration for BTP Connectivity:
1. Communication Arrangements (S/4HANA): - /n/IWFND/MAINT_SERVICE: Activate OData APIs needed
by BTP. - Create Communication System (SM59 or newer /SCTS transactions) pointing to BTP endpoints. -
Create Communication User: Dedicated user for BTP integration (system user type). - Create
Communication Arrangement: Links communication system, user, and scenario.
2. ICM/HTTPS: - SMICM: Ensure HTTPS is active. - Import BTP root certificates into STRUST (SSL
client/server certificates).
Monitoring BTP Integration: - SCC Admin UI > Monitor: Active connections, traffic, errors. - S/4HANA:
SM21 for RFC/HTTP call errors. - BTP Integration Suite: Message monitoring for integration flows. - BTP
Cockpit > Connectivity: SCC connection status.
Key T-Codes: SMICM, STRUST, SM59, /IWFND/MAINT_SERVICE BTP Tools: Cloud Connector
Admin UI, BTP Cockpit, Integration Suite Operations SAP Note 2835207: Cloud Connector
performance tuning. SAP Note 2621200: SCC installation guide.

Scenario 46: SAP Upgrade Project – Basis Planning

Q: Your organization is planning an SAP ECC 6.0 to S/4HANA 2023 upgrade. As the lead
Basis consultant, what are your key responsibilities and activities across the project phases?
Answer & Explanation:
An S/4HANA upgrade is a major project lasting 6-18 months. Basis consultants have critical responsibilities
in every phase.
PROJECT PHASES AND BASIS ACTIVITIES:
Phase 1: Preparation and Discovery (1-2 months):
Technical Assessment: - Current system specs: OS, DB, kernel version, SP stack. - Hardware
compatibility: Is current hardware S/4HANA certified? - Database migration plan: Are you on AnyDB
(Oracle, SQL Server)? Plan HANA migration.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 41 of 47

SAP Readiness Check: - Install and run SAP Readiness Check 2.0 (standalone program + Maintenance
Planner). - Results: Custom code adaptation required, add-on compatibility, simplification items. - Review
with functional and development teams.
Sizing: - Run SAP Quick Sizer for the S/4HANA landscape. - Assess current database size vs. expected
HANA size. - Recommend hardware upgrades if needed.
Phase 2: System Setup (2-3 months):
Landscape Setup: - Install and configure new S/4HANA DEV, QAS, PRD systems. - Or: Plan in-place
conversion (convert existing ECC systems). - Configure STMS for the new landscape. - Configure Solution
Manager for the new systems.
Technical Infrastructure: - Install SAP HANA database. - Configure HA/DR (HSR for HANA, ASCS
clustering). - Configure SAP Router and network access. - Set up monitoring (CCMS, SolMan monitoring).
Phase 3: System Conversion (Core Project):
Trial Conversions (3-4 rounds): - Apply SUM tool to DEV system. - Learn and resolve technical issues in
each trial. - Measure downtime duration. - Optimize: Parallel processing, pre-generation (SGEN), NZDT
(near-zero downtime) options.
Functional team activities: - SPDD/SPAU: Review and merge custom modifications with new SAP
standard. - These are SAP Basis/development activities that must be planned carefully.
Production Conversion: - Final trial run in QAS simulating production conditions. - Define cutover plan:
Exact steps, timing, responsible persons. - Freeze period: Lock all changes 2 weeks before production
conversion. - Execute production conversion: Estimated downtime 4-48 hours depending on DB size and
parallelism.
Phase 4: Post-Conversion Stabilization:
Immediate (Week 1): - Monitor SM21, ST22, SM37 intensively. - Performance: ST03N, HANA memory,
CPU. - Interfaces: All RFC/IDoc connections. - User access: Fiori configuration, role assignments.
Short-term (Weeks 2-8): - Resolve defects from production usage. - Performance tuning (SQL optimization,
missing HANA indexes). - Apply first post-upgrade SP stack.
Key T-Codes: SPAM (SUM is external tool), SPDD, SPAU, SE10, STMS, SM21, ST03N Project Tools:
SAP Readiness Check, SAP Quick Sizer, Maintenance Planner (MOPZ), SUM, SWPM

Scenario 47: Handling SAP System Split (Client Independence)

Q: Your client is divesting a business unit. The SAP system contains both the retained
company and the divesting company's data. How do you technically separate the two
companies in SAP?
Answer & Explanation:
System splitting is a complex scenario requiring careful technical planning. SAP handles legal entity
separation through the Company Code structure, but splitting a system into two separate systems is a
major undertaking.
System Split Approaches:
Approach 1: Legal Entity Separation within Same System: - If both companies will continue to use the same
SAP system under different ownership, maintain separate company codes. - Authorization strategy: Use
company code-based authorization restrictions so each company's users can only see their own data. -
This is operationally simpler but may not satisfy the divestiture requirements.
Approach 2: Selective Data Migration (Technical System Split): For a true system split (two separate SAP
systems post-divestiture), use:
1. SAP Landscape Transformation (SLT): Replicates data from source to target system based on filters
(company code, plant, etc.). 2. CPYBAS (Company Code Copy) combined with selective migration tools. 3.
SAP System Data Transfer (DMO/SUM with migration): Complex but possible.
Basis Technical Steps for System Split:
Step 1: New System Setup: - Procure new SAP infrastructure for the divesting entity. - Install new SAP
system (SWPM-based installation). - Configure: Client, company code, organizational structure matching
the divesting entity.
Step 2: Transport Configuration Copy: - Export all configuration (not transactional data) via client export
(SCC8). - Import into new system (SCC7). - Remove configuration related to the retained company.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 42 of 47

Step 3: Master Data Migration: - Identify master data belonging ONLY to the divesting entity. - Migrate:
Vendor master (LFA1), Customer master (KNA1), Material master (MARA), General Ledger accounts. -
Tools: LSMW, LTMC, or custom ABAP extraction + load.
Step 4: Transactional Data Migration (If Required): - Open items: Open AR/AP, open POs, open sales
orders. - DART (Data Archiving and Retrieval Tool): Export data for compliance. - Historical data: Often not
migrated; kept in archive or read-only access to old system.
Step 5: Cutover: - Agree on a legal cutover date. - Post all outstanding transactions before cutover. - On
cutover date: New system goes live; old system access restricted for divested entity.
Step 6: Decommission (Post-Divestiture): - Old system (with both entities) must be retained for audit/legal
purposes. - Lock divested entity's users in the old system. - Put old system in read-only archive mode after
agreed period.
Legal and Compliance: - Data retention requirements: Both entities must retain access to historical data per
local regulations. - Tax requirements: Tax records typically need 7+ years retention. - Ensure audit trails
are preserved and accessible.
Key T-Codes: SCC4, SCC8, SCC7, LSMW, SE16, SU10, STMS

Scenario 48: SAP Internet Transaction Server (ITS) and Web Enablement
Q: Users need to access certain SAP transactions from a web browser (not SAP GUI). How
does SAP enable web-based access through ITS and what is the modern alternative?
Answer & Explanation:
SAP ITS (Internet Transaction Server) was the traditional mechanism for web-enabling SAP ABAP
transactions. In S/4HANA, it has been largely replaced by SAP Fiori, but ITS is still relevant in ECC and
hybrid landscapes.
Traditional SAP ITS Architecture: - WGate (Web Gate): Web server component handling HTTP requests. -
AGate (Application Gate): Interface between WGate and SAP system. - The ITS converts ABAP Dynpro
screens into HTML pages for browser rendering. - Limitation: UI quality is poor; basic HTML rendering of
SAP GUI screens.
Types of ITS Applications: 1. IAC (Internet Application Components): Standard SAP transactions web-
enabled via themes. 2. WebGUI: Any transaction can be opened in a web browser using SAP Web
Application Server.
SAP WebGUI Configuration (For Browser-Based SAP GUI Access): 1. ICM must be running: SMICM >
HTTP services active. 2. Access WebGUI: [Link] 3. This opens
a browser-based SAP GUI that works without the SAP GUI fat client. 4. Performance: Slower than SAP
GUI; better than nothing for occasional access.
Modern Alternative: SAP GUI for HTML / SAP Fiori:
SAP Fiori (Recommended): - Modern, responsive, role-based UI. - Works on any device (desktop, tablet,
mobile) without SAP GUI installation. - Replaces ITS completely for new development. - Activated and
configured by Basis via /IWFND/MAINT_SERVICE and Fiori configuration.
SAP Business Client (Transitional): - A browser-based container that can host both traditional SAP
transactions and Fiori apps side by side. - Acts as a bridge during the Fiori transition period.
Configuring Web Access (ICM):
Step 1: SMICM > Services > HTTP: - Verify HTTP and HTTPS services are in "Active" state. - Note the port
numbers: 80xx (HTTP), 443xx (HTTPS).
Step 2: Enable Services (SICF): - SICF: Service Configuration. - Activate the required web services:
/sap/bc/gui/sap/its/webgui (for WebGUI), /sap/bc/adt/ (for ABAP development tools), /sap/opu/odata/ (for
OData services). - Right-click service > Activate. - Inactive services return HTTP 404.
Step 3: SSL Configuration (STRUST): - For HTTPS: Import a valid SSL certificate. - STRUST > SSL Server
Standard > Import certificate. - Trusted CA certificates must also be imported for outbound HTTPS calls.
Step 4: Test Access: - Access the URL from a browser. - Verify: Page loads, login works, no SSL errors.
Key T-Codes: SMICM, SICF, STRUST, /IWFND/MAINT_SERVICE, /UI2/FLP Note: SAP will end
mainstream maintenance for SAP GUI for Windows in 2027. Planning the Fiori transition is
important for all Basis teams.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 43 of 47

 Scenario 49: SAP Basis Interview: Top Technical Questions
Q: Prepare concise, precise answers to the most commonly asked technical Basis interview
questions at the senior consultant level.
Answer & Explanation:
The following are the most frequently asked SAP Basis interview questions with expert-level answers:
Q1: What is the difference between a Dialog Work Process and a Background Work Process? A: Dialog
(DIA) processes handle interactive user sessions; limited to a configurable timeout (default 600 seconds).
Background (BGD) processes run jobs submitted via SM36; can run for hours. A dialog work process can
serve multiple users via multiplexing (roll-in/roll-out), while a background work process is dedicated to one
job at a time.
Q2: Explain SAP Extended Memory (EM) and how it works. A: SAP Extended Memory is shared memory
accessible by all work processes. When a user starts a transaction, their program context is loaded into
EM. This allows work process multiplexing - one physical work process can serve many users by rolling
context in and out of EM. Key parameters: em/initial_size_MB (total EM size), ztta/roll_extension (max EM
per user context).
Q3: What is the purpose of the Dispatcher in SAP? A: The SAP Dispatcher is the traffic controller. It
receives incoming requests (from SAP GUI, RFC, HTTP) and assigns them to available work processes. It
maintains the work process queue and handles load distribution among the work processes on a single
application server.
Q4: What is the difference between sm50 and sm66? A: SM50 shows work processes for the CURRENT
application server only. SM66 shows work processes across ALL application servers in the SAP landscape.
SM66 is the system-wide view and is preferred for overall system health checks.
Q5: What happens if the Message Server goes down? A: New logons are impossible; the message server
is required for logon load balancing. However, existing active user sessions may continue if they are
already connected to a specific application server. All RFC connections using logon groups will fail. The
ASCS must be restarted (via cluster failover in HA setups).
Q6: Explain the significance of the DDIC (Data Dictionary) user. A: DDIC is SAP's Data Dictionary user. It is
used for ABAP Dictionary operations, system startup (DDIC is the first user active during system start
before 000 client logon), and is used by SAP standard programs that need dictionary access. DDIC should
never be deleted. Its password should be secured and changed from default. In production, DDIC should
be locked when not needed.
Q7: What is tRFC and qRFC, and when would you use each? A: tRFC (Transactional RFC): Guarantees
that an RFC call is executed exactly once, even if the network fails. The call is stored locally and retried
until successful. Monitored via SM58. qRFC (Queue RFC): Extends tRFC with serialization. Calls in the
same queue are processed in sequence. Used when the order of execution matters (e.g., IDoc processing).
Monitored via SMQ1 (outbound) and SMQ2 (inbound).
Q8: What is the purpose of Transaction SCC4? A: SCC4 (Client Administration) is used to: Create clients,
define client roles (Production, Test, etc.), set client change option (changes to client-independent objects
allowed/not allowed), set cross-client change option (who can change cross-client customizing), and set the
client protection level (no external access, no transfers, etc.). This is a critical security configuration for
controlling what can be changed in each client.
Q9: What are the key files in the SAP transport directory structure? A: /usr/sap/trans/ (transport root)
contains: /data/ - transport data files (R<TR_number>.<SID>), /cofiles/ - transport control files
(K<TR_number>.<SID>), /log/ - transport and import logs, /buffer/ - import queue buffers per system,
/EPS/in/ - inbox for SP files (SPAM), /EPS/out/ - exported SP files.
Q10: What is the role of the Enqueue Server, and what happens if it fails? A: The Enqueue Server
manages application-level lock entries. SAP application locks (SM12) are stored in the enqueue server's
memory. If the enqueue server fails: All existing locks are lost, potentially causing data inconsistency; new
lock requests fail; transactions requiring locks (e.g., posting) will fail. In HA configurations, ENSA2 (new
enqueue server) provides replication to a standby enqueue server for automatic failover without lock loss.
Key T-Codes Mentioned: SM50, SM66, SCC4, SM12, SM58, SMQ1, SMQ2, STMS

Scenario 50: Comprehensive Basis Key T-Codes and OS Commands Reference

Q: Provide a complete reference of the most important SAP Basis transaction codes and OS-
level commands that every Basis consultant must know.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 44 of 47

Answer & Explanation:
This is your essential SAP Basis quick reference guide. These T-codes and commands cover the full
spectrum of day-to-day Basis administration activities.
SYSTEM MONITORING T-CODES: SM50: Work Processes (current server). SM66: Work Processes (all
servers). SM21: System Log. ST22: ABAP Dump Analysis. SM12: Lock Entries. AL08: All Logged-On
Users. SM04: Users on Current Server. ST06: Operating System Monitor. DB02: Database Monitor (tables,
missing indexes, space). SM51: SAP Server Overview. RZ20: CCMS Alert Monitor. ST03N: Workload
Monitor. STAD: Statistical Records.
USER AND SECURITY T-CODES: SU01: User Maintenance. SU10: Mass User Changes. PFCG: Profile
Generator (Role Maintenance). SU53: Authorization Check Analysis. SUIM: User Information System.
SM20: Security Audit Log. SM19: Security Audit Configuration. SECPOL: Security Policy. SU24: Auth
Objects for Transactions. SCC4: Client Administration.
TRANSPORT MANAGEMENT T-CODES: STMS: Transport Management System. SE10: Transport
Organizer. SE09: Workbench Requests. SE03: Transport Organizer Tools. SE01: Extended Transport
Organizer. SMSY: System Landscape (SolMan). CG3Y: Upload file to application server (alternative: CG3Z
download).
BACKGROUND JOBS T-CODES: SM36: Define Background Jobs. SM37: Job Overview. SM61:
Background Server Group Maintenance. SMLG: Logon Group Maintenance. SM62: Events for Job Control.
SM65: Background Processing Analysis.
PRINTING AND SPOOL T-CODES: SP01: Spool Requests (User). SP00: All Spool Requests. SP12:
TemSe Administration. SPAD: Spool Administration. SM59: RFC Destination Maintenance.
SYSTEM MAINTENANCE T-CODES: RZ10: Profile Parameter Maintenance. RZ11: Display/Maintain
Profile Parameter. SPAM: Support Package Manager. SAINT: Add-On Installation Tool. SNOTE: Note
Assistant. SMICM: ICM Monitor. SICF: Service Configuration (web services). STRUST: Trust Manager
(SSL certs).
DATABASE AND PERFORMANCE T-CODES: DB13: DBA Planning Calendar (for AnyDB). DB02:
Database Performance. ST05: SQL Trace. SE30: ABAP Runtime Analysis. SM12: Lock Entries. AL11: SAP
Directories Browser. SARA: Archive Administration.
INSTANCE/SYSTEM T-CODES: SM01: Lock/Unlock Transactions. SM02: System Messages. SM59: RFC
Connections. SLICENSE: License Management. USMM: System Measurement. SCC8: Client Export.
SCC7: Client Import. SCCL: Local Client Copy. SCC9: Remote Client Copy. SCC3: Client Copy Log. SICK:
Installation Check. SM04: User Overview. AL08: Logon Overview.
ABAP AND INTERFACE T-CODES: SE38: ABAP Editor. SE80: Object Navigator. SE11: ABAP Dictionary.
WE02: IDoc Monitor. WE20: Partner Profile. BD87: IDoc Reprocessing. SM58: tRFC Monitor. SMQ1: qRFC
Outbound Queue. SMQ2: qRFC Inbound Queue. SXMB_MONI: Integration Engine Monitor (PI).
/IWFND/MAINT_SERVICE: Gateway Services.
OS COMMANDS (Linux/Unix - as <sidadm>): sapcontrol -nr <instance> -function GetSystemInstanceList:
Check instance status. sapcontrol -nr <instance> -function Start: Start SAP instance. sapcontrol -nr
<instance> -function Stop: Stop SAP instance. /usr/sap/<SID>/exe/disp+work -version: Check kernel
version. SAPCAR -xvf <file>.SAR -R <target>: Extract SAR archives. HDB start / HDB stop: Start/stop SAP
HANA (as <sdbadm>). hdbnsutil -sr_state: Check HANA system replication status. tp showlog <TR>
<SID>: View transport log from OS. df -h: Disk space usage. free -m: Memory usage. top: Process and
CPU monitor. ps aux | grep dw: Show SAP work processes.
IMPORTANT SAP NOTES TO KNOW: Note 19466: SAP kernel versions and patch levels. Note 88416:
Memory configuration for ABAP server. Note 1999997: HANA database sizing. Note 2380176: HANA 2.0
installation guide. Note 1820529: HANA system replication configuration. Note 2235581: HANA upgrade
guide.

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 45 of 47

Appendix: SAP Basis T-Code Quick Reference
Complete T-code reference for all 10 chapters. Use this as a quick-lookup during interviews and daily
administration.

T-Code Description Category

SM50 Work Process Monitor (current Performance Monitoring
server)
SM66 Work Process Monitor (all servers) Performance Monitoring
SM21 System Log Error Analysis
ST22 ABAP Dump Analysis Error Analysis
SM12 Lock Entries Lock Management
AL08 All Logged-On Users User Monitoring
SM04 User Overview (current server) User Monitoring
ST06 OS Monitor (CPU, Memory, Disk) Performance Monitoring
DB02 Database Performance Monitor Database Administration
SM51 SAP Application Server Overview System Administration
RZ20 CCMS Alert Monitor Monitoring
ST03N Workload Monitor Performance Analysis
STAD Statistical Records Performance Analysis
ST05 SQL Trace Performance Analysis
ST02 Buffer Overview Performance Monitoring
SU01 User Maintenance User Administration
SU10 Mass User Changes User Administration
PFCG Profile Generator (Role Security
Management)
SU53 Authorization Check Analysis Security
SUIM User Information System Security Reporting
SM20 Security Audit Log Security Audit
SM19 Security Audit Configuration Security Configuration
SECPOL Security Policy Maintenance Security Configuration
SU24 Auth Objects for Transactions Security Configuration
SCC4 Client Administration Client Management
SCCL Local Client Copy Client Management
SCC9 Remote Client Copy Client Management
SCC8 Client Export Client Management
SCC7 Client Import Client Management
SCC3 Client Copy Log Client Management
STMS Transport Management System Transport Management
SE10 Transport Organizer Transport Management
SE09 Workbench Requests Transport Management
SE03 Transport Organizer Tools Transport Management
SM36 Schedule Background Jobs Background Processing
SM37 Background Job Overview Background Processing

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 46 of 47

T-Code Description Category
SM61 Background Server Groups Background Processing
SMLG Logon Group Maintenance Load Balancing
SP01 Spool Requests (User) Spool Management
SP00 All Spool Requests Spool Management
SP12 TemSe Administration Spool Management
SPAD Spool Administration Spool Management
RZ10 Profile Parameter Maintenance System Configuration
RZ11 Display Profile Parameter System Configuration
SPAM Support Package Manager Patching
SNOTE Note Assistant Patching
SMICM ICM Monitor Web Services
SICF Service Configuration Web Services
STRUST SSL/TLS Trust Manager Security/Certificates
SM59 RFC Destination Maintenance Integration
WE02 IDoc Monitor Integration/EDI
WE20 Partner Profile Maintenance Integration/EDI
BD87 IDoc Reprocessing Integration/EDI
SM58 tRFC Monitor Integration
SMQ1 qRFC Outbound Queue Integration
SMQ2 qRFC Inbound Queue Integration
SXMB_MONI PI Integration Engine Monitor PI/PO Monitoring
/IWFND/ Gateway Service Activation SAP Gateway/Fiori
MAINT_SERVICE
SLICENSE SAP License Management License Administration
USMM System Measurement (Licensing) License Administration
SARA Archive Administration Data Archiving
LSMW Legacy System Migration Data Migration
Workbench
LTMC Migration Cockpit (S/4HANA) Data Migration
SM01 Lock/Unlock Transactions System Administration
SM02 System Messages System Administration
AL11 SAP Directory Browser File Management
SM13 Update Record Monitor Update Management
SICK Installation Check System Verification
DSWP Solution Manager Workcenter SolMan

SAP Basis Real-Time Scenarios | Basis Consultant Reference Guide | Page 47 of 47