| Join wMUsers | Blog at wMUsers | User Control Panel | Site Map | webMethods Jobs |For Employers |
 |
|
 |
Another approach to consider is defining processing rules that filter on the partner identifier (sender ID attribute) within the document. While hiding the private details from the sender, this approach still has problems at both the technical and business level. We would need a unique processing rule for each category of partner and a static list of the partners in that category. With our partners moving up and down the categories based on expenditures, this static list will not exist. We need an approach allowing TN to receive a purchase order from any partner, select a single document type, execute a single processing rule, select the category of the partner from a dynamically maintained database table, and then reprocess the document -- without requiring any changes to the document and all within the same TN transaction. Dynamic Processing SolutionIf we combine pieces of the two undesirable approaches, we can create one approach that minimizes our short-term and long-term effort (so we will use very few document types and processing rules) as well as allowing for dynamic partner categories and hiding those category details from our partners. Remembering our sequence of events for document processing, we know that TN will identify incoming documents based on criteria established in our document types, and then extract the document attributes once identification has been made. In our scenario, we will use one document type to identify ALL purchase orders. The selection criteria will include a DOCTYPE identifier and a root tag of purchaseOrder, as these are the identifying pieces of our standard purchase order document. We will extract attributes SenderID, ReceiverID, DocumentID, and UserStatus. We know that as soon as TN has extracted the document attributes, it will then start looking for a processing rule. We will have four processing rules:
An important thing to remember about processing rules is the order in which they appear in the TN console is the order in which they are evaluated. As soon as any one processing rule criteria matches the current document and process, that rule is selected and all others are ignored. This means for our scenario solution to work, we have to place the processing rules in the correct order, as shown above. Otherwise, there exists the potential for AllPurchaseOrderRule to be selected in all cases (as it does not care about the User Status). As you have probably surmised, the key to our solution is the service called by the AllPurchaseOrderRule. This is a standard Integration Server service, utilizing the input/output specification for processing services ( This specification allows the service to receive the business document (inside of a bizdoc envelope), the extracted document attributes, and anything else in
Once the document is resubmitted, the VitalPartnerRule, StrategicPartnerRule, or OtherPartnerRule will trigger based on the new value of the User Status field. Each of these rules triggers appropriate actions or services specific to the category of partner. We can then dynamically change the processing behavior for inbound Purchase Order documents by altering only one thing: the PartnerCategory table. SummaryOur solution has achieved dynamic business logic routing, without requiring our partners to make changes to their business documents or processes, and while leveraging the routing and filtering capability of Trading Networks. Of course, this is a generic design solution, intended to show the possible benefit of using User Status to resolve dynamic processing challenges. User Status can be used in a similar way to create dynamic processing solutions to meet your technical and business needs. One Last DetailWhen I implemented this solution for my customer, I ran into one unexpected problem in the way Trading Networks stores SenderID and ReceiverID in the TN database. While our document attributes for SenderID and ReceiverID may extract the company name, DUNS ID, or some other external unique identifier, Trading Networks resolves SenderID and ReceiverID back to the unique profile ID created by TN when the profile was saved. For example, a company called ACME with a DUNS ID of 3167890 may have a TN unique profile ID of 7f000001f70df1ff00000066 in the partner database. It is the TN unique profile ID that is sent as part of the bizdoc, not the extracted attribute value. This means a lookup database table such as our PartnerCategory table should either contain the TN unique profile ID for the trading partner, or the processing service should resolve this ID back to the extracted attribute value (using a service such as Go Deeper on the Subject: The wMUsers Discussion Forums Phillip Leary is a co-founder of Crossvale, an educational services firm specializing in integration issues. In the five years prior to co-founding Crossvale, Phillip held a variety of consultancy, management, and business development positions at Deloitte Consulting and Price Waterhouse. He has provided consulting and training services on the webMethods platform since 1998.
Phillip can be reached via email at |
© All Rights Reserved, 2001-2008. |