Lesson 5 of 5
Documenting and transporting
10 min
Listen to this lesson
A role that only its builder understands cannot be tested, approved or audited. A role that moves to production without a controlled transport cannot be trusted. This lesson covers the two habits that turn a built role into a release-ready one: documentation that answers the auditor's questions, and a transport and verification routine that proves CMQ and CMP hold exactly what was approved.
What to document
SAP's course mentions the working artifacts of a role concept: role descriptions from the analysis and conception step, an authorization list with a process view and a transaction overview per role, and published test scenarios. Contoso keeps the essentials in the role's description in PFCG and the detail in the authorization list, linked from the change in Cloud ALM.
| Item | Where | Example for ZCMC_AP_INVOICE_POST_1710 |
|---|---|---|
| Purpose and scope | PFCG description | Post supplier invoices for company code 1710 |
| Owner and approver | PFCG description and authorization list | Owner: Dan; approved in change for the conversion |
| Master role | Derive from Role field | ZCMC_AP_INVOICE_POST |
| Apps and transactions | Menu, mirrored in the authorization list | Supplier invoice apps and the custom fleet rebate report |
| Sensitive values and reasons | Authorization list | No change of supplier bank data; payment release excluded |
| Test evidence | Cloud ALM test cases and runs | Positive and negative tests in CMQ client 100 with SU53 output |
Contoso's minimum documentation per role.
How roles travel
Roles are customizing objects and move with transport requests. SAP's course describes transporting single roles with the role's transport function, or several with mass transport, and importing through the transport management system. Two settings in table PRGN_CUST shape what arrives.
| Setting | Default behavior | With the setting changed |
|---|---|---|
| USER_REL_IMPORT | User assignments in the transport are imported and replace the role's entire assignment in the target | Set to NO: user assignments are not imported; users are assigned in the target |
| PROFILE_TRANSPORT | Generated profiles travel with the role | Set to NO: profiles must be generated in the target (mass generation, SUPC) before the comparison |
The user-assignment setting is the one that bites. SAP warns that importing assignments replaces the whole assignment in the target and removes existing ones. In a landscape with Central User Administration, SAP's guidance is to transport roles without user assignments and block their import on the subsystems. Contoso blocks user assignment imports in CMQ and CMP and assigns users through its approved access process.
- Build in CMDRole built, generated and unit-tested by Nadia's team
- Release the transportLinked to the Cloud ALM feature for the change
- Import to CMQThrough transport management; check the import log
- ComparisonRun the user comparison so test users get the new profiles
- VerifyCompare role in CMQ with CMD; run positive and negative tests
- Approve and import to CMPAfter sign-off; assignments via the access process; comparison run
Default values travel too. SAP's course says the customer tables for SU24 data are transported as a whole from the SU25 steps, that individual SU24 changes create transport requests automatically, and that an import replaces the default values in the target. Review SU24 transports as carefully as role transports, because they change the proposals for every role in the target. For derived roles, make sure the master role is in the target system before or with its derived roles.
Verifying in QA
A successful import proves the transport worked, not that the role is right. Priya's test plan for roles in CMQ checks three things. First, the role arrived as built: the generated profile is current and the role matches CMD. Second, the user comparison ran, so test users actually have the new authorizations. Third, the role does what it should and nothing more, through positive and negative test cases linked to the role's requirement in Cloud ALM, with SU53 output attached for every expected refusal.
What would you do?
After a role transport to CMQ, half of Priya's testers lose access to roles they had yesterday. The transport carried user assignments from CMD. What went wrong, and what is the fix?
- Document purpose, owner, master role, apps, exclusions and test evidence for every role.
- PRGN_CUST controls imports: USER_REL_IMPORT for user assignments, PROFILE_TRANSPORT for profiles.
- Imported user assignments replace the target's; block them where users are assigned locally or through CUA.
- After import, run the comparison and verify with positive and negative tests before approving for production.
Check your understanding · not graded
Lesson check
1. What happens by default when a role transport with user assignments is imported?
2. Which PRGN_CUST setting stops user assignments being imported?
3. If PROFILE_TRANSPORT is set to NO, what must happen in the target?
4. Why document what a role deliberately does not allow?