Topic
  • 4 replies
  • Latest Post - ‏2014-03-03T06:52:47Z by franzw
itimnewie
itimnewie
3 Posts

Pinned topic how access request workflow determines to add or modify account?

‏2014-02-27T07:30:10Z |

Hi all,

I currently have a problem whereby 2 accounts are created for a user after the approver approved the access request. Each account will contain only 1 access that the user requested.

It will happen whenever the user requested for 2 or more accesses at the same time when he did not have any account for that particular service.

If the user already had an account for the service, the existing account will be modified instead.

I would like to know if it's possible for me to do a check in the workflow so that the issue of 2 accounts being created will not happen.

  • goonitsupport
    goonitsupport
    103 Posts

    Re: how access request workflow determines to add or modify account?

    ‏2014-02-27T13:40:09Z  

    There are time when race conditions cause problems in ISIM and IBM would simply say that it is working as designed.

    However I would say this sounds like a genuine problem and one you shouldn't have to code around. I would raise a PMR for this. At the very least they will provide a workaround.

  • franzw
    franzw
    339 Posts

    Re: how access request workflow determines to add or modify account?

    ‏2014-02-28T08:49:02Z  

    There are time when race conditions cause problems in ISIM and IBM would simply say that it is working as designed.

    However I would say this sounds like a genuine problem and one you shouldn't have to code around. I would raise a PMR for this. At the very least they will provide a workaround.

    I believe the problem is the very well known problem that the entities in the default workflows/operations are not updated before the actual write to the ldap is performed.

    The workflow engine persists the entity (e.g. account) as it looks like at the point in time it is created - for long time (asynch)  transactions you will see the problem you describe.

    The good thing is that you can easily solve it by inserting a script node that basically takes the DN of the entity - looks up the current value in the ldap and updates this :

    ....

    myAcc = new Account(account.dn);

    account.set(myAcc);

    ....

     

    It is assumed in the code here that the account is stored in the property "account" - in some workflow this is "entity"....

    Code comes without testing and warranty :-)

    HTH

    Regards

    Franz Wolfhagen

  • itimnewie
    itimnewie
    3 Posts

    Re: how access request workflow determines to add or modify account?

    ‏2014-03-03T02:20:42Z  
    • franzw
    • ‏2014-02-28T08:49:02Z

    I believe the problem is the very well known problem that the entities in the default workflows/operations are not updated before the actual write to the ldap is performed.

    The workflow engine persists the entity (e.g. account) as it looks like at the point in time it is created - for long time (asynch)  transactions you will see the problem you describe.

    The good thing is that you can easily solve it by inserting a script node that basically takes the DN of the entity - looks up the current value in the ldap and updates this :

    ....

    myAcc = new Account(account.dn);

    account.set(myAcc);

    ....

     

    It is assumed in the code here that the account is stored in the property "account" - in some workflow this is "entity"....

    Code comes without testing and warranty :-)

    HTH

    Regards

    Franz Wolfhagen

    hi franzw and goonitsupport,

     

    thanks for your suggestions.

    I tried franzw's method but unfortunately I got the following error:

     

    Script interpreter error, line=1, col=65 Unknown member 'isNew' in Java Class 'com.ibm.itim.script.wrappers.generic.ProtectedAccountWrapper'

    I believe I got this error because the input parameter is actually a UserAccess type instead of a Account type. From what I read in ITIM documentation,  UserAccess extends the Account class there are some methods that are used by ITIM internally. By overwriting the UserAccess object with the entity, these methods are lost i think.

     

     

     

  • franzw
    franzw
    339 Posts

    Re: how access request workflow determines to add or modify account?

    ‏2014-03-03T06:52:47Z  
    • itimnewie
    • ‏2014-03-03T02:20:42Z

    hi franzw and goonitsupport,

     

    thanks for your suggestions.

    I tried franzw's method but unfortunately I got the following error:

     

    Script interpreter error, line=1, col=65 Unknown member 'isNew' in Java Class 'com.ibm.itim.script.wrappers.generic.ProtectedAccountWrapper'

    I believe I got this error because the input parameter is actually a UserAccess type instead of a Account type. From what I read in ITIM documentation,  UserAccess extends the Account class there are some methods that are used by ITIM internally. By overwriting the UserAccess object with the entity, these methods are lost i think.

     

     

     

    I do not think your analysis is right - but you should really show us what you are doing - without your code we are left in the dark...

    Did you read the account object from the properties - e.g. account = account.get() ? If you r analysis is right you should some how use the user access object and get the account from that - eventually you can check the <titm_data>/enRoleModel.xml file to see the relationships.

    I have deliberately left out all this basic code (and the null checking that should be performed) - this is part of your home work...

    HTH

    Regards

    Franz Wolfhagen