During an implementation for MSS, we came across an interesting issue on Talent Management iView. The manager had 40 odd direct and and indirect employees under him. List of employees appeared correctly in Team Calendar. But when accessing Talent Management iView, we saw 40 entries with employee names repeating 16 times for 1 employee, and twice for other two employees.

Data in PA0002 was accurate and the fact that Team Calendar did show correct names for all employees, we discarded the possibility of bad data. The issue was reported after setting up structural authorizations but employee names repeated multiple times did not make sense.

Here is what I found after some debugging.

FM HRMSS_GET_QUALIFICATIONS called by Talent Management application calls FM HR_READ_INFOTYPE inside a loop for each employee selected by OADP configuration. Note highlighted part in the code. Exception handling is commented out for FM, internal table LT_0002 and work area LS_0002 are not cleared after each loop pass.

Image1.jpg

FM HR_READ_INFOTYPE checks for structural authorization of user in class CL_HRPAD00AUTH_CHECK_STD, method CHECK_CONTEXT_AUTH_OBJ. In case of missing authorizations to read PA0002 for an employee, FM HR_READ_INFOTYPE returns empty internal table LT_0002.

Image2.JPG

Now consider a case where the manager has authorization to read PA0002 for employee 1 , employee 17, employee 19, employee 20, and employee 21 and employee 23 to employee 40. Because of the code, even though HR_READ_INFOTYPE returns empty internal table LT_0002 for employee 2 to 16, employee names for these employees will be populated as employee 1 only i.e. employee 1 reperating 16 times and so on.

So output in view like Competency Matchup would show,

employee 1

employee 1

employee 1.

..employee 1 ( 16 times ),

employee 17

employee 17

employee 19

employee 20

employee 21

employee 21

employee 23

employee 24

employee 40

Image3.jpg

Lessons learned. 🙂 Yes, we need to set up structural authorizations properly, but never miss recommended best practices below.

1) Judiciously use CLEAR on internal table and work area inside a loop.

2) Code appropriate error handling after FM call.

Also learnt was the lesson that if you have correct data in backend ECC and missing/confusing data on portal iView, do not rule out authorization issues early.

What is there in a name? Well, name does matter when a manager wants to match up employee competency for a position. 😆

I hope this helps in others facing similar issues.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Hadrien Paquet

    Another best practice in case of any issues in SAP code would be to open a message to SAP to make sure than others don’t have to face the same issue.

    Thank you for you digging into this.

    (0) 
    1. Parag Parikh Post author

      Agreed and done already with raising OSS 🙂 Also see that no begin and end date are passed when reading PA0002 followed by READ on INDEX 1.

      New issue found is that if employee has two records in infotype PA0002, logic will select and display first record only.

      (0) 

Leave a Reply