Service Bindings Part 3: Moving Bindings Through DEV, QAS and PRD

📌 KEY POINTS
✅ Transport all objects: CDS, BDEF, pool, service definition, binding.
✅ Publishing in QAS/PRD follows your system's release rules — check after import.
✅ Test with a real role in every system.
⚠️ Clear metadata caches after imports if changes are not visible.

▶ WHERE WE ARE
Your ZUI_PURCHREQ_O4 service works in DEV (Part 2). The most common failure with service bindings is not in DEV — it is "works in DEV, 404 or 403 in QAS". This part makes the landscape move predictable.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT GOES INTO THE TRANSPORT
All repository objects of the stack travel in the same transport request (on-premise) or software component (ABAP cloud with gCTS):

• Tables (ZPR_HEAD, ZPR_ITEM, draft tables), number range object, authorization object and lock object
• CDS views (ZR_, ZC_), metadata extensions, access controls (DCL)
• Behavior definitions and behavior pools
• Service definition (object type SRVD) and service binding (SRVB)
• For cloud: IAM app, business catalog, communication scenario

Rule: release them together. A binding imported without its projection or BDEF will fail to activate in the target system.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT DOES NOT AUTOMATICALLY FOLLOW (ON-PREMISE)

• The publication of the service. On many on-premise releases, the binding arrives in QAS as an active repository object but is not published there. It must be published in each system: for OData V4 in /IWFND/V4_ADMIN (publish the service group), for OData V2 in /IWFND/MAINT_SERVICE. Check how your release and your Gateway setup (embedded vs hub) behave, and make publication an explicit step in the cutover plan.
• Role assignments to users. PFCG roles themselves can be transported; assignments of users to roles are done per system.
• Fiori launchpad content assignments in the target client, if your organization maintains them per system.
• System aliases and SICF service activation (/sap/opu/odata4, /sap/opu/odata) are system configuration, not part of your transport.

━━━━━━━━━━━━━━━━━━━━
▶ HOW ACCESS IS GRANTED — ON-PREMISE
A user calling the service needs:

1. Start authorization for the service itself. In PFCG, add the service (for V4 the service group, for V2 the service) to the role menu or authorization defaults so that the S_SERVICE authorization is generated.
2. The business authorizations your BO checks — e.g. authorization object ZPR_REQ from the Managed series and any CDS access control objects.
3. For the Fiori app: the launchpad catalog/space and page with the tile, and the target mapping.

If 1 is missing you get 403 before your code runs; if 2 is missing you get a business error or empty lists from your authorization logic.

━━━━━━━━━━━━━━━━━━━━
▶ HOW ACCESS IS GRANTED — SAP BTP ABAP ENVIRONMENT / S/4HANA CLOUD DEVELOPMENT

• UI service: create an IAM app (type for UI apps) in ADT that references the service binding, add it to a business catalog, and assign the catalog to a business role in the Maintain Business Roles app. Users get the role.
• Web API: create a communication scenario in ADT that contains the binding's inbound service. In each target system, an administrator creates a communication system, a communication user and a communication arrangement for that scenario. The consumer authenticates as the communication user.

These cloud artifacts are part of your software component, but the business roles, arrangements and users are created per tenant.

━━━━━━━━━━━━━━━━━━━━
▶ ENVIRONMENT-SPECIFIC VALUES
Never hard-code system-specific values (host names, client numbers, destination URLs, user names) in CDS, BDEF or ABAP. Use destinations, communication arrangements or customizing that is maintained per system. A binding itself contains no host name — the URL path is the same in every system, only the host changes.

━━━━━━━━━━━━━━━━━━━━
▶ POST-IMPORT CHECKLIST (RUN IN QAS AND PRD)

1. Transport imported without errors; binding status active (check in ADT or via the import log).
2. Service published in this system (V4: /IWFND/V4_ADMIN; V2: /IWFND/MAINT_SERVICE).
3. GET $metadata returns 200 in /IWFND/GW_CLIENT with an admin user.
4. GET list returns 200 with a test user who has only the business role.
5. One create or action executed end-to-end with the business-role user.
6. Fiori launchpad tile opens the app (UI services) or the consumer system calls succeed (Web APIs).
7. /IWFND/ERROR_LOG and /IWBEP/ERROR_LOG checked after the tests.

If step 3 fails, it is publication or system setup; if step 4 fails, it is roles; if step 5 fails, it is business authorization or BO logic.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 3
A deployment path that turns "works in DEV" into "works everywhere", with a checklist that tells you which layer is broken when something fails. Part 4 explains UI vs Web API bindings in depth.

A Purchase Request app passed testing in DEV and was imported into QAS on a Friday. On Monday, testers reported that the Fiori tile opened an app that only showed "Service unavailable", and the API consumers received 404.
The transport was complete and every object was active. The service group had simply never been published in QAS — that step was done manually in DEV and nobody had written it down. After publication in /IWFND/V4_ADMIN, the tile worked, but half the testers now got 403: their test role did not contain the service start authorization.
The team created a post-import checklist (publish, $metadata with admin user, list with business user, one end-to-end create, check error logs) and made it part of every transport's cutover document. The PRD go-live two weeks later needed no emergency fixes.

• Assuming the binding transport also publishes the service in the target system.
• Transporting the binding without the projection, BDEF or service definition it depends on.
• Testing QAS only with an administrator user, hiding missing service authorizations.
• Hard-coding host names, clients or destination URLs in ABAP or CDS.
• Forgetting user-to-role assignments and launchpad content in the target system.
• In the cloud: creating the IAM app or communication scenario but no business role or communication arrangement in the tenant.
• Debugging BO code for a 404 that is really a publication problem.

• Put the whole RAP stack for one app into one transport request or one software component.
• Maintain a written post-import checklist and run it in every target system.
• Always test with a user that has only the business role.
• Keep system-specific values in destinations, arrangements or customizing — never in code.
• Record which publication steps are manual on your release, and automate or script them where possible.
• Read error logs after every deployment test, even when the tests pass.

Practical question: "Your RAP service works in DEV but returns 404 in QAS — what do you check?" Answer: whether the binding is active and published in QAS (V4 service group in /IWFND/V4_ADMIN, V2 in /IWFND/MAINT_SERVICE), SICF nodes and system alias, then the URL. "And 403?" — service start authorization (S_SERVICE via PFCG) and business roles, then BO authorization.
For cloud roles, explain IAM app plus business catalog plus business role for UI services, and communication scenario plus communication arrangement for Web APIs. Candidates who describe a structured post-import checklist stand out.