Title Page

Trading Networks Version 7.1 webMethods Trading Networks

Concepts Guide
Copyright
&  Docu‐
ment ID

Cerebra, Glue, Infravio X‐Broker, Infravio X‐Registry, Infravio, My webMethods Server, My webMethods, webMethods Access, webMethods Administrator, 
webMethods Broker, webMethods Central Configuration, webMethods Dashboard, webMethods Designer, webMethods Developer, webMethods Fabric, 
webMethods Glue, webMethods Infrastructure Data Collector, webMethods Infravio X‐Broker, webMethods Infravio X‐Registry, webMethods Installer, 
webMethods Integration Server, webMethods logo, webMethods Mainframe, webMethods Manager, webMethods Modeler, webMethods Monitor, 
webMethods Optimize for Infrastructure, webMethods Optimize for Process, webMethods Optimize, webMethods Portal, webMethods Process Engine, 
webMethods Servicenet, webMethods Task Engine, webMethods Trading Networks, webMethods Workflow, and webMethods are either registered 
trademarks or trademarks of webMethods, Inc.
Acrobat, Acrobat, and Reader are registered trademarks of Adobe Systems Incorporated.  Amdocs and ClarifyCRM are registered trademarks of Amdocs.  
Ariba is a registered trademark of Ariba, Inc.  BEA, BEA WebLogic Server, Jolt, and Tuxedo are registered trademarks, and BEA WebLogic Platform is a 
trademark of BEA Systems, Inc.  Action Request System, BMC Software, PATROL, and Remedy are registered trademarks of BMC Software, Inc.  BroadVision 
is a registered trademark of BroadVision, Inc.  Chem eStandards and CIDX are trademarks of CIDX, The Chemical Industry Data Exchange.  SiteMinder and 
Unicenter are registered trademarks of CA, Inc.  PopChart is a registered trademark of CORDA Technologies, Inc.  Kenan and Arbor are registered trademarks 
of Alcatel‐Lucent.  Data Connection and SNAP‐IX are registered trademarks of Data Connection Corporation.  D&B and D‐U‐N‐S are registered trademarks of 
Dun & Bradstreet Corporation.  Eclipse is a trademark of Eclipse Foundation, Inc.  Entrust is a registered trademark of Entrust, Inc.  papiNet is a registered 
trademark of the European Union and the United States.  Financial Information eXchange, F.I.X, and F.I.X Protocol are trademarks of FIX Protocol Ltd.  
UCCnet and eBusinessReady are registered trademarks, and 1SYNC and Transora are trademarks of GS1 US.  Hewlett‐Packard, HP, HP‐UX, OpenView, PA‐
RISC, and SNAplus2 are trademarks of Hewlett‐Packard Company.  i2 is a registered trademark of i2 Technologies, Inc.  AIX, AS/400, CICS, ClearCase, DB2, 
Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, and WebSphere, and 
z/OS are registered trademarks; and Communications System for Windows NT, DB2 Universal Database, IMS, MVS, and SQL/DS are trademarks of IBM 
Corporation.   InnoDB is a trademark of Innobase Oy.  Itanium is a registered trademark of Intel Corporation.  Linux is a registered trademark of Linus 
Torvalds.  W3C is a registered trademark, and X Window System is a trademark of the Massachusetts Institute of Technology.  MetaSolv is a registered 
trademark of Metasolv Software, Inc.  ActiveX, Microsoft, Outlook, Visual Basic, Visual SourceSafe, Windows, Windows NT, and Windows Server are 
registered trademarks of Microsoft Corporation.   Six Sigma is a registered trademark of Motorola, Inc.  Firefox and Mozilla are registered trademarks of the 
Mozilla Foundation.  MySQL is a registered trademark of MySQL AB.  nCipher is a trademark of nCipher Corporation Ltd.   Eclipse is a trademark of Eclipse 
Foundation, Inc.  Entrust is a registered trademark of Entrust, Inc.  papiNet is a registered trademark of the European Union and the United States.  Financial 
Information eXchange, F.I.X, and F.I.X Protocol are trademarks of FIX Protocol Ltd.  UCCnet and eBusinessReady are registered trademarks, and 1SYNC and 
Transora are trademarks of GS1 US.  Hewlett‐Packard, HP, HP‐UX, OpenView, PA‐RISC, and SNAplus2 are trademarks of Hewlett‐Packard Company.  i2 is a 
registered trademark of i2 Technologies, Inc.  AIX, AS/400, CICS, ClearCase, DB2, Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, 
OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, and WebSphere, and z/OS are registered trademarks; and Communications System for Windows 
NT, DB2 Universal Database, IMS, MVS, and SQL/DS are trademarks of IBM Corporation.  InnoDB is a trademark of Innobase Oy.  Itanium is a registered 
trademark of Intel Corporation.   Teradata is a registered trademark of NCR Corporation. Netscape is a registered trademark of Netscape Communications 
Corporation.  ServletExec is a registered trademark, and New Atlanta is a trademark of New Atlanta Communications, LLC.  SUSE is a registered trademark 
of Novell, Inc.  Appia is a registered trademark and Javelin Technologies is a trademark of NYFIX, Inc.  CORBA is a registered trademark of Object 
Management Group, Inc.  JD Edwards, OneWorld, Oracle, PeopleSoft, Siebel, and Vantive are registered trademarks; and Infranet, PeopleSoft Pure Internet 
Architecture, Portal, and WorldSoftware are trademarks of Oracle Corporation.  Perforce is a trademark of Perforce Software.  JBoss and Red Hat are 
registered trademarks of Red Hat, Inc.  PIP and RosettaNet are trademarks of RosettaNet, a non‐profit organization.   SAP and R/3 are registered trademarks 
of SAP AG.  PVCS is a registered trademark of Serena Software, Inc.  SWIFT and SWIFTNet are registered trademarks of Society for Worldwide Interbank 
Financial Telecommunication SCRL.  SPARC and SPARCStation are registered trademarks of SPARC International, Inc.  BAAN and SSA are registered 
trademarks; and SSA Global is a trademark of SSA Global Technologies, Inc.  EJB, Enterprise JavaBeans, Java, JavaServer, JDBC, JSP, J2EE, Solaris, Sun, and 
Sun Microsystems are registered trademarks; and Java Naming and Directory Interface, JavaServer Pages, SOAP with Attachments API for Java, and SunSoft 
are trademarks of Sun Microsystems, Inc.  Sybase is a registered trademark of Sybase, Inc.  VERITAS is a registered trademark, and VERITAS Cluster Server is 
a trademark of Symantec Corporation.  UNIX is a registered trademark of The Open Group.  Unicode is a trademark of Unicode, Inc.  VeriSign is a registered 
trademark of Verisign, Inc. 
Software AG and all Software AG product names are either trademarks or registered trademarks of Software AG. 
Other product and company names mentioned herein may be the trademarks of their respective owners.
Copyright © 2005‐2007 webMethods, Inc. All rights reserved.
Copyright © 2005‐2007 Software AG and/or its suppliers, Uhlandstrasse 12, 64297 Darmstadt, Germany. All rights reserved.

Document ID: TN-CG-71-20070831

 Contents

Contents

About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapter 1. Overview of webMethods Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 9

What Is a Trading Network? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
What Is webMethods Trading Networks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Architecture and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Trading Networks Is the Foundation for eStandards Processing . . . . . . . . . . . . . . . . . . . . . . . . 12
Partners in a Trading Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Document Processing with Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Overview of Trading Networks Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Design Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 2. Trading Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Overview of Trading Partner Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Profile Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Profile Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Data Types of Profile Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Required Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Trading Partner Agreements (TPAs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
TPA Information vs. Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Information in a TPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
TPA Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 3. Setting Up Trading Networks to Process Documents . . . . . . . . . . . . . . . . . . . 25

Overview of Items to Set Up for Processing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Document Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
What You Specify to Define a Document Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
How Document Attributes Relate to TN Document Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
How Trading Networks Uses Document Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
TN Document Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
TN XML Document Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
TN Flat File Document Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Document Gateway Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

webMethods Trading Networks Concepts Guide Version 7.1 3

 Contents

Information You Supply to Define TN Flat File Document Types . . . . . . . . . . . . . . . . . . . . 34

Unknown TN Document Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Processing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Processing Rule Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Pre-processing Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Processing Rule Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Scheduled Delivery Queues and Processing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 4. Sending Documents to Trading Networks for Processing . . . . . . . . . . . . . . . 41

Overview of Sending Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Sending Documents to Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Clients that Trading Partners Use to Send Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Service the Client Should Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
User Accounts for Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Protocols the Client Can Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Sending the Documents to Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Forwarding Documents to Another Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Sending a Document Back to the Same Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 5. Trading Networks Document Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Overview of How Trading Networks Processes a Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Processing of Documents in Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Recognition Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Recognition of XML Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Recognition of Flat Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Document Gateway Services During Flat File Recognition . . . . . . . . . . . . . . . . . . . . . . . . . 56
Trading Networks Processing During Flat File Recognition . . . . . . . . . . . . . . . . . . . . . . . . 59
Processing Rule Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Pre-processing Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Processing Rule Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Pipeline Information that You Can Use in Processing Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Execute a Service Processing Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Send an Alert E-mail Processing Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Change User Status Processing Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Deliver the Document to the Receiver Processing Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Respond with a Message Processing Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Large Document Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
How Trading Networks Handles Large Documents Differently . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Items You Must Set Up Differently for Large Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

webMethods Trading Networks Concepts Guide Version 7.1 4

 Contents

Chapter 6. Delivering Documents to Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Overview of Delivering Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
How Trading Networks Determines Delivery Method Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
When Delivery Information Cannot Be Determined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Immediate Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Immediate Delivery Methods Provided with Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Adding Your Own Immediate Delivery Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Reliable Delivery with Immediate Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Using Reliable Delivery for an Immediate Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Scheduled Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Scheduled Delivery Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Scheduled Delivery Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Scheduled Delivery Services Provided with Trading Networks . . . . . . . . . . . . . . . . . . . . . . 80
Adding Your Own Scheduled Delivery Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Reliable Delivery and Scheduled Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Queuing Documents for Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
When Trading Networks Uses Queue for Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Chapter 7. Sending Documents to Business Processes for Processing . . . . . . . . . . . . . 85

Overview of Sending Documents to Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
How You Define the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Conversation IDs for Trading Networks Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
How Documents Are Passed to a Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Chapter 8. Tracking and Viewing Run-Time Information in Trading Networks . . . . . . . . 91

Run-time Information that You Can Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Viewing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Resubmitting and Reprocessing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Viewing Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Stopping, Restarting, Reassigning, and Deleting Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Viewing the Activity Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Viewing the Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Using Trading Networks Web Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Chapter 9. Business Analysis and Monitoring of Trading Networks Transaction Data . 99

Overview of the Analysis of Trading Networks Transaction Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Architecture and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Design Time Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Monitoring Trading Networks Transaction Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Stages at Which the Events are Passed to the Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

webMethods Trading Networks Concepts Guide Version 7.1 5

 Contents

Appendix A. Glossary for Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Appendix B. Security within Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Overview of Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Communicating Securely Using SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Protecting Access to User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Access to My webMethods for Trading Networks Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Access to Trading Networks User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Protecting Partner Profile Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Protecting Access to Trading Networks Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Certificates for Verifying, Signing, Encrypting, and Decrypting Documents . . . . . . . . . . . . . . . . . . . . 120
Verifying Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Actions You Must Take to Verify Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
How Trading Networks Verifies Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Digitally Signing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
How Trading Networks Signs Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Encrypting and Decrypting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Encrypt Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
How Trading Networks Encrypts Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Decrypt Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
How Trading Networks Decrypts Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

webMethods Trading Networks Concepts Guide Version 7.1 6

 About This Guide

About This Guide

This manual is for users of webMethods Trading Networks and webMethods for Partners 
and provides an overview of webMethods Trading Networks (Trading Networks). It 
contains information to familiarize you with using Trading Networks and describes how 
to monitor Trading Networks data.

Note: The webMethods Trading Networks and webMethods for Partners components 
perform the same functionality. The difference between the components is that 
webMethods Trading Networks allows you to have as many partners in your network as 
you want, and webMethods for Partners allows you to have only a single partner. This 
guide provides documentation for both components although it refers only to 
webMethods Trading Networks (referred to as Trading Networks).

Document Conventions

Convention Description
Bold Identifies elements on a screen.
Italic Identifies variable information that you must supply or change 
based on your specific situation or environment. Identifies terms the 
first time they are defined in text. Also identifies service input and 
output variables.
Narrow font Identifies storage locations for services on the webMethods 
Integration Server using the convention folder.subfolder:service.
Typewriter Identifies characters and values that you must type exactly or 
font messages that the system displays on the console.
UPPERCASE Identifies keyboard keys. Keys that you must press simultaneously 
are joined with the “+” symbol.
\ Directory paths use the “\” directory delimiter unless the subject is 
UNIX‐specific.
[ ] Optional keywords or values are enclosed in [ ]. Do not type the [ ] 
symbols in your own code.

webMethods Trading Networks Concepts Guide Version 7.1 7

 About This Guide

Additional Information
The webMethods Advantage Web site at http://advantage.webmethods.com provides you 
with important sources of information about webMethods products:
Troubleshooting Information. The  webMethods Knowledge Base provides 
troubleshooting information for many webMethods products. 
Documentation Feedback. To provide feedback on webMethods documentation,  go to 
the Documentation Feedback Form on the webMethods Bookshelf.
Additional Documentation. Starting with 7.0, you have the option of downloading the  
documentation during product installation to a single directory called 
“_documentation,” located by default under webMethods installation directory. In 
addition, you can find documentation for all webMethods products on the 
webMethods Bookshelf.

webMethods Trading Networks Concepts Guide Version 7.1 8

Chapter 1. Overview of webMethods Trading Networks

What Is a Trading Network? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

What Is webMethods Trading Networks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Architecture and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Partners in a Trading Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Document Processing with Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Overview of Trading Networks Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

webMethods Trading Networks Concepts Guide Version 7.1 9

 1. Overview of webMethods Trading Networks

Note: The webMethods Trading Networks and webMethods for Partners components 
provide the same functionality. The difference between the components is that 
webMethods Trading Networks allows you to have as many partners in your network as 
you want, while webMethods for Partners allows you to have only a single partner. This 
guide provides documentation for both components although it only refers to 
webMethods Trading Networks.

What Is a Trading Network?

A trading network is a set of organizations that have agreed to exchange business 
documents. Participants might include strategic partners, buyers, suppliers, and 
marketplaces. Examples of typical business documents are purchase orders, order 
statuses, purchase order acknowledgements, invoices, as well as other domain‐specific 
business documents. The organizations in your network are referred to as trading partners 
(partners). A trading partner can be any system, within or outside your enterprise, that 
produces or consumes business documents.

What Is webMethods Trading Networks?

webMethods Trading Networks (also referred to as Trading Networks) is a component that 
runs on the webMethods Integration Server. Trading Networks enables your enterprise to 
link with other companies (buyers, suppliers, strategic partners) and marketplaces to form 
a business‐to‐business trading network. 
The components of Trading Networks are a server and the following user interfaces:
My webMethods, which is a web‐based, administration and monitoring user interface 
for managing your webMethods components.
Trading Networks Console, which is a standalone user interface that is Trading 
Networks‐specific. Portions of the Console are deprecated in 7.1. The deprecated 
portions are those areas of functionality that have been migrated to My webMethods 
(e.g., transaction analysis, tasks, and activity log viewing, profile management).
Trading Networks Web Manager, which is also a web‐based user interface; however 
this is a Trading Networks‐specific user interface and has only limited functionality. 
Trading Networks Web Manager is deprecated.

webMethods Trading Networks Concepts Guide Version 7.1 10

 1. Overview of webMethods Trading Networks

Architecture and Components

The following shows the components of Trading Networks:

Architecture and Components

My webMethods
My
Server
webMethods

Trading
Networks
Console Trading Networks
WmTN package Relational
Database
WmTNWeb package

Trading
Networks Integration Server
Web Manager

My webMethods Server is the run‐time container for functions that webMethods 
components make available. For example, Trading Networks makes the functions to 
monitor and manage transactions available. Users access these functions from the My 
webMethods user interface. For example, when a user monitors a transaction, My 
webMethods Server handles the request by interacting with Trading Networks to 
perform the function and return information to the user.
Trading Networks WmTN and WmTNWeb packages run within the Integration Server. 
The packages provide the logic to handle the management of partners on your 
network and the exchange of documents. You can interact with the Trading Networks 
via the user interfaces. Your partners interact with the server to exchange business 
documents.

Note: The WmTNWeb package, which is for Web Manager, is deprecated.

Integration Server hosts packages that contain services and related files. The Integration 
Server provides an environment for the orderly, efficient, and secure execution of 
services.
Relational database (RDBMS) that Trading Networks uses to store all information about 
the trading network: partner information, the types of documents to process, how to 
process business documents, information about business documents that pass 
through the network, log information, etc. You need to install a relational database for 
Trading Networks use, for example, Oracle or SQL Server.

webMethods Trading Networks Concepts Guide Version 7.1 11

 1. Overview of webMethods Trading Networks

My webMethods is a web‐based, administration and monitoring user interface for 
managing your webMethods components. You can use it to monitor Trading 
Networks transactions, service execution tasks, delivery tasks, and the activity log. 
Additionally, you can use webMethods to manage profiles, profile groups, and 
Trading Networks queues.
Trading Networks Console, which is a Java‐based GUI, is a Trading Networks user 
interface primarily for designing how you want Trading Networks to recognize 
documents using TN document types and how Trading Networks processes 
documents. You can also use it to perform functions that have been migrated to My 
webMethods. These portions(e.g., transaction analysis, tasks, and activity log 
viewing, profile management) of the Console that have been migrated to My 
webMethods are deprecated.
Trading Networks Web Manager  is another user interface for Trading Networks that you 
access via a Web browser. Trading Networks Web Manager is deprecated. It offers 
some of the functionality of the Trading Networks Console plus additional 
administrative actions.

Trading Networks Is the Foundation for eStandards

Processing
Trading Networks is also the base through which webMethods components support 
numerous eBusiness Standards (eStandards) such as RosettaNet, EDI, ebXML Messaging 
Service, SWIFT, FIX, and CIDX. webMethods eStandards Modules that use features of the 
Trading Networks component to carry out the processing behavior that is specific to the 
eStandard the module supports.

Partners in a Trading Network

To form a trading network, you add trading partners (also known as partners) that will send 
documents to Trading Networks for processing and/or that will receive documents that 
Trading Networks is instructed to deliver. You add partners by creating a Trading 
Networks profile for each partner you want to add to the trading network. The profile 
contains information about a partner.
Each of your partners has their own system that communicates with your instance of 
Trading Networks. Trading Networks does not require that all partners in the network use 
webMethods Trading Networks or Software AG software. If you have a buyer, supplier, or 
strategic partner that uses other software, you can add them to your network. When you 
add the partner by defining its profile, you provide information about how to connect to 
the partner and how to send that partner information.

webMethods Trading Networks Concepts Guide Version 7.1 12

 1. Overview of webMethods Trading Networks

A Trading Network

Trading Integration Application

Networks Server Server

Integration
Server
Marketplace

Trading
DB Networks

Integration
Server
Trading Trading
Networks Networks
DB
Integration Integration
Server Server

DB DB

In the above network, one of the non‐Trading Networks partners is a webMethods 
Integration Server that is not using Trading Networks. Also, the application server and 
marketplace (e.g., Ariba Network) might not use Software AG software at all.
Also note in the above network, that the partner in the center is referred to as the hub of 
the network. The other partners are referred to as spokes. The hub hosts the network and 
the spokes participate by interacting with the hub.

webMethods Trading Networks Concepts Guide Version 7.1 13

 1. Overview of webMethods Trading Networks

A Trading Networks partner does not have to be exclusively a hub or a spoke; it can be 
both, as illustrated below. It can be a hub of its own network and a spoke in another 
partnerʹs network.

Trading Networks Partner Can Be Both a Hub and a Spoke

Integration Application
Server Server
Trading
Trading Networks
Networks Marketplace
Integration
Integration Server
Server Trading
Networks

Integration DB
DB Server
Trading
Networks

Integration Trading
Trading DB Networks
Server
Networks
hub and spoke Integration
Integration Server
Server
DB

hub and spoke DB

DB

Trading
Networks
Integration
Server

DB

Document Processing with Trading Networks

Use Trading Networks to set up your network of trading partners in a document‐oriented 
exchange scenario. You can exchange business documents with the partners in your 
network to relay production information. The business documents can be in any format 
recognized by two partners that exchange data, e.g., XML and flat file.
Conceptually, Trading Networks is a format‐neutral, business‐document gateway that can 
recognize and process a variety of XML and structured flat‐file formats that flow between 
distributed trading partners.

webMethods Trading Networks Concepts Guide Version 7.1 14

 1. Overview of webMethods Trading Networks

To specify how to exchange documents, you define:
Profiles for partners; that is, the information you want to collect and maintain about 
your partners. A profile contains the information that Trading Networks needs to 
exchange documents with your partners.
TN document types that specify the types of business documents that you want to 
exchange with your partners. The business documents might conform to an industry 
standard, such as, cXML, CBL, OAG, and EDI, or have your own customized 
specifications.
Processing rules that indicate how you want Trading Networks to process documents 
as they traverse your trading network.
After you have your trading network established, you use Trading Networks to manage 
and maintain your trading network.

Overview of Trading Networks Processing

The following diagram and accompanying text provide a high‐level overview of how 
Trading Networks receives and processes documents.

Overview of Processing

Trading Partner 1 2 Trading Partner

Trading
Networks
Client Receiver
Integration
Server

Step Description

1 A client sends a document to Trading Networks.

2 Trading Networks receives and processes the document. For example, Trading 
Networks might be instructed to deliver the document to another trading 
partner.

You define the processing that Trading Networks performs at run time when a document 
is received. You define this run time processing by defining Trading Networks objects at 
design time. For a list and description of these Trading Networks objects, see “Design 
Time” below.

webMethods Trading Networks Concepts Guide Version 7.1 15

 1. Overview of webMethods Trading Networks

Design Time
At design time, you define the following objects for Trading Networks: 

Define for Trading

Networks Description For more information, see...
Profiles  Identifies the partners you want  “Profiles” on page 18
Trading Networks to interact with.
TN document Defines the types of documents that  “TN Document Types” on 
types you want Trading Networks to  page 30
recognize and process.
Document Identifies the pieces of information  “Document Attributes” on 
attributes  within the documents that are  page 27
important to you for processing 
documents and for later analyzing 
the documents that have passed 
through your network.
Processing rules Defines the actions you want  “Processing Rules” on 
Trading Networks to take against  page 36
the documents it receives, for 
“Processing Rule Actions” on 
example, delivering the document 
page 38
to its receiver.

Run Time
At run time, the following actions occur:

Action for Trading Networks For more information, see...

A client or back‐end system sends a document to  Chapter 4, “Sending 
Trading Networks Documents to Trading 
Networks for Processing”
Trading Networks processes the document Chapter 5, “Trading 
Networks Document 
Processing”
Trading Networks can deliver the document to a  Chapter 6, “Delivering 
trading partner Documents to Partners”

webMethods Trading Networks Concepts Guide Version 7.1 16

Chapter 2. Trading Partners

Overview of Trading Partner Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Profile Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Profile Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Trading Partner Agreements (TPAs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

webMethods Trading Networks Concepts Guide Version 7.1 17

 2. Trading Partners

Overview of Trading Partner Information

You supply information about trading partners in:
Profiles. Profiles are required for each partner in your trading network. To add a 
partner to your trading network, you define a profile for that partner. Trading 
Networks is only aware of partners for which it has a profile. The profile contains 
information such as contact information and information that Trading Networks uses 
when exchanging documents with the partner.
Trading partner agreements (TPAs). Optionally, you can define trading partner 
agreements for pairs of partners. Each TPA contains specific information for two 
trading partners, where one partner represents a sender and the other represents the 
receiver. You can create applications that use TPA information to tailor how 
documents are exchanged. Other webMethods components (e.g., webMethods EDI 
Module) use TPAs to perform processing.

Profiles
A profile is a collection of information about a corporation that is a part of a trading 
network. Trading Networks maintains your profile (called the Enterprise profile), as well as 
the profile of each of your trading partners on your network. 
The information in a profile encompasses both technical (e.g., HTTP port number) and 
business level (e.g., payment terms) information. You fill in profile fields to define the 
information for a profile. A profile contains standard profile fields that are provided 
out‐of‐the‐box and extended profile fields that you define. For more information, see 
“Profile Fields” on page 19.
The information in the profile includes the following types of information:
General information about the corporation, for example, the corporation name and its 
address.
Contact information for the corporation, for example, a technical contact.

Information about how documents should be delivered to the corporation, for 
example, the HTTP host name and port number to use to deliver a document to the 
corporation via HTTP.
Certificate information for digital signing of documents, verifying digital signatures, 
encrypting and decrypting documents. 
Any information that you want to include in the profile that Trading Networks does 
not provide. You define extended fields for this information.

webMethods Trading Networks Concepts Guide Version 7.1 18

 2. Trading Partners

For more information about:

Defining profiles, see Chapter 9, ʺDefining and Managing Your Profile (Your 
Enterprise)ʺ, Appendix H, ʺManaging Your Profile Using the Consoleʺ, 
Chapter 10, ʺDefining and Managing Partner Profilesʺ, and Appendix I, 
ʺManaging Partner Profiles Using the Consoleʺ in the webMethods Trading 
Networks Administrator’s Guide.
Certificate information, see, Appendix B, “Security within Trading Networks”.

Profile Status
Trading Networks maintains a status for the profile of each partner. After you add a 
profile for a partner and Trading Networks validates the fields, Trading Networks saves 
the profile and sets profile status to “Inactive”. Before you can exchange documents with 
the partner, you must enable the profile by updating the status to “Active”. When you 
enable your own profile, you are able to exchange documents with partners. When you 
enable a partner’s profile, you are able to exchange documents with that partner.
The following table shows the possible profile statuses and their meanings: 

Value Meaning
Active You have filled in the partnerʹs profile and Trading Networks has 
programmatically determined that all profile fields (standard and extended) 
are valid. You have enabled the profile by setting the status to “Active”.
When the partnerʹs profile is active, you can exchange documents with the 
partner.
Inactive When a partner’s profile is inactive, you cannot exchange documents with 
this partner.
Either you have just added the profile and have not yet enabled it, or you 
have disabled the profile.

Profile Fields
Profile fields are the fields in a profile. Each profile field represents information that you 
can collect and maintain about your own enterprise and the enterprises of each partner in 
your network. There are two types of profile fields—standard and extended.
Standard fields are Trading Networks‐defined fields that incorporate the majority of the 
information that you will want to collect and maintain about a partner. These profile 
fields are available out of the box.
Most of the standard fields are for your own use, for example, the name of the 
corporation and its mailing address. However, Trading Networks requires some of 

webMethods Trading Networks Concepts Guide Version 7.1 19

 2. Trading Partners

the standard fields to operate normally, for example, the host and port number that a 
partner uses for HTTP to deliver a document to the partner via HTTP.
Extended fields are custom fields that you define to extend the standard profile that are 
provided out of the box. If you want to collect additional information about your 
partners that is not covered by the standard fields, you can define extended fields. If 
you define extended fields, all profiles on your Trading Networks system will contain 
the standard fields and the extended fields that you define. 
Both standard and extended profile fields are 1) have a data type and 2) can be required.

For more information about defining profile fields, see Chapter 8, ʺDefining and 

Managing Profile Fieldsʺ and Appendix G, ʺManaging Profile Fields Using the 
Consoleʺ in the webMethods Trading Networks Administrator’s Guide.

Data Types of Profile Fields

A profile field can have one of two data types—string or binary.
When the data type is string, you can define:
A default value for the field. Trading Networks includes the default value in the 
partner profile that it displays.
The maximum length allowed for the field. Trading Networks assures that the 
specified value for the field is no longer than the maximum value.
A list of valid values that can be specified for a field. If valid values are specified, 
Trading Networks assures that the specified value for the field matches one of the 
valid values.

Required Fields
A required field is one that you want supplied for all profiles, both your profile and your 
partners.
Several of the standard fields are required. If you want, you can change standard fields 
that come out‐of‐the‐box as non‐required to required. When you add your own extended 
fields, you can make them required. 
Each profile on your system must have a value for each required profile field before you 
can make the profile active. In other words, a partner’s profile must contain a valid value 
for all required fields before you can enable the partner’s profile and therefore make the 
partner an active member in the trading network from which Trading Networks will 
accept documents and to which Trading Networks can send documents.
In My webMethods and the Trading Networks Console, Trading Networks places an 
asterisk (*) next to the required fields, so you can easily see the fields that are required.

webMethods Trading Networks Concepts Guide Version 7.1 20

 2. Trading Partners

Trading Partner Agreements (TPAs)

A Trading Partner Agreement (TPA) is an optional set of parameters that you can define and 
use to tailor how documents are exchanged between two trading partners. These can be 
any two partners, not necessarily the hub and a spoke. Both partners must have existing 
profiles in Trading Networks.
Each TPA must have a unique combination of the following:
Partner that represents the sender

Partner that represents the receiver

Type of TPA, represented by the “Agreement ID”
You might have multiple TPAs for a pair of trading partners. For example, the following 
shows two TPAs for partners A and B that are used by the webMethods EDI Module:

TPA field TPA 1 TPA2

Partner that represents the sender A B
Partner that represents the receiver B A
Type of TPA (Agreement ID) EDITPA EDITPA

Trading Networks does not use TPAs for its own processing. For example, Trading 
Networks does not use TPAs when determining the processing rules to use for a 
document. Rather the parameters that you specify in the TPA are available for your own 
use. For example, you can access the TPA information from services executed by a 
processing rule. Access to this information allows you to build a document exchange 
application that uses the TPA to tailor the exchange of documents between partners. 
Other webMethods components take advantage of the TPA feature in Trading Networks. 
For example, the webMethods ebXML Module uses the TPA feature to support ebXML 
Collaboration Protocol Agreements (CPAs). For more information, see the webMethods 
ebXML User’s Guide.
Based on the document exchange processing that you want to put into effect, you define 
the parameters that you want saved in the TPA. The set of parameters can be different for 
different types of TPAs. For example, you might use TPAs for partners that exchange 
documents using ebXML that contain the parameters defined by the webMethods ebXML 
Module. Other partners might exchange documents using EDI, and for those partners you 
create TPAs that contain parameters defined by the webMethods EDI Module. For more 
information, see the webMethods EDI Module User’s Guide.

For more information about how to define TPAs, see Chapter 12, ʺDefining and Managing 

Trading Partner Agreements (TPAs)ʺ in the webMethods Trading Networks User’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 21

 2. Trading Partners

TPA Information vs. Profile Information

The type of information that a TPA contains is different than the type of information that 
Trading Networks maintains in a profile. A profile contains information about the partner 
that does not vary with each document being exchanged (e.g., company information and 
address, certificate information, delivery protocol parameters, external IDs). However, 
TPAs are intended to contain transaction‐dependent information (e.g., configuration 
information to support specific types of documents being exchanged) that are specific to a 
group of transactions between the two trading partners (e.g., digital signature or 
encryption to a message). The TPA augments the profile in Trading Networks and offers a 
flexible way to process and manage the documents exchanged between two trading 
partners. 
The primary goal of the TPA function in Trading Networks is to offer users a flexible and 
efficient way to define these transaction‐specific parameters; users can design and store 
any application‐specific TPA information at design time and efficiently retrieve the TPA 
information at run time.

Information in a TPA
When you define a TPA, you assign the following information: 
The partner that represents the sender for the TPA.

The partner that represents the receiver for the TPA.

An agreement ID to identify the type of TPA (e.g., TPAs for the webMethods EDI 
Module use the agreement ID “EDITPA”).
The TPA data that contains the application‐specific variables to use to tailor the 
processing of documents exchanged between the sender and receiver. You specify this 
data by defining an IS document type that defines the structure of the data to provide. 
You supply values for the variables defined by the IS document type. For example, the 
webMethods EDI Module ships with an IS document type (the wm.b2b.editn.TPA:EDITPA 
IS document type) to use for TPAs for partners exchanging EDI documents. This IS 
document type contains a set of variables that are used for processing EDI documents.
Optionally, an export service that you supply to export the TPA data.

Optionally, an initialization service that you supply to initialize the TPA data (e.g., the 
webMethods EDI Module supplies an initialization service to set the TPA values to its 
default values).

webMethods Trading Networks Concepts Guide Version 7.1 22

 2. Trading Partners

TPA Statuses
TPAs have two types of statuses—agreement status and data status.
1 Agreement status. Indicates the status of the TPA agreement between the receiver and 
sender.There are three TPA agreement statuses.

Proposed
When the agreement status is Proposed, a TPA is in a draft status. You do most of 
the modification to the TPA fields and data input in this Proposed state.

Agreed
An Agreed status means that the TPA is final. When the agreement status is 
Agreed, the data statuses take affect. Additionally, after the agreement status is 
Agreed, you cannot delete the TPA agreement. 

Disabled
The Disabled status means the TPA should not be used. If you are using a TPA 
and no longer want to use it, you can disable it. When you disable a TPA, the TPA 
remains in the Trading Networks system, but is considered inactive. Later, if you 
decide that you need the TPA, you can change the agreement status to Proposed 
or Agreed. 
webMethods components that use the TPA feature recognize a Disabled 
agreement status for a TPA. For example, if the webMethods ebXML Module 
attempts to use a TPA with a Disabled status, it acts as if there is no TPA. If you 
create an application that uses TPAs, it should check and honor the Disabled 
status.
2 Data status. The data status determines whether you can modify the TPA data, which is 
data that you supply for the IS document type you define for the TPA. That is, the 
TPA data is the data for the application‐specific variables to use to tailor the 
processing of documents exchanged between a sender and receiver. The TPA data 
status can be:
Modifiable. You can change TPA data; that is you can change the values of the 
variables in the IS document type associated with the TPA.
Non-modifiable. You cannot change the TPA data; that is you cannot change the 
values of the variables in the IS document type associated with the TPA.

Note: The data status is only effective when the Agreement status is Agreed. When the 
Agreement status is Proposed, Trading Networks allows you to make any changes to 
the TPA, including changing the TPA data.

webMethods Trading Networks Concepts Guide Version 7.1 23

 2. Trading Partners

webMethods Trading Networks Concepts Guide Version 7.1 24

Chapter 3. Setting Up Trading Networks to Process
Documents

Overview of Items to Set Up for Processing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Document Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

TN Document Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Processing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

webMethods Trading Networks Concepts Guide Version 7.1 25

 3. Setting Up Trading Networks to Process Documents

Overview of Items to Set Up for Processing Documents

To set up how you want Trading Networks to process documents, you define the 
following Trading Networks objects:
Document attributes that identify specific pieces of information that you want Trading 
Networks to extract from documents, for example, the sender of the document or the 
total amount of a purchase order. For more information, see “Document Attributes” 
on page 27.
TN document types that represent the types of documents that you expect for delivery 
to your trading network. TN document types are definitions that represent particular 
categories of documents. They are typically associated with a particular formatting 
style and a particular business purpose. The TN document type can represent 
documents specific to:
An internet standard, for example, a cXML Purchase Order (an Ariba cXML 
purchase order), FIXML Quote Request (a FIXML‐formatted request for 
quotation), or Biztalk Envelope (a Microsoft BizTalk envelope)
A custom standard used specifically for your trading partner integrations, for 
example, a purchase order format that you and your partner have agreed upon.
In a TN document type, you specify the document attributes that you want to extract 
from documents that match the TN document type. For example, if you are defining a 
TN document type for a purchase order, you might specify to extract the attributes for 
the total number of items purchased and the total amount of a purchase order.
For more information, see “TN Document Types” on page 30.
Processing rules that specify the actions that you want Trading Networks to perform 
for the document. For example, you might specify that you want Trading Networks to 
deliver the document to a partner or invoke a service to process the document. For 
more information, see “Processing Rules” on page 36.

For more information about:

Standard and custom document attributes, including how to define custom 
attributes, see Chapter 13, ʺDefining and Managing Document Attributesʺ in the 
webMethods Trading Networks Administrator’s Guide.
How to define TN document types, see Chapter 14, ʺDefining and Managing TN 
XML Document Typesʺ and Chapter 15, ʺDefining and Managing TN Flat File 
Document Typesʺ in the webMethods Trading Networks Administrator’s Guide.
How to define processing rules, see Chapter 16, ʺDefining and Managing 
Processing Rulesʺ in the webMethods Trading Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 26

 3. Setting Up Trading Networks to Process Documents

Document Attributes
Document attributes identify selected content from the documents that pass through your 
trading network. This selected content is information in the documents that you are 
interested in, for example, a purchase order number or the account number of a 
purchaser. You also use the document attributes for monitoring by webMethods Optimize 
for B2B, for example, a comparative analysis of all the purchase order quantities by a 
particular customer. For more information, see Chapter 9, “Business Analysis and 
Monitoring of Trading Networks Transaction Data”.
Trading Networks maintains two types of attributes—system attributes and custom 
attributes. 
System attributes are Trading Networks‐defined attributes. The system attributes are:

SenderID Identification of the sender of a document
ReceiverID Identification of the receiver of a document
DocumentID Identification of the document
User Status The status that you or a partner associate with the document
GroupID Identification within a document that associates a document 
with other documents in a group
ConversationID Identification within a document that associates this document 
with other documents in the same business process (or 
conversation of documents)
SignedBody Portion of a document that contains data that was digitally 
signed
Signature Portion of a document that contains the digital signature of the 
document

Although you do not define the system attributes, if you want Trading Networks to 
extract a system attribute from a document, you must specify that system attribute in 
the TN document type. For more information, see “How Document Attributes Relate 
to TN Document Types” on page 28.
Custom attributes are attributes that you define to identify any other content that you 
are interested in extracting from documents. For example, to extract the purchase 
order number from documents, you might define a document attribute named 
“PO_Number”. To extract the total amount of a purchase order, you might define a 
document attribute named “Total_Order_Amount”.

webMethods Trading Networks Concepts Guide Version 7.1 27

 3. Setting Up Trading Networks to Process Documents

When you enable Trading Networks with BAM, you can monitor both, system 
attributes and custom attributes. Trading Networks always extracts the system, 
attributes, SenderID, ReceiverID, and InternalID for monitoring.
For more information about:
System and custom document attributes, including how to define custom 
attributes, see Chapter 13, ʺDefining and Managing Document Attributesʺ in the 
webMethods Trading Networks Administrator’s Guide.
Enabling BAM with Trading Networks, see Chapter 9, “Business Analysis and 
Monitoring of Trading Networks Transaction Data”.

What You Specify to Define a Document Attribute

The definition of a document attribute consists of:
Name of the attribute

Description of the attribute

Data type of the attribute, which can be one of: STRING, STRINGLIST, NUMBER, 
NUMBER LIST, DATETIME, or DATETIME LIST.

How Document Attributes Relate to TN Document Types

Document attributes are simply definitions of the pieces of information that you are 
interested in from all types of documents. After you define a document attribute, you can 
reference the attribute in TN document types indicating that you want that piece of 
information extracted from documents that match the TN document types.
As described above, the document attribute defines the name, description, and data type 
for a document attribute. When you set up a TN document type to extract a document 
attribute, you define how to locate an attribute within that specific type of document. 
Different types of documents have different formats, so the location of attributes within a 
document is based on the type of document. 
In the illustration below, there are three TN document types and a single document 
attribute (PO_Number). Each of the TN document types represents a different format of 
purchase order. All three TN document types indicate that Trading Networks is to extract 
the PO_Number attribute. Each TN document type specifies where in the purchase order 
to locate the content that should be extracted for the PO_Number attribute.

webMethods Trading Networks Concepts Guide Version 7.1 28

 3. Setting Up Trading Networks to Process Documents

Document Attributes and How They Relate to TN Document Types

Document #1 TN Document Type

The definition of a
<!-- OAG --> Name = OAG PO
document attribute
.
specifies the name,
The definition of a TN .
description, and data
document type specifies .
type for a document
how to locate the attributes Attributes
<POID>A230</POID> PO_Number
in the specific type of
document. .
.
.
Document Attribute
Name = PO_Number
Type = Number
Description = Purchase Order Number
TN Document Type
Name = cXML PO
. Document #2 Document #3 TN Document Type
. <!-- cXML --> <!-- CBL --> Name = CBL PO
. .
Attributes <OrderRequestHeader <BuyerRefNum> .
PO_Number orderID = P01234> <Reference> .
. . <RefNum> Attributes
. . 100 PO_Number
. . </RefNum> .
</Reference> .
</BuyerRefNum> .

In the TN document type, you can also indicate that you want Trading Networks to 
transform the value that is extracted for an attribute. You can transform the value using 
either a built‐in transformation (for example, upper case a STRING value), or if you need 
more complex transformations, you can create your own custom transformation services. 
Additionally, when you define the TN document type, you indicate whether you want 
Trading Networks to save the attribute values that it extracts to the database. If you save 
the attribute values, they are available for your later use. By default, Trading Networks 
always saves the attribute to the database.

How Trading Networks Uses Document Attributes

Extracted attributes can be used in the following ways:
You can select a processing rule based on the value of an extracted attribute. For example, you 
can select one processing rule if the sender is Partner A or another processing rule if 
the sender is Partner B. Another example might be to select a processing rule if the 
receiver is Partner B and the custom attribute for total amount of a purchase order 
(Total_Order_Amount custom attribute that you define) is greater than $10,000.
Trading Networks requires that you extract some system attributes for normal processing. For 
example, if you want Trading Networks to verify the digital signature of a document, 
you must extract the SignedBody and Signature system attributes. Additionally, if you 
want Trading Networks to deliver the document, you must extract the ReceiverID 

webMethods Trading Networks Concepts Guide Version 7.1 29

 3. Setting Up Trading Networks to Process Documents

system attribute so Trading Networks can determine the partner that is to receive the 
document.
If you save attribute values to the database, you can query the database based on attribute values
to locate specific documents. For example, you might want to locate all documents that 
were sent by Partner A and have and for which the custom attribute for total amount 
of a purchase order (Total_Order_Amount custom attribute that you define) is greater 
than $10,000.
If Trading Networks is BAM enabled, Trading Networks passes the attribute values to Optimize for
monitoring: For example, extracting the custom attribute PO_Quantity and the system 
attributes, SenderID and ReceiverID, to generate a report on the purchase order 
quantity by a particular sender from a particular receiver.

For more information about:

Standard and custom document attributes, including how to define custom 
attributes, see Chapter 13, ʺDefining and Managing Document Attributesʺ in the 
webMethods Trading Networks Administrator’s Guide.
How to extract attributes from TN document types, including how to transform 
attribute values using either the built‐in transformations or your own custom 
transformation services, see Chapter 14, ʺDefining and Managing TN XML 
Document Typesʺ and Chapter 15, ʺDefining and Managing TN Flat File Document 
Typesʺ in the webMethods Trading Networks Administrator’s Guide.
How to define processing rule criteria that uses the values of extracted attributes, 
see Chapter 16, ʺDefining and Managing Processing Rulesʺ in the webMethods 
Trading Networks Administrator’s Guide. 
How to query the database for documents based on the values of extracted 
attributes, see Chapter 3, ʺManaging and Tracking Documents from My 
webMethodsʺ and Chapter 8, ʺManaging and Tracking Documents from the 
Consoleʺ in the webMethods Trading Networks User’s Guide.
Monitoring the Trading Networks data, see Chapter 9, “Business Analysis and 
Monitoring of Trading Networks Transaction Data”.
How to define the TN document type and select the document attributes for 
monitoring, see webMethods Trading Networks Administrator’s Guide.

TN Document Types
TN document types represent the types of documents that you expect to come into your 
trading network. TN document types include:

webMethods Trading Networks Concepts Guide Version 7.1 30

 3. Setting Up Trading Networks to Process Documents

Identification information, which indicates how Trading Networks is to recognize a type 
of document, for example is the document a cXML Purchase Order (an Ariba cXML 
purchase order) or a custom format that you and a trading partner use.
Extraction information, which indicates the document attributes to extract from an 
inbound document that are required for further processing or monitoring. After 
Trading Networks matches an inbound document to the TN document type, the TN 
document type indicates the attributes to extract from the inbound document. For 
more information, see “Document Attributes” on page 27.
Pre-processing options. In a TN document type, you can specify pre‐processing options 
that Trading Networks performs before it performs the actions specified by a 
processing rule. For more information, see “Pre‐processing Actions” on page 38.
Trading Networks supports TN document types for two categories of documents: 
XML documents

Flat file documents
For more information about how Trading Networks uses TN document types at run time, 
see “Recognition Processing” on page 55.

TN XML Document Types

TN XML document types define how Trading Networks recognizes XML documents, where 
to locate attributes within an XML document, and how to pre‐process the XML 
documents.
To define TN XML document types, you specify the following types of information: 
Identification information. Trading Networks checks XML documents against the 
identification information to determine whether the document matches a defined TN 
XML document type. When you define the identification information for a TN XML 
document type, you can specify one or more of the following:
Root tag that the XML document must have to match the TN XML document 
type.
Identifying queries, which are XQL queries that Trading Networks performs 
against the XML document to locate specific nodes in the XML document. The 
nodes must be present for Trading Networks to consider the TN XML document 
type a match. Optionally, you can specify the value the node must have.
Pipeline variables that must be present when Trading Networks is determining 
the TN XML document type to use. The pipeline variables that you specify must 
exist for Trading Networks to consider the TN XML document type a match. 
Optionally, you can specify the value the pipeline variables must have.
Extraction information. Specifies the attributes (system attributes and custom attributes) 
that you want Trading Networks to extract from XML documents. You define XQL 

webMethods Trading Networks Concepts Guide Version 7.1 31

 3. Setting Up Trading Networks to Process Documents

queries that Trading Networks uses to locate the attributes within the XML 
documents. For Trading Networks to extract a value, the node that the XQL query 
identifies must exist in the XML document. Optionally, in the extraction information, 
you can specify that you want Trading Networks to use a built‐in transformation or 
invoke a custom transformation service against the attribute value to alter the value of 
the extracted attribute. For example, you might want Trading Networks to transform 
a STRING value into all uppercase characters.
Namespace mappings. If the XML documents use namespaces, you should specify 
namespace mappings to describe the namespaces that XML documents might use. 
Namespaces are used in an XML document to distinguish between elements that come 
from different sources. A set of elements (or tags) from a specific source is assigned to 
a specific namespace. Each namespace is associated with a URI, which is used to 
uniquely identify the namespace. Namespace mappings map the prefixes used by 
namespaces to the URIs used by those namespaces. For more information about XML 
namespaces, see the XML Namespace specification at http://www.w3.org/.
When you define namespace mappings in a TN XML document type, Trading 
Networks uses the namespace mappings you specify when applying XQL queries 
against the XML document. That is, Trading Networks uses the namespace mappings 
for both the identifying XQL queries and the XQL queries to extract attributes. 
Options. You can use the options to define items for later processing. When specifying 
the options for an XML document, you can specify: 
An IS document type that defines the structure of the XML document and that 
can be used to parse the XML document into an IData object. Trading Networks 
uses the IS document type if you invoke the wm.tn.doc.xml:bizdocToRecord service to 
convert the document content in the BizDocEnvelope to an IData object.
An IS schema that defines the structure of the XML document. Trading Networks 
uses this IS schema if you indicate you want to Trading Networks to perform the 
pre‐processing action to validate the structure of the XML document.
Whether you want Trading Networks to perform any or all of the pre‐processing 
actions. Pre‐processing actions are actions that Trading Networks performs before 
using the processing rule actions to process the XML document. For more 
information, see “Pre‐processing Actions” on page 38.

Note: You specify pre‐processing actions in both TN XML document types and 
processing rules. The pre‐processing actions in a processing rule indicate whether 
Trading Networks is to use the settings from the TN document type or to override 
the TN document type settings. 

Whether you want Trading Networks to process a document using a processing 
rule or want to prevent Trading Networks from performing processing rule 
actions. When you disable processing rule routing, Trading Networks only 
performs the pre‐processing actions specified in the TN document type; it does 
not search for a processing rule, nor does it perform any processing rule actions. 

webMethods Trading Networks Concepts Guide Version 7.1 32

 3. Setting Up Trading Networks to Process Documents

For more information about:

How to define TN XML document type, see Chapter 14, ʺDefining and Managing 
TN XML Document Typesʺ in the webMethods Trading Networks Administrator’s 
Guide.
How to define document attributes, see Chapter 13, ʺDefining and Managing 
Document Attributesʺ in the webMethods Trading Networks Administrator’s Guide

TN Flat File Document Types

TN flat file document types are definitions that Trading Networks uses to recognize flat file 
documents.
Flat file documents present complex hierarchical data in a record‐based storage format 
which, unlike XML, does not embed structural information within the data. Trading 
Networks’ definition of a flat file is any file or document that has a format that is non‐
describing, that is, a document that does not contain metadata.
In other words, flat file data is externalized as a set of records (list of records containing 
fields and composites) without any structural information. As the records are not 
structured in the document, the application receiving the flat file must have knowledge of 
the structure of a flat file to read its content. When you want to process a flat file 
document through Trading Networks, the application that initially receives the flat file 
document is a document gateway service that you create.

Document Gateway Services

For Trading Networks to process a flat file document, you must create a document gateway 
service (also referred to as a gateway service). The main function of the document gateway 
service is to provide hints that Trading Networks uses to recognize the type of flat file 
document; that is, to determine which TN flat file document type the incoming flat file 
matches.
Document gateway services are the entry points for flat files into Trading Networks. That is, 
rather than sending flat files directly to Trading Networks, your trading partners send their 
flat files to a document gateway service. After the gateway service executes, it passes control 
to Trading Networks.
A document gateway service performs the following:
Provide hints to Trading Networks to indicate the TN flat file document type to use for 
the flat file document. The service provides these hints in the TN_parms variable, 
which is located at the root of the pipeline. 
Specifies the attributes and their values. Because Trading Networks does have 
knowledge of the structure a flat file document, it cannot extract values for attributes. If 
you want to use document attributes, the gateway service must supply the values. 

webMethods Trading Networks Concepts Guide Version 7.1 33

 3. Setting Up Trading Networks to Process Documents

Records the name of the gateway service in the pipeline. This allows Trading 
Networks to be able to obtain the name of the gateway service and record it in its 
database. Because Trading Networks records the name of the gateway service, you 
can resubmit the document if necessary.
Passes the flat file document to Trading Networks to continue processing.

Information You Supply to Define TN Flat File Document Types

The information you provide in a TN flat file document type indicates how to match a flat 
file document to a TN flat file document type, specify the attributes that Trading 
Networks is to associate with the flat file document, and specify options for 
pre‐processing the flat file.
To define TN flat file document types, you specify the following types of information: 
Identification information. Trading Networks checks pipeline hints against the 
identification information to determine whether to use the TN flat file document type 
for the flat file document. When you define the identification information for a TN flat 
file document type, you can specify pipeline variables that must be present. The 
pipeline variables will be present if the document gateway service places them in the 
pipeline hints. Optionally, you can specify the value the pipeline variables must have.
Extraction information. Specifies the attributes (system attributes and custom attributes) 
that you want Trading Networks to associate with the flat file document. Trading 
Networks looks in the pipeline for the attributes that you define in the TN flat file 
document type. If the document gateway service placed the attribute with its value in 
the pipeline, Trading Networks can associate the attribute with the flat file document.
For TN flat file document types, the SenderID and ReceiverID system attributes are 
always required.
Options. You can use the options to define items for later processing. When specifying 
options for a flat file document, you can specify:
A  flat file schema that Trading Networks can use to perform the pre‐processing 
action to validate the structure of the flat file document.
Whether you want Trading Networks to perform any or all of the pre‐processing 
actions. Pre‐processing actions are actions that Trading Networks performs before 
using the processing rule actions to process the flat file document. For more 
information, see “Pre‐processing Actions” on page 38.

Note: You specify pre‐processing actions in both TN flat file document types and 
processing rules. The pre‐processing actions in a processing rule indicate whether 
Trading Networks is to use the settings from the TN document type or to override 
the TN document type settings. 

webMethods Trading Networks Concepts Guide Version 7.1 34

 3. Setting Up Trading Networks to Process Documents

Whether you want Trading Networks to process a document using a processing 
rule or want to prevent Trading Networks from performing processing rule 
actions. When you disable processing rule routing, Trading Networks only 
performs the pre‐processing actions specified in the TN document type; it does 
not search for a processing rule, nor does it perform any processing rule actions. 

For more information about:

How to define TN flat file document types, see Chapter 15, ʺDefining and 
Managing TN Flat File Document Typesʺ in the webMethods Trading Networks 
Administrator’s Guide.
Flat file schemas and parsing flat files, see the Flat File Schema Developer’s Guide.

Unknown TN Document Type

Each document that passes through your system should match exactly one TN document 
type. To determine the TN document type to use for a document, Trading Networks looks 
at all enabled TN document types for that type of document. That is:
For XML documents, Trading Networks matches documents against all enabled TN 
XML document types. 
For flat file documents, Trading Networks matches the flat file against all enabled TN 
flat file document types. 
An unknown document type can occur when a document (XML or flat file):
Does not match any TN document type.

Matches more than one TN document type. The document is considered to be an unknown 

type because Trading Networks does not know which of the multiple matching TN 
document types to use. In this situation, Trading Networks logs a message to the 
activity log that identifies all the TN document types that the document matched.
When Trading Networks cannot match a document to exactly one TN document type:
Trading Networks cannot extract any attribute information from the document; a TN 
document type identifies the attribute information to extract.
Processing rule routing will be enabled for this document; a TN document type is 
where routing can be disabled.
Trading Networks will still attempt to process documents with an unknown TN 
document type by performing the actions identified in the processing rule that the 
document triggers. You can set up processing rules that act on documents with an 
unknown TN document type.

webMethods Trading Networks Concepts Guide Version 7.1 35

 3. Setting Up Trading Networks to Process Documents

Processing Rules
Processing rules specify how you want Trading Networks to process documents. 
Processing rules define the actions that you want Trading Networks to take for a 
particular document. For example, you might want Trading Networks to send an alert 
e‐mail message to a contact and then deliver the document to the receiver that is identified 
in the document.
For each document that Trading Networks is to process, it performs a processing rule 
lookup to determine which processing rule to use. To perform the lookup, Trading 
Networks uses criteria that you define in processing rules. Trading Networks matches 
information from the document against the criteria you specify. After Trading Networks 
locates a matching processing rule based on the criteria, it takes the actions that you 
specify in the matching processing rule.
Processing Rules

If the document information ...perform the pre-processing and

matches the processing rule processing actions specified in the
criteria... processing rule.

Information from Document Processing Criteria Pre-processing Actions Processing Actions

sender sender verify Execute a service
receiver receiver validate Send an alert e-mail
document type document type check duplication Change the user status
user status user status save Deliver the document to the receiver
errors? errors? Respond with a message
custom attributes custom attributes

bizdoc
Processing Rules

Trading Networks

Note: If you do not want Trading Networks to perform any processing actions, you disable 
processing rule routing for documents in the TN document type. When processing rule 
routing is disabled, Trading Networks does not lookup a processing rule. It performs the 
pre‐processing actions as defined in the TN document type, but does not perform any 
processing actions.

For more information about how to define processing rules, see Chapter 16, ʺDefining and 

Managing Processing Rulesʺ in the webMethods Trading Networks Administrator’s Guides

webMethods Trading Networks Concepts Guide Version 7.1 36

 3. Setting Up Trading Networks to Process Documents

Processing Rule Criteria

The purpose of the criteria in a processing rule is to identify the documents Trading 
Networks should process using the processing rule. You can define criteria that uses one 
or more of the following:
The sender and receiver of the document. Trading Networks uses the values of the 
SenderID and/or ReceiverID system attributes (which identify the sender and receiver 
of the document) to determine the sending and/or receiving partner. Then it matches 
the sender or receiving partner from the document to the sender and receiver criteria 
you specify in the processing rule. For example, if you specify the sender criteria in a 
processing rule, Trading Networks uses the value extracted for the SenderID system 
attribute to find the profile for the sending partner. Then Trading Networks matches 
that partner to the sender criteria in the processing rule.
The TN document type. Trading Networks matches the TN document type used for the 
document against the TN document type criteria you specify in the processing rule. 
For example, if you have a TN document type for a cXML Purchase Order, you can 
define criteria to select a processing rule if the document matched the cXML Purchase 
Order TN document type.
The User Status system attribute. Trading Networks matches the value of the User Status 
system attribute to the user status criteria you specify in a processing rule. For 
example, you might set the User Status system attribute to PENDING in certain 
circumstances, and then you can define criteria to select a processing rule if the 
User Status system attribute is PENDING.
Whether Trading Networks encountered recognition errors. For example, you might set up 
processing rule criteria to select the processing rule only if Trading Networks did not 
encounter errors determining the TN document type to use.
The values of custom attributes. Trading Networks matches the values of the custom 
attributes that are associated with the document to the values you specify in the 
processing rule criteria. For example, if you have a custom attribute 
Total_Order_Amount, you can define criteria to select a processing rule if 
Total_Order_Amount is greater than $10,000.
If you specify more than one criterion, a document must match all the criteria for Trading 
Networks to select it.
For more information about how Trading Networks uses processing rule criteria at run 
time, see “Processing Rule Selection” on page 60.

webMethods Trading Networks Concepts Guide Version 7.1 37

 3. Setting Up Trading Networks to Process Documents

Pre-processing Actions
The pre‐processing actions specify actions you want Trading Networks to take before it 
processes the document using the processing actions you specify. For a list of the 
processing rule actions, see “Processing Rule Actions” on page 38. Use pre‐processing 
actions to instruct Trading Networks to: 
Verify the digital signature of a document

Validate the structure of a document

Determine whether the document has already been received by Trading Networks

Save the document content, attribute values, and/or activity log information to the 
database

Note:  You can specify pre‐processing actions in both TN document types and the 
processing rule. You can use the pre‐processing actions in the processing rule to override 
the actions that are specified in the TN document type.

For more information about how Trading Networks uses pre‐processing actions at run 
time, see “Pre‐processing Actions” on page 61.

Processing Rule Actions

The processing actions (also referred to as processing rule actions) specify how Trading 
Networks is to process a document. After Trading Networks locates the processing rule to 
use for a document (using the criteria), Trading Networks performs the actions specified 
in the processing rule to process the document. 
Trading Networks can perform the following processing actions: 
Execute a service that you create. Trading Networks can execute the service 
synchronously or asynchronously.
Send an alert e‐mail message.

Change the User Status system attribute that is associated with the document.

Deliver the document to the receiver identified in the document. Trading Networks 
can deliver the document in the following ways:
Immediately using delivery methods such as SMTP, HTTP, FTP, or FTPS by 
invoking a delivery service that you create.
At a later time using scheduled delivery. To schedule a document, Trading 
Networks places the document into a scheduled delivery queue that you define. 
When you define the queue, you associate the delivery schedule with the queue. 
At the times indicated by the delivery schedule, Trading Networks acts on the 

webMethods Trading Networks Concepts Guide Version 7.1 38

 3. Setting Up Trading Networks to Process Documents

documents that are in the queue. For more information about queues, see 
“Scheduled Delivery Queues and Processing Rules” on page 39.
Queue the document for polling. In this situation Trading Networks does not 
deliver the document; rather, the receiver polls for the document at a later time 
and Trading Networks returns the document in response to the polling.
For more information about delivery options, see Chapter 6, “Delivering Documents 
to Partners”.
Respond to the caller by sending a message back to the sender of the document. 
For more information about how Trading Networks uses processing actions at run time, 
see “Processing Rule Actions” on page 63.

Scheduled Delivery Queues and Processing Rules

If you want to use scheduled delivery, you need to define all queues that you will want to 
use before you can set up the delivery action in the processing rules. A scheduled delivery 
queue is a grouping of documents that are intended for one or more trading partners.
Trading Networks supports two types of scheduled delivery queues—public queues and 
private queues.
Public queues are queues that can contain documents for multiple receiving partners.

Private queues are queues that contains only delivery tasks that correspond to 
documents aimed for a specific receiving partner. You define private queues in the 
profile of the receiving partner.
For more information about using scheduled delivery to deliver documents, see 
“Scheduled Delivery” on page 77.

For more information about:

Defining private and public queues, see Chapter 17, ʺDefining and Managing 
Queues in Trading Networksʺ and Appendix K, ʺManaging Queues Using the 
Consoleʺ in the webMethods Trading Networks Administrator’s Guide. 
How to set up schedule delivery, see Chapter 18, ʺCreating Delivery Servicesʺ in 
the webMethods Trading Networks Administrator’s Guide. 

webMethods Trading Networks Concepts Guide Version 7.1 39

 3. Setting Up Trading Networks to Process Documents

webMethods Trading Networks Concepts Guide Version 7.1 40

Chapter 4. Sending Documents to Trading Networks for
Processing

Overview of Sending Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Sending Documents to Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Forwarding Documents to Another Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Sending a Document Back to the Same Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

webMethods Trading Networks Concepts Guide Version 7.1 41

 4. Sending Documents to Trading Networks for Processing

Overview of Sending Documents

To start the run‐time processing of Trading Networks, a document is sent to Trading 
Networks. The following lists some of the ways a document can be sent to Trading 
Networks:
A back‐end system can send a document to Trading Networks; for more information, 
see “Sending Documents to Trading Networks” on page 42.
A partner can send a document to Trading Networks; for more information, see 
“Sending Documents to Trading Networks” on page 42.
A partner’s Trading Networks system can deliver a document to your Trading 
Networks system; for more information, see “Forwarding Documents to Another 
Server” on page 46.
Your own Trading Networks system can send a document back to your system for 
processing; for more information, see “Sending a Document Back to the Same Server” 
on page 48.

Sending Documents to Trading Networks

To have Trading Networks process business documents, trading partners and back‐end 
systems send business documents to Trading Networks. For a trading partner to send 
business documents, it must create an application that communicates with the server. This 
application is called a client. Clients and back‐ends systems can use HTTP, HTTPS, FTP, 
FTPS, or SMTP to send the documents to Trading Networks.

Clients that Trading Partners Use to Send Documents

For a trading partner to send business documents, it must create a client that 
communicates with the server to send the business documents to the server. You can use 
any of the following types of clients:
Java client

C/C++ client

Visual Basic client

Excel client

Browser‐based client

webMethods Trading Networks Concepts Guide Version 7.1 42

 4. Sending Documents to Trading Networks for Processing

Service the Client Should Invoke

When a client sends a document to Trading Networks, it must specify the service that is to 
accept and process the document. For XML documents, the client should invoke the 
wm.tn:receive service. For flat files, the client should invoke a document gateway service 
you created, which in turn, invokes the wm.tn:receive service. For more information about 
flat files, see “Document Gateway Services” on page 33.
Trading Networks protects access to the wm.tn:receive service using an Access Control List 
(ACL). The protection assures only partners with Trading Networks administrative 
authority or partner authority can invoke this service. 

User Accounts for Partners

To invoke the wm.tn:receive service, the client must supply the user name and password of a 
valid My webMethods or Integration Server user account. When using a user account 
with Trading Networks administrative authority, Trading Networks always accepts and 
processes the document. However, you will typically not grant your partners 
administrative authority. Instead, they have user accounts that have Trading Networks 
partner authority.
When you create a profile for a partner, you can associate a user account with the profile, 
and therefore the partner. When you create a profile using:
My webMethods, you can associate one or more My webMethods users with the 
profile. When you associate a My webMethods user with a profile, Trading Networks 
automatically gives that My webMethods user partner authority.
Trading Networks Console, you can configure Trading Networks so that it 
automatically creates an Integration Server user account for the partner. The 
Integration Server user account that Trading Networks creates has partner authority.
When using a user account with partner authority, Trading Networks ensures that the 
user invoking the wm.tn:receive service matches the sender specified within the document 
being sent. Trading Networks uses the sender identified within the document to lookup 
the sender’s profile and ensures that the profile is associated with the My webMethods or 
Integration Server user account that was used to send the document. If the user account is 
not associated with the sender’s profile, Trading Networks does not process the 
document.
For more information about administrative and partner authority, see “Protecting Access 
to User Interfaces” on page 116.

webMethods Trading Networks Concepts Guide Version 7.1 43

 4. Sending Documents to Trading Networks for Processing

Protocols the Client Can Use

A Trading Networks client can send a document to the wm.tn:receive service using any of 
the following methods.

XML Flat File

Method document document Client
Post the document via HTTP All types of clients except 
D D
browser‐based clients
Post the document via HTTPS All types of clients except 
D D
browser‐based clients
Send a document via FTP All types of clients except 
D D
browser‐based clients
Send a document via FTPS All types of clients except 
D D
browser‐based clients
Send a document via SMTP All types of clients except 
D D
browser‐based clients
Submit the XML document in  All types of clients
D
the $xmldata variable

Note:  For more details about using each of the above methods for XML documents, see the 
chapter about passing XML data to services in the webMethods Developer User’s Guide.

For more information about creating clients, see the chapter about creating client code in 

the webMethods Developer User’s Guide. In the webMethods Developer User’s Guide, 
“clients” are referred to as “IS clients.”

Sending the Documents to Trading Networks

When a client or back‐end system sends a document to Trading Networks, it invokes one 
of the following:
For XML documents, the wm.tn:receive service

For flat files, the document gateway service you created, which in turn, invokes the 
wm.tn:receive service

webMethods Trading Networks Concepts Guide Version 7.1 44

 4. Sending Documents to Trading Networks for Processing

Clients and Back-end Systems Sending Documents to Trading Networks

1 3
Trading Networks
Client XML
(for a Trading Partner)
1. Recognize the document.
or 2 2. Extract the attributes.
3. Perform pre-processing.
back-end system Flat document gateway 4. Perform processing actions.
File service

Step Description

1 The client or back‐end system sends the document to Trading Networks.

2 If the document is a flat file, the client or back‐end system should invoke the 
document gateway service. For more information, see “Document Gateway 
Services” on page 33.

3 When Trading Networks receives the document, it processes the document as 
defined by TN document types and processing rules.
Trading Networks performs the following tasks to process the document:
1 Recognizes the document using the TN document types. If the document is 
a flat file, the document first goes to the document gateway service, then to 
Trading Networks for recognition. For more information, see “Recognition 
Processing” on page 55.
2 Extracts the attribute values from the document as instructed by the 
matching TN document type. For more information, see “Recognition 
Processing” on page 55.
3 Performs the pre‐processing actions against the document as defined in the 
TN document type and/or processing rule. For more information, see “Pre‐
processing Actions” on page 61.
4 Performs the processing actions against the document as defined in the 
processing rule. For more information, see “Processing Rule Actions” on 
page 63.
For more information, see Chapter 3, “Setting Up Trading Networks to Process 
Documents” and Chapter 5, “Trading Networks Document Processing”.

webMethods Trading Networks Concepts Guide Version 7.1 45

 4. Sending Documents to Trading Networks for Processing

Forwarding Documents to Another Server

One of your trading partners that is using Trading Networks might have their Trading 
Networks process a document and then use a processing rule to deliver the document to 
your Trading Networks system. In this situation, your partner’s Trading Networks system 
acts as a client to your Trading Networks system.
Your Partner’s Trading Networks System as a Client to Your Trading Networks System

Your Trading Partner’s Trading Networks

XML
Trading Networks
System
1. Recognize the document.
(acts as a client) 2. Extract the attributes.
3. Perform pre-processing.
Flat document gateway 4. Perform processing actions.
File service

