Ouch, we only have 44K employees, but that is already enough! 116K?
PHEW...
We also have an "IDMS - Identity Management System" which is a Novel
eDir LDAP data as well. (funny thing huh?)
Our process is as this:
Each hour, query IDMS to see which records are "new / updated", and
shove the ifxGlobalID (the unique 'Person Key' if you like) into a
queuing form. This is done via a simple escalation against the IDMS-LDAP
form. We check for new/created('whenChanged' attribute) > $TIMESTAMP$ -
1.25 hours for escalation delay, etc. We do not worry about missing
records, because of the frequency of these darn records getting updated,
and although the update stamp changed, usually the data that "we" are
interested in is the same :-( - whoops I digress...
OK, now the queuing form is driven by a "ARDriver" .Net utility I wrote
which simply reaches out and presses the "Status->Trigger", calculates
data-feed statistics, sends out notifications on 'bad things', etc.
So the true "meat" of the process is all done via filters on the Queuing
form.
Pushing data in V4/5/6 to SHR:People was sure a heck of a lot easier, I
gotta tell you! (this is also how we do it in the V6 systems..) .
whoops, rambling again sorry...
So the bulk of the work involves:
> At any point during the checks, if something is wrong, the Queuing
entry is set to "Failed" and the error information is set into a text
field for human analysis <
Pull IDMS Data & Validation (Identity is mapped to a "Normal Active
Directory Account", etc) - We try to not accept garbage downstream.
If Phone Number is NULL or "garbage" - DEFAULT Phone Number (Business
Phone is a mandatory field!)
Setup Company (Fortunately, ours is a "Infineon Generic Contact"
company, so this is a bit easier!!)
Organization Check, and CREATE organization if necessary (**
Organization is not required, but if used, must exist
Company->Organization->Department)
Location Check, and obtain site linking if available, else Default to a
pre-defined "Unknown Location"
Check to see if the person ALREADY EXISTS as the logic is different on
Create / Update
Terminated Person Check (if IDMS = Terminated and person exists, setup
logic accordingly)
NEW_Person - Setup Default Fields
NEW_Person - Obtain predefined TEMPLATE to use (CTM:People Template)
NEW_Person - Generate a Person GUID (CTM:CFG PeopleTagNumGenerator)
NEW_Person - Push_PG (CTM:People Template PG)
NEW_Person - Push_PPPG (CTM:People Permission Groups)
NEW_Person - Push_People (CTM:People && CTM:People Permission Groups)
UPDATE_Person - Push_People (CTM:People)
Currently the only issue that I am aware of, is in the creation of the
USER entries, and that was just reported and I'm diagnosing it. I
believe that I need to separate the "NEW_Person - Push_People" actions
into two filters, but those who are interested and have digested
(without getting ill) the code can contact me privately.
How I created this was taking an AL+FILTER+SQL Logging of me manually
creating a person record. Then many tries at getting the code correct
:-(
I have a definitions file, but cannot send it to the list, so if you
would like it, please email privately...
Thanks-n-advance;
HDT Platform Incident / Problem Manager & Architect
Robert Molenda
IT OS PA
Tel: +1 408 503 2701
Fax: +1 408 503 2912
Mobile: +1 408 472 8097
[EMAIL PROTECTED]
Quality begins with your actions.
________________________________
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of strauss
Sent: Monday, May 07, 2007 3:25 PM
To: [email protected]
Subject: Re: ITSM 7 People import methodology
I am busy trying to figure out how to do this from EIE against a SQL
Server table that is being updated by Novell eDir LDAP data. The
"quality" of the EIE documentation isn't making this any easier. Right
now I am trying to push it directly into CTM:People, but I suspect that
I will either have to pre-populate required data for CTM:People fields
in a second SQL Server table and use that with EIE, or use EIE to
populate a staging table in ARS from which to populate CTM:People.
Still looking for the solution that will be the easiest to
implement/understand/troubleshoot. In our case, it will involve over
116,000 records for our active LDAP entries. All suggestions are
welcome.
Christopher Strauss, Ph.D.
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/helpdesk/
__20060125_______________________This posting was submitted with HTML in
it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
