PerLDAP for PeopleSoft
Author: David McNeely

Directory Server Integration with PeopleSoft using PerLDAP for PeopleSoft

> Directory Server Integration Overview
> This document defines the technology and implementation requirements used to establish an internal Directory Server architecture for Netscape Communications use internally. The Directory Server deployment was based on various business and technology drivers, and sets out to define a Directory Server architecture in which information access across all of Netscape will evolve to support current and future enterprise needs in the most appropriate fashion.

> It is our goal to use the Directory Server as the centerpiece for Netscape business processes. Business policies and procedures are being changed to embrace the advantages of using Directory. While providing support and integration for SuiteSpot server products, we have expanded the use of Directory to include connections for:

> - PeopleSoft Database
> - PBX
> - Facility Access Systems (Badging)
> - Secured Remote Access
> - DNS
> - DHCP
> - NIS
> - NT Domain
> The remainer of this document will describe the details behind the integration of the most important, in terms of data value, of the data sources that feeds the directory, Netscape's PeopleSoft human resources management system.

> PeopleSoft Integration Overview
> As the authoritative information owner of personnel information for Netscape, we need to ensure that all people employed by and/or partnered with Netscape can be tracked in PeopleSoft. This was a significant change in the business practices and process that were used by the Human Resources department before we began designing the Directory. A team with representation from the appropriate departments evaluated the vision for PeopleSoft and Information Systems support applications. The goal was simple: provide the means to track an individual from the time of hire through separation and capture any changes in between.

> With Human Resources providing timely authoritative information into the Directory, IS could use this information to:

> > - Enhance the security of Netscape property (intellectual and physical).
> > - Enable IS to automate the process that generates user accounts on various servers, provides access to intranet services, and adds new hires to departmental mailing lists and groups.
> > - Have user information available in strategic support systems the first day of work.
> > - Provide information for new-hire equipment configurations.
> > - Notify support facilities for network drops, office setup, telephone service, badging requirements, and access levels to Netscape facilities.

> In addition to providing timely information on new hires, the same is true for the separation process. Once the process is started, and a termination date is entered into PeopleSoft, the Information Systems separation processes can be administered. These automated processes, triggered from the Directory, allow Information Systems to:

> > - Maintain the highest level of security for Netscape property (intellectual and physical).
> > - Deactivate access to facilities.
> > - Deactivate access to intranet services.
> > - Provide notification to other support groups throughout the enterprise where appropriate.
> > - Flag separated individuals in the Directory, for easy identification through the various applications and UIs.

> By tracking all individuals using one central system (PeopleSoft), Human Resources has access to information on contractors, contingents, vendors, and OEM partners that it never had before.

> To accomplish this process we:

> > - Identified all the mechanisms by which an individual could gain access to Netscape facilities, the Internet, extranets, and Netscape intranet services.
> > - Interviewed the people responsible for monitoring these individuals and documented the work and data flow processes.
> > - Identified the current methods and requirements for tracking people.
> > - Defined and proposed a scope of work to migrate disparate people-tracking systems to a single system that could deliver information for the Directory.
> > - Wrote the tools necessary to maintain the integrity of the information in the Directory and PeopleSoft.
> > - Defined and executed a pilot test, evaluated feedback, provided closure on the pilot, and deployed the architecture.

> As with any legacy systems that are migrated to new systems and work processes, we encountered problems with the integrity of some of the data being supplied to the Directory. Despite our best efforts to avoid this, we needed to evaluate that data and identify the bad data and sources. This led to the development of some cleanup tools mentioned in the IS Tools section of this document. The major problems existed in historical data transferred from non-Netscape employee tracking systems. With the tools in place, we were able to clean up the information in the Directory.

> Within PeopleSoft we have enforced standards via the UI. We have also done this with our own UIs, which provide updates or master information for the Directory. In PeopleSoft and the Directory, we have continued to monitor the integrity of data being supplied. This is accomplished through the toolset that we have developed for both environments.

#### Figure 6: PeopleSoft Integration with Directory Server

> Modifications to PeopleSoft
> Several new database tables were developed to house the additional non-employee data that was introduced into PeopleSoft. These database tables are accessed by new data entry panels that were made available to the various groups responsible for entering and maintaining the data within PeopleSoft.

> The new PeopleSoft database tables are as follows:

> > - PS_N_CONTRACTOR - high-level personal data for each independent contractor.
> > - PS_N_CONTRACT_JOBS - repeating job-related data for each job to which this independent contractor has been assigned.
> > - PS_N_CONTINGENT - high level personal data for each contingent (temporary) employee.
> > - PS_N_CONTNGNT_JOBS - repeating job-related data for each job to which this contingent has been assigned.
> > - PS_N_VENDOR- high level specific data for each vendor.
> > - PS_N_VENDOR_JOBS - repeating job related data for each job to which this vendor has been assigned.
> > - PS_N_INTCONTRACTOR - high-level personal data for each international contractor.
> > - PS_N_INTCONTR_JOBS - repeating job related data for each job to which this international contractor has been assigned.
> > - PS_N_OEM - high-level personal data for each Netscape partnering engineer.
> > - PS_N_OEM_JOBS - repeating job-related data for each job to which this partnering engineer has been assigned.

> The new PeopleSoft panels are as follows:

> > - PS_N_CONTRACTOR - provides Online access to the independent contractor personal data.
> > - PS_N_CONTRACT_JOBS - provides Online access to the independent contractor repeating job related data.
> > - PS_N_CONTINGENT - provides Online access to the contingent personal data.
> > - PS_N_CONTNGNT_JOBS - provides Online access to the Contingent repeating job related data.
> > - PS_N_VENDOR - provides Online access to the vendor personal data.
> > - PS_N_VENDOR_JOBS - provides Online access to the vendor repeating job-related data.
> > - PS_N_INTCONTRACTOR - provides Online access to the international contractor personal data.
> > - PS_N_INTCONTR_JOBS - provides Online access to the international contractor repeating job-related data.
> > - PS_N_OEM - provides Online access to the Netscape partnering engineer personal data.
> > - PS_N_OEM_JOBS - provides Online access to the Netscape partnering engineer repeating job-related data.

> These new panels are accessible through a new menu called "ICs, Contingents, Vendors."

PerLDAP for PeopleSoft

> The Netscape IS Architecture team has developed a series of tools to assist in the deployment, support, and maintenance of the Directory Server. In order to sync the PeopleSoft data into the Directory, the tools described below were created.

> Standard Options
> Most of the LDAP-enabled scripts use a standard set of options. Many of these options have default values, which are defined as follows:

-n | Don't do any updates (dry run).
-v | Give verbose output messages.
-W | Give verbose/extra warnings when applicable.
-h hostname | LDAP server name.
-p port # | LDAP port, default is 389 (or 636 for SSL).
-b base DN | LDAP base-DN.
-D bind DN | LDAP bind DN (connect to server as this "user").
-w bind pwd | Password to bind to the server.
-P certfile | Use SSL, with the certificates from the file.

There are a few shortcuts available for the "-D" and "-b" options:

-D |  |
| root | Bind as the LDAP "root" user.
| user | Bind as the current UNIX user.
-b |  |
| root | The default Base for your DIT.
| people | Where your "people" entries are.
| mail | Mail groups.
| groups | LDAP groups for ACLs, etc.

PeopleSoft Sync Tool
psoftsync.pl - This is the Perl program that will performs the synchronization that updates the Directory with exported PeopleSoft data. This program also provides exception reporting to the appropriate support staff teams.

PeopleSoft Export Cleanup
These tools are used to ensure the integrity of the data being exported from the PeopleSoft database and pushed into the Directory. Although there are data integrity checks within the PeopleSoft database, there are times when the information might be missing attributes needed to synchronize with the Directory. The following is a list of the possible exceptions that the cleanup tools will report based on their processing.

Exception Category | Perl Script | Exception Description
1a | cat1.pl | Category 1a exceptions occur when a worker is listed as expired in PeopleSoft, but their LDAP account is still active.
1b | cat1.pl | Category 1b exceptions occur when a worker has an expiration date in PeopleSoft set 2 weeks or less into the future, but still has an active LDAP account.
2 | cat2.pl | Category 2 exceptions occur when a worker has a terminated LDAP account but no corresponding PeopleSoft record.
3 | cat3.pl | Category 3 exceptions occur when a worker has an active LDAP account, but there is no corresponding PeopleSoft record for the worker.
5 | cat5.pl | Category 5 exceptions occur when people are terminated in LDAP and have PeopleSoft records but have no expiration date in PeopleSoft.
6 | cat6.pl | Category 6 exceptions occur when it seems likely that the worker had their LDAP UID changed but this change did not follow in PeopleSoft. This script makes some major assumptions to come up with this report, basing the decision on the phone number and complete name in the LDAP record.
7 | cat7.pl | This script traverses ou=People in LDAP and looks for any records with missing or inaccurate Manager, Organizational Unit, or Business Category fields in PeopleSoft and reports these.
8 | cat8.pl | This script identifies potentially duplicate LDAP accounts by finding duplicate full name fields. The exceptions reported by this script may not actually be a problem since it is possible for two or more employees to have the same full name.
9 | cat9.pl | Category 9 exceptions occur when PeopleSoft reports terminated managers for active employees. Since an active employee can only have an active manager, this is a serious problem in the integrity of the PeopleSoft data.

PeopleSoft Tools

Before you can sync the data from PeopleSoft, you must gain access to the data. Human Resources prepares the extract file using the following tools.

PeopleSoft Online Edits
PeopleCode edits were put into place to ensure that the UID (email ID) field is unique within PeopleSoft. We added this code to the EMAILID column on the PS_PERSONAL_DATA database table.
PeopleSoft Data Extraction
NLDAPEXT.SQR. This SQR program is executed four times daily and generates a text interface file containing data from PeopleSoft in a delimited variable format. The extract file includes the following fields:

Name
Email ID
Country Code
Currency Code
Employee ID
Department ID
City
State
Manager Name
Manager Email ID
Business Title
Department Name
Division Name
Personnel Status (Employee, Independent Contractor, Temporary Employee, Vendor, OEM, etc).