BTP & Integrationintermediate

BTP Integration Suite Part 2: Provisioning and Configuring Capabilities

Key takeaway

Set up Integration Suite: subscription in a subaccount, activating capabilities, role collections for developers, operators and business experts, the Process Integration Runtime service instance for inbound calls, and a checklist before the first iFlow.

Explanation

📌 KEY POINTS
✅ Subscribe to Integration Suite in the subaccount and activate needed capabilities.
✅ Assign role collections (e.g. PI_Administrator, PI_Integration_Developer, PI_Business_Expert) by responsibility.
✅ Inbound callers authenticate via a Process Integration Runtime service instance (plan integration-flow) and its service key (client credentials or certificate).
✅ Separate dev/test/prod tenants (subaccounts) for change control.
⚠️ Giving everyone PI_Administrator removes control over security material and deployments.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 mapped capabilities. Now setup.

━━━━━━━━━━━━━━━━━━━━
▶ 1. SUBSCRIPTION

Integration Suite in subaccount.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CAPABILITIES

Activate Cloud Integration, API Management, etc.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ROLES

Admin, developer, business expert, operator.

━━━━━━━━━━━━━━━━━━━━
▶ 4. RUNTIME ACCESS

Service instance + key for senders.

━━━━━━━━━━━━━━━━━━━━
▶ 5. LANDSCAPE

Dev/test/prod tenants; transports.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Subscribe and activate Cloud Integration.
Assign role collections.
Create runtime instance and service key.

✅ CHECKPOINT: a test sender can authenticate and call a deployed endpoint.

Code example

ABAP Code

===== SETUP =====Subaccount → Service Marketplace → Integration Suite (subscribe) → Add CapabilitiesRole collections: PI_Administrator | PI_Integration_Developer | PI_Business_ExpertRuntime access: Process Integration Runtime → plan integration-flow → service key (clientid/secret or certificate) ===== SENDER CALL =====POST https://<tenant>.it-cpi0xx-rt.cfapps.<region>.hana.ondemand.com/http/ordersAuthorization: Bearer <token from service key token URL>

Real project scenario

A review found all developers had PI_Administrator and one shared client secret for 40 senders. Role cleanup and per-sender service keys allowed a leaked secret to be revoked without outage.

Common mistakes

Admin for all.
Shared secrets.
One tenant for all.
Unused capabilities.
No key rotation.

Best practices

Role by responsibility.
Key per sender.
Separate tenants.
Activate by need.
Rotate credentials.

Interview angle

Questions: "How do you provision Integration Suite?", "Which roles exist?", "How do senders authenticate?"
Strong answer: subscription, capabilities, roles, runtime access, landscape.

Practice this lesson

Quick check

1. Which role collection typically allows building and deploying iFlows without full admin rights?

2. Why create one service key per sender system?

3. How do external sender systems typically authenticate to Cloud Integration endpoints?

Interview questions

1. Provision Integration Suite for a new program with several sender systems.

Answer it in your own words first, then compare.

2. How would you apply Integration Suite in a real SAP project? Walk through the design or implementation approach.