Improving Upon wm.tn:receive By Sonam Chauhan

---

Introduction

The webMethods Integration Server (IS) is an excellent product for business-to-business document exchange. It is often implemented along with its optional Trading Networks (TN) component to offer solid RDBMS-backed reliability and transaction monitoring.

As discussed in Phillip Leary's article in this issue of the webMethods Ezine, a key advantage of TN is that it provides a single point of entry for documents entering a system. This "Universal Document Entry Point" is actually a TN service -- wm.tn:receive.

As this article discusses, however, the webMethods-advised approach of submitting documents to wm.tn:receive has serious drawbacks. This article discusses them and provides an alternate solution."

---

Problems with wm.tn:receive

Problem #1 -- TN Has No Concept of a Marketplaces or VAN

Documents are often received from an entity acting on behalf of multiple trading partners. An example of this is purchase orders originating from different buyers but routed through the same Marketplace or Value Added Network (VAN) provider. Because webMethods has no concept of Marketplaces or VANs, the sender cannot be properly identified -- Trading Networks profiles represent end-parties only.

The webMethod Implementation Manual requires that each TN profile have a corresponding username and password for IS. In this model, the IS account username is set to the primary Trading Networks ID of the partner (usually a DUNS number).

It follows that a proper authentication of an inbound VAN document will fail if the inbound document's originator is not equal to the IS username assigned to the Trading Networks profile. To work around this problem, a VAN would need to supply different authentication credentials for each document that it submits to wm.tn:receive. Enforcing this behavior is quite impractical.

Problem #2 -- TN Returns a Failure Status on Failed Processing

A major flaw with wm.tn:receive is that the service will return a "success" status even if the document was not properly processed within Trading Networks. For example, if a purchase order was submitted via HTTP to wm.tn:receive, but TN did not recognize the doctype, the service will still return a HTTP Status Code of "200 OK" to the document sender.

Because trading partners commonly depend upon the HTTP Status Code to determine if a document was successfully submitted, this is a major inconvenience -- a separate process must be setup for detecting processing errors and reconciling documents with the sender.

Problem #3 -- Vendor Service Exposed

Principles of robust system-building state that a vendor-provided service like wm.tn:receive should never be exposed directly to a user. At the very least, a simple wrapper service should be written that invokes the vendor service internally.

---

The Importance of "Sender Verification"

Recent versions of wm.tn:receive implement a basic and effective security measure that I call "Sender Verification".

Sender Verification works like this: when wm.tn:receive receives a document from a partner, it first checks whether the document sender and the IS user submitting the document are the same entity. In other words, before introducing the inbound document to Trading Networks, IS will verify that both the following represent the same Trading Networks profile

1. The sender specified within the document
2. The logged-in IS user submitting the document

At first glance, it seems bizarre and useless for a trading partner to identify itself wrongly -- one may very well think "what use is 'Sender Verification'"? However, Sender Verification will prevent authorized trading partners from exploiting your system.

To see how, consider the following: Assume that you are a supplier called "A". You receive purchase order documents from buyer "B" and also send "B" invoice documents. Without Sender Verification, the malicious buyer "X" could post a XML invoice to Trading Networks from you (Supplier A) to Buyer "B".

If malicious buyer "X" is successful, upon parsing the XML document, Trading Networks determines it to be an invoice with sender = "A" and receiver = "B". The proper TN routing rules are fired for this scenario and the fake outbound invoice is delivered to "B" using your digital certificate as authentication! Of course, the fake invoice also contained wire transfer payment instructions to malicious buyer "X"'s overseas account.

So, any service emulating or replacing wm.tn:receive must replicate its Sender Verification functionality.

---

[1]  2  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums