SAP System Refresh / Post-Copy Activities

SAP System Refresh / Post-Copy Activities in SAP Basis

A System Refresh (also known as a System Copy) in SAP Basis involves creating a copy of an existing SAP system (the "source" system, usually Production) onto another system (the "target" system, usually Quality, Development, or Sandbox). The primary purpose is to refresh non-production systems with up-to-date production data for various reasons:

Testing: Provide realistic data for functional, integration, regression, or performance testing.
Development: Give developers current production data to analyze issues or develop new features in a production-like environment.
Training: Create environments with current data for user training.
Troubleshooting: Replicate production issues in a non-production environment for diagnosis.
Upgrades/Migrations: Provide a fresh, recent copy of production for upgrade/migration test cycles.

The process typically involves backing up the source database, restoring it onto the target server, and then performing a series of "post-copy" activities to adapt the copied system to its new environment and purpose.

I. Methods of System Refresh

Database Backup/Restore (Recommended for Homogeneous Copies):
- Process:
  - Take a full database backup of the source system.
  - Restore this backup onto the target system's database instance.
  - Execute database-specific post-restore steps (e.g., database open reset logs in Oracle, recover database in SQL Server, HANA recovery).
- Pros: Most common, reliable, generally faster for large databases.
- Cons: Requires source and target to have the same database type and version (homogeneous).
SAPinst (Software Provisioning Manager - SWPM) Export/Import (Heterogeneous or Specific Scenarios):
- Process:
  - Use SWPM to perform a "System Copy" (Database Dependent Export / Import). This exports the SAP data from the source database independent of the database type.
  - Import the exported data into the target system on its (potentially different) database.
- Pros: Can be used for heterogeneous system copies (e.g., Oracle to SQL Server, though not relevant for HANA as HANA is the target). Can be used for database migration (e.g., non-HANA to HANA).
- Cons: Slower, more resource-intensive, generally more complex than backup/restore.
- Note for HANA: For ECC on HANA, you'd typically use Database Backup/Restore if target is also HANA. If source is non-HANA and target is HANA, then SWPM with DMO (Database Migration Option) is the method, but this is a migration, not a standard refresh.

II. Phases of a System Refresh

Pre-Copy Phase (Source System Preparation):
- Cleanup: Archive/delete old data if reducing size is desired (Data Volume Management - DVM).
- Stop Production Activity (if hot backup not possible): Ensure no transactions are running during backup. For most modern databases (HANA, Oracle, SQL Server), hot backups are standard.
- Backup Source System: Perform a full, consistent database backup.
- Copy Backup Files: Transfer backup files securely to the target server.
- Gather Source System Information: Collect hostname, IP, SID, instance number, kernel version, database parameters, RFCs, Logical System Names, client settings, TMS configuration, printer settings, batch job schedules, etc. (often documented in a "Refresh Checklist").
Copy Phase (Database Restore):
- Prepare Target System: Stop target SAP application, shut down target database.
- Restore Database: Restore the source database backup onto the target database instance.
- Database-Specific Post-Restore: E.g., open database with reset logs (Oracle), run database integrity checks.
Post-Copy Phase (Critical for Functionality):
- Start Target Database and SAP System.
- Mandatory Technical Steps (Crucial for System Identity and Connectivity):
  - Execute BDLS (Logical System Name Conversion): Only if required. Converts logical system names (e.g., PRDCLNT100 to QASCLNT100) in tables. Essential for ALE, IDocs, BW connections.
  - Cleanup/Adjust Client Settings:
    - Logon to 000 client with DDIC.
    - Run SCCL or SCC4 to set target client status (e.g., "production" to "test").
    - Disable user logins in other clients (SCC4).
    - Create/Copy DDIC user in relevant clients if needed.
  - Delete/Lock Production Users: Delete or lock all dialog users from the production refresh (except DDIC, SAP*, SAPCPIC) to prevent unauthorized access. Create or unlock test users as needed.
  - Adjust RFC Destinations (SM59): Modify all RFC destinations pointing back to the source production system to point to correct target systems (e.g., development, quality, or other integrated systems). Delete obsolete ones.
  - Adjust Operation Modes (RZ04), Work Processes (RZ10), Load Balancing (SMLG): Adapt to the target system's hardware resources and landscape.
  - Adjust Printer Settings (SPAD): Change printer output devices and logical spool servers to avoid printing to production printers.
  - Adjust Background Jobs (SM37, SM36):
    - Disable/Delete all scheduled production jobs immediately.
    - Reschedule only necessary jobs (e.g., index rebuilds, daily consistency checks) for the target system.
    - Modify job steps to point to correct directories/paths.
  - Adjust TMS (Transport Management System - STMS):
    - Reconfigure target system to act as its own development/quality system or point to the correct transport domain controller.
    - Remove old transport routes.
  - Update License Key (SLICENSE): Install a new license key specific to the target system's hardware key and SID. The old production license will become invalid.
  - Update Logon Load Balancing (SMLG): Adjust server groups for new system names/instance.
  - Update Hostname/IP references: In SM51 and other configurations, ensure the system recognizes its own new hostname.
  - Update SAP Profile Parameters (RZ10): Review and adjust parameters like instance.hostname, rdisp/myname, SAPGLOBALHOST, DIR_TRANS, login/system_client, etc.
  - Update Kernel and Database Client: If the target system has different kernel/DB client version, ensure it's compatible. Re-apply any specific patches.
  - Clean Shared Memory/Table Buffers: /$SYNC or dpmon -cache might be required.
  - Recreate/Adjust Background User Password: For SAP_BATCH_<SID> or other background users.
  - BW/BI Specific Adjustments: For BW systems, specific post-copy steps are crucial (e.g., RS_BW_POST_MIGRATION, RSRV checks, source system recreation).
