Skip to main content
Do checkout my poem section. You are going to love it.

SAP Cloud Connector

SAP Cloud Connector (SCC) Setup

I. What is SAP Cloud Connector?

The SAP Cloud Connector (SCC) is a lightweight, on-premise agent that creates a secure tunnel between an on-premise network and SAP Business Technology Platform (BTP) services (formerly SAP Cloud Platform). It acts as a reverse invoke proxy that eliminates the need for opening incoming firewall ports into the corporate network.

  • Purpose: To enable secure and reliable access from BTP applications (e.g., Fiori apps on BTP, Integration Suite, CPI) to on-premise systems (e.g., SAP ECC, S/4HANA, databases, file shares) without exposing the internal network directly to the internet.
  • Key Function: It establishes an outbound tunnel from the on-premise network to the BTP, meaning all connections are initiated from inside your firewall. This is a major security advantage.

II. Architecture and Components

  1. On-Premise Network:

    • SAP Cloud Connector (SCC): Installed on a dedicated server (Linux or Windows) within the corporate network, preferably in a DMZ or directly accessible to the backend systems.
    • Backend Systems: The target on-premise systems (e.g., SAP ECC, S/4HANA, NW ABAP, non-SAP databases, file systems) that BTP services need to connect to.

  2. Internet/Public Network: The communication medium.

  3. SAP Business Technology Platform (BTP):

    • Cloud Applications/Services: Applications running on BTP (e.g., SAP Build Work Zone, SAP Integration Suite, custom Fiori apps) that require access to on-premise data.
    • Connectivity Service: The BTP service that manages the cloud-side of the secure tunnel established by SCC.
    • Subaccount: SCC is always connected to a specific BTP subaccount.

III. Prerequisites for Installation

  1. Operating System: Windows Server (64-bit) or Linux (64-bit, e.g., SUSE, Red Hat).
  2. Hardware: Minimum 4GB RAM, 2 CPUs, 20GB disk space (production requires more).
  3. Java Runtime Environment (JRE): Specific version required (e.g., SAP JVM or OpenJDK). Check SAP Notes for the exact compatible version. SCC usually comes with its own JVM.
  4. Network Access:
    • Outbound Internet Access: SCC server needs outbound HTTP/HTTPS access to connectivity.global.sap.com (or regional endpoints) and accounts.sap.com for BTP connectivity.
    • Internal Network Access: SCC server needs access to the internal IP addresses/hostnames and ports of the on-premise backend systems it will expose.
  5. BTP Subaccount: Access to an active BTP Global Account and a specific Subaccount where SCC will be registered.
  6. User Credentials:
    • BTP Global Account/Subaccount administrator user (S-user or email ID for BTP login).
    • Operating System user with administrative privileges for SCC installation.
    • Backend system users (e.g., for RFC, HTTP connections).

IV. Installation Steps (High-Level)

  1. Download SCC: Obtain the latest version of SAP Cloud Connector from the SAP Support Portal (Service Marketplace).
  2. Install JRE: If not bundled or specified otherwise, install the required JRE version.
  3. Run Installer: Execute the downloaded installer. Follow the prompts. It typically installs as a service.
  4. Initial Configuration:
    • Web UI Access: Access the SCC administration UI via https://<SCC_Host>:8443 (default port).
    • Initial Login: Default user Administrator, password manage. You will be prompted to change this.
    • Set Master Password: A master password for SCC keystore operations.
    • Configure Proxy (if applicable): If your network requires an outbound proxy for internet access, configure it here.

V. Core Configuration Steps

This is where the real work begins.

  1. Connect to BTP Subaccount:

    • Location ID: Define a unique Location ID (e.g., MY_ONPREM_HQ) for this Cloud Connector instance. This ID helps BTP applications identify which SCC to use.
    • BTP Subaccount Details: Provide the BTP Subaccount's Region, Subaccount ID, and the BTP Administrator User credentials.
    • Tunnel Status: After successful connection, the tunnel status should turn green.
    • Rationale: Establishes the secure WebSocket tunnel between SCC and BTP.

  2. Define Access Control (Cloud To On-Premise):

    • This is where you specify which on-premise resources SCC will expose to BTP and how.
    • Add System Mapping:
      • Backend Type: ABAP System, Non-ABAP System, SAP Host, SAP Application, etc.
      • Protocol: HTTP, HTTPS, RFC, TCP, WEBSOCKET, SNC.
      • Internal Host / Internal Port: The actual hostname/IP and port of your on-premise backend system (e.g., myeccdev.corp.net:8000). This is the system that SCC can see directly.
      • Virtual Host / Virtual Port: A logical, "virtual" hostname and port that BTP applications will use to address the on-premise system. This is what the BTP connectivity service "sees." It can be the same as the internal host/port or different for security/abstraction.
      • Description: A descriptive name.
      • Check Internal Host Reachability: SCC will try to ping the internal host.
      • Save: This creates the mapping.
    • Resource Management (Specific Paths/Functions):
      • After adding a system mapping, you must define which specific resources within that system are allowed.
      • Add Resource:
        • Path: Specify the allowed path (e.g., /sap/opu/odata/, /sap/bc/, /sap/rfc/, /sap/es/). For RFC, it's typically / and the allowed function modules.
        • Access Policy: Path and all sub-paths (recommended for general access) or Only Path (very restrictive).
      • HTTP Methods (for HTTP/HTTPS): Limit allowed methods (GET, POST, PUT, DELETE) if granular control is needed.
      • Rationale: This is the heart of SCC's security. It acts as a granular firewall, ensuring BTP can only access explicitly defined resources on-premise.

  3. Configuring Specific Service Channels:

    • A. RFC (Remote Function Call):

      • Scenario: For BTP applications that use RFC for communication (e.g., some SAP Cloud Integration scenarios, older Cloud Connector usages).
      • Setup:
        • Define System Mapping with Protocol: RFC.
        • Add Resource: Path: /, and then add Allowed Function Modules by name (e.g., BAPI_MATERIAL_GETALL, RFC_READ_TABLE). Use specific function module names or generic patterns carefully.
        • Prerequisite: A dedicated RFC user in the backend system with necessary authorizations.
      • BTP Connectivity: In BTP, create an RFC destination.

    • B. HTTP/HTTPS:

      • Scenario: Most common for Fiori apps on BTP, OData services, Web Dynpro ABAP, SAPUI5 apps, etc.
      • Setup:
        • Define System Mapping with Protocol: HTTP or HTTPS.
        • Add Resources: Specify exact paths (e.g., /sap/opu/odata/SAP/SALESORDER_SRV/ for a specific OData service, /sap/bc/ui5_ui5/sap/hrfiori_old/ for a specific Fiori app UI5 component). For broad Fiori access, /sap/opu/odata/ and /sap/bc/ are common.
        • SNC (Secure Network Communications): If HTTPS is chosen, SCC uses the backend's SSL certificate. You might need to import the backend's root certificate into SCC's trust store. If SNC is used for RFC, specific SNC parameters are needed.
      • BTP Connectivity: Create an HTTP destination in BTP.

    • C. TCP:

      • Scenario: For generic TCP connections, e.g., connecting to a custom port of a database, messaging queue.
      • Setup:
        • Define System Mapping with Protocol: TCP.
        • Add Resource: Path: /, specify the specific Internal Port allowed.
      • BTP Connectivity: Create a TCP destination in BTP.

    • D. LDAP/Mail/JDBC (via TCP): Specific configurations if SCC needs to tunnel these, often as generic TCP.

  4. BTP Destination Configuration:

    • Purpose: In your BTP Subaccount, you create Destinations that cloud applications consume. These destinations point to the Virtual Host/Port defined in SCC.
    • Type: HTTP, RFC, TCP.
    • Proxy Type: Crucially, set Proxy Type to OnPremise. This tells BTP to use SCC.
    • Name: A logical name (e.g., ECC_QAS_Odata).
    • URL: https://<Virtual_Host>:<Virtual_Port> (for HTTP/HTTPS).
    • Location ID: Enter the exact Location ID you defined in SCC.
    • Authentication: NoAuthentication, BasicAuthentication, OAuth2ClientCredentials, PrincipalPropagation (for Single Sign-On).
    • Trust Store: If using HTTPS, import the backend system's root CA certificate into the BTP destination's trust store.
    • Principal Propagation: If SSO is required from BTP to on-premise, configure principal propagation in SCC (Kerberos, X.509 certificates) and BTP.

