Synchronization of IdM Tasks - part II

[former_member192665]

Hi there,
I had written earlier about Synchronization of IdM Tasks.

Recently, I have come across a situation in a customer project that has demonstrated pretty well how important synchronization can be.

Let's assume identities have an end date. Once the end date is reached a workflow is triggered that inactivates the user (whatever this means in detail). Usually, it will take a couple of minutes until the workflow reaches at its end and the user is really removed from the system. Or inactivated. Anyway, what I mean is that during this time the user shouldn't be available anymore for other activities, like requesting privileges etc.

The point I'm trying to make is that you might end up with 2 asynchroneous workflows that run in parallel. And that are kind of not compatible with each other. In the example above, imagine you start a request role workflow while the user is in the "inactivate user" workflow and in the middle of the role requesting the user suddenly vanishes from the system (inactivation means that all queries to the view mxiv_sentries for an inactive mskey will yield an empty result). This will simply result in an undefined behaviour. You'll probably get some completely weird error messages since the tasks that are supposed to handle your identity can't find it anymore.

The desired behaviour (translated into a proper UI error message) would be something like "Sorry, the system has detected that the person you're trying to assign a role is currently being inactivated. Can't process your request. Sorry for the inconvenience!".

In the above mentioned blog post I had presented how you can detect that an object is currently being processed. Just check for suspicious entries in the table mxp_provision for the given mskey.
Now, wouldn't it be great to really return the message above in the UI?
With input validation and rhidmo, this is a piece of cake.



I have created 2 example UIs. The first one inactivates the user. Let's say the second one provisions something (actually, it doesn't matter what it does. It isn't hard to imagine a workflow that will just behave weirdly when the object it handles just disappears in the middle of processing)..
The second one checks with the following validation script in the onSubmit hook that there is no item in the provisioning queue:

function ktec_js_check_inactivate_user (data)

{

    load ('ktec_js_helper');

    var caller = data.getCaller ();

    var user = data.getIdmObj ();



    info ("ktec_js_check_inactivate_user called by " + caller.getMSKEYVALUE () + " on behalf of " + user.getMSKEYVALUE ());



    var mskey = user.getMSKEY ();



    var result = ktec_js_selectList ("select SIGN(count(*)) from mxp_provision where actionid=1878 and mskey = " + mskey,

                                     new Array ());



    if (result!=null && result.size ()>0) {

        return "An inactivation is already running for this user. Submit not possible.";

    }

}

And you'll get a neat error message in the UI: