You can run TDXM in two modes: batch mode and UI mode. In this chapter we are describing batch mode processing.
TDXMPP should be started with parameters:
TDXMPP.exe <config_XML> <input_XML> <output_XML> <log_XML>
config_XML – path and name of configuration XML file
input_XML - path and name of input XML file
output_XML - path and name of output XML file
Log_XML - path and name of log/debug XML file (it is optional)
Sample *.bat file (in this case for RFS database):
cd bin TDXMPP.exe ..\TDXMXMLConf.xml ..\input\RFS_01.xml ..\output\outRFS_01.xml ..\output\logRFS_01.xml
TDXM Input Node serves the purpose of specification and processing needed to establish and maintain a connection between TDXM and external world. TDXM could consume data in any XML format. It depends on configuration and on XSL files used to transformation. With installation of TDXM you get XSL files to work with data in FI2002 format or in FI2 v. 1.22 format.
Input node verifies input information and prepare it for processing by next TDXM nodes, trying to make their task simpler and more predictable.
The scope of operation of TDXM Input Node may be loosely defined as actions that we have reasons to do after receiving an XML input file from potentially distrusted source and before we do anything that may require access to output domain.
TDXM Domains Node serves the purpose of handling objects’ identity in the context of potentially multiple naming domains. We will have to translate objects descriptions between supported domains. Then, if TOBIS support is available, we must verify objects’ identity using registered records or perform new registrations. The resulting output XML file should contain objects descriptions with additional data, like GUID, target domain IDs or delayed registration requests, that will facilitate performing functions by next TDXM nodes.
The scope of operation of TDXM Domains Processing Node may be loosely defined as actions that we have reasons to do after receiving an XML input file initially prepared and verified by TDXM Input Preparation Node and before we do anything that may require access to target HyperDoc database.
TDXM Objects Matching Node takes over processing after everything that can be done using just input data and (optionally) TOBIS database has been achieved. Now we must access target HyperDoc database in order to perform the final verification of objects matching and to handle the unmatched objects manually. Then, if TOBIS support is available, we must perform target domain registrations or prepare delayed registrations to be done conditionally by the next processing step. The resulting output XML file should contain complete and verified objects descriptions ready for straightforward updating of target HyperDoc database by the next TDXM nodes.
The scope of operation of TDXM Objects Matching Node may be loosely defined as actions that we have reasons to do after receiving an XML file enhanced by TDXM Domains Processing Node and before we actually perform updating of HyperDoc database.
TDXM Database Update Node performs the update of target HyperDoc database using XML data fully prepared by the preceding TDXM nodes. Now we must perform update operations specific for various objects (geometry, linking) and documents (versions, document files). Then, if TOBIS support is available, we must perform target domain registrations and delayed registrations in other domains forwarded from previous processing steps (pending final update success).
The scope of operation of TDXM Database Update Node may be loosely defined as actions needed to make use of XML data prepared by TDXM Objects Matching Node (and all preceding nodes) to perform update of target HyperDoc database.
