Mystery MX_PERSON objects

[Former Member]

Hi guys,

I'm encountering an issue where I seem to be getting some random MX_PERSON objects being created in the identity store under the name MX_<value> like MX_123456.

IdM version:  IdM 8.0 SP2 PL6

Database: Oracle 11.2

In the identity store I seem to be acquiring random MX_PERSON objects...

So I have a look in the audit tables and I can see the task referenced that created the object.

select * from MXP_AUDIT where mskey = (select distinct mskey from idmv_vallink_ext where mskey = (select mcmskey from idmv_entry_simple where mcmskeyvalue = 'MX_889242'));

And the task seems to be a 1 step process to resolve dynamic groups for an entry... eh?

select * from MXP_TASKS where taskid = 5086;

The process is attached to to some MX_PERSON attributes to be called on a modify event.

and heres the content of the script...

function custom_resolveDGMembership(Par) {


    /* Reset result */
    var result = "";
    var lv_identity = Par.get("MSKEY");


    /* Check the value isn't null and proceed, else return a null value and stop wasting time */


    if (Par != null && Par != "") {


        var lv_sqlQuery = "SELECT MCMSKEY FROM IDMV_ENTRY_SIMPLE WHERE MCENTRYTYPE = \'MX_DYNAMIC_GROUP\'";
        var lv_sqlResult = uSelect(lv_sqlQuery);
        var arrayOfResults = lv_sqlResult.split("!!");


        /* Loop through the array and get the mskey of the manager for each time interval. */
        for (i = 0; i < arrayOfResults.length; i++) {
            result = uResolveDGMembership(arrayOfResults[i], lv_identity);
        }
    } else {
        result = "";
    }
    return "";
}

Anyone experienced anything similar or have any thoughts on what might be causing these entries to be created?

Reproducing the issue seems to be near on impossible (happens sporadically).  Any thoughts would be appreciated.

Thanks,

Pat

[peterwass · Accepted solution]

Hi Patrick

Do the users have any additional information on them or are they just empty shells.

The MSKEYVALUE looks like what happens if you don't provide one during a create.  I wonder if its trying to write out data to the blank MSKEY and creating a new entry for it. Given you're not using the MSKEY value, change the attribute name to DUMMY or something similar

Peter

[Former Member · Accepted solution]

Thanks Peter.

It does just create a shell (basic 3 attributes (MSKEYVALUE, MX_ENTRYTYPE and DISPLAYNAME)).

I had checked the value used to create the name of the object (MX_<value>) to see if the value related to another object but it doesn't.  I.e. there is an entry MX_889242 but there is no object with an MSKEY value of 889242.

That's a good idea to try change the attribute name to DUMMY.  I will give that a go and play the waiting game to see if another object appears .

The strangest part is that there is nothing I can think of within that process, generic pass or script that should allow a new object to be created.

Regards,

Pat

[peterwass · Accepted solution]

The MX_<number> MSKEYVALUE is basically the IDM equivalent of 'next value'.  It has no relationship to the MSKEY by default.

I have found that sometimes it will treat things like that as 'update the data' and if you provide a referable attribute (MSKEY / MSKEYVALUE) it will attempt to update that record.  If that record doesn't exist, it creates it.

You can also add 'changetype modify' to the attribute list to prevent it creating records but you might get errors.  Much safer to just use an attribute name that doesn't have an internal meaning.

Peter

[Chenyang]

Hi Patrick,

These MX_PERSON entries are usually generated in a toIdentityStore pass, when you try to update an existing MX_PERSON, but the entry does not exist. If you put a condition like "changetype=modify", it will give you an error instead of creating a new entry.

The mskeyvalue 'MX_123456', looks like a pending value object to me. Maybe you can check the tasks that can generate pending value objects, but incorrectly put a 'MX_PERSON' as the entry type of the pass.

Cheers

Chenyang

[former_member201064]

I don't know if it helps, but I would change the script as following:

• Remove the returns. They aren't needed in a ToGeneric pass / script. Maybe they are even harmful
• Use for (var i;...) instead of for(i;...). This prevents that the variable i is re-used with a higher value than 0 when two entries enter the task/job at the same time. The MSKEYs of the created persons are directly after each other, so maybe that could be the main reason
• I can imagine that these two conditions (return and multiple executions in one run) combined are the reason why the persons are created. Can you check the log of the job whether there are two ore more entries in the same joblog entry?
• Add uWarnings where the returns and the uResolveDGMembership function are.

I would use a text for the uWarnings like these:

• "1: result = " + result where the u function is
• "2: input mskey was " + lv_identity
• "3: input mskey was " + lv_identity

Using the numbers you can identify which way the script went

Additionally I would include a to_char(mcLastModified, 'YYYY-MM-DD HH24:MI:SS.FF') and to_char(mcCreated, 'YYYY-MM-DD HH24:MI:SS.FF') to the query you used to determine the milliseconds when the persons were created. I hope that was the correct to_char command though.