The Subscriber object contains a filter and a set of rules. Some rules are defined as XSLT style sheets and some are simple XML rule documents. These rules and style sheets 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 rules prior to submitting the data to the PeopleSoft Driver, which converts the data from the DirXML 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 specifies the object classes and accompanying attributes that will be 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 will allow changes to only these attributes to be passed to the DirXML engine. If a Telephone Number attribute is modified, the Subscriber filter will remove this data because the Telephone Number attribute is not in the filter. Other attribute values can be created by the Subscriber rules 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 that will be considered as Authoritative from eDirectory or any other authoritative application that may have written the data to eDirectory. Based on business logic, there may be multiple authoritative sources of specific data (such as another DirXML driver or eDirectory itself). The configuration of the filters in your environment will determine data ownership and authority.
By default, PeopleSoft applications are considered to be highly authoritative. Therefore most of the field names in the Subscriber filter will be data elements that are generally not assigned by a PeopleSoft application. As noted earlier, the names of attributes in the filter are eDirectory attribute names that have been mapped via the Mapping rule. As noted in the Publisher Filter documentation, the default PeopleSoft application, DIRXML_SCHEMA01, also defines a level-1 scroll element named PHONES. The PHONES scroll contains multiple elements, each of which contains two fields that identify telephone numbers and the type of the number. Because these elements cannot be directly mapped to eDirectory attributes they cannot be in the Mapping rule. However, with DirXML it is possible to create a style sheet that can convert the single-valued eDirectory attributes into unique instances of the PHONES scroll element. The eDirectory attributes can be listed in the filter to allow them to be passed to the DirXML engine. The Output Transformation rule of the Subscriber channel performs the appropriate data transformations.
The attributes listed below are included in the default Subscriber filter.
| Attributes | Attributes |
|---|---|
CN |
mobile |
Description |
pager |
homePhone |
workforceID |
Internet EMail Address |
|
The CN, Description, and Internet EMail Address attributes are unique to the Subscriber filter. The homePhone, mobile, and pager attributes are also in the Publisher filter. This implies that these attributes have dual authority or a peer-to-peer relationship between eDirectory and PeopleSoft. The workforceID attribute is in the filter for the purpose of rules processing and is not synchronized back to PeopleSoft.
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 the Modifying a DirXML Publication or Subscription Filter operation to configured the filter as desired. Make sure that attributes that are required for Subscriber rules processing (such as workforceID) are present in the filter even if they won't be synchronized to the PeopleSoft application.