Building high performance QAD interface

Building real time, high performance, robust interface to QAD system is popular topic these days. And this is not a simple task as it may seem at glance. QAD users are considering CIM solutions, Qxtend, ODBC and other 3rd party software solutions.

QAD’s Qxtend is an enterprise platform, designed to process ANY type of messages and formats, both inbound and outbound. Main emphasis is done on the ability to conform variety of standards and formats and therefore qxtend has many layers in its architecture. The complexity of design justifies the purpose, however performance suffers.

Performance bottlenecks for qxtend:

1) JAVA – underlying platform. It is known being slow. Can be optimized in java start up options.

2) Application server, Jakarta Tomcat. Can be optimized in start up parameters.

3) XML parser. Avoid XML format for performance sake, if possible.

People often talk and think that XML message is the best invention for system interactivity. This is one side of the coin only.  XML parser is slows, the processing speed is the cost you pay for the convenience XML brings. Also, one needs to know that systems based on XML formats are also very picky on the data values, encapsulated into XML messages. Such system may fail with one transaction and it’s very hard to troubleshoot why it does so. Whereas, another very similar transaction would work just fine. Folks who has experience with XML, know that data should be sanitized prior to encapsulated into XML and after transmission it should be de-sanitized, i.e. this way you are adding a couple more layers into your architecture – which cost you more processing time.

If the performance and robustness that you are looking for, but you do not need the variety of formats qxtend offers, TCP/IP socket solutions are worth considering as an option. Such interface has much less layers, bare minimum, and so latency in data processing.

Socket solutions