VI. Important Configurations and Considerations

  1. Security (Most Important):

    • Principle of Least Privilege: Grant only the absolute minimum required access:
      • Internal Host/Port: Only expose the exact systems needed.
      • Resources: Be as granular as possible with paths. Avoid Path and all sub-paths (/) for HTTP/HTTPS unless truly necessary.
      • RFC: List specific FMs; avoid generic patterns (*).
      • HTTP Methods: Restrict to GET for read-only services, add POST/PUT/DELETE only if write operations are required.
    • User Management: Change default Administrator password immediately. Use strong passwords.
    • Transport Layer Security (TLS): Ensure TLS 1.2 or higher is enforced for all communication.
    • Certificates: Manage certificates in SCC's trust store (for backend HTTPS) and key store (for principal propagation).
    • DMZ Placement: Consider placing SCC in a DMZ for an extra layer of security.

  2. High Availability (HA):

    • Redundant SCCs: For production environments, deploy at least two SCC instances, connecting to the same BTP subaccount and using the same Location ID. This provides failover.
    • Shared Configuration: SCCs in an HA setup automatically synchronize their configurations.

  3. Performance:

    • Sizing: Ensure SCC host has sufficient CPU, RAM, and disk space for expected load.
    • Network Bandwidth: Good network bandwidth between SCC and backend systems.
    • Caching: SCC itself can perform some basic caching of responses (less common for dynamic OData).
    • Resource Limits: Monitor SCC resource usage (Monitoring tab in SCC UI).

  4. Monitoring and Troubleshooting:

    • SCC Dashboard: Provides tunnel status, connected subaccounts, resource usage.
    • Trace Files: Configure trace levels in SCC for detailed logging. Log And Trace Files tab.
    • Audit Logs: SCC logs all configuration changes and connection attempts.
    • BTP Connectivity Monitor: In BTP Cockpit, go to Connectivity -> Cloud Connectors to see the status from the cloud side.
    • Backend Logs: Check SM21, ST22, SM50 on the backend system for errors related to incoming connections from SCC.

  5. Lifecycle Management:

    • Updates: Regularly update SCC to the latest version for bug fixes, security patches, and new features. Updates are generally non-disruptive (can update one SCC in HA setup at a time).
    • Backup: Regularly back up the SCC configuration (using the "Export Configuration" option in the SCC UI).

  6. Virtual Host/Port Convention: Use a consistent and meaningful convention for virtual hostnames/ports to make BTP destinations easier to manage.

30 Interview Questions and Answers (One-Liner) for SAP Cloud Connector

  1. Q: What is the primary function of SAP Cloud Connector (SCC)?
    • A: To create a secure tunnel between an on-premise network and SAP BTP.
  2. Q: What type of proxy is SCC considered?
    • A: Reverse Invoke Proxy.
  3. Q: Why is SCC considered more secure than opening firewall ports?
    • A: It establishes an outbound tunnel, meaning connections are initiated from inside the firewall.
  4. Q: What is the default port for accessing the SCC administration UI?
    • A: 8443 (HTTPS).
  5. Q: What is the default initial username for SCC?
    • A: Administrator.
  6. Q: To which SAP cloud platform entity is SCC connected?
    • A: A specific BTP Subaccount.
  7. Q: What is a "Location ID" in SCC?
    • A: A unique identifier for a Cloud Connector instance in a BTP subaccount.
  8. Q: What are "Internal Host" and "Virtual Host" in SCC system mapping?
    • A: Internal is the actual on-premise system; Virtual is the logical name BTP uses.
  9. Q: Which BTP destination Proxy Type must be used for SCC connections?
    • A: OnPremise.
  10. Q: Name three protocols SCC can tunnel.
    • A: HTTP, HTTPS, RFC, TCP.
  11. Q: Where do you define specific allowed paths for HTTP/HTTPS services in SCC?
    • A: Under "Access Control" -> "Resources".
  12. Q: How do you allow specific Function Modules via RFC in SCC?
    • A: Add resource Path: / and then add specific function modules.
  13. Q: What is the benefit of having multiple SCC instances for the same subaccount?
    • A: High Availability (HA) and failover.
  14. Q: How do SCC instances in an HA setup synchronize their configurations?
    • A: Automatically.
  15. Q: What is the main security principle to follow when configuring SCC?
    • A: Principle of Least Privilege.
  16. Q: Where can you monitor the tunnel status in SCC?
    • A: On the SCC Dashboard (Connector State).
  17. Q: Where can you find detailed logs and traces in SCC?
    • A: Log And Trace Files tab.
  18. Q: How do you back up SCC configuration?
    • A: Using the "Export Configuration" option in the SCC UI.
  19. Q: What BTP service typically consumes SCC connections?
    • A: BTP Connectivity Service.
  20. Q: What is Principal Propagation in the context of SCC?
    • A: Enabling Single Sign-On (SSO) from BTP to on-premise using user identities.
  21. Q: Which BTP Cockpit section shows the status of Cloud Connectors?
    • A: Connectivity -> Cloud Connectors.
  22. Q: Does SCC require any inbound firewall ports to be opened?
    • A: No.
  23. Q: What should you do immediately after the initial SCC installation and login?
    • A: Change the default Administrator password.
  24. Q: Can SCC connect to non-SAP on-premise systems?
    • A: Yes.
  25. Q: What is the purpose of setting an "Access Policy" (e.g., "Only Path" vs "Path and all sub-paths") for resources?
    • A: To control the granularity of access to specific URLs/paths.
  26. Q: What should be checked on the backend system if an SCC connection is failing?
    • A: SM21, ST22, SM50 for incoming connection issues or dumps.
  27. Q: What is TLS in the context of SCC security?
    • A: Transport Layer Security, ensuring encrypted communication.
  28. Q: Where do you import backend SSL certificates into SCC for HTTPS connections?
    • A: In the "Trusted Certificates" store of SCC.
  29. Q: What is the impact of misconfigured resource paths in SCC?
    • A: BTP applications will receive "404 Not Found" or "Forbidden" errors when trying to access on-premise resources.
  30. Q: Can SCC connect to multiple BTP subaccounts simultaneously?
    • A: No, one SCC instance connects to one BTP subaccount. For multiple subaccounts, you need multiple SCC instances.

5 Scenario-Based Hard Questions and Answers for SAP Cloud Connector Setup

  1. Scenario: You have set up a new SAP Cloud Connector (SCC) and connected it successfully to your BTP subaccount. You then configure a System Mapping for an on-premise SAP ECC system via HTTPS and define resources for an OData service (/sap/opu/odata/sap/CUSTOM_SRV/). However, when you try to test the BTP destination or the Fiori app in BTP, you receive an "SSL Handshake Failed" error.

    • Q: What are the most likely causes for an "SSL Handshake Failed" error in this scenario, and what detailed steps would you take to diagnose and resolve it?
    • A:
      • Most Likely Causes for "SSL Handshake Failed":
        1. Missing/Invalid Backend Certificate in SCC: SCC does not trust the SSL certificate presented by the on-premise ECC system. This is the most common cause. The root CA certificate (or the entire certificate chain) of the backend system's SSL certificate is not imported into SCC's trust store.
        2. Incorrect Hostname/IP in Backend Certificate: The Common Name (CN) or Subject Alternative Name (SAN) in the ECC system's SSL certificate does not match the Internal Host or Virtual Host specified in the SCC System Mapping.
        3. Outdated TLS Version: A mismatch in supported TLS versions between SCC and the backend system.
        4. Firewall Blocking (Less likely for Handshake): While SCC is outbound, the backend might have an internal firewall blocking the port. (Less common for handshake failure, more for connection timeout).
        5. Time Sync Issues: Significant time difference between SCC server and backend server.
      • Detailed Steps to Diagnose and Resolve:
        1. Verify Backend System's SSL Certificate:
          • Action: On the ECC system, use T-code STRUST to check the SSL Server Standard PSE. Note down the certificate details, especially the "Issued To" (CN/SAN) and "Issued By" (Issuer CA).
          • Action: Export the entire certificate chain (Root CA, Intermediate CA, Server Certificate) from STRUST (or get it from the security team). Export as Base64.
          • Rationale: You need to know what certificate the backend is presenting.
        2. Import Backend Certificate Chain into SCC Trust Store:
          • Action: Access the SCC administration UI (https://<SCC_Host>:8443).
          • Go to Configuration -> Cloud To On-Premise -> (Select the ECC system mapping).
          • Click on Check Internal Host. If HTTPS is configured, it will show certificate details. Look for "Certificate Status."
          • Go to Configuration -> On-Premise -> Trusted Certificates.
          • Action: Click "Import Certificate" and import the Root CA certificate (and any intermediate CAs) of your ECC system's SSL certificate.
          • Rationale: SCC needs to trust the CA that issued the backend's certificate.
        3. Verify Hostname Consistency:
          • Action: Compare the Internal Host and Virtual Host in your SCC System Mapping (Configuration -> Cloud To On-Premise) with the CN/SAN in the ECC system's SSL certificate (checked in step 1). They must match. If your certificate is for eccdev.corp.net but you used 10.0.0.100 as the Internal Host, it will fail.
          • Action: If Internal Host is an IP address, ensure the certificate contains the IP as a SAN. If it's a hostname, ensure DNS resolution is working from the SCC server.
          • Rationale: SSL certificates are bound to specific hostnames/IPs.
        4. Check TLS Version Compatibility:
          • Action: In SCC, go to Configuration -> On-Premise -> TLS. Ensure that the minimum and maximum TLS versions configured in SCC are compatible with what the backend ECC system supports (usually TLS 1.2 is standard now).
          • Rationale: Mismatched TLS versions can cause handshake failures.
        5. Restart SCC Service:
          • Action: After importing certificates or changing TLS settings, restart the SCC service to ensure changes take effect.
          • Rationale: Sometimes changes require a service restart.
        6. Retest Connection:
          • Action: Re-test the Check Internal Host button in SCC. Then re-test the BTP destination and the Fiori app.

  2. Scenario: You have a critical SAP Fiori app on BTP that connects to an on-premise S/4HANA system via SCC. The app's performance has recently degraded, especially for list reports that fetch large datasets. You suspect the SCC might be a bottleneck.

    • Q: What SCC-specific monitoring and performance optimization strategies would you implement to diagnose and alleviate the performance bottleneck for high-volume data transfers?
    • A:
      • SCC-Specific Monitoring and Performance Optimization Strategies:
        1. Monitor SCC Dashboard for Load and Resource Usage:
          • Action: Access the SCC UI Dashboard. Observe "Backend Traffic" (requests/sec, data volume), "Tunnel Throughput," and "CPU/Memory Usage" of the SCC host.
          • Verification: Look for consistently high CPU (>70%), high memory usage (approaching limits), or significant network queues/latency within SCC.
          • Rationale: Identifies if SCC itself is under heavy load or resource constrained.
        2. Check SCC Logs and Traces for Bottlenecks:
          • Action: Go to Log And Trace Files tab in SCC. Increase the trace level temporarily (e.g., to DEBUG) for the "Connectivity" component. Replicate the slow scenario.
          • Verification: Analyze the logs for warnings or errors related to connection timeouts, slow response times, or excessive queuing within SCC. Pay attention to the time taken for requests to pass through SCC.
          • Rationale: Provides granular details about processing within SCC.
        3. Validate Network Latency from SCC to Backend:
          • Action: From the SCC host server's OS command line, perform ping and tracert (or traceroute) to the Internal Host of your S/4HANA system. Measure round-trip times.
          • Rationale: High network latency between SCC and the backend system will directly translate to slow app performance. SCC cannot fix this, but it identifies it as an external bottleneck.
        4. Check Backend System Performance (ST03N, SM50, DB02):
          • Action: While not SCC-specific, always verify that the backend S/4HANA system itself is not the bottleneck (e.g., slow OData service implementation, inefficient database queries, high CPU/memory usage). SCC is a proxy; it's only as fast as the backend.
          • Rationale: Rule out backend as the root cause.
        5. SCC Performance Optimization Actions:
          • SCC Host Sizing Review: If monitoring indicates sustained high CPU/memory on SCC, consider increasing the SCC host's resources (CPU, RAM).
          • Backend Traffic Filtering (Resource Granularity): Ensure you are not exposing too many unnecessary paths or RFCs. The more granular the access control, the less processing SCC needs to do for unauthorized requests.
          • HTTP Method Restrictions: Restrict allowed HTTP methods (GET, POST, etc.) for resources to only what's necessary, reducing potential for malformed requests.
          • OData Service Optimization (Backend): The most impactful optimization for high-volume data is at the OData service level in S/4HANA. Ensure $top, $skip, $filter, and $expand are used effectively by the Fiori app, and the backend DPC_EXT methods/CDS views are highly optimized for data retrieval. SCC can only proxy what it receives.
          • Network Bandwidth: Ensure sufficient network bandwidth between the SCC host and the S/4HANA system.

  3. Scenario: Your company decides to implement Single Sign-On (SSO) for Fiori apps on BTP connecting to on-premise SAP ECC via SCC. The requirement is that the user's identity from BTP (e.g., federated from Azure AD) should be propagated to ECC, so users don't have to re-authenticate when accessing on-premise data.

    • Q: Detail the key configuration steps required in SCC, BTP, and the on-premise ECC system to enable Principal Propagation for this scenario, assuming X.509 certificate-based SSO?
    • A:
      • Key Configuration Steps for Principal Propagation (X.509 Certificate-Based SSO):

        • I. On SAP Cloud Connector (SCC):

          1. Configure Principal Propagation:
            • Action: Go to Configuration -> Principal Propagation.
            • Action: Select "On" for Principal Propagation.
            • Action: Generate an SCC "Signing Certificate" if one doesn't exist (Generate Certificate Signing Request). This certificate will be used by SCC to sign generated user certificates.
            • Action: Export this SCC Signing Certificate.
            • Rationale: SCC acts as an intermediate CA, signing user-specific certificates.
          2. Add Backend System for Principal Propagation:
            • Action: Go to Configuration -> Cloud To On-Premise. Select the ECC system mapping.
            • Action: In the "Principal Propagation" column, select "Enabled".
            • Rationale: Tells SCC to generate and forward user certificates for this backend.

        • II. On On-Premise SAP ECC System (STRUST, SM30, SM59):

          1. Import SCC Signing Certificate into ECC Trust Store:
            • Action: In ECC, go to T-code STRUST. Double-click on "SSL Server Standard" (or relevant PSE).
            • Action: Import the SCC Signing Certificate (exported in SCC step I.1) into the Certificate List of the SSL Server Standard PSE.
            • Action: Add it to the "Certificate List" and then save the PSE.
            • Rationale: ECC needs to trust the SCC Signing Certificate as a valid issuer of user certificates.
          2. Configure VUSREXTID Table (for User Mapping):
            • Action: Go to T-code SM30, enter table VUSREXTID.
            • Action: Configure how the external identity (from the BTP user's certificate) maps to the internal ECC user ID.
              • External ID: Usually the "Subject" (Distinguished Name - DN) from the user's certificate generated by SCC (e.g., CN=user.email@company.com, OU=SCC, O=SAP).
              • Internal User: The corresponding SAP ECC user ID.
            • Rationale: This table allows ECC to identify the correct internal user based on the certificate details.
          3. Create/Adjust RFC Destination (Backend to Backend, if applicable):
            • If Principal Propagation is used for RFC calls between ECC systems via SCC (less common for Fiori direct access), the RFC destination in SM59 needs to be configured with "Current User" and SNC settings.
            • Rationale: Ensures user context is preserved for backend-initiated calls.

        • III. On SAP BTP Subaccount (Destinations):

          1. Configure Destination for Principal Propagation:
            • Action: In the BTP Subaccount, go to Connectivity -> Destinations. Select the existing destination pointing to the on-premise ECC via SCC.
            • Action: Set Authentication to PrincipalPropagation.
            • Action: Ensure Proxy Type is OnPremise.
            • Action: Verify the Location ID matches the SCC.
            • Rationale: This tells BTP to request SCC to generate a user certificate for the call.
          2. Ensure BTP User Identity:
            • Action: Ensure the BTP user (accessed via Identity Provider like Azure AD) has a consistent and unique attribute (e.g., email address) that can be mapped to the VUSREXTID table in ECC.
            • Rationale: The BTP user's identity is the source for principal propagation.

        • IV. Verification:

          1. SCC Trace: Enable Principal Propagation trace in SCC.
          2. BTP Destination Test: Test the BTP destination.
          3. Backend Logs: Check SM21 (System Log), ST01 (Auth Trace), ST03N (Workload Monitor) in ECC. Look for successful login attempts via certificates and USREXTI related entries.
          4. Fiori App Test: Access the Fiori app on BTP as a test user and verify seamless access to on-premise data without re-authentication.

  4. Scenario: You have two SAP Cloud Connectors (SCC1 and SCC2) configured in an HA setup, connected to the same BTP subaccount with the same Location ID. SCC1 is the primary, SCC2 is the secondary. You perform a configuration change (e.g., add a new resource mapping) on SCC1. Later, you find that a Fiori app on BTP (which connects through this Location ID) cannot access the newly configured resource when SCC1 is down and SCC2 takes over.

    • Q: What is the most likely reason for this discrepancy in configuration between the HA SCC instances, and what troubleshooting steps would you take to ensure configuration consistency and proper failover?
    • A:
      • Most Likely Reason for Discrepancy:
        • Configuration Synchronization Failure: While SCCs in an HA setup should automatically synchronize, network issues, firewall blocks between SCC instances (port 8443 or others), or a temporary glitch could cause the synchronization to fail. The change was made on SCC1 but never propagated successfully to SCC2.
      • Troubleshooting Steps to Ensure Configuration Consistency and Proper Failover:
        1. Verify Synchronization Status in SCC UI:
          • Action: Log in to the SCC administration UI of both SCC1 and SCC2.
          • Verification: On the Dashboard or Configuration -> High Availability tab, check the "Synchronization Status" between the two nodes. It should show as "Synchronized" or "Connected." If it shows "Disconnected," "Synchronization Failed," or similar, that's the primary issue.
          • Rationale: Directly tells you if the HA setup is working as expected.
        2. Check Network Connectivity Between SCC Instances:
          • Action: From the OS of SCC1, try to ping SCC2's IP/hostname. Also, try to telnet to SCC2's administration port (8443) and any other ports SCC uses for internal communication (check SCC documentation for HA specific ports, usually 8443 and 443 for internal communication). Repeat from SCC2 to SCC1.
          • Rationale: Firewall rules or network routing issues between the SCC nodes are common culprits for sync failures.
        3. Review SCC Logs for Synchronization Errors:
          • Action: On both SCC1 and SCC2, go to Log And Trace Files. Look for error messages or warnings related to "synchronization," "replication," "HA," or "connection to peer."
          • Rationale: Logs will provide details on why synchronization failed (e.g., "peer unreachable," "certificate mismatch," "access denied").
        4. Manually Initiate Synchronization (if possible/necessary):
          • Action: In the SCC UI (Configuration -> High Availability), there might be an option to "Trigger Synchronization" or "Force Synchronization." Attempt this from the node with the correct configuration (SCC1 in this scenario).
          • Rationale: Can sometimes resolve transient sync issues.
        5. Restart SCC Services (Ordered):
          • Action: If synchronization remains problematic, restart the secondary SCC (SCC2) first, then the primary SCC (SCC1). This can often re-establish the connection and trigger a full sync.
          • Rationale: A simple restart can resolve underlying process issues.
        6. Verify Failover Mechanism:
          • Action: After ensuring configuration consistency, intentionally bring down SCC1 (e.g., stop its service).
          • Verification: Confirm that SCC2 automatically takes over as primary and that the Fiori app can now successfully access all resources, including the newly added one. Then bring SCC1 back up and confirm it resyncs.
          • Rationale: Validates the HA setup end-to-end.

  5. Scenario: You are configuring SCC for an on-premise ABAP system to allow access to both HTTP (OData services) and RFC (specific Function Modules). The security team insists on granular control and warns against using / (Path and all sub-paths) for HTTP resources or * for RFC Function Modules.

    • Q: Detail how you would precisely configure resource access in SCC for this mixed HTTP/RFC scenario to meet the security team's requirements, including examples of paths/Function Modules, and explain the implications of different access policies?
    • A:
      • Precise Resource Access Configuration for Mixed HTTP/RFC Scenario:

        • I. System Mapping Setup (Common for both):

          1. Add System Mapping:
            • Backend Type: ABAP System
            • Protocol: You will need two separate system mappings for this scenario if you want to apply different access policies or if your backend HTTP and RFC services run on different ports/protocols (which is common, e.g., HTTP on 8000/44300, RFC on 3300).
              • Mapping 1: Protocol: HTTPS (for OData/HTTP)
              • Mapping 2: Protocol: RFC (for RFC FMs)
            • Internal Host / Internal Port: Actual hostname/IP and ports for your ABAP system (e.g., myerp.corp.net:44300 for HTTPS, myerp.corp.net:3300 for RFC).
            • Virtual Host / Virtual Port: Logical names for BTP consumption (e.g., myerpH.virtual:443 for HTTP, myerpR.virtual:3300 for RFC).
            • Save.

        • II. Resource Management for HTTP (Granular Control):

          • Action: Select the HTTPS system mapping you just created.
          • Add Resource (for OData Service 1):
            • Path: /sap/opu/odata/sap/SALESORDER_SRV/
            • Access Policy: Only Path (Extremely restrictive, only allows direct access to SALESORDER_SRV root).
              • Implication: This will not allow access to $metadata or entity sets like /SalesOrderSet. You would need to add separate Only Path entries for /sap/opu/odata/sap/SALESORDER_SRV/$metadata and /sap/opu/odata/sap/SALESORDER_SRV/SalesOrderSet. This is often too restrictive for Fiori.
            • Better Action for OData: Add Resource with Path: /sap/opu/odata/sap/SALESORDER_SRV/ and Access Policy: Path and all sub-paths.
              • Implication: This allows access to the service's metadata and all entity sets and functions within that specific OData service. This is the recommended approach for individual OData services.
          • Add Resource (for OData Service 2, if applicable):
            • Path: /sap/opu/odata/sap/MATERIAL_SRV/
            • Access Policy: Path and all sub-paths.
          • Add Resource (for generic Fiori UI5 components):
            • Path: /sap/bc/ui5_ui5/sap/
            • Access Policy: Path and all sub-paths.
              • Implication: This is often required for Fiori Launchpad content. You might make this more granular if possible (e.g., /sap/bc/ui5_ui5/sap/appname/).
          • HTTP Methods: For each resource, specify allowed methods (e.g., GET for read-only apps; GET, POST, PUT, DELETE for transactional apps).

        • III. Resource Management for RFC (Granular Control):

          • Action: Select the RFC system mapping you created.
          • Add Resource (for a specific BAPI):
            • Path: / (This is always / for RFC, but the control is at the Function Module level).
            • Access Policy: Only Path (irrelevant for RFC path, it's about the FMs).
            • RFC Function Module: Click "Add" under "Allowed Function Modules".
            • Action: Enter the exact name of the Function Module: BAPI_SALESORDER_CREATEFROMDAT2.
            • Rationale: Allows only this specific function module.
          • Add Resource (for another specific FM):
            • RFC Function Module: RFC_READ_TABLE.
            • Rationale: This FM is often used for reading data and needs to be carefully restricted due to its power.
          • Avoid: Using * for RFC Function Modules. This grants access to all Function Modules, which is a major security risk.

        • IV. Implications of Access Policies (Summary):

          • Only Path: Allows access only to the exact path specified, not its sub-paths. Extremely restrictive. Often impractical for dynamic web content like OData services (which have $metadata, $batch, entity sets as sub-paths). Useful for very specific static files.
          • Path and all sub-paths: Allows access to the specified path and everything below it. This is generally preferred for OData services (at the service root level) and UI5 components. It provides a balance between security and usability. For maximum security, use the most specific root path possible (e.g., /sap/opu/odata/sap/YOUR_SRV/ instead of /sap/opu/).

        • V. Verification:

          • Test each configured OData service in GW_CLIENT (from BTP destination with correct Location ID) and through the Fiori app.
          • Test RFC connections from BTP (e.g., from CPI) by calling the specific Function Modules.
          • Monitor SCC logs and backend (SM21, ST01) to ensure only authorized calls are passing through.

Comments

Post a Comment

Popular posts from this blog

An experiment with the life

"Best Thing about experiment is that it only improves the outcome." Well, I am Rakshit, hope you already know. I am not special and surely not especially gifted. Neither things go according to my wish. Neither I am the best writer.  But I am myself who is totally unique from anyone else. And I am Rakshit Ranjan Singh. I have my own fun, fights and fall in the most fundamentalistic way. Mechanical is my degree. IT is my Job. Beauty in nature is what I search. Words of my heart are what I write. Four different things I carry on my shoulder and a smile on my face, hope you might have seen that. What do I care for? Family, friends and nature. Do I have regrets? More than I can imagine. Let us move further to see what really is my life.
Read more

Learn Java

Hello Friends, You might already know what Java is. Without taking much of your time, I would like to ask you to please click below if you are ready to learn it from end to end. The Material over here is available on the internet and is free to access.  I would request you to bookmark this page and follow it. Please comment if you are happy with the learning. click here
Post a Comment
Read more

Driving

My Driving Journey: From Zero to (Almost) Hero! Hello everyone! I'm excited to share my ongoing adventure of learning to drive. It's been a mix of nervous excitement, hilarious near-misses, and the slow but steady feeling of progress. Buckle up, because here's a peek into my journey behind the wheel! The First Lesson: Clutch Confusion! My first time in the driver's seat was... memorable. Let's just say the clutch and I weren't immediate friends. Lots of jerky starts and a few stalls later, I began to understand the delicate dance between the pedals. My instructor was incredibly patient (thank goodness!). Mastering the Steering Wheel (Sort Of) Steering seemed straightforward enough, but navigating turns smoothly was a different story. I definitely had a few moments of feeling like I was wrestling with the wheel. Slowly but...
Post a Comment
Read more