10-15-2013 9:52 PM
Hello. I have not found this question answered in existing discussions. My apologies if I have overlooked an existing thread.
We are doing our annual Support Pack/Enhancement Package installation. During our freeze on new configuration in Development, we required creation of a new role on an emergency basis.
I created the new role in our emergency break fix client. After testing, review and approval, it was imported to Production.
Now that our normal Development/QA/Production transport path is open again, I am to create the same role in Development, and then move it through QA and then to Production upon successful testing.
Is there a possibility of introducing inconsistencies or any other potential problem which might result from creating and transporting a role from two different systems like this? Are there any key fields or numbering or anything else which might be out of whack? (This is my first year on the Security team after a misspent youth supporting Financials)
Thank you
Aoife Bratton
10-15-2013 10:16 PM
Yes, there definately is a risk.
First of all, you should maintain Su24 and not create new little roles and then try to put humpty dumpty together again via use assignments or composites. A good concept does not need composites.
Creating testing roles or "hot fix roles" is OK but you must not transport them. They only bridge the testing activities. You must fix the real roles.
You must ensure that the System IDs (which are an attribute of the generated profile name (1st and 3rd character) and the number range (table AGR_NUM_2, which is client depenedent...!) do not collide with each other),
On import, a colliding profile name will be rejected but the PFCG data (AGR*) tables will be imported, so it will look ok...
Best practice is to set the AGR_NUM_2 range to a +100k gap between the systems and try to only use 50 to max 100 single roles per FI-alligned org unit you want to control on (bar cost center / internal orders / profit center reporting if you have that retentiveness).
Then you never hear about it again.
If you dont do it, then it will drive you crazy...
Cheers,
Julius
10-15-2013 10:16 PM
Yes, there definately is a risk.
First of all, you should maintain Su24 and not create new little roles and then try to put humpty dumpty together again via use assignments or composites. A good concept does not need composites.
Creating testing roles or "hot fix roles" is OK but you must not transport them. They only bridge the testing activities. You must fix the real roles.
You must ensure that the System IDs (which are an attribute of the generated profile name (1st and 3rd character) and the number range (table AGR_NUM_2, which is client depenedent...!) do not collide with each other),
On import, a colliding profile name will be rejected but the PFCG data (AGR*) tables will be imported, so it will look ok...
Best practice is to set the AGR_NUM_2 range to a +100k gap between the systems and try to only use 50 to max 100 single roles per FI-alligned org unit you want to control on (bar cost center / internal orders / profit center reporting if you have that retentiveness).
Then you never hear about it again.
If you dont do it, then it will drive you crazy...
Cheers,
Julius
10-16-2013 12:54 AM
Julius.
Thank you for the fast response. You are very helpful, as always.
Aoife