This section contains information to help you understand how the driver's policies are implemented, as well as information about how you can modify these objects. Topics include the following:
The Mapping policy is a Novell® eDirectoryTM object that defines the relationship between data fields defined in the PeopleSoft application and eDirectory attributes. The Mapping policy is located in the driver object container and is used by both the Publisher and Subscriber channels of the driver.
A preconfigured default Mapping policy is delivered with the driver product. The mappings defined in the Mapping policy are designed in coordination with the preconfigured PeopleSoft application Component Interface (CI) that is also delivered with the driver product.
The default CI is called DIRXML_SCHEMA01 and represents a set of employee data. The data fields in this CI are mapped to similar attributes of the eDirectory User object.
The following is a short sample of the delivered Mapping policy. The nds-name represents the name of the class or attribute in eDirectory and the app-name represents the class or field name of the PeopleSoft CI.
<?xml version="1.0" encoding="UTF-8"?> <attr-name-map>
<class-name>
<nds-name>User</nds-name>
<app-name>DIRXML_SCHEMA01</app-name>
</class-name> <attr-name classname="User">
<nds-name>Given Name</nds-name>
<app-name>FIRST_NAME</app-name>
</attr-name> ... </attr-name-map >
When you modify or create a Mapping policy, verify that the PeopleSoft field names appear identically (spelling and capitalization) in the Mapping policy and PeopleSoft CI definition. If you use the Identity Manager Mapping policy editor, correct mapping behavior is ensured. It is also important to note that if new attributes are included or removed from the Mapping policy, the new attribute set should be reflected in the respective Publisher and Subscriber filters. If mapped attributes are not included in the filters, they cannot be synchronized.
By default, the schema that the driver reads from PeopleSoft consists of the data fields defined on the DIRXML_SCHEMA01 Component Interface. If the data elements are modified or the CI is renamed, it is necessary to refresh the PeopleSoft application schema definition and re-map affected attributes.
The Publisher object contains a filter and a set of policies. Policies are necessary for converting data from the PeopleSoft CI into XDS format. The driver then submits the data to the DirXML engine. The engine applies the Publisher filter to the data and applies the business logic defined by the Publisher policies prior to submitting the data to eDirectory.
The Publisher filter is a logical component of the driver filter object. The filter specifies the object classes and accompanying attributes that are passed from the PeopleSoft CI to eDirectory. The filter is defined using eDirectory attribute naming, so it is applied after schema mapping takes place.
For example, if the User class is specified in the Publisher filter with only the Surname and Given Name attributes, the DirXML® engine allows changes to only these attributes to be passed to the Publisher policies from the PeopleSoft Driver. If a Telephone Number attribute is modified, the Publisher filter removes this data because the Telephone Number attribute is not in the filter. Other attribute values can be created by the Publisher policies according to the integration scenario.
You can configure the Publisher filter to include attributes required by your environment and allowable by eDirectory access controls. Configure it to include the following:
The Publisher filter specifies a set of data to be considered as authoritative from the PeopleSoft database. Based on business logic, there might be multiple authoritative sources of specific data (such as another driver or eDirectory itself). The configuration of the filters in your environment determines data ownership and authority.
By default, PeopleSoft applications are considered to be highly authoritative. Therefore, most of the field names in the default DIRXML_SCHEMA01 Component Interface are passed through the Publisher filter. As noted earlier, the names of attributes in the filter are eDirectory attribute names that have been mapped via the Mapping policies.
The Publisher Channel attributes listed below are included in the default filter:
Most of the attributes in the Driver Filter are configured for bidirectional synchronization. This is done for sample purposes to allow the driver to perform add, modify, and delete operations on both the Subscriber and Publisher channels. In most installations the driver policies and filter are configured to function in either a predominant Subscriber or Publisher mode.
PeopleSoft applications, as with many other applications, contain sensitive data that must be highly secured by organizations. There are two ways to ensure that secure data is not published from the PeopleSoft application:
The first method guarantees that the data does not leave the PeopleSoft application. The second method guarantees that it is not be synchronized to eDirectory via the driver.
The Publisher channel object, by default, contains or uses the following policies:
Policies contain templates that perform specific operations that can manipulate data, query either eDirectory or PeopleSoft for additional data required for processing, create new attributes based on values of other attributes, or even discard entire data events. The following section explains each policy and describes the operations of each policy or template. Because XML, DirXMLScript and XSLT allow for great flexibility, all policies can be modified to meet the individual needs of your organization. The Mapping policy has been previously described and is not addressed in this section. For more information, refer to Modifying the Driver Mapping Policy.
The Input Transformation policy is implemented as a default policy for the PeopleSoft Driver. Although the Input Transformation policy is not exclusively used by the Publisher channel, it performs a publishing role because it is used to transform the data format of any XDS document received from the PeopleSoft Driver shim, regardless of which channel generated the submission of the document. That is, the Subscriber channel can issue object queries to the driver shim. All data returned in the response is processed through the Input Transformation policy. An example of data transformation contained in this policy is the transformation of character attributes in PeopleSoft to Boolean attributes in eDirectory.
This template converts the Y or N data values in the PeopleSoft Manager attribute into True or False Boolean values to reflect the data format of the eDirectory isManager attribute.
The Matching policy is used by the DirXML engine to apply criteria to determine if a matching data object already exists in eDirectory. The Matching policy is applied to all Add documents received from the PeopleSoft Driver shim. If a match is found by this policy, the Add event is automatically converted to a Modify event by the DirXML engine. If a matched object in eDirectory is not currently associated with the PeopleSoft application, an association is created.
The Matching policy should provide criteria that are guaranteed to produce a 0 or 1 match. More than one policy can exist, and the DirXML engine applies them in the order that they are defined. Any policy producing 0 or more than one match is skipped and the next policy is applied. Processing finishes when one match is found or after the last policy has been processed.
The default Publisher Matching policy is a DirXMLScript policy that attempts to match eDirectory User objects containing the same value in the workforceID attribute (mapped from the DIRXML_SCHEMA01 attribute).
The Create policy is used to specify the criteria for creating a new object after the Matching policy has failed to find a match. This policy performs various tests and transformations based on the requirements for object creation in eDirectory and the business logic being applied.
The default PeopleSoft Create policy is an XML policy that asserts that the <add> document is for a User object and that it must contain a Surname and Given Name attribute. The Surname attribute is mandatory in eDirectory, and the business logic used for object naming requires the existence of the Given Name attribute. If this criteria is met, a secondary XSLT style sheet policy is called to create the eDirectory Name attribute and default password.
The Placement policy defines where an object is placed in the eDirectory tree when the object is created. This placement can be determined based on the presence (or absence) of attributes, particular values of attributes, etc. Placement can also be determined by the Create policy and passed to the Placement policy.
In a typical PeopleSoft HR environment, an employee is hired within PeopleSoft, a notification is sent to the IS department, and an IS administrator determines the location of the new User object in the eDirectory tree. Before defining location policies in the Placement policy, analyze your organization's current business process.
The default PeopleSoft Placement policy is a DirXMLScript policy that handles placement of User objects based on the employeeStatus attribute. It uses the following order of processing: If the employeeStatus value is A, the employee is placed in the Org Name\Users\Active organizational unit. If the employeeStatus is I, the employee is placed in the Org Name\Users\InActive organizational unit. If the employeeStatus attribute is not present, the employee is placed in the Org Name\Users\InActive organizational unit.
The Command Transformation policy is the final transformation policy to be processed prior to submission of a Publisher document to eDirectory. To demonstrate this functionality, the default PeopleSoft Driver configuration implements an unusual example of business logic that demonstrates the flexibility and power of Identity Manager.
The business logic scenario is a requirement to maintain the object CN attribute and full distinguished name DN of each User in the PeopleSoft application. The CN attribute is generated on new objects when they are created in eDirectory. The DN is not a true attribute at all, but a concatenation of the directory path and CN of a User. The DN changes based on the employeeStatus attribute of an object, so it is set on User Add events and Delete events that are transformed into Move events.
Because this data is known during the processing of the Command Transformation policy, the CN and DN data is placed into the event-id attribute of the document causing the add or move of the object. After Identity Manager applies the data to eDirectory, a status document is returned. The Output Transformation policy (documented in the Subscriber channel) monitors status documents that are returned and transforms successfully processed documents with the embedded CN and DN data into modification documents that are applied to the PeopleSoft application. This is known as write-back functionality.
As the final transformation policy, the Command Transformation policy provides an excellent location to define operations that must be applied without the risk of further event transformation, thus allowing complicated policy processing to be programmed in one location. As will be seen, the bulk of the business logic transformations in the Publisher channel are implemented in this policy.
The following templates exist in the default Command Transformation policy. In addition to the listed templates, all Identity Manager policies contain identity-transform templates that allow the copying of XML attributes and elements that are passed through unmodified. The default configuration only handles documents related to User objects.
This template does the following:
This template does the following:
This template does the following:
These templates are part of the CN and DN write-back implementation. They are responsible for embedding the User object CN and DN attributes into the event-id attribute of the document.
This template requests the value of the employeeStatus attribute from a specified User object in eDirectory.
This template requests the value of the isManager attribute from a specified User object in eDirectory.
This template requests the value of the CN attribute from a specified User object in eDirectory.
This template requests the value of the managerWorkforceID attribute from a specified User object in eDirectory.
This template requests the value of the Identity Manager WorkforceID attribute from a specified User object in eDirectory.
This template queries eDirectory to determine if the passed-in managerWorkforceID parameter references an active User object in eDirectory. The name of the manager-User object is set in the User's manager attribute if the manager is active.
This template receives a manager-User object ID parameter. A query is sent to eDirectory for a list of all active Users who have the specified manager-User object ID in the managerWorkforceID attribute. The manager attribute of all Users in the list is set with the name of the manager-User.
This template receives a manager-User object ID parameter. A query is sent to eDirectory for a list of all active Users who have the specified manager-User object ID in the managerWorkforceID attribute. The manager attribute of all Users in the list is removed.
This template receives a manager-User object ID parameter. A query is sent to eDirectory to find an active User who has the specified manager-User object ID in the workforceID attribute. The directReports attribute of the manager-User object is modified to include the DN of the User object specified in the source document.
This template receives a manager-User object ID parameter. A query is sent to eDirectory to find an active User who has the specified manager-User object ID in the workforceID attribute. The directReports attribute of the manager-User object is modified to remove the DN of the User object specified in the source document.
This template receives a User object ID parameter. A query is sent to eDirectory to find a list of active Users who have the specified User object ID in the managerWorkforceID attribute. The directReports attribute of the User object is modified to include the DN of all User objects in the list.
The Subscriber object contains a filter and a set of policies. These policies are necessary for converting data from eDirectory to the PeopleSoft Driver.
eDirectory sends filtered data modification events to PeopleSoft through the DirXML engine. The engine applies the business logic defined by the Subscriber policies prior to submitting the data to the PeopleSoft Driver, which converts the data from the Identity Manager XDS format into PeopleSoft Component Interface format. The PeopleSoft Driver then submits the data to the PeopleSoft application and updates the staging table.
The Subscriber filter is a logical component of the driver filter object. The filter specifies the object classes and accompanying attributes that are passed from eDirectory to the PeopleSoft Component Interface. The filter is defined using eDirectory attribute naming, so it is applied before schema mapping takes place.
For example, if the User class is specified in the Subscriber filter with only the mobile and pager attributes, the filter allows changes to only these attributes to be passed to the DirXML engine. If a Telephone Number attribute is modified, the Subscriber filter removes this data because the Telephone Number attribute is not in the filter. Other attribute values can be created by the Subscriber policies according to the integration scenario.
You can configure the Subscriber filter to include attributes required by your environment and allowable by eDirectory access controls. Configure it to include the following:
The Subscriber filter specifies a set of data to be considered as Authoritative from eDirectory or any other authoritative application that might have written the data to eDirectory. Based on business logic, there might be multiple authoritative sources of specific data (such as another driver or eDirectory itself). The configuration of the filters in your environment determines data ownership and authority.
Most of the attributes in the Driver Filter are configured for bidirectional synchronization. This is done for sample purposes to allow the driver to perform add, modify, and delete operations on both the Subscriber and Publisher channels. In most installations the driver policies and filter is configured to function in either a predominant Subscriber or Publisher mode.
The attributes listed below are included in the default Subscriber filter.
As mentioned previously, the Subscriber synchronization attributes in the Driver Filter are present for demonstration purposes. It is very important to note that Subscriber filter and policies should be set to match the requirements of the PeopleSoft CI being utilized. If you want the ability to Add objects on the Subscriber channel, make sure all required attributes in the CI are allowed to pass through the filter. Also make note of which fields in the CI are related display fields or translate values that cannot be synchronized, such as, Title, OU, and Full Name. By implementing and enforcing the CI application restrictions in your filter and policies, you encounter fewer synchronization errors and achieve higher throughput.
If there is sensitive data that should not be shared with the PeopleSoft application, it should be removed from the Subscriber filter.
A properly configured Subscriber filter promotes a secure environment and secures data sharing from eDirectory to PeopleSoft. Follow the steps in Modifying the Filter to configured the filter as desired. Make sure that attributes that are required for Subscriber policies processing (such as workforceID) are present in the filter even if they won't be synchronized to the PeopleSoft application.
The Subscriber object, by default, contains or uses the following policies:
Policies contain templates that perform specific operations that can manipulate data, query either eDirectory or PeopleSoft for additional data required for processing, create new attributes based on values of other attributes, or even discard entire data events. The following section explains each policy and provides a description of the operations each policy performs. Because XML, DirXMLScript, and XSLT allow for great flexibility, all policies can be modified to meet the individual needs of your organization. The Schema Mapping policy has been previously described and is not be addressed in this section. For information on the Schema Mapping policy, refer to Modifying the Driver Mapping Policy.
The Event Transformation Policy is used to remove or change received event types into different events. The following templates exist in the default Event Transformation Policy:
PeopleSoft does not allow the rename or modification of primary key values. This policy transforms a User <rename> event into a <modify> event that resets the CommonName and DistinguishedName fields in the CI.
PeopleSoft does not support object containment or hierarchy. This policy transforms User <move> events into <modify> events that reset the DistinguishedName field in the CI.
This template is commented out by default to allow delete events to be passed to the driver. This policy remains for reference for non-delete scenarios. Previous versions of the driver did not support <delete> events, so this template transforms them into <modify> events that remove only Subscriber Channel fields in the CI (CommonName, DistinguishedName, Internet Email Address, and Description).
The Matching policy is used by the DirXML engine to apply criteria to determine if a matching data object already exists in the PeopleSoft application. The Matching policy is applied to all documents received from eDirectory that contain User objects that are not currently associated with PeopleSoft objects. If a match is found by this policy, the Add event is converted into an object merge operation. This merge queries PeopleSoft for all attributes in the Publisher filter and applies them to eDirectory, and queries eDirectory for all attributes in the Subscriber filter and applies them to the PeopleSoft application. The process is finalized when an association value is written on the eDirectory User object.
The Matching policy should provide criteria that are guaranteed to produce a 0 or 1 match. More than one policy can exist, and the DirXML engine applies them in the order that they are defined. Any policy producing 0 or more than one match is skipped and the next policy is applied. Processing finishes when one match is found or after the last policy has been processed.
The default Subscriber Matching policy is an XML policy that attempts to find a PeopleSoft DIRXML_SCHEMA01 object that contains a AssocID attribute that matches the eDirectory User object's workforceID attribute. If that policy fails, the driver uses another policy to locate a PeopleSoft DIRXML_SCHEMA01 secondary object with a matching Given Name and Surname. The policy is defined in eDirectory class and attribute names because schema mapping has not yet been applied.
The Create policy specifies the criteria for creating a new object after the Matching policy has failed to find a match. This policy performs various tests and transformations based on the requirements for object creation in the DIRXML_SCHEMA01 CI in PeopleSoft and the business logic being applied.
The default Subscriber Create policy is a DirXMLScript policy that asserts that the <add> document is for a User object and that it must contain a value for Given Name, Surname, employeeStatus, departmentNumber, and jobCode. These fields are required because the default PSA has defined these fields as required in the DIRXML_SCHEMA01 CI. (Additional required fields, such as BirthDate and Manager, have defined default values in the CI and are thus not required here.) By making sure all required fields are present before submitting the <add> event to the driver, synchronization performance and integrity is enhanced.
This default policy does not assert particular values that are required for employeeStatus, departmentNumber, and jobCode in the PSA, but such assertions can be added to the Subscriber policies if desired.
The Output Transformation policy is implemented as both a DirXMLScript and XSLT policy by default for the PeopleSoft Driver. Although the Output Transformation policy is not exclusively used by the Subscriber channel, it performs a subscribing role because it is used to transform the data format of any XDS document received from eDirectory, regardless of which channel generated the submission of the document. An example of data transformation contained in this policy is the transformation of single-value eDirectory attributes into structured, multivalue scroll elements in PeopleSoft.
The following templates exist in the default Output Transformation policy. In addition to the listed templates, all Identity Manager policies contain identity-transform templates that allow the copying of XML attributes and elements that are passed through unmodified. Multiple instances of each listed template exist for each type of document or data element that can be received by the policy.
As documented in the Publisher Channel Command Transformation policy, this template monitors all status document responses from eDirectory. If a status document with a Success value is received and it contains an event-id attribute with an embedded CN and DN value, the template holds the status document and issues a Modify document with the CN and DN values to the PeopleSoft application. When the write-back command completes, the original status document is returned to the Publisher channel.
This template converts the Boolean True and False values of the eDirectory isManager attribute into character Y and N values of the PeopleSoft Manager field.