IMP! - A huge issue to resolve on ORG values

[Former Member]

Hi All,

Need all your expert views and advise on this one

The issue: Our landscape D->Q->P is on like since a long time. I saw some role change I did which seemed improper to me in the QA/PRD system, when I debugged the issue, I saw 4 ORG values missing in QA & PRD!!

I checked USORG table and found the DEV system has 4 more entries than QA/PRD.

OMG!!!!!

$PERSA is one among them. They have been promoted to ORG values in DEV ONLY!

How do I even think of getting this corrected??!!! I can run the program pfcg_orgfield_create and promote these 4 to the ORG value....but ..our role structure is set for end users since years....and ..shouldnt have this been done during the initial design of the system?? shouldnt this be uniform across the landscape ??

How do I achieve this feat in production? I know this program whacks a lot of corresponding roles and tables!!

Our R3 production is too HUGE to imagine !!

I need your advise on :

1 - What are the impacts of trying this in a live system? Will there be auth issues for users..when the program reconciles the roles?

2. Lets take an example PERSA. The functional values pull PERSA value from the ORG. This works fine in DEV, as we can see and maintain PERSA in the ORG restriction. WHen this same role is transported to prd, PERSA value is flushed, as it is no longer an ORG value, and the functional values end up having value "$PERSA" !! It is trying to pull the values , but cannot find any!

Surprisingly, end users are not complaining! So does this mean a "*" is taking its place($<ORG>) ? I did a role compare of the role in DEV and PRD and found no diff! .....maybe because the agr_1251/2 tables contain the corresponding values , as these too are transported!

3. What cuould be the impacts going forward if this is not corrected soon? upgrade issue ? any other issue?

4. I can try this on QA. BY running this program, and mass transporting all roles from DEV to QA immediately after the run. Would this work as any sour role change will be corrected?

Would appreciate all your views!!

-Abhishek

(each day i think...at least today i can sleep sound!!)

[Former Member]

best advise i think of:

run the programm in QAD, see whet happens Check everything verry carefully.

And then run the program in PRD.

I do not see a reason why this could be a problem.

Only change you will see is that all ORG Values will be moved from table AGR_1251 to AGR_1252

Never allow * values to replaec your restrictions

[Former Member]

Appreciate all your answers...

Hi Auke,

I think its a good idea running this in the QA system would give me an idea of the approximate runtime...and/or other issues. I will actually further request the basis team to copy the QA system to a sandbox to try it there first. Dont wanna mess with QA right away. Just to ensure no '*' comes across, I will transport all the roles from DEV to QA once this program is finished.

Hi Jurjen,

what I understand from your reply is then the profile will have the same values as that defined in the DEV system, no matter what lies ahead in the ORG field structure in QA/PRD (unless generated). and I think it makes sense too as the profile, unless touched would be a snapshot of the generated role.

For your statement:

"

2- If your profiles are generated in dev and transported, the values of AGR_1252, rather than the variable name from AGR_1251 are put into the profile.

"

....i got it! I confirmed this by checking the profile values. THANK YOU

For statement:

"

Do keep in mind that roles and the AGR_* tables do not hold the authorizations that are actually checked by AUTHORITY_CHECK.

"

I was not 100% sure on this this earlier....but now since you have confirmed this, i trust you! and it makes sense too for me now! 😛

.....THANK YOU!!!!

I think Role comparisons compare the generated profiles and not the AGR_1251/2 tables. I tested this by adding some values to a object to a role, saving it without generating it. The comparison showed no difference though the AGR tables had extra entries.

Please correct me if I have misunderstood anything.

Out of curiosity, if any of the support team members generate a role in PRD, what would the profile look like?

I want to try this by generating on the staging and comparing it wit DEV.

Also, a question still on my mind -

1 - What are the impacts of trying this in a live system? Will there be auth issues for users..when the program reconciles the roles?

Will this program be generating all the roles one by one?

Thank you both!!! You guys are awesome!

-Abhishek

[jurjen_heeck]

>

> Out of curiosity, if any of the support team members generate a role in PRD, what would the profile look like?

> I want to try this by generating on the staging and comparing it wit DEV.

Why don't you copy an existing role in PRD to a temporary one and generate that profile. Then you can compare the orginal with the copy without yeopardizing production. You may need to look in the actual profile table to find differences.....

> Also, a question still on my mind -

> 1 - What are the impacts of trying this in a live system? Will there be auth issues for users..when the program reconciles the roles?

Well, since the PFCG_ORGFIELD_CREATE only deals with your roles and not with your profiles you should be fine.

Besides that, the program comes with a very friendly checkbox, called "Test Mode"

[Former Member]

Hi Jurjen,

Per note 323817, SAP is not clear on the 'test mode' of this program.

per the note:

"

Unfortunately, the TESTMODE parameter for reports was not checked

correctly.

"

I will work this further. Let me know if you have any thoughts on the note

Thank you

Abhishek

[jurjen_heeck]

Maybe you can find an 'innocent' field (something from a module not in use), add it to a test role and play around with the orgfield on your test system.

There's also PFCG_ORGFIELD_DELETE to revert the effects.

I wouldn't worry too much as the effect of the orglevels is only important when creating or changeing roles. That should be done in DEV which appareantly is the case at your site since you haven't run into big problems yet.

I didn't know about the test mode note, thanks for that.

Jurjen

[jurjen_heeck]

My 2 cents:

1- If your roles are maintained in dev the org values in AGR_1252 are correctly filled.

2- If your profiles are generated in dev and transported, the values of AGR_1252, rather than the variable name from AGR_1251 are put into the profile.

The profiles will not be changed by transporting them.

3- For an orglevel field the AGR_1251 value is always a variable name like $ORGLEVELFIELD

Do keep in mind that roles and the AGR_* tables do not hold the authorizations that are actually checked by AUTHORITY_CHECK. These are in the profiles (and only get there by generating the profiles from the roles).

As long as you do not generate profiles on a system where your orglevels are 'incorrect' the endusers would indeed not notice. Role comparisons may not spot anything as either they look in AGR tables, without checking the orglevel settings on the system, or they're comparing the profiles which have been correctly generated in your dev system.

So I'd say you can correct your problem on your production system because changing the settings do not affect existing profiles.

Hope this helps,

Jurjen

[Former Member]

Hi,

If it just is to add organizational fields then run with sa38 program PFCG_ORGFIELD_CREATE. Take a look at the programs that start with PFCG.

Have fun

Jan van Roest

[Former Member]

>

> My 2 cents:

>

> So I'd say you can correct your problem on your production system because changing the settings do not affect existing profiles.

>

> Hope this helps,

>

> Jurjen

I agree with Jurjen's 2 cents.

[Former Member]

Hi Alex,

Appreciate your response. Yeap...me too agree wit Jurjen now

Whew!

Abhishek

[Former Member]

FYI,

Below is part of the PFCG_ORGFIELD_CREATE documentation.

"The new organizational level field definition is not included in a transport request. Nor are the changed roles included in a transport request. Therefore, it is necessary to run the report in both the preparation system and the production system."

I run this report across the D Q & P landscape. Just make sure you run the report during off hous, cause you have the regenerate in order to adjust some of the roles in PRD.

Have fun.

Lye