User ID getting deleted Repeatedly

[Former Member]

Hi Experts,

  The User ID is getting deleted Repeatedly in IdM. This is happening with only one Employee. All the other employees are fine. I even checked the value of the attribute 'MX_FS_EMPLOYMENT_STATUS_ID'  for that Employee, and its 3(Active) and not 0(Withdrown). Dont know what is gone wrong.

select aValue from mxiv_sentries where MSKEY = 227669 and AttrName =

'MX_FS_EMPLOYMENT_STATUS_ID'

PFB the Job screen shot FYR.Please do Help.

Regards,

Mohamed Fazil

[ivan_petrov]

Hi Praman,

As Peter already said, the main question here is how(from which task exactly) you are calling this task?

Without knowing your scenario all we can do is shooting in the dark.

Best regards,

Ivan

[Former Member]

Hi Mohamed

How is this job getting triggered? Is it an event task or triggered by a UI task?

How its being called can affect the SQL - it may be that you're actually querying a PendingValue rather than the actual object with %MSKEY%.  You should be able to find out pretty easily (although logging in switch and conditional tasks is poor you can add other tasks around them to do the work).

I'm not sure how its going to deal with blank values either - sometimes its a little picky.  Thats why I prefer the count option when just choosing between 2 options. It guarantees an outcome.

Peter

[terovirta]

Peter Wass wrote:
I'm not sure how its going to deal with blank values either - sometimes its a little picky.  Thats why I prefer the count option when just choosing between 2 options. It guarantees an outcome.

Switch-task has an "else" branch which offers way to output trace stuff to job log.

So Mohamed, if you follow Peter's advice about the PVO and note the MSKEY from the job log, what does executing the SQL with that MSKEY return?

[Former Member]

Hi Mohamed,

Sorry if this appears rude but why are you doing this in the first place?

If you want to deprovision exited employees, add an event task on modify event of MX_FS_EMPLOYMENT_STATUS_ID, in there check to see if it was switched to 3 using the same SQL you are using above and if it was 3, remove the users roles and privileges with a to IdS pass with {d} operator on MXREF_MX_ROLE and MXREF_MX_PRIVILEGE. Then let the standard framework take care of all the deprovisioning, including removing account flags etc.

Hope that helps,

Ian

[former_member2987]

Ian,

Spot on! A direct and simple approach!

[terovirta]

Matt Pollicove wrote
Spot on! A direct and simple approach!

Regardless of what happens inside the switch task in regards of user deletion, the SQL condition of the task would be the same and that seemed to be the problem here..

Mohamed, don't put customizations to SAP PF folder that is going to be affected by new PF version import.

[Former Member]

Hi  Praman,

From what I see your select  is wrong.

If you want to check a condition and the expected result isTRUE or FALSE you should change  the select.

select COUNT(aValue) from mxiv_sentries where MSKEY = 227669 and AttrName =

'MX_FS_EMPLOYMENT_STATUS_ID' - and add a condition for the attribute value(if it's 3 or 0)

I'm not familiar with this view, but if you want show me what you have fot this mskey in the view and I can make a select.

BR,

Simona

[Former Member]

Hi Simona,

    Thanks a lot for your reply. But we are not expecting TRUE or FALSE so as to make decision, but instead we are selecting the value of 'MX_FS_EMPLOYMENT_STATUS_ID', if its 3 or 0, if 0 then only Delete.(Please check the attached screen shot in my previous post). But my doubt is why is the ID getting deleted even though the Select Query is returning 3 (and not 0). Please do let me know if u need any oter details so that I can provide you.

Regards,

Mohamed Fazil

[Former Member]

Hi Praman,

You can try to check from your job log(for this user) the audit ID:

select * from mcmv_audit where auditref=AuditID; - and from here you can get the refaudit that has call the job.... and so on, until you see the root cause(the task that has started the provisioning).

BR,

Simona

[former_member2987]

From what I am seeing here you are just getting the values of MX_FS_EMPLOYMENT_STATUS_ID.  Which could be anything, I'm assuming that there's some further logic to evaluate what to do based on the value in a script or switch task?

Matt

[terovirta]

Matt Pollicove wrote:
From what I am seeing here you are just getting the values of MX_FS_EMPLOYMENT_STATUS_ID.  Which could be anything, I'm assuming that there's some further logic to evaluate what to do based on the value in a script or switch task?
Matt 

I guess the only way to "debug" would be having an empty job just before the switch-task, execute the same SQL in javascript with uSelect and uErrMsg the result set of the query. But if the same SQL has been run in query tool and it returns non zero..

I have the same SQL (in 7.2 data model format) in my current project, only difference is that ID Store is referred in WHERE-clause, but MSKEYs are unique at Identity Center level, so that shouldn't be the issue.