The Publisher channel object, by default, contains or uses the following rules and style sheets:
XSLT style sheets contain templates that perform specific operations that may 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 rule and style sheet and describes the operations each rule or template. Because XML and XSLT allow for great flexibility, all rules and style sheets can be modified to meet the individual needs of your organization. The Mapping rule has been previously described and will not be addressed in this section. For more information, refer to Modifying the Driver Mapping Rule .
The Input Transformation rule is implemented as a style sheet by default for the PeopleSoft Driver. Although the Input Transformation rule 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 may issue object queries to the driver shim. All data returned in the response is processed through the Input Transformation rule.) An example of data transformation contained in this rule is the transformation of structured, multi-valued attributes in PeopleSoft being converted to string attributes in eDirectory.
The following templates exist in the default Input Transformation rule. In addition to the listed templates, all DirXML style sheets contain identity-transform templates that allow copying of XML attributes and elements that will be passed through unmodified. Multiple instances of each listed template exist for each type of document that may be received by the rule (query response, add, and modify):
These templates convert 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.
These templates convert the structured format values of the PeopleSoft PHONES scroll data elements into the appropriate attributes and string formats in eDirectory. Based on the Phone Type component of PHONES, the Phone Number component will be written to an appropriate string formatted eDirectory attribute.
The following mappings are provided:
| Phone Type | eDirectory Attribute |
|---|---|
BUSN |
Telephone Number |
HOME |
homePhone |
CELL |
mobile |
PGR |
pager |
The Matching rule is used by the DirXML engine to apply criteria to determine if a matching data object already exists in eDirectory. The Matching rule is applied to all Add documents received from the PeopleSoft Driver shim. If a match is found by this rule, the Add event is automatically converted to a Modify by the DirXML engine. If a matched object in eDirectory is not currently associated with the PeopleSoft application, an association is created.
The Matching rule should provide criteria that are guaranteed to produce a 0 or 1 match. More than one rule can exist, and the DirXML engine will apply them in the order that they are defined. Any rule producing 0 or more than one match is skipped and the next rule is applied. Processing finishes when one match is found or after the last rule has been processed.
The default Subscriber Matching rule is an XML rule that attempts to match on eDirectory User objects containing the same value in the workforceID attribute. (Mapped from the DIRXML_SCHEMA01 DIRXML_ASSOC_ID attribute).
Sample Subscriber Matching Rule: The following is a sample of the Subscriber Matching rule.
<?xml version="1.0" encoding="UTF-8"?>
<matching-rules>
<matching-rule description="Match on WorkForceID">
<match-class class-name="User"/>
<match-attr attr-name="workforceID"/>
</matching-rule>
</matching-rules>
The Create rule is used to specify the criteria for creating a new object after the Matching rule has failed to find a match. This rule performs various tests and transformations based on the requirements for object creation in eDirectory and the business logic being applied.
The default PeopleSoft Create rule is an XML rule 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.
The following is the default Create rule.
<?xml version="1.0" encoding="UTF-8"?>
<create-rules>
<create-rule class-name="User">
<required-attr attr-name="Surname"/>
<required-attr attr-name="Given Name"/>
</create-rule>
</create-rules>
There is a Create style sheet that is chained from the Create rule. This style sheet contains various policies including CN generation.
The Placement rule defines where an object will be placed in the eDirectory tree when the object is created. This placement may be determined based on the presence (or absence) of attributes, particular values of attributes, etc. Placement may also be determined by the Create rule and passed to the Placement rule.
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 rule, analyze your organization's current business process.
The default PeopleSoft Placement rule is a set of XML rules that do placement of User objects based on the employeeStatus attribute. In 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 following is the default Placement rule:
<?xml version="1.0" encoding="UTF-8"?><placement-rules dest-dn-format="slash" src-dn-format="slash">
<placement-rule>
<match-class class-name="User"/>
<match-attr attr-name="employeeStatus">
<value><![CDATA[A]]></value>
</match-attr>
<placement><![CDATA[novell\Users\Active\]]>
<copy-attr attr-name="CN"/>
</placement>
</placement-rule>
<placement-rule>
<match-class class-name="User"/>
<match-attr attr-name="employeeStatus">
<value><![CDATA[I]]></value>
</match-attr>
<placement><![CDATA[novell\Users\InActive\]]>
<copy-attr attr-name="CN"/>
</placement>
</placement-rule>
<placement-rule>
<placement><![CDATA[novell\Users\InActive\]]>
<copy-attr attr-name="CN"/>
</placement>
</placement-rule>
</placement-rules>
The Command Transformation rule is the final transformation rule to be processed prior to submission of a Publisher document to eDirectory. This rule is new with DirXML 1.1 and provides a great deal of new functionality. To demonstrate this functionality, the default PeopleSoft Driver configuration implements an unusual implementation of business logic that demonstrates the flexibility and power of DirXML.
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 rule, the CN and DN data is placed into the event-id attribute of the document causing the add or move of the object. After DirXML applies the data to eDirectory, a status document is returned. The Output Transformation rule (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 rule, the Command Transformation rule provides an excellent location to define operations that must be applied without the risk of further event transformation, thus allowing complicated rules 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 rule.
The following templates exist in the default Command Transformation rule. In addition to the listed templates, all DirXML style sheets contain identity-transform templates that allow the copying of XML attributes and elements that will be 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 DirXML association attribute from a specified User object in eDirectory. The association value represents the unique ID of the object in the PeopleSoft application.
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 that 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 that have the specified manager-User object ID in the managerWorkforceI' 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 that 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 that 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 that 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.