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]

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)