3.4 Policy Types
There are several different types of policies you can define on both the Subscriber and Publisher channels. Each policy is applied at a different step in the data transformation, and some policies are only applied when a certain action occurs. For example, a Creation policy is applied only when a new object is created.
The different policy types and their order of execution on the channel are:
Figure 3-2 Order of Execution of the Policies
3.4.1 Event Transformation Policy
Event Transformation policies alter the Metadirectory engine's view of the events that happen in the Identity Vault or the connected application. The most common tasks performed in an Event Transformation policy are changing an event and custom filtering, such as scope filtering and event-type filtering.
Changing an event includes performing an action to change an object, either in the source or destination directories, but not adding anything to the existing operation event.
For example, a policy could remove the association in the publisher event transform when a delete is detected and then remove the delete event, or detect events in the subscriber event transform and write back modifications to the Identity Vault. This type of policy should not be used to add destination attributes to the operation, as this policy is not used in merge operations.
Scope filtering removes unwanted events based on event location or an attribute value. For example, a policy could remove the event if the object is not in a specific container, or if the department attribute is not equal to a specific value, or if the user is not a member of a specific group.
Event-type filtering removes unwanted events based on event type. For example, a policy could remove all delete events.
Examples:
Scope Filtering: Example 1
This example DirXML Script policy allows events only for users who are contained within the Users subtree, are not disabled, and do not contain the word Consultant or Manager in the Title attribute. It also generates a status document indicating when an operation has been blocked. To view the policy in XML, see Event_Transformation_Scope1.xml.
<policy>
<rule>
<description>Scope Filtering</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
<or>
<if-src-dn op="not-in-subtree">Users</if-src-dn>
<if-attr name="Login Disabled" op="equal">True</if-attr>
<if-attr mode="regex" name="Title" op="equal">.*Consultant.*
</if-attr>
<if-attr mode="regex" name="Title" op="equal">.*Manager.*
</if-attr>
</or>
</conditions>
<actions>
<do-status level="error">
<arg-string>
<token-text>User doesn’t meet required conditions</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
Scope Filtering: Example 2
This DirXML Script policy vetoes all operations on User objects except for modifies of already associated objects. To view the policy in XML, see Event_Transformation_Scope2.xml..
<policy>
<rule>
<description>Veto all operation on User except modifies of already associated objects</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
<or>
<if-operation op="not-equal">modify</if-operation>
<if-association op="not-associated"/>
</or>
</conditions>
<actions>
<do-veto/>
</actions>
</rule>
</policy>
Type Filtering: Example 1
The first rule of this example DirXML Script policy allows only objects in the Employee and Contractor containers to be synchronized. The second rule blocks all Rename and Move operations. To view the policy in XML, see Event_Transformation_Type1.xml.
<policy>
<rule>
<description>Only synchronize the Employee and Contractor subtrees
</description>
<conditions>
<and>
<if-src-dn op="not-in-container">Employees
</if-src-dn>
<if-src-dn op="not-in-container">Contractors
</if-src-dn></and></conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text xml:space="preserve">Change ignored: Out of scope.
</token-text>
</arg-string>
</do-status><do-veto/>
</actions>
</rule>
<rule>
<description>Don't synchronize moves or renames
</description>
<conditions>
<or>
<if-operation op="equal">move
</if-operation>
<if-operation op="equal">rename
</if-operation>
</or>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text xml:space="preserve">Change ignored: We don't like you to do that.
</token-text></arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
Type Filtering: Example 2
This DirXML Script policy blocks all Add events. To view the policy in XML, see Event_Transformation_Type2.xml.
<policy>
<rule>
<description>Type Filtering</description>
<conditions>
<and>
<if-operation op="equal">add</if-operation>
</and>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text>Change ignored: Adds are not allowed.</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
3.4.2 Matching Policies
Matching policies, such as Subscriber Matching and Publisher Matching, look for an object in the destination data store that corresponds to an unassociated object in the source datastore. It is important to note that Matching policies are not always needed or desired.
For example, a Matching policy might not be desired when performing an initial migration if there are no preexisting or corresponding objects.
A Matching policy must be carefully crafted to ensure that the Matching policy doesn’t find false matches.
Match by Internet E-Mail Address: Example
This example DirXML Script policy matches users based on the Internet E-mail Address. To view the policy in XML, see Matching1.xml.
<policy>
<rule>
<description>Match Users based on email address</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
</and>
</conditions>
<actions>
<do-find-matching-object>
<arg-dn>
<token-text>ou=people,o=novell</token-text>
</arg-dn>
<arg-match-attr name="Internet EMail Address"/>
</do-find-matching-object>
</actions>
</rule>
</policy>
Match by Name: Example
This example DirXML Script policy matches a Group object based on its Common Name attribute. To view the policy in XML, see Matching2.xml.
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<rule>
<description>Match Group by Common Name</description>
<conditions>
<or>
<if-class-name op="equal">Group</if-class-name>
</or>
</conditions>
<actions>
<do-find-matching-object scope="subtree">
<arg-match-attr name="CN"/>
</do-find-matching-object>
</actions>
</rule>
</policy>
3.4.3 Creation Policy
Creation policies, such as the Subscriber Creation policy and the Publisher Creation policy, define the conditions that must be met to create a new object.
For example, you create a new user in the Identity Vault, but you give the new User object only a name and ID. This creation is mirrored in the Identity Vault tree, but the addition is not immediately reflected in applications connected to the Identity Vault because you have a Creation policy specifying that only User objects with a more complete definition are allowed.
A Creation policy can be the same for both the Subscriber and the Publisher, or it can be different.
Template objects can be specified for use in the creation process when the object is to be created in the Identity Vault.
Creation policies are commonly used to:
-
Veto creation of objects that don’t qualify, possibly because of a missing attribute.
-
Provide default attribute values.
-
Provide a default password.
Examples:
Required Attributes: Example
The first rule of this example DirXML Script policy requires that a User object contain a CN, Given Name, Surname, and Internet EMail Address attribute before the user can be created. The second rule requires an OU attribute for all Organizational Unit objects. The final rule vetoes all User objects with a name of Fred. To view the policy in XML, see Create1.xml.
<policy>
<rule>
<description>Veto if required attributes CN, Given Name, Surname and Internet EMail Address not available</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
</conditions>
<actions>
<do-veto-if-op-attr-not-available name="CN"/>
<do-veto-if-op-attr-not-available name="Given Name"/>
<do-veto-if-op-attr-not-available name="Surname"/>
<do-veto-if-op-attr-not-available name="Internet EMail Address"/>
</actions>
</rule>
<rule>
<description>Organizational Unit Required Attributes</description>
<conditions>
<or>
<if-class-name op="equal">Organizational Unit</if-class-name>
</or>
</conditions>
<actions>
<do-veto-if-op-attr-not-available name="OU"/>
</actions>
</rule>
<rule>
<description>Conditionally veto guys named "Fred"</description>
<conditions>
<and>
<if-global-variable name="no-fred" op="equal">true</if-global-variable>
<if-op-attr name="Given Name" op="equal">Fred</if-op-attr>
</and>
</conditions>
<actions>
<do-status level="warning">
<arg-string>
<token-text xml:space="preserve" xmlns:xml="http://www.w3.org/XML/1998/namespace">Vetoed "Fred"</token-text>
</arg-string>
</do-status>
<do-veto/>
</actions>
</rule>
</policy>
Default Attribute Values: Example
This example DirXML Script policy adds a default value for a user’s Description attribute. To view the policy in XML, see Create2.xml.
<policy>
<rule>
<description>Default Description of New Employee</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
</or>
</conditions>
<actions>
<do-set-default-attr-value name="Description">
<arg-value type="string">
<token-text>New Employee</token-text>
</arg-value>
</do-set-default-attr-value>
</actions>
</rule>
</policy>
Default Password: Example
This example DirXML Script policy provides creates a password value comprised of the first two characters of the first name and the first six characters of the last name, all in lowercase. To view the policy in XML, see Create3.xml
<policy>
<rule>
<description>Default Password of [2]FN+[6]LN</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-password op="not-available"/>
</and>
</conditions>
<actions>
<do-set-dest-password>
<arg-string>
<token-lower-case>
<token-substring length="2">
<token-op-attr name="Given Name"/>
</token-substring>
<token-substring length="6">
<token-op-attr name="Surname"/>
</token-substring>
</token-lower-case>
</arg-string>
</do-set-dest-password>
</actions>
</rule>
</policy>
Specify Template: Example
This example DirXML Script policy specifies a template object if a user’s Title attribute indicates that the user is a Manager (contains “Manager”). To view the policy in XML, see Create4.xml.
<policy>
<rule>
<description>Assign Manager Template if Title contains Manager</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr name="Title" op="available"/>
<if-op-attr mode="regex" name="Title" op="equal">.*Manager.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-template-dn>
<arg-dn>
<token-text>Users\Manager Template</token-text>
</arg-dn>
</do-set-op-template-dn>
</actions>
</rule>
</policy>
3.4.4 Placement Policy
Placement policies determine where new objects are placed and what they are named in the Identity Vault and the connected application.
A Placement policy is required on the Publisher channel if you want object creation to occur in the Identity Vault. A Placement policy might not be necessary on the Subscriber channel even if you want object creations to occur in the connected application, depending on the nature of the destination data store. For example, no Placement policy is needed when synchronizing to a relational database because rows in a relational database do not have a location or a name.
Placement By Attribute Value: Example 1
This example DirXML Script policy creates the user in a specific container based on the value of the Department attribute. To view the policy in XML, see Placement1.xml.
<policy>
<rule>
<description>Department Engineering</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Department" op="equal">.*Engineering.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Eng</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Department HR</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Department" op="equal">.*HR.*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>HR</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
Placement By Attribute Value: Example 2
This DirXML Script policy determines placement of a User or Organization Unit by the src-dn in the input document. To view the policy in XML, see Placement2.xml.
<policy>
<rule>
<description>PublisherPlacementRule</description>
<conditions>
<or>
<if-class-name op="equal">User</if-class-name>
<if-class-name op="equal">Organizational Unit</if-class-name>
</or>
<or>
<if-src-dn op="in-subtree">o=people, o=novell</if-src-dn>
</or>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>People</token-text>
<token-text>\</token-text>
<token-unmatched-src-dn convert="true"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
Placement By Name: Example
This example DirXML Script policy creates the user in a specific container based on the first letter of the user’s last name. Users with a last name beginning with A-I are placed in the container Users1, while J-R are placed in Users2, and S-Z in Users3. To view the policy in XML, see Placement3.xml.
<policy>
<rule>
<description>Surname - A to I in Users1</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[A-I].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users1</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Surname - J to R in Users2</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[J-R].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users2</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
<rule>
<description>Surname - S to Z in Users3</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
<if-op-attr mode="regex" name="Surname" op="equal">[S-Z].*</if-op-attr>
</and>
</conditions>
<actions>
<do-set-op-dest-dn>
<arg-dn>
<token-text>Users3</token-text>
<token-text>\</token-text>
<token-op-attr name="CN"/>
</arg-dn>
</do-set-op-dest-dn>
</actions>
</rule>
</policy>
3.4.5 Command Transformation Policy
Command Transformation policies alter the commands that Identity Manager is sending to the destination data store by either substituting or adding commands. Intercepting a Delete command and replacing it with Modify, Move, or Disable command is an example of substituting commands in a Command Transformation policy. Creating a Modify command based on the attribute value of an Add command is a common example of adding commands in a Command Transformation policy.
In the most general terms, Command Transformation policies are used to alter the commands that Identity Manager executes as a result of the default processing of events that were submitted to the Metadirectory engine.
It is also common practice to include policies here that do not fit neatly into the descriptions of any other policy.
Convert Delete to Modify: Example
This DirXML Script policy converts a Delete operation to a Modify operation of the Login Disabled attribute. To view the policy in XML, see Comannd1.xml.
<policy>
<rule>
<description>Convert User Delete to Modify</description>
<conditions>
<and>
<if-operation op="equal">delete</if-operation>
<if-class-name op="equal">User</if-class-name>
</and>
</conditions>
<actions>
<do-set-dest-attr-value name="Login Disabled">
<arg-value type="state">
<token-text>true</token-text>
</arg-value>
</do-set-dest-attr-value>
<do-veto/>
</actions>
</rule>
</policy>
Create Additional Operation: Example
This DirXML Script policy determines if the destination container for the user already exists. If the container doesn’t exist, the policy creates an Add operation to create the Container object. To view the policy in XML, see Command2.xml.
<policy>
<rule>
<description>Check if destination container already exists</description>
<conditions>
<and>
<if-operation op="equal">add</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="target-container">
<arg-string>
<token-dest-dn length="-2"/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="does-target-exist">
<arg-string>
<token-dest-attr class-name="OrganizationalUnit" name="objectclass">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
</token-dest-attr>
</arg-string>
</do-set-local-variable>
</actions>
</rule>
<rule>
<description>Create the target container if necessary</description>
<conditions>
<and>
<if-local-variable name="does-target-exist" op="available"/>
<if-local-variable name="does-target-exist" op="equal"/>
</and>
</conditions>
<actions>
<do-add-dest-object class-name="organizationalUnit" direct="true">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
</do-add-dest-object>
<do-add-dest-attr-value direct="true" name="ou">
<arg-dn>
<token-local-variable name="target-container"/>
</arg-dn>
<arg-value type="string">
<token-parse-dn dest-dn-format="dot" length="1" src-dn-format="dest-dn" start="-1">
<token-local-variable name="target-container"/>
</token-parse-dn>
</arg-value>
</do-add-dest-attr-value>
</actions>
</rule>
</policy>
Setting Password Expiration Time: Example
This DirXML Script policy modifies the Identity Vault user’s Password Expiration Time attribute. To view the policy in XML, see Command3.xml.
<?xml version="1.0" encoding="UTF-8"?>
<policy xmlns:jsystem="http://www.novell.com/nxsl/java/java.lang.System">
<rule>
<description>Set password expiration time for a given interval from current day</description>
<conditions>
<and>
<if-operation op="equal">modify-password</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="interval">
<arg-string>
<token-text>30</token-text>
</arg-string>
</do-set-local-variable>
<do-set-dest-attr-value class-name="User" name="Password Expiration Time" when="after">
<arg-association>
<token-association/>
</arg-association>
<arg-value type="string">
<token-xpath expression="round(jsystem:currentTimeMillis() div 1000 + (86400*$interval))"/>
</arg-value>
</do-set-dest-attr-value>
</actions>
</rule>
</policy>
3.4.6 Schema Mapping Policy
Schema Mapping policies hold the definition of the schema mappings between the Identity Vault and the connected system.
The Identity Vault schema is read from the Identity Vault. The Identity Manager driver for the connected system supplies the connected application’s schema. After the two schemas have been identified, a simple mapping is created between the Identity Vault and the target application.
After a Schema Mapping policy is defined in the Identity Manager driver configuration, the corresponding data can be mapped.
It is important to note the following:
-
The same policies are applied in both directions.
-
All documents that are passed in either direction on either channel between the Metadirectory engine and the application shim are passed through the Schema Mapping policies.
See Defining Schema Map Policies
in Policies in Designer 4.0.2 for administrative information.
Basic Schema Mapping Policy: Example
This example DirXML Script policy shows the raw XML source of a basic Schema Mapping policy. However, when you edit the policy through Designer for Identity Manager, the default Schema Mapping editor allows the policy to be displayed and edited graphically. To view the policy in XML, see SchemaMap1.xml.
<?xml version="1.0" encoding="UTF-8"?><attr-name-map>
<class-name>
<app-name>WorkOrder</app-name>
<nds-name>DirXML-nwoWorkOrder</nds-name>
</class-name>
<class-name>
<app-name>PbxSite</app-name>
<nds-name>DirXML-pbxSite</nds-name>
</class-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>PBXName</app-name>
<nds-name>DirXML-pbxName</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>TelephoneNumber</app-name>
<nds-name>Telephone Number</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>LoginName</app-name>
<nds-name>DirXML-pbxLoginName</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>Password</app-name>
<nds-name>DirXML-pbxPassword</nds-name>
</attr-name>
<attr-name class-name="DirXML-pbxSite">
<app-name>Nodes</app-name>
<nds-name>DirXML-pbxNodesNew</nds-name>
</attr-name>
</attr-name-map>
Custom Schema Mapping Policy: Example
This example DirXML Script policy uses DirXML Script to perform custom Schema Mapping. To view this policy in XML, see SchemaMap2.xml.
<?xml version="1.0" encoding="UTF-8"?><policy>
<rule>
<!--
The Schema Mapping Policy can only handle one-to-one mappings.
That Mapping Policy maps StudentPersonal addresses.
This rule maps StaffPersonal addresses.
-->
<description>Publisher Staff Address Mappings</description>
<conditions>
<and>
<if-local-variable name="fromNds" op="equal">false</if-local-variable>
<if-xpath op="true">@original-class-name = ’StaffPersonal’</if-xpath>
</and>
</conditions>
<actions>
<do-rename-op-attr dest-name="SA" src-name="Address/Street/Line1"/>
<do-rename-op-attr dest-name="Postal Office Box" src-name="Address/Street/Line2"/>
<do-rename-op-attr dest-name="Physical Delivery Office Name" src-name="Address/City"/>
<do-rename-op-attr dest-name="S" src-name="Address/StatePr"/>
<do-rename-op-attr dest-name="Postal Code" src-name="Address/PostalCode"/>
</actions>
</rule>
<rule>
<description>Subscriber Staff Address Mappings</description>
<!--
The Schema Mapping Policy has already mapped addresses to StudentPersonal.
This rule maps StudentPersonal to StaffPersonal.
-->
<conditions>
<and>
<if-local-variable name="fromNds" op="equal">true</if-local-variable>
<if-op-attr name="DirXML-sifIsStaff" op="equal">true</if-op-attr>
</and>
</conditions>
<actions>
<do-rename-op-attr dest-name="Address/Street/Line1" src-name="StudentAddress/Address/Street/Line1"/>
<do-rename-op-attr dest-name="Address/Street/Line2" src-name="StudentAddress/Address/Street/Line2"/>
<do-rename-op-attr dest-name="Address/City" src-name="StudentAddress/Address/City"/>
<do-rename-op-attr dest-name="Address/StatePr" src-name="StudentAddress/Address/StatePr"/>
<do-rename-op-attr dest-name="Address/PostalCode" src-name="StudentAddress/Address/PostalCode"/>
</actions>
</rule>
</policy>
3.4.7 Output Transformation Policy
Output Transformation policies primarily handle the conversion of data formats from data that the Metadirectory engine provides to data that the application shim expects. Examples of these conversions include:
-
Attribute value format conversion
-
XML vocabulary conversion
-
Custom handling of status messages returned from the Metadirectory engine to the application shim
All documents that the Metadirectory engine supplies to the application shim on either channel pass through the Output Transformation policies. Since the Output Transformation happens after schema mapping, all schema names are in the application namespace.
Attribute Value Conversion: Example
This example DirXML Script policy reformats the telephone number from the (nnn) nnn-nnnn format to the nnn.nnn.nnnn format. The reverse transformation can be found in the Input Transformation policy examples. To view the policy in XML, see Output_Transformation1.xml.
<policy>
<rule>
<description>Reformat all telephone numbers from (nnn) nnn-nnnn to nnn.nnn.nnnn</description>
<conditions/>
<actions>
<do-reformat-op-attr name="telephoneNumber">
<arg-value type="string">
<token-replace-first regex="^\((\d\d\d)\) *(\d\d\d)-(\d\d\d\d)$" replace-with="$1.$2.$3">
<token-local-variable name="current-value"/>
</token-replace-first>
</arg-value>
</do-reformat-op-attr>
</actions>
</rule>
</policy>
Customer Handling of Status Messages:
This example DirXML Script policy detects status documents with a level not equal to success that also contain a child password-publish-status element within the operation data and then generates an e-mail message using the DoSendEmailFromTemplate action. To view the policy in XML, see Output_Transformation2.xml.
<?xml version="1.0" encoding="UTF-8"?>
<policy>
<description>Email notifications for failed password publications</description>
<rule>
<description>Send e-mail for a failed publish password operation</description>
<conditions>
<and>
<if-global-variable mode="nocase" name="notify-user-on-password-dist-failure" op="equal">true</if-global-variable>
<if-operation op="equal">status</if-operation>
<if-xpath op="true">self::status[@level != ’success’]/operation-data/password-publish-status</if-xpath>
</and>
</conditions>
<actions>
<!-- generate email notification -->
<do-send-email-from-template notification-dn="\cn=security\cn=Default Notification Collection" template-dn="\cn=security\cn=Default Notification Collection\cn=Password Sync Fail">
<arg-string name="UserFullName">
<token-src-attr name="Full Name">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="UserGivenName">
<token-src-attr name="Given Name">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="UserLastName">
<token-src-attr name="Surname">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="ConnectedSystemName">
<token-global-variable name="ConnectedSystemName"/>
</arg-string>
<arg-string name="to">
<token-src-attr name="Internet Email Address">
<arg-association>
<token-xpath expression="self::status/operation-data/password-publish-status/association"/>
</arg-association>
</token-src-attr>
</arg-string>
<arg-string name="FailureReason">
<token-text/>
<token-xpath expression="self::status/child::text()"/>
</arg-string>
</do-send-email-from-template>
</actions>
</rule>
</policy>
3.4.8 Input Transformation Policy
Input Transformation policies primarily handle the conversion of data formats from data that the application shim provides to data that the Metadirectory engine expects. Examples of these conversions include:
-
Attribute value format conversion
-
XML vocabulary conversion
-
Driver heartbeat
-
Custom handling of status messages returned from the application shim to the Metadirectory engine
All documents supplied to the Metadirectory engine by the application shim on either channel pass through the Input Transformation policies.
Attribute Value Format Conversion: Example
This example DirXML Script policy reformats the telephone number from the nnn.nnn.nnnn format to the (nnn) nnn-nnnn format. The reverse transformation can be found in Section 3.4.7, Output Transformation Policy examples. To view the policy in XML, see Input_Transformation1.xml.
<policy>
<rule>
<description>Reformat all telephone numbers from nnn.nnn.nnnn to (nnn) nnn-nnnn</description>
<conditions/>
<actions>
<do-reformat-op-attr name="telephoneNumber">
<arg-value type="string">
<token-replace-first regex="^(\d\d\d)\.(\d\d\d)\.(\d\d\d\d)$" replace-with="($1) $2-$3">
<token-local-variable name="current-value"/>
</token-replace-first>
</arg-value>
</do-reformat-op-attr>
</actions>
</rule>
</policy>
Driver Heartbeat: Example
This DirXML Script policy creates a status heartbeat event. The driver’s heartbeat functionality is used to send a success message (HEARTBEAT: $driver) at each heartbeat interval. The message can be monitored by Novell Audit.The Identity Manager driver must support heartbeat, and heartbeat must be enabled at the driver configuration page. To view the policy in XML, see Input_Transformation2.xml.
<?xml version="1.0" encoding="UTF-8" ?>
<policy>
<rule>
<description>Heartbeat Rule, v1.01, 040126, by Holger Dopp</description>
<conditions>
<and>
<if-operation op="equal">status</if-operation>
<if-xpath op="true">@type="heartbeat"</if-xpath>
</and>
</conditions>
<actions>
<do-set-xml-attr expression="." name="text1">
<arg-string>
<token-global-variable name="dirxml.auto.driverdn" />
</arg-string>
</do-set-xml-attr>
<do-set-xml-attr expression="." name="text2">
<arg-string>
<token-text>HEARTBEAT</token-text>
</arg-string>
</do-set-xml-attr>
</actions>
</rule>
</policy>
3.4.9 Start Up Policies
When a driver is started, the Identity Manager engine sends a start-up event to the policy set. A Start-up event looks like this:
<nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Advanced" version="4.0.2.3">DirXML</product> <contact>Novell, Inc.</contact> </source> <input> <status level="success" type="startup"/> </input> </nds>
You can create policies on top of a start-up event to perform custom actions at the driver start up. For example, initialization of persistent driver-scope variables, sending a notification from the DirXML Script to an external auditing or monitoring system, and so on. There are no plug-ins currently available to create policies in the Start-up policy set. To create these policies, run the following steps:
-
Create policies in any of the driver policy sets. For example, Subscriber Command Transformation Policy set.
-
Link the policies to the Start-up policy set.
-
Go to , click the tab, then select the DirXML-Policies attribute from the list and click .
-
In the Edit Attribute dialog, select the desired policy, then click the button. The TypeNamedUiHandlerLevel attribute specifies the order in which you want to execute the policy. Policy at level 0 is executed first followed by level 1, 2, and so on. The TypeNamedUiHandlerInterval attribute specifies the policy set in which you want to execute the policy. For the Start-up policy, set the value to 15, then click .
-
3.4.10 Shut-Down Policies
When a driver is stopped, the Identity Manager engine sends a stop event to the policy set. A Shut-Down event looks like this:
<nds dtdversion="4.0" ndsversion="8.x"><source> <product edition="Advanced" version="4.0.2.3">DirXML</product> <contact>Novell, Inc.</contact> </source> <input> <status level="success" type="shutdown"/> </input> </nds>
You can create policies on top of a start-up event to perform custom actions at the driver shutdown. For example, saving the state of driver-scope variables by writing them to the eDirectory objects, making use of Java to perform some customized tasks, and so on. There are no plug-ins currently available to create policies in the Shut-Down policy set. To create these policies, run the following steps:
-
Create policies in any of the driver policy sets. For example, Subscriber Command Transformation Policy set.
-
Link the policies to the Shut-down policy set.
-
Go to , click the tab, then select the DirXML-Policies attribute from the list and click .
-
In the Edit Attribute dialog, select the desired policy, then click the button. The TypeNamedUiHandlerLevel attribute specifies the order in which you want to execute the policy. Policy at level 0 is executed first followed by level 1, 2, and so on. The TypeNamedUiHandlerInterval attribute specifies the policy set in which you want to execute the policy. For the Shut-down policy, set the value to 16, then click .
-