Similarly, you might set up your Trading Networks system to delivery a document to a 
partner’s system. In this situation, your Trading Networks system becomes the client to 
your partner’s system.
Your Trading Networks System as a Client to Your Partner’s Trading Networks System
Your Trading Partner’s
Your Trading
Trading Networks XML Networks System
System
(acts as a client)

1. Recognize the document.

2. Extract the attributes.
3. Perform pre-processing. document gateway Flat
4. Perform processing actions. service File

To forward a document to another server, you can use either the Execute a service or the 
Deliver Document By processing actions. 

webMethods Trading Networks Concepts Guide Version 7.1 46

 4. Sending Documents to Trading Networks for Processing

Forwarding Documents to Another Integration Server

Trading Networks
Client

1
Trading Networks 4
Trading Networks
2 1. Recognize the document.
2. Extract the attributes.
3. Perform pre-processing. 1. Recognize the document.
3 2. Extract the attributes.
4. Perform processing actions;
deliver the document to another 3. Perform pre-processing.
Integration Server using: 4. Perform processing actions.
- Execute a service processing action
- Deliver Document By processing action

Step Description

1 A client or back‐end system sends a document to Trading Networks.

Note: In the above illustration, a document gateway service is not shown. If the 
document is a flat file, it would be processed by a document gateway service 
before being sent to Trading Networks for processing.

2 Trading Networks processes the document as defined by TN document types 
and processing rules.

3 The actions in the processing rule indicate to deliver the document to another 
instance of Trading Networks, that is, the target Trading Networks. You can use 
either the Execute a service or the Deliver Document By processing actions:
When you use the Execute a service processing action, Trading Networks 
executes a service that you specify. To forward the document the target 
Trading Networks, this service can invoke the wm.tn:receive service or a 
document gateway service on the target Integration Server. 
When you use the Deliver Document By processing action, Trading Networks 
sends the document being processed to the partner identified as the receiver 
in the document. Trading Networks uses the delivery information in the 
profile to determine how to send the document to the target Trading 
Networks. 

4 The Trading Networks receives the document and processes it as defined by its 
TN document types and processing rules.

webMethods Trading Networks Concepts Guide Version 7.1 47

 4. Sending Documents to Trading Networks for Processing

Sending a Document Back to the Same Server

You can have your own Trading Networks system send a document back to itself to have 
your Trading Networks system perform further processing. For example, Trading 
Networks receives a document from a partner. The document is in cXML format; 
however, the receiving partner requires the document in CBL format. When the document 
is originally received, the processing actions convert the document from cXML format to 
CBL format. After converting the document, the document can be sent to the receiving 
partner. To send the document to the receiving partner, send the document back into your 
Trading Networks system for processing. This CBL document triggers a different 
processing rule and the processing actions delivers the document to the receiving partner. 

Processing a Document Again on the Same Server

Trading Networks
Client

Trading Networks Second time, use a

4
2 processing rule that
1. Recognize the document. delivers the document
2. Extract the attributes. back to the receiving
3. Perform pre-processing. partner.
4. Perform processing actions.

3 First time, use a

processing rule that sends
the document back to the
same server.

Step Description

1 The client or back‐end system sends the original document (e.g., cXML 
document) to Trading Networks running on an Integration Server.

2 Trading Networks processes the document as defined by TN document types 
and processing rules. (For example, convert the document from cXML format to 
CBL format.) 

webMethods Trading Networks Concepts Guide Version 7.1 48

 4. Sending Documents to Trading Networks for Processing

Step Description

3 Additionally, the processing actions include logic to send the document back to 
the same Trading Networks for further processing (e.g., to deliver it to the 
receiving partner). To send the document back to the same Trading Networks:
For an XML document, use the wm.tn.doc.xml:routeXml service rather than the 
wm.tn:receive service.
For a flat file, use the wm.tn.doc.ff:routeFlatFile service rather than the 
wm.tn:receive service.
Trading Networks does not check the identity of the sender against the IS user 
account invoking the wm.tn.doc.xml:routeXml or wm.tn.doc.ff:routeFlatFile service. (That 
is, Trading Networks does not check to ensure that the user invoking the one of 
these services has Trading Networks partner authority and that the sender 
identified within the document is associated with the partner that sent the 
document.)

4 Trading Networks processes the document again; this time selecting a different 
TN document type and processing rule for the document. (For example, this 
time Trading Networks might select a processing rule that indicates that the 
document is to be delivered to the receiving partner.)

webMethods Trading Networks Concepts Guide Version 7.1 49

 4. Sending Documents to Trading Networks for Processing

webMethods Trading Networks Concepts Guide Version 7.1 50

Chapter 5. Trading Networks Document Processing

Overview of How Trading Networks Processes a Document . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Processing of Documents in Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Recognition Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Processing Rule Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Pre-processing Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Processing Rule Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Large Document Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

webMethods Trading Networks Concepts Guide Version 7.1 51

 5. Trading Networks Document Processing

Overview of How Trading Networks Processes a Document

Trading Networks uses the information you specify at design time to process a document 
at run time. It uses:
Sender’s profiles to ensure the user sending the document is an active partner in your 
network
Receiver’s profiles to obtain information specific to the receiving partner for processing 
document (e.g., the partner’s HTTP host name and port number if delivering a 
document via HTTP)
TN document types to recognize the type of document that was sent and to determine 
document attributes to associate with the document
Processing rules to determine the actions you want Trading Networks to perform 
against the inbound document
The run‐time processing that Trading Networks performs for an inbound document can 
be divided into four areas:
Recognition processing, which is determining the TN document type that matches the 
inbound document using the identification information that you defined in TN 
document types, and after locating the matching TN document type, obtaining the 
values of the document attributes that you specified in the TN document type.
Processing rule selection, which is determining the processing rule to use for the 
inbound document based on the criteria that you defined in processing rules.
Pre-processing actions, which is performing the pre‐processing actions that you defined 
in the TN document type and/or processing rule.
Processing actions, which is performing the processing actions that you defined in the 
processing rule.

webMethods Trading Networks Concepts Guide Version 7.1 52

 5. Trading Networks Document Processing

Processing of Documents in Trading Networks

The following illustrates how Trading Networks processes an inbound document. See the 
table below the diagram for more information.

How Trading Networks Processes Documents

3
Recognize TN
XML Document Type and
Extract Attributes

1 2 4
TN document bizdoc
Flat document gateway type
File service

5 6 7
Select the Perform Perform
Processing Rule to Pre-processing Processing
Use Actions Actions
- Execute a service
- Verify - Send an alert e-mail
- Validate - Change the user status
processing - Check for duplicate
rules - Deliver the document
- Save - Respond with a message

bizdoc

Step Description

1 Trading Networks is sent a document (for example an XML document or a flat 
file) to process. For information about how to send a document to Trading 
Networks, see Chapter 4, “Sending Documents to Trading Networks for 
Processing”.

2 If the document is a flat file, the document is first sent to a document gateway 
service. The document gateway service provides recognition hints that Trading 
Networks uses to help select the correct TN document type in the next step. For 
more information, see “Document Gateway Services” on page 33.

webMethods Trading Networks Concepts Guide Version 7.1 53

 5. Trading Networks Document Processing

Step Description

3 Trading Networks performs recognition processing. In recognition processing, 
Trading Networks recognizes the type of document using TN document types 
that you set up. 
For more information about TN XML document types, see “TN XML 
Document Types” on page 31. 
For more information about TN flat file document types, see “TN Flat File 
Document Types” on page 33.
If Trading Networks cannot determine the type of document, it considers the 
TN document type unknown. For more information, see “Unknown TN 
Document Type” on page 35.
If Trading Networks determines the type of document, it extracts specific pieces 
of information from the document based on the document attributes you 
specify in the TN document type. For more information about document 
attributes, see “Document Attributes” on page 27 and “How Document 
Attributes Relate to TN Document Types” on page 28.
For more information about this step, see “Recognition Processing” on page 55.

4 The output of the Trading Networks recognition processing is a BizDocEnvelope. 
A BizDocEnvelope contains the original document, the extracted attribute 
values, and additional information that Trading Networks requires for routing 
and processing the document. In other words, the BizDocEnvelope represents a 
routable Trading Networks transaction. Trading Networks places the 
BizDocEnvelope in the pipeline in the bizdoc variable.

Note: When you enable a TN document type for monitoring, Trading Networks 
creates a hash map within the BizDocEnvelope, and stores the monitoring 
attributes in it. These attribute values are then used to create events. For more 
information, see “Monitoring Trading Networks Transaction Data” on page 102.

Note: You can define a TN document type to indicate that you want to disable 
processing rule routing. If the TN document type that matched the incoming 
document indicates that processing rule routing is disabled, Trading Networks 
performs the pre‐processing actions defined by the TN document type. After 
that, Trading Networks does not perform a processing rule lookup, nor does it 
perform any processing rule actions. However, if the document is part of a 
business process, Trading Networks will pass the document to the Process 
Engine. For more information, see Chapter 7, “Sending Documents to Business 
Processes for Processing”.

webMethods Trading Networks Concepts Guide Version 7.1 54

 5. Trading Networks Document Processing

Step Description

5 Trading Networks performs processing rule selection. In this step, Trading 
Networks uses the processing rule criteria to locate the processing rule to use 
for the inbound document. For more information, see “Processing Rule 
Selection” on page 60.

6 Trading Networks performs pre‐processing actions that you define in either the 
TN document type or the processing rule. For more information, see “Pre‐
processing Actions” on page 61.

7 Trading Networks performs the actions you specify in the processing rule. For 
more information, see “Processing Rule Actions” on page 63.

Note: If Trading Networks successfully extracted the ConversationID system 
attribute from a document, Trading Networks passes the document to the 
Process Engine for the document to be processed in a business process. You 
define the actions taken in the business process by creating a process model. For 
more information, see Chapter 7, “Sending Documents to Business Processes 
for Processing”.

Recognition Processing
When Trading Networks receives an inbound document, the first step is recognition 
processing; that is, determining the TN document type to use. 
After determining the TN document type, Trading Networks uses the matching TN 
document type to determine the document attribute values to associate with the 
document and the initial list of pre‐processing actions to perform against the document.

Note:  You can specify pre‐processing actions in both TN document types and the 
processing rule. You can use the pre‐processing actions in the processing rule to override 
the actions that are specified in the TN document type.

The final step of recognition processing is to form a BizDocEnvelope that contains the 
original document, the extracted attribute values, and additional information that Trading 
Networks requires for routing and processing the document. The BizDocEnvelope is 
passed to other processing in the bizdoc variable in the pipeline.
Recognition processing varies based on whether the inbound document is an XML 
document or a flat file document.

webMethods Trading Networks Concepts Guide Version 7.1 55

 5. Trading Networks Document Processing

Recognition of XML Documents

When Trading Networks receives an XML document, it uses the identification 
information in the TN XML document type to determine the matching TN XML 
document type. The identification information can be the one or more of the following:
Root tag of the XML document. If you use the root tag for identification, Trading 
Networks only uses the TN XML document type if the root tag of the inbound XML 
document matches the root tag that you specify in the identification information of 
the TN XML document type.
Identifying XQL queries. If you use identifying queries, Trading Networks performs the 
XQL query against the inbound document. Trading Networks only uses the TN XML 
document type if the node represented by the XQL query is in the inbound XML 
document. Additionally, if you specify a value for the identifying query, Trading 
Networks also ensures that the value of the node represented by the XQL query 
matches the value you specified in the identification information; if not, Trading 
Networks will not use the TN XML document type for the inbound XML document.
Pipeline values that must be present. Trading Networks inspects the pipeline for the 
variables that you specified in the TN XML document type. Trading Networks only 
uses the TN XML document type if the variables you specify exist. Additionally, if you 
specify a value for the pipeline variables, Trading Networks also ensures that the 
value of the pipeline variable matches the value you specified in the identification 
information; if not, Trading Networks will not use the TN XML document type for the 
inbound XML document
After determining the TN XML document type to use, Trading Networks extracts the 
values of the document attributes associated with the TN XML document type by 
executing the XQL queries for the document attributes.

For more information about how to define TN XML document type, see Chapter 14, 

ʺDefining and Managing TN XML Document Typesʺ in the webMethods Trading 
Networks Administrator’s Guide.

Recognition of Flat Files

A flat file document is first sent to a document gateway service; then the document 
gateway service passes the document to Trading Networks.

Document Gateway Services During Flat File Recognition

For flat files, processing begins with a document gateway service that you must create. 
Your document gateway service must place recognition hints in the pipeline in the 
TN_parms variable, which must be in the root of the pipeline. 
The recognition hints the document gateway service places in the TN_parms variable can 
be:

webMethods Trading Networks Concepts Guide Version 7.1 56

 5. Trading Networks Document Processing

Pipeline variables that you use in the identification information of TN flat file 
document types
Optionally, the name of the TN flat file document type you want Trading Networks to 
use for the flat file
Additionally, the document gateway service can place attributes along with their values in 
the pipeline. Because the attributes are in the pipeline, Trading Networks can include the 
attributes in the BizDocEnvelope if instructed to do so by the matching TN flat file 
document type.
The values that your document gateway service places in the pipeline can be hardcoded, 
extracted from the content of the flat file, or derived by some other means.
The following diagram shows how a flat file document flows through Trading Networks 
and how Trading Networks performs document recognition on that flat file.

TN Flat File Document Type Runtime Overview

Trading Networks 4
Recognize TN
3 Document Type and 5
Extract Attributes
Continue
bizdoc
with Trading
tn:receive Networks
processing
TN document
type

1 2
document gateway
service
Flat File
Document Integration Server

Step Description

1 A user sends a flat file document to a Trading Networks document gateway 
service. 

Note: Trading Networks considers incoming documents with the “text/plain” 
content type as flat file documents by default. You can register other content 
types as flat file documents as well. Use the tn.ff.contenttypes property in the 
properties.cnf file to register additional flat file content types. For more 
information, see the “Flat File Properties” in the Trading Networks properties 
online help.

webMethods Trading Networks Concepts Guide Version 7.1 57

 5. Trading Networks Document Processing

Step Description

2 The flat file document passes through the document gateway service, which 
provides information hints needed by Trading Networks for flat file document 
recognition. 

Note: Because Trading Networks looks for these hints in TN_parms, 
applications that want to pass data into Trading Networks should place the 
data in the TN_parms variable, which is located at the root of the pipeline.

The document gateway service performs the following:
Specifies values for at least one of the following system attributes: 
SenderID, ReceiverID, GroupID, ConversationID, DocumentID, and 
DoctypeID or DoctypeNameID in the TN_parms variable in the pipeline. 
These could be hardcoded in the gateway service, derived from the 
document content, or derived by some other means.
Optionally, adds custom (user‐defined) attributes to the pipeline in the 
TN_parms variable.
Invokes the wm.tn:receive or wm.tn.doc.ff:routeFlatFile service.

3 The wm.tn.receive service recognizes the flat file data and creates a bizdoc from it.

4 The wm.tn.receive service invokes the Trading Networks recognition process, 
which determines the TN flat file document type to use for the file. 

Note: If you specify the document type ID or the document type name, (i.e., the 
gateway service sets the variable DoctypeID or the variable DoctypeName 
within TN_parms), Trading Networks will not attempt to determine which TN 
flat file document type to use. Instead, Trading Networks skips this step and 
will use the TN flat file document type specified by DoctypeID or DoctypeName.

Trading Networks completes the bizdoc by filling in attribute values. The TN 
document type has certain custom attributes associated with it. If there is a 
variable in the pipeline for a custom attribute (set by the gateway service), 
Trading Networks sets the value of that attribute in the bizdoc.
The Trading Networks recognition process returns a bizdoc and information 
about the sender and receiver. Trading Networks adds the bizdoc to the 
pipeline.

webMethods Trading Networks Concepts Guide Version 7.1 58

 5. Trading Networks Document Processing

Step Description

5 At this point, Trading Networks handles the flat file bizdoc just like a bizdoc 
formed from an XML document. 
If processing rule routing is enabled, Trading Networks continues with the 
pre‐processing actions and the actions specified in the processing rules.
If the TN document type disabled processing rule routing, Trading 
Networks performs the pre‐processing actions defined by the TN 
document type. After that, Trading Networks does not perform a 
processing rule lookup, nor does it perform any processing rule actions. 
However, if the document is part of a business process, Trading Networks 
will pass the document to the Process Engine. For more information, see 
Chapter 7, “Sending Documents to Business Processes for Processing”.

Trading Networks Processing During Flat File Recognition

When Trading Networks receives a flat file, it uses the identification information in the TN 
flat file document type to determine the matching TN flat file document type. 
If your document gateway service places in the pipeline the name of the TN flat file 
document type that you want to use for the flat file, Trading Networks does not search 
for a matching TN flat file document type; rather it uses the TN flat file document 
type you specify.
If you do not place in the pipeline the name of the TN flat file document type to use, 
Trading Networks determines the TN flat file document type to use.
To determine the TN flat file document type to use, Trading Networks inspects the 
pipeline for the variables that you specified in the identification information of your 
TN flat file document types. Trading Networks only uses a TN flat file document type 
if the variables you specify in a TN flat file document type exist in the pipeline. 
Additionally, if you specify a value for the pipeline variables, Trading Networks also 
ensures that the value of the pipeline variable matches the value you specified in the 
identification information; if not, Trading Networks will not use the TN flat file 
document type for the inbound flat file.
After determining the TN flat file document type to use, Trading Networks obtains the 
values of the document attributes associated with the TN flat file document type. To do so, 
for each attribute identified in the TN flat file document type, Trading Networks checks 
the pipeline for the attribute. If your document gateway service placed a value for the 
attribute in the pipeline, Trading Networks obtains the value for that attribute and 
includes it in the BizDocEnvelope for the flat file.

For more information about how to define TN flat file document type, see Chapter 15, 

ʺDefining and Managing TN Flat File Document Typesʺ in the webMethods Trading 
Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 59

 5. Trading Networks Document Processing

Processing Rule Selection

To determine the processing rule to use, Trading Networks matches information from the 
inbound document against the criteria you specify in processing rules. The information 
from the document that you can use as processing rule criteria is:
Sender identified in the inbound document

Receiver identified in the inbound document

TN document type Trading Networks is using for the inbound document

Value of the User Status system attribute of the document

Whether Trading Networks encountered errors during recognition processing (e.g., 
sender identified in the document does not have a profile in your Trading Networks 
system or Trading Networks was unable to extract an attribute that you marked as 
required)
Values of the custom attribute values that Trading Networks extracted from the 
document
Trading Networks uses all the criteria you specify in a processing rule to determine 
whether the inbound document matches. All processing rule criteria must match for 
Trading Networks to select the processing rule. For example, you might set up the 
following criteria:

Criterion Value(s) To match...

Sender “Any sender” The sender can be any value
Receiver “Industrial Steel Company” The receiver must be “Industrial 
“United Steel” Steel Company” or “United Steel”
TN Document Type “cXML Order Request” The TN document type must be 
“cXML Order Request”
User Status “Needs approval” The user status must be “Needs 
approval”
Recognition Errors “has no errors” The document cannot have 
recognition errors

If a document matches more than one processing rule, Trading Networks uses the first 
processing rule it encounters. As a result, the order in which you maintain your processing 
rules is important because Trading Networks checks for a matching processing rule in that 
order. Keep rules with specific criteria before rules with general criteria. You should also 
set up a default processing rule that you want Trading Networks to use when a document 
does not match any of the other processing rules. Place the default processing rule last in 
the list.

webMethods Trading Networks Concepts Guide Version 7.1 60

 5. Trading Networks Document Processing

For more information about how to define processing rule criteria and how to maintain the 

order of your processing rules, see Chapter 16, ʺDefining and Managing Processing 
Rulesʺ in the webMethods Trading Networks Administrator’s Guide.

Pre-processing Actions
After selecting the processing rule, Trading Networks has the list of pre‐processing actions 
specified in the TN document type and the list of pre‐processing actions specified in the 
selected processing rule. 

Note:  The pre‐processing actions in the processing rules can override the pre‐processing 
actions specified in the a TN document type.

Each pre‐processing action in the processing rule, can indicate one of the following:
Use the setting in the TN document type

Perform the pre‐processing action regardless of the setting in the TN document type

Not perform the action regardless of the setting in the TN document type
The following list the pre‐processing actions. Trading Networks performs the pre‐
processing actions in the order specified.
Verify Digital Signature. For this pre‐processing action Trading Networks verifies the 
digital signature of the inbound document. This pre‐processing action verifies:
The digital signature to assure that the signed body of the inbound document has 
arrived unchanged. 
The sender is who it claims to be by matching the certificate from the digital 
signature to the certificate that Trading Networks has on file for the partner.
Validate Structure. For this pre‐processing action Trading Networks validates the 
structure of the document against an IS schema. Trading Networks assures that the 
document matches the structure identified by the IS schema (using the 
pub.schema:validate built‐in service).
Check for Duplicate Document. For this pre‐processing action, Trading Networks 
determines whether there is a duplicate of the document; that is, if it has already 
received the document. You can have Trading Networks determine whether the 

webMethods Trading Networks Concepts Guide Version 7.1 61

 5. Trading Networks Document Processing

document has a duplicate using a built‐in duplication check that Trading Networks 
provides or using a custom duplicate check service that you create.
Built-in services. Trading Networks checks the document being processed against 
documents it has in its database. The built‐in duplication checks that Trading 
Networks provides are:
Document ID only. Trading Networks assures that it does not already have a 
document with same document ID in its database.
Document ID and sender. Trading Networks assures that it does not already 
have a document with same document ID and sender in its database.
Document ID, sender and receiver. Trading Networks assures that it does not 
already have a document with the same document ID, sender, and receiver in 
its database.
Document ID, sender and document type. Trading Networks assures that it does 
not already have a document with the same document ID, sender, and TN 
document type in its database.
Custom services. If you want to use another method to determine whether a 
document is a duplicate, you can create and use a duplication check service. 
Trading Networks saves the results of the duplication check to the pipeline. As a 
result, this information is available for use in the processing actions that you define in 
the processing rule. Additionally, Trading Networks uses the results of the 
duplication check in the Save Document to Database pre‐processing action. 
Save Document to Database. For this pre‐processing action Trading Networks saves a 
copy of the document content, attributes, and/or activity log information to the 
database. You can instruct Trading Networks to use the results of the duplication 
check for this pre‐processing action; that is, you can instruct Trading Networks to only 
save information to its database if the inbound document is not a duplicate.
Certain delivery options require saving the document content to the database, for 
example, if you want to deliver a document via a queue. If you do not select to save 
the document content and Trading Networks is to use a delivery option that requires 
document content to be saved, Trading Networks will automatically save the 
document.
Regardless of whether Trading Networks can perform a specified pre‐processing action or 
if errors result from a pre‐processing action, Trading Networks continues performing the 
rest of the pre‐processing actions. It also performs the processing actions that are defined 
in the processing rule. If Trading Networks is unable to perform a pre‐processing action or 
errors result, Trading Networks records the information to its activity log.

webMethods Trading Networks Concepts Guide Version 7.1 62

 5. Trading Networks Document Processing

For more information about:

How to define how to define pre‐processing actions in TN document types, see 
Chapter 14, ʺDefining and Managing TN XML Document Typesʺ and Chapter 15, 
ʺDefining and Managing TN Flat File Document Typesʺ in the webMethods Trading 
Networks Administrator’s Guide.
How to define pre‐processing actions in processing rules, see Chapter 16, ʺDefining 
and Managing Processing Rulesʺ in the webMethods Trading Networks 
Administrator’s Guide.

Processing Rule Actions

After performing the pre‐processing actions, Trading Networks performs the actions that 
you defined in the selected processing. The processing actions (also referred to as processing 
rule actions) specify how Trading Networks is to process the inbound document. If you 
select more than one of the processing actions, Trading Networks performs the actions in 
the order listed below:
Action 1: “Execute a Service Processing Action”

Action 2: “Send an Alert E‐mail Processing Action”

Action 3: “Change User Status Processing Action”

Action 4: “Deliver the Document to the Receiver Processing Action”

Action 5: “Respond with a Message Processing Action”
If Trading Networks encounters an error performing one of the actions, it will continue to 
attempt the other actions. For example, if the service specified in the rule does not exist, 
Trading Networks will receive an error attempting to invoke the service. In this situation, 
Trading Networks logs the error in the activity log and continues, attempting to send the 
alert e‐mail message and deliver the document to the receiver.

For more information about how to define processing actions in processing rules, see 

Chapter 16, ʺDefining and Managing Processing Rulesʺ in the webMethods Trading 
Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 63

 5. Trading Networks Document Processing

Pipeline Information that You Can Use in Processing Actions

Before defining the processing actions you want to use, it is useful to know what 
information is in the pipeline during processing.
If you select one of the following actions, you might want to use the pipeline information:

Processing action Use for pipeline variables

Execute a service You can use data in the pipeline in your service. For example, 
you might want to use the results of the Check Duplication of
Document pre‐processing action and perform one type of 
processing if the pre‐processing action indicated the document 
was a duplicate and different processing if the document is not 
a duplicate.
Send an Alert e-mail You can include information that is in the pipeline in the body 
of the e‐mail message. For example, if you want to send an 
e‐mail message that refers to the type of document, you can 
include the name of the TN document type.
Deliver Document by If you use a custom delivery service that you create, your 
delivery service can use information in the pipeline, for 
example to obtain the document content from the 
BizDocEnvelope in the bizdoc variable.
Respond with message You can include information that is in the pipeline in a 
message that Trading Networks is to return to the caller.

The following illustrates the information that Trading Networks places in the pipeline 
when a document is recognized.
Information in the Pipeline During Processing

Variable Description
bizdoc Contains the BizDocEnvelope that Trading Networks creates during 
recognition processing. The BizDocEnvelope contains the original document 
content and the extracted attribute values. This variable adheres to the 
wm.tn.rec:BizDocEnvelope IS document type.
sender  Contains information about the partner that is identified as the sender in the 
document. This variable adheres to wm.tn.rec:ProfileSummary IS document type.

webMethods Trading Networks Concepts Guide Version 7.1 64

 5. Trading Networks Document Processing

Variable Description
receiver  Contains information about the partner that is identified as the receiver in 
the document. This variable adheres to wm.tn.rec:ProfileSummary IS document 
type.

To see the actual structure of each of these IS document types, use the webMethods 
Developer to view the IS document types. All the IS document types are located in the 
wm.tn.rec folder that is in the WmTN package and each is described in the webMethods 
Trading Networks Built‐in Services Reference.

Note: The bizdoc variable is an instance of com.wm.app.tn.doc.BizDocEnvelope. The sender and 
receiver variables are instances of com.wm.app.tn.profile.ProfileSummary.

In addition to the information that Trading Networks normally places in the pipeline 
when executing a processing rule, if the processing rule specifies the Execute a service 
action and also indicates that Trading Networks is to invoke the service synchronously, 
the pipeline will contain any information placed in it by the service as well. The pipeline 
will also contain information from a gateway service, if a gateway service was used for a 
flat file.

Execute a Service Processing Action

Use the Execute a service action to have Trading Networks invoke a service that you specify. 
The service can perform any action you want. For example, you can execute a service to 
send the document to a back‐end system for processing or to update data in an internal 
system based on the values of attributes extracted from the document. You can have 
Trading Networks invoke the service one of the following ways:
Synchronous. Trading Networks invokes the service synchronously a single time. 
Before performing the rest of the processing actions, Trading Networks waits for the 
service to complete and then merges the results from the service into the pipeline. 
This allows you to use the service results in output templates or in other processing 
actions. If there are no subsequent processing actions, Trading Networks waits for the 
service to complete before returning to the caller that sent the document for 
processing.
Asynchronous. Trading Networks invokes the service asynchronously a single time. 
Trading Networks processes the remaining processing actions immediately. The 
results of the service are not available in the pipeline for the remaining processing 
actions. If there are no subsequent processing actions, Trading Networks immediately 
returns to the caller that sent the document for processing.
Service Execution Task. Trading Networks uses a service execution task to execute the 
service asynchronously. By using a service execution task, Trading Networks uses its 
reliable execution feature. The reliable execution feature allows Trading Networks to 
automatically retry failed services. If Trading Networks attempts to execute a service 

webMethods Trading Networks Concepts Guide Version 7.1 65

 5. Trading Networks Document Processing

and the service fails, Trading Networks attempts to execute the service subsequent 
times until the service succeeds or until Trading Networks reaches the maximum 
retry limit. If Trading Networks has reached the maximum retry limit and the service 
has not successfully executed, Trading Networks marks the service execution task as 
failed.
You define the system‐wide parameters that Trading Networks uses to determine 
how many times to attempt to re‐execute a failed service and how often to attempt the 
retries (how often to wait between the attempts to retry a service after a failed 
attempt).

Send an Alert E-mail Processing Action

Use the Alert e-mail action to send an e‐mail message to a specified contact. Recipients of 
the e‐mail message can be: 
One of the contacts defined in the sender’s profile

One of the contacts defined in the receiver’s profile

The webMethods system administrator 

Another e‐mail address that you specify 
When you use the Alert e-mail action, you specify the recipient that is to receive the e‐mail 
message, the subject line for the e‐mail message, and the body (or content) of the e‐mail 
message.

Change User Status Processing Action

Use the User Status action to change the value of the User Status system attribute that is 
associated with a document. The user status is a status that you can associate with a 
document.
The User Status action is used to assign a status to a document that you will use when 
performing document queries or generating reports. For example, you might require that 
purchase orders be approved. In this case, you can send an alert e‐mail message to the 
person responsible for approving the purchase order and set the user status to “pending 
approval”. To determine the purchase orders that are waiting for approval, users can 
query documents, searching for the user status “pending approval”.

webMethods Trading Networks Concepts Guide Version 7.1 66

 5. Trading Networks Document Processing

Deliver the Document to the Receiver Processing Action

When a processing rule includes the Deliver Document By processing action, Trading 
Networks attempts to deliver a document to the receiver that is identified in the 
document. Trading Networks delivers the document using the delivery method you 
specify in the processing rule. You can specify one of four ways to deliver a document:
Immediate delivery

Scheduled delivery

Queued for polling

Preferred protocol
Trading Networks automatically uses reliable delivery if you save the document content. 
Reliable delivery is a feature of Trading Networks where Trading Networks attempts to 
deliver a document to a partner subsequent times based on settings you define.
For more information about this processing action, see Chapter 6, “Delivering Documents 
to Partners”.

Respond with a Message Processing Action

Use the Respond with action to have Trading Networks return a specified message to the 
caller that sent the document to be processed. When you use the Respond with action, you 
must specify the message you want Trading Networks to return and the content type of 
the message. For example, you might use this action and return an acknowledgement that 
indicates that you received the document.

Large Document Handling

As installed, Trading Networks acts on all documents in the same manner regardless of 
their size. That is, Trading Networks receives the document and keeps the document 
content in memory during processing. However, if you receive large documents, Trading 
Networks can encounter problems when working with these documents because they 
constrain the system’s memory. These memory constraint problems can occur:
When Trading Networks attempts to execute an XQL query against an XML 
document; for example when Trading Networks first receives an XML document and 
uses the identifying queries to match an XML document to a TN XML document type 
and XQL queries to extract document attributes from an XML document.
When Trading Networks processes the document using signature verification, 
document validation, or the actions defined by processing rules.
If some or all of the documents that you need Trading Networks to process encounter 
problems due to memory constraints, you can set up Trading Networks to handle large 
documents in a different manner. That is, you can have Trading Networks write large 

webMethods Trading Networks Concepts Guide Version 7.1 67

 5. Trading Networks Document Processing

document content to hard disk drive space (referred to as tspace) and keep a reference to 
the large document content in memory rather than in the document content itself.

How Trading Networks Handles Large Documents Differently

When Trading Networks receives a document, it determines whether the document is 
large or not. You define how Trading Networks determines whether a document is large 
by setting a configuration property. You specify a number of bytes above which a 
document should be considered large. 
If a document contains a greater number of bytes than the value you configure, Trading 
Networks processes the document as a large document. That is, Trading Networks does not 
attempt to read the document content into memory. Rather, it writes the document 
content to disk and stores only a reference to the document content in memory. 
When Trading Networks needs to access the document content during processing, it 
checks to determine whether the document content is in memory or in hard disk drive 
space. If the document content is on disk (tspace), it accesses the document content from 
disk. Trading Networks either uses a Java InputStream to read the document content or it 
retrieves a certain number of bytes of the document content.
The document content remains on disk until both of the following occur:
The service that processes the document (and all services invoked from that service) 
complete.
The “time to live” period has expired. You set the time to live period using the 
Integration Server watt.server.tspace.timeToLive property.

For more information about:

How to configure Trading Networks to handle large documents, see Chapter 3, 
ʺConfiguring webMethods Trading Networksʺ in the webMethods Trading Networks 
Administrator’s Guide and the online help for TN Properties page, which you access 
via the Server Administrator.
Areas of Trading Networks that behave differently when you are working with 
large documents, see Appendix F, ʺLarge Document Handlingʺ in the webMethods 
Trading Networks Administrator’s Guide.

Items You Must Set Up Differently for Large Documents

If you set up Trading Networks to handle large documents differently, you must do the 
following differently:
Ensure the XQL queries you specify for TN document types only access the part of the XML
document that Trading Networks reads. When Trading Networks works with XML 
documents, it only reads a certain number of bytes of XML document to use for XQL 

webMethods Trading Networks Concepts Guide Version 7.1 68

 5. Trading Networks Document Processing

queries in TN document types. You configure the number of bytes that Trading 
Networks reads.
Ensure IS clients do not use the $xmldata variable to send large XML documents to Trading 
Networks. For more information about clients, see “Clients that Trading Partners Use 
to Send Documents” on page 42.
Code services to recognize when a document is large and take the appropriate actions based on
whether the document content is in memory or written to hard disk drive space. This affects:
Services you create to be invoked by the Execute a Service processing action.
Immediate delivery services you register to add addition immediate delivery 
methods. For more information, see “Adding Your Own Immediate Delivery 
Methods” on page 76.
Scheduled delivery services that you register to use with scheduled delivery 
queues. For more information, see “Scheduled Delivery Services” on page 80.

For more information about:

How to define TN XML document types, see Chapter 14, ʺDefining and Managing 
TN XML Document Typesʺ in the webMethods Trading Networks Administrator’s 
Guide.
How to create services to be invoked by the Execute a Service processing action, see 
Chapter 16, ʺDefining and Managing Processing Rulesʺ in the webMethods Trading 
Networks Administrator’s Guide.
How to create delivery services, see Chapter 18, ʺCreating Delivery Servicesʺ in the 
webMethods Trading Networks Administrator’s Guide.
Areas of Trading Networks that behave differently when you are working with 
large documents, see Appendix F, ʺLarge Document Handlingʺ in the webMethods 
Trading Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 69

 5. Trading Networks Document Processing

webMethods Trading Networks Concepts Guide Version 7.1 70

Chapter 6. Delivering Documents to Partners

Overview of Delivering Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

How Trading Networks Determines Delivery Method Information . . . . . . . . . . . . . . . . . . . . . . . . 73

Immediate Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Scheduled Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Queuing Documents for Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

webMethods Trading Networks Concepts Guide Version 7.1 71

 6. Delivering Documents to Partners

Overview of Delivering Documents

When a processing rule includes the Deliver Document By processing action, Trading 
Networks determines the delivery method to use to deliver the document to the receiving 
partner; the receiving partner is identified in the document by the ReceiverID.
Trading Networks can deliver documents using one of the following delivery options that 
you specify with the Deliver Document By processing action in a processing rule:
Immediate Delivery. Trading Networks attempts to deliver a document directly to the 
receiving partner. Trading Networks provides many built‐in immediate delivery 
methods. Additionally, you can add immediate delivery methods if the built‐in ones 
do not meet your needs. For more information, see “Immediate Delivery” on page 75.
Scheduled Delivery. Trading Networks queues documents to be delivered at scheduled 
times. You define scheduled delivery queues in Trading Networks. When you define 
the queue, you associate both a schedule and a scheduled delivery service with the 
queue. At the time(s) the schedule indicates, Trading Networks invokes the scheduled 
delivery service to act on the documents in the queue to deliver them. Trading 
Networks provides one built‐in scheduled delivery service. You can add additional 
scheduled delivery services to meet your needs. For more information, see 
“Scheduled Delivery” on page 77.
Queued for polling. Trading Networks places the document in an internally‐defined 
queue.The receiving partner later polls for documents, and Trading Networks returns 
all the documents in the queue for which that partner is the receiver. For more 
information, see “Queuing Documents for Polling” on page 82.
Receiver’s Preferred Protocol. Trading Networks looks up the receiver’s profile and uses 
the delivery method that is identified in the profile as the preferred delivery method. 
The preferred delivery method can be any of the immediate delivery methods, 
scheduled delivery, or queued for polling. 
When using immediate delivery or scheduled delivery, you can take advantage of the 
Trading Networks reliable delivery feature. Reliable delivery is a feature of Trading 
Networks where Trading Networks attempts to re‐deliver a document to a partner one or 
more times if previous attempts to deliver the document fails. For more information, see 
“Reliable Delivery with Immediate Delivery” on page 76 and “Reliable Delivery and 
Scheduled Delivery” on page 81.

For more information about queues in Trading Networks, see Chapter 17, ʺDefining and 

Managing Queues in Trading Networksʺ and Appendix K, ʺManaging Queues Using 
the Consoleʺ in the webMethods Trading Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 72

 6. Delivering Documents to Partners

How Trading Networks Determines Delivery Method Information

Depending on the delivery method, Trading Networks might require additional 
information from the receiving partner’s profile before it can deliver the document. The 
following lists some reasons Trading Networks needs to access the receiver’s profile for 
additional information:
When the Deliver Document By processing rule action indicates to use the Receiver’s Preferred
Protocol, Trading Networks must determine the delivery method that is designated as 
the preferred protocol.
To deliver the document using an immediate delivery method, Trading Networks requires 
information that is specific to the receiving partner before it can deliver the document. 
For example, if the delivery method is Primary HTTP, Trading Networks needs to 
determine the host name and port number to use to send the document via HTTP.
To deliver the document using the scheduled delivery method, “Receiver’s queue”, Trading 
Networks needs to determine the queue that is associated with the receiving partner.
For Trading Networks to obtain information from the receiver’s profile, it must first 
determine the partner that is the receiver. After it determines the receiving partner, 
Trading Networks looks up the information it requires from the receiver’s profile. For 
example, the illustration below shows how Trading Networks obtains information from 
the receiver’s profile, so it can deliver a document using HTTP. See the table below the 
diagram for more information.

How the Deliver Document By Action Works

Primary HTTP--
ReceiverID information: host: TN01 port: 5555
<DUNS>123456789</DUNS> DUNS: 123456789 location: /invoke/wm.tn/receive

Profile
Profile
Profile
Profile
Profile
1 2 4

http://TN01:5555/invoke/wm.tn/receive
3

Processing Rule
Deliver Document By: Primary HTTP

Trading Networks

webMethods Trading Networks Concepts Guide Version 7.1 73

 6. Delivering Documents to Partners

Step Description

1 Trading Networks receives a document and extracts the ReceiverID attribute 
from the document. In the above illustration, the value of the ReceiverID 
attribute is 123456789 and is found within the <DUNS> tag.

2 Trading Networks matches the value of the ReceiverID attribute to the external 
ID information stored for partners in the partner profiles. The profile that 
contains the matching external ID information is the profile for the receiving 
partner. In this illustration, the matching profile is for a partner that has the 
D‐U‐N‐S number 123456789. 

3 Trading Networks looks up the delivery method specified on the Deliver
Document By action of the processing rule in the receiving partner’s profile to 
obtain delivery information that is specific to that partner.
In this illustration, the Primary HTTP information defined in the matching 
partner profile indicates that Trading Networks is to deliver the document to 
the host name TN01 at port 5555 specifying the location /invoke/wm.tn/receive.

4 Trading Networks uses the delivery information specified in the profile to 
deliver the document. In this illustration, Trading Networks delivers the 
document to the receiver at the URL 
http://TN01:5555/invoke/wm.tn/receive.

For more information about how to define external IDs and delivery method information in 

profiles, see Chapter 9, ʺDefining and Managing Your Profile (Your Enterprise)ʺ, 
Appendix H, ʺManaging Your Profile Using the Consoleʺ, Chapter 10, ʺDefining and 
Managing Partner Profilesʺ, and Appendix I, ʺManaging Partner Profiles Using the 
Consoleʺ in the webMethods Trading Networks Administrator’s Guide.

When Delivery Information Cannot Be Determined

At times, Trading Networks might be unable to determine the required delivery 
information. For example:
The matching profile does not contain information for the delivery method that is 
specified in the processing rule. For example, the processing rule specifies the 
immediate delivery Secondary HTTPS, but the matching profile does not contain 
information for this delivery method. Or, the processing rule specifies to deliver to the 
receiver’s queue, but no queue is defined in the partner’s profile. 
The delivery method information from the matching profile is not valid.

The receiver’s profile status is Inactive, meaning Trading Networks cannot deliver 
documents to this partner until the partner is active.

webMethods Trading Networks Concepts Guide Version 7.1 74

 6. Delivering Documents to Partners

In these situations, Trading Networks logs the error to its activity log and queues the 
document for polling. For more information, see “Queuing Documents for Polling” on 
page 82.

Immediate Delivery
For an immediate delivery, Trading Networks attempts to immediately deliver a 
document directly to the receiving partner. 
Delivering Documents with an Immediate Delivery Method

Deliver to receiving
Processing Rule partner using
Deliver Document By: Primary HTTP immediate delivery
method

Trading Networks

Trading Networks provides many built‐in immediate delivery methods. Additionally, you 
can add immediate delivery methods if the built‐in ones do not meet your needs.

Immediate Delivery Methods Provided with Trading Networks

The following immediate delivery methods are provided out‐of‐the‐box:

Primary E-mail Secondary E-mail

Primary FTP Secondary FTP

Primary FTPS Secondary FTPS

Primary HTTP Secondary HTTP

Primary HTTPS Secondary HTTPS

Each immediate delivery method that Trading Networks provides is associated with a 
built‐in immediate delivery service that Trading Networks provides. An immediate delivery 
service is a service that acts on a single document to deliver the document to a single 
partner. Trading Networks invokes the delivery service to deliver a document to a trading 
partner.

webMethods Trading Networks Concepts Guide Version 7.1 75

 6. Delivering Documents to Partners

Adding Your Own Immediate Delivery Methods

If you need to deliver documents via a method that is not provided by one of the built‐in 
immediate delivery methods, you can add or register a new immediate delivery service. 
For example, you might want to create an immediate delivery service that delivers a 
message into a message queuing system. 
When you register a new immediate delivery service, you, in effect, add a new immediate 
delivery method. You assign the delivery service that you create a display name that 
Trading Networks uses to identify the delivery service. For example, you might add the 
service named TNDeliveryMethods:MsgQueue and assign it the display name of “Message 
Queue”. After you register a new immediate delivery service, the Trading Networks lists 
the display name (e.g., “Message Queue”) with the other immediate delivery methods 
available with the Deliver Document By processing action on the Processing Rules screen. As a 
result, the new immediate delivery method is available for you to select when you define 
processing rules.

For more information about how to create immediate delivery services and register them, 

see Chapter 18, ʺCreating Delivery Servicesʺ in the webMethods Trading Networks 
Administrator’s Guide.

Reliable Delivery with Immediate Delivery

Reliable delivery is a feature of Trading Networks where Trading Networks attempts to 
re‐deliver a document to a partner one or more times if previous attempts to deliver the 
document fails. 
To keep track of the attempts to re‐deliver a document, Trading Networks establishes a 
delivery task. When creating the delivery task, Trading Networks uses the reliable delivery 
settings from the receiving partner’s profile to establish the parameters for the delivery 
task. These parameters include:
How many times to try to re‐deliver a document to the partner

How long to wait between attempts to re‐deliver a document
Trading Networks’ task manager checks for delivery tasks that are eligible to be retried and 
retries them, updating the task status to indicate whether the delivery was successful or 
not and the number of times left to retry. If the task manager retries the delivery the 
maximum number of times and the delivery is still unsuccessful, it updates the delivery 
task status to FAILED and no longer attempts to retry delivery. If you determine the 
reason for failure and correct the problem, you can restart the delivery task and the task 
manager will start attempting to deliver the document again. 

webMethods Trading Networks Concepts Guide Version 7.1 76

 6. Delivering Documents to Partners

Delivery tasks remain in the Trading Networks system until you delete them or until the 
document with which the delivery task is associated is archived or deleted. You can view 
information about delivery tasks in:
My webMethods on the Monitoring > Integration > B2B > Tasks page

Trading Networks Console on the Tasks screen

For more information about how to view and restart tasks, see Chapter 4, ʺManaging Tasks 

from My webMethodsʺ and Chapter 9, ʺManaging Delivery Tasks from the Consoleʺ in 
the webMethods Trading Networks User’s Guide.

Using Reliable Delivery for an Immediate Delivery

When using an immediate delivery method to deliver a document to a trading partner, 
Trading Networks automatically uses reliable delivery if the pre‐processing action Save
Document to Database indicates that Trading Networks is to save the document content. You 
do not explicitly specify that you want Trading Networks to use reliable delivery for a 
document.

Note: If Trading Networks is not instructed to save the document content, it only 
attempts to deliver the document a single time. If the attempt to deliver the document 
fails, the document is not delivered. There is no way to have Trading Networks 
attempt to deliver the document again because it does not have a copy of the 
document content.

Scheduled Delivery
Scheduled delivery is a way to batch multiple documents that are acted on (delivered) at 
scheduled times. When the Deliver Document By processing action indicates a scheduled 
delivery method, Trading Networks creates a delivery task for the document and places the 
delivery task in the queue identified with the Deliver Document By processing action. The 
queue is associated with a schedule and a scheduled delivery service. At the times the 
schedule indicates, Trading Networks invokes the scheduled delivery service to act on the 
documents in the queue to deliver them.
Use scheduled delivery when it is more efficient to deliver a batch of documents at a time 
rather than deliver them immediately as they arrive. For example, if you want to deliver 
documents via FTP, you might want to use scheduled delivery, so you only open a 
connection one time, deliver all the documents in the queue, then close the connection, 
rather than delivering the documents with an immediate delivery method that requires 
the connection to be opened and closed for each document being delivered.
The following diagram illustrates scheduled delivery. See the table below the diagram for 
additional information.

webMethods Trading Networks Concepts Guide Version 7.1 77

 6. Delivering Documents to Partners

Delivering Documents with a Scheduled Delivery Method

1
processing
rules

bizdoc
Create a delivery task
for the document.
2
(The document is
contained in the
bizdoc.).
delivery task

scheduled delivery queue

delivery task
delivery task
delivery task Scheduled delivery service retrieves the
document content from the delivery task and
delivers it to the receiving partner

3 4
scheduled delivery service

Trading Networks

Step Description

1 Trading Networks receives a document, and the processing rule for the 
document includes the Deliver Document By processing action and indicates 
scheduled delivery.

2 Trading Networks establishes a delivery task for the document. The delivery 
task includes the BizDocEnvelope, which includes the content of the document. 
Trading Networks places the delivery task in the scheduled delivery queue that 
is identified with the Deliver Document By processing action.

3 When the schedule associated with the scheduled delivery queue indicates, 
Trading Networks invokes the scheduled delivery service that is associated 
with the scheduled delivery queue. The scheduled delivery service acts on each 
delivery task in the queue. 

4 The scheduled delivery service attempts to deliver the document to the 
receiving partner and indicates whether the delivery was successful or not. The 
status of the delivery task is updated accordingly. For more information, see 
“Reliable Delivery and Scheduled Delivery” on page 81.

webMethods Trading Networks Concepts Guide Version 7.1 78

 6. Delivering Documents to Partners

Scheduled Delivery Queues

A scheduled delivery queue is a queue that you define and that you use to batch documents 
that you want to deliver at scheduled times. When you define a queue, you specify:
The scheduled delivery service that Trading Networks is to invoke to deliver the 
documents
A delivery schedule that indicates when Trading Networks is to invoke the scheduled 
delivery service to deliver the documents

Note: A scheduled delivery queue is not a queue in the traditional sense. It is a set of rows 
in the Trading Networks database. Each queued delivery task that is associated with a 
document is a row in the same table of the Trading Networks database.

There are two types of scheduled delivery queues: public queues and private queues.
Public queue is a queue that you define to schedule the delivery of documents that are 
aimed at multiple different receiving partners. When you define a public queue, the 
name of the public queue is added to the list of queues you can select when specifying 
a scheduled delivery method with the Deliver Document By processing action.
Private queue is a queue that you define to schedule the delivery of documents that are 
aimed at one specific trading partner. You define a private queue in the profile of the 
partner to receive the documents. To use this queue, you select Receiver’s Queue for the 
scheduled delivery method of the Deliver Document By processing action. When the
Deliver Document By processing action indicates Receiver’s Queue, Trading Networks 
looks up the receiver’s profile and places the delivery task for the document to be 
scheduled in the queue identified in the receiver’s profile.

Note: When defining a queue in a partner’s profile, rather than creating a private 
queue, you can alternatively specify a public queue. In this situation, when Trading 
Networks encounters Receiver’s Queue for the Deliver Document By processing action, it 
looks up the receiver’s profile to determine whether the receiver’s queue is actually a 
public queue, and places the delivery task in the public queue.

For more information about:

How to define private and public queues, see Chapter 17, ʺDefining and Managing 
Queues in Trading Networksʺ and Appendix K, ʺManaging Queues Using the 
Consoleʺ in the webMethods Trading Networks Administrator’s Guide.
Selecting a queue for scheduled delivery in a processing rule, see Chapter 16, 
ʺDefining and Managing Processing Rulesʺ in the webMethods Trading Networks 
Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 79

 6. Delivering Documents to Partners

Scheduled Delivery Services

A scheduled delivery service is a service that acts on multiple documents to deliver those 
documents to one or more partners. You associate a scheduled delivery service with a 
scheduled delivery queue. You can use the same scheduled delivery service for multiple 
queues. Trading Networks invokes the scheduled delivery service at the times dictated by 
the delivery schedule that is also associated with the queue. 
When the scheduled delivery service is invoked, it acts on all of the delivery tasks in the 
queue that have the QUEUED status. These QUEUED delivery tasks include all of the 
delivery tasks already in the queue when the service is invoked and any new tasks added 
to the queue before the delivery service terminates. Each delivery task is associated with a 
document that needs to be delivered.
When the scheduled delivery service is invoked, it begins reading delivery tasks from the 
queue. When the scheduled delivery service reads a delivery task from the queue, the task 
is not actually removed from the queue. Instead, its task status is changed to identify the 
stage of delivery. 
After a scheduled delivery service attempts to deliver a document, it reports whether the 
delivery was successful or not. The Trading Networks task manager uses this outcome 
(success or fail) to update the status of the delivery task accordingly.

Scheduled Delivery Services Provided with Trading Networks

A single scheduled delivery service, the wm.tn.transport:batchFtp service, which uses FTP to 
deliver documents to a single destination is provided. This service opens a connection one 
time, delivers all the documents, and then closes the connection. You can use this 
scheduled delivery service for the queues you define.

For more information about the wm.tn.transport:batchFtp service, see the webMethods Trading 

Networks Built‐in Services Reference.

Adding Your Own Scheduled Delivery Services

If you want to deliver batches of documents using methods that are different from that 
provided by the built‐in wm.tn.transport:batchFtp service, you can create your own scheduled 
delivery services and register them with Trading Networks. 
When you register your own scheduled delivery service, you assign the delivery service a 
display name. Trading Networks uses the display name to identify the available 
scheduled delivery services in My webMethods and the Trading Networks Console. As a 
result, when you create a public or private queue, you can associate the scheduled 
delivery services that you define with a queue.

For more information about how to create and register a scheduled delivery service, see 

Chapter 18, ʺCreating Delivery Servicesʺ in the webMethods Trading Networks 
Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 80

 6. Delivering Documents to Partners

Reliable Delivery and Scheduled Delivery

Trading Networks automatically uses reliable delivery for a scheduled delivery method. 
When Trading Networks establishes the delivery task that is places in the scheduled 
delivery queue, it uses the reliable delivery settings from the receiving partner’s profile to 
establish the parameters for the delivery task. Specifically, it uses a setting from the 
receiving partner’s profile to define how many times it should attempt to re‐deliver a 
document that is scheduled for delivery.

Note: For scheduled delivery, Trading Networks does not use the reliable delivery 
parameter that indicates how long to wait between retry attempts. This is not necessary 
because Trading Networks retries the delivery based on the delivery schedule that is 
associated with the scheduled delivery queue.

After a scheduled delivery service attempts to deliver a document, it must report whether 
the delivery was successful or not. The Trading Networks task manager uses this outcome 
(success or fail) to update the status of the delivery task accordingly. If a document cannot 
be delivered, for example because the receiving partner’s server is not available, the task 
manager leaves the delivery task with the QUEUED status, and as a result, at the next 
scheduled time, the delivery task will be available again for the scheduled delivery service 
to attempt to deliver the document again.
The Trading Networks task manager keeps track of the number of times the delivery has 
been attempted. If the maximum retry limit is reached and the scheduled delivery service 
still reports that it was unable to deliver the document, the task manager marks the 
delivery task as FAILED. As a result, at the next scheduled time, the scheduled delivery 
service will not be given that delivery task to work with.
As with delivery tasks for immediate delivery, the delivery tasks remain in the Trading 
Networks system until you delete them or until the document that the delivery task is 
associated is archived or deleted. You can view information about delivery tasks in:
My webMethods on the Monitoring > Integration > B2B > Tasks

Trading Networks Console on the Tasks screen

For more information about how to view and restart tasks, see Chapter 4, ʺManaging Tasks 

from My webMethodsʺ and Chapter 9, ʺManaging Delivery Tasks from the Consoleʺ in 
the webMethods Trading Networks User’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 81

 6. Delivering Documents to Partners

Queuing Documents for Polling

Polling is a way that trading partners can obtain documents without having Trading 
Networks deliver documents directly to the partner, for example, because of firewall 
constraints. 
When the Deliver Document By processing action indicates Queue for polling, Trading 
Networks saves the document to the database and sets the documents processing status to 
POLLABLE. For Trading Networks to queue documents, it must save the document to the 
database. As a result, Trading Networks always saves the document to the database 
regardless of whether instructed to do so by the Save Document to Database pre‐processing 
action. Trading Networks then waits for the receiving partner to poll for the documents.
To poll for documents, the receiving partner determines the polling method (e.g., HTTP) 
to use to access your system to retrieve its documents. To do so, the receiving partner 
looks up your enterprise’s profile on its system. The delivery method information in your 
profile on the receiving partner’s system should identify the polling method to use and 
how often to poll for documents on your system.
Using the polling method, the receiving partner asks for each document in turn. In 
response, your system delivers the document to the receiving partner. The receiving 
partner returns a status for the document whether the document was accepted or 
accepted with errors. Your Trading Networks system updates the processing status of the 
document on your system accordingly, either setting it to ACCEPTED or 
ACCEPTED W/ ERRORS.

Polling for Documents

1. Request list of queued documents

Trading 2. Request a document Receiving

Networks partner
3. Indicate the document from Step 2 was received

The receiving partner repeats Steps 2-3

for each document in the list.

Note: When the delivery method is Queue for polling, Trading Networks does not use reliable 

delivery because Trading Networks does not deliver the document. It sends the document 
in response to a request from the partner that is to receive the document.

webMethods Trading Networks Concepts Guide Version 7.1 82

 6. Delivering Documents to Partners

When Trading Networks Uses Queue for Polling

Trading Networks uses the Queue for polling delivery method when the Deliver Document By 
processing action indicates one of the following:
Queue for polling selection

Receiver’s Preferred Protocol selection and the preferred protocol in the receiver’s profile 

is Queue for polling
When Trading Networks is unable to obtain delivery information for a delivery 
method from the receiving partner’s profile. For example, the Deliver Document By 
processing action indicates the immediate delivery method Secondary HTTPS, but the 
profile does not contain delivery information for the Secondary HTTPS delivery 
method. Or, another example is when the scheduled delivery method is Receiver’s
Queue, but no queue is defined in the receiving partner’s profile.

webMethods Trading Networks Concepts Guide Version 7.1 83

 6. Delivering Documents to Partners

webMethods Trading Networks Concepts Guide Version 7.1 84

Chapter 7. Sending Documents to Business Processes for
Processing

Overview of Sending Documents to Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

How You Define the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Conversation IDs for Trading Networks Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

How Documents Are Passed to a Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

webMethods Trading Networks Concepts Guide Version 7.1 85

 7. Sending Documents to Business Processes for Processing

Overview of Sending Documents to Business Processes

In addition to using processing rules, or as an alternative, you can define a business process 
(also called a conversation) that describes multiple steps required to process documents.
Use a business process when you want to process documents using a multi‐step business 
process that involves interaction among systems, people, and trading partners. A business 
process can be fully automated (involve only interaction among computer systems) or 
include varying degrees of human interaction (for example, review and approval steps).

How You Define the Business Process

You define the actions that take place in a business process by using webMethods 
Designer to design a process model. A process model is a diagram that shows the steps in 
the business process. 
To handle documents sent by Trading Networks, the process model describes how to 
process a conversation of related documents that all contain the same conversation ID. 
The process model can include steps to wait for actions required by a human. An example 
of a business process might be the fulfillment of a purchase order that includes a purchase 
order document, human interaction to determine whether to approve the purchase order, 
and either an order acknowledgment (ACK) document or an order negative 
acknowledgement (NACK) document.
You set properties for each step in the process model to further define the actions to take 
for a step. For example, you can set a step’s properties to identify a service to invoke.
webMethods Designer is a design‐time tool only. Before the process model can be 
executed, you must create run‐time elements for a process model. This is called building 
and uploading the process model. When you build and upload the process model, Designer 
generates triggers, flow services, etc. based on the steps in your process model and saves 
these run‐time elements in the Integration Server and in My webMethods Server. 
At run time the Process Engine, which is a facility of the Integration Server, manages the 
execution of business processes. The Process Engine executes the business process by 
using the appropriate run‐time elements that were generated from a process model.
Typically, a business process starts based on the arrival of a document. It is the 
responsibility of the Process Engine to determine the actions to take for a specific 
document. The Process Engine determines the process model to use for the document and 
defines a new instance of the process to govern the actions to take for the business process. 
When a subsequent document for the business process arrives, it is the Process Engine 
that determines the correct running instance of a process and rejoins the business process 
by passing it the document that just arrived. 
The way the Process Engine determines the documents that belong to a single instance of 
a business process is through the conversation ID. All documents in the same instance of a 
business process share the same conversation ID. So when the Process Engine receives a 

webMethods Trading Networks Concepts Guide Version 7.1 86

 7. Sending Documents to Business Processes for Processing

document, it determines whether it has a running business process that uses the 
conversation ID. If it does, the Process Engine passes the document to the running 
business process to rejoin the running business process. If there is no running business 
processes that uses that conversation ID, the Process Engine searches for a process model 
that has the first step that waits for the document, and if found, starts a new instance of 
the process model.
As the Process Engine manages the execution of a business process, it logs its progress 
and status to the Process Audit Log database. You can view the progress and status from 
My webMethods using webMethods Monitor.

For more information about:

How to create process models, see the webMethods Designer online help.

How to monitor running business processes, see the webMethods Monitor User’s 
Guide.

Conversation IDs for Trading Networks Documents

The conversation ID that business processes use is the Trading Networks ConversationID
system attribute. Your TN document type must extract this system attribute if you want to 
process documents using a business process. 
Trading Networks determines whether to pass a document to the Process Engine based on 
whether it has extracted a value for the ConversationID system attribute. If Trading 
Networks has a value for the ConversationID system attribute, it passes the document to 
the Process Engine, which in turn processes the document based on the steps in a business 
process. For more information, see “How Documents Are Passed to a Business Process” 
below.

For more information about:

Document attributes, see the Chapter 13, ʺDefining and Managing Document 
Attributesʺ in the webMethods Trading Networks Administrator’s Guide.
How to instruct Trading Networks to extract attributes and associate them with 
documents, see Chapter 14, ʺDefining and Managing TN XML Document Typesʺ 
and Chapter 15, ʺDefining and Managing TN Flat File Document Typesʺ in the 
webMethods Trading Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 87

 7. Sending Documents to Business Processes for Processing

How Documents Are Passed to a Business Process

Trading Networks does its own processing (document recognition and performing the 
pre‐processing actions and actions defined by a processing rule). Then, if Trading 
Networks was instructed to extract the ConversationID system attribute and it has a 
value, Trading Networks passes the document to the Process Engine. For a document to 
be used in a business process, the document must be sent to the Process Engine.

Note: If Trading Networks is to pass the document on to the Process Engine, Trading 
Networks always saves the attributes and activity log information for the document 
regardless of the setting of the Save Document to Database pre‐processing action.

The following diagram illustrates Trading Networks passing a document to the Process 
Engine. For more information, see the table after the diagram.

Processing documents using a business process

1
Recognize TN
Document Type and
Extract Attributes

2
TN document bizdoc
type

3 4 5
Select the Perform Perform
Processing Rule to Pre-processing Processing
Use Actions Actions 6
- Execute a service
- Verify - Send an alert e-mail
- Validate
Process
processing - Change the user status
- Check for duplicate - Deliver the document
Engine
rules - Save - Respond with a message

bizdoc

webMethods Trading Networks Concepts Guide Version 7.1 88

 7. Sending Documents to Business Processes for Processing

Step Description

1 When Trading Networks receives a document and determines the TN 
document type to use for the document. The TN document type should instruct 
Trading Networks to extract the ConversationID system attribute.

2 Trading Networks creates the BizDocEnvelope for the document. The 
BizDocEnvelope contains the original document, the extracted attribute values, 
and additional information that Trading Networks requires for routing and 
processing the document.

Note: You can define a TN document type to indicate that you want to disable 
processing rule routing. If the TN document type that matched the incoming 
document indicates that processing rule routing is disabled, Trading Networks 
performs the pre‐processing actions defined by the TN document type. After 
that, Trading Networks does not perform a processing rule lookup, nor does it 
perform any processing rule actions. Because the ConversationID was 
extracted, Trading Networks immediately passes the document to the Process 
Engine, which is described in step  6 .

3 Trading Networks performs processing rule selection. In this step, Trading 
Networks uses the processing rule criteria to locate the processing rule to use 
for the inbound document. For more information, see “Processing Rule 
Selection” on page 60.

4 Trading Networks performs pre‐processing actions that you define in either the 
TN document type or the processing rule. For more information, see “Pre‐
processing Actions” on page 61. 
If Trading Networks is to send a document to the Process Engine, it always 
saves the attributes and activity log information to its database.

5 Trading Networks performs the actions you specify in the processing rule, if 
any. For more information, see “Processing Rule Actions” on page 63.

6 Because the ConversationID system attribute contains a value, Trading 
Networks passes the document to the Process Engine. The Process Engine 
either:
Starts a new business process based on a process model that you have 
designed if the ConversationID does not match that of any running 
business process.
‐or‐
Rejoins a running business process if it determines that the ConversationID 
matches that of a currently running business process.

webMethods Trading Networks Concepts Guide Version 7.1 89

 7. Sending Documents to Business Processes for Processing

webMethods Trading Networks Concepts Guide Version 7.1 90

Chapter 8. Tracking and Viewing Run-Time Information in
Trading Networks

Run-time Information that You Can Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Viewing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Viewing Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Viewing the Activity Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Viewing the Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Using Trading Networks Web Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

webMethods Trading Networks Concepts Guide Version 7.1 91

 8. Tracking and Viewing Run-Time Information in Trading Networks

Run-time Information that You Can Track

Trading Networks gives you visibility into your network to track run‐time information 
about the documents that your Trading Networks system has sent/received, delivery and 
service execution tasks that have been run/started, and activity log entries relating to the 
server. You can use My webMethods and the Trading Networks Console to query 
run‐time information that Trading Networks has saved to its database;. Note that 
run‐time monitoring is deprecated in the Console.
The following table lists the run‐time information you can view, along with the My 
webMethods pages and Trading Networks Console screens to use to view the 
information:

Trading Networks
My webMethods page Console Screen To view:
Monitoring > Transaction Information about the documents that 
Integration > B2B > Analysis Trading Networks has saved to its database:
Transactions
Attributes that have been extracted from 
documents
Content of documents that have passed 
through your system
Status of documents that Trading 
Networks is in the process of delivering
In addition to viewing this information, 
Trading Networks also provides features you 
can use to resubmit and reprocess 
documents.
For more information, see “Viewing 
Documents” on page 93.
Monitoring > Task The progress and status of each delivery task 
Integration > B2B > and service execution task. In addition to 
Tasks viewing this information, Trading Networks 
also provides features you can use stop, 
restart, and delete tasks. For more 
information, see “Viewing Tasks” on page 94.
Monitoring > Activity Log Audit information of the activity that has 
Integration > B2B > occurred in your Trading Networks system. 
Activity Log For more information, see “Viewing the 
Activity Log” on page 96.

If you plan to use the same query multiple times, you can save the query settings. When 
you want to use the same query again, you simply select that saved query. 

webMethods Trading Networks Concepts Guide Version 7.1 92

 8. Tracking and Viewing Run-Time Information in Trading Networks

Note: My webMethods and Trading Networks do not share queries. Queries you save in 
one of the user interfaces cannot be used in the other user interface.

For more information about:

How to save searches in My webMethods, see the Getting Started with My 
webMethods.
How to perform queries in Trading Networks Console, see Chapter 12, ʺQueries in 
Trading Networks Consoleʺ in the webMethods Trading Networks User’s Guide.

Viewing Documents
You can view information about the documents that Trading Networks has saved to its 
database. You can:
Manage and track documents that have flowed through your trading network:
View document attributes and document content.
View related documents, which are other documents that are somehow related to a 
document. Trading Networks automatically relates documents that are part of a 
business process (or conversation). For more information about processes, see 
Chapter 7, “Sending Documents to Business Processes for Processing”. 
Additionally you can explicitly relate documents to one another using the 
wm.tn.doc:relateDocuments built‐in service. 
Manage and track the delivery of documents:
View the processing status of documents to determine whether they have been 
delivered, are still in the process of being delivered, or if the delivery failed.
View pollable documents that are queued for a trading partner.
View documents that are scheduled for delivery.
Add or update comments that are associated with a document. This feature is only 
available via My webMethods.
View tasks (delivery tasks and service execution tasks) that are associated with the 
document.
View activity log entries that are associated with the processing that Trading 
Networks has performed against a document.

webMethods Trading Networks Concepts Guide Version 7.1 93

 8. Tracking and Viewing Run-Time Information in Trading Networks

For more information about how to search for documents and display information about 

them, see Chapter 3, ʺManaging and Tracking Documents from My webMethodsʺ and 
Chapter 8, ʺManaging and Tracking Documents from the Consoleʺ in the webMethods 
Trading Networks User’s Guide.

Resubmitting and Reprocessing Documents

