vkhoury;2491067 wrote:
Hi I'm using User application with IDM 4.7.
I would like to create a workflow in order to allow a manager to approve or revoque a Provisioning Request for roles and resources.
I noticed that under the UA/Entitlements in designer there is a series of templates of workflows.
But these workflows are only simulated by an PRD in AD and not by the Request page where users can normally request roles.
I've tried to solve this problem by adjusting the options of the role created in role catalog and require an approval from a manager.
But what is really weird is that once the user requests the role it is provisioned immediately without approval.
Is it normal to have such response? I think i must be missing something in the process.
What is the right way of doing this?

I realized that once a user request a role the request remains in pending state for about 24 hours before appearing in the task section of the user responsible of provisioning the role.
However, I don't know why it's taking that much time and if tif this can be configured or not.

vkhoury;2491067 wrote:
Hi I'm using User application with IDM 4.7.
I would like to create a workflow in order to allow a manager to approve or revoque a Provisioning Request for roles and resources.
I noticed that under the UA/Entitlements in designer there is a series of templates of workflows.
But these workflows are only simulated by an PRD in AD and not by the Request page where users can normally request roles.
I've tried to solve this problem by adjusting the options of the role created in role catalog and require an approval from a manager.
But what is really weird is that once the user requests the role it is provisioned immediately without approval.
Is it normal to have such response? I think i must be missing something in the process.
What is the right way of doing this?

I realized that once a user request a role the request remains in pending state for about 24 hours before appearing in the task section of the user responsible of provisioning the role.
However, I don't know why it's taking that much time and if tif this can be configured or not.

vkhoury <vkhoury@no-mx.forums.microfocus.com> wrote:
>
vkhoury;2491067 Wrote:
>
>> I've tried to solve this problem by adjusting the options of the role
> created in role catalog and require an approval from a manager.
>> But what is really weird is that once the user requests the role it is
> provisioned immediately without approval.
>> Is it normal to have such response? I think i must be missing something
> in the process.
>> What is the right way of doing this?
>

You can use the default rope approval PRD as a template and customise it to
your hearts content.

> I realized that once a user request a role the request remains in
pending state for about 24 hours before appearing in the task section of
the user responsible of provisioning the role.
> However, I don't know why it's taking that much time and if tif this can
be configured or not.

It shouldnâ€t take so long. Sounds like it is waiting a timeout of some
sort.

Also keep in mind that users assigned to a role via an indirect mechanism
(group to role, container to role, role to role) skip any defined approval
workflow. This is by design.

vkhoury;2491194 wrote:
I realized that once a user request a role the request remains in pending state for about 24 hours before appearing in the task section of the user responsible of provisioning the role.
However, I don't know why it's taking that much time and if tif this can be configured or not.

This is the Role

On 11/21/2018 5:36 AM, sma wrote:
>
> vkhoury;2491194 Wrote:
>> I realized that once a user request a role the request remains in
>> pending state for about 24 hours before appearing in the task section of
>> the user responsible of provisioning the role.
>> However, I don't know why it's taking that much time and if tif this can
>> be configured or not.
>
> This is the Role

Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
>
>
> The RRSD driver is interesting in how it works.
>
> It events on certain things (users, nrfRequest objects,
> nrfResourceAssociation objects) and it checks dynamic groups on a
> schedule. It also seems to look for events due on a schedule as well.
>
> So if you have something with a pending time period, then RRSD is what
> is watching for that to come due and process it. (Perhaps you have set
> RRSD to a very long polling interval to reduce load from checking a lot
> of dynamic groups?)
>

IiRC Polling period for other things than dynamic groups canâ€t be tweaked.

More likely the RRSD driver was stuck/stopped and that is explanation for
delay.

On 11/21/2018 2:13 PM, Alex McHugh wrote:
> Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
>>
>>
>> The RRSD driver is interesting in how it works.
>>
>> It events on certain things (users, nrfRequest objects,
>> nrfResourceAssociation objects) and it checks dynamic groups on a
>> schedule. It also seems to look for events due on a schedule as well.
>>
>> So if you have something with a pending time period, then RRSD is what
>> is watching for that to come due and process it. (Perhaps you have set
>> RRSD to a very long polling interval to reduce load from checking a lot
>> of dynamic groups?)
>>
>
> IiRC Polling period for other things than dynamic groups canâ€t be tweaked.
>
> More likely the RRSD driver was stuck/stopped and that is explanation for
> delay.

Or slow? It is within the realm of possibility that evaluating the
Dynamic groups took that long. (Would be a very very bad design if true...)

