Provisioning and Configuring Integration Suite Capabilities: Subaccounts, Tenants, and Runtime Setup

Explanation

Once the architectural model of SAP Integration Suite is understood, the next step for a consultant is actually provisioning and configuring the service for project use. This lesson focuses on the practical configuration sequence and the decisions that materially affect how integration development and operations will run. Provisioning begins in the BTP cockpit at the subaccount level. An administrator assigns the Integration Suite entitlement (from the global account's available service plans) to the target subaccount, then subscribes to the Integration Suite application. On first access, the platform prompts for capability activation — commonly Cloud Integration and API Management for classical middleware replacement projects. Activating Cloud Integration provisions a dedicated Cloud Integration tenant tied to that subaccount; this tenant has its own URL, its own message processing runtime, and its own monitoring dashboards, separate from the design-time workspace. A key configuration decision is how design-time content will be managed. Integration Suite supports both the classic package-based design model (packages containing iFlows, value mappings, and message mappings stored in the platform's own repository) and a Git-enabled workspace model where content is version-controlled in an external or SAP-provided Git repository. For projects with mature DevOps practices, Git integration is strongly preferred because it enables branching, code review, and integration with CI/CD pipelines; for smaller or pilot projects, the classic package model may be adequate initially but creates technical debt if the project later needs proper version control and multi-environment promotion. Connectivity configuration is another core setup task. To connect Cloud Integration to on-premise systems (such as an S/4HANA on-premise backend or ECC), the project typically configures the SAP Cloud Connector, establishing a secure tunnel between the customer's on-premise network and the specific BTP subaccount. This is registered via a location ID and mapped to specific virtual-to-internal host mappings that Cloud Integration flows reference through the Cloud Connector's HTTP destination configuration in the subaccount's destination service. Misconfiguring the location ID or exposing more internal resources than necessary through Cloud Connector is a frequent security gap on real projects. Security artifacts also need configuring at this stage: OAuth clients or certificate-based authentication for inbound/outbound communication, keystore entries for TLS certificates used by adapters (such as SFTP, HTTPS, or IDoc-based adapters), and user role collections (such as Integration Developer, Integration Operator, and Business Expert roles) assigned via the identity provider. Without correctly assigned role collections, developers cannot deploy iFlows even if they can design them, which is a common early blocker. Finally, environment strategy must be decided: most projects provision separate subaccounts (or at minimum separate Cloud Integration tenants) for development, quality assurance, and production, each with its own entitlements, connectivity, and monitoring setup. Content is promoted between environments either via manual export/import of integration packages or via CI/CD pipelines that deploy Git-managed content into each tenant. Consultants should verify, rather than assume, that connectivity (Cloud Connector, destinations) and credentials are separately configured per environment, since these are not automatically replicated when content is promoted.

Code example

# Example: registering an HTTP destination in the BTP subaccount# destination configuration properties used by a Cloud Integration iFlow's Receiver adapter Name=ERP_ONPREM_HTTPType=HTTPURL=http://virtual-host-defined-in-cloud-connector:8000/sap/bc/srt/rfc/sap/ZINTEGRATION_SVCProxyType=OnPremiseAuthentication=BasicAuthenticationUser=<technical_user>Password=<stored_securely_not_in_destination_plaintext_in_prod>cloud.connector.location.id=LOC1 # Notes:# - ProxyType=OnPremise tells the runtime to route via Cloud Connector.# - cloud.connector.location.id must match the location ID registered in Cloud Connector.# - In production, use certificate-based or OAuth authentication instead of Basic Auth where possible.

Real project scenario

During a project connecting SAP Integration Suite to an on-premise S/4HANA system for order synchronization, the integration team builds and tests an iFlow successfully in the development tenant. When promoted to the QA subaccount, the flow fails with connection timeouts. Root cause analysis reveals that Cloud Connector was only registered and mapped for the development subaccount's location ID; the QA subaccount had no corresponding Cloud Connector mapping or destination entry. The fix required coordinating with the Basis team to register a second Cloud Connector instance (or additional subaccount mapping) and recreate the destination in QA, highlighting why environment-specific connectivity setup must be planned from the start rather than assumed to carry over automatically.

Common mistakes

• Assuming design-time content and connectivity/security configuration automatically replicate across dev, QA, and production tenants. • Using the classic package-only design model for a project that will eventually need CI/CD, creating rework later. • Registering overly broad internal host mappings in Cloud Connector instead of scoping access to only the required backend services. • Storing credentials in plaintext destination properties instead of using secure credential stores or OAuth/certificate-based authentication. • Forgetting to assign role collections (Integration Developer, Integration Operator) to new team members, blocking deployment despite design access.

Best practices

• Provision separate Cloud Integration tenants (via separate subaccounts) for dev, QA, and production, each with independently verified connectivity. • Prefer Git-enabled workspaces for design-time content when the project has more than a handful of integration flows or multiple developers. • Scope Cloud Connector virtual-to-internal mappings tightly to only the backend services required by the integration scenarios. • Use OAuth or certificate-based authentication over Basic Authentication for production destinations wherever the backend supports it. • Maintain a documented checklist of per-environment setup steps (entitlements, role collections, destinations, Cloud Connector, keystore entries) to avoid gaps during promotion.

Interview angle

Interviewers often probe whether a candidate has actually configured connectivity end-to-end, asking how Cloud Connector location IDs relate to destination configuration, or how content promotion works across environments. Candidates who can describe the difference between design-time repository content and per-environment runtime configuration (destinations, credentials, Cloud Connector mappings) demonstrate genuine implementation experience rather than tool-navigation familiarity alone.