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: 

No SAP Solution for bringing context-sensitive HR structural auth. to BI 7

l_borsboom
Active Participant
0 Kudos

I will take you on a journey through my problem

Present situation: in ECC (R/3 HR) system: HR Structural Authorizations have been implemented with the context-sensitive switch activated

Goal: HR Structural Authorization should become available in BI 7.0. Changes in the Organizational Structure in ECC (R/3 HR) should be automatically made available in SAP BI (on a daily basis).

SAP Solution: In the SAP Business Content 2 DataSources (0HR_PA_2 & 0HR_PA_3) are available to bring the Structural Authorizations to BI. The input are the R/3 table T77PR, T77UA & T77UU and the eventual output are the generated analysis authorizations in BI.

This method is described in these white papers:

- [BW/HR Authorization ASAP for BW Accelerator|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e1cba990-0201-0010-43ae-af579aee7a73] (BW 3.0)

- [BW 3.0 Authorizations|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/39f29890-0201-0010-1197-f0ed3a0d279f], page 6-34 (BW 3.0)

Gap: implementing context-sensitive authorization means that the user-structural profile assignment is made within authorization object P_ORGINCON (field PROFL) rather than assignment via table T77UA (transaction OOSB). (edited on 01-07: we use the BAdI HRBAS00_GET_PROFL to get the profile values, otherwise structural profile authorization assignment has 2 sources which for me seems to be a recipe for confusion)

