Adding Dynamic Processing Logic to Trading Networks By Phillip Leary

---

Abstract

Trading Networks (TN) is a webMethods application providing three primary functions to Integration Server users: central management of trading partners; the creation, storage and use of document types; and intelligent processing of business documents.

This article focuses on the last of these (intelligent processing) and describes a way to enhance TN with custom processing logic. While TN allows for the creation of very specific document types and powerful processing rules, these doc types and rules are static and apply to incoming documents in the same way every time.

In situations where dynamic routing is required, a little-used feature of the TN business document structure can be employed to enhance the standard approach.

---

Trading Networks Overview

Prior to the release of Trading Networks, the webMethods Integration Server (then known as the B2B server) was a developer's dream and an administrator's nightmare. The functionality of the B2B server was very powerful, allowing for the rapid development and release of integration services. It sliced, it diced, and it made connecting trading partners and exchanging business documents very easy.

However, with that ease came complications: as more and more services and partners were added, webMethods administrators faced increasing complexity in handling security, document storage, and partner management. All B2B server implementations eventually came up against the same needs: a single entry point for all partners, central management of trading partner information, and mechanism for storing business documents to a database.

webMethods answered these recurring issues with the release of Trading Networks, a packaged application for the Integration Server which came with a single point-of-entry (the wm.tn:receive service), a client GUI for managing partners, document types and processing rules (the TN console), and a repository for storing incoming business documents (the built-in Cloudscape repository or the external DB of choice.)

In addition to these core capabilities, TN functionality also extends to transaction analysis, conversation management, web browser access, and a variety of other powerful features.

Users of TN must perform a number of initial steps prior to using the application, including installation, repository configuration, partner profile setup, document type creation, and the definition of processing rules.

Installation is straightforward and performed through two install wizards, once for the console and the other for the server. By default, a Cloudscape database is installed and configured at the time of installation.

Next, a local trading partner profile must be defined for the TN server. Trading partner profiles are a collection of information describing the company, primary contacts, connection information, and security settings. Profiles are defined for both the local server, as well as for any other partners brought into the trading network.

After defining profiles, TN administrators define document attributes, which represent important data to be extracted from incoming business documents. TN has a number of system-defined document attributes, and TN administrators may define additional custom document attributes as well.

With document attributes defined, document types represent a way to handle incoming business documents and typically define how to recognize the document, what attributes to extract and store from the document, as well as set defaults for pre-processing actions.

Defining processing rules is the next important step after document types. Processing rules describe the actions to be taken against incoming documents, and consist of selection criteria (which processing rule should be triggered), pre-processing actions (what should be done when the processing rule is triggered), and actions (what should be done after the pre-processing actions.) Pre-processing actions include checks for validation and uniqueness, as well as storing the document to the database.

Actions include executing services, sending notifications and responses, passing the document through to another trading partner, and setting user status.

When a document is received into Trading Networks (meaning the endpoint URI for the business document is the wm.tn:receive service), the following steps are performed:

1. TN matches the document against configured document types. If no matching document type exists, the TN server assigns it a document type of Unknown. If a matching document type exists, TN assigns it the appropriate document type and extracts specific business document data (the document attributes).
   
   
2. TN then begins checking the list of processing rules for an appropriate rule to run. If none of the custom processing rule criteria match the incoming business document, the Default processing rule is run (which specifies the document user status will be set to IGNORED and the document stored in the database.) If a custom processing rule is selected, the pre-processing and processing actions of the rule are performed as configured by the administrator.

---

[1]  2  3  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums