 |
|
|
|
|
|
|
|
|
| April 2001 | |
|
|
| DeveloperNet University Course | |
|
|
|
Introduction to DirXML Stylesheet Programming
Objective: After studying the concepts in this section, you should be able to construct and interpret simple stylesheets.
Important
You must understand how to interpret NDS.DTD for all of the projects in this section. If you feel weak on that topic, now would be a good time to review Analyzing NDS.DTD to Construct XDS Trees.
The purpose of this section is to enable a person who already understands NDS, basic DirXML configuration, and XML to write a simple stylesheet.
Any discussion about DirXML must, at some point, refer to an external system or directory that is to be hooked up to NDS with a DirXML driver. For the purposes of this discussion, this section makes references to a fictitious application called PBXSimulator that could use a DirXML driver to synchronize the phone numbers maintained in a PBX with User phone numbers in NDS. You don't really have to know much about PBXs or PBXSimulator to understand the section. Just understand that it is a simple example of an external system for DirXML.
Introducing Business Rules
Most real world environments will have unique requirements in how data and/or events are transferred between their external systems and NDS. These exceptions are called "business rules."
Let's use a couple of environmental considerations for PBXSimulator as an example of simple business rules.
You may have noticed that PBXSimulator allows only the '-' character to delimit groups of digits in its phone numbers. For managing phone account information inside of a PBX, this might be fine. But when that value is sent to NDS where it could be forwarded to many other special purpose directories, it is conceivable that one or two of them might require that different characters delimit their phone numbers.
For the purposes of this discussion, let's assume that the most common delimiter needed in a particular installation is the '.' character (dot). To solve this incompatibility, a simple business rule could be implemented stating that all phone numbers in the core directory must be delimited by dots.
To accommodate this business rule in PBXSimulator's DirXML driver, the hyphens in PBXSimulator's phone numbers must be converted to dots as they are sent to NDS.
We don't have to worry about the phone number coming back through PBXSimulator's Subscriber channel because the phone number isn't listed in the Subscriber's filter, so changes to the phone number won't even be seen by the engine on the Subscriber side. This was a conscious design decision to prevent the phone number from being changed by anyone but the PBX administrator. (This is an example of yet another business rule that was implemented by simple filter configuration.)
So the question is, how do we implement this hyphen/dot phone number business rule on the Publisher side.
"Easy", you say, "just program the translation from hyphens to dots into the driver's Publisher shim?"
Well, that would work. However, if PBXSimulator were a real product, we might want to distribute its driver into other business environments, some of which might require a different delimiter than either dots or hyphens. Coding the business rule into a shim (a compiled executable) implements the rule for every installation.
What we really need is a flexible way to implement the business rule, allowing the use of whatever delimiter may be required at a given installation if and when implementation is necessary.
DirXML Stylesheets Implement Business Rules and Perform XDS Data Format Conversions
The flexible solution for implementing business rules is usually a stylesheet. Stylesheet programming is different from the code in shims in that stylesheet code is not compiled. Instead, stylesheet programs are composed using a language called the Extensible Stylesheet Language Transformation Language (XSLT) that is interpreted by XSLT processors to manipulate/construct XML documents. Since XSLT is interpreted, this means that the administrator can modify stylesheets as needed for each installation without having to rebuild/recompile the driver.
Stylesheets provide programmatic access to XDS (DirXML's XML vocabulary for communicating directory information) documents as they travel along from the Publisher shim to the DirXML engine or from the engine to the Subscriber shim. Stylesheets implement the unique business rules for the environment by adding, deleting, or modifying nodes in these documents.
Figure 1: The flow of XDS on the Publisher and Subscriber sides.
There are four usages of stylesheets shown in Figure 1 (stylesheets may also be used to replace any rule).
- The input stylesheet has two main tasks. The first task will always be to implement data specific business rules such as the phone number requirement described above. Whether or not the stylesheet has a second task depends on the version of XML outputted by the Publisher shim. If the shim outputs a non-XDS version of XML, then the stylesheet's second task is to translate that XML into XDS.
The output of the Publisher shim should always be some form of XML. The form of XML outputted by the shim depends on the way the shim was designed. It is mainly a balance between convenience and flexibility. In the simplest case, if the external system already outputs in XML, the shim could implement the most flexible transformation possible by simply outputting the external system's XML documents directly so that they can be applied to the input stylesheet.
This is most efficient because the XSLT processor already works with XML and with the help of an appropriate stylesheet, it can transform the external application's XML documents to XDS quite handily.
The flexibility benefit becomes evident later if changes are needed in the directory data models being synchronized by the driver. The XSLT and XPath in the stylesheet can be modified to accommodate these changes without needing to be recompiled.
If the external system is not XML conversant (as is the case in PBXSimulator), the transformation from the system's event information can only be performed in the Publisher shim using the DOM APIs standardized by the World Wide Web Consortium (see http://www.w3.org/ for more information on DOM). In this scenario, the input stylesheet's only task is that of implementing data-oriented business rules. And if there are no data-oriented business rules on the Publisher side, then there is no need for an input stylesheet.
- After the mapping rule has mapped the external system's attribute and class names to NDS attribute and class names, the engine will send the resulting XDS document to the Event Transformation stylesheet (if one is associated with the Publisher side). Here the administrator has a chance to add stylesheet logic to modify the event elements in the XDS documents.
For example, recall that the PBXSimulator driver currently deletes corresponding NDS objects when one of its accounts is deleted. A PBX being allowed to delete User objects from an enterprise's core directory would be a very unusual behavior in a real world environment.
More likely, the administrator would write some code in the Publisher's Event Transformation stylesheet that would capture XDS elements describing PBX account delete events.The stylesheet would convert the delete elements to XDS elements to remove the driver's association to the NDS object and then delete the NDS object's current 'Telephone Number' attribute values.
A later lab in this section will have you program this very task into an Event Transformation stylesheet for the Publisher.
- Events coming from NDS to the Subscriber side are already expressed in XDS, so Event Transformation business rules capturing NDS events and modifying them for the external system can be invoked right away.
- The output stylesheet is like the input stylesheet in that it has two tasks. The first one, like the input stylesheet, is to implement any business rules applying to the data being sent from NDS to the external system.
The second is only needed if the external system understands XML. If it does, then the output stylesheet could transform the XDS event information from NDS to the external system's native XML vocabulary. The Subscriber shim can then pass that XML directly to the external system without having to perform any of the transformation in its compiled code. This is the most flexible way to perform the transformation for the same reasons as those described in item 1.
However, if the external system does not understand XML, then the output transformation should be performed in the Subscriber shim's code where DOM APIs can be mixed with external system APIs to achieve the most efficient integration possible in that scenario.
|
|||||||||||||||
