|
| > Online Courses > Introduction to DirXML
|
|
|
External Data Conversion
It is possible that your external data source (a database or application) may not have XML as its native data format. This data will have to be converted to XML before passing it on to the DirXML engine. Below are a few common problems addressed by DirXML.
Schema Mapping
What if your application or external data source supports different ways of expressing data than what is currently available in eDirectory? How can you account for this discrepancy? DirXML and eDirectory provide a solution called schema mapping. DirXML gives you the flexibility to map objects and properties, one to one, between your application and eDirectory. An added bonus is that the same rules can be used for both the publisher and subscriber.
Figure 4, shows the properties page of a mapping rule in ConsoleOne. This is viewed from the DirXML snap-in, specifically designed for ConsoleOne. Following is a sample listing of the XML code used to do this mapping.
Figure 4: Properties page of a Mapping rule in ConsoleOne.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<attr-name-map>
<class-name>
<nds-name>User</nds-name>
<app-name>System User</app-name>
</class-name>
<attr-name classname="User">
<nds-name>Given Name</nds-name>
<app-name>First Name</app-name>
</attr-name>
<attr-name classname="User">
<nds-name>Surname</nds-name>
<app-name>Last Name</app-name>
</attr-name>
<attr-name classname="User">
<nds-name>Telephone Number</nds-name>
<app-name>Phone</app-name>
</attr-name>
<attr-name classname="User">
<nds-name>L</nds-name>
<app-name>Location</app-name>
</attr-name>
</attr-name-map>
Object Mapping
Different computing systems have different ways of identifying the same object. Naming schemes may be different, properties of similar objects may be different. Figure 5 illustrates how the same user can be identified as a number on one system, while being identified as an e-mail address on another. eDirectory also identifies the user uniquely.
eDirectory uses what is called an Association Attribute keep track of this information. DirXML stores the unique identifier for each system in eDirectory. This way eDiectory can keep track of all of the similar objects. There is no need to have a unique ID across all systems. Also, objects can be mapped regardless of hierarchy.
Figure 5: Object mapping in eDirectory.
The following DirXML rules can be used to perform object mapping in eDirectory.
The Matching Rule
Figure 6 shows the screen for invoking the editing of the matching rule in ConsoleOne. The Matching rule determines the criteria for finding a match, which must have a unique result. In addition, multiple matches results in an error meaning the matching criteria was too vague. You will need to refine the matching rule for it to work properly. Below is sample XML code for a matching rule. Note that is matching a username with an employee ID.
Figure 6: Matching Rule Editing Window.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<matching-rules>
<matching-rule>
<match-class class-name="User"/>
<match-attr attr-name="Emp ID"/>
</matching-rule>
<matching-rule>
<match-class class-name="User"/>
<match-attr attr-name="Surname"/>
<match-attr attr-name="Given Name"/>
<match-attr attr-name="Telephone Number"/>
</matching-rule>
</matching-rules>
The Create Rule
The Creation Rule determines the set of required attributes needed to create an object. It will veto the create if the required attributes are not present. However, default values can be specified. Figure 7 shows the Create Rule Edit window, in ConsoleOne. The following XML code demonstrates how to create a user object, complete with attributes of CN, Surname, and L. Note that all of these are required attributes.
Figure 7: The Create Rule edit window.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<create-rules>
<create-rule class-name="User">
<required-attr attr-name="CN"/>
<required-attr attr-name="Surname"/>
<required-attr attr-name="L">
<value>Provo</value>
</required-attr>
</create-rule>
</create-rules>
The Placement Rule
The Placement Rule determines the criteria for placement of the new object. The criteria for this can be based on class, attribute or path. Figure 8 shows the Placement Rule Edit window as presented in ConsoleOne. The following sample XML code illustrates how to implement a placement rule.
Figure 8: The Placement Rule edit window.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<placement-rules src-dn-format="slash"
dest-dn-format="slash">
<placement-rule>
<match-attr attr-name="L">
<value>Provo</value>
</match-attr>
<placement>
\TREE\novell\Provo\<copy-name/>
</placement>
</placement-rule>
<placement-rule>
<match-attr attr-name="L">
<value>Orem</value>
</match-attr>
<placement>
\TREE\novell\Orem\<copy-name/>
</placement>
</placement-rule>
<placement-rule>
<placement>\TREE\novell\<copy-name/></placement>
</placement-rule>
</placement-rules>
Data Flow through DirXML Driver
Figure 9 shows the overall data flow from application to eDirectory and back again using the magic of DirXML. Starting at the bottom left, an event that you would like to track occurs (App event). This is trapped and transformed to XLM in what is referred to as Application Native Format or (ANF) formatted XML. This is then passed to the DirXML Join engine where the ANF is converted to information that eDirectory can understand (ANF to NDS) and then formatted to NDS compatible XML (NDS formatted XML).
Figure 9: Figure of overall data flow.
The converse happens when a tracked eDirectory event occurs. Following the top part of Figure 9, starting in the upper right-hand corner, a NDS event occurs (NDS event). This causes the data of the event to be changed into (NDS formatted XML) by the DirXML engine. Next the DirXML Join Engine converts the NDS formatted XML to ANF XML in preparation to send to the application. Lastly the ANF formatted XML is sent to the application via the custom DirXML driver.
Figures 10 and 11 detail the data path for both the Publisher and Subscriber respectively. It is important to realize that when NDS initializes, it reads the event filter that you have set up, registers your custom DirXML driver for the appropriate events that you want to track, also setting up a cache for these events. NDS then notifies the DirXML engine when an event occurs. The DirXML engine reads all the rules you have set up for the subscription shim of your driver (event transformations, matching, placement, create, mapping, and output style) and sends the data to your subscription shim.
Figure 10: Building associations through the Publisher.
Referring in more detail to Figure 10, the Publisher portion of the driver performs the gathering and sending of updates from the external database/application to NDS. The following tasks are driver implementation specific:
- Changes. The driver needs to be informed of changes to the information in the external database.
- Filtering. Once the driver has gathered the changed information, it should filter it to the correct set of data so that data that isn't being shared is not sent to NDS. If your driver doesn't filter the data, NDS will filter and discard the data that doesn't apply.
- Converting. The driver needs to convert the data from the application's native format (ANF) to XML format and then send the data to the DirXML engine.
- Sending. The driver then sends the data to the DirXML engine and then waits until a response is returned.
Figure 11: Building associations through the Subscriber.
Referring to Figure 11, the Subscriber portion of the driver is responsible for the following tasks:
- Data Conversion. The driver needs to supply a method for converting the XML data to a format that the external application can use. This tool kit includes the nds.dtd file which contains the supported formats for input and output commands and DTDs for the rules (matching, creation, placement, and mapping). The ConsoleOne snapin makes all of these items available for configuration by the system administrator, but they can also be used by the driver developer. You have the flexibility to use input and output style sheets to help in the conversion. If possible, all data conversion should be handled in rules and style sheets because these can be modified to match a particular implementation of the external application. If the driver handles the data conversion, modifications to the process require recompiling the driver.
- Event Transform Rules. The event transform rules are designed to change an XML command (such as delete) to another XML command (such as remove-association). As such, this functionality is available to the system administrator through the ConsoleOne snapin. But this rule can also be used to change an XML command into another type of command understood by your application. When this happens, the command is sent directly to the mapping routine of the DirXML engine and is passed to the driver.
- Data Sending. The driver needs to use the interface of the external application to send the data to the application. The driver should wait until a response is returned.
- Response Handling. The driver needs to convert the response from the application into an XLM document and return it to the DirXML engine.
Object Data Transformation
Applications, by nature, have different ways to represent data. For example, one application will store dates in the format of 15.2.1965 compared to another application storing a date in the format of 2/15/65. The DirXML engine in conjunction with eDirectory has the ability of transforming data from one application to another. Figure 16 shows two applications, an Human Resources (HR) database and an e-mail server. Both applications store the same date in different formats. In this example, data can be read from the HR database, transformed into an eDirectory acceptable format (DirXML Driver), to be stored in eDirectory. Where upon it is read and transformed into a compatible format for the e-mail server (DirXML driver).
DirXML allows data to be transformed to a canonical format, which is stored in eDirectory. In order to do this, an XSLT stylesheet needs to be created.
Figure 12: The transformation of data from external HR data source to eDirectory then on to Email source.
Object Event Transformation
DirXML is very function when it comes to modifying an object to be the way you desire it to be. For example, in Figure 13, an event in your eDirectory tree may need to be transformed, such as deleting a user when they leave your company. DirXML allows changes made to the eDirectory tree to be transformed to perform other operations. In our example, when you delete user Bobby from eDirectory, Bobby's e-mail account is automatically disabled on the corporate e-mail server. This, too, requires that an XSLT stylesheet be created to make this functionality happen.
Figure 13: The Event transformation: an object is deleted from eDirectory and transformed to a disable in the external HR data source.
 |
|
