Non-transactional – Adding an order

Now let's see how to add an order using non-transactional replication.

A company has three sites: OHIO, MICH, and CALIF. OHIO and MICH are on the same intranet, MIDWEST; CALIF is on a separate intranet, PACIFIC. A non-transactional replication rule exists from OHIO to target site CALIF for the Centralized Order Entry category, with an interval of “Immediate.” A similar rule exists from OHIO to target site MICH.

An OHIO user updates and saves an order line record in the OHIO database. When the record is saved, a SQL trigger copies the data to the coitem_mst_all table. (The coitem_mst_all table is included in the Centralized Order Entry category.)

Since order entry data is to be shared between sites, the system defined a replication trigger on the coitem_mst_all table. When the order line data is copied to the coitem_mst_all table in OHIO, the replication trigger fires. The replication trigger’s job is to take the updated data and initiate the process of sending that data to the sites that need it. MICH and CALIF both need the order line update. The replication trigger writes the updated data to a set of staging tables; separate rows are created for the data that needs to go to the MICH site and the data that needs to go to the CALIF site.

A set of replication services run on the application server. These are processes (which run as Windows services) that are responsible for packaging/delivering and receiving/processing replication updates.

There are two replication services:

  • Infor Framework Replicator is responsible for polling its intranet’s sites’ replication staging tables and packaging the data updates found in those tables into XML documents. These XML documents are then forwarded to the appropriate message queue, where they will be picked up and processed by the second service, Replication Queue Listener.
  • Infor Framework Replication Queue Listener has two jobs: delivering the replication XML documents to remote intranets, and processing incoming replication XML documents from remote intranets. The Replication Queue Listener has two separate queues, one for outgoing data deliveries and one for incoming data.

If the replication XML document is to be delivered to a site on a remote intranet, the Replicator service drops the document in the outgoing queue for the Replication Queue Listener service. If the document is to be delivered to a site on the local intranet, the Replicator service drops the document in the incoming queue for the Replication Queue Listener service. In our example, the replication update to CALIF will be placed in the MIDWEST Replication Queue Listener’s outgoing queue, and the replication update to MICH will be placed in the MIDWEST Replication Queue Listener’s incoming queue.

Delivery of replication XML documents to the remote PACIFIC intranet by the Replication Queue Listener is performed using HTTP. The replication XML document is delivered to the PACIFIC intranet’s URL (as defined in the data found in the OHIO site’s Intranets form) by means of an HTTP POST operation. The ASP page that receives this POST on the PACIFIC intranet places the posted XML document into the incoming queue for the PACIFIC Replication Queue Listener service. The PACIFIC Replication Queue Listener picks up the XML document and imports the incoming coitem_mst_all data into the CALIF site’s database.

The Replication Queue Listener for the MIDWEST intranet also accepts the incoming coitem_mst_all update and creates or updates the record in the MICH site’s database.

For more information about the services and queues mentioned in this example, see Replication behind the scenes.

For more information about the XML documents used in replication, see the Integrating IDOs with External Applications guide.