Highlighted
Absent Member.
Absent Member.
688 views

Pick up object with some attributes that has changed today

Jump to solution

Hi,

I have a text driver that runs once a day and writes users that has been
added or updated to a csv file that later get exported to a other
system.
That system has a problem handling files were the same users exist
multiple times, like for instance if the users is added and later the
same day is updated with a phone number then I'm ending up with a file
looking like this
user1;;;;
user1;phonenumber;;;
And then remote system chokes.
I have a powershell script that scans thru the file and removes
duplicates before moving file to remote system. But that dosent help in
this case.
So I was thinking if there is a possibility to create a job that runs
once a day that pick up users that has got some specific attributes
(like phone number etc) updated the last x hours and let the driver
write those to csv file?
All suggestion welcome
/Lelle


--
lelle
------------------------------------------------------------------------
lelle's Profile: https://forums.netiq.com/member.php?userid=410
View this thread: https://forums.netiq.com/showthread.php?t=57794

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Knowledge Partner
Knowledge Partner
lelle wrote:

>
> All suggestion welcome



Here is how I would do this (without messing about with ECMAScript)
Note ECMAScript is great and might be a good choice here, but this is a
way to leverage the event based nature of IDM to achieve the same
result.

1 Add/amend policies related to trigger job.


a. create a subscriber trigger job with the following config:
b. Run once a day
c. Scoped on your users container, configured so that it generates a
trigger event for each user in the container.
d. Only generate trigger events for associated objects (this part is
important)
e. make sure that the user that the job runs as has enough rights to
read associations on the users.

2. Add/amend policies related to daily export

a. sub-etp, additional scoping (as required)
b. sub-etp (modify existing stylesheet) convert ONLY trigger to
instance document with all the required attributes for the export.
d. otp (modify existing stylesheet to generate CSV - you probably
already have this, plus generate a remove-association event for each
instance)

3. Add amend policies and filter to detect and queue changes

a. sub-etp, scoping - veto add/modifies for already associated users
b. sub-ctp for users with operation add/modify - add association
(direct) and veto
c. driver filter, set all attributes that you want to detect a change
on as subscriber sync. Also set User class as subscriber sync.

The way this works, every time a user is changed on an attribute you
care about, if the user is not yet associated with the driver, it will
be. (but not yet exported to file, as we veto straight away)

Then once a day, the trigger fires off and generates a list of
associated users (those that have changed since last export)

The triggers get converted into instances and then converted into
delimited strings. Association is removed during this process, so the
user won't be exported again until a relevant attribute is
changed/updated again.
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.

View solution in original post

14 Replies
Highlighted
Knowledge Partner
Knowledge Partner
Sure, use a job to contain the logic, but I'd probably actually implement
the logic via ECMAscript making LDAP calls to the directory. It's really
easy to find objects created since the yesterday by querying by
createTimestamp, or finding things modified by modifyTimestamp, both which
are operational properties that can be queried via LDAP.

You coudl also do this outside of IDM, but then you need to maintain it
wherever it is (cron job plus script plus credentials stored in a file
somewhere).

Look at the Password Notification driver configuration from Lothar for an
idea of how this is done with password notification, which is really very
similar in implementation; it is kicked off periodically, queries for all
objects whose passwords are within an interval and which have not been
notified yet within that interval, and then it iterates over the results
(which come from LDAP) and sends the e-mails.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner
lelle wrote:

>
> All suggestion welcome



Here is how I would do this (without messing about with ECMAScript)
Note ECMAScript is great and might be a good choice here, but this is a
way to leverage the event based nature of IDM to achieve the same
result.

1 Add/amend policies related to trigger job.


a. create a subscriber trigger job with the following config:
b. Run once a day
c. Scoped on your users container, configured so that it generates a
trigger event for each user in the container.
d. Only generate trigger events for associated objects (this part is
important)
e. make sure that the user that the job runs as has enough rights to
read associations on the users.