You can have Trading Networks process a document again, if necessary. For example, you 
might want to process a document again if the document did not match any of your TN 
document types or if the document triggered the wrong processing rule. In this type of 
situation, you could add an appropriate TN document type or correct your processing 
rules, then process the document again. For Trading Networks to be able to process a 
document again, the content of a document must be saved in the database.
There are two ways you can process a document again: resubmit or reprocess.
Resubmit. Trading Networks sends the document back to recognition processing as a 
new document. As a result, Trading Networks determines the TN document type for 
the document, extracts the document attributes, selects a processing rule, and 
processes the document. For more information about how Trading Networks 
performs these tasks, see Chapter 5, “Trading Networks Document Processing”.
Reprocess. Trading Networks sends the document back to processing rule selection. 
As a result, Trading Networks uses the TN document type it already has saved for the 
document as well as the document attributes it already has saved for the document. It 
simply selects a new processing rule and processes the document again. For more 
information about these actions, see “Processing Rule Selection” on page 60, “Pre‐
processing Actions” on page 61, and “Processing Rule Actions” on page 63.

For more information about how to reprocess and resubmit documents, see Chapter 3, 

ʺManaging and Tracking Documents from My webMethodsʺ and Chapter 8, 
ʺManaging and Tracking Documents from the Consoleʺ in the webMethods Trading 
Networks User’s Guide.

Viewing Tasks
You can view information specifically about tasks. Additionally, while viewing 
documents, you can view tasks that are associated with a specific document.

Note: If you are using an OEM version of the product, the Tasks screen is not available 
through the Trading Networks Console. To view tasks, use My webMethods.

webMethods Trading Networks Concepts Guide Version 7.1 94

 8. Tracking and Viewing Run-Time Information in Trading Networks

Trading Networks uses two types of tasks: delivery tasks and service execution tasks.
Delivery tasks. Trading Networks creates delivery tasks to keep track of its attempts to 
deliver documents when it is using reliable delivery. For more information about 
delivery tasks and reliable delivery, see “Reliable Delivery with Immediate Delivery” 
on page 76 and “Reliable Delivery and Scheduled Delivery” on page 81.
Service execution tasks. Trading Networks creates a service execution task when you 
use the Execute a Service processing action and select service execution task to indicate 
how Trading Networks is to execute the service. For more information, see “Execute a 
Service Processing Action” on page 65.
You can view details for a task, which includes the number of times that Trading Networks 
has attempted to retry the task; that is, for a delivery task the number of times Trading 
Networks has attempted to retry delivering a document and for a service execution task 
the number of times Trading Networks has attempted to retry the service.

For more information about how to search for and view task information, see Chapter 4, 

ʺManaging Tasks from My webMethodsʺ and Chapter 9, ʺManaging Delivery Tasks 
from the Consoleʺ and Chapter 10, ʺManaging Service Execution Tasks from the 
Consoleʺ in the webMethods Trading Networks User’s Guide.

Stopping, Restarting, Reassigning, and Deleting Tasks

You can manage tasks by: stopping, restarting, and/or deleting them.
Stopping a task. If you want to stop an immediate delivery of a document or stop the 
execution of a service, you can stop the associated delivery task or service execution 
task. For example, you might want to stop a delivery task if the receiver of the 
document cannot receive the document at the present time. You might want to stop a 
service execution task if you need to alter the service that is to be invoked.

Note: You cannot stop an individual delivery task for a scheduled delivery. To stop 
delivery tasks for scheduled delivery, you can disable or suspend the queue in which 
the delivery task resides.

Restarting a task. If you previously stopped a task, you can restart it. Additionally, if a 
task failed (e.g., Trading Networks was unable to deliver a document and the 
maximum retry limit was reached), you can restart the task. When you restart a task, 
Trading Networks resets the retry count to zero. As a result, after restarting the task, 
Trading Networks will attempt to retry the task up to the maximum number of 
allowed retries.
Reassigning a task. If you have a clustered environment (that is, multiple Integration 
Servers that share a single database), you can reassign a task to another server in the 
cluster.

webMethods Trading Networks Concepts Guide Version 7.1 95

 8. Tracking and Viewing Run-Time Information in Trading Networks

Deleting a task. You can manually delete tasks when you no longer need them in the 
system.

Note: Trading Networks automatically deletes tasks when the document with which 
the task is associated is archived or deleted.

For more information about how to stop, restart, and delete tasks, see Chapter 4, 

ʺManaging Tasks from My webMethodsʺ; Chapter 9, ʺManaging Delivery Tasks from 
the Consoleʺ; and Chapter 10, ʺManaging Service Execution Tasks from the Consoleʺ in 
the webMethods Trading Networks User’s Guide.

Viewing the Activity Log

The activity log is a log that Trading Networks maintains to record the activity that occurs:
When you perform administrative actions for your Trading Networks system

While managing your partners

While documents are being received, processed, and delivered

Note: Trading Networks only records activity log entries while documents are being 
received, processed, and delivered if instructed to do so by the Save Document to
Database pre‐processing action. For more information about this pre‐processing 
action, see “Pre‐processing Actions” on page 61.

You can view all activity log entries or search for specific entries. 

For more information about how to view the activity log, see Chapter 5, ʺManaging the 

Activity Log from My webMethodsʺ and Chapter 11, ʺManaging the Activity Log from 
the Consoleʺ in the webMethods Trading Networks User’s Guide.

Viewing the Server Log

The server log is a log that Integration Server maintains to record information about 
operations and errors that occur on Integration Server, such as the starting of Integration 
Server subsystems and the loading of packages belonging to the Integration Server, 
including Trading Networks. Trading Networks writes log entries directly to the server 
log. You control server logging using the Server Administrator; you can activate or 
deactivate logging and specify the logging level (the amount of detail) you want to write 
to the log. 

For more information about working with logging data, see the webMethods Logging Guide.

webMethods Trading Networks Concepts Guide Version 7.1 96

 8. Tracking and Viewing Run-Time Information in Trading Networks

Using Trading Networks Web Manager

Trading Networks Web Manager is another Trading Networks‐specific user interface that 
you use via a Web browser. Trading Networks Web Manager is deprecated.
Web Manager provides some of the functionality that is available through My 
webMethods and the Trading Networks Console. For example, you can use Web Manager 
to view profiles, search for documents, and check the status of documents.

For more information about Web Manager, see the 6.5 version of the webMethods Trading 

Networks Web Manager Administrator’s Guide, which is available on webMethods 
Advantage.

webMethods Trading Networks Concepts Guide Version 7.1 97

 8. Tracking and Viewing Run-Time Information in Trading Networks

webMethods Trading Networks Concepts Guide Version 7.1 98

Chapter 9. Business Analysis and Monitoring of Trading
Networks Transaction Data

Overview of the Analysis of Trading Networks Transaction Data . . . . . . . . . . . . . . . . . . . . . . . 100

Architecture and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Design Time Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Monitoring Trading Networks Transaction Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

webMethods Trading Networks Concepts Guide Version 7.1 99

 9. Business Analysis and Monitoring of Trading Networks Transaction Data

Overview of the Analysis of Trading Networks Transaction Data

Business Activity Monitoring (BAM) allows you to analyze real time information about 
the performance of your business, including the volume of business activity and its 
responsiveness, serious errors that might have occurred, and other key performance 
indicators (KPIs). Using this actionable data, you can eliminate problems and take 
advantage of business opportunities.
For similar purposes, you can monitor Trading Networks B2B (Business to Business) 
transactions. You can then view, monitor and analyze based on the monitoring data. For 
example, you can view the purchase order or invoice trend of a particular customer from a 
particular region and then analyze if that customer proves beneficial for the enterprise or 
not.
For more information on BAM, see the webMethods Optimize for Process Administrators 
Guide.
Trading Networks uses the monitoring capabilities of Optimize to analyze and monitor its 
transaction data. You indicate what data you want to monitor by configuring the TN 
document types and selecting the required document attributes. The information that the 
system uses for analysis and monitoring is the values of these attributes. 
After analysis, you view the data as graphs, reports, and so on, using My webMethods.

Architecture and components

When you want to enable BAM for Trading Networks data, you must have the following 
additional components in your network:
webMethods Broker

webMethods Optimize for B2B
The following diagram shows the components that are required for BAM on Trading 
Networks:

webMethods Trading Networks Concepts Guide Version 7.1 100

 9. Business Analysis and Monitoring of Trading Networks Transaction Data

Trading Networks Optimize for

Broker B2B

Integration Server
Document

Optimize’s
database

My webMethods
Server

Trading Networks: Extracts the document attributes from every document it receives. 
These extracted document attributes include the ones required for monitoring and for 
further processing. After the document processing, Trading Networks sends the 
monitorable attribute values as events to Optimize for B2B for analysis. An event is the 
data that Trading Networks sends to Optimize for monitoring.
Broker: Acts as an intermediary while passing the data from Trading Networks to 
Optimize. Broker uses a JMS (Java Messaging Service) Queue to pass the data to 
Optimize.
Optimize: Trading Networks uses Optimize for its monitoring capabilities and to define 
and manage the KPIs required for analysis and monitoring. Optimize for B2B 
subscribes to the events from Broker and analyzes them using one of its Analytic 
Engines. This analyzed data is saved to Optimize for B2B’s database. 
My webMethods Server: Is the run‐time container for functions that webMethods 
components make available. Trading Networks administrators use My webMethods 
to configure Trading Networks to enable BAM. My webMethods also presents the 
analyzed data as graphs, reports, and so on by retrieving it from Optimize for B2B’s 
database.
For more information about:
webMethods Broker, see the webMethods Broker Administrator’s Guide.

webMethods Optimize for B2B, see the webMethods Optimize for Process 
Administrators Guide and the webMethods Optimize for Process User’s Guide.
My webMethods Server, see the Getting Started with My webMethods.

webMethods Trading Networks Concepts Guide Version 7.1 101

 9. Business Analysis and Monitoring of Trading Networks Transaction Data

Design Time Actions

To monitor the Trading Networks transaction data, you must do the following actions at 
design time.
1 Initialize Integration Server and Trading Networks for BAM.
Initialize Integration Server by setting the server configuration property 
watt.server.optimize.monitoring=true in the Integration Server’s config.cnf 
file. Setting this property creates a Broker and a JMS (Java Messaging System) 
Queue factory required to pass the events to Optimize. 
Initialize Trading Networks for BAM by setting the watt property 
tn.bam.monitoring.enable=true in the Trading Networks properties file. 
Setting this property allows you to monitor the Trading Networks transaction 
data and thus configure the TN document types for monitoring.
2 Configure the TN document type by selecting the document attributes you want to monitor. The 
values of only those document attributes that you select are extracted for monitoring. 
You can monitor both system attributes and custom attributes.
3 Create the event map for the TN document type you are configuring. That is, you must 
associate each document attribute you indicate as a fact, dimension, or transaction. 
The event map defines what each document attribute in an event means.
4 Deploy the event map to Optimize for B2B. This saves the TN document type configuration 
and deploys the event map details to Optimize for B2B.
5 Define the KPI hierarchies and the individual KPIs. KPI is a monitor item that 
analyzes the facts using the dimensions. KPI hierarchy illustrates the relationships 
between KPIs. You map each KPI with a KPI hierarchy. Based on these KPIs, Optimize 
analyzes the data and saves it to its database.
For more information about:
Initializing Trading Networks and Integration Server, see the webMethods 
Trading Networks Administrator’s Guide.
Configuring the TN document types, see the webMethods Trading Networks 
Administrator’s Guide.

Monitoring Trading Networks Transaction Data

After all the necessary configurations as mentioned in section “Design Time Actions” on 
page 102 are complete, at run time, the processing of the data required for monitoring is 
done as follows: 
1 After the recognition of a document, Trading Networks creates a BizDocEnvelope that 
contains the original document, the extracted attribute values, and additional 
information required for routing and processing the document. Trading Networks 

webMethods Trading Networks Concepts Guide Version 7.1 102

 9. Business Analysis and Monitoring of Trading Networks Transaction Data

then checks if that TN document type and Trading Networks itself are enabled for 
BAM. If yes, Trading Networks collects all the attribute values for monitoring and 
stores in a hash map within the BizDocEnvelope until the document processing is 
complete.
After the document processing is complete, Trading Networks once again 
synchronizes the actual attribute values to the ones existing in the hash map. This is 
necessary because the attribute values stored in the BizDocEnvelope might get 
updated either during any of the service execution tasks (both Synchronous / 
Asynchronous) or due to any other services in Trading Networks. 
Trading Networks then maps the attributes to the event maps as configured during 
the design time, and creates events.
For more information about the BizDocEnvelope and the document processing in 
Trading Networks, see “Processing of Documents in Trading Networks” on 
page 53.

2 The events are then passed to webMethods Broker. A Java Messaging System (JMS) 
provided by Broker collects all these events using a DCA. 
If an error occurs while passing the events, an exception is thrown. This exception will 
be logged as a warning in the Activity Log associated with that document.

Note: When Trading Networks passes the event to Broker during the document 
processing depends on the processing rule actions defined for the TN document type. 
For more information about when Trading Networks passes the events to Broker, see 
“Stages at Which the Events are Passed to the Broker” on page 103.

3 webMethods Optimize for B2B subscribes to the events from the Broker’s JMS queue 
and feeds them to its Analytic Engine. The Analytic Engine analyzes these events and 
saves the data to Optimize for B2B’s database.
4 During monitoring, My webMethods Server retrieves the required data from 
Optimize for B2B’s database at run time and allows the user to view the data in a 
presentable format such as graphs, reports, and so on.

Note: You can also use Informatica’s Dashboard to analyze, monitor and view the data. 
This is possible because the schema defined for analysis is common for both My 
webMethods Server and Dashboard.

Stages at Which the Events are Passed to the Broker

After completing the processing of a document, Trading Networks collects the 
monitorable attribute values and creates events to be passed to the Broker. If the 
document processing fails and the document is reprocessed, duplicate events might get 

webMethods Trading Networks Concepts Guide Version 7.1 103

 9. Business Analysis and Monitoring of Trading Networks Transaction Data

passed to Broker. To avoid this, based on the delivery method you choose for a TN 
document type, the events are passed to the Broker as follows:
If you choose to turn off the routing for the document, the event is passed 
immediately after the document process completion.
If you use the Execute a Service processing action, when the event is passed is based on 
how the service is invoked:
Synchronous: The event is passed only after the execution of the service is 
complete and the processing of the document is successful.
Asynchronous or Reliable Execution: The event is passed after the execution of the 
service is complete irrespective of the document processing status.
If you use the Deliver Document By processing action, the event is passed only when the 
document processing status is complete.

Note: When a TN document type has both Execute a Service and Deliver Document By tasks 

associated with it, then while configuring the TN document type for monitoring you must 
select either of the tasks in the Send BAM Event After option. Depending on this, Trading 
Networks passes the events to the Broker after the chosen task is complete and thus 
avoids duplicate events being passed. For more information about configuring the TN 
document type for monitoring, see the Chapter 5, ʺSetting Up Analysis of Trading 
Networks Transaction Dataʺ in the webMethods Trading Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 104

Appendix A. Glossary for Trading Networks

activity log
A log that Trading Networks maintains to record the activity that occurs within the 
Trading Networks system. Trading Networks records entries, for example, when you 
manage trading partner information, when it processes documents, and when you perform 
administrative tasks.
activity class
A classification that identifies the Trading Networks function associated with an entry in 
the activity log. For example, Trading Networks sets the activity class to Recognition when 
adding entries related to using the TN document types to recognize a document.
ambiguous document
A document that matches multiple TN document types. (Compare with unknown document.)
attribute
See document attribute.
BAM (Business Activity Monitoring)
Allows you to analyze real‐time information about the performance of your business, 
including the volume of business activity and its responsiveness, serious errors that might 
have occurred, and other KPIs. Using this actionable data, you can eliminate problems 
and take advantage of business opportunities.
bizdoc
The name of the variable in the pipeline that contains the BizDocEnvelope.
BizDocEnvelope
A BizDocEnvelope represents a routable Trading Networks transaction. It contains the 
content of a document that Trading Networks is processing and includes additional 
information that Trading Networks requires for routing and processing the document. It is 
in the pipeline in the bizdoc variable and conforms to the IS document type 
wm.tn.rec:BizDocEnvelope.
Broker
See webMethods Broker.
business process
A multi‐step interaction among participating systems, people, and trading partners. A 
business process can be fully automated (involve only interaction among computer 
systems) or include varying degrees of human interaction (for example, review and 
approval steps). It can be brief or long‐running. Some business processes transpire over 
days or weeks. (Compare with conversation.)
conversation
A specific case of a business process that involves a series of related documents being 
exchanged by two or more trading partners. All documents from a specific trading partner 

webMethods Trading Networks Concepts Guide Version 7.1 105

 A. Glossary for Trading Networks

contain the same Conversation ID. You model a conversation by creating a process model 
using webMethods Designer.
Conversation ID
A system attribute that identifies a value within a document that is common to all documents 
that are part of the same business process. (A or same conversation of documents.)
custom attribute
A document attribute that you define to identify information within a document that is of 
interest to you. (Contrast with system attribute.)
deliver
Sending an outbound document from Trading Networks to the trading partner that is the 
receiver of the document.
delivery method
A method for delivering a document to a trading partner, e.g., HTTP, HTTPS, FTP, FTPS, 
e‐mail (SMTP). Trading Networks supports, immediate delivery methods, scheduled delivery 
methods, and queue for polling.
delivery task
A task that Trading Networks establishes to keep track of the attempts to re‐deliver a 
document when it is using reliable delivery. 
dimension
While defining an event map, you define a document attribute as a dimension that has a 
value that is not measurable, for example, region, department, and so on. You use 
dimensions to analyze a fact. 
document
A business document (e.g., purchase order, acknowledgement, confirmation) sent to 
Trading Networks. The document can be in any format (XML, EDI, etc.) Trading Networks 
provides out‐of‐the‐box support for XML and flat file documents. The webMethods EDI 
Module is necessary for EDI documents.
document attribute
A Trading Networks object that defines a piece of information within a document that is of 
interest. For example, document attributes in a purchase order might be the purchase order 
number, the account number of the purchase order and the total purchase amount. 
Document attributes can be either a system attributes (those that are provided with Trading 
Networks) or custom attributes (those that you define for your enterprise). 
document gateway service
A service that you create and that is the entry point for processing a flat file. The service you 
create places information in the pipeline for Trading Networks to use to determine the TN 
flat file document type to use for a flat file. The service can also place document attributes 
along with their values in the pipeline. After the document gateway service executes, it passes 
control to Trading Networks.

webMethods Trading Networks Concepts Guide Version 7.1 106

 A. Glossary for Trading Networks

Document ID
A system attribute for an identifier in a document that is typically a unique value that 
distinguishes a document from other versions of the same document.
document type
See TN document type or IS document type.
document validation
The process of verifying the structure and content of an individual document by validating 
it against a schema.
Enterprise partner
The partner that hosts the trading network. On your Trading Networks system, this would 
typically be your corporation. (Also known as the hub, local partner, or sponsor.) (Contrast 
with spoke.)
event
The data that trading network passes to the Broker at run time, after the document 
processing is complete. It contains the document attributes values for monitoring, the event 
map and the time stamp data of the document.
event map
The knowledge of what each document attribute in an event means. An event map 
associates business data, such as dimensions, with a particular transaction.
extended fields
Fields within a profile that you define for your enterprise. Create extended fields to maintain 
information about trading partners that is not covered by the standard fields.
external ID type
A type of identifier in a document used to identify the sender or receiver of the document. 
For example, the sender might be represented by the D‐U‐N‐S number for the sender’s 
corporation.
external ID
The value of the external ID type within a document. For example, if the external ID type is a 
D‐U‐N‐S number, the external ID is the actual value of the D‐U‐N‐S number.
fact
A measurable attribute value that you can use to analyze the trading network transactions1 
data, for example, quantity, cost, and so on.
flat file
Any file or document that has a format that is non‐describing, that is, a document that does 
not contain metadata. A flat file document presents hierarchical data in a record‐based 
storage format, which unlike XML, does not embed structural information within the 
data.
flat file dictionary
A collection of record definitions, field definitions, and composite definitions that can be 
used in multiple flat file schemas. 

webMethods Trading Networks Concepts Guide Version 7.1 107

 A. Glossary for Trading Networks

flat file schema

A blueprint that contains the constraints to which a flat file document should conform to 
be considered valid.
gateway service
See document gateway service.
Group ID
A system attribute for an identifier in a document that is common to all documents in a group 
of documents.
hub
The partner that hosts the trading network. (Also known as the Enterprise partner, local 
partner or sponsor.) (Contrast with spoke.)
IData object
The collection of name/value pairs on which a service operates. An IData object can contain 
any number of elements of any valid Java objects, including additional IData objects. (Also 
called an IS document.)
identifying query
An XQL query that is specified in a TN XML document type and that Trading Networks 
uses to match an inbound XML document to a TN XML document type. Trading Networks 
performs the identifying query to ensure the node that the XQL query represents is in an 
XML document. If the node is present and all other identifying information matches the 
inbound XML document, Trading Networks determines that the inbound XML document 
matches the TN XML document type that contains the identifying query. Alternatively, if the 
node is not present, Trading Networks determines that the inbound XML document does 
not match the TN XML document type.
immediate delivery method
A delivery method where Trading Networks attempts to immediately deliver a document 
directly to the receiving partner. Trading Networks provides many built‐in delivery 
methods, such as, Primary HTTP, Secondary HTTP, Primary E‐mail, etc.
IS document type
An element in the Integration Server’s namespace that contains a set of fields used to 
define the structure and type of data in an IS document (IData object).
IS schema
The blueprint or model document that you validate an XML document against. The 
schema defines what can and cannot be contained in the XML documents it is validated 
against.
Java Messaging System (JMS)
A messaging system that acts as medium to pass all the events stored in Broker by the 
trading network to Optimize.
local partner
The partner that hosts the trading network. (Also known as the Enterprise partner, hub or 
sponsor.) (Contrast with spoke.)

webMethods Trading Networks Concepts Guide Version 7.1 108

 A. Glossary for Trading Networks

KPI
Key performance indicator. A measurement of a business activity that is important to the 
success of an organization. KPIs monitor metrics – quantitative business and system data 
– such as revenue, volume of orders, queue length, and cycle time. KPIs help answer 
questions such as “How many orders over $10,000 are stuck in this process?” A KPI 
defines a way to aggregate event data.
KPI Hierarchy
An ordered ranking of dimensions. A hierarchy provides additional ways to slice data into 
smaller components. For example, a sales hierarchy might consist of two dimensions: 
region and sales person.
My Enterprise partner
Old term for the partner that hosts the trading network; now known as the Enterprise 
partner. (See Enterprise partner.)
My webMethods
A web‐based, administration and monitoring user interface for managing your 
webMethods components. You can use it to monitor Trading Networks transactions, 
service execution tasks, delivery tasks, and the activity log. Additionally, you can use 
webMethods to manage profiles, profile groups, and Trading Networks queues.
My webMethods Server
The run‐time container for functions that webMethods components make available via 
My webMethods. For example, Trading Networks makes the functions to monitor and 
manage transactions available.
Optimize
See webMethods Optimize for B2B.
partner
See trading partner.
pipeline
The general term used to refer to the data structure in which input and output values are 
maintained. The pipeline starts with the input to a service and collects inputs and outputs 
from subsequent services. When a service executes, it has access to all data in the pipeline.
private queue
A scheduled delivery queue that you define to schedule the delivery of documents that are 
aimed at one specific trading partner. You define a private queue in the profile of the partner 
to receive the documents. (Contrast with public queue.)
process
See business process.
Process Engine
A facility of the Integration Server that manages the execution of business processes (or 
conversations). You model a business process (or conversation) by using webMethods 
Designer to create a process model.

webMethods Trading Networks Concepts Guide Version 7.1 109

 A. Glossary for Trading Networks

process model
Diagrams that illustrate and define the actions to perform for a business process or 
conversation. You create process models using webMethods Designer. 
process run time
Old term for the Process Engine.
processing rule
A Trading Networks object that contains a set of actions that determine how Trading 
Networks is to process an inbound document and criteria that indicates when to select a 
processing rule for an incoming document.
profile
A Trading Networks object that contains a summary of information about a corporation 
that is part of a trading network. A profile contains standard fields that Trading Networks 
provides and extended fields that are site‐defined.
profile fields
Fields in a profile. Each profile field represents information that you collect and maintain for 
trading partners in the trading network. There are two types of profile fields: standard fields 
and extended fields.
public queue
A scheduled delivery queue that you define to schedule the delivery of documents that are 
aimed at multiple trading partners. (Contrast with private queue.)
queue for polling
A delivery method where a trading partners can obtain documents without having Trading 
Networks deliver documents directly to the trading partner, for example, because of firewall 
constraints. Trading Networks saves the documents to its database in an internally‐defined 
queue. At a later time, the receiving partner polls for documents, and Trading Networks 
returns all the documents in the queue for which that trading partner is the receiver.
ReceiverID
A system attribute that identifies the trading partner that is to receive a document. The 
ReceiverID is an external ID (i.e., the value of an external ID type).
reliable delivery
A feature of Trading Networks where Trading Networks attempts to re‐deliver a document 
to a trading partner one or more times if previous attempts to deliver the document fails. For 
an immediate delivery method, Trading Networks automatically uses reliable delivery when 
the pre‐processing action Save Document to Database indicates that Trading Networks is to 
save the document content to its database. For a scheduled delivery method, Trading 
Networks always uses reliable delivery.
reliable execution
A feature of Trading Networks where Trading Networks attempts to re‐execute a service 
if previous attempts to execute the service fails. Trading Networks uses reliable execution 
when you select service execution task as the method for how Trading Networks is to 
asynchronously execute a service for the Execute a Service processing action. See also 
service execution task.

webMethods Trading Networks Concepts Guide Version 7.1 110

 A. Glossary for Trading Networks

scheduled delivery method

A delivery method where Trading Networks batches multiple documents in a scheduled 
delivery queue. The documents in the queue are acted on at scheduled times to deliver them.
scheduled delivery queue
A grouping of documents that are intended for one or more trading partners. Trading 
Networks supports two types of scheduled delivery queues: public queue and private queue. 
schema
See flat file schema or IS schema.
SenderID
A system attribute that identifies the trading partner that sent a document. The SenderID is an 
external ID (i.e., the value of an external ID type).
service execution task
A task that Trading Networks establishes to keep track of the attempts to re‐execute a 
service when using reliable execution. Trading Networks creates a service execution task 
when you select service execution task as the method for how Trading Networks is to 
asynchronously execute a service for the Execute a Service processing action.
signature
A system attribute that identifies the portion of a document that contains the digital 
signature for the document.
SignedBody
A system attribute that identifies the portion of a document that contains the data that was 
digitally signed to create the digital signature.
spoke
A trading partner that is a member of a trading network, but is not the host of the network. 
(Contrast with hub.) 
standard fields
Fields within a profile that are provided out‐of‐the‐box. The standard fields typically 
incorporate most of the information that sites want to collect about a trading partner. See 
also profile fields.
system attribute
A document attribute that is provided with Trading Networks out‐of‐the‐box.
tasks
See delivery task and service execution task.
TN document type
A Trading Networks object that defines how Trading Networks is to recognize a document 
and initial actions to take on a recognized document. Trading Networks recognizes the 
document by using identification information in the TN document type. The actions 
specified in aTN document type indicate the document attributes that Trading Networks is to 
extract from the document (including information about XML namespaces the documents 
might use) and specify options for pre‐processing the document (which include 

webMethods Trading Networks Concepts Guide Version 7.1 111

 A. Glossary for Trading Networks

verification, validation, and whether to save the document attributes, document content, 
and log entries for the document to the database). 
TN flat file document type
A TN document type that Trading Networks uses when recognizing flat file documents. To 
match a flat file to a TN flat file document type, Trading Networks relies on information 
provided by a document gateway service.
TN XML document type
A TN document type that Trading Networks uses when recognizing XML documents.
TPAs
See Trading Partner Agreement (TPA).
trading network
A system of organizations that are connected to share business information. The 
organizations in a trading network are strategic partners, buyers, suppliers, and 
marketplaces. They share business information by exchanging documents, for example, 
purchase orders, order statuses, purchase order acknowledgements, invoices, as well as 
domain‐specific business documents. 
Trading Partner Agreement (TPA)
A Trading Networks object that you can use to tailor how documents are exchanged 
between two trading partners.
trading partner
An organization in your trading network, for example, a strategic partner, marketplaces, 
buyer, or supplier. Each trading partner requires a profile. You can exchange business 
documents with the trading partners in your network to relay mission critical production 
information. (Also known as partners.) 

transactions1
The documents that have passed through Trading Networks. 
transaction2
While defining an event map, you define a document attribute as a transaction, if its value 
is neither a fact nor a dimension. You do not use this data for analysis but just as a reference 
point. For example, order ID.
unknown document
A document that does not match any TN document type. (Compare with ambiguous 
document.)
unknown partner
A trading partner (sender or receiver) of a document is considered unknown if Trading 
Networks is unable to determine the sender or receiver; that is match the sender or 
receiver to a profile in the Trading Networks system.
User Status
A system attribute that contains a status that a user can associate with a document, e.g., 
ʺNeeds Approvalʺ.

webMethods Trading Networks Concepts Guide Version 7.1 112

 A. Glossary for Trading Networks

webMethods Broker
The primary message backbone product in a webMethods integration environment. 
webMethods Broker facilitates asynchronous, message‐based communication using the 
publish‐and‐subscribe model.
When you enable monitoring on trading networks transaction data, Broker acts as an 
intermediary while passing events from a trading network to Optimize. It uses a Java 
Messaging System (JMS) queue that publishes the events to the Optimize.
webMethods Optimize for B2B
When you enable BAM on Trading Networks transaction data, Optimize subscribes the 
events from the Java Messaging System (JMS) queue of the Broker, analyzes them based on 
the defined KPIs, and saves them to its database. At run time, My webMethods Server 
retrieves this data to view or monitor the data in a graphical or a tabular format.
Web Manager
A Trading Networks‐specific user interface that you use via a Web browser. This use 
interface is deprecated. 
XML
EXtensible Markup Language, a uniform method for describing and exchanging data that 
is flexible, extensible, and easy to implement. It is a simplified dialect of the Standard 
Generalized Markup Language (SGML).
XQL
XML Query Language. A language used to retrieve information from an XML document.

webMethods Trading Networks Concepts Guide Version 7.1 113

 A. Glossary for Trading Networks

webMethods Trading Networks Concepts Guide Version 7.1 114

Appendix B. Security within Trading Networks

Overview of Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Communicating Securely Using SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Protecting Access to User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Protecting Partner Profile Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Protecting Access to Trading Networks Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Certificates for Verifying, Signing, Encrypting, and Decrypting Documents . . . . . . . . . . . . . . . 120

webMethods Trading Networks Concepts Guide Version 7.1 115

 B. Security within Trading Networks

Overview of Security Features

Trading Networks includes security features for:
“Communicating Securely Using SSL”

“Protecting Access to User Interfaces”

“Protecting Partner Profile Passwords”

“Protecting Access to Trading Networks Processing”

“Certificates for Verifying, Signing, Encrypting, and Decrypting Documents”

Communicating Securely Using SSL

Because Trading Networks runs in the Integration Server, it takes advantage of 
Integration Server features, such as its support of Secure Sockets Layer (SSL) for secure 
communications. To enable Trading Networks to act as an SSL client connecting to a 
remote secure server, specify an SSL Client certificate in your Enterprise profile or your 
partner’s profile.
When using SSL connections that require client‐side authentication, Trading Networks 
looks at the sender’s profile to see if it contains the specific private key to use to connect to 
the receiver (the remote secure server). If Trading Networks:
Finds a set of certificates to use for that specific receiver, it uses the private key from 
that certificate set
Does not find a set of certificates to use for that specific receiver, it uses the default 
private key specified in the sender’s profile.
Does not find a default private key specified in the sender’s profile, it uses the default 
certificates specified in the Integration Server.

Protecting Access to User Interfaces

To prevent unauthorized access to the user interfaces, a user is authenticated before 
allowing access to My webMethods, Trading Networks Console and Trading Networks 
Web Manager. All components are user name/password protected.

Access to My webMethods for Trading Networks Actions

Trading Networks actions that you access from My webMethods are protected by 
role‐based access. That is, to view Trading Networks data (e.g., information about a delivery 
task) and to perform actions against that data (e.g., restart a task), you must be a member 

webMethods Trading Networks Concepts Guide Version 7.1 116

 B. Security within Trading Networks

of a role to which that permission has been granted. There are two aspects to role‐based 
access:
Data permissions, which identifies a data set of profiles, transactions, tasks, and activity 
log entries along with the actions a role can perform against that Trading Networks 
data set. Using data‐level security, you can grant roles the following permissions:
View/edit profile settings of existing profiles.
Reprocess transactions
Resubmit transactions
Edit user status attribute for transactions
Edit comment for transactions
View content of transactions
Edit content and resubmit transactions
View, restart, stop, delete, or reassign tasks
View/delete activity log entries
General functional permissions, which grants a role the permission to perform Trading 
Networks actions against other Trading Networks data. Using general functional 
permissions, you can grant roles the following permissions:
Manage public queues
Manage profile groups
Create new profiles
Delete existing profiles
Manage extended profile fields
Add external ID types
View SQL associated with a query performed in My webMethods
Manage Trading Networks Business Activity Monitoring (BAM) configuration
View user preferences
Edit user preferences
View Trading Networks configuration properties
Edit Trading Networks configuration properties
Query expiring partner certificates

webMethods Trading Networks Concepts Guide Version 7.1 117

 B. Security within Trading Networks

For more information about setting up role‐based access, see Chapter 4, ʺConfiguring 

My webMethods to Work with Trading Networksʺ in the webMethods Trading 
Networks Administrator’s Guide.

Access to Trading Networks User Interfaces

For the Trading Networks‐specific user interfaces (i.e., the Console and Web Manager), a 
user must provide a user name/password with Trading Networks administrative authority 
to access Trading Networks for administrative use, such as to configure the system or to 
update profiles, TN document types, and processing rules. A partner must have partner 
authority to access the Trading Networks Web Manager to view information in a partner’s 
system.

Protecting Partner Profile Passwords

All passwords contained in partner profiles are securely managed by the Integration 
Server’s Password Manager. When you create a partner profile, Trading Networks creates 
a handle for the password and passes both the password and its handle to the Integration 
Server’s Password Manager. The Password Manager encrypts the password and stores the 
password and its handle in the IS repository. The Trading Networks database stores only 
the handle.
When you need to display or update an existing profile, Trading Networks reads the 
appropriate handle in its database and asks the Password Manager to return the 
password. The Password Manager obtains the password from the Integration Server 
repository, decrypts it, and returns it to Trading Networks. If the password is already 
cached in the Trading Networks database, this process is not necessary.

Note: Passwords used in scheduled delivery queues (public and private) are stored in the 
Trading Networks database in binary‐encoded form (not in clear text). It is not possible for 
Trading Networks to encrypt passwords used in scheduled delivery queues; because 
trading partners are allowed to create custom scheduled delivery services, Trading 
Networks cannot anticipate which user‐defined input variable might be a password.

For information about creating partner profile passwords, see Chapter 10, ʺDefining and 
Managing Partner Profilesʺ and Appendix I, ʺManaging Partner Profiles Using the 
Consoleʺ in the webMethods Trading Networks Administrator’s Guide.

webMethods Trading Networks Concepts Guide Version 7.1 118

 B. Security within Trading Networks

Protecting Access to Trading Networks Processing

When trading partners want to connect to your Trading Networks system, for example to 
send a document for processing, access can be protected via a user account (user 
name/password) or x.509v3 client certificates. A partner must have partner authority to 
access your Trading Networks system to exchange documents. When you define a profile 
for a partner, you can associate one or more My webMethods or Integration Server user 
accounts with a profile. Your partner can use the user account(s) to access your system. 
For more information, see “User Accounts for Partners” on page 43.
When your Trading Networks system needs to connect to a partner’s system, for example 
to deliver a document, it can use a user account (user name/password) or x.509v3 client 
certificates as credentials that the partner’s system uses for authentication. If your partner 
requires authentication using user name/password, your Trading Networks system 
maintains the user name and password it needs to supply when connecting to that partner 
in the partner’s profile on your system. If a partner requires authentication using client 
certificates, your Integration Server system maintains the client certificate it needs to 
supply when connecting with that partner.

Access Control Lists

When a client sends a document to Trading Networks, the client must specify the service 
that is to accept and process the document. When you send a document, specify the 
wm.tn:receive service. For more information, see “Sending Documents to Trading 
Networks” on page 42.
Trading Networks protects access to the wm.tn:receive service using an Access Control List 
(ACL). The protection assures only clients with Trading Networks administrative 
authority or partner authority can invoke this service. Clients must identify the user name 
and password for their user account when invoking the wn.tn:receive service.
If the user account that sends the document has Trading Networks administrative 
authority, Trading Networks always processes the document. When the user account has 
partner authority, Trading Networks ensures that the user invoking the wm.tn:receive 
service matches the sender specified within the document being sent. That is, Trading 
Networks uses the sender identified within the document to lookup the sender’s profile 
and ensures that the profile is associated with the My webMethods or Integration Server 
user account that was used to send the document. If the user account is not associated 
with the sender’s profile, Trading Networks does not process the document.

webMethods Trading Networks Concepts Guide Version 7.1 119

 B. Security within Trading Networks

Certificates for Verifying, Signing, Encrypting, and Decrypting

Documents
You can use a single set of certificates for all partners, or you can use a unique set of 
certificates for each sender/receiver pair (or selected pairs). For example, you can use one 
set of certificates for sending documents from A to B, and a different set of certificates for 
sending documents from C to A.
When you define your profile and the profiles of your trading partners, you specify the 
following kinds of certificates in the following profiles:

Specify this
certificate ... In this profile ... Description
Verify sender’s profile When a partner sends a document to you, Trading 
Networks looks at the sender’s profile to see if it 
contains the specific public certificate to use to 
verify the document.
Sign sender’s profile When you sign a document to send to a partner, 
Trading Networks looks at your profile to see if it 
contains the specific private key to use to sign the 
document.
Encrypt receiver’s profile When you encrypt a document to send to a partner, 
Trading Networks looks at the receiver’s profile to 
see if it contains the specific public certificate to use 
to encrypt the document.
Decrypt receiver’s profile When a partner sends an encrypted document to 
you, Trading Networks looks at your profile to see if 
it contains the specific private key to use to decrypt 
the document.

The following table summarizes all scenarios of certificate usage:

Sender Receiver Operation Profile used

A B Sign A
A B Verify A
B A Sign B
B A Verify B
A B Encrypt B
A B Decrypt B
B A Encrypt A

webMethods Trading Networks Concepts Guide Version 7.1 120

 B. Security within Trading Networks

Sender Receiver Operation Profile used

B A Decrypt A
A B SSL Auth A
B A SSL Auth B

Verifying Digital Signatures

Trading Networks supports x.509v3 certificates for verifying the digital signature of 
documents sent by a partner. Trading Networks verifies the digital signature to:
Assure that the documents have arrived unchanged

Verify that the sender is who it claims to be
Trading Networks verifies a digital signature when instructed to do so by the Verify Digital
Signature pre‐processing action. For more information, see “Pre‐processing Actions” on 
page 61.

Actions You Must Take to Verify Digital Signatures

To verify the digital signature, you must:
Save the partner’s Verify certificate in the partner’s profile. Trading Networks must have 
access to the partner’s certificates. When you add a Verify certificate, Trading 
Networks stores the certificate in the Trading Networks database.

Note: If you include the private key in this certificate information, Trading Networks 
can also use this certificate information to digitally sign documents on behalf of the 
partner. You might have the private key if the profile describes an internal group, for 
example a department within your corporation.

Set up your TN document type to extract the following system attributes:

Signature that identifies the portion of the document that contains the digital 
signature. The signature must be a base64 encoded PKCS#7 detached digital 
signature. The signature can contain information for one or more signers.
SignedBody that identifies the portion of the document that was digitally signed. 
Use the Verify Digital Signature pre-processing action. When you set up the TN document 
type or processing rule, be sure to specify that you want Trading Networks to verity 
the digital signature.

webMethods Trading Networks Concepts Guide Version 7.1 121

 B. Security within Trading Networks

How Trading Networks Verifies Digital Signatures

When a partner sends a document to you, Trading Networks looks at the partner’s profile 
to see if it contains the specific public certificate to use to verify the document. If Trading 
Networks:
Finds a set of certificates to use for that specific receiver, it uses the appropriate 
certificate in that set
Does not find a set of certificates to use for that specific receiver, it uses the default set 
of certificates specified in the partner’s profile.
To verify that the document arrived unchanged from the partner to you, Trading 
Networks invokes the pub.security.pkcs7:verify service. Trading Networks passes this service 
the value of the SignedBody and Signature system attributes that it extracted from the 
document. For more information about this service, see the webMethods Integration Server 
Built‐In Services Reference.
Trading Networks can only verify information on itself because Trading Networks does 
not have the certification/verification for the partner. Trading Networks ensures that the 
CA that signed the certificate is included in the list of trusted CA certificates that the 
Integration Server maintains.
To assure that the signed body has not changed, Trading Networks verifies the digital 
signature, which is the value of the Signature system attribute. To verify that the sender is 
who it claims to be, Trading Networks matches the certificate from the digital signature to 
the Verify certificate that Trading Networks has on file for the partner.
For more information on security, including trusted CA certificates and mapping 
certificates to user accounts, see the chapter about security information in the webMethods 
Integration Server Administrator’s Guide.

Digitally Signing Documents

Trading Networks supports x.509v3 certificates for digitally signing documents that you, 
the owner of the certificates, want to send to trading partners. To digitally sign a 
document, invoke the built‐in service wm.tn.doc:sign. For more information on this service, 
see the webMethods Trading Networks Built‐in Services Reference.
When you invoke this service, Trading Networks locates the sender and receiver to 
retrieve the correct signed certificate from the Trading Networks database. The owner of 
the certificate is the sender and the receiver is the trading partner. You can set up Trading 
Networks to use alternate certificates for different partners. 
You can also specify a default Sign certificate by providing the certificate information in 
the owner’s profile. If a default Sign certificate is defined, then Trading Networks will use 
this default Sign certificate when a partner‐specific Sign certificate is not available.

webMethods Trading Networks Concepts Guide Version 7.1 122

 B. Security within Trading Networks

How Trading Networks Signs Documents

When you sign a document to send to a partner, Trading Networks looks at your profile to 
see if it contains the specific private key to use to sign the document. If Trading Networks:
Finds a set of certificates to use for that specific receiver, it uses the appropriate 
certificate in that set
Does not find a set of certificates to use for that specific receiver, it uses the default set 
of certificates specified in your profile.

Encrypting and Decrypting Data

Trading Networks maintains x.509v3 certificates to use for:
Encrypting documents that are being sent to partners

Decrypting encrypted documents received from partners
Trading Networks does not have the built‐in ability to encrypt outgoing documents and 
decrypt inbound documents. The certificate information that Trading Networks maintains 
is for other webMethods components (e.g., webMethods RosettaNet Module) that take 
advantage of this feature.

Encrypt Certificates
If you are using another webMethods component that requires Encrypt certificates, save a 
partner’s Encrypt certificate in the partner’s profile. You can also add your own 
functionality that takes advantage of this certificate information. You can obtain the 
certification information by using built‐in services.
Trading Networks does not check to see if the CA that signed the Encrypt certificate is in 
the list of trusted CAs that the webMethods Integration Server maintains.

Note: If you include the private key in this certificate information, this certificate 
information can also be used to decrypt documents that were encrypted with the partner’s 
public key. You might have the private key if the profile describes an internal group, for 
example a department within your corporation.

How Trading Networks Encrypts Documents

When you encrypt a document to send to a partner, Trading Networks looks at the 
partner’s profile to see if it contains the specific public certificate to use to encrypt the 
document. If Trading Networks:
Finds a set of certificates to use for that specific receiver, it uses the appropriate 
certificate in that set

webMethods Trading Networks Concepts Guide Version 7.1 123

 B. Security within Trading Networks

Does not find a set of certificates to use for that specific receiver, it uses the default set 
of certificates specified in the partner’s profile.

Decrypt Certificates
If you are using another webMethods component that requires Decrypt certificates, save 
your Decrypt certificate in the owner’s profile. Because you can store Decrypt certificates 
in the owner’s profile, you can set up alternate Decrypt certificates for different partners. 
You can also specify a default Decrypt certificate by providing the certificate information 
in the owner’s profile. If a default Decrypt certificate is defined, then Trading Networks 
will use this default Decrypt certificate when a partner‐specific Decrypt certificate is not 
available.
Trading Networks does not check to see if the CA that signed the Decrypt certificate is in 
the list of trusted CAs that the webMethods Integration Server maintains.

How Trading Networks Decrypts Documents

When a partner sends an encrypted document to you, Trading Networks looks at your 
profile to see if it contains the specific private key to use to decrypt the document. If 
Trading Networks:
Finds a set of certificates to use for that specific receiver, it uses the appropriate 
private key in that set
Does not find a set of certificates to use for that specific receiver, it uses the default set 
of private keys defined in the Default profile for partners.

webMethods Trading Networks Concepts Guide Version 7.1 124