This document describes the XML Document rendering process. It is intended to give a high level overview of the basic processing logic within the TransactXML Server. The intended audience is expected to understand common internet technologies and terms.
View inside the TransactXML Server as a “Black Box” Process
|This document describes the XML Document rendering process. It is intended to give a high level overview of the basic processing logic within the TransactXML Server. The intended audience is expected to understand common internet technologies and terms.View inside the TransactXML Server as a “Black Box” ProcessEach number is explained below, the sequence of a TransactXML transaction
1. Initiating process issues a request for an XML Document.
The initiating process may be a component in your server or it may be post data directly from a web browser.
2. “Web Server” or TransactXML process receives the request.
TransactXML Server works independent of the transport mechanism.
3. POST data is made available to the TransactXML Server.
Step 2 received a request to generate an XML Document. Now the request is passed onto the TransactXML Server. If you use a web server from step 2, then the server passes the request into a CGI or ISAPI process that contains TransactXML Server. The Stand Alone Server services the request within the same process.
4. The XML Document rendering rules are loaded.
A rule script file (actually an XML document published by DesignerXML) that describes all aspects of the XML Document is loaded into memory. The first request for any document type causes the script file to become cached so that subsequent requests for the same document type are serviced more quickly as they skip this step.
5. A Data Source Driver is selected as specified in the script file.
The rule script specifies where an XML document should obtain its raw data from. A driver is loaded into the same process space as the server. Data Source Drivers are implemented as .DLL’s in NT and as shared libs in UNIX. The Data Source Driver is conceptually the same as ODBC. This is the Data Abstraction. Abstract Fact
6. The Data Source Driver makes the actual request for data.
Data Source Drivers are compiled binaries that know how to retrieve information directly from the data source. DB2 and Oracle implementations link directly with the DBMS kernel libraries, limiting any performance bottlenecks to the implementation of the driver or the data source.
UBT has implemented native drivers for Oracle, MS SQL Server, and MS Access, DB2, MySQL, and PostgreSQL for many common platforms as well as a shell driver that uses ODBC to get the data – enabling any existing ODBC driver to load from within this shell driver under Windows platforms.
A Data Source driver development kit is owned by UBT and will be licensed at will upon agreeable terms of implementation. In most cases the data source is a DBMS so that most customers won’t need this SDK. Custom drivers can be built for all types of data sources including real time controllers or any machine capable of producing data.
7. The raw data is returned from the data source to the TransactXML Server.
The rule script specifies how to convert from a Row/Column data structure to an XML Document. Any formatting commands in the script file are applied to the data before it’s added to the XML Document.
8. The element values are further manipulated or obtained through Language Drivers.
TransactXML Server has the most common tasks of data manipulation ‘built in’ and were applied in step 7. Additionally, C/C++ Library, Java, Perl, or Python can be used to further customize the data, or to supply a ‘branch’ of XML that will be grafted into the final XML Document. To provide the ultimate in extendibility, Application Drivers can be made to host a standard script processor or can be a direct application extension into an existing information system. A language driver development kit is owned by UBT is licensed freely for all uses. This is the Language Abstraction Abstract Fact
9. The XML Document is Transformed according to the Stylesheet, if applied.
A rule script may specify one or more transformations that can be applied to the XML Document. The request from step 1 specifies which Transformation/View, if any, should be applied to the XML document. A typical transformation renders an HTML document that displays the XML Document in a clear human readable format. Transformations can also be used to convert the XML to EDI, RTF, or PDF according to the XSLT. TransactXML retains “Multiple views of the same XML Document”, so that you may view an HTML page and create a business document from the same real-time data, simplifying transactional integrity. Our XSLT implementation is built over the Apache Xerces XML Parser.
10. The rendered XML Document is returned to the calling process.
The Internal flow within the ‘black box’ is important to understand when considering scalability and security, however when building an information system based on this ‘black box’ component – all that’s important to keep in mind is step 1 and step 10. Any language or development environment capable of issuing an HTTP POST can drive the server to render XML documents.
© 2015 United Business Technologies, Inc. All Rights Reserved.