Table T77UA will not be maintained anymore, hence the input for the DataSources will be incorrect. SAP does not have a solution for this issue. In fact, I have found numerous unanswered questions about this topic, for example [here|;, [here|;, [here|; and [here|;.

Question: Does anybody know of a best practice which can solve this issue?

Possible solution I can think of:

Create a table join (ABAP report, Query or Quick view) which connects tables USR02, AGR_USERS and AGR_1251. Make the following selection variant:

 
Table-Field		Option		Value
USR02-GLTGV		LE		SY-DATUM
USR02-GLTGB		GE		SY-DATUM
AGR_1251-OBJECT		EQ		P_ORGINCON
AGR_1251-FIELD		EQ		PROFL
AGR_1251-DELETED	NE		X
AGR_USERS-FROM_DAT	LE		SY-DATUM
AGR_USERS-TO_DAT	GE		SY-DATUM

Your output will consist of a list with active userids and active structural profile values.

Now you have 2 options:

1. Use the output of the table join as an input for table T77UA for the sole reason to be able to use the standard Data Sources 0HR_PA_2 & 0HR_PA_3. Of course, before each new output (daily) table T77UA should be made empty again. The table join, the clearing and updating of table T77UA and the extraction of the DataSources should be scheduled in a daily background job. The remainder of the procedure is the same as the default procedure for HR structural authorizations to BI

2. Use the output of the table join as in input for report RHAUTH01. This will lead to an output of active users and the Organizational Units they are authorized for. This output can be loaded into a flat file (on a daily basis) and imported into BI. The remainder of the procedure is the same as the default procedure for using flat file authorization.

If you haven't lost me already(!) could you please let me know:

- if these solutions make sense

- what I am forgetting here

- if you have a better best practice (or standard SAP solution)

- which option you prefer and for what reason

Thank you very much for your cooperation!

Kind regards,

Lodewijk Borsboom

Edited by: Lodewijk Borsboom on Jan 7, 2009 10:12 AM

11 REPLIES 11

charmaine_greene
Explorer
0 Kudos

In R/3 the assignment of Structural Authorisation profile to user Id is can done in 2 ways.

1. by running the report RHRPROFL0 against the org structure which automatically updates table T77UA - usually this is set up to run as a nightly job.

2. or by using tx OOSB.

So table T77UA will always be maintained with user id and structural assignment

I don't think you need to worry about using context authorisations & P_ORGINCON (field PROFL) for BI. In R/3 this option is only used to prevent an overlap in authorisations when a user has many transactional roles. I have never heard of context authorisations used in BI yet.

Regards

Charmaine

0 Kudos

Hi Charmaine

Thanks for your input. This might be the way to go for us.

I will discuss this option tomorrow with our HR consultant.

It confuses me a little though:

Does using report RHRPROFL0 (scheduled to run every night) mean that you won't need the BAdI HRBAS00_GET_PROFL?

What will be leading in R/3: T77UA or the the value for PROFL in P_ORGINCON?

Thanks for your reply!

Lodewijk

0 Kudos

Hi Lodewijk

Does using report RHRPROFL0 (scheduled to run every night) mean that you won't need the BAdI HRBAS00_GET_PROFL?

RHRPROFL0 works differently to HRBAS00_GET_PROFL. You can use RHRPROFL0 to manage the indirect assignments and BAdI HRBAS00_GET_PROFL to manage the direct assignments.

RHRPROFL0 needs to run nightly to update the user ids linked to the position via the structural profile. If a user starts,changes or leaves a position, this is automatically updated by RHRPROFL0 in T77AU.

There will be scenarios where you will need to use manual direct assigment approach when setting up access for test users, external consultants (anyone that does not have a personnel record).

RHRPROFL0 can't be used for the assignment because these users do not exist in the org plan. So this is where you can use BAdI HRBAS00_GET_PROFL - it takes away the need to maintain table T77AU manually - It picks up the structural profile entries from PROFL in P_ORGINCON and updates T77AU automatically.

What will be leading in R/3: T77UA or the the value for PROFL in P_ORGINCON?

I would say T77UA -

Regards

Charmaine

0 Kudos

Dd you get a solution working to generate authorisations in BI where vcontext sensitive authorisations have been used on the ERP side?

mvais
Explorer
0 Kudos

This message was moderated.

Former Member
0 Kudos

Lodewijk Borsboom

Are able to find the solution , I am in similar situation , Please let us know . Thanks

Regards

Prasad

0 Kudos

Don't use the BADI.

Former Member
0 Kudos

This message was moderated.

Former Member
0 Kudos

Lodewijk,

  1. Your solution makes a lot of sense.
  2. There is no Standard SAP Solution of bringing contextual solution, structural authorizations (SA)
  3. You will have to change your BW design to reflect/mirror the way Structural Authorizations (SA) are being used in ECC side.
  4. You need to extract the following Data from ECC - User - SA - Orgs (with combining data from HRP1001 & User & AGR tables
  5. Then in BW, segregate the InfoProviders according to the SA and generate Analysis Authorizations - Orgs per user per Infoprovider.

I have sent you an email with more details, please have a look.

Regards,

Shivraj

Former Member
0 Kudos

Hello,

We have a problem similar to this.

In our  HR system, We are using

1)Context based sloution (P_ORGINCON) - Profile name is addedd to PROF field of P_ORGINCON. T77UA is not updated.

2) BADI HRBAS00_GET_PROFILE (for automatic profile assignment)  - Does not updae table T77UA

3) Two functional modules -

FM 1- Standard - RH_GET_MANAGER_ASSIGNMENT for managers

FM2 - Cusomt - ZFM.... - For Central HR Professionals which provides access to Org units based on Contract value in IT0001.

Now, we are pulling ECC/HR data to BW system using 0PA_DS03.

Issue - I found everything seems to be working fine (BADI, Standard FM and P_ORGINCON) in ecc side (RSA3 and on BW side.

However, Custom FM works perfectly on ECC side (diplaying data in PPOSE etc.). But it does not show up any records when checked in RSA3. So data which is going to BW is also not correct.

How and where is the problem. any help on this will be appreciated.

Kind Regards,

SS

Former Member
0 Kudos

I see a lot of posts out here for similar issues, and I am wondering how this will turn out as I am trying to do the same.  We have implemented the BADI, as well as context authorizations,  and it appears that the correct values and authorizations are being generated correctly for 0PA_DS02, based on the users in T77UU.  The problem we have is with the hierarchies in 0PA_DS03.  It will only generate them for users that are in T77UA.  Obviously we don't use OOSB any more, there were just some users still out there but once we deleted the users from T77UA then no hierarchies were loaded.

Has anybody got this to work using the BADI?  I realize we will have to do something with the user exit in note 771168, but I think that only applies to 0PA_DS02 data, not the hierarchies.

Regards,

James