Highlighted
New Member.
723 views

User Application Role and Resource Provisioning Requests

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?
Labels (1)
0 Likes
9 Replies
Highlighted
New Member.

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.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

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.

Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Highlighted
Outstanding Contributor.
Outstanding Contributor.

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&Resource driver that manage request states, you should check the trace log of this driver for any errors.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

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&Resource driver that manage request states, you should
> check the trace log of this driver for any errors.


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?)



0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

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.




Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

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...)


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

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.



0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

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.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner


>> 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.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.