Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Any inconsistencies from new role created in break-fix followed by same role created in Dev?

Former Member
0 Kudos

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

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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

2 REPLIES 2

Former Member
0 Kudos

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

0 Kudos

Julius.

Thank you for the fast response. You are very helpful, as always.

Aoife