Aligning SAP BTP with the ERP landscape

Most SAP S/4HANA programs now include work on SAP Business Technology Platform: side-by-side apps, integration flows, workflows, launchpad content. That work has its own landscape, and it must line up with the ERP landscape. A BTP app tested against the wrong ERP system proves nothing, and a BTP change that reaches production before the ERP change it depends on breaks production.

Subaccounts per stage

On SAP BTP, apps and services run in subaccounts inside a global account, optionally grouped in directories. SAP Learning recommends separate subaccounts per stage because each subaccount has its own configuration: trust to identity providers, destinations, connectivity and access. That lets you connect the development subaccount to developer identities and development systems, and keep production locked down. Labels such as owner, cost center or stage add metadata for cost and governance.

Pairing each stage with an ERP tier

The pairing is implemented through destinations in each subaccount (and, for systems not exposed to the internet, the Cloud Connector). Contoso names destinations identically in every subaccount, for example CMC_S4HANA, so the app code never changes between stages; only the destination's target differs. A destination in the test subaccount that points to CMP is a defect, and Priya's entry criteria for a test cycle include a destination check.

Shared services and transports

SAP's DevOps reference architecture for BTP recommends running services such as SAP Cloud Transport Management in their own subaccount, alongside other shared services, to separate concerns. Contoso follows that: cmc-central-services hosts transport management and alerting. A CI/CD pipeline builds and tests the app, then hands the tested archive to Cloud Transport Management, which moves it through test, pre-production and production nodes. ERP transports and BTP transports are tied to the same release in SAP Cloud ALM so they are deployed in the right order.

Identity and integration content per stage

Trust is configured per subaccount, which lets each stage use the right identities. Contoso's production subaccount trusts the corporate identity provider so business users sign in with their normal accounts and are assigned role collections by group. The test and pre-production subaccounts use test users that mirror business roles, so authorization tests mean something, and developers never hold production role collections. The same staging applies to integration content: Cloud Integration flows such as the ASN to Great Lakes Fleet Services are promoted through test, pre-production and production tenants with transport management, never edited directly in production. Each tenant's endpoints and credentials are configured for its own stage and kept out of the deployable content.

Two common mistakes are worth naming. The first is a single "non-production" subaccount shared by development and testing: developers redeploy during a test cycle and results become meaningless. The second is a test subaccount whose identity provider is the production one with broad groups: testers then carry real business authorizations into tests, and negative authorization tests cannot fail the way they should.