XML Document Rendering 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” 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. The prior builds B2B(Business to Business) systems based on this architecture and the latter B2C (Business to Customer). 2. “Web Server” or TransactXML process receives the request. TransactXML Server works independent of the transport mechanism. The request could come over a variety of network data sources. This is the Transport Abstraction:  Abstract Fact Web Server In many architectures, a web server already exists. Ports 80 and 443 are already in use on that machine, so if “web server pass through” was not supported it would force an additional machine to be added to the architecture. Since it is supported, you are free to do what makes the most sense for your situation. If you determine that your existing web server hardware can support the additional processing load of XML Document generation, your architecture will be simplified by implementing the XML Server as a backpage on your existing system because TransactXML is implemented in ISAPI for Apache and IIS. Stand Alone HTTP Server This option provides the best performance and a very simple configuration. A single process (TransactXML.exe ) does the same job as a web server, but more efficiently. TransactXML will act as its own HTTP server. 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 . The same logic can be used from within an entirely separate UBT product called DesignerXSL that loads compatible Language Drivers. 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.