Conditional Update Script Question

This topic has 6 replies, 3 voices, and was last updated 5 years, 11 months ago by [email protected].

  • Author
    Posts
  • #5537
     Matt Mencel
    Participant

    When I create a new managed user object from the official record system (CSV file), the user doesn’t yet have a username or email created for them yet. Those are generated when I request LDAP to generate a new account. So initially I just create their userName as their personId and their mail as [email protected].

    Eventually the account gets provisioned in LDAP with a real username and email and I will push those back into the managed user object in OpenIDM.

    I don’t wan’t to then update the username and mail fields again from the CSV file mapping. I think I need to setup a Conditional Update Script on those two attributes. This is the explanation, “If the result is true or if there is no script the property will be updated, otherwise updates will not be sent to the target.” So I think I need to return false if the managed user object exists, correct?

    Something like….

    if (typeof object === ‘undefined’) {
    }

    Is that right or should I be doing something else?

    Thanks,
    Matt

    #5538
     Chris Drake
    Participant

    Matt,

    If I understand you correctly, you have the following mappings in OpenIDM.

    CSV -> Managed User
    LDAP -> Managed User

    The first mapping from CSV -> Managed User is responsible for the initial creation of a skeleton the Managed User object. The LDAP -> Managed User is responsible for updating the Managed User object once the LDAP Account has been created and allows the Managed User to be populated with additional attributes.

    Do you have a requirement to push updates from CSV to Managed User? Or post creation does LDAP become the authoritative source for updates? If you do not need to push updates from CSV -> Managed User then the simplest solution is to set the actions for the FOUND and CONFIRMED situations on the CSV mapping to ASYNC.

    For example:

                    {
                        "situation" : "CONFIRMED",
                        "action" : "ASYNC"
                    },
                    {
                        "situation" : "FOUND",
                        "action" : "ASYNC"
                    },
                    {
                        "situation" : "ABSENT",
                        "action" : "CREATE"
                    }
    

    The above ensures that UPDATEs are never pushed to Managed Users from CSV, and only CREATE operations are performed when the managed user does not already exist.

    Regards,
    Chris

    #5552
     Matt Mencel
    Participant

    Hi Chris,

    The CSV is authoritative for most of the standard attributes like first/middle/last names, address and phone, etc. So I need to continue to be able to feed updates into Managed User from that connection.

    LDAP will be authoritative for username, email, and few other attributes. LDAP will have two mappings to Managed User, one as target and one as source.

    CSV -> Managed User
    LDAP <–> Managed User

    So I still need some kind of conditional on a couple attributes from the CSV source so they don’t overwrite the values that LDAP is feeding into Managed User.

    Thanks,
    Matt

    #5553
     Chris Drake
    Participant

    Matt,

    In that case there are a few ways you can accomplish this. You can either use a condition on the individual attributes, or you can use an onUpdate trigger within your mapping to remove attributes from the target object that you do not want to push to the external system.

    In the case of a condition you need a way to determine whether the source object has just been created, or whether it is being updated. You can use the onCreate and onUpdate managed.json triggers to set a flag on creation, and remove it when the object is updated. The presence of this flag can then be used by your condition to determine if the specific attributes should be pushed out or not.

    If you go the route of the onUpdate trigging within the mapping, then you could do something like the following within the onUpdate trigger:

    
    delete target['mail'];
    delete target['personId'];
    

    Regards,
    Chris

    #5554
     Matt Mencel
    Participant

    Thanks Chris, I’ll give that a try. I’m assuming the ‘delete target’ in this case doesn’t actually mean to delete the attribute in the target (Managed User), just to delete the update action for that target attribute?

    Matt

    • This reply was modified 6 years, 1 month ago by Matt Mencel.
    #5584
     Chris Drake
    Participant

    Matt,

    That’s correct. The delete is just to remove the attribute from the calculated target object and will not actually cause the attribute to be deleted from the target.

    Regards,
    Chris

    #6202

    HI Chris,

    I was checking the scripting reference and onUpdate hook doesn’t have source/target object, it has oldObject and newObject. Am I missing something here?

    Thank You,
    Mukesh

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

©2021 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?