On 11/21/2018 2:13 PM, Alex McHugh wrote:
> Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
>>
>>
>> The RRSD driver is interesting in how it works.
>>
>> It events on certain things (users, nrfRequest objects,
>> nrfResourceAssociation objects) and it checks dynamic groups on a
>> schedule. It also seems to look for events due on a schedule as well.
>>
>> So if you have something with a pending time period, then RRSD is what
>> is watching for that to come due and process it. (Perhaps you have set
>> RRSD to a very long polling interval to reduce load from checking a lot
>> of dynamic groups?)
>>
>
> IiRC Polling period for other things than dynamic groups canâ€t be tweaked.

Actually, I thought you could. I was about to complain that I
remembered there being one and was about to accept your Authoritah
(Cartman reference anyone?). I was about to write that I was wrong. But
I thought, I remember that being an option.

Dropped an RRSD driver into Designer, and dound this setting:

<definition display-name="Frequency of reevaluation of dynamic and
nested groups (in minutes)" name="dyn-group-interval" range-hi="1440"
range-lo="1" type="integer">
<description>The frequency in minutes at which dynamic and nested
groups that are associated with roles are reevaluated to determine
changes in membership.</description>
<value>60</value>
</definition>

So dyn-group-interval in minutes. Now that is a 4.7 config.

Went back to see when it appeared. 2.0 package has it (I went to 2.0
thinking it would be far enough back, even 1.0 has it!)

1.0 is a IDM 4.0, and 2.0 is a 2012 build.

Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
> On 11/21/2018 2:13 PM, Alex McHugh wrote:
>> Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
>>>
>>>
>>> The RRSD driver is interesting in how it works.
>>>
>>> It events on certain things (users, nrfRequest objects,
>>> nrfResourceAssociation objects) and it checks dynamic groups on a
>>> schedule. It also seems to look for events due on a schedule as well.
>>>
>>> So if you have something with a pending time period, then RRSD is what
>>> is watching for that to come due and process it. (Perhaps you have set
>>> RRSD to a very long polling interval to reduce load from checking a lot
>>> of dynamic groups?)
>>>
>>
>> IiRC Polling period for other things than dynamic groups canâ€t be tweaked.
>
> Actually, I thought you could. I was about to complain that I
> remembered there being one and was about to accept your Authoritah
> (Cartman reference anyone?). I was about to write that I was wrong. But
> I thought, I remember that being an option.
>
> Dropped an RRSD driver into Designer, and dound this setting:
>
> <definition display-name="Frequency of reevaluation of dynamic and
> nested groups (in minutes)" name="dyn-group-interval" range-hi="1440"
> range-lo="1" type="integer">
> <description>The frequency in minutes at which dynamic and nested
> groups that are associated with roles are reevaluated to determine
> changes in membership.</description>
> <value>60</value>
> </definition>
>
> So dyn-group-interval in minutes. Now that is a 4.7 config.
>
> Went back to see when it appeared. 2.0 package has it (I went to 2.0
> thinking it would be far enough back, even 1.0 has it!)
>
> 1.0 is a IDM 4.0, and 2.0 is a 2012 build.
>

That option is just for dynamic groups, interestingly enough, the dynamic
groups value snaps neatly
to the system clock. (So if you say every 15 mins, it will be on the hour,
quarter past hour etc. It doesnâ€t start from driverâ€s restart time).

Everything.else seems to happen every minute (or at least on a fixed
schedule) without any capability to adjust this.

IIRC The tasks it checks for on a fixed 1 minute schedule are expired/old
assignments and the like.

You can see all of this if you set trace to 1 or higher for RRSD.

Also these timer based jobs must run to completion which is confusing if
you are in middle of dynamic group refresh and stop the RRSD driver. It can
look like it is “hung” and refuse to stop until it completes that group
refresh job.

You should resist temptation to set group refresh rate under 10 mins. It
can be unreliable with such a setting.

>> So dyn-group-interval in minutes. Now that is a 4.7 config.

>
> That option is just for dynamic groups, interestingly enough, the dynamic
> groups value snaps neatly
> to the system clock. (So if you say every 15 mins, it will be on the hour,
> quarter past hour etc. It doesnâ€t start from driverâ€s restart time).

That is interesting to know.

> Everything.else seems to happen every minute (or at least on a fixed
> schedule) without any capability to adjust this.

So expiration/approval checking should happen on the minute.

> IIRC The tasks it checks for on a fixed 1 minute schedule are expired/old
> assignments and the like.
>
> You can see all of this if you set trace to 1 or higher for RRSD.
>
> Also these timer based jobs must run to completion which is confusing if
> you are in middle of dynamic group refresh and stop the RRSD driver. It can
> look like it is “hung” and refuse to stop until it completes that group
> refresh job.
>
> You should resist temptation to set group refresh rate under 10 mins. It
> can be unreliable with such a setting.

Agreed.