Skip to Content
avatar image
Former Member

Mystery MX_PERSON objects

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    Aug 23, 2016 at 05:00 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • 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

  • Aug 23, 2016 at 04:37 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • Aug 24, 2016 at 03:41 AM

    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

    Add comment
    10|10000 characters needed characters exceeded