Pending Value Problem / Attribute Not Being Read

[Former Member]

Hello fellow experts. I've written something about this problem before. I had hoped that by rebuilding the repository where I'm having my provisioning issue, the problem would be solved but I'm still having the same issue. This leads me to believe it's something inside the provisioning framework or maybe a bug inside IDM itself.

A little background on my environment, I am running IDM v7.2, patch 5 on top of an Oracle database.

I'm trying to write some attribute values back to HCM from IDM. To do this, I used a setup that has been covered in other discussions. Basically, I have a repository that was created as an AS ABAP Application Specific repository referring back to my HCM system and the hook tasks have been manually changed to use the Business Suite tasks.  I have a BAdI setup on HCM's side and ran the initial load to bring the HR_COMMUNICATION privilege over to IDM. This all worked. My test user has an account in HCM and the PRIV_XXX_ONLY and PRIV_SYSTEM_XXX privileges for this repository and has an email address attribute, MX_MAIL_PRIMARY, and an ACCOUNTXXX attribute.

When I attempt to assign the HR_COMMUNICATION privilege for this repository, the pending value that get created doesn't grab the MCVALUE from this person's record in the Identity Store.

This makes no sense to me. The value is clearly there. Why is it not being entered into the pending value entry type for the provisioning framework to process it? Here's the task in question:

I'm at a complete loss on this one. If anyone has any suggestions or paths I could go down to look into this, I'd be eternally grateful. Thanks.

[Former Member · Accepted solution]

So thanks all for getting me to think about the various different ways in which this problem could be solved. I did, finally, get it fixed yesterday. Like I've been saying, this is a DEV environment and this functionality works in PROD so while I wanted to fix the problem without going this far, the thought occurred to me that maybe I should just import PROD's Provisioning Framework then point all my hook tasks and whatnot to that framework. That seems to have done the trick.

I would still be interested in know what the real problem was in case I run across it again but in the world of consulting, the method of solving the problem really doesn't matter, only that the problem is solved.

[Former Member · Accepted solution]

Awesome. If you add a "delay before start" (to halt the processing for a few minutes) on the task that used to fail, then look at the PVO values/audit as I mentioned earlier you should be able to see where it's set.

[Former Member · Accepted solution]

That's a good idea too. I sometimes forget I can put a delay on tasks which would allow the pending value to hang out there for a bit and thus let me look at it. Thanks for that. I'll use that at some point in the future, I'm sure. 

[Former Member]

Hi Brandon,

Looking at the destination grid it seems that the parameters for the verifyValueExists

  ACCOUNT%$rep.$NAME%!!%ACCOUNT%$rep.$NAME%%

should have become

  ACCOUNTHCDE210!!<value of users ACCOUNTHCDE210 attribute>

Since your entry in screenshot 1 has mskey 179959, and the DSE log has mskey 195263 I'm guessing that this is running as a PVO and as you say it does not have this value. If I remember correctly the PVOs referenced user value can be accessed using:

  ACCOUNT%$rep.$NAME%!!%PARENT.ACCOUNT%$rep.$NAME%%

Unless some other task elsewhere in the framework is supposed to add this attribute to the PVO but is not linked in to your workflow or fails to do so for this repository.

I could be wrong and I have been out of SAP/IdM for a while now so I have no way to check... 🙂

Br,

Chris

[Former Member]

Thanks Chris. I'll give that try. The only thing that bothers me about that is this same task with the same destination setup works in this company's PROD environment. So why is there a problem in DEV? It makes no sense to me. I can tell by the slow-to-come responses that the community on here is seemingly just as stumped as I am. I actually did manage to capture one of the PVOs during one of my test runs. Don't know if anything stands out in here but if you see something, let me know.

[Former Member]

The task might be identical in Dev and Prod but the data they work with is probably not 🙂 The ACCOUNTHCDE210 is not there so addressing it as %ACCOUNTHCDE210% in the destination pass will give the error you see.

Not sure if you're able to run a query that lists existing PVOs that contain an attribute named ACCOUNT% in the working environment, something like

select mskey,searchvalue,changeby,changebyaudit,modifytime,userid from idmv_value_ext where (attrname like 'ACCOUNT%' or attrname like 'MX_ENTRYTYPE') and mskey in

(select mcmskey from idmv_entry_simple where mcEntryType='MX_PENDING_VALUE')

- Check the modifytime - If it is automatically set during PVO creation it should have the same modifytime, or very close to, the entrytype value.

- If useid is set it would be the job/actionid that set it, and you need to locate it in the broken environment to see what is failing or if its linked into the workflow properly.

Again, I've not been able to check any of the above.

Br,

Per Christian

[Former Member]

One quick question while I seem to have your attention, I've been able to trace this workflow pretty well and through all of that, the core of this problem seems to be that the PVO doesn't contain the necessary information. It works in PROD but not in DEV. This leads me to believe that the process used to create PVOs in PROD is different than it is in DEV. Where is this process located? I'd like to see the code or task or job, whatever it is that specifically creates the PVO and evaluate it. I don't know where to look to find that piece of functionality. If I could see that process, I think I could solve this problem. It's the only piece of this puzzle I'm unable to directly evaluate.

[Former Member]

The PVO is usually created by the evaluate link procedure when someone does an assignment (mxref or mxmember attribute) from the UI/job/action, or directly by a job/action that creates a PVO entry. In the assignment case the eval-link procedure and is an async process disconnected from the actual assignment. In any case the PVO and its audit/linkaudit should tell you who initiated the assignment.

- If it's an assignment - Check the validate add and addmember task workflows defined on the repository

- If it's programatic - Check the task creating the PVO (see audit and PVO to trace back to it)

[terovirta]

Brandon Bollin wrote:

Hello fellow experts. I've written something about this problem before. I had hoped that by rebuilding the repository where I'm having my provisioning issue, the problem would be solved but I'm still having the same issue.

Do you have a screen shot of your repository? I've done this only once and with ramp-up version of 7.2 on SQL Server but cannot remember any specific issues. Duplicated HCM repository for 0105 write back and as far as I remember the only trick was to add NO_USER_ACCOUNT=1 repository constant.

Are you provisioning SU01 roles/profiles to same system (via different repository) with same PF hook tasks and that works okay?

regards, Tero

[Former Member]

You might be on to something with that one. I'm actually working on a DEV system and this all works in PROD so I'll go into the PROD system and see what differences there are between my DEV repository and the PROD one. Here's a screenshot of my problem repository in DEV.

[Steffi_Warnecke]

That's the problem with not sitting in front of a system... I'd have checked the mentioned script then, before answering here. ^^ But since that's what would be my start point of searching for the issue, I shared the idea. Normally I work my way backwards from the error messages .

Hmm, I really would love to have access to my system right now to check some things. *sign*

[Steffi_Warnecke]

Hello Brandon,

are changes on the identity itself (like search term or things like this you'd find in the SU01) provisioned to this system? Am I understanding this correctly, that only provisioning of the privilege fails?

My next step would be to have a closer look at that script and test the sql-statements in it via my SQL developer to see, what results those give back.

Regards,

Steffi.

[Former Member]

Once the HR_COMMUNICATION privilege is added to the user, changes on that user's account, in this case an e-mail address, would be provisioned to HCM so that this user's HRIS record would reflect his/her e-mail address.

Problem is, when I attempt to assign the privilege via the UI, after doing all the processing, it comes back "Failed". When you assign a privilege, this creates a pending value and that pending value is the source of information for the job (actually a task) pictured in my last screen shot. When that pending value is created, it should grab the MCATTRNAME of ACCOUNTHCDE210 and the MCVALUE; in the case of my test user that would be TESTINCN (highlighted in the first screen shot).

I setup a task to capture the attributes stored in an MX_PENDING_VALUE entry type upon creation so I could see this for myself as, once a pending value is processed, it's deleted with no record of its existence, much less what it contained. And, exactly as the error messages show, the MCVALUE isn't being added to my pending value even though there clearly *IS* an MCVALUE for this attribute on my user record.

If you want a little more background on this unique IDM to HCM provisioning setup, check out this discussion entry as it's exactly what I'm using:

Also, I can't test the script's SQL statements as it contains none. It is simply checking the pending value to make sure the necessary information is in there so the framework can do it's job. Since it's finding a NULL value where my account name should be, it's skipping the job entirely and failing to add the privilege to my user.