Topic
  • 7 replies
  • Latest Post - ‏2013-03-19T18:17:37Z by yn2000
jdell
jdell
97 Posts

Pinned topic ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

‏2013-03-18T00:39:31Z |
Hello all,

I'm currently working on a prototype TDI/TIM application whereby a TDI assembly line reads "staff movement" records (e.g. resignations, back from leave) from a table in the HR database and then sets the erpersontstatus attribute according to the type of staff movement detected e.g. sets to "1" for termination or "0" if person's accounts need to be restored. There are workflows and provisioning policies already in place that then suspend/restore the person's accounts.

The prototype works nicely and the person's accounts are suspended/restored immediately in TIM. However, I now want to make use of the "effective date" field on the staff movement record and rather than suspend/restore accounts immediately, I would like to schedule the suspend/restore operation - like one can do in the TIM administration interface when suspending/restoring accounts manually.

I'm aware of the "process" tables that are modified in the TIM database, but adding records to these tables directly kind of "smells" to me. I've looked through the ITIM JS workflow extensions reference and I can't find anything there that could perhaps help me out.

At the moment I'm using a "push" mechanism for the feed from the HR database --> TDI --> TIM via a DB change detector connector in the TDI assembly line. I could change this to the more traditional "pull feed" via a TIM recon then check the effective date, compare that date to the current date and then change the person status. But if there is some way of doing this (assuming that it's not too convoluted) with my current connector setup, I'd like to investigate it further.

If anyone else has done this sort of thing before, I'd sure be interested in hearing from you. :)