- Application-Specific Adjustments:
  - Integrate with Third-Party Systems: Adjust connections (middleware, external tools).
  - ABAP Program/Variant Adjustments: Some custom programs or variants might have hardcoded paths or server names.
  - Middleware Configuration: PI/PO, CPI, etc., might need adjustments.
  - Workflow: Re-check workflow configurations.
  - BW Source System Connections: Reconnect to source systems.

III. Important Configurations to Keep in Mind

Documentation & Checklist:
- Maintain a detailed, up-to-date checklist for each refresh. This is the single most important configuration to prevent missed steps.
- Document all pre-copy parameters and post-copy adjustments.
Database User Passwords:
- Ensure all database user passwords (e.g., SAP<SID>, SYSTEM, DDIC) are known for both source and target.
- Change the SAP<SID> password on the database after restore if different from target's previous password (brtools for Oracle, SQL Studio for SQL Server, hdbuserstore for HANA).
SAP License Management (SLICENSE):
- A new license is always required for the target system after a refresh, as the hardware key changes.
- Request the new license from SAP before the refresh downtime, using the target system's hardware key.
Security and User Management:
- Lock All Users: Immediately lock all dialog users after the refresh (except admin users) until post-copy activities are complete and testing users are explicitly reactivated.
- User Master Data (SU01): Understand that user master data is copied. Plan for deletion/deactivation of production users and creation/activation of test users.
TMS Configuration (STMS):
- Know your transport landscape. The target system must be reconfigured in STMS to remove its association with the production transport route and integrate it into the correct landscape (e.g., QAS in a DEV -> QAS -> PRD landscape).
RFC Destinations (SM59):
- Crucial for connectivity. A systematic approach to identify, modify, or delete RFCs is needed. Look for RFCs pointing back to the source system.
Background Jobs (SM37, SM36):
- Immediate Disablement: Disable/delete all jobs from the production copy to prevent them from running on the test system and interfering with production or test data.
- Reschedule only necessary basis jobs.
Logical System Names (BDLS):
- Crucial for ALE/IDoc interfaces and BW source systems. Know which tables require BDLS conversion (e.g., based on RSAP_BIW_CONNECT_SRCSYS_GET).
- BDLS can be time-consuming for large tables; plan for its execution time.
Printer Settings (SPAD):
- Change output devices to non-production printers to avoid accidental printing to production.
Application-Specific Post-Copy Steps:
- Involve functional teams to identify and execute application-specific post-copy steps (e.g., re-initializing queues, adjusting interfaces in middleware, configuring BW source systems).
Client Strategy:
- Understand the client structure (e.g., 000, 001, application client). Perform SCC4 adjustments carefully.
System Log (SM21) & Dumps (ST22):
- Monitor these closely immediately after refresh for any errors during system startup or post-copy activities.

30 Interview Questions and Answers (One-Liner) for System Refresh / Post-Copy Activities

Q: What is the primary purpose of an SAP system refresh?
- A: To copy a source system (e.g., Production) onto a target system (e.g., Quality) for up-to-date data.
Q: Name two common methods for performing a system refresh.
- A: Database Backup/Restore and SAPinst Export/Import.
Q: Which refresh method is typically used for homogeneous system copies?
- A: Database Backup/Restore.
Q: Which SAP tool is used for an export/import based system copy?
- A: Software Provisioning Manager (SWPM), also known as SAPinst.
Q: What is a critical pre-copy activity to reduce refresh downtime for large databases?
- A: Data Volume Management (DVM) and Archiving.
Q: What is the first thing you must do with production users after a refresh?
- A: Lock or delete them (except DDIC, SAP*, SAPCPIC).
Q: Which transaction code is used to adjust RFC destinations after a refresh?
- A: SM59.
Q: What is the purpose of BDLS after a system refresh?
- A: To convert logical system names in tables.
Q: When is BDLS typically required?
- A: When logical system names need to be changed (e.g., for ALE/IDoc communication).
Q: What happens to the SAP license key after a system refresh?
- A: The old one becomes invalid, and a new one is required.
Q: Which transaction code is used to install a new SAP license key?
- A: SLICENSE.
Q: What immediate action should be taken for background jobs copied from production?
- A: Disable or delete all of them immediately.
Q: Which transaction code is used to manage background jobs?
- A: SM37 (display), SM36 (create).
Q: What is the purpose of adjusting printer settings (SPAD) post-refresh?
- A: To prevent printing to production printers.
Q: Which transaction code is used to manage TMS (Transport Management System)?
- A: STMS.
Q: What needs to be done in STMS after a refresh?
- A: Reconfigure the target system to fit its role in the transport landscape.
Q: What is a "refresh checklist," and why is it important?
- A: A detailed, step-by-step guide to ensure all post-copy activities are completed consistently.
Q: What are SCC4 settings used for post-refresh?
- A: To adjust client roles (e.g., "production" to "test") and disable client logins.
Q: Why is it important to ensure database user passwords are known after a refresh?
- A: To establish correct database connectivity for the SAP system.
Q: What is the purpose of RZ10 post-refresh?
- A: To adjust SAP profile parameters, including hostname and work process settings.
Q: Which ABAP user should you log in with initially in client 000 after a refresh?
- A: DDIC.
Q: How do you verify the target system's hostname after a refresh?
- A: Check SM51 or hostname OS command.
Q: What are the risks of skipping BDLS when it's required?
- A: Inconsistent data, failed IDocs, broken interfaces, and incorrect BW source system connections.
Q: What is the primary purpose of SMLG in post-copy?
- A: To adjust logon load balancing groups for the new system.
Q: What should be done with sensitive data (e.g., personal data) after a production refresh to a test system?
- A: Data scrambling/anonymization (optional, but highly recommended for compliance).
Q: What is the rdisp/myname parameter used for in SAP profiles?
- A: Defines the symbolic name of the application server.
Q: What is the role of functional teams in a system refresh?
- A: To perform application-specific post-copy steps and functional testing.
Q: How do you handle system security post-refresh in terms of RFCs?
- A: Ensure RFCs don't point back to production, and delete unnecessary ones.
Q: What is a "hot backup," and why is it preferred for system refresh?
- A: A backup taken while the database is online; minimizes production downtime.
Q: What is the purpose of checking SM21 and ST22 immediately after a refresh?
- A: To identify any critical errors or dumps during system startup and post-copy activities.

5 Scenario-Based Hard Questions and Answers for System Refresh / Post-Copy Activities

Scenario: You have just completed a successful production system refresh to your Quality Assurance (QAS) environment. The SAP system starts, and you can log in. However, when the functional team tries to test financial processes, they complain that IDocs are stuck in status 03 and new IDocs are not being generated for intercompany postings. You check SM58 and see RFC errors.
- Q: What is the most likely root cause for these issues, and what specific steps would you take to diagnose and resolve it immediately, using relevant transaction codes?
- A:
  - Most Likely Root Cause: The most likely root cause is that the Logical System Names (LSNs) have not been correctly converted using BDLS, or related RFC destinations are still pointing back to the production system. IDocs rely heavily on correct LSNs for source and target determination, and intercompany postings often use ALE configurations that are tied to LSNs and RFCs. Status 03 (Output created) indicates the IDoc left the system, but probably failed at the receiving end or couldn't find a valid destination.
  - Specific Steps to Diagnose and Resolve:
    1. Check SM58 (RFC Monitor):
      - Action: Immediately check SM58 (Transaction RFC Monitor). Filter by the RFC destination used for intercompany postings/IDocs. You will likely see errors like "Logical system name missing" or "Target host not found" for RFCs pointing to the production system.
      - Rationale: Confirms RFC issues and often points to the specific problematic RFC destination.
    2. Verify Logical System Names (BD54 / SALE):
      - Action: Go to BD54 (Logical Systems) in the QAS system. Confirm that the logical system name for the QAS system (e.g., QASCLNT100) is correctly defined and the logical system name for the production system (e.g., PRDCLNT100) is still present as a partner system.
      - Rationale: Ensures basic LSN configuration is in place.
    3. Run BDLS (Logical System Name Conversion):
      - Action: Execute transaction BDLS.
        
        In "Old Logical System Name", enter the production logical system name (e.g., PRDCLNT100).
        
        In "New Logical System Name", enter the QAS logical system name (e.g., QASCLNT100).
        
        Run in test mode first, then in actual execution mode. Crucially, ensure you include all relevant tables. A common mistake is missing application-specific tables. For intercompany postings, tables related to financial postings and message control are vital.
      - Rationale: This converts the hard-coded production LSNs to QAS LSNs in tables, resolving the core data inconsistency for IDocs. Note that BDLS can be time-consuming depending on database size and tables selected.
    4. Adjust RFC Destinations (SM59):
      - Action: Go to SM59. Identify all RFC destinations that were pointing to the production system from QAS (and are now incorrect because QAS is a copy of production).
      - Modify: Change the target host and instance number of these RFCs to point to the correct systems in the QAS landscape (e.g., QAS Development, QAS BW, or even the QAS system itself if local RFCs are used).
      - Delete: Delete any RFCs that are no longer relevant in the QAS environment (e.g., RFCs pointing to external production systems that should not be touched by QAS).
      - Create New: Create any new RFCs needed for QAS-specific interfaces.
      - Test: Use the "Connection Test" and "Authorization Test" functions in SM59.
      - Rationale: BDLS converts LSNs in data, but SM59 adjusts the actual network connections. Both are necessary.
    5. Test IDoc Processing:
      - Action: After BDLS and SM59 adjustments, ask the functional team to re-process the stuck IDocs (WE19 for manual re-processing, BD87 for mass re-processing) and generate new intercompany postings.
      - Rationale: Validates the fix.
Scenario: You are performing a system refresh of a large S/4HANA production system (10 TB) to a sandbox environment using the database backup/restore method. The restore process completes successfully, but when you try to start the SAP application, the disp+work processes repeatedly start and stop. The system log (SM21) shows errors related to "License Key Invalid" and "Hardware Key Mismatch."
- Q: What is the most immediate action required to bring the SAP system up, and what is the critical pre-refresh step that should have prevented this issue from delaying the system startup?
- A:
  - Most Immediate Action Required:
    - Install a new SAP License Key: The system is failing to start because the copied production license key is tied to the production system's hardware key, which is different from the sandbox system's hardware key. The disp+work processes require a valid license to fully start.
    - Steps:
      1. Obtain the sandbox system's hardware key using saplicense -get at the OS level or SLICENSE in client 000 (if DDIC can log in before crash) or directly from the initial installation.
      2. Request a new permanent or temporary license key from SAP Support Portal using the sandbox system's SID and hardware key.
      3. Install the new license key using SLICENSE in client 000 (if possible) or directly at the OS level using saplicense -install followed by the license file path.
      4. Restart the SAP application instance (startsap).
  - Critical Pre-Refresh Step to Prevent Delay:
    - Request New License Key in Advance: Before initiating the system refresh, the Basis team should have proactively requested a new license key from SAP for the target sandbox system, using its existing SID and hardware key. This new license file should be readily available on the target server so it can be installed immediately after the database restore and before the first SAP application startup attempt. Having it pre-staged prevents the delay caused by waiting for SAP to generate and send the license.
