Delivering a Trading Networks Document in Multiple Formats By Rob Eamon

---

Introduction

In the previous webMethods Ezine, the article "Publish/Subscribe with Trading Networks: Subscription-style Delivery of Documents" described a technique whereby a single document could be delivered to multiple subscribers. The next logical step is to format document differently for each subscriber. This article extends the concepts of the Publish/Subscribe sample, presenting an approach that provides this functionality.

---

Overview of Dynamic Document Mapping

Typical document processing services follow the same general steps: 1) get the document into record form, usually using pub.web:documentToRecord; 2) map the source record to a target format; 3) submit the target record to Trading Networks (TN) or some other transport service, possibly converting the target record to a document format.

When a service is delivering a single document to multiple receivers in multiple formats, the only difference in the processing of each format is the mapping steps. We can isolate this difference and create a processing service that handles any type of source document and sends it to any number of recipients in any number of formats.

The basic concept is to once again use extended fields within the TN profiles to provide configuration information to our Flow service. The service looks up the name of the mapping service to use for a specific source document type from the profile that is to receive the document. The mapping service simply converts the source format to the target format. Figure 1 depicts an overview of the process.

---

Prerequisites

Just like the first two steps in the Pub/Sub with Trading Networks article, we need to create an extended field and configure the profiles. First, create two profiles, one for XYZ Corp. and one for Another Partner. Use any values desired for the external IDs and other settings.

Follow the instructions in the Subscription-style Delivery of Trading Networks Documents article to establish subscriptions for the Customer Change document.

We’ll store mapping-related extended fields in a group named Maps and name the fields within using the form sourceDocType, where sourceDocType identifies the name of the source document that the mapping service will convert to a target. Create an extended field named CustomerChangeMap in the Maps group. Repeat this step to add an extended field for each desired source document type.

For the XYZ Corp. profile, set the CustomerChangeMap extended field to DynDocMap.map:grayToBlue. For the Another Partner profile, set the extended field to DynDocMap.map.grayToGreen. We will define both of these services in the next section.

---

Define the Mapping Services

There are a few concepts that help keep mapping services simple and reusable:

1. A mapping service is responsible solely for mapping from one record structure to another. The input to a mapping service is a specific record structure and the output is another specific structure.
2. A mapping service can use external resources to perform its function, such as a database table for code translations or another service to perform a calculation.
3. The mapping service should not perform any "transport" functions, such as moving a document to a directory or submitting the document to TN. The main processing service that invokes the mapping service will do that.

Since a mapping service can be invoked from any other service, the mapping service must not make any assumptions about the state of the pipeline or the service that invoked it. A mapping service should rely only on its service input parameters.

Now that we have set the guiding concepts, we can define the mapping services needed for both XYZ Corp and Another Partner. These services are named for the document types they work with, not for the profiles that use them. This allows us to reuse mapping services for more additional profiles.

---

[1]  2  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums