In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   On Demand  |   Home  |   qad.com




The QXO Outbound Process
Creating QDocs from extracted QAD Enterprise Applications data is accomplished in several steps. Each step is defined in—and can be monitored in—the QXO administration interface.

Basic QXO Architecture
The steps for data include the following:
1
A change occurs to watched data in QAD Enterprise Applications. Change notifications are written out to the qxevents database.
Note: DDP business objects are passed directly from the source application to the qxodb database in QXO, then processed by the message publisher.
2
QXO queries QAD Enterprise Applications for the changed records.
3
The extracted data is published as QDocs.
4
The QDocs are delivered to the assigned subscribers.
Taking each step in turn, the product architecture and implementation requirements become clear. Refer to Basic QXO Architecture to see product architecture and data flow through QAD QXtend.
Change to Watched Data in QAD Enterprise Applications
Data becomes watched when you install and then activate replication triggers on the tables for a given business object. In order to avoid performance overhead, the triggers are simple: they write out a notification of a changed record to a side database, qxevents. A change is any add, modify, or delete to these tables.
The triggers required for supported QXO business objects are shipped and installed with the product. However, even unused triggers, if active, create a small performance overhead. Therefore, each implementation determines which triggers are activated.
Triggers are not required for DDP business objects since the entire business object is passed directly to QXO—it is not necessary to watch event data for these objects.
QXO Queries QAD Enterprise Applications
QXO uses an event service to connect to the qxevents database and poll for change notifications, using either the table rowid or a unique identifier field on the database table to identify where changes occurred. When it encounters a change record, the event service queries the QAD Enterprise Applications tables that make up the impacted business objects in QXO.
For business objects that employ DDP an event service is not required since these business objects are passed directly to the qxodb database in QXO, and from there processed as usual.
One table can be a component of multiple business objects. For example, the customer master, cm_mstr, is a component of the customer, customer item, and sales order business objects, among others. Depending on setup, queries can be for the full business object, or only for the primary index fields and any changed field data.
No query against QAD Enterprise Applications is run when:
No valid or active business object exists for the changed data.
No active profiles exist for the data.
No active subscribers request this data.
The event service writes the extracted data to the QXO database.
Publishing the Data
Next, the message publisher generates one or more QDocs using the profiles as templates and stores the QDocs in qxodb. The QDocs generated are XML documents in proprietary QAD format. The SOAP-compliant container—an envelope, a header, and a footer—in which the QDoc is wrapped by the message sender (if the subscriber is thus configured) allows the QDoc to be sent to Web services that accept or poll for XML documents.
When publishing multiple profile messages from the same business object instance, the Message Publisher processes the messages in alphabetical order so that the sequence can be easily managed by the user.
Delivering the Data
The QDocs can be delivered to a directory location where the subscriber polls for and picks up new QDocs. Alternately, the QDocs can be delivered to a Web service listening for new QDocs through a URL (Universal Resource Locator).
The subscriber can be another QAD Enterprise Applications instance, another QAD product, or a third-party application or messaging broker set up to receive and interpret QDocs. QDocs moving between QAD products start as outbound QDocs and are picked up by QAD QXtend Inbound.