Example Tree for Scope Filtering
Scope filtering means adding rules to each driver to limit the scope of the driver's actions to specific containers. The following are two situations in which you would need to use scope filtering:
A DirXML driver by default will synchronize objects in all the containers that are replicated on the server where it is running. To narrow that scope, you must create scope filtering rules.
To synchronize all users without having them replicated on one single server, you need to determine which set of servers holds all the users, and then create an instance of the DirXML driver on each of those servers. To prevent two instances of the driver from trying to synchronize the same users, you will need to use scope filtering to define which users each instance of the driver should synchronize.
NOTE: In this case, you should use scope filtering even if your server's replicas don't currently overlap. In the future, replicas could be added to your servers and an overlap could be created unintentionally. If you have scope filtering in place, your DirXML drivers will not try to synchronize the same users, even if replicas are added to your servers in the future.
Keep in mind that to move an object, DirXML must have both the source container and the destination container replicated on the same server. Splitting up your users on different servers and using scope filtering could limit the ability of DirXML to move users.
Here's an example of how scope filtering is used.
Figure 7 shows a tree with three containers that contain users: Marketing, Finance, and Development. Each is a separate partition.
Figure 7
Example Tree for Scope Filtering
In this example, the eDirectory administrator has two eDirectory servers, Server A and Server B, shown in Figure 8. Neither server contains a copy of all the users. Each server contains two of the three partitions, so the scope of what the servers hold is overlapping.
The administrator wants all the users in the tree to be synchronized by the GroupWise® driver, but does not want to aggregate replicas of the users onto a single server. He chooses instead to use two instances of the GroupWise driver, one on each server. He installs DirXML and sets up the GroupWise driver on each eDirectory server.
Server A holds replicas of the Marketing and Finance containers. Also on the server is a replica of the DirXML Management container, which holds the DirXML Driver Set for Server A and the GroupWise Driver object for Server A.
Server B holds replicas of the Development and Finance containers, and the DirXML Management container holding the DirXML Driver Set for Server B and the GroupWise Driver object for Server B.
Because Server A and Server B both hold a replica of the Finance container, both servers hold the user JBassad, who is in the Finance container. Without scope filtering, both GroupWise Driver A and GroupWise Driver B would synchronize JBassad.
Figure 8
Two Servers with Overlapping Replicas, without Scope Filtering
Figure 9 shows that scope filtering prevents the two instances of the driver from managing the same user, because it defines which drivers synchronize each container.
Figure 9
Scope Filtering Defines Which Drivers Synchronize Each Container
Here is a sample of how you would create a rule for scope filtering. The rule you create should be placed in the Subscriber Event Transformation style sheet. (This sample is for illustration purposes only; it is not meant to be copied.)
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:jstring="http://www.novell.com/nxsl/java/java.lang.String"
exclude-result-prefixes="jstring">
<!--
To select different containers for scoping, add/delete/modify the <value>
elements in the body of the variable "in-scope-containers-rtf"
Note that if the container is not in the root of the tree, then the DN
(minus the tree name) of the container must be specified, e.g.,
Corporate\Executives
Note: THESE MUST BE ENTERED IN THE TABLE AS ALL UPPERCASE
-->
<xsl:variable name="in-scope-containers-rtf">
<value>CORPORATE\USERS\ACTIVE</value>
<value>CORPORATE\USERS\INACTIVE</value>
</xsl:variable>
<xsl:variable name="in-scope-containers" select="document('')/xsl:transform/xsl:variable[@name='in-scope-containers-rtf']/value"/>
<!--
"identity" transformation - copies unchanged everything not explicitly
matched by other templates
-->
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- throw away events that are out of scope -->
<xsl:template match="input/*[@src-dn]">
<xsl:variable name="in-scope">
<xsl:call-template name="in-scope"/>
</xsl:variable>
<xsl:choose>
<xsl:when test="$in-scope = '1'">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:when>
<xsl:otherwise>
<xsl:message>
<status level="warning">Operation vetoed by Event Transformation
Rule - out of scope</status>
</xsl:message>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<!--
check to see if an object is in the scope defined by the variable
"in-scope-containers"
-->
<xsl:template name="in-scope">
<xsl:param name="scope-value"/>
<!-- validate that the container is in scope -->
<xsl:variable name="src-dn" select="substring-after(substring-after(@src-dn,'\'),'\')"/>
<xsl:variable name="src-dn-i" select="jstring:lastIndexOf($src-dn,'\')"/>
<xsl:if test="$src-dn-i != -1">
<xsl:variable name="src-dn-container" select="jstring:substring($src-dn, 0, $src-dn-i)"/>
<!--
the following test takes advantage of the XPath existential
quantification semantics: basically, if one node in the node-set has
a string value that matches the string, then the statement is true
-->
<xsl:if test="jstring:toUpperCase($src-dn-container) = $in-scope-containers">
<xsl:value-of select="'1'"/>
</xsl:if>
</xsl:if>
</xsl:template>
</xsl:transform>