DirXML 1.1: Synching With Style
Articles and Tips: article
Cheryl Walton
01 Oct 2001
By the time you read this article, DirXML 1.1 will be days away from availability, if it's not available already. Like its predecessor, DirXML 1.1 enables you to synchronize data between Novell eDirectory and other network directories based on your company's business rules and workflow policies. (To see how other companies are using DirXML, see "Novell Products in Action." For more information about DirXML, see "Too Many Directories? Synch 'Em With DirXML," Novell Connection, May 2000, pp. 8-14..)
DirXML 1.1 features several enhancements that enable you to do the following:
Run eDirectory and the DirXML engine on one server, an application on another server, and the application's DirXML driver on yet another server.
Log errors and warnings according to where they occur in the DirXML data-sharing process.
Create filters that are defined in both eXtensible Markup Language (XML) and eXtensible Stylesheet Language Transformations (XSLT). (XML and XSLT are World Wide Web Consortium [WC3] standards that describe how to create and change XML documents, respectively. For more information, visit www.w3.org/XML/1999/XML-in-10-points.)
Define exceptions to e-business rules automated through DirXML.
REMOTE LOADER FOR MORE FLEXIBILITY
DirXML 1.1 includes a new feature called the remote loader. The remote loader is agent software that enables communications between the DirXML engine and an application's DirXML driver that is running on another computer. These communications occur over a Secure Sockets Layer (SSL) connection, but to the DirXML engine, communications with the remote application driver appear to be local.
The remote loader offers several advantages, not the least of which is the flexibility to host applications and their drivers wherever you want. For example, suppose you are using DirXML to synchronize information between eDirectory and several other directories and databases on your company's network. Further suppose that you'd like to add your company's human resource management (HRM) application to this DirXML-controlled metadirectory. However, this application's API set (with which DirXML drivers communicate) does not support remote access.
If you were using DirXML 1.0, you would have to run your HRM application, its DirXML driver, the DirXML engine, and your company's eDirectory tree all on the same server. In contrast, if you were to use DirXML 1.1, you could run the DirXML engine and the eDirectory tree on one server, your HRM application on another server, and the HRM application's DirXML driver on yet another server.
In addition, these servers' platforms don't have to be the same. You could run the HRM application and its driver on Windows 2000 servers (perhaps the only platform on which this HRM application could run), but you might run the DirXML engine and your eDirectory tree on a Solaris server.
Among other things, this ability to run applications and drivers on any server you choose essentially extends eDirectory's platform support. For example, with the DirXML 1.1 remote loader, you can synchronize applications running on OS390 or Macintosh operating systems with eDirectory, despite the fact that eDirectory does not support these platforms. The remote loader, in other words, renders DirXML 1.1 essentially platform blind.
PER-FUNCTION ERROR LOGGING SAVES TIME
DirXML 1.1 enables you to log errors based on where in the process these errors may be occurring. Using DirXML 1.0, you have to search an aggregate error log and figure out for yourself where errors are occurring. DirXML 1.1 also logs errors according to where the errors occur--namely in the subscriber channel, the publisher channel, or the driver set. Basically, this new per-function logging feature saves you some time, enabling you to efficiently spot error trends, hone in on their causes, and identify solutions.
ADDITIONAL OPTIONS FOR DRIVER CONFIGURATION
DirXML 1.1 gives you additional options for configuring DirXML drivers, including the following:
Rule-chaining
Command transformation
New drivers
Rule-Chaining Simplifies the Process of Creating Filters
The rule-chaining option enables you to create filters (for DirXML drivers) that are defined in both XML and XSLT formats. Filters, as you may know, define the information flow between a particular application and eDirectory.
Using DirXML 1.0, a filter must be defined in either an XML or XSLT format, but the filter cannot be defined in both XML and XSLT. The standard DirXML rules that you combine to create a filter (which may include schema mapping, create, and data replacement rules) are defined in XML format. However, more complex rules generally require an XSLT format. Thus, if you are forced to develop more complex rules, you are also forced to create the entire filter using XSLT.
For example, suppose you need to create a filter that uses the standard DirXML create, event, and replacement rules, but you need a more complex schema-mapping rule. Using DirXML 1.0, you have to create a filter that uses an XSLT format. This XSLT format then transforms all of the rules--including the create, event, and replacement rules --rather than just the schema-mapping rule, which is in fact the only rule that requires XSLT.
With DirXML 1.1, you have another option: You can create a filter that includes an XML document containing the standard create, event, and replacement rules. This XML document can then call an XSLT document that defines the more complicated schema-mapping rule. Rule-chaining, in other words, simplifies the process of creating filters for DirXML drivers.
Command Transformation Takes Care of the Exceptions
The command transformation feature enables you to define exceptions to the rules that comprise a DirXML filter. For example, suppose you want DirXML 1.1 to push employees' home telephone numbers from your company's HRM application to its metadirectory tree. You then want to make this information available to users over the Internet via Novell eGuide, an application that can access and display directory-based information. You do have one problem: Some employees do not want their home telephone numbers listed.
To ensure that the home telephone numbers for these employees stay out of the metadirectory tree, and are therefore unavailable through eGuide, you can create a filter that pushes the home telephone numbers of all employees to eDirectory. You can then use the DirXML 1.1 command transformation feature to withhold the telephone numbers of employees who do not want their numbers listed.
More Good News About Drivers for DirXML
In addition to its new features, DirXML 1.1 ships with two new drivers, one for NT Domains and one for Delimited Text. DirXML 1.1 includes matching licenses for eDirectory and the NT Domains and Delimited Text drivers and for other drivers that ship with the product. Other shipping drivers include the following: eDirectory, Active Directory, Exchange, Lotus Notes, and LDAP-enabled directories.
On a related note, this past August, Novell released a new DirXML driver for PeopleSoft, which enables connectivity with the PeopleSoft 8.1 platform, as well as PeopleSoft 7.5 and 7.0. This driver works with any of the PeopleSoft modules, including its Finance and Education modules and its Human Resource module.
For more information about DirXML 1.1 and the new DirXML PeopleSoft driver, visit Novell's web site (www.novell.com/products/nds/dirxml).
Linda Kennard and Cheryl Walton work for Niche Associates, an agency that specializes in writing and editing technical documents. Niche Associates is located in Sandy, Utah. For more information about Niche Associates, visit http://www.niche-associates.com/.
Novell Products in Action
Finding out about the new features a product offers is great, but you probably also want to know which companies are using the product and how they are using it. The following explains, in a nutshell, how one company is using DirXML in conjunction with Novell eDirectory and ZENworks for Desktops. (DirXML is also used as part of Novell's eProvisioning Solution Framework. See "eProvisioning: Get Your Business in Hand.")
THE CLIENT
Allina Health System, a not-for-profit medical services provider
THE PROBLEM
Allina Health System needed to unify its various independent networks located throughout clinics, hospitals, and administration offices. The resulting unified network needed to provide cross-platform functionality, centralized management capabilities, and tight security.
THE TOOLS
-
Novell eDirectory
-
DirXML
-
ZENworks for Desktops
THE SOLUTION
The Allina Health System network is built on NetWare and Windows NT. To unify the separate directories of these two systems, Allina Health System turned to eDirectory and DirXML. By using DirXML, Allina Health System was able to unify directory information across eDirectory and Active Directory.
In addition, Allina Health System uses ZENworks for Desktops to streamline the installation, management, and support of more than 1,000 application profiles. As a result, help-desk calls have decreased by 50 percent. The number of PCs has grown by 57 percent--from 7,000 to 11,000 PCs--without requiring additional support staff.
THE RESPONSE
"Novell products offer the security, stability, and cross-platform management capability we must have to be successful in meeting our mission. With eDirectory, we have been able to build a directory that runs on any platform," says David Lind, Allina Health System director of information services.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.