2. Add/amend policies related to daily export

a. sub-etp, additional scoping (as required)
b. sub-etp (modify existing stylesheet) convert ONLY trigger to
instance document with all the required attributes for the export.
d. otp (modify existing stylesheet to generate CSV - you probably
already have this, plus generate a remove-association event for each
instance)

3. Add amend policies and filter to detect and queue changes

a. sub-etp, scoping - veto add/modifies for already associated users
b. sub-ctp for users with operation add/modify - add association
(direct) and veto
c. driver filter, set all attributes that you want to detect a change
on as subscriber sync. Also set User class as subscriber sync.

The way this works, every time a user is changed on an attribute you
care about, if the user is not yet associated with the driver, it will
be. (but not yet exported to file, as we veto straight away)

Then once a day, the trigger fires off and generates a list of
associated users (those that have changed since last export)

The triggers get converted into instances and then converted into
delimited strings. Association is removed during this process, so the
user won't be exported again until a relevant attribute is
changed/updated again.
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.

View solution in original post

Highlighted
Knowledge Partner
Knowledge Partner
That is a really clever way of doing it!
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner
joakim ganse <joakim_ganse@no-mx.forums.microfocus.com> wrote:
>

That is a really clever way of doing it!

It is a subtle twist on an approach my colleague came up with a few years
back. He deserves all the credit.
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
I can recommend another method, that include benefits of LDAP modification timestamp query, but a little bit more granular:
LDAP timestamp query can recognize last object modification, but not able to segregate "real" modification of attributes that you want to monitor, from any other modifications (that you can skip).

Solution is pretty simple:
1. When you have modification of any attributes from "monitoring list", you can set your own flag (object modified)
2. Once a day (based on your business requirements), you doing extract of "modified" users and remove the flag.
3. You are ready to "next" modification cycle.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner
al b wrote:

> Solution is pretty simple:
> 1. When you have modification of any attributes from "monitoring list",
> you can set your own flag (object modified)
> 2. Once a day (based on your business requirements), you doing extract
> of "modified" users and remove the flag.
> 3. You are ready to "next" modification cycle.


That is actually the same as (the other) Alex' solution, only he uses the
association as tha flag instead of a dedicated (new) attribute.

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner
You right!
I reviewed Alex explanation again and can confirm it. 🙂

Great minds think alike. 😉
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner
Using a dedicated attribute could be useful if you write it as modification time.
That way there is no need to delete it.
You only export today's modifications and at the same time have a history of last modification that driver should have got.

Not the most needed function but could be useful in some cases.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner
joakim ganse <joakim_ganse@no-mx.forums.microfocus.com> wrote:
>

Using a dedicated attribute could be useful if you write it as
modification time.
> That way there is no need to delete it.
> You only export today's modifications and at the same time have a

history of last modification that driver should have got.
>
> Not the most needed function but could be useful in some cases.


Yeah you could do that. It rarely is required though.

Attributes are cheap to create, but a per-export driver attribute can
become a bit unwieldy if you have lots of exports to juggle. Associations
are built in.

There are a thousand ways to solve this.



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 Wed, 12 Apr 2017 08:44:01 +0000, lelle wrote:

> So I was thinking if there is a possibility to create a job that runs
> once a day that pick up users that has got some specific attributes
> (like phone number etc) updated the last x hours and let the driver
> write those to csv file?


A while back, I wrote up a CoolSolutions article that you may find
helpful:

https://www.netiq.com/communities/cool-solutions/high-performance-data-
extract-driver-identity-manager/

--
David Gersic
Knowledge Partner http://forums.microfocus.com
If you find this post helpful, please click on the star below.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner
David Gersic wrote:

> A while back, I wrote up a CoolSolutions article that you may find
> helpful:
>


I have read that, have you compared performance to an associated-users
only trigger like I described? (Guessing your approach is still better
for huge environments, but not sure by how much)
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
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.