wiki:ALL__record_lifecyle
Last modified 6 years ago Last modified on 11/20/14 10:54:22

Enterprise Directory Record Lifecycle (LDAP_REG.STATE)

Original author: Beth Mercer - 20090108

This document introduces the concept of record lifecycle as implemented in the Enterprise Directory (EDIR) through its batch processes. Records receive an initial state when first created after which state may be changed. Possible states are recorded in LDAP_REG_STATES and vary by record type (see the query report_state_counts) as well as by stage of processing. As of 20080107, possible states are these:

STATE DESCRIPTION
A PEOPLE ENTITIES - ACTIVE RECORDS
B PEOPLE ENTITIES - BAD RECORDS
b PEOPLE ENTITIES - FLAGGED FOR BAD PROCESSING
D DEPARTMENT ENTITIES - ACTIVE RECORDS
E PEOPLE ENTITIES - EXPECTED RECORDS
G GROUP ENTITIES - ACTIVE RECORDS
I PEOPLE ENTITIES - INACTIVE RECORDS
i PEOPLE ENTITIES - FLAGGED FOR INACTIVE PROCESSING
N PEOPLE ENTITIES - FLAGGED FOR DIRECTORY RECORD CREATION
O ROUTING ENTITIES - ACTIVE RECORDS
P ALL ENTITIES - PURGED RECORDS
p PEOPLE ENTITIES - FLAGGED FOR PURGE PROCESSING
R RESOURCE ENTITIES - ACTIVE RECORDS
S PEOPLE ENTITIES - SPONSORED RECORDS
X FLAGGED FOR EXCLUSION FROM BATCH PROCESSING

NOTE: With one exception, transitional states are lowercase. The state N, though uppercase, is a transitional state establish early in the evolution of lifecyle processing. If someone had the time to change the dependent code, changing N to n would be desirable.

People records have the most complex lifecycle, as reflected by number of possible states, because peoples' relationships with the University are the most changeable. Automated batch processes have evolved to address that complexity and rely on the various possible states for people records. More about them later is in this document.

DEPARTMENT, GROUP, RESOURCE and ROUTING RECORDS

When department, group, resource and routing records are first created, they are given a state reflecting the type of record. The only other supported (by batch processing) state is P for purged.

STATE DESCRIPTION
D DEPARTMENT ENTITIES - ACTIVE RECORDS
G GROUP ENTITIES - ACTIVE RECORDS
R RESOURCE ENTITIES - ACTIVE RECORDS
O ROUTING ENTITIES - ACTIVE RECORDS
P ALL ENTITIES - PURGED RECORDS

So, a group record is given a state of G when created. That state is changed to P when purged. The initial state of G is reestablished if a previously purged record is restored. The same holds true for department, resource and routing records.

D | G | R | O when department, group, resource and routing records created
P when purged
D | G | R | O if purged record subsequently restored

Department records are created via two processes: a monthly batch update process driven by changes to OIR's BOR table (see Monthly Process: EDIR Unit Changes Following BOR Structure Table Changes) and the EDIR Seed Department form. Department records are deleted and restored by the same processes with certain restrictions. The EDIR Seed Department form will only delete and restore "faux" records - those created via the form. The Seed Department form will not delete those department records originating from the BOR table.

Group, resource and routing records are all created, deleted and restored via the corresponding AUTHSERV or EDIR forms:

  • Seed Group
  • Seed Resource
  • Seed Routing

PEOPLE RECORDS

For people records, the initial state reflects a subcategory of people records

  • A : Records matched to Banner with active employee or student affiliation
  • E : Records matched to Banner for which active employee or student affiliation is expected but does not yet exist
  • S : Records with no match in Banner (generally thought of as "guest accounts")
STATE DESCRIPTION
A PEOPLE ENTITIES - ACTIVE RECORDS
E PEOPLE ENTITIES - EXPECTED RECORDS
S PEOPLE ENTITIES - SPONSORED RECORDS

Aside from signifying a subcatetory of people records, state on people records is also used for batch process control.

A State Records

A state records are subject to record aging and will be flagged for inactivation by the EDIR Banner Extract process when the record no longer meets the active affiliation test. Inactivated records are present but hidden in the EDIR UI. They are visible through iPlanet queries on IDMP-3. The EDIR Banner extract process is the primary source of people records with an initial state of A. However, the AUTHSERV Sponsor Account form can also restore previously purged records. Those restored records have an initial state of A and will be inactivated due to lack of active affiliation unless subsequently sponsored.

===E State Records === E state records are exempt from inactivation processing. Their state is changed from E to A by the EDIR Banner Extract process once the record meets the normal extract criteria. A now obsoleted AUTHSERV form was the only source of people records with an initial state of E. The current AUTHSERV Sponsor Account form is now used to sponsor regular accounts as well as guest accounts making the E state obsolete.

NOTE: As of 1/8/2009, there were still 10 EDIR records with a state of E.

S State Records

S state records are also exempt from inactivation processing. State changes from S to A only when sponsorship is revoked. The AUTHSERV Sponsor Account form is the only source of people records with an initial state of S.

Additional States

There are additional LDAP_REG values that reflect alternate and transitional states for people records.

STATE DESCRIPTION
I PEOPLE ENTITIES - INACTIVE RECORDS
B PEOPLE ENTITIES - BAD RECORDS
P ALL ENTITIES - PURGED RECORDS
N PEOPLE ENTITIES - FLAGGED FOR DIRECTORY RECORD CREATION
i PEOPLE ENTITIES - FLAGGED FOR INACTIVE PROCESSING
b PEOPLE ENTITIES - FLAGGED FOR BAD PROCESSING
p PEOPLE ENTITIES - FLAGGED FOR PURGE PROCESSING

One step in the EDIR Banner Extract process flags people records with the transitional states of N (new), i (inactive) or b (bad). A final step generates directory LDIF based on the transitional states and then changes the state to A (active), I (inactive) or B (bad) accordingly.

NOTE: The fact that the N state is upper case rather than lowercase is an unfortunate by-product of how lifecycle processing developed for EDIR. See 'NOTE:'.

The process of purging the directory of inactive and bad people records (see UPDT_process_purge) has not been run since 2007. When the purge is performed, LDAP_REG is changed to the transitional state of p (purge), directory LDIF is generated and then state is changed to P (purged).

X State Records

There is one special people record state not previously mentioned - X (exclude).

STATE DESCRIPTION
X FLAGGED FOR EXCLUSION FROM BATCH PROCESSING

The state X, which is a kludge that addressed a security/privacy issue that cropped up for one user's record, must be established and removed manually. Records with a state of X are excluded from processing by the EDIR Banner Extract. If state is X, the EDIR Banner Extract process neither updates the registry with Banner data nor changes the record state.

NOTE: As of 1/8/2009, there was only 1 EDIR records with a state of X.

WARNING: Place no reliance on state X without first investigating how it is currently used.

SAMPLE PEOPLE RECORD STATE FLOWS

Regular People Record

Example 1: Inactivating a record

* N	when EDIR Banner Extract process identifies a qualifying entity which no directory record exists
	  * NOTE: this could be a previously purged record
* A	once the EDIR Banner Extract process (or AUTHSERV Sponsor Account form) generates the directory record
* i	when the EDIR Banner Extract process flags the record for inactivation
* I	after the EDIR Banner Extract process inactivates the record
* p	when the record is flagged for purging
* P	after the record has been purged
* A	when the AUTHSERV Sponsor Account form restores the purged record
* S	when record is sponsored by AUTHSERV Sponsor Account form
* A	when sponsorship is revoked
* i	when the EDIR Banner Extract process flags the record for inactivation
* I	after the EDIR Banner Extract process inactivates the record
* p	when the record is flagged for purging
* P	after the record has been purged

Example 2: Flagging a bad record

* Same as above for states N, A, through S, A
...
* b	when EDIR Banner Extract process flags record as "bad" (as result of Banner multiple PIDM cleanup)
* B	after the EDIR Banner Extract process inactivates the "bad" record
* p	when the record is flagged for purging
* P	after the record has been purged

Guest Records

* S	when record is sponsored by AUTHSERV Sponsor Account form
* A	when sponsorship is revoked
* i	when the EDIR Banner Extract process flags the record for inactivation
* 	after the EDIR Banner Extract process inactivates the record
* p	when the record is flagged for purging
* P	after the record has been purged
* A	when the AUTHSERV Sponsor Account form restores the purged record
* S	when record is sponsored by AUTHSERV Sponsor Account form
* A	when sponsorship is revoked
* i	when the EDIR Banner Extract process flags the record for inactivation
* I	after the EDIR Banner Extract process inactivates the record
* p	when the record is flagged for purging
* P	after the record has been purged