Successful DirXML Synchronization
Articles and Tips: qna
01 Nov 2001
Q.
One of the consultants at my company uncovered this issue in a client's lab and forwarded the Technical Information Document on to me. We are both working on large scale DirXML projects with implementations slated for this month. We recommended placing all Read/Write (RW) replicas on the DirXML servers. We have seen moves go through sporadically when there is a RW on the server, and all of the time when there is a Master on the server.
Has anyone run into this issue? Is there a fix? I still need to perform further testing, but any advanced help would be great.
DirXMLing in Daytona Beach
A.
Dear DirXMLing: You are right about TID #10060809 stating that sometimes you will get a
-631 error moving objects via DirXML
error message. This can happen when using DirXML to synchronize two eDirectory trees--every object move will return the -631 error. This is cause by DirXML requiring the Master replica to reside on the same server as the DirXML engine.
The quick fix is to change the replicas on the DirXML server to be Masters. In greater detail, with DirXML 1.0, moves will fail unless you are running the driver on the master of both the source and destination container. This issue was addressed in DirXML 1.1, but not completely. Until it is completely resolved, you will need to use the Move Proxy Driver that is available at Novell's Web site, http://www.novell.com. Below is a summary of what the driver does:
The Move Proxy driver was designed as a means of getting around the current DirXML limitation that prevents move operations from occurring through DirXML, unless the server running the DirXML driver holds the master replica of the source object and the destination container.
The Move Proxy monitors events that add a value to a new attribute. The Subscriber Event Transformation Rule looks for a modify event that adds a value to the moveProxyTrigger attribute. The Rule then converts it to a custom event that contains the DN of the object to be moved and the DN of the container to move it to. All other events are blocked.
The Output Transformation looks for the custom event generated by the Event Transformation Rule and converts it to a delimited text record containing the relevant DNs. This record is written to a file by the flat file driver subscriber channel.
The flat file driver publisher channel monitors the same directory and extension that the subscriber writes, so it picks up the files written by it's own subscriber.
The Input Transformation converts the delimited text record to a move operation and removes the value from the moveProxyTrigger.
You may wonder if this can be achieved without using the flat file driver, since this would add more complexity to the design. Yes, just keep all the masters on one server, which gets even more complicated because you have more than one driver per tree. So how would you handle moves between the US and UK? With great difficulty.
The best shot you have is to have a single driver per tree and either place the master on that server or use the Move Proxy. Having multiple drivers per tree makes it almost impossible to complete all moves (specifically between the different GEOs).
* Originally published in Novell AppNotes
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.