At a high level, policies enable you to customize the way DirXML sends and receives updates.
To understand policies, it helps to understand some level of detail regarding what a driver shim is written to do.
When a driver shim is written, an attempt is made to include the ability to synchronize anything a company deploying the driver might use. The developer writes the driver shim to detect any relevant changes in the connected system, then pass this change to Novell® eDirectoryTM.
This change is contained in an XML document, formatted according to the DirXML specification. The following snippet contains one of these XML documents:
<nds dtdversion="2.0" ndsversion="8.7.3">
<source>
<product version="2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="User" event-id="0" src-dn="\ACME\Sales\Smith"
src-entry-id="33071">
<add-attr attr-name="Surname">
<value timestamp="1040071990#3" type="string">Smith</value>
</add-attr>
<add-attr attr-name="Telephone Number">
<value timestamp="1040072034#1" type="teleNumber">111-1111</value>
</add-attr>
</add>
</input>
</nds>
Now, depending on what you are trying to accomplish, you might not care that a user named Smith with a telephone number of 111-1111 was added to a system. However, someone else might.
Point is, drivers are designed to report any relevant changes, then enable you to filter or modify the change however you see fit. The logic of what changes are important and how to process these changes is handled in the engine, not in the driver shim.
If one company wasn't very concerned with users, they could implement a filter to block all operations regarding users in either eDirectory or the connected system. If users were all they cared about, they could implement a filter to do the reverse.
Defining filters to prevent the synchronization of objects that aren't interesting to you is the first step in driver customization.
The next step defines what DirXML does with the objects that aren't blocked by your filter. As an example, let's refer to the add operation in the XML document above. A user named Smith with a telephone number of 111-1111 was added to your connected system. Assuming you don't filter this operation, DirXML needs to decide what to do with this user.
To make this decision, DirXML applies a set of policies, in a specific order (for now we are going to ignore transformation policies, which occur before the filter is applied on the publisher channel, and as the last step on the subscriber).
The first policy, matching, answers the question, "Is this object already in the data store?" To answer this, you need to define the characteristics that are unique to an object. A common attribute to check might be an e-mail address, since these are generally unique to ensure we all receive our fair share of spam. You could define a policy that says "If two objects have the same e-mail address, they are the same object."
If a match is found, DirXML notes this find in an attribute called an association. An association is a unique value that enables DirXML to associate objects in connected systems.
In circumstances where a match is not found, the second policy, creation, is called on. The create policy tells DirXML under what conditions you would like objects created. You can make the existence of certain attributes mandatory in the creation rule. If these attributes do not exist, DirXML blocks the creation of the object until the required information is provided.
After the object is created, the third rule, placement, tells DirXML where to put it. You could specify that objects should be created in a hierarchical structure identical to the system they came from, or you could place them somewhere completely different based on an attribute value.
If you would like to place users in a hierarchy according to a location attribute on the object, and name them according to their Full Name, you could make these attributes required in the create policy. This way you can ensure that the attribute exists so your placement strategy works correctly.
There are many other things you can do with policies. Using Policy Builder, you can easily generate unique values, add and remove attributes, generate events, send e-mail, and a laundry list of other operations. Even more advanced transformations are available by using XSLT to transform the XML document directly (remember that changes are sent to and from eDirectory in XML documents).
The basic thing to keep in mind is policies enable you to control how DirXML handles updates.
Continue to Introduction to Policies to learn more about the different types of policies, then move on to Defining Policies Using Policy Builder to get your hands dirty in Policy Builder.
Transformation policies act as a translation mechanism between DirXML and the connected system. They transform schema between systems, and make preliminary changes to operations coming in, and final changes going out.
In a basic sense, transformation policies are used to make the other rules discussed previously (matching, create, placement), work correctly. The default configuration for each driver contains all of the necessary transformation policies, so you don't need to worry about these at first (the only exception might be the schema mapping policy, which you can easily modify using a GUI in iManager).
After you have a grasp of the basic policy types, understanding transformation policies might enable you to perform some customization that isn't possible with the basic policies.
If you have not used DirXML 1.x, you do not need to review this section.
In DirXML 1.x, the term rule was used to describe a set of rules, the individual rules in this set, and the conditions and actions within the individual rules, depending on the context. This overlap causes confusion in circumstances when the context is not clear.
In DirXML 2, the term policy is now used to replace the previous usage of the term rule, when describing the high level transformation that is occurring. You now define a set of policies, which consists of one or more policies, where each policy contains one or more rules. The term rule is now used to describe only an individual set of conditions and actions.
The following table shows this terminology change: