Www.novell.com Novell DirXML ™ Commands, Events, and Transformations Shon Vella Software Engineer, Consultant Novell, Inc. [email protected] Perin Blanchard

www.novell.com

Novell DirXML™ Commands, Events, and Transformations

Novell DirXML™ Commands, Events, and Transformations

Shon VellaSoftware Engineer, ConsultantNovell, [email protected]

Perin BlanchardSoftware Engineer, ConsultantNovell, [email protected]

DirXML™ and XML

• DirXML is a flexible data sharing service Shares data between disparate systems

throughout the network Flexibility is achieved by encoding the shared

data in XML and using configurable rules to transform the data as it is transferred between systems

In order to use DirXML effectively to implement complex business processes it is necessary to understand DirXML’s XML vocabulary and the ways that the XML can be transformed by rules

Vision…one NetA world where networks of all types—corporate and public, intranets, extranets, and the Internet—work together as one Net and securely connect employees, customers, suppliers, and partners across organizational boundaries

MissionTo solve complex business and technical challenges with Net business solutions that enable people, processes, and systems to work together and our customers to profit from the opportunities of a networked world

DirXML and XSLT

• XSLT is a transformation language for XML XSLT is an acronym for eXtensible Stylesheet

Language Transformations XSLT 1.0 is a World Wide Web Consortium

(W3C) recommendation published in 1999 XSLT is a vocabulary of XML that specifies

transformation semantics that operate on XML documents

DirXML uses XSLT 1.0 as a method of implementing rules

<person> <given-name>John</given-name> <surname>Doe</surname> <telephone>801-555-1234</telephone></person>

An Introductory Stylesheet

Convert an XML document

For display in HTML as

<html><body> First name: John<br> Last name: Doe<br> Phone: 801-555-1234<br></body></html>

An Introductory Stylesheet:Stylesheet Element

<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"version="1.0">

<xsl:template match="person">

<html><body>

First name: <xsl:apply-templates select="given-name"/><br/>

Last name: <xsl:apply-templates select="surname"/><br/>

Phone: <xsl:apply-templates select="telephone"/><br/>

</body></html>

</xsl:template>

</xsl:transform>

An Introductory Stylesheet:Namespace and Instructions



<html><body>




</body></html>

</xsl:template>

</xsl:transform>

An Introductory Stylesheet:Templates and Match Patterns



<html><body>




</body></html>

</xsl:template>

</xsl:transform>

An Introductory Stylesheet:Recursion and XPath Expressions



<html><body>




</body></html>

</xsl:template>

</xsl:transform>

An Introductory Stylesheet:Literal Result Elements and Text



<html><body>




</body></html>

</xsl:template>

</xsl:transform>

DirXML Architecture

Novell eDirectory™ DirXML Application

API

Event

Eventcaching

DirXMLengine

DirXML application

shim

eDirectory server

NDS.DTD

• NDS.DTD defines document structure for Commands and events in the DirXML Engine (XDS) The simple form of the following DirXML rules

• Schema mapping rules • Matching rules• Create rules• Placement rules

• The NDS.DTD file, together with documentation on semantics and usage, is available in the NDK

http://developer.novell.com/ndk/dirxml.htm

DirXML’s XML Vocabulary

• DirXML defines an XML vocabulary that DirXML uses to encode data events and commands

The vocabulary is called XDS XDS documents are used as the medium of

communication between the DirXML engine and a DirXML application shim

Used internally by the DirXML engine Operated on by DirXML rules XDS is user-extensible and is not validated against

the DTD by the DirXML engine

Input and Output Documents

• An XDS document consists of an <nds> element with an optional <source> element and a single <input> or <output> element

Documents used to report data events from eDirectory or from an application are input documents

Documents used to command eDirectory or an application to perform an action are input documents

Documents returned in response to an input document are output documents

<nds dtdversion="1.1" ndsversion="8.5"> <source> <product version="1.1">DirXML</product> <contact>Novell, Inc.</contact> </source> <input> <add class-name="User"

src-dn="Users\Julia"dest-dn="cn=Julia,o=Users"event-id="0">

<add-attr attr-name="Surname"> <value type="string">Gulia</value> </add-attr> </add> </input></nds>

Input Example

An application shim is sent the following document as input

<nds dtdversion="1.1" ndsversion="8.5"> <output> <status event-id="0" level="success"/> <add-association dest-dn="Users\Julia">JuliaGulia1</add-association> </output></nds>

Output Example

The application shim might respond with

Events vs. Commands

• An event is a report of a data change event in either Novell eDirectory or an application

• A command is an instruction to either eDirectory or an application

• When an event notification is sent to DirXML the DirXML engine will determine, based on the rules, what commands need to be issued to keep the data synchronized

Input Events and Commands

• Events and commands that may be children of an <input> element include

<add> <modify> <delete> <rename> <move> <query> Other allowed children of <input> are less frequently

used

Input Events and Commands

• The <add>, <modify>, <delete>, <rename>, and <move> elements represent both commands and events

Commands and events have essentially the same syntax

Interpretation depends on context• Events are sent to the DirXML engine by the

application shim and by eDirectory• Commands are sent to the application shim and to

eDirectory by DirXML

Output Responses

• Events and commands that can be children of an <output> element include

<status> <instance> <add-association> Other allowed children of <output> are less

frequently used

Common Attributes

• Attributes common to many events and commands and responses include

class-name • The base class of the object

dest-dn• The DN of the target object for commands

src-dn• The DN of the source object for events

event-id• An identifier used to tag the results of an event or

command

Common Content Elements

• Content elements that are common to many events, commands, and responses include

<association> <value> <component>

Association

• The value of the <association> element is a unique key provided by the application shim used to identify the source application object of an event or the target application object of a command

The key is used to associate objects in eDirectory with an object in another application and is stored as an attribute of the eDirectory object

The state attribute is used internally by DirXML for control purposes

Value

• <value> elements are used to represent object values or properties

The type attribute is used to determine how to interpret the <value> content• “Octet” values contain base64-encoded binary data• “Structured” values consist of zero or more

<component> elements• All other value types use a simple string

representation of the value The association-ref attribute is used in

conjunction with referential attributes

Values Examples

• Example <value> elements

<value type="string">Fred</value>

<value type="octet">RM8FFyP21kirzwqLjr+Q6g==</value>

<value type="structured"><component name="protectedName">[All Attributes Rights]</component><component name="trustee" association-ref="cn=b,o=n">\TREE\O\Admin</component><component name="privileges">2</component>

</value>

Status

• A <status> element is used to return the status of processing a command or event

More than one <status> element can be returned as a result of a given event or command

The level attribute indicates the disposition of the associated event or command• Possible values “success”, “warning”, “error”, “retry”,

and “fatal” The event-id attribute—the event-ID value of the

corresponding event or command element The content is a specific error or warning message

<status event-id="0" level="success"/>

<status event-id="37" level="warning">Operation vetoed by Placement Rule</status>

<status event-id="4" level="error">ERR_NO_ACCESS</status>

Status Examples

• Example <status> elements

Add

• An <add> element is used As an event from an application shim or from

eDirectory notifying DirXML that an object was added

As a command from DirXML instructing an application shim to add an object in the application or instructing eDirectory to add an object

Add Example

• A simple object-creation event from a hypothetical application

<nds dtdversion="1.0" ndsversion="8.5"><input>

<add class-name="User" src-dn="cn=John Doe,o=novell"><association>JDoe2474</association><add-attr attr-name="Given Name">

<value type="string">John</value></add-attr><add-attr attr-name="Surname">

<value type="string">Doe</value></add-attr><add-attr attr-name="Telephone Number">

<value type="string">555-2474</value></add-attr>

</add></input>

</nds>

Modify

• A <modify> element is used As an event from an application shim or from

eDirectory notifying DirXML that one or more of an object’s attribute values were modified

As a command from DirXML instructing an application shim to modify attribute values in an application object or instructing eDirectory to modify attribute values in an eDirectory object

Modify Example

• A simple object-modification event from a hypothetical application

<nds dtdversion="1.0" ndsversion="8.5"><input>

<modify class-name="User" src-dn="cn=John Doe,o=novell"><association>JDoe2474</association><modify-attr attr-name="Telephone Number">

<remove-value><value type="string">555-2474</value>

</remove-value><add-value>

<value type="string">555-1234</value></add-value>

</modify-attr></modify>

</input></nds>

Rename

• A <rename> element is used As an event from an application shim or from

eDirectory notifying DirXML that an object was renamed

As a command from DirXML instructing an application shim to rename an application object or from DirXML instructing eDirectory to rename an eDirectory object

Rename Example

• A simple object-rename event from a hypothetical application<nds dtdversion="1.0" ndsversion="8.5"> <input> <rename class-name="User" src-dn="cn=JDoe,o=novell" old-src-dn="cn=John Doe,o=novell"> <association>JDoe2474</association> <new-name>JDoe</new-name> </rename> </input></nds>

Move

• A <move> element is used As an event from an application shim or from

eDirectory notifying DirXML that an object was moved

As a command from DirXML instructing an application shim to move an application object or from DirXML instructing eDirectory to move an eDirectory object

Move Example

• A simple object-move event from a hypothetical application

<nds dtdversion="1.0" ndsversion="8.5"> <input> <move class-name="User" src-dn="cn=JDoe,o=Inactive" old-src-dn="cn=JDoe,o=novell"> <association>JDoe2474</association> <parent src-dn="o=Inactive"> <association>TC234689887</association> </parent> </move> </input></nds>

Query

• A <query> element is used as a command instructing an application shim or eDirectory to find and/or read objects and their attributes

• Queries are limited by specification of A base object Scope

• Entry, subordinates, or subtree Classes to include Attribute values to search for Attributes to return in the response

Query (cont.)

• A query that reads attributes values from an object

<nds dtdversion="1.0" ndsversion="8.5"> <input> <query class-name="User" scope="entry"> <association>JDoe2474</association> <read-attr attr-name="Telephone Number"/> </query> </input></nds>

Query (cont.)

• A query that searches for objects of a particular class with particular attribute values

<nds dtdversion="1.0" ndsversion="8.5"> <input> <query class-name="User" scope="subtree"> <search-class class-name="User"/> <search-attr attr-name="Given Name"> <value type="string">John</value> </search-attr> <read-attr/> </query> </input></nds>

Query Response

• Zero or more <instance> elements are contained in the response to a query

Query Response Example

• A potential response to a query that reads an attribute value from an object

<nds dtdversion="1.0" ndsversion="8.5"> <output> <instance class-name="User" src-dn="cn=JDoe,o=Inactive">

<association>JDoe2474</association> <attr attr-name="Telephone Number"> <value type="string">555-2474</value> </attr></instance >

</output></nds>

Delete

• A <delete> element is used As an event from an application shim or from

eDirectory notifying DirXML that an object was deleted

As a command from DirXML instructing an application shim or instructing eDirectory to delete an object

Delete (cont.)

• A simple object-delete event from a hypothetical application

<nds dtdversion="1.0" ndsversion="8.5"> <input> <delete class-name="User" src-dn="cn=JDoe,o=Inactive"> <association>JDoe2474</association> </delete> </input></nds>

• Submitting samples to DirXML <add> <modify> <rename> <move> <query> <delete>

demonstratio

Rules:XML Transformations

• Rules control how the DirXML engine transforms an event reported on a channel input into set of commands for the channel output

Subscriber• Input event comes from eDirectory and the output

command(s) are sent to the application shim Publisher

• Input event comes from the application shim and the output command(s) are sent to eDirectory

Any DirXML rule can be implemented as an XSLT stylesheet

Simple Rules

• Four types of rules perform a well-defined role and have a simple XML vocabulary to describe the event-to-command transformation

Schema Mapping rules Matching rules Create rules Placement rules

• Any of the above rule types can also be implemented using an XSLT stylesheet

XSLT-Only Rules

• Four types of rules allow for more general customization and must be implemented with an XSLT stylesheet

Event Transformation Rules Command Transformation Rules Input Transformation Rules Output Transformation Rules

Rule Chaining

• Any rule can be implemented as a series of individual rule objects chained together

• The output of each rule object is passed as the input to the next rule object in the chain

• Used to supplement the behavior of a simple rule with a stylesheet without having to implement all the rule logic in a stylesheet

Schema Mapping Rules

• Schema Mapping Rules are used to map class names and attribute names between eDirectory and application namespaces

Maps all class-name attributes in an XDS document

Maps all attr-name attributes in an XDS document• attr-name mapping may be based on the class-name

that is in scope Is bi-directional and same rule operates on both

channels

Simple Schema Mapping Rules

• Simple Schema Mapping Rules provide a 1-1 mapping of schema names

• Attribute name mappings may be optionally dependent on the class name

• Any other more complex mapping must be done with an XSLT stylesheet

<attr-name-map> <class-name> <nds-name>User</nds-name> <app-name>inetOrgPerson</app-name> </class-name> <attr-name class-name="User"> <nds-name>Given Name</nds-name> <app-name>givenName</app-name> </attr-name> <attr-name> <nds-name>Surname</nds-name> <app-name>sn</app-name> </attr-name></attr-name-map>

Simple Schema Mapping Rules Example

• Schema Mapping Rules for a hypothetical application

Simple Schema Mapping Rules Transformation Example

<add class-name="User"

src-dn="\TREE\Provo\JSmith">

<add-attr attr-name="CN">

<value>John Smith</value>

</add-attr>

<add-attr attr-name="Surname">

<value>Smith</value>

</add-attr>

<add-attr attr-name="Given Name">

<value>John</value>

</add-attr>

</add>

• To application shim

<add class-name="inetOrgPerson" src-dn="\TREE\Provo\JSmith"> <add-attr attr-name="CN"> <value>John Smith</value> </add-attr> <add-attr attr-name="sn"> <value>Smith</value> </add-attr> <add-attr attr-name="givenName"> <value>John</value> </add-attr></add>

• From eDirectory

XSLT Schema Mapping Rules Example

<xsl:transform

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

version="1.0">

<xsl:param name="fromNds"/>

<xsl:template match="/">

<xsl:choose>

<xsl:when test="$fromNds">

<xsl:apply-templates mode="fromNds"/>

</xsl:when>

<xsl:otherwise>

<xsl:apply-templates mode="toNds"/>

</xsl:otherwise>

</xsl:choose>

</xsl:template>

<xsl:template match="@class-name[.='User']"

mode="fromNds">

<xsl:attribute name="{name()}">inetOrgPerson</xsl:attribute>

</xsl:template>

<xsl:template match="@class-name[.='inetOrgPerson']" mode="toNds">

<xsl:attribute name="{name()}">User</xsl:attribute>

</xsl:template>

<xsl:template match="@attr-name[.='Given Name' and

ancestor-or-self::*[@class-name][1]/@class-name[.='User']]"

mode="fromNds">

<xsl:attribute name="{name()}">givenName</xsl:attribute>

</xsl:template>

<xsl:template match="@attr-name[.='givenName' and

ancestor-or-self::*[@class-name][1]/@class-name[.='inetOrgPerson']]"

mode="toNds">

<xsl:attribute name="{name()}">Given Name</xsl:attribute>

</xsl:template>

<xsl:template match="@attr-name[.='Surname']" mode="fromNds">

<xsl:attribute name="{name()}">sn</xsl:attribute>

</xsl:template>

<xsl:template match="@attr-name[.='sn']" mode="toNds">

<xsl:attribute name="{name()}">Surname</xsl:attribute>

</xsl:template>

<xsl:template match="node()|@*" mode="fromNds">

<xsl:copy>

<xsl:apply-templates select="@*|node()" mode="fromNds"/>

</xsl:copy>

</xsl:template>

<xsl:template match="node()|@*" mode="toNds">

<xsl:copy>

<xsl:apply-templates select="@*|node()" mode="toNds"/>

</xsl:copy>

</xsl:template>

<xsl:template match="node()|@*">

<xsl:copy>

<xsl:apply-templates select="@*|node()"/>

</xsl:copy>

</xsl:template>

</xsl:transform>

Matching Rules

• Matching Rules are used to try to find a matching object in the channel destination for an unassociated object in the channel source as a result of an <add> event from the channel source

Applied before deciding if a new object should be created in the channel destination

On Publisher channel adds a dest-dn attribute for matches

On Subscriber channel adds an <association> attribute for matches

Simple Matching Rules

• An applicable rule is selected by object class and available attributes from the <add>

• A subtree-scoped query for the channel destination is generated based on the attribute values and class name from the <add> and the base object specified by the rule

• Each applicable rule is tried until a match is found

Simple Matching Rule Example

• Matching Rules for Subscriber Channel of hypothetical application

<matching-rules> <matching-rule> <match-class class-name="User"/> <match-attr attr-name="workforceID"/> </matching-rule>

<matching-rule> <match-class class-name="User"/> <match-path prefix="o=novell"/> <match-attr attr-name="Surname"/> <match-attr attr-name="Given Name"/> <match-attr attr-name="Telephone Number"/> </matching-rule></matching-rules>

Simple Matching Rules Transformation Example (Subscriber)





</add-attr>



</add-attr>


<value>John</value>

</add-attr>

</add>

• After

<add class-name="User" src-dn="\TREE\Provo\JSmith"> <association>JSmith99</association> <add-attr attr-name="CN"> <value>John Smith</value> </add-attr> <add-attr attr-name="Surname"> <value>Smith</value> </add-attr> <add-attr attr-name="Given Name"> <value>John</value> </add-attr></add>

• Before

Simple Matching Rules Transformation Example (Publisher)


src-dn="cn=Jsmith,o=novell"

<association>JSmith99</association>



</add-attr>



</add-attr>


<value>John</value>

</add-attr>

</add>

• After

<add class-name="User" src-dn="cn=Jsmith,o=novell" dest-dn="\TREE\Provo\Jsmith"> <association>JSmith99</association> <add-attr attr-name="CN"> <value>John Smith</value> </add-attr> <add-attr attr-name="Surname"> <value>Smith</value> </add-attr> <add-attr attr-name="Given Name"> <value>John</value> </add-attr></add>

• Before

XSLT Matching Rules Example



<xsl:transform version="1.0" xmlns:query="http://www.novell.com/nxsl/java/com.novell.nds.dirxml.driver.XdsQueryProcessor" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:param name="destQueryProcessor"/>



<xsl:variable name="ucase" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'"/>

<xsl:variable name="lcase" select="'abcdefghijklmnopqrstuvwxyz'"/>

<xsl:template match="node()|@*">

<xsl:copy>

<xsl:apply-templates select="node()|@*"/>

</xsl:copy>

</xsl:template>

<xsl:template match="add">

<xsl:copy>

<xsl:apply-templates select="@*"/>



<xsl:variable name="src-path">\</xsl:variable>

<xsl:variable name="dest-path">\MY-TREE\</xsl:variable>

<xsl:variable name="match-dn" select="concat($dest-path, substring-after(translate(@src-dn, $ucase,$lcase),translate($src-path,$ucase,$lcase)))"/>



<xsl:variable name="query">

<nds dtdversion="1.0" ndsversion="8.5">

<input>

<query dest-dn="{$match-dn}" scope="entry">

<read-attr/>

</query>

</input>

</nds>

</xsl:variable>



<xsl:variable name="result"

select="query:query($destQueryProcessor,$query)"/>

<xsl:variable name="instance" select="$result//instance"/>





<xsl:if test="translate(@class-name,$ucase,$lcase) =

translate($instance/@class-name,$ucase,$lcase)">

<xsl:attribute name="dest-dn">

<xsl:value-of select="$match-dn"/>

</xsl:attribute>

</xsl:if>

<xsl:apply-templates select="node()"/>

</xsl:copy>

</xsl:template>

</xsl:transform>

Create Rules

• Create Rules determine if it is permissible to generate an <add> command as a result of an <add> event

Veto disallowed <add> elements by removing them from the document

Fill in default values for unspecified attributes Add initial passwords Specify a template object Only applied after any Matching Rules

determine that there are no matching objects

Simple Create Rules

• An applicable rule is selected by object class and matching attributes from the <add>

• The <add> is vetoed if any of the required attributes are missing and no default is specified

• A template-dn attribute is added to an allowed <add> if specified by the rule

• Only the first applicable rule is applied• If no applicable rule is found the <add> is

allowed

Simple Create Rules Example

<create-rules> <create-rule class-name="User"> <match-attr attr-name="OU"> <value>Defense</value> </match-attr> <required-attr attr-name="Given Name"/> <required-attr attr-name="Surname"/> <required-attr attr-name="Clearance"/> <template template-dn="tmplt\Secure"/> </create-rule>

<create-rule class-name="User"> <required-attr attr-name="Given Name"/> <required-attr attr-name="Surname"/> <required-attr attr-name="Clearance"> <value>None</value> </required-attr> </create-rule></create-rules>

• Create Rules for Publisher Channel of hypothetical application

Simple Create Rules Transformation Example


src-dn="\TREE\Provo\JSmith"

<association>JSmith99</association>



</add-attr>


<value>John</value>

</add-attr>

</add>

• After

<add class-name="User" src-dn="\TREE\Provo\JSmith"> <association>JSmith99</association> <add-attr attr-name="Surname"> <value>Smith</value> </add-attr> <add-attr attr-name="Given Name"> <value>John</value> </add-attr> <add-attr attr-name="Clearance"> <value>None</value> </add-attr></add>

• Before

XSLT Create Rules Example

<xsl:transform


version="1.0">

<xsl:template match="@*|node()">

<xsl:copy>


</xsl:copy>

</xsl:template>

<xsl:template match="add[@class-name='User']">

<xsl:if test="add-attr[@attr-name='Surname'] and

add-attr[@attr-name='Given Name'] and

add-attr[@attr-name='Clearance']">

<xsl:copy>

<xsl:attribute name="template-dn">

<xsl:text>tmplt\Secure</xsl:text>

</xsl:attribute>


<xsl:call-template name="create-password"/>

</xsl:copy>

</xsl:if>

</xsl:template>


<xsl:if test="add-attr[@attr-name='Surname'] and

add-attr[@attr-name='Given Name']">

<xsl:copy>


<xsl:if test="not(add-attr[@attr-name='Clearance'])">

<add-attr attr-name="Clearance">

<value>None</value>

</add-attr>

</xsl:if>

<xsl:call-template name="create-password"/>

</xsl:copy>

</xsl:if>

</xsl:template>

<xsl:template name="create-password">

<password>

<xsl:value-of select="add-attr[@attr-name='Surname']/value"/>

</password>

</xsl:template>

</xsl:transform>

Placement Rules

• Placement Rules are used to give an object that is about to be created a name and location

Adds a dest-dn attribute value to the <add> Only applied after any Create Rules determine

that the add operation is allowed Always required on the Publisher channel for

object creation Might not be required on the Subscriber channel

depending on the application shim and application

Simple Placement Rules

• An applicable rule is selected by object class, matching attributes, and matching src-dn from the <add>

• A destination dn is generated by concatenation of literal text and pieces of the src-dn or attribute values from the <add>

• The pieces of the src-dn used may be converted to a different format (slash/dot/ldap/custom)

Simple Placement Rules Example

• Matching Rules for Subscriber Channel of hypothetical application

<placement-rules src-dn-format="slash" dest-dn-format="ldap"> <placement-rule> <match-class class-name="User"/> <match-path prefix="\TREE\novell"/> <placement><copy-path-suffix/>,o=novell</placement> </placement-rule> <placement-rule> <match-class class-name="User"/> <match-class class-name="Group"/> <placement>cn=<copy-name/>,ou=<copy-attr attr-name="OU"/>,o=novell</placement> </placement-rule> <placement-rule> <placement><copy-path/></placement> </placement-rule></placement-rules>

Simple Placement Rules Transformation Example





</add-attr>


<value>John</value>

</add-attr>

<add-attr attr-name="OU">

<value>Eng</value>

</add-attr>

</add>

• After

<add class-name="User" src-dn="\TREE\Provo\JSmith" dest-dn="cn=Jsmith,ou=Eng,o=novell"> <add-attr attr-name="Surname"> <value>Smith</value> </add-attr> <add-attr attr-name="Given Name"> <value>John</value> </add-attr> <add-attr attr-name="OU"> <value>Eng</value> </add-attr></add>

• Before

XSLT Placement Rules Example

<xsl:transform


version="1.0">

<xsl:template match="@*|node()">

<xsl:copy>


</xsl:copy>

</xsl:template>


<xsl:variable name="location"

select="string(add-attr[@attr-name='L']/value)"/>

<xsl:variable name="rdn"

select="substring-after(

substring-before(@src-dn, ','),

'=')"/>

<xsl:copy>

<xsl:attribute name="dest-dn">

<xsl:text>\TREE\novell\</xsl:text>

<xsl:value-of select="$location"/>

<xsl:choose>

<xsl:when test="$location">

<xsl:value-of select="$location"/>

</xsl:when>

<xsl:otherwise>

<xsl:text>Unknown</xsl:text>

</xsl:otherwise>

</xsl:choose>

<xsl:text>\</xsl:text>

<xsl:value-of select="$rdn"/>

</xsl:attribute>


</xsl:copy>

</xsl:template>

Input and Output Transformation Rules

• Input and Output Transformation Rules are used primarily to convert data formats

Sometimes also used to convert XDS to/from other vocabularies

XDS documents sent or returned to an application shim are sent through the Output Transformation Rules

XDS documents sent from or returned from an application shim to the DirXML engine are sent through the Input Transformation Rules

The same rules operate on both channels Always implemented as an XSLT Stylesheet

Input and Output Transformation Rules Example

• Input Transformation RulesFrom: nnn-nnn-nnnn

To: (nnn)nnn-nnnn

• Output Transformation RulesFrom: (nnn)nnn-nnnnTo: nnn-nnn-nnnn

<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy></xsl:template>

<xsl:template match="*[@attr-name='Telephone Number']//value/text()"> <xsl:variable name="area" select="substring-before(., '-')"/> <xsl:variable name="local" select="substring-after(., '-')"/> <xsl:value-of select="concat('(', $area, ')', $local)"/></xsl:template>

</xsl:transform>


<xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy></xsl:template>

<xsl:template match="*[@attr-name='Telephone Number']//value/text()"> <xsl:value-of select="translate(.,')(','-')"/></xsl:template>

</xsl:transform>

Event Transformation Rules

• Event Transformation Rules are used to perform preliminary transformations on an event

Custom event filtering Transforming the event directly into a custom

command to be passed to the application Generating additional events Always implemented as an XSLT Stylesheet

Event Transformation Rules Example

• Filter out all renames and moves


<xsl:template match="rename | move"></xsl:template>

<xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> </xsl:transform>

Command Transformation Rules

• Command Transformation Rules are used to perform any final transformations on commands before they are sent to eDirectory or the application shim

Changing the command type Blocking commands Adding additional commands Controlling the output of merge processing Always implemented as an XSLT Stylesheet

Command Transformation Rules Example

• Convert <delete> to set Login Disabled to true<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:template match="delete[@class-name='User']"> <modify> <xsl:apply-templates select="@class-name|@src-dn|@dest-dn|association"/> <modify-attr attr-name="Login Disabled"> <remove-all-values/> <add-value> <value type="state">true</value> </add-value> </modify-attr> </modify></xsl:template>

<xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> </xsl:transform>

DirXML Event Processing

Eventto

XML

EventTransformation

AssociationProcessor

AddEvent?

SchemaMapper

OutputTransformation

MatchingRule

CreateRule

PlacementRule

MatchingRule

CreateRule

PlacementRule

Subscriber Add ProcessorPublisher Add Processor

AddEvent?

AssociationProcessor Input

TransformationSchemaMapper

EventTransformation

PublisherFilter

SubscriberFilter

EventCache

XMLto

NDS

no

yes

no

yes

The DirXML Engine

CommandTransformation

CommandTransformation

demonstratiodemonstratio

•Rules in action

DirXML Links

• For the latest information on DirXML and drivers go tohttp://www.novell.com/products/nds/dirxml/

• For course schedules and registration information go tohttp://www.novell.com/education

• For boot camp registration information go tohttp://www.novell.com/registernow

Conclusion

Understanding XDS and the transformations

that can be performed via Rules will enable you to use DirXML to effectively share

data throughout the network