Cheers,
John D.
Updated on 2013-03-19T18:17:37Z at 2013-03-19T18:17:37Z by yn2000
  • SystemAdmin
    SystemAdmin
    9855 Posts

    Re: ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

    ‏2013-03-18T06:51:40Z  
    Timebased automated lifecycle management is a very normal thing in this end of the world (northern europe)...

    IMHO the best way to do this is NOT to use the scheduler to drive the changes as this may conflict with other changes to the entities. IMHO the scheduled submit should only be used in special cases (e.g. timecritical submission of provisioning policies) and never for account/person changes.

    When we implement this we design a number of new attributes (e.g. start date, end date, grace period date. deletion date etc. depending on how the requirements are for the lifecycle) and then drives this from the operational workflow. One major design point is that changes to a person is handled the same way whether the source is HRFeed, console/ssui or some application. Also we normally define a dataowner of each attribute (normally HRFeed source) so that manual changes can be corrected bu the authoritative source automatically.

    HTH

    Regards
    Franz Wolfhagen
  • TiborB
    TiborB
    19 Posts

    Re: ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

    ‏2013-03-18T21:28:07Z  
    Timebased automated lifecycle management is a very normal thing in this end of the world (northern europe)...

    IMHO the best way to do this is NOT to use the scheduler to drive the changes as this may conflict with other changes to the entities. IMHO the scheduled submit should only be used in special cases (e.g. timecritical submission of provisioning policies) and never for account/person changes.

    When we implement this we design a number of new attributes (e.g. start date, end date, grace period date. deletion date etc. depending on how the requirements are for the lifecycle) and then drives this from the operational workflow. One major design point is that changes to a person is handled the same way whether the source is HRFeed, console/ssui or some application. Also we normally define a dataowner of each attribute (normally HRFeed source) so that manual changes can be corrected bu the authoritative source automatically.

    HTH

    Regards
    Franz Wolfhagen
    There is one noteworthy part implied but not explicitly mentioned by Franz: lifecycle rules. A dynamic filter can be used to trigger the time based action (workflow) based, see example below.
    
    (contractExpiry<=$
    {system.date + 15
    })
    

    Expressions that can be used in the filter are documented here: http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itim.doc/ref/ref_ic_lifecycle_ldap_filter.html

    Hope this helps.
       T
  • yn2000
    yn2000
    1086 Posts

    Re: ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

    ‏2013-03-19T03:48:46Z  
    Hmmm... "...I could change this to the more traditional "pull feed" via a TIM recon then check the effective date, compare that date to the current date and then change the person status..."

    It sounds that you are looking for the 'timer' connector in TDI.
    Please take a look at it and put it one of your design option.

    Rgds. YN.
  • jdell
    jdell
    97 Posts

    Re: ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

    ‏2013-03-19T04:12:49Z  
    • yn2000
    • ‏2013-03-19T03:48:46Z
    Hmmm... "...I could change this to the more traditional "pull feed" via a TIM recon then check the effective date, compare that date to the current date and then change the person status..."

    It sounds that you are looking for the 'timer' connector in TDI.
    Please take a look at it and put it one of your design option.

    Rgds. YN.
    Thanks to all for taking the time to respond to my post.

    So Franz/Tibor, I gather from your responses, I should really be looking at using a life cycle rule for my "scheduling" requirement. I do like that idea - I am aware of life cycle rules management in TIM, but have never used one "in anger". :).

    I've done some research on LC rules and at a high level it makes sense. However, I do have some queries.

    If we take the use case of an employee resignation, then I can easily store the termination date on the person record (we already use a customized object class for Person). I take it that I will need to write an LC rule for suspending the Person entity and another LC rule for suspending that person's accounts. What I don't quite understand is how to store the "termination date" on the account(s) for that person. OK, I know how to put the termination date on the account say via a provisioning policy, but does that mean I have to customize the object class for my account(s) to allow for this attribute? Or do I use the "custom use" attribute erlastoperation to store the termination date? For example, in your response Tibor, your example rule uses an attribute called contractExpiry - is that a custom attribute for account type entities?

    @yn2000 - Yes I'm aware of Timer connectors (I currently use them in many of my ALs) - and you're right I could use a timer connector in this case as well. I just want to see where this LC rules direction takes me. :)

    Cheers,
    John D
  • jdell
    jdell
    97 Posts

    Re: ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

    ‏2013-03-19T04:55:51Z  
    • jdell
    • ‏2013-03-19T04:12:49Z
    Thanks to all for taking the time to respond to my post.

    So Franz/Tibor, I gather from your responses, I should really be looking at using a life cycle rule for my "scheduling" requirement. I do like that idea - I am aware of life cycle rules management in TIM, but have never used one "in anger". :).

    I've done some research on LC rules and at a high level it makes sense. However, I do have some queries.

    If we take the use case of an employee resignation, then I can easily store the termination date on the person record (we already use a customized object class for Person). I take it that I will need to write an LC rule for suspending the Person entity and another LC rule for suspending that person's accounts. What I don't quite understand is how to store the "termination date" on the account(s) for that person. OK, I know how to put the termination date on the account say via a provisioning policy, but does that mean I have to customize the object class for my account(s) to allow for this attribute? Or do I use the "custom use" attribute erlastoperation to store the termination date? For example, in your response Tibor, your example rule uses an attribute called contractExpiry - is that a custom attribute for account type entities?

    @yn2000 - Yes I'm aware of Timer connectors (I currently use them in many of my ALs) - and you're right I could use a timer connector in this case as well. I just want to see where this LC rules direction takes me. :)

    Cheers,
    John D
    OK, with regards to my previous post I think I may have found my own answer to my queries.

    I created a no input suspend operation for my customized person entity, and set the accountSuspend flag to "true" in my relevant data items. I then created a simple LCR that just targets one person (uid=xxxx) and assigned the suspend operation to this rule.

    I ran the LCR and it worked a treat, suspending the person and all the person's accounts. So it appears that I can use the one LCR for my purposes (well for that one particular use case anyway). Of course I will have to use the termination date in my LDAP filter for the LCR.

    Does that sound like I'm on track? Are there any other issues that I should be aware of?

    Again, thanks for all your ideas and help - I really do appreciate it.

    Cheers,
    John D.
  • SystemAdmin
    SystemAdmin
    9855 Posts

    Re: ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

    ‏2013-03-19T07:15:48Z  
    • jdell
    • ‏2013-03-19T04:55:51Z
    OK, with regards to my previous post I think I may have found my own answer to my queries.

    I created a no input suspend operation for my customized person entity, and set the accountSuspend flag to "true" in my relevant data items. I then created a simple LCR that just targets one person (uid=xxxx) and assigned the suspend operation to this rule.

    I ran the LCR and it worked a treat, suspending the person and all the person's accounts. So it appears that I can use the one LCR for my purposes (well for that one particular use case anyway). Of course I will have to use the termination date in my LDAP filter for the LCR.

    Does that sound like I'm on track? Are there any other issues that I should be aware of?

    Again, thanks for all your ideas and help - I really do appreciate it.

    Cheers,
    John D.
    LCR are an essential part of any time based solution. They are performing the role of triggers - if you look at the re-certification logic this is exactly how it is performed.

    Depending on your requirements you can run them any minute, hour, day etc (I would recommend something in hour/day range not to overflow your requests database).

    I am simply so used to this kind of thinking that I forgot to mention it - but is good to have people here keeping me on track :-)

    Regards
    Franz Wolfhagen
  • yn2000
    yn2000
    1086 Posts

    Re: ITIM/TDI: Scheduling account suspend/restore via feed (design suggestions)

    ‏2013-03-19T18:17:37Z  
    LCR are an essential part of any time based solution. They are performing the role of triggers - if you look at the re-certification logic this is exactly how it is performed.

    Depending on your requirements you can run them any minute, hour, day etc (I would recommend something in hour/day range not to overflow your requests database).

    I am simply so used to this kind of thinking that I forgot to mention it - but is good to have people here keeping me on track :-)

    Regards
    Franz Wolfhagen
    IMO, timer in TDI and LCR in TIM does the same thing. It is a matter of designer's preference, whether he/she chooses to have the logic in TDI or in TIM. Both have their advantages and disadvantages. If you can use LCR then this would be your first choice, because some advantages that LCR can offer, but LCR is dealing with a static data, which is the current LDAP data at the time that the LCR is running. It means that you don't have before and after data, unless you put a bunch of flag attributes.

    Rgds. YN.