Scenario: After refreshing your Development (DEV) system with production data, the ABAP developers report that all their custom background jobs, which they previously scheduled, are now either missing, failing immediately, or trying to connect to production resources. This disrupts their development and testing activities.
- Q: Why did this happen, and what is the correct post-copy strategy for managing background jobs in a refreshed development system to avoid these issues while ensuring necessary jobs run?
- A:
  - Why this happened:
    1. Deletion/Disabling by Basis (Correct Action): As a mandatory post-copy activity, Basis administrators must disable or delete all background jobs copied from the production system. This is crucial to prevent them from accidentally running against production systems via RFCs, generating production output (e.g., printing checks), or consuming resources unnecessarily in the non-production environment.
    2. Hardcoded References: Some custom jobs might have hardcoded production logical system names, server names, or file paths within their ABAP program variants or job steps, causing them to fail when run in the DEV environment.
  - Correct Post-Copy Strategy for Managing Background Jobs:
    1. Immediate Disabling/Deletion (Mandatory Basis Step):
      - As the absolute first post-copy step, log in to the refreshed DEV system (e.g., client 000 or development client) and use SM37 or SM36 to immediately select all scheduled jobs and disable them or delete them en masse. This is a non-negotiable security and operational measure.
    2. Basis Essential Job Rescheduling:
      - Only reschedule basic system jobs that are essential for the DEV environment's stability and maintenance (e.g., RSCOLL00 for performance data, update statistics jobs, clean-up jobs).
      - Ensure these rescheduled jobs have correct variants for the DEV system.
    3. Developer-Driven Re-scheduling and Adaptation:
      - Communication: Clearly communicate to the ABAP development team that their jobs from the previous DEV system are now gone, replaced by production's job schedule, which has been disabled.
      - Job Recreation/Adaptation: Developers must log in to the refreshed DEV system and re-create their development-specific background jobs from scratch or adapt the copied production job definitions.
      - Variant Adjustment: Emphasize the importance of creating or adjusting job variants to use DEV-specific parameters, logical system names, and file paths.
      - Testing: Encourage developers to thoroughly test their re-scheduled jobs in DEV.
    4. No Unnecessary Production-like Jobs: Avoid running jobs in DEV that simulate high production loads or interact with external systems unless explicitly required for specific testing and with proper controls.
Scenario: You've completed a system refresh to your Quality (QAS) environment. All basic SAP checks are green, but the testing team reports that several interfaces to external third-party systems are failing. They are receiving errors like "Authorization failed," "Connection refused," or "Invalid credentials" from the external systems. Your SM59 RFCs were adjusted.
- Q: Beyond SM59 RFCs, what other potential integration points or configurations in SAP Basis need to be checked and adjusted after a refresh to ensure external interfaces work correctly? Name specific areas and the likely missing adjustments.
- A:
  - Beyond SM59 RFCs, other critical integration points/configurations:
    1. SAP Process Integration (PI/PO) / Cloud Integration (CPI) Integration:
      - Likely Missing Adjustment: The PI/PO or CPI system typically has configuration entries (e.g., communication channels, receiver determinations, sender agreements) that point to specific SAP backend systems using their logical system names or SIDs. After a refresh, PI/PO/CPI might still be configured to send/receive messages from the original QAS system or even the production system, leading to routing issues, incorrect credentials, or certificate mismatches.
      - Action: On the PI/PO/CPI side, update the system landscape directory (SLD) and integration directory configurations to reflect the refreshed QAS system's identity (SID, logical system name, hostname). Re-import the refreshed QAS system's certificate if using SSL. Adjust communication channels for target URLs/ports.
    2. Web Service (SOAP/REST) Configurations (SOAMANAGER):
      - Likely Missing Adjustment: Web service consumer proxies (SOAMANAGER) within the SAP QAS system might still point to production web service endpoints. External systems might also be configured to call the production web service URL.
      - Action: In SOAMANAGER on the QAS system, adjust logical ports for consumer proxies to point to QAS-specific web service endpoints (e.g., test environments of external systems). Ensure external systems are configured to call the QAS web service URL. Re-import or trust updated SSL certificates if applicable.
    3. Certificate Management (STRUST):
      - Likely Missing Adjustment: If interfaces use SSL/TLS for secure communication, the QAS system's certificates (e.g., PSEs in STRUST) might be copied from production, leading to issues if trust relationships or common names differ. External systems might not trust the copied production certificate on the QAS system.
      - Action: Review all relevant PSEs (SSLC, SSL Client (Standard), ACL) in STRUST. If the QAS system's hostname has changed, or if it uses its own distinct certificates, these might need to be regenerated or re-imported. Ensure necessary root and intermediate certificates from external systems are trusted.
    4. Background User Passwords:
      - Likely Missing Adjustment: Communication users (SAP_BATCH_<SID>, ALEREMOTE, RFC users) used for interfaces might have their passwords changed on the source (production) system after the refresh, or the target system expects different credentials.
      - Action: Verify and re-synchronize passwords for all communication users in SU01 that are used by interfaces. If these users are defined in external systems, their credentials there must also be updated.
    5. Operating System (OS) Level Connectivity / Firewalls:
      - Likely Missing Adjustment: While not strictly SAP Basis configurations, network routes, firewall rules (on SAP servers or network level), or /etc/hosts entries on the QAS server might not be correctly configured to reach external systems' test environments.
      - Action: Verify network connectivity (ping, telnet) from the QAS server to the external system's interface endpoints. Check OS-level firewall rules.
    6. External System Configuration:
      - Likely Missing Adjustment: The external systems themselves might still be configured to expect incoming connections or send data to the production SAP system's hostname/IP/Logical System Name, not the QAS system.
      - Action: Coordinate with the owners of external systems to update their configurations to point to the QAS environment's interfaces.
Scenario: You have just completed a refresh of your SAP BW on HANA Quality system from Production. You have performed all standard post-copy steps including BDLS, SM59 adjustments, and license installation. However, when users try to execute existing BW queries, they either fail, or the data appears inconsistent. When you check the Data Source views (RSA1 -> Source Systems), the Production source system shows a red status.
- Q: What specific BW-related post-copy activities are crucial after a refresh from a production BW system, and how would you resolve the red status for the source system connection in RSA1?
- A:
  - Specific BW-Related Post-Copy Activities (Crucial after Refresh):
    1. BW Source System Connections Recreation/Restoration: This is the most critical step. The copied BW system contains metadata about its source systems (e.g., ECC, other BWs). After a refresh, these connections still point to the production source systems, but the BW Quality system needs to connect to its own Quality source systems.
    2. RS_BW_POST_MIGRATION (or RS_AFTER_MIGRATION): This report performs various post-migration/copy adjustments crucial for BW objects and connections.
    3. RSRV Checks (Analysis and Repair of BW Objects): Run comprehensive consistency checks to identify and repair any inconsistencies in BW metadata and data after the copy.
    4. Re-importing Transformations, DTPs, Process Chains: While BDLS handles logical system names in tables, some process chain variants, DTPs, and transformations might need specific attention or re-import if issues persist.
    5. Deleting/Recreating RFCs for Source Systems: Even after BDLS, the underlying RFCs need to be correct in SM59.
    6. Security and Authorizations: Ensure that BW authorizations (for source systems, objects, etc.) are correctly replicated or re-assigned.
  - Resolving Red Status for Source System Connection in RSA1:
    The red status indicates a broken connection to the source system. This is almost always due to the refreshed BW Quality system still trying to connect to the production ECC/BW system (or other source system) with the quality logical system name, or simply due to incorrect RFC definitions.
    
    Resolution Steps:
    1. Verify Logical System Names (BD54 / SALE):
      - Ensure the logical system name for your target BW QAS system is correctly defined (e.g., BWQCLNT100).
      - Ensure the logical system name for your source ECC QAS system (e.g., EQACLNT100) is also correctly defined in the BW QAS system.
    2. Adjust RFC Destinations (SM59):
      - Identify the RFC destination(s) used by the problematic source system connection (e.g., BWQCLNT100 -> EQACLNT100).
      - Change the target host and instance number of these RFCs in SM59 on the BW QAS system to point to the correct quality source system (e.g., your ECC Quality system).
      - Perform "Connection Test" and "Authorization Test" in SM59.
    3. Delete and Recreate Source System in RSA1:
      - Action: In RSA1 -> Source Systems, right-click the problematic source system (the one showing red status) and choose "Delete". This deletes the connection metadata in BW.
      - Then, right-click on the folder (e.g., "SAP") and choose "Create Source System...". Follow the wizard to create a new source system connection to your Quality ECC system (or whatever the actual source system for your QAS BW is). This will establish the correct connection using the adjusted RFC.
      - Rationale: Even after BDLS, sometimes the connection metadata within BW's source system definition gets corrupted or is unable to correctly resolve. Deleting and recreating forces BW to build the connection anew using the correct logical system names and RFCs. This is a common and robust solution for BW source system issues after a refresh.
    4. Run RS_BW_POST_MIGRATION:
      - Action: Execute the ABAP program RS_BW_POST_MIGRATION (or RS_AFTER_MIGRATION for older BW versions) in SE38. This program performs various internal adjustments for BW objects and source system assignments after a system copy.
      - Rationale: Ensures internal consistency and updates necessary references.
    5. Perform RSRV Checks:
      - Action: In RSRV, execute various test packages relevant to your BW objects (e.g., "All Tables of a BW Object," "Characteristics Consistency," "InfoCube Consistency"). Correct any identified inconsistencies.
      - Rationale: Ensures the integrity of BW objects and data after the copy.

Rakshit Ranjan Singh

Search This Blog