Implementing In-Memory Latching By Conor Brankin

---

Introduction

Integrations using the Enterprise Server are often used for synchronization of data across disparate applications. The classic example of synchronization is the ordering system and warehouse system scenario.

In this scenario, an order is placed into an ordering application. This may be an order entered over the Internet using a web application, or the retailer’s personnel may have entered it into the ordering system. In either case, a record is entered into one or more database tables in the order entry application. The data from this order is synchronized with the warehousing system using a canonical document, a.k.a. UDM, which is subscribed to by the warehouse adapter.

The situation may arise whereby a change to that order may be made in the ordering system or the warehouse system, hence requiring bi-directional synchronization of a single order across the two systems. Bi-directional synchronization requires the use of latches to ensure echo suppression. The Cross Reference table provides a mechanism to implement echo suppression.

However, this implementation is rather heavyweight and slow for applications that use a single adapter process for each resource. In-memory latching provides an alternative for better performance and enhanced throughput.

---

Latching Overview

Consider the scenario shown in Figure 1, which does not use latching. If the customer table is updated on the order application, this is the order of events:

1. A notification is fired.
2. The UDM document is published.
3. The warehouse adapter subscribes to the UDM, and the customer table in the warehouse is updated.
4. Our application requires bi-directional synchronization; therefore, an update notification configured operation built using the customer table in the warehouse application, fires when the update is performed.
5. This causes the UDM to be published.
6. The UDM is subscribed to by the order adapter, which causes an update to be performed in the order application.
7. This causes the notification configured operation to fire in the order application.
8. We return to the start of the integration again.

Implementing a bi-directional synchronization without latching causes a never-ending loop to occur every time an update is performed.

Figure 1

To prevent this looping behavior, webMethods provides a mechanism for echo suppression using the cross-reference table, ATC_XREF. Figure 2 illustrates how echo suppression is achieved using the ATC_XREF table.

---

When the customer table is updated on the order application side using echo suppression, this is the order of events:

1. A notification is fired.
2. The UDM document is published.
3. Using a common operation, the warehouse adapter accesses the ATC_XREF table and sets the latch_closed column to TRUE.
4. The warehouse adapter then performs the update in the warehouse application.
5. As in the previous scenario, the notification configured operation in the warehouse fires.
6. The warehouse adapter checks the status of the latch_closed column in the ATC_XREF table.
7. The latch_closed column is, of course, set to TRUE. The warehouse adapter resets the latch_closed column to FALSE and stops, i.e., no documents are published from the warehouse adapter.

Figure 2

Closer scrutiny of Figure 2 shows that this latching requires a lot of messages to be published and delivered using the Broker. The messaging associated with latching can slow integrations down dramatically and can cause the Broker to become unnecessarily burdened with additional load.

To improve the performance of bi-directional synchronization and assist in decreasing the load on the Broker, you might consider using in-memory latching.

---

Standard Latching

Figures 3 and 4 show two standard common operations that could be used for utilizing the ATC_XREF table for latching. It is not the intention of this article to regurgitate the documentation on the use of the ATC_XREF table. However an understanding of the capabilities of the standard latching functionality is required to fully appreciate the capabilities (and shortcomings) of an in-memory implementation.

Figure 3

When a source integration component sends the UDM document, the target adapter receives the document. The target adapter calls the customerTgt common operation (Figure 4) and sets the latch_closed column in the ATC_XREF table to TRUE. A separate integration component in the same adapter calls the customerSrc common operation (Figure 3), which checks the status of the latch_closed column and returns a Boolean indicating if the adapter should send a UDM or not.

Figure 4

An example for using the ATC_XREF table for latching is provided in the "Standard" integration folder of the provided sample.

---

[1]  2  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums