Publishing events to the Identity Vault begins with updates in PeopleSoft. As these updates occur, transactions are placed in a worklist queue. These events are then made available to the Identity Vault through the Event Server.
As the Event Server receives transactions from PeopleSoft, it transforms the data into an XML document and passes the document to the driver shim. The driver shim then passes the document to the Metadirectory engine, which processes the transaction in the Identity Vault based on the policies as defined in the driver.
The transaction in the worklist is also updated with either a worked or error status. As the status is being updated in PeopleSoft, additional PeopleCode can be processed to trigger e-mail notifications to users in a defined PeopleSoft workflow role. The e-mail message communicates information regarding both successful transactions and transactions that create errors.
As updates or actions occur within PeopleSoft, workflow triggers are executed. These triggers place transactions in a PeopleSoft worklist queue. Each transaction is given key fields that uniquely identify the transaction to the driver.
One of these key fields is the Event Name field. Event Names are assigned based on a PeopleSoft action. The driver monitors the queue, checking for transactions that meet the criteria for processing.
The criteria for processing include the following:
The transactions have the status of 0.
Action, date, and time are less than or equal to current date and time.
After receiving the event, the Event Server converts the event into XML and sends the XML to the driver shim. This shim passes the XML document to the Metadirectory engine. The engine then applies the appropriate policies for that event type (based on the EventName field). The driver changes the XML to Identity Vault commands and sends the events to the Identity Vault.
The delivered solution supports the following workflow events. By default, an event in PeopleSoft equates to an XML functional event or document.
Table 1-3 PeopleSoft To XML Events
To trigger the appropriate event for the type of XML document that is to be generated, you must configure PeopleSoft appropriately. Without proper configuration and review of your business processes, a termination (action) could trigger a UPD event instead of a DIS event. The resulting XML document would be a Modify document instead of a Delete document.
The delivered driver configuration identifies two fields (Email ID and Description) on the Subscriber channel. These fields synchronize data from the Identity Vault to PeopleSoft. Additional fields can be subscribed to PeopleSoft from the Identity Vault, based on the needs of your organization. For Subscriber channel information, refer to Subscribing from the Identity Vault.
The ADD event is generally triggered when a new record is added. For the HR module, this is when an employee is hired. When a new Hire record is created within PeopleSoft, the following steps occur:
The SSCreate policy is configured as a sample Create policy. You use this policy to create the User object. You can define the eDirectory Common Name, Initial Login Password, and other Create policies within this policy.
Depending on your business requirements, you can apply additional configurations to the PSA to expose additional data elements. You can also configure the policies to meet business objectives.
During the ADD event processing, an association is made between the employee’s PeopleSoft record and the eDirectory object. For the HR module, the EmplID field is used as the key field and saved in the association attribute on the User object.
When an object is created, various attributes or data elements defined in PeopleSoft could be passed through the interface and used to place the object. The Placement policy on the Driver object would use these values.
UPD events are generally triggered when data on a specified PeopleSoft field is modified. A workflow is triggered through the use of PeopleCode, and a UPD event is written to the worklist. Through the same process as the ADD transaction, the driver retrieves the transaction and applies the appropriate policies. In the delivered solution, the eventXform policy is used to apply these events. The policies might vary, based on the individual needs of an organization.
To determine the PeopleSoft fields that should be synchronized and used as part of the policies within the Identity Vault, analyze your business processes.
For example, a user’s location, department, or company can determine the location of that individual’s User object within eDirectory. If one of these fields is updated from PeopleSoft, the eDirectory User object must be moved to the appropriate container, based on the new information.
PeopleSoft fields can also be stored in the Identity Vault as attributes. Telephone numbers, department, preferred names, business titles, and locations are some common fields that can be shared between the two systems. As you analyze your business processes and needs, you determine the necessary data mappings between the systems.
The DIS event is generally triggered when records are disabled. Many different actions within PeopleSoft represent a disabled process. In the HR module, this event occurs when an employee terminates. When a termination record is created within PeopleSoft, a workflow is triggered and a DIS entry is written to the worklist.
IMPORTANT:If a DIS transaction is triggered, a Delete XML document is the result.
An organization can choose to delete, disable, or disable and move the Identity Vault account. As with the modify/update process, the eventXform policy is delivered to show how a Delete XML document is transformed into a Modify document.
NOTE:By default, when the Publisher channel processes any event, the eDirectory ID and eDirectory DN (distinguished name) are updated in PeopleSoft. You can disable this process by updating the driver’s XML properties.