Webmethods Modeler Users Guide

webMethods Modeler
User’s Guide
VERSION 6.1
webMethods, Inc.
3930 Pender Drive
Fairfax, VA 22030
USA
703.460.2500
http://www.webmethods.com
webMethods Administrator, webMethods Broker, webMethods Dashboard, webMethods Developer, webMethods Glue, webMethods Fabric, webMethods
Installer, webMethods Integration Server, webMethods Mainframe, webMethods Manager, webMethods Mobile, webMethods Modeler, webMethods
Monitor, webMethods Optimize, webMethods Trading Networks, webMethods Workflow, and the webMethods logo are trademarks of webMethods, Inc.
"webMethods" is a registered trademark of webMethods, Inc.
Acrobat, Adobe, and Reader are registered trademarks of Adobe Systems Incorporated. Amdocs and ClarifyCRM are registered trademarks of Amdocs Ltd.
Ariba is a registered trademark of Ariba Inc. BEA is a registered trademark, and BEA WebLogic Platform and BEA WebLogic Server are trademarks of BEA
Systems, Inc. BMC Software and PATROL are registered trademarks of BMC Software, Inc. BroadVision is a registered trademark of BroadVision, Inc. Chem
eStandards and CIDX are trademarks of Chemical Industry Data Exchange. Unicenter is a registered trademark of Computer Associates International, Inc.
Kenan and Arbor are registered trademarks of CSG Systems, Incorporated. SNAP-IX is a registered trademark, and Data Connection is a trademark of Data
Connection Ltd. DataDirect, DataDirect Connect, and SequeLink are registered trademarks of DataDirect Technologies. D&B and D-U-N-S are registered
trademarks of D&B, Inc. Entrust is a registered trademark of Entrust. Hewlett-Packard, HP, HP-UX, and OpenView are trademarks of Hewlett-Packard
Company. i2 is a registered trademark of i2 Technologies, Inc. AIX, AS/400, CICS, DB2, IBM, Infoprint, Informix, MQSeries, OS/390, OS/400, RACF, RS/6000,
SQL/400, S/390, System/390, VTAM, and WebSphere are registered trademarks; and Communications System for Windows NT, IMS, MVS, SQL/DS, Universal
Database, and z/OS are trademarks of IBM Corporation. JBoss and JBoss Group are trademarks of Marc Fleury under operation by JBoss Group, LLC. J.D.
Edwards and OneWorld are registered trademarks, and WorldSoftware is a trademark of J.D. Edwards. Linux is a registered trademark of Linus Torvalds and
others. X Window System is a trademark of Massachusetts Institute of Technology. MetaSolv is a registered trademark of Metasolv Software, Inc. ActiveX,
Microsoft, Outlook, Visual Basic, Windows, and Windows NT are registered trademarks; and SQL Server is a trademark of Microsoft Corporation. Teradata is
a registered trademark of NCR. Netscape is a registered trademark of Netscape Communications Corporation. New Atlanta and ServletExec are trademarks
of New Atlanta Communications, LLC. CORBA is a registered trademark of Object Management Group, Inc. UNIX is a registered trademark of Open Group.
Oracle is a registered trademark of Oracle Corporation. PeopleSoft and Vantive are registered trademarks, and PeopleSoft Pure Internet Architecture is a
trademark of PeopleSoft, Inc. Infranet and Portal are trademarks of Portal Software, Inc. RosettaNet is a trademark of “RosettaNet,” a non-profit organization.
SAP and R/3 are trademarks or registered trademarks of SAP AG. Siebel is a trademark of Siebel Systems, Inc. SPARC and SPARCStation are trademarks of
SPARC International, Inc. SSA Global is a trademark and SSA Baan is a registered trademark of SSA Global Technologies, Inc. EJB, Enterprise JavaBeans, Java,
Java Naming and Directory Interface, JavaServer Pages, JDBC, JSP, J2EE, Solaris, Sun Microsystems, and SunSoft are trademarks of Sun Microsystems, Inc.
SWIFT and SWIFTNet are trademarks of S.W.I.F.T. SCRL. Sybase is a registered trademark of Sybase, Inc. UCCnet is a trademark of UCCnet. eBusinessReady
is a trademark of Uniform Code Council, Inc. (UCC) and Drummond Group, Inc. (DGI). Verisign is a registered trademark of Verisign. VERITAS, VERITAS
SOFTWARE, and VERITAS Cluster Server are trademarks of VERITAS Software. W3C is a registered trademark of World Wide Web Consortium.
All other marks are the property of their respective owners.
Copyright © 2002-2004 by webMethods, Inc. All rights reserved, including the right of reproduction in whole or in part in any form.
Document ID: MOD-UG-61-20040322

Contents
Contents
About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
What is Modeling? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
What is the webMethods Modeler? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
webMethods Modeler and Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Modeler and the webMethods Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Modeler Design-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Design-time Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Controlled and Uncontrolled Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Steps and Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Multiple Steps Represented as a Single Icon in the Process Model . . . . . . . . . . . . . . 25
Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Process Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Run-time Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Participants in Process Modeling and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Bottom-Up Vs. Top-Down Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Top-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Bottom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Phases of Development and Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The Production Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Introduction to BPEL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 2. Getting Started with webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Starting the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Updating the Workflow Client Directory from Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Connecting to a Different Design Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Shutting Down the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Familiarizing Yourself with the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
webMethods Modeler User’s Guide Version 6.1 3

Contents
Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Main Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Process Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Process Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
View Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 3. Configuring webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Defining Servers Where Process Steps Will Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Defining Logical Servers and Their Physical Server Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Editing Logical Servers and Their Physical Server Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
For More Information on Server Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Changing the Modeler Repository Storage Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapter 4. Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Before Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Basic Steps in Process Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Process Model Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
The To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Tasks in the To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Process Model Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Step Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Workflow Step Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Steps Outside of the Scope of the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Viewing the To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Quick Reference of Basic Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Saving a Process Model as a JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 5. Adding Steps to a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Flow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Workflow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Web Service Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Empty Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Terminate Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Step Functions and Step Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Start Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
End Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Process-Wide Error Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Join Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Join Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4 webMethods Modeler User’s Guide Version 6.1

Contents
Referenced Process Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Subprocess Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Accessing and Editing a Subprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Restoring a Subprocess to the Main Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Working with Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Defining Web Service Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Importing Port Types from a WSDL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Defining Web Service Port Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Defining New Process Port Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Adding Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Defining Web Service Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Web Service Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Binding for Web Service Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Using Static Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Using Dynamic Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Using Deployment-time Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Mapping WSDL Elements to EndPointReference Document Fields . . . . . . . . . . . . . . . . . . 101
Web Service Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Web Service Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Guidelines on Using Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Controlling the Visual Properties of Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Changing a Step’s Icon Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Controlling the Display of Step Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Chapter 6. Assigning Inputs and Outputs to Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Types of Inputs and Outputs Available to Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
How Information Flows through the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Are Step Inputs/Outputs Required or Optional? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Assigning and Editing Step Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Subscription Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Adding a Subscription to an External Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Guidelines for Using External Documents in the Process Model . . . . . . . . . . . . . . . . 112
Adding a Subscription to a Publishable IS Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Guidelines on Subscribing to IS Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Editing Subscription Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Editing the Instance Name (or Role) of a Subscription Document . . . . . . . . . . . . . . . 120
Editing the Contents of an Existing Subscription Document . . . . . . . . . . . . . . . . . . . . 120
Deleting Subscription Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Contents
Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Adding Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Editing Input Data Instance Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Deleting Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Assigning and Editing Step Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Publishing an IS Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Editing Publication Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Deleting Publication Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Adding Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Editing Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Deleting Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Adding Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Editing Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Deleting Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Publication and External Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Having a Step Send an External Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Controlling the Display of Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Choosing Fields to Log For Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Using the Publish/Subscribe Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Building Publish/Subscribe Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Working with Global Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
How Global Data Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Using Global Data in Your Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Defining Data Properties and Data Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Chapter 7. Adding Logic to Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Working with Flow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
How Modeler Generates Flow Services for Flow steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Guidelines for Working with Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
PRT Services that You Might Want to Use in User-Defined Services . . . . . . . . . . . . . . . . . 150
Controlling the Process’s Run-Time Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Creating and Logging User-Defined Activity Messages . . . . . . . . . . . . . . . . . . . . . . . 150
Selecting a Service to Invoke for a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Working with Workflow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Guidelines for Generated Workflow Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Selecting a Workflow to Invoke for a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Contents
Working with Correlation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Checklist of Correlation Services Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Tips for Creating the Correlation ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Examples to Use for Forming the Correlation IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Determining How the Correlation ID-to-PID Mapping Will Be Created . . . . . . . . . . . . . . . . . . . . 154
The PRT Automatically Creates the Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
You Must Manually Create the Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Mapping Method 1: Use the establishCorrelation Service within Upstream Step Logic 154
Mapping Method 2: Use the Conversation ID of the Start Step’s External Document . 155
Creating a Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Input/Output Specification for the Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Assigning a Correlation Service to a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Editing an Existing Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Deleting an Existing Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Broadcasting Correlation IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Chapter 8. Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Overview of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Summary of Transitions Allowed Per Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Transition Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Splitting, Branching, and Joining Logic in a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Building Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Defining Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Edit Transition Conditions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Defining Transition Conditions Using XPath Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Working with Global data in XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Guidelines for Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Guidelines for Transitions that Create Splits and Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
The Appearance of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Displaying/Hiding Transitions Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Controlling the Color of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Default Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Other Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Chapter 9. Adding Groups to a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Adding a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
External Groups and Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Contents
Resizing and Moving Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Changing the Appearance of Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Chapter 10. Importing and Exporting BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . 181

Importing BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
BPEL Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Partner Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Variables, Message Types, and Document Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
BPEL Web Service Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Terminate Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Empty Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Wait Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
While Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Assign Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
BPEL Structural Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Flow without Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Flow with Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Pick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Exporting Process Models in BPEL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
BPEL Export Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
BPEL Export Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Chapter 11. Generating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Overview of Process Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
What Modeler Generates for a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Items Generated for Steps Associated with Integration Servers . . . . . . . . . . . . . . . . . . . . . . . . . 201
Sample Process Model and Generated Run-time Elements . . . . . . . . . . . . . . . . . . . . . . . . 204
Items Generated for Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Web Service Receive/Reply Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Web Service Invoke Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Items Generated for Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Workflow Step Generation and Multiple Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
What Modeler Generates to Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Consequences to Changing the Associated Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Validating a Process Model Before Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Contents
Before You Can Execute a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

STEP 1: Generating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Regenerating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Before You Can Execute a Regenerated Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Changes that Modeler Makes when Regenerating Integration Server Run-time Elements 211
Changes that Modeler Makes when Regenerating Workflow Run-time Elements . . . . . . . 215
Troubleshooting Process Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
STEP 2: Optionally Adding Logic to Generated Run-time Elements . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Adding Logic to Flow Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Adding Logic to Implementation Modules and Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
STEP 3: Making the Process Model Available for Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
STEP 4: Enabling Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Chapter 12. Managing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Updating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Versioning the Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Deleting Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Exporting and Importing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Exporting Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Importing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Managing Logical Servers and Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Managing Logical Servers in the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Managing Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Chapter 13. Moving Process Models to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Servers and Moving Processes to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Items that You Need to Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Identifying the Items You Need to Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Information the Deployment List Contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Generating the Deployment List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Moving Items that Reside on Integration Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Moving Modeler Generated Run-time Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Locating the Items to Include in the Release of the Package . . . . . . . . . . . . . . . . . . . . . . . 239
Creating Releases Based on Your Logical-to-Physical Server Mappings . . . . . . . . . . . . . . 241
Mappings in the Development Environment Mirror the Production
Environment Exactly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Mappings in the Development Environment Do Not Mirror the Production
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Contents
Moving Referenced Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Moving Items that are Stored in Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Moving Items that Reside on webMethods Workflow Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Moving Process Models to Production Process Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Appendix A. Tuning Performance and Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Backwards Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Quality of Service vs. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Maximum Quality of Service: Minimum Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Maximum Performance: Minimum Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Configuring the System to Meet Your Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
STEP 1: Configure the Territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Overview of Tuning the Territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Choosing Central vs. Distributed Process Tracking Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Central Process Tracking Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Distributed Process Tracking Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Choosing a Process Completion Tracking Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Single Server Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
STEP 2: Configure Process-Level Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Step 1: Choose Global Default Process Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Step 2: Tune Individual Process Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Choosing a Logging Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Logging Level Effect on Document Field Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Using Volatile Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Effect on Monitor Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Using Volatile Transition Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Effect on Automatic Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Summary of Using Volatile Transition Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Contents
Optimizing the Process Locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Effect on Where the Process Automatically Recovers . . . . . . . . . . . . . . . . . . . . . . . . 264
Example of a Process with Enabled Optimize Locally Property . . . . . . . . . . . . . . . . . 265
Example of Process that Does Not Optimize Locally . . . . . . . . . . . . . . . . . . . . . . . . . 266
Managing Correlation IDs in a Distributed Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Local Correlation Property’s Effect on Correlation ID Receipt . . . . . . . . . . . . . . . . . . . 267
Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Summary of Local Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
STEP 3: Optionally Modify Step Pipeline Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
A Note About Referenced Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Appendix B. Guidelines for Working with Referenced Processes . . . . . . . . . . . . . . . . . . . 271

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Referenced Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Design Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Referenced Process Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Design-Time Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Assigning Inputs and Outputs to Referenced Process Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Related Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Assigning a Return Join Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Using the Hot-Swappable Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
If a Referenced Process Step is Hot-Swappable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
If a Referenced Process Step is Not Hot-Swappable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Appendix C. Migrating 4.6 Process Models to Modeler 6.1 . . . . . . . . . . . . . . . . . . . . . . . . 279

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Basic Steps in Process Model Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Ensuring the Model is 6.1-Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Assign Valid Logical Servers to Each Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Ensure All Documents in the Model Exist on the 6.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Check the Integrity of Step Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Check the Integrity of Transitions and Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Migration of Typical Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Migration of Trading Networks “Status”-Based Transition Conditions . . . . . . . . . . . . . . . . . 284
If a 4.6 Step Has TN “Status” Conditions and Other Conditions . . . . . . . . . . . . . . . . . . . . . 284
If a 4.6 Step Has More than One TN “Status” Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Contents

About This Book
About This Book
This guide is for users of webMethods Modeler. It provides procedures for how to use
webMethods Modeler to build, generate, and deploy business process models. With
webMethods Modeler, you can create easy-to-understand, visually-based, process
automation solutions that integrate the pillars of integration.
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.
Additional Information
The webMethods Advantage Web site at http://advantage.webmethods.com provides you
with important sources of information about the webMethods Integration Platform:
Troubleshooting Information. webMethods provides troubleshooting information for
many webMethods components in the webMethods Knowledge Base.
Documentation Feedback. To provide documentation feedback to webMethods, go to the
Documentation Feedback Form on the webMethods Bookshelf.
Additional Documentation. All webMethods documentation is available on the
webMethods Bookshelf.

About This Book

WEBMETHODS MODELER
CHAPTER 1
Concepts
What is Modeling? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
What is the webMethods Modeler? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
webMethods Modeler and Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . 17
Modeler and the webMethods Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Modeler Design-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Process Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Participants in Process Modeling and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Bottom-Up Vs. Top-Down Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Phases of Development and Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Introduction to BPEL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

CHAPTER 1 Concepts
What is Modeling?
Modeling is drawing a diagram that illustrates a business process. Modeling helps you to:
Visualize the actions taking place in the business process
Indicate the work or information flow
Analyze the business process
Document the business process and your procedures
What is the webMethods Modeler?

webMethods Modeler is a design-time tool that you use to draw business process models.
However, webMethods Modeler goes beyond modeling the business process. After you
draw the process model, webMethods Modeler allows you to generate the components
needed to execute your business process in the underlying webMethods platform.
With webMethods Modeler, you can create easy-to-understand, visually-based, process
automation solutions that integrate any or all of the following pillars of integration:
Internal systems and applications
Databases/data warehouses
Trading Partners
Web services
Mainframes
Workflows (human interactions)

The graphical modeling capabilities of webMethods Modeler provide a high-level view of
the business process, including the interaction across the pillars of integration. You can
quickly and easily create visual models that represent the flow of information within the
enterprise and beyond by placing icons representing steps in the process onto a screen
window. If multiple steps in a process occur within an internal group (e.g., accounting
department) or an external partner group (e.g., buyer), you can box the steps together to
designate that the steps are performed by that specific internal or external group. If your
business process involves many steps, you can collapse steps to make the process model
visually simpler, but can still easily access and traverse the collapsed steps. You can make
your process model self-describing by using specialized icons for different steps and
annotating the process model with text labels and notes.

webMethods Modeler and Business Process Management
webMethods Modeler and Business Process Management

Business process management represents the ability to model, integrate, manage, and
optimize interactions between the six pillars of integration (internal systems and
applications, databases/data warehouses, trading partners, web services, mainframes, and
human workflow).
webMethods Modeler is the tool to use to model your business processes that intertwine
these six pillars of integration and to generate the run-time components of those business
processes. The webMethods platform also includes webMethods Monitor that you can
use to monitor and manage your business processes and webMethods Workflow that you
use to model and run the human interaction portion of your business processes.
Modeler and the webMethods Platform

The following shows the architecture of the webMethods platform and how Modeler fits
into this architecture.
webMethods Platform Architecture and webMethods Modeler
Modeler
Process Audit Log

Design
Server
IS IS IS IS
Modeler WmModeler WmMonitor Monitor
repository package package
Broker Workflow

CHAPTER 1 Concepts
Component Description
Modeler webMethods Modeler is a Java GUI. It is the tool that is described
in this manual and that you use to draw and generate business
process models.
Design Server The Design Server is an Integration Server to which you connect
the Modeler. You install the WmModeler package on the Design
Server machine. The WmModeler package contains the services
that are needed to load and store process model definitions, which
are maintained in the Modeler repository. The WmModeler
package also installs the services required to generate the run-time
components required to execute process models.
Modeler The Modeler repository is a storage area that Modeler uses to save
repository (through the WmModeler package) process model information.
Typically, you define the Modeler repository on the same machine
as the Design Server.
IS The components labeled IS in the diagram represent the
Integration Servers you have installed in a single territory. (A
territory is all servers connected to a single Broker.) These servers
can have webMethods components installed on them such as
webMethods Trading Networks or webMethods PeopleSoft
Adapter. When you draw a process model, the Modeler can access
information from these servers. For example, if you are running
Trading Networks on a server, you can draw process models that
reference documents sent to and from your trading partners.
Broker The Broker acts as the communication link between Integration
Servers in a territory. The Broker receives, queues, and delivers
internal documents that are sent and received within your
Enterprise. The Broker routes internal documents between servers
based on subscriptions. One server publishes a document to the
Broker and the Broker delivers the document to any server that
subscribes to that type of document.
When you draw your process model, you identify on what server
a step takes place. If a step is executed on one server and the next
on a different server, at run time, the server performing the first
step creates an internal document and sends it to the Broker. The
second server will have a subscription to this internal document,
and consequently will receive the document when the Broker
sends it. The Modeler defines these internal documents and
subscriptions when you generate a process model.

Modeler Design-Time Environment
Process Audit The Process Audit Log is a database that the Integration Servers in
Log the territory use to log audit information about the execution of
business processes. The Process Audit Log is stored in an external
relational database, such as Oracle, Sybase, or Microsoft SQL
Server.
Workflow webMethods Workflow is a Java GUI. You use Workflow to model
and execute human interaction. You can include Workflow steps
in your business processes where human interaction is required in
a business process.
Monitor webMethods Monitor is an administrative tool that you use to
examine instances of business processes, services, integrations,
and documents that the integration platform is processing or has
finished processing. Besides viewing status information about
your processes, services, integrations, and documents, you can
also use Monitor to perform control tasks such as suspending or
resuming processes or editing and resubmitting documents,
services, or the step pipeline.
webMethods Monitor retrieves information about processes,
services, integrations, and documents by querying the audit logs
and the Trading Networks database.
The Monitor is hosted by an integration server. You access
webMethods Monitor through a web browser.

webMethods Modeler is the design-time tool for modeling a business process and
generating the run-time elements required to execute the business process. This section
describes:
Architecture involved when designing process models
Elements of a process model
Approach to developing process models

CHAPTER 1 Concepts
Design-time Architecture
The following shows the design-time architecture for creating process models using
webMethods Modeler.
Design-time Architecture
Modeler
Design
Server
Modeler IS IS IS IS
repository WmModeler Workflow
package
Logical Server Names = Utility Services Accounting Customer Info Partner Gateway
Modeler During design time, you use the Modeler (a Java GUI) to draw the
process model by placing icons on a screen window and linking
the icons to show the process and information flow. Each icon
represents a step in the process.
As you draw the model, you identify where each step is to be
completed; that is, you assign steps to servers. However, when
assigning the steps, you do not specify a specific physical server
(e.g., acct45.company.com:5555). Rather, you assign steps to a
logical server (e.g., Accounting). Each logical server is mapped to a
physical server. By assigning the steps to logical servers you assign
steps based on functionality and can easily change the underlying
physical servers. When you generate the process model, the
Modeler uses the logical-to-physical server mapping to know
where to place the run-time elements that it creates.
The Modeler connects to the various servers, as needed, to retrieve
information you might require when drawing your process model.
For example, as you identify services and documents in the
process model, Modeler connects to the machines containing those
services and documents.

Design Server The Design Server is an Integration Server on which the
WmModeler package resides. You connect the Modeler to the
Design Server when you initialize the Modeler. The Design Server
is responsible for authenticating the access to the Modeler GUI and
the Modeler repository. It also contains the logic necessary to
update process models to the Process Audit Log, so you can
monitor a process using webMethods Monitor.
Modeler The Modeler saves information about the process models that you
repository draw to the repository. When you want to view a previously saved
process model, the Modeler obtains information about the process
model that it stored in the repository, so it can display the process
model in the Modeler GUI. The Modeler accesses the Modeler
repository via the WmModeler package on the Design Server.
IS The Integration Servers contain the documents, services, and
records that you will want to access when drawing your process
models. The Modeler directly connects to an Integration Server as
information is needed when designing the process model.
When you generate the process model, the Modeler stores services,
triggers, and process run-time scripts on Integration Servers. These
services, triggers, and process run-time scripts are the run-time
elements that execute when the process runs.
Workflow Use webMethods Workflow to design human workflows that
represent the human interaction that is required for a business
process. For example, you might need a step to have a person
approve a purchase order. Modeler directly connects to Workflow
when you specify that a Workflow step connect to a workflow that
you have previously created. Or you can simply create a Workflow
step for which you will later define the human workflow.
When you generate the process model, Modeler creates Workflow
projects, implementation modules, and Workflow tasks in the
webMethods Workflow environment.

CHAPTER 1 Concepts
Process Models
Process models are the diagrams that illustrate a business process that you create using the
Modeler.
Sample Process Model

Internal groups box steps
that are performed within
your enterprise
Steps represent an
automated process
performed by a computer or
a manual step performed by
a person.
Transitions are lines
between steps that
indicate the flow of
execution.
External groups box steps

that are performed outside
your enterprise.
A process model consists of:

Steps
Transitions
Groups (optional)
Annotations (optional)

Steps
Steps are the basic unit of work in a business process. A step can represent an automated
process performed on an Integration Server (e.g., executing a service), a manual step
performed by a person (via webMethods Workflow), or a visual aid that identifies a task
that an external organization performs. Steps can also depict a service that you want
executed if an error or timeout occurs in the process.
You add a step to a process model by placing an icon on the screen. You can use the
default icon for a step or select a different icon. You might select a different icon to make
your process model more self-describing. For example, you might use an icon of a truck to
represent a step that represents an item is to be shipped to a buyer.
The Modeler provides three main kinds of steps: Flow steps, Workflow steps, and Web
Service steps.
Flow steps. Flow steps represent automated processes, such as executing a service. This
can include steps that execute when another step or the process times out or
encounters an error. When you generate the process model, the Modeler generates
flow services, triggers, and process run-time scripts as the run-time elements for this
type of step.
Workflow steps. Workflow steps are manual steps that require human intervention. A
person performs this type of step using webMethods Workflow. You add a Workflow
step that references a human workflow in the webMethods Workflow system. When
you generate the process model, the Modeler generates a webMethods Workflow
project and implementation module that contains the reference to the human
workflow.
Web Service steps. Web Service steps allow you to define and manage relationships
between BPEL partners and define web service interactions. These steps are designed
to replicate the BPEL invoke, receive, and reply activities.
Controlled and Uncontrolled Steps

At design time, you have the option of placing steps into groups, either internal or
external. Groups provide visual and conceptual demarcations to a process model that
make it easier to understand. By placing steps into groups, you create two new step
categories: controlled or uncontrolled.
Controlled steps are those within an internal group or outside of any group. Most steps in a
typical process model are controlled steps. They include Flow steps or Workflow steps for
which Modeler generates run-time elements (e.g., flow services, triggers, process run-time
scripts, and Workflow elements).
Uncontrolled steps are those that you include in the process model purely as a visual aid.
They identify tasks that an external organization (e.g., a trading partner) performs. You
add uncontrolled steps to your process model to make the model easier to understand
and more self-describing. They are not necessary. When you generate the process model,
the Modeler does not generates any run-time element for this type of step.

CHAPTER 1 Concepts
Steps and Information Flow

Steps in a process require data or information on which they act. When you design your
process model, you indicate the data a step needs or acts on by identifying data as input
into the step. During processing, a step can create data and this data is available to other
steps that are downstream in the process model. To indicate the data that results from the
execution of a step, you identify data as the outputs of the step.
There are two main types of data on which a step can act: publication/subscription
documents and input/output data.
Publication/subscription documents. Publication and subscription documents are
documents that your process model is to publish or to which your process is to create
a subscription. These publications and subscriptions allow your process model to
send information to and receive information from applications or services that are
external to your process model. When you define a step in your process model, you
can have Modeler display a list of the documents that are available on the logical
server associated with the step. At run time, the receipt of the start step’s subscription
document signals to the process run time (PRT) that the business process should start
running. The types of documents that you can publish and/or to which you can
subscribe are:
IS documents that are exchanged through the Broker. This type of document
allows communication between the various webMethods components. IS
documents to which a step subscribes become part of the process pipeline.
External documents that are exchanged through webMethods Trading Networks.
This type of document allows communication to and from sources outside the
webMethods platform, for example, trading partners. Examples of these types of
documents are purchase orders, confirmations, acknowledgements, etc.
You can define publish/subscribe filters to restrict the documents that a step subscribes
to or publishes. You define filters by specifying conditions that a document must meet
to be used by the step. For example, you might have a step that subscribes to a cXML
purchase order. However, you only want the step to use the document if the total
purchase amount (field TotalAmount within the document) is greater than $10,000. In
this case you would set a filter using the field TotalAmount that indicates that you only
want the step to use the document if the field TotalAmount is greater than 10,000.
You can also define publish/subscribe filters based on information about trading
partners referenced in the process model.
Pipeline data. In contrast to publications and subscriptions, pipeline data deals only
with information available within a given process, rather than information that can be
retrieved from or sent to external sources. Specifically, pipeline data is all information
(documents and other data types) available to any given step because it was
introduced upstream in the process. That is, it is information that is in the process
pipeline.

Multiple Steps Represented as a Single Icon in the Process Model

There are two ways you can represent multiple steps using a single icon in a process
model: referenced processes and subprocesses.
Referenced processes are pointers to another process model that you have previously
defined. The ability to reference a process inside another process model allows you to
reuse steps and simplify your design.
To edit a referenced process, you must open the original process. When you edit a
referenced process, the changes are automatically reflected in all processes that
reference it. For example, if process model A and B reference process model C, you
must open and update C to make changes to it. The changes that you make in process
model C take affect in process models A and B.
Subprocesses are a collection of steps in your process model that you collapse into a
single icon. Create subprocesses in your process model to combine several steps to
make the process model visually simpler. You can easily descend into the collapsed
steps to view them.
Transitions
You draw transitions (or lines) between steps to indicate the execution order of the steps
within the process model.
To control the flow of execution, you can place conditions on transitions. The condition
affects whether a transition is taken or not. For example, during the process model you
might need to approve an item. After the step that determines whether the approval is
granted, you would use transition conditions so the model transitions to one step if
approval is granted and another if approval was not granted.
Using transitions you can create splits, branches, and joins.
Splits. You create splits when you draw transitions from one step to two or more steps
without placing conditions on the transitions. At run time, all transitions are executed
and processing splits into two or more threads of execution.
Branches. You create branches when you draw transitions from one step to two or
more steps and place conditions on the transitions, so at run time, at most one
transition is executed.
Joins. You create joins when you draw transitions from two or more steps to a single
step, merging multiple threads of execution to return to a single thread of execution.
You can also create a join by subscribing to multiple documents, or by subscribing to a
document that also has an input transition.

CHAPTER 1 Concepts
You can also create the following types of transitions to handle special conditions that
might occur for a particular step:
Retries Exceeded. The step property Retry Count specifies the number of times to
execute a step. At run time, if the process attempts to execute the step more times than
Retry Count specifies, then the process takes the Retries Exceeded transition.
Timeout. When you create joins that cause the process to wait for multiple events to
occur before continuing (e.g., AND joins), you can specify how long to wait for all the
events to occur. At run time, if the amount of time you specify is exceeded, the
process will take the timeout transition. This relative timeout can be set for a number
of milliseconds or based on an XPath condition.
You can also set an absolute timeout for a join condition that will cause the process to
continue until a set date and time, or based on an XPath condition.
Error. An error transition incorporates general error handling for a step. At run time,
the error transition is taken if the service executed by the step throws an exception.
Else. Else transitions specify what step should execute if no other transitions are
followed. At run time, if no other transitions from a step are followed, the Else
transition will be followed.
Groups
You can place steps into groups to represent different organizational boundaries within
the business process model. Groups are represented by shaded rectangles in the process
model. Placing steps within groups can be a helpful visual aid for complicated process
models, but is never required. There are two types of groups: internal and external.
Internal groups Steps within internal groups (as with steps outside of any group) are
steps within the scope of the business process. That is, they are controlled steps. You
might use internal groups to specify different departments within the process (for
example, accounting or purchasing) that complete a specific grouping of steps.
External groups You place steps within external groups to visualize steps that occur
outside of the scope of the business process, for example, a step that waits for a
document or sends an acknowledgement. Since steps in external groups are by
definition outside the scope of the process, they are known as uncontrolled steps. That
is, when you generate the process model, the process run ignores these steps
completely; no run-time elements are generated for these steps. Use external groups if
it helps you to conceptualize steps in a process that occur outside of the scope of the
process.

Process Execution
Annotations
You can annotate your process model by labeling steps, transitions, groups. Additionally,
you can place notes and explanatory text anywhere on your process model.
Note–text that is enclosed in a shaded box
Text–lines of text without a border or background

The annotations you add to your process model help describe your business process and
make it self-describing.
Process Execution
Processes execute in the underlying webMethods platform. A process begins execution
when the conditions for the first step(s) in the process is met. For example, if the process
model indicates the process begins when a specific purchase order arrives from a partner,
the process begins when that purchase order arrives.
One of the run-time elements that are generated from the process model are called process
run-time scripts. The process run-time scripts determine when a step needs to start, when
one step is complete, and when to pass control to another step.
After a process has started, you can monitor and manage the process using the
webMethods Monitor. For example, you can view the steps a process has completed and
whether the steps were successful or not. You can suspend a running process, then
resume it; or you can terminate a running process if you no longer want it to execute.

CHAPTER 1 Concepts
Run-time Architecture
The following shows the run-time architecture for executing business processes that you
design using webMethods Modeler.
Run-time Architecture for Business Processes
Process Audit Log
P IS P IS P IS P IS
R R R R WmMonitor Monitor
T T T T package
Broker Workflow
IS The Integration Servers contain the run-time elements that were
generated from the automated controlled steps within the process
model. The run-time elements are services, triggers, and process
run-time scripts.

Process Execution
PRT The process run time (PRT) is a facility within an Integration
Server that runs the process run-time scripts. It is the run-time
component that executes process logic, logs process data, and
controls process execution order.
It is the responsibility of the PRT to pass control of execution from
one step to the next. Based on how the process model was
designed, two consecutive steps might be executed on different
servers. PRT passes control to different steps by publishing
internal documents (called process transition documents) to the
Broker. The Broker sends the process transition documents to the
server that has the subscription.
As the process executes, the PRT logs data about processes to the
Process Audit Log. It logs information such as the results of
completed steps, documents used in the process, and process
status. The webMethods Monitor uses this information when a
user monitors the process.
The PRT also handles the suspend, resume, restart, and terminate
commands that a user issues from webMethods Monitor. To
process these commands, webMethods Monitor publishes process
control documents to the Broker. The Broker dispatches the
document to the PRTs on the Integration Servers to handle the
request.
Broker The Broker acts as the communication link between Integration
Servers in a territory. The Broker receives, queues, and delivers
internal documents that are sent and received from the various
PRTs and webMethods Workflow.
Process Audit The PRT logs audit data about running processes to the Process
Log Audit Log.
Workflow The PRT passes control to webMethods Workflow when the
process requires human interaction. To perform the human
interaction, responsible parties use webMethods Workflow to
exercise the human workflows that you referenced in the process
model.

CHAPTER 1 Concepts
Monitor webMethods Monitor is an administrative tool that you use to
examine instances of business processes, services, integrations,
and documents that the integration platform is processing or has
finished processing. Besides viewing status information about
your processes, services, integrations, and documents, you can
also use Monitor to perform control tasks such as suspending or
resuming processes or editing and resubmitting documents,
services, or the step pipeline.
webMethods Monitor retrieves information about processes,
services, integrations, and documents by querying the audit logs
and the Trading Networks database.
The Monitor is hosted by an integration server. You access
webMethods Monitor through a web browser.
Participants in Process Modeling and Implementation

There will be most likely be more than one person involved in the various phases of
process model design and implementation. The people involved will have different types
of expertise. For example, a business analyst or architect might conceive of the high-level
steps that need to happen in a process; the same or another person might physically draw
the model within Modeler. And yet another person (a programmer or person with
implementation expertise) might create the logic associated with the model’s steps.
Bottom-Up Vs. Top-Down Approach

You can approach process model design in two ways. You can use a top-down or bottom-
up development approach (or a mixture of the two). The approach you use is a matter of
preference.
Top-Down
In the top-down approach, you draw a process model before creating any of the services,
workflows, or data upon which the process depends. Using this approach, when you
draw the process model, you specify the type of data that a step expects (e.g., an IS
document, an external document, a String, etc.). You also specify on which logical servers

Phases of Development and Production
the services associated with steps will execute. When you generate a process model
created in this way, Modeler generates empty flow services to the Integration Server(s)
and empty implementation modules and workflows to Workflow. Later, you use
Developer or Workflow to fill in the logic.
Bottom-Up
In the bottom-up approach, you create the services, workflows, or data before drawing the
process model. Using this approach, when you draw the process model, you associate
steps with the services, workflows, and data that you have previously created. When you
generate a process model created in this way, Modeler creates flow services to contain the
services that you have specified, and Workflow implementation modules to contain the
workflows that you have specified.
Note: Even if you create services and workflows before associating them with a given
model, you still will need to use Developer and Workflow to tweak these services so that
they are set up correctly. For details, see Chapter 7, “Adding Logic to Steps”.
Phases of Development and Production

The following sections describe which phases of process model creation or management
are associated with which type of environment.
The Development Environment

Designing. You should create your process models in a development environment. The
logical servers in your development environment must match the logical servers in your
production environment.
Generating and Implementing. When you have completed the process model, you are ready to
generate the run-time elements. You will want to generate the process model to a
development environment. When you generate, Modeler uses the model’s steps and
transitions to create packages, flow services, triggers, process run-time scripts, Workflow
implementation modules and workflows.
Implementing. After generating, add logic and mapping to all generated run-time elements
that need it. For example, you need to add code to services, map services, or design a
human workflow if you have not already done so.
Testing. When the run-time elements are complete, test your business process in the
development environment to ensure it behaves as expected. Make corrections as needed.
When you are satisfied that your business process runs as expected, you can deploy from
your development environment to your production environment.

CHAPTER 1 Concepts
The Production Environment

Deploying. To deploy, move the items in the webMethods platform on which your model
depends (e.g., services, data, workflows) from your development servers to the
production servers. Your physical development servers will be different from your
physical production servers; however, the logical servers in each environment must be the
same. Your logical-to-physical server mappings ensure that the process still runs in the
production environment
Introduction to BPEL Support

Modeler 6.1 introduces the capability to import and export process models from and to
the Business Process Execution Language (BPEL) XML standard. This feature gives users
with the ability to work with business process models that have been developed outside
of the webMethods environment and to share webMethods models with people who do
not have access to the webMethods platform. For importing BPEL, Modeler supports a
limited subset of BPEL constructs, details of which can be found in Chapter 10,
“Importing and Exporting BPEL Process Models”. It is not necessary, however, to use or
understand BPEL for the normal design, building and execution of business processes
with webMethods Modeler.
Note: For details regarding the BPEL language, please refer to the “Business Process
Execution Language for Web Services Specification, version 1.1 dated May 5, 2003” The
specification is available from the following web locations:
http://dev2dev.bea.com/technologies/webservices/BPEL4WS.jsp
http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
http://ifr.sap.com/bpel4ws/
http://www.siebel.com/bpel
The business process behavior defined by BPEL is based on Web Services. In this regard,
BPEL depends on the following specifications:
WSDL 1.1
XML Schema 1.0
XPath 1.0
WS-Addressing
Of these specifications, WSDL (Web Services Description Language) is the most important
in terms of its impact on BPEL. Every BPEL process model is based on the interaction
between services described in WSDL.
Business processes developed according to the BPEL4WS specification are imported to
Modeler using a translation process that substitutes a Modeler step (or steps) for BPEL
activities, as detailed in Chapter 10, “Importing and Exporting BPEL Process Models”

WEBMETHODS MODELER
CHAPTER 2
Getting Started with webMethods Modeler
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Starting the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Connecting to a Different Design Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Shutting Down the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Familiarizing Yourself with the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

CHAPTER 2 Getting Started with webMethods Modeler
Overview
This chapter describes how to start and exit the Modeler, and introduces you to the
Modeler’s user interface.
Starting the Modeler

Before you start the Modeler, make sure the Design Server to which you will connect the
Modeler is running. The Design Server is an integration server on which the WmModeler
package is installed.
To start the Modeler on Microsoft Windows
On the Start menu, select ProgramswebMethodsModeler.
To
To start the Modeler on UNIX
At the shell prompt, type Modeler Installation Directory/bin/runbi.sh.
Updating the Workflow Client Directory from Modeler

To configure webMethods Modeler to connect to webMethods Workflow, launch the
Workflow Designer and connect to a Workflow Server at least once before launching
Modeler. If you installed Workflow client in the same root directory as Modeler, Modeler
will automatically detect the Workflow client installation and prompt you to restart
Modeler. If you installed Workflow client in a separate root directory from that in which
you installed Modeler, Modeler will not be able to detect the Workflow client installation.
To configure Modeler to connect to Workflow in a separate root directory, login to
Modeler, select Options from the Tools menu, and change the value of the Workflow
Directory option to reflect the root location of your webMethods Workflow client
installation. You can accomplish this by clicking the ellipses icon and browsing for the
Workflow client root. Then restart Modeler.

Connecting to a Different Design Server
Connecting to a Different Design Server

You can change the Design Server to which Modeler is connected at any time. To do so,
use the following procedure.
To connect to a different Design Server
1 While running Modeler, choose SessionClose Design Server connection from the menu
bar. The session with that Design Server closes.
2 From the menu bar, choose SessionConnect to Design Server. The Open Session to
Design Server window appears.
3 Select the new Design Server, enter your Username and Password, then click OK.
Shutting Down the Modeler

To shut down the Modeler, follow the single step procedure below.
To shut down the Modeler
Select FileExit.

Familiarizing Yourself with the Modeler

The main Modeler window consists of:
Menu bar
Main toolbar
Process toolbar
Process window
Canvas
View options
Main Modeler Window
Menu bar
Main toolbar
Process window
Process toolbar
Canvas
View Options
Menu Bar
The Modeler menu options are:
File: Use to create, open, close, save, rename, delete, import, export, and print process
models. In addition, use it to exit the Modeler.
Edit: Use to undo and redo recent actions, as well as to delete steps in a process model.

View: Use to view the Properties window, the To-Do List, Global Data, Web Service
Interactions, Web Service Ports, Deployment Information, and process model
Dependencies.
Session: Use to close the connection to the current Design Server and open a
connection to a new one, view the Server Connections Manager, and Refresh Services
and Documents.
Tools: Use to Validate or Generate a business process, update a model for monitoring,
replace logical servers, launch Developer, and access the Options window.
Window: Use to toggle between open process models.
Help: Use to access the About webMethods Modeler screen.
Main Toolbar
The main toolbar provides several icons to access common functions. The icons and their
descriptions are provided below.
This Represents...
icon...
Connect to Design Server. Opens the Open Session to Design Server dialog.
Verify the server name and user name, and enter the password to connect
to the Design Server.
Close Design Server Connection. Closes the current Design Server session.
Open Server Connections Manager. Opens the Server Connections Manager.

You use the Server Connections Manager to connect or disconnect from
servers, and to view logical server names, their host:port addresses, and
connection statuses.
Refresh Documents and Services. Synchronizes the process model to use the
latest documents and services available on the Integration Servers
associated with the process model.
New. Opens a new Process window so that you can create a new process
model.
Open. Opens the file system on which existing process models are stored so
that you can view or edit an existing process model.
Save. Saves changes to the active process model.

This Represents...
icon...
Print. Prints the process model on the active Process window.
Undo. Undoes the most recent action. You can use multiple undos.
Redo. Redoes the most recent action. You can use multiple redos.
Validate Business Process.Validates the business process.
Generate Business Process.Generates the business process.
Update Model for Monitoring. Moves the process to the Process Audit Log so
that you can monitor the process with webMethods Monitor.
Properties. Opens the Properties window to display the properties of the

selected item, including a step, a transition, or a process model.
To Do List. Opens the To-Do List of the active process model.
Global Data. Opens the Global Data dialog that lists the global data items for
the process.
Web Service Interactions. Opens the Web Service Interactions dialog that
shows the interactions and port types for the process.
Web Service Ports. Opens the Web Service Ports dialog to show the existing
WSDL imports or define new port types for the process.

Process Window
The Process window is where you design your process model. The Process window
appears when you create a new process model or open an existing process model.
Process Window
Process toolbar
Canvas
View options
The Process window consists of:

Process toolbar
Canvas
View options
Properties (optional)
To Do List (optional)

Process Toolbar
The following table lists the icons of the process toolbar, along with a description of each.
This icon... Represents...

Zoom Out. Zooms out of a subprocess and into its parent process.
Zoom In. Zooms in to the subprocess of a selected step.
Switch to Edit. De-selects the item that is currently selected. For

example, if you select New Step and then decide you don’t want to
insert a new step, clicking Switch to Edit de-selects the new step so
that you can choose again.
Delete. Deletes the selected item, e.g., a step.
Insert a Predefined Service or Process. Opens a list of services and

processes that you can insert into the active process.
New Flow Step. Places a new Flow step onto the canvas.
New Workflow Step. Places a new Workflow step onto the canvas.
New Web Service Step. Places a new Web Service step onto the
canvas.
New Empty Step. Places a new Empty step onto the canvas.
New Terminate Step. Places a new Terminate step onto the canvas.
Group. Draws a group box around steps so that you can visually
describe whether the steps are internal or external to your
organization.
Note. Adds a box in which you can type text to make the process
model more self-describing.
Text. Enables you to type text (without a box) to make the process
model more self-describing.
Show/Hide Properties Window and To-Do List. Shows or hides the
Properties window and the To-Do List.

Canvas
The canvas is where you design the business process. You can use a grid to help to position
objects on the canvas symmetrically. You can specify the default grid setting (show or
hide) for all new processes. You can change (override) the default grid setting on any
active canvas.
To specify the default grid setting
1 On the main toolbar, select ToolsOptions.

2 Check or uncheck the Show Grid option.
To change the grid setting of the active canvas
On the View Options area at the bottom of the Process window, check or uncheck
Show Grid.
View Options
The View Options area at the bottom of the Process window contains the following
settings to control the look of the canvas and the objects on the canvas.
This option... Represents...

Zoom. Zooms in or out of the picture on the canvas.
Line Style. Assigns either a curved or straight line style to

the transitions in the process model.
Show Inputs/Outputs. Shows or hides the inputs and
outputs associated with each step.
Show Grid. Shows or hides the grid on the active canvas.
Overrides the default grid setting.
Snap to Grid. Controls whether the Modeler forces objects
on the canvas to adhere to the grid parameters.


WEBMETHODS MODELER
CHAPTER 3
Configuring webMethods Modeler
Defining Servers Where Process Steps Will Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Changing the Modeler Repository Storage Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

CHAPTER 3 Configuring webMethods Modeler
Defining Servers Where Process Steps Will Execute

During process model design, you assign each step a server on which the step’s logic
should generate and execute. Rather than assigning each step a specific physical server
(e.g., mycompany.com:5555), you assign the step a logical server, which you might name
based on functionality (e.g., Accounting).
You set up logical servers and their physical server mappings using webMethods
Administrator. You must do so prior to assigning a logical server to a process model step.
If a logical server’s physical server mapping changes, you can change the mapping from
the Administrator without needing to modify the step’s logical server assignment.
Defining Logical Servers and Their Physical Server Mappings

Use the following procedure to define a logical server and its physical server mapping.
Defining Logical Servers and Their Physical Server Mappings
1 Log in to the webMethods Administrator, if you are not already.

2 In the Logical Servers menu of the Navigation panel, click Add Logical Servers.

Defining Servers Where Process Steps Will Execute
3 In the Add Logical Server page, specify the following information:
For this parameter... Specify...
Name The name you give the logical server.
Important! The name is managed by the system and cannot

be edited once given.
Type The type of physical server: Integration Server or Workflow.

Description (optional) The description that describes the functionality of the
logical server.
Physical Server The name of the physical server to map to the logical server.
The physical server list is comprised of the registered
servers in webMethods Administrator. For information on
registering servers, see the “Managing Resources” chapter
of the webMethods Administrator User’s Guide.
Note: You do not have to choose a physical server to be

mapped to the logical server at this time. If you prefer, you
can add the physical server mapping using the Edit function
at a later time.
4 Click Add Logical Server.

5 Click Return to Logical Servers to return to the previous page.
Editing Logical Servers and Their Physical Server Mappings

Use the following procedure to edit a logical server or its physical server mapping.
Editing Logical Servers and Their Physical Server Mappings
1 Log in to the webMethods Administrator, if you are not already.

2 Click the Logical Servers menu of the Navigation panel.

3 On the Logical Servers page, locate the server you want to modify and click Edit in the
Edit column.
The Edit Logical Server page displays.
4 Make your changes and click Save Changes.

Changes may consist of modifying the type of logical server, the description, and
changing the associated physical server. You cannot change the name of the logical
server.
5 Click Return to Logical Servers to return to the previous page.

Changing the Modeler Repository Storage Mechanism
For More Information on Server Management

For more information on managing logical and physical servers, or on using webMethods
Administrator, see the webMethods Administrator User’s Guide.
Changing the Modeler Repository Storage Mechanism

When you installed webMethods Modeler, you configured the Modeler Repository to
store its data in either a flat file or a database. (For a review of the Modeler Repository
configuration instructions, see the “Complete the Modeler Design Package Installation”
section of the webMethods Integration Platform Installation Guide.) If you configured the
Modeler Repository to write to a flat file, you may later decide that you want to change
your storage mechanism. The following instructions describe how to change your
Modeler Repository storage mechanism from a flat file to a database without losing data.
Changing the Modeler Repository Configuration from Flat File to Database
1 From webMethods Modeler, export all process models to a temporary storage

location. Use the Complete Model export option. For details on exporting process
models, see “Exporting and Importing Process Models” on page 229.
Note: The process model data previously stored in the flat file is converted to an XML
file and exported to the directory of your choice.
2 Change the Modeler Repository configuration from flat file to database on the
Modeler home page at http://Integration Server_host:Integration
Server_port/WmModeler. For instructions on configuring the Modeler Repository to
write to a database, see the “Configure the Modeler Repository to Write to a
Database” section of the webMethods Integration Platform Installation Guide.
Important! If you use an Oracle database, you must use a SequelLink driver and a
SequelLink server to run on the same machine as the database. If you do not, Modeler
performance will be unacceptably slow.
3 Restart the Integration Server and webMethods Modeler.

4 From webMethods Modeler, re-import the process models that you exported in Step
1. For details on importing process models, see “Importing Process Models” on
page 230.
Note: The process model data remains in the XML file, and is also migrated to the
database.


WEBMETHODS MODELER
CHAPTER 4
Creating a Process Model
Before Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Basic Steps in Process Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Process Model Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
The To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Quick Reference of Basic Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Saving a Process Model as a JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

CHAPTER 4 Creating a Process Model
Before Creating a Process Model

The following tables list prerequisites to complete before creating a process model in all
cases, and when you are specifically using a bottom-up development approach. For a
review of the two types of development approaches, top-down and bottom-up, see
Chapter 1, “Concepts”.
Prerequisites for all Process Models
Define all logical servers (and their logical-to-physical server mappings) to be used
in the process. To do so, use webMethods Administrator. See Chapter 3,
“Configuring webMethods Modeler”.
Set up trading partner profiles within Trading Networks for any steps in the
process that need to act on specific information about trading partners.
Define any external document types to be used in the process, e.g., an XML or EDI
document.
Prerequisites for Process Models When Using a Bottom-Up Development Approach
Complete all prerequisites in the “Prerequisites for All Process Models” table
(above).
Create the logic, or services, that process steps should invoke. For guidelines, see
Chapter 7, “Adding Logic to Steps”.
Create all document types that the process model will publish, and all document
types to which the process model will subscribe on all physical Integration Servers
involved in the process model. For details on creating these document types, see
the Publish-Subscribe Developer’s Guide book.

Basic Steps in Process Model Creation
Basic Steps in Process Model Creation

An overview of the steps in process model creation is described below.
To Create a Process Model
1 Start webMethods Modeler. For instructions, see Chapter 2, “Getting Started with
webMethods Modeler”.
2 Open a new process model by selecting FileNew.
3 Set the process model properties. For descriptions of process model properties, see
“Process Model Properties” on page 51.
4 Build the model by adding steps and step transitions. (You might also want to add
groups or annotations.) For more information on defining these items, see:
To add steps, see Chapter 5, “Adding Steps to a Process Model”.
To create step transitions, see Chapter 8, “Creating Step Transitions”.
To add groups, see Chapter 9, “Adding Groups to a Process Model”.
5 Use the To-Do List to ensure that you have completed all tasks associated with the
model and its steps. For details on using the To-Do List, see “The To-Do List” on
page 60.
6 Save the process model by selecting FileSave. In the Save dialog, select the folder in
which you want to save the process model; or, click New to create a new folder. Type a
name for the model in the Save As dialog if you haven’t already, and then click Save.
Process Model Properties

While creating a process model, you define many of its properties. The following table
describes process model properties that either you or Modeler assign to the model.
Important! Some of the properties below define where the underlying process model
components (e.g., flow services, triggers, etc.) generate and execute. More details on this
topic are provided in “What Modeler Generates for a Process Model” on page 201.

Property Description Default

Label Process model name. Before saving a new
model, the model is titled
Note: You should assign each process “New Process”. When you
model a unique name. save the model, you type
the model name.
Description Description of the process model, e.g., Choose Edit to enter a
“Purchase order with Viva Italia July description.
2003”. There is no limit on the description
length.
Package The name of the package to which Modeler Modeler auto-populates
Name will generate the process model this property with the
components (e.g., flow services, triggers, process model name (i.e.,
etc.). Upon generation, Modeler creates a the name that you
package with this name on each physical assigned using the Label
Integration Server associated with the property described
process. above). You may choose
any name you like.
Process Key The internally-generated unique ID that This is a read-only
Modeler assigns to the process model. property.
Created by The Username of the person who initially The Username
created the process model. corresponds to the
Modeler User login name.
This is a read-only
property.
Last The Username of the person who made the The Username
Modification last Save to the process model, and the corresponds to the
time/date stamp of the Save. Modeler User login name.
This is a read-only
property.
Last The date and time that the process model This is a read-only
Generation was last generated. property.
Last Model The date and time that the process model This is a read-only
Update was last updated for monitoring; that is, property.
the last time it was written to the Process
Audit Log. This date and time reflects the
most updated information that
webMethods Monitor has about the
process model.


Version The process model version. Modeler assigns each new
process model a Version
Note: For important information on value of 1. If you select
versioning a process model, see FileSave as New Version,
“Versioning the Process Model” on Modeler increments the
page 227. version by a value of 1,
but you can specify a
different value if you
prefer.
Global Data The Global Data dialog. This dialog Choose Edit to display the
displays global data elements defined for Global Data dialog.
this process.
Data The Data Properties and Data Properties Choose Edit to display the
Properties Aliases dialog. This dialog displays data Data Properties and Data
properties and aliases defined for this Properties Aliases dialog.
process.
Web Service The Web Service Interactions dialog. This Choose Edit to display the
Interactions dialog displays web service interactions Web Service Interactions
defined for this process. Web service dialog.
interactions correspond to the BPEL
PartnerLink construct.
Web Service The Web Service Ports dialog. This dialog Choose Edit to display the
Ports displays the web service ports defined for Web Service Ports dialog.
the process.
Error Step The process-wide error step for the process Select the appropriate step
model. This is the step to be invoked when from the drop down.
any step not associated with its own error
step encounters an error.


Focal Role The unique name for the participant “Focal Role”. To change
hosting the controlled steps (i.e., for your this, type a name in the
role) in the process. The value can be Focal Role box.
whatever you like it to be, e.g., “buyer”,
“seller”, and so on. You should always
create a Focal Role value for process models
using external documents. Modeler uses
these Focal Role values when you assign
step transition conditions to steps and/or
when you assign step publish/subscribe
filters.
Note: If a process does not use external

documents, you can ignore this property.
Logging Level The precise level of information to persist Process and All Steps
to the Process Audit Log; this level
determines the extent to which you can
view and control the process in
webMethods Monitor.
Logging Levels are:
None
Errors Only
Process Only
Process and Start Steps
Process and All Steps
Note: If you want to log the pipeline of

individual steps or view the maximum
amount of information about the process
and its steps at run time (through the
Monitor), choose “Process and All Steps”.
Log Turns on transition logging. Check the box to turn on

Transitions transition logging.


Express Whether to use a complete or abridged Disabled
Pipeline (express) pipeline at run time. When
enabled, the PRT sends an abridged
pipeline to subsequent steps in the process.
That is, PRT sends only those
inputs/outputs which have been explicitly
chosen on the steps in the Modeler. In this
scenario, if you create a flow service to be
invoked by a step, and that flow service
adds data to the pipeline, Modeler does not
propagate that data to subsequent steps.
That is, you are unable to access flow
service-created pipeline values
downstream when Express Pipeline is
enabled.
If this property is disabled, the PRT sends
the entire IS pipeline downstream,
regardless of whether that data is explicitly
used downstream. RosettaNet processes,
for example, make use of many hidden
variables that are hidden at the process
level, so those processes would not use an
Express Pipeline.
Note: If you do not use an Express Pipeline,

the pipeline is larger, which might slow
performance.


Volatile Whether the integration servers hosting For new processes (i.e,
Tracking the process should store process transition those created and
documents in the Process Tracking Store generated after the
or in RAM. If this property is enabled, application of Modeler
servers store these documents in RAM. If it 6.0.1 SP1 and Integration
is disabled, servers store documents in the Server 6.0.1 SP2), the
Process Tracking Store. default is Enabled.
For pre-existing processes
(i.e, those created and
generated before the
application of Modeler
6.0.1 SP1 and Integration
Server 6.0.1 SP2), the
default is Disabled. This
ensures that models
created before the
existence of the service
packs work as they did
before service pack
application, unless
settings are manually
changed.


Volatile Whether the Broker should store process For new processes (i.e,
Transition transition documents to hard disk or in those created and
Documents RAM. If this property is enabled, Broker generated after the
uses RAM. If it is disabled, Broker uses application of Modeler
disk. 6.0.1 SP1 and Integration
Note: If the step is a Workflow step, Broker default is Enabled.
always stores process transition For pre-existing processes
documents to hard disk, thus guaranteeing (i.e, those created and
Workflow’s receipt of the document. generated before the
application of Modeler
ensures that models
created before the
before service pack
application, unless
changed.


Optimize Whether servers should publish process For new processes (i.e,
Locally transition documents between execution of those created and
adjacent steps on the same IS. A simpler generated after the
method of passing control between steps application of Modeler
on the same IS is to directly invoke them. 6.0.1 SP1 and Integration
This decreases Broker traffic and increases Server 6.0.1 SP2), the
performance. default is Enabled.
If enabled, servers use the direct invoke to For pre-existing processes
pass control between steps on the same IS. (i.e, those created and
If disabled, servers publish process generated before the
transition documents between execution of application of Modeler
adjacent steps on the same IS. 6.0.1 SP1 and Integration
ensures that models
created before the
before service pack
application, unless
changed.


Local Whether to save correlation IDs on the For new processes (i.e,
Correlation local server that created them, or whether those created and
it is necessary to broadcast them to generated after the
different servers in the process. application of Modeler
It might be necessary to broadcast these Server 6.0.1 SP2), the
IDs when 1) the process spans multiple default is Enabled.
servers and 2) the territory uses a
distributed Process Tracking Store. For pre-existing processes
Broadcasting IDs ensures that if the step (i.e, those created and
that needs the correlation ID is on a generated before the
different server than that which created application of Modeler
the ID, the ID is received. 6.0.1 SP1 and Integration
When enabled, correlation IDs are not
broadcast; when disabled, they are
ensures that models
broadcast (through the Broker) to all
created before the
servers in the process.
Note: If a process does not use correlation before service pack
services, this property is not applicable application, unless
and can be ignored. Details about when settings are manually
and how to use correlation services are changed.
provided on “Working with Correlation
Services” on page 152.

The To-Do List

Modeler provides a To-Do List to help you keep track of items, or tasks, that you need to
complete from process model inception until generation. The To-Do List includes both
required and suggested tasks. Required tasks are distinguished by check boxes with a red
dot; these tasks must be completed for the process model to generate successfully. The
check boxes of suggested tasks are empty; these tasks suggest how to make the model as
complete as possible (such as suggesting to create an error-handling step), but they are not
required for the model to generate successfully.
As you complete items on the list, Modeler places check marks in the task check boxes so
that you can keep track of tasks that are completed.
Note: You cannot edit items in the To-Do List in any way; the list is read-only.
Tasks in the To-Do List

The items in the To-Do List consist of process model tasks and step tasks.
Process Model Tasks

The general process model tasks in a To-Do List are:
Add starting step for the process
Choose error handling step
Add a step to the canvas
Step Tasks
After adding steps to the process model, Modeler updates the To-Do List with tasks for
each step. In general, these are:
Assign Server
Subscribe to starting external document
Select inputs
Select outputs
Connect step

The To-Do List
In Modeler, the checklist for a new step looks like the following:
In addition to these general tasks, Modeler can add items to a step’s checklist in response
to the way that the model is designed. For example, Modeler can add the following items:
Set join type (if a join step has been established)
Set expression for complex join (if a complex join step has been established)
Workflow Step Tasks

In addition to all of the items described above, Workflow steps include an additional task:
Set Workflow project name
In Modeler, the checklist for a new Workflow step looks like the following:
Steps Outside of the Scope of the Process

Modeler does not generate a checklist for steps outside of the control of the process (i.e.,
steps within external groups) because you do not need to assign properties to these types
of steps.
Viewing the To-Do List

To view the To-Do List for a process model, use the following procedure.
Viewing the To-Do List
On the process toolbar, click the Show/Hide button. The To-Do List and Properties
windows appear; or
On the menu bar, select ViewTo Do List. The To-Do List appears.

Quick Reference of Basic Actions

The following table describes how to perform basic actions in process model creation.
To... Perform this procedure...

Start a new On the menu bar, select FileNew.
process model
Open an existing On the menu bar, select FileOpen.
process model
Add a step On the process toolbar, click the New Step button and then click on
the canvas to set it down.
Select a step Click the step.
Select multiple Press CTRL and then click each step; or, draw the pointer around
steps multiple steps.
Move a step Click and drag the step.
Delete a step Select the step and then press Delete on the keyboard, the process
toolbar, or the right-click menu.
Create step Position your cursor over a step until an arrow appears; click the
transitions arrow and drag it to the target step.
Move a transition Click the transition to select it, then drag the green handles.
Undo an action On the main toolbar, select Undo.
to the process
model
Redo an action to On the main toolbar, select Redo.
the process
model
Save a process On the menu bar, select FileSave.
model

Saving a Process Model as a JPEG
Saving a Process Model as a JPEG

You can save the picture of the process model (in JPEG format) using the following
procedure.
To Save a Process Model as a JPEG
1 On the menu bar, choose FileSave as JPEG.

2 Choose the name and location for the JPEG.
3 Click Save.


WEBMETHODS MODELER
CHAPTER 5
Adding Steps to a Process Model
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Flow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Workflow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Web Service Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Empty Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Terminate Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Step Functions and Step Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Working with Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Guidelines on Using Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Controlling the Visual Properties of Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

CHAPTER 5 Adding Steps to a Process Model
Overview
Steps are the basic unit of work in a business process. A step can represent an automated
process performed on an Integration Server (e.g., executing a service), a manual step
performed by a person (via webMethods Workflow), or a visual aid that identifies a task
that an external organization performs (steps in external groups). Steps can also depict an
action to take when an error or timeout occurs in the process.
While creating a process model, you do several things to steps.
Step Action... Description...

Add steps to the You add a step to a process model by placing its icon onto the
model. canvas. Steps that perform specific functions or are assigned in a
special way are described in “Step Functions and Step Types” on
page 85.
Assign You must assign step properties to all steps within the control of
properties to the business process (i.e., all steps not within external groups). For
steps. details, see “Flow Step Properties” on page 67.
Assign inputs Inputs and outputs specify the information that should flow from
and outputs to one step to the next. For details, see Chapter 6, “Assigning Inputs
steps. and Outputs to Steps”.
Add logic to Logic specifies how steps perform their actions, for example,
steps. checking credit. You add flow or java services to flow steps, and
workflows to Workflow steps. You might also need to add
correlation services to steps. For details, see Chapter 7, “Adding
Logic to Steps”
Draw transitions You draw transitions between steps to indicate the order in which
between steps. steps should execute. Use transitions to create splits, branches, and
joins. Specific transition types (e.g., retry, timeout, error, and else)
and transition conditions enable you to create complex process
logic. For details, see Chapter 8, “Creating Step Transitions”.
Place steps into Modeler provides the option to place steps within groups if you
groups. would like a model to depict different organizational boundaries.
Groups can act as informative visual containers, especially for
complex models, but are never required. For details, see Chapter 9,
“Adding Groups to a Process Model”.

Flow Step Properties

As you establish steps, you define their properties. These are defined in the table below.
Note: You do not need to assign properties to steps within external groups.

Label The name of the step. “Flow Step”. To change
this, type a new name
Note: The step name should be unique. under the step or in the
box next to the Label
property.
Description Step description, e.g., “This step sends a Choose Edit to enter a
purchase order to XYZ Corp.”. There is no description.
limit to the length of the description.
Unique ID The internally-generated unique ID that This is a read-only
Modeler assigns to the step. property.
Logical Server The logical server on which Modeler will The server designated as
generate and execute step logic. the Design Server. To
change this, select a
Note: For details on replacing all existing server from the drop-
logical servers in a process, see “Managing down list. Available
Logical Servers and Server Connections” on servers correspond to
page 231. those that have been set
up through
webMethods
Administrator.


Folder The namespace folder to which Modeler Select a pre-existing
will generate step components (e.g., flow folder from the list; or,
services, triggers, etc.). leave this property
blank and Modeler
Upon generation, Modeler places this folder generates a folder
on each physical Integration Server named:
associated with the process. ProcessName/LogicalServe
r Name.
Note: This folder is located under the IS
package corresponding to the process
Package Name property.
Generated Name for the step’s generated flow service. Equivalent to step name.
Flow Name Each step generates a flow service which in You can override this by
turn invokes another service (specifiable via typing a new name in
Service to Invoke) to perform the step’s logic. the box beside Generated
Flow Name.
Service to Flow or java service which the generated If you specify a pre-
Invoke flow service will invoke to perform the existing Service to Invoke,
step’s logic. Specifying a service to invoke at Modeler generates a
this time is optional; alternately, you can flow service with an
specify this after generating the model. INVOKE flow operation
to invoke the specified
Important! Chapter 7, “Adding Logic to service.
Steps”, provides important guidelines for If you do not specify the
creating the services that steps invoke. Service to Invoke
property, Modeler does
nothing and you must
create this service
manually.
Correlation Correlation service for the step. You assign To select a service, click
Service these services to connect IS documents with the arrow and browse to
the process instance; these services are the service.
sometimes required in addition to services
that perform step logic.
Important! In many cases, though not all, it

will be necessary to assign correlation
services to steps. For criteria, see“Working
with Correlation Services” on page 152.


Transitions The list of transitions (and transition-related Transition properties
properties) associated with the step. A and their defaults are
transition can be one of five types: Normal, described on “Transition
Error, Timeout, Retries Exceeded, and Else. Properties” on page 162.
Note: For details, see “Overview of

Transitions” on page 160.
Retry Count The number of times to execute the step if To change the default,
the step fails. type another number in
the box next to Retry
Note: When you assign a Retry Count to a Count.
step, you must also create a Retries
Exceeded transition to another step, as
described in Chapter 8, “Creating Step
Transitions”.
Join Type Join type associated with the step. You need To choose a join type,
to assign join types to steps that have select one from the
multiple subscriptions or multiple input drop-down list.
transitions; this tells the step under what
conditions to continue processing.
Possible join types are: AND, OR, XOR,
COMPLEX and XPath. For details, see “Join
Steps” on page 88.
Note: When a step is an AND join step (or a

COMPLEX join step containing AND logic),
you must also assign a Timeout Value for
the step using the Timeout Value property
described below.


Join Timeout Timeout value for steps that are AND joins None. To define a
(or COMPLEX joins containing AND logic). Timeout Value, click
You do not need to specify this property for Edit, choose the Timeout
any other type of join step. Type, then enter either a
time in milliseconds or
Relative: The Timeout Value is the time (in an XPath condition.
ms) by which the join conditions must be
met before the timeout transition from the
join step will be taken. The timer begins
counting once the first join condition is met
(e.g., the first input arrives). This relative
timeout can be set for a number of
milliseconds or based on an XPath
condition.
Absolute: You can also set an absolute
timeout for a join condition that will cause
the process to continue until a set date and
time, or based on an XPath condition.
Note: When you assign a Timeout Value to a

step, you must also create a Timeout
transition to another step, as described in
Chapter 8, “Creating Step Transitions”.
Step Timeout Timeout value for steps that are not based None. To define a
on a condition. Timeout Value, click
Edit, choose the Timeout
Relative: The Timeout Value is the time (in
Type, then enter either a
ms) during which step execution will occur
time in milliseconds or
before the timeout action will be taken. The
an XPath condition.
timer begins counting once the step
execution begins. This relative timeout can
be set for a number of milliseconds or based
on an XPath condition.
timeout for a step that will cause the step to
execute until a set date and time, or based


Publish/ The publish/subscribe filter associated with To assign a
Subscribe the step. Filters enable you to specify publish/subscribe filter,
Filter conditions that the subscription or choose Edit. Details are
publication document must meet in order to provided in “Using the
be used by the step, e.g., subscribe to this Publish/Subscribe
document only when Field X has a value Filter” on page 139.
less than 10.
Note: For details, see “Using the

Publish/Subscribe Filter” on page 139.
Inputs/ The inputs and outputs (such as IS To assign inputs and

Outputs documents, external documents, etc.) outputs to steps, click
associated with the step. This is the Edit.
information that a step receives (input) and
produces (output).
Note: For details on assigning inputs and

outputs, see Chapter 6, “Assigning Inputs
and Outputs to Steps”.
Logged Fields Fields of the input/output documents that To choose document

you want to log to the Process Audit Log so fields, click Edit.
that you can view the fields in the Monitor.
Note: For details, see “Choosing Fields to

Log For Monitoring” on page 138.
Enable Whether to log this step’s pipeline to the This property is

Resubmission Process Audit Log. If enabled, PRT logs the available only when the
step pipeline. If disabled, PRT does not log process model Logging
the step pipeline. Level property is
“Process and All Steps”.
Only steps whose pipelines were logged can
When this property is
be viewed in detail or resubmitted via
available, it is enabled
webMethods Monitor.
out-of-the-box;
however, the default
state of this property is
controlled through
ToolsOptionsSteps
Enable Resubmission.

Important! Modeler displays additional properties for referenced process steps only. For
details, see “Referenced Process Step Properties” on page 273.
Workflow Step Properties

After adding a Workflow step, define its properties. These are described in the table
below.

Label The name of the Workflow step. “Workflow Step”. To
change this, type a new
Note: Assign steps a unique name. name under the step or
in the box next to the
Workflow step Label
property.
Description Workflow step description, e.g., “Approve Choose Edit to enter a
purchase order”. There is no limit to the description.
length of the description.
Logical Server The logical server on which the Workflow To select a server,
step’s components (i.e., implementation choose one from the
modules, projects, workflows) should drop-down list. This
generate and execute. logical server should
correspond to the
Important! For Workflow steps only, physical Workflow
Modeler generates logic to two servers: the server. Available
server defined here, and an Associated servers correspond to
Server. Read “Workflow Step Generation those that have been
and Multiple Servers” on page 206 for set up through
details. webMethods
Administrator.


Project The Workflow project associated with the Select or type the name
Workflow step. This project will contain an of a pre-existing project;
implementation module, which will in turn or, type a name for a
contain a workflow. project which does not
yet exist and Modeler
will generate it.
Version The Workflow project version. If you entered a pre-
existing project in the
Project property,
Modeler loads all
project versions that
exist for that project so
that you can select the
appropriate version.
If Modeler generated a
new project, it is
automatically assigned
a version of 1.0.
Implementation The implementation module associated Type a name for the
Module with the Workflow step. implementation
module which
Modeler will generate.
Note: If you leave this

property blank,
Modeler generates an
implementation
module named:
StepName_IM.
Workflow to The workflow associated with the Select or type the name
Invoke Workflow step. of a pre-existing
workflow; or, type a
name for a workflow
which does not yet
exist and Modeler will
generate an empty one.


Correlation Correlation service for the step. You assign To select a service, click
Service these services to connect IS documents the arrow and browse
with the process instance; these services to the service.
are sometimes required in addition to
services that perform step logic.

Transitions The list of transitions (and transition- Transition properties

related properties) associated with the and their defaults are
step. A transition can be one of five types: described on
Normal, Error, Timeout, Retries Exceeded, “Transition Properties”
and Else. on page 162.

Retry Count The number of times to execute the step if To change the default,
the step fails. type another number
in the box next to Retry
Note: When you assign a Retry Count to a Count.
Transitions”.


Join Type Join type associated with the step. You To choose a join type,
need to assign join types to steps that have select one from the
and COMPLEX. For details, see “Join
Steps” on page 88.

COMPLEX join step containing AND
logic), you must also assign a Timeout
Value for the step using the Timeout Value
property described below.
(or COMPLEX joins containing AND Timeout Value, click
logic). You do not need to specify this Edit, choose the
property for any other type of join step. Timeout Type, then
enter either a time in
milliseconds or an
XPath condition.
counting once the first join condition is met
(e.g., the first input arrives). This relative
condition.
Note: When you assign a Timeout Value to

a step, you must also create a Timeout


Edit, choose the
Relative: The Timeout Value is the time (in Timeout Type, then
ms) during which step execution will occur enter either a time in
before the timeout action will be taken. The milliseconds or an
timer begins counting once the step XPath condition.
execution begins. This relative timeout can
be set for a number of milliseconds or
based on an XPath condition.
timeout for a step that will cause the step to
execute until a set date and time, or based
Publish/ The publish/subscribe filter associated To assign a
Subscribe Filter with the step. Filters enable you to specify publish/subscribe
conditions that the subscription or filter, choose Edit. Then
publication document must meet in order choose Inputs or
to be used by the step, e.g., subscribe to this Outputs, and then
document only when Field X has a value choose the document
less than 10. on which you will base
the filter.
Note: For details, see “Using the
Publish/Subscribe Filter” on page 139.
Inputs/ The inputs and outputs (such as IS To assign inputs and

Outputs documents, external documents, etc.) outputs to steps, click
associated with the step. This is the Edit.
information that a step receives (input) and
produces (output).
Note: For details on assigning inputs and

outputs, see Chapter 6, “Assigning Inputs
and Outputs to Steps”.

Web Service Step Properties

Logged Fields Fields of the input/output documents that To choose document
you want to log to the Process Audit Log fields, click Edit.
so that you can view the fields in the
Monitor.
Note: For details, see “Choosing Fields to

Log For Monitoring” on page 138.

Resubmission Process Audit Log. If enabled, PRT logs the available only when
step pipeline. If disabled, PRT does not log the process model
the step pipeline. Logging Level property
is “Process and All
Only steps whose pipelines were logged Steps”. When this
can be viewed in detail or resubmitted via property is available, it
webMethods Monitor. is enabled out-of-the-
box; however, the
default state of this
property is controlled
through
ToolsOptionsSteps

After adding a Web Service step, define its properties. These are described in the table
below.

Label The name of the Web Service step. “Web Service Step”.
To change this, type a
Note: Assign steps a unique name. new name under the
step or in the box next
to the Web Service
step Label property.


Description Web Service step description, e.g., “Web Choose Edit to enter a
Service Step”. There is no limit to the description.
length of the description.
Logical Server The logical server on which the Web Default is Design
Service step’s components should generate Server. To select a
and execute. server, choose one
from the drop-down
list. Available servers
correspond to those
that have been set up
through webMethods
Administrator.
Web Service The Web Service configuration associated Click Edit to display
Configuration with the Web Service step. the Web Service
Configuration dialog.
Interaction Name The name for the Web Service interaction. The Web Service
interaction name is
set in the Web Service
Operation The Web Service operation associated with The Web Service
the step. operation is set in the
Web Service
Correlation Correlation service for the step. You assign To select a service,
Service these services to connect IS documents click the arrow and
with the process instance; these services browse to the service.
are sometimes required in addition to
services that perform step logic.



Normal, Error, Timeout, Retries Exceeded, “Transition
and Else. Properties” on
page 162.
Retry Count The number of times to execute the step if To change the
the step fails. default, type another
number in the box
Note: When you assign a Retry Count to a next to Retry Count.
Transitions”.
COMPLEX and XPath. For details, see
“Join Steps” on page 88.



Relative: The Timeout Value is the time (in milliseconds or an
ms) by which the join conditions must be XPath condition.
counting once the first join condition is
met (e.g., the first input arrives). This
relative timeout can be set for a number of
condition.

Edit, choose the
Timeout Type, then
ms) during which step execution will
occur before the timeout action will be
milliseconds or an
taken. The timer begins counting once the
XPath condition.
step execution begins. This relative
condition.
timeout for a step that will cause the step
to execute until a set date and time, or
based on an XPath condition.


Resubmission Process Audit Log. If enabled, PRT logs the available only when
step pipeline. If disabled, PRT does not log the process model
the step pipeline. Logging Level property
is “Process and All
Only steps whose pipelines were logged Steps”. When this
can be viewed in detail or resubmitted via property is available,
webMethods Monitor. it is enabled out-of-
the-box; however, the
default state of this
property is controlled
through
ToolsOptionsSteps

Empty Step Properties

The Empty step invokes no execution logic. It is provided for use where join and split
transition logic needs to be defined in the process but no step execution logic is required.
After adding an Empty step, define its properties. These are described in the table below.

Label The name of the Empty step. “Empty Step”. To
change this, type a
step or in the box
next to the Empty
Description Empty step description, e.g., “Invoke Choose Edit to enter a
Search”. There is no limit to the length of description.
the description.
Logical Server The logical server on which the Empty Default is Design
step’s components should generate and Server. To select a
execute. server, choose one
from the drop-down
correspond to those
through
webMethods
Administrator.
Normal, Error, Timeout, Retries Exceeded, “Transition
and Else. Properties” on
page 162.

Empty Step Properties


milliseconds or an
XPath condition.
counting once the first join condition is
met (e.g., the first input arrives). This
relative timeout can be set for a number of
condition.


Terminate Step Properties

The Terminate step is used to manually end a process. When a Terminate step is reached
the process is cancelled, causing the same effect as if the process were cancelled manually
from webMethods Monitor: Any steps currently running will complete, but no new
transitions will be taken, effectively terminating the process. It is not necessary or
recommended to use a Terminate step at the natural end of a process. After adding a
Terminate step, define its properties. These are described in the table below.

Label The name of the Terminate step. “Terminate Step”. To
change this, type a
step or in the box
next to the Terminate
Description Terminate step description, e.g., “End of Choose Edit to enter a
Process”. There is no limit to the length of description.
the description.
Logical Server The logical server on which the Terminate Default is Design
step’s components should generate and Server. To select a
execute. server, choose one
from the drop-down
correspond to those
through webMethods
Administrator.

Step Functions and Step Types

Join Type Join type associated with the step. The To choose a join type,
Terminate step will execute when process select one from the
control is passed to it from any incoming drop-down list.
transition and the join condition is
satisfied.


You add steps to a process model by placing icons onto the canvas. Modeler’s main three
step types are Flow steps, Workflow steps, and Web Service steps. Beyond this, some
steps can be thought of as being a specific step type due to their special function in a
process (e.g., steps that start or end a process, join multiple threads of logic, or perform
error handling); you might also think of steps that you establish in a unusual way as being
a distinct step type (e.g., subprocess and referenced process steps). Steps that represent
special functions in a process, or that you establish in an unusual way, are described in the
following sections.
Start Steps
You establish a start step for a process by virtue of its transitions (it has outgoing but no
incoming transitions) and by virtue of its subscription document. A start step must
subscribe to at least one document. The arrival of this document is the trigger that tells the
PRT to begin running the process. For details on subscribing to a document, see
“Assigning and Editing Step Inputs” on page 109.
Note: Typically, you will want to establish only one start step per process model, but
Modeler places no limits on the number of allowable start steps.
Important! Use caution with steps that are OR joins because OR join steps that subscribe to
a document can start a new process instance (at the OR join step) at run time. See the
following process model for illustration.

Example of an OR join step as a possible start step
In the above model, if the subscription document for Step 3 arrives before Step 2 executes,
the PRT kicks off a new instance of the process starting at Step 3. There is no way to
prevent this from occurring, so consider whether using an AND join would work just as
well or better. For details on join steps, see “Join Steps” on page 88.
End Steps
As the name implies, the end step is the step that you intend to be the last step in the
model to run. End steps should have input transitions but no output transitions. (End
steps can, however, publish documents.) However, in reality, many steps might be the
last step in the model to run. For example, if timeouts and errors occur, steps that follow
timeout and error transitions become the last step to run. Or, a process-wide error step
might be the last step to run. In the following process model, the Send Confirmation step
is the target end step, while the Send Error step might actually become the end step in the
event that the error transitions are taken.

Process-Wide Error Steps

You can designate a process-wide error step to each model for general error handling. At
run time, this is the step that the PRT invokes when a step that is not associated with its
own error step encounters an error. (Steps can be assigned designated error steps through
error transitions, described on “Creating Step Transitions” on page 161.) Unlike other
steps in the process model, the process-wide error step should not be connected by
transitions to other steps, nor should they contain input data or subscriptions.
To Establish a Process-Wide Error Step
1 Within a process model, access process model properties.

2 From the Error Step property pull-down, select a standalone step to be the process-
wide error step. See the process-wide error step in the following model.
Model Containing a Process-Wide Error Step

Join Steps
Join steps are steps that act as a kind of hub by receiving multiple subscriptions or input
transitions and then specifying the conditions by which the step should execute.
Specifically, you need to assign a join type to any step that:
Has multiple subscriptions (including start steps)
Has both an input transition and a subscription
Has multiple input transitions
Example of the 3 types of join steps
When you create a join, you must specify a join type for the step that is receiving the join
(i.e., the join step). You assign a join type using Step Properties.

Join Types
The possible join types are:
AND. The AND join tells the PRT to execute the join step only when it receives all
subscriptions (or subscriptions and input transitions). You must assign a Timeout
Value to each AND join step using the step’s Timeout Value property. The Timeout
Value is the time (in ms) that the join step should wait for all inputs once the first
input arrives. If the time elapses before all inputs arrive, a step timeout error is issued
and the step’s timeout step is invoked (if it has been assigned). The timeout step is the
step following a timeout transition.
OR. The OR join tells the PRT to execute the join step when any of the step
subscriptions or input transitions are received. If multiple inputs are received
simultaneously, the step executes for each input received.
XOR. The XOR join tells the PRT to execute the step when only one of the subscriptions
or input transitions is received at any given time. If more than one is received
simultaneously, the step does not execute.
XPath. The XPath join provides the capability to define join conditions in the XPath
expression language.
Complex. The Complex join tells the PRT to execute the step when the conditions that
you have specified in the Complex Join Editor are met. You use the Complex Join
Editor to build complex join conditions that can include a combination of AND, OR,
and XOR joins.
For important guidelines on implementing joins, see “Splitting, Branching, and Joining
Logic in a Process” on page 163.
Referenced Process Steps

Steps that invoke an entirely separate business process are known as referenced process
steps. For important details on creating process models that contain referenced processes,
see Appendix B, “Guidelines for Working with Referenced Processes”.
To Establish a Referenced Process Step
1 While working in a business process, select Insert from the process toolbar.
2 From the Insert window, choose a process and click Insert and Close.
3 Place the step onto the canvas and name it.
As shown in the sample model below, referenced process step icons (see the “PO process”
step) are distinct from the icons of other steps.

Example of a referenced process step
To Edit a Referenced Process Step
1 Open the referenced process using one of the following methods.

a Open the process independently, using Modeler’s File Open command. For
example, if process model A and B reference process model C, you can open and
update C independently.
b Open the process from within a process that it resides by double-clicking on the
referenced process step. For example, if process model A and B reference process
model C, you can open and update C by clicking on the referenced process step
referring to C in models A or B.
2 Edit the process. When you edit a referenced process, the changes are automatically
reflected in all processes that reference it. In this case, all changes take effect in process
models A, B, and C.
Subprocess Steps
You can collapse several steps into a single icon to make a complex model visually
cleaner. Unlike referenced process steps, subprocess steps simply provide a single visual
container for steps within the same process model, rather than pointing to an entirely
separate business process. The subprocess does not affect the way steps execute.You can
easily descend into a subprocess to view its steps.
To Establish a Subprocess Step
1 Open a process model. Let’s use the following model as an example.
2 Use CTRL to select a grouping of steps to be collapsed; or, drag the pointer around
steps to select them. (Let’s collapse Step 2 and Step 3.)

3 Right-click and select Collapse to subprocess. The single subprocess icon appears in
place of the collapsed steps.
Accessing and Editing a Subprocess
You can easily descend into subprocess steps for viewing or editing.
To Access and Edit a Subprocess
1 Double-click the subprocess step; or, select it and click the Zoom into icon from the
process toolbar. The collapsed steps appear, along with arrows depicting which step
precedes and follows the subprocess, as shown below.
Note: If you create a subprocess out of steps not yet linked by transitions, the
subprocess will not contain the “from” and “to” arrows depicted above because
Modeler does not know which steps precede and follow the subprocess. You must
establish the steps that precede and follow the subprocess at some point before
generation. When you do, ensure that the subprocess contains the “from” and “to”
arrows depicted above, and that the arrows are connected to the correct steps.
2 To exit the subprocess and return to the main canvas, select the Zoom out icon from the
process toolbar.
Restoring a Subprocess to the Main Canvas

If want to restore subprocess steps back to the main canvas, use the following procedure.
To Restore a Subprocess to the Main Canvas
From within a process model, select the subprocess icon, right-click, and select Extract
steps from subprocess.

Working with Web Service Steps

Modeler provides a web service step to allow your processes to connect to web services.
The web service step, once added to the canvas, can be configured to function in one of
three ways:
Invoke: The web service invoke step allows a business process to invoke a one-way or
request-response operation on a WSDL portType (or endpoint) offered by a partner or
web service provider.
Receive: The web service receive step allows a business process to perform a blocking wait
for a matching web service message to arrive. The receive step acts as a listener for a web
service request from an external party.
Reply: The web service reply step allows a business process to send a message in reply to a
message received through a prior web service receive step. The combination of a web
service receive and reply forms a request-response operation on the WSDL portType for
the process, exposing the activities it covers as a web service.
The following sections provide instructions for working with web service steps.
Defining Web Service Interactions

Before a web service step can be configured, a web service interaction must be defined to
represent the relationship between you and the external partner with whom you will be
communicating using web services. The web service interaction is the object by which the
process keeps track of web service interactions with external parties. In the case of web
service invoke, the web service interaction will have binding information associated with
it, and in the case of web service receive and reply, the web service interaction will be
used as the channel by which a reply step is associated with preceding receive step.
The web service interaction is also used to identify the web service port types that are
used by you and your partner for the interaction. A partner in this sense is just an entity
external to your process. It could be another business or just another one of your own
processes or web services.
Note: For those readers familiar with BPEL, a web service interaction is Modeler's version
of a BPEL Partner Link.
A web service interaction is defined by a name and two web service port types: My Port
Type and My Partner's Port Type. You will need a new web service interaction for every
different instance of web service communication between your process and an external
partner. Multiple calls to the same web service of a partner, including different operations
on the same port type, are the exception to this rule, and in that case one web service
interaction is required.
The name of your web service interaction must be unique within your process, and it
must be NCName compliant. To be NCName compliant, the name must start with a letter

or an underscore and may contain no spaces. For full details on NCName compliance see:
<http://www.w3.org/TR/xmlschema-2/#NCName>
The port types you define in your web service interaction will depend on the type of
interaction you are trying to model:
If you are invoking a web service of a partner, then you will need to choose the port
type for that web service as My Partner's Port Type when configuring the web service
interaction. You should import the port type definition from a WSDL file. See
“Defining Web Service Port Types” on page 95.
If your process is invoked using a web service call from an external entity, you will
need to create a new port type for the My Process' Port Type half of the web service
interaction. In creating a new port type for your process you will define the
operations and their inputs and outputs. See “Defining Web Service Port Types” on
page 95.
If you have a series of calls and responses between the web service of your partner
and your process, you may define both My Partner's Port Type and My Port Type in a
single web service interaction.
Follow these steps to define web service interactions in Modeler.
To Define a Web service interaction
1 Choose FileNew to open a new process model.

2 Set the process model properties. For descriptions of process model properties, see
Chapter 4, “Process Model Properties”.
3 Choose ViewWeb Service Interactions to display the Web Service Interactions dialog.

4 Click Add. A new web service interaction field is displayed.
5 Type the name of the web service interaction in the Interaction Name field.
6 Define port type information for My Partner’s Port Type and/or My Process’s Port
Type.
7 Choose FileSave to enter a name for the process model and save it. The web service
interactions defined in this procedure are now available for use in this process.
Importing Port Types from a WSDL File

Use the Web Service Interactions dialog to import port types from a WSDL file.
To import port types from a WSDL file

2 Click Import Port Type from WSDL. The Select WSDL Import file dialog appears.
3 Navigate to the desired folder, select the WSDL file and click Open to import port
types from the WSDL file.
Defining Web Service Port Types

There are basically two kinds of web service port types to be concerned with in Modeler.
Your partner's port types, and your port types.
In order to call one of your partner's web services from within a process in webMethods,
you must have a WSDL file that describes the web service port types and operations that
you want to invoke. You can import port definitions by selecting the Web Service Ports
button or by opening the process properties dialog and selecting Web Service Ports from
the properties table, and then clicking the Import from WSDL button and selecting the
WSDL file you wish to import. Once you have imported the port types they will be
available for use in defining web service interactions.
In order to answer web service calls directly from your process, you must define your
processes web service port types. Use the button Create New to make up a port type for
your process that can be used in defining web service interactions.

Defining New Process Port Types

Use the Web Service Interactions dialog to define new process port types.
To define new process port types
2 Click Define New Process Port Type. The Define New Port type for My Process dialog
appears.
3 Type a name for the port type in the Port Type Name field.
4 Click Add to define the new port type.
5 Type the Operation Name and define input and output document types to complete
the port type definition.

Adding Web Service Steps

Follow these instructions to add web service steps to your process.
To add a Web service step
1 Click the Web Service step icon in the toolbar.

2 Click the canvas to place the web service step in the process.
3 Type the step name in the highlighted name field.
Defining Web Service Configuration

Use the Web Service Configuration dialog to define the activity for the web service step.
The choices are:
Invoke
Receive
Reply
To Define Web service configuration
1 Right-click on the web service step and choose Web Service Configuration from the
menu. The Web Service Configuration dialog appears.

2 Choose the activity type for the Web Service step.
3 Continue defining the following web service configuration for the step:
Interaction
Port Type
Operation
Input Variable
Output Variable
The following sections outline the steps to configuring Web Service Invoke, Receive, and
Reply steps.
Web Service Invoke

To invoke a web service you use a Web Service Invoke step.
To Define a Web Service Invoke step
1 Select the Add new Web Service step button and place the step on the process model
canvas.
menu.
3 In the Web Service Configuration dialog, click the Invoke button.
4 Select the Web Service Interaction for this step from the Interaction drop down list.
5 Select the web service operation to be invoked from the Operation drop down list.
6 Select the input data for the web service by selecting either an existing pipeline input
or New Global Data from the Input Variable drop down list.
If New Global Data was chosen, enter the global data Instance Name.
7 Select the output variable from the Output Variable drop down list. Choose either
New Global Data or New Pipeline Data and enter the Instance Name for either data
format.

At this point your web service invoke step will be completely configured within the
process model. Next you will have to choose and set up a method for web service binding.
Binding for Web Service Invoke

The web service port type defines the interface for a web service, but it does not define
how your process will locate the service on the Internet. For this you need binding
information. The binding can either be determined by the process runtime by reading
directly from WSDL files in the deployment environment that contain the web service
binding information, or the process itself can set the binding for a particular web service
interaction using information formatted as an endpoint reference. In the case of an
endpoint reference, the process assigns the binding for web service interaction by using
predefined PRT services within a flow step. The endpoint reference can either be hard-
coded into the process, or passed to the process at runtime.
There are three possible methods of binding:
Static binding: The binding information is explicitly declared in the form of an
EndPointReference document and assigned to a web service interaction using the prebuilt
assign services of the PRT. See the webMethods Built-In Services Reference. Note that these
services, in their names, use BPEL terminology and refer to web service interactions as
Partners.
Dynamic binding: The binding information, in the form of an EndPointReference, is
discovered by the process at runtime, perhaps as part of a document being sent in to the
process. This endpoint reference is then assigned to the web service interaction using the
prebuilt assign services of the PRT. See the webMethods Built-In Services Reference. Note
that these services, in their names, use BPEL terminology and refer to web service
interactions as Partners.
Deployment-time binding: The binding information is read from a WSDL file that you must
manually place on the runtime server.
Using Static Binding

For static binding of an endpoint reference to a web service interaction, you will need to
create a flow step which transitions to the web service invoke step.
To use static binding
1 Lock global data, using the pub.prt.globalData:lockGlobalData service, mapping the input
ProcessData fields ProcessInstanceID, ProcessIteration and ProcessStepID to their
counterparts in the service input.
2 Define an EndPointReference document that contains all of the necessary binding
information for the web service you wish to invoke.
3 Assign this Endpoint Reference to the “value” document of the
pub.prt.assign:literalToPartner service.

4 If the web service is running on a webMethods Integration Server, you must also
assign authentication data for the literalToPartner service. If using the default
Integration Server configuration, this can be set to:
type=basic
user=Administrator
password=manage
5 Statically assign the partnerTo value for the literalToPartner service to the name of the
web service interaction of the web service invoke step you wish to bind.
Using Dynamic Binding

For dynamic binding of WSDL to an endpoint reference, you will need to create an assign
step which transitions to the web service invoke step.
To bind the assign step from pipeline data
2 Map an EndPointReference document from your process to the “value” document in
the pub.prt.assign:literalToPartner service.
3 If the web service is running on a webMethods Integration Server, you must also
assign authentication data for the literalToPartner service. If using the default Integration
Server configuration, this can be set to:
type=basic
user=Administrator
password=manage
4 Statically assign the partnerTo value for the literalToPartner service to the name of the
web service interaction of the web service invoke step you wish to bind.
To bind the assign step from global data
2 Statically assign the name of the relevant global data variable containing your
endpoint reference, and optionally from the top-level part name, and the exact value
in nested data, and the partnerTo value for the variableToPartner service.

To copy binding from another web service interaction
2 Statically assign the partnerFrom, roleFrom and partnerTo values, all of which are set
in the process Modeler using the web service interactions definitions.
Using Deployment-time Binding

For deployment-time binding of WSDL to an endpoint reference, one will need to create
an assign step which transitions to the web service invoke step, as with static and dynamic
binding.
To use deployment-time binding
2 Statically assign authentication data using the pub.prt.assign:setPartnerAuthentication
service.
3 Statically assign the partnerTo value for the setPartnerAuthentication service.
The WSDL file will need to be deployed to the process package, at the
<IntegrationServer_Home>/packages/<package-name>/config/wsdl/<logical-
server-name> directory. If deployed at runtime, the WmPRT package will need to be
reloaded in order to deploy the WSDL.
Mapping WSDL Elements to EndPointReference Document Fields

WSDL elements map to EndPointReference document fields as follows:
WSDL Element EndPointReference Field

<soap:address location='address-value'/> address
<portType name='portType-value'/> portType
<soap:body namespace='namespace-value'/> operation.namespaceName

<operation name='operation-value'/> operation.localName
<soap:operation soapAction=’soapAction-value'/> operation.Service.soapAction
<soap:binding style='style-value'/> binding.soapBinding.soapStyle
<soap:binding transport='transport-value'/> binding.soapBinding.soapTransport
Note: For each operation per port type, these mappings are made (a port type can have
multiple operations)

The following is a sample WSDL file, showing the elements to be mapped:
urn_xmethods-delayed-quotes.wsdl
--------------------------------
<?xml version='1.0' encoding='UTF-8'?>
<definitions name='net.xmethods.services.stockquote.StockQuote'
targetNamespace='http://www.themindelectric.com/wsdl/net.xmethods.services.stockquote.StockQuote/'
xmlns:tns='http://www.themindelectric.com/wsdl/net.xmethods.services.stockquote.StockQuote/'
xmlns:electric='http://www.themindelectric.com/'
xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/'
xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
xmlns='http://schemas.xmlsoap.org/wsdl/'>
<message name='getQuoteResponse1'>
<part name='Result' type='xsd:float'/>
</message>
<message name='getQuoteRequest1'>
<part name='symbol' type='xsd:string'/>
</message>
<portType name='net.xmethods.services.stockquote.StockQuotePortType'>
<operation name='getQuote' parameterOrder='symbol'>
<input message='tns:getQuoteRequest1'/>
<output message='tns:getQuoteResponse1'/>
</operation></portType>
<binding name='net.xmethods.services.stockquote.StockQuoteBinding'
type='tns:net.xmethods.services.stockquote.StockQuotePortType'>
<soap:binding style='rpc' transport='http://schemas.xmlsoap.org/soap/http'/>
<operation name='getQuote'>
<soap:operation soapAction='urn:xmethods-delayed-quotes#getQuote'/>
<input>
<soap:body use='encoded' namespace='urn:xmethods-delayed-quotes'
encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'/>
</input>
<output>
<soap:body use='encoded' namespace='urn:xmethods-delayed-quotes'
encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'/>
</output>
</operation>
</binding>
<service name='net.xmethods.services.stockquote.StockQuoteService'>
<documentation>net.xmethods.services.stockquote.StockQuote web service</documentation>
<port name='net.xmethods.services.stockquote.StockQuotePort'
binding='tns:net.xmethods.services.stockquote.StockQuoteBinding'>
<soap:address location='http://66.28.98.121:9090/soap'/>
</port>
</service>
</definitions>

This WSDL can be represented as an EndPointReference document as follows:

EndPointReference document:
--------------------------
address=http://66.28.98.121:9090/soap
portType=net.xmethods.services.stockquote.StockQuotePortType
auth
type=null
user=null
operation
namespaceName=urn:xmethods-delayed-quotes
localName=getQuote
soapAction=urn:xmethods-delayed-quotes#getQuote
binding
soapStyle=rpc
soapTransport=http://schemas.xmlsoap.org/soap/http
Web Service Receive

To perform web service receive in Modeler, you define a web service receive step.
To Define a Web Service Receive step
canvas.
menu.
3 In the Web Service Configuration dialog, click the Receive button.
6 Select the input data for the web service by selecting either an existing pipeline input
format.
At this point your web service receive step will be completely configured within the
process model. Generate the model to create the process package.

Web Service Reply

A Web Service Reply Step is used to send a synchronous response to a preceding Web
Service Receive call. In order to perform web service reply, you must define both a web
service receive step and a web service reply step in the process modeler. The reply will be
associated with the receive only if the same Web Service Interaction is declared for both
steps.
To Define a Web Service Reply step
canvas.
menu.
3 In the Web Service Configuration dialog, click the Reply button.
6 Select the input data for the Web Service by selecting either an existing pipeline input
format.
At this point your web service receive step will be completely configured within the
process model. Generate the model to create the process package.
Guidelines on Using Workflow Steps

Use the following guidelines for working with processes that contain Workflow steps.
When defining multiple Workflow steps in series, consider combining them into one
Workflow step if possible. Because Workflow steps can be viewed by webMethods
Monitor, this combination would avoid unnecessary network traffic and simplify
navigation within the Monitor.
Determine the Workflow steps that form a logical unit of work and generate them into
the same project, so they can be versioned as a whole.
When creating documents that will be used by both the Broker and Workflow, it is
recommended that for simplicity that you create the documents first for the Broker;
then copy them to Workflow.

Controlling the Visual Properties of Steps
Controlling the Visual Properties of Steps

There are two types of visual step properties that you can control:
A step’s icon type
The display of a step’s inputs and outputs
Changing a Step’s Icon Type

Modeler provides many types of icons to help you make process models as visually
intuitive as possible. You can specify a default icon for steps, as well as change step icons
individually.
Note: You cannot change the icon for Workflow steps.
To Change the Icon of a Single Step
1 From within a process model, right-click on a step.

2 Select Change Image. The Choose Image dialog appears.
3 Select an icon and click OK.
Controlling the Display of Step Inputs and Outputs

For steps on how to control the display of step inputs and outputs, see “Controlling the
Display of Inputs and Outputs” on page 137.


WEBMETHODS MODELER
CHAPTER 6
Assigning Inputs and Outputs to Steps
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Assigning and Editing Step Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Assigning and Editing Step Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Publication and External Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Controlling the Display of Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Choosing Fields to Log For Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Using the Publish/Subscribe Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Working with Global Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

CHAPTER 6 Assigning Inputs and Outputs to Steps
Overview
Step inputs and outputs represent the information that should flow from one step to the
next throughout the business process. Another way to think of it is that inputs are the
information that a step needs to complete its work, and outputs are the information that a
step produces as a result of its work. This chapter describes the concepts and steps
involved in working with inputs and outputs for most steps in the process model. For
additional important information on working with referenced process step inputs and
outputs, see Appendix B, “Guidelines for Working with Referenced Processes” of this
guide.
Types of Inputs and Outputs Available to Steps

There are two main types of inputs and outputs that you can assign to steps in the process
model.
Publication/subscription documents. Publication and subscription documents are
documents that your process model is to publish or to which your process is to create
a subscription. These publications and subscriptions allow your process model to
send information to and receive information from applications or entities external to
your process model. The types of documents that you can publish and/or to which
you can subscribe are:
IS documents that are exchanged through the Broker. This type of document
allows communication between the various webMethods components. IS
documents used in the process become part of the process pipeline.
External documents that are exchanged through webMethods Trading Networks.
Examples of these types of documents are purchase orders, confirmations,
acknowledgements, etc. External documents never become part of the process
pipeline.
Note: There is an important functional difference between publishing an external

document and publishing an IS document. For details, see “Publication and External
Documents” on page 136.
Input/output data. In contrast to publications and subscriptions, input and output data is
data that is in the process pipeline. Specifically, input data is data or documents that
Modeler makes available as input to steps because they exist in the process pipeline.
Output data is data or documents that you specify steps should produce, thereby
adding the data to the process pipeline.
Global data. Provides an alternative means to share data across Flow Steps and Web
Service Steps. Global data is accessible from within any Flow Step in a single process
via predefined services, and it can be selected as inputs and outputs to Web Service
Steps. You can also use global data to define data properties and data property
aliases.

Assigning and Editing Step Inputs
How Information Flows through the Business Process

Each process’s start step requires an input subscription document to trigger the process to
start running. This can be any publishable IS document or any external document. As the
process runs, the PRT fills the process pipeline with the data and documents specified as
the step inputs and outputs, with the exception of external document types, which are
never added to the pipeline. The contents of the process pipeline determine the
input/output data is available to steps.
Are Step Inputs/Outputs Required or Optional?

You should explicitly assign inputs and outputs to all steps in a process model, even
though technically they are required only if a process uses an Express Pipeline. (See the
Express Pipeline property in “Process Model Properties” on page 51.) Nevertheless,
webMethods strongly recommends that you explicitly assign inputs and outputs to all
steps in a process model.

The two types of inputs that you can assign to steps are:
Subscription documents, including publishable IS documents or the external document
types processed by Trading Networks (e.g., EDI and XML documents).
Input Data, which is data that is in the pipeline as a result of being used somewhere
upstream in the process. This can be a publishable IS document or other types of data,
such as a String.
Note: When you add inputs (subscriptions and input data) to a step, you are prompted to
provide an instance name. Modeler uses instance names to distinguish between two
identical types of inputs used at different places within a process. For example, if step one
and step four both take in the input type “POString”, the String in step four might be
different than in step one, depending on the processing that has occurred. Modeler uses
the instance name to correlate an input type with the instance that it is used in the process.
Each instance of a document in the process must have a unique instance name.

Subscription Documents
Start steps must subscribe to a document to trigger the business process to start running.
Any other step in the process model can also subscribe to a document. The steps for
adding and editing document subscriptions are described in the following sections.
Adding a Subscription to an External Document

When Trading Networks receives a document identical to a document that a process step
subscribes to, Trading Networks passes the document to the PRT to become part of the
running process. The following procedure describes how to assign an external document
subscription to a step. For important guidelines on working with steps with external
subscriptions, see “Guidelines for Using External Documents in the Process Model” on
page 112.
Note: Ensure the external document exists on the step’s logical server prior to assigning the
subscription.
To Add a Subscription to an External Document
1 Right-click on the step and choose Edit Inputs/Outputs; or, from the step’s Inputs/Outputs
property, select Edit. The Inputs and Outputs dialog appears.
2 Click Add Subscription. The Add Subscription window appears. The window displays
a list of webMethods IS packages and external documents residing on the step’s

logical server. The external documents appear in a separate folder called “Trading
Networks Documents”, as shown below.
3 Browse to the external document to which you want to subscribe and select it.
4 In the Instance Name field, type an instance name for the document. By default,
Modeler populates the Instance Name field with the name of the document type. For
information on instance names, see the note on page 109.
5 Click Add Document. The Set TN Roles window appears.

Note: When you subscribe to an external document, you are prompted to select roles
for the document’s sender and receiver. If the document’s sender/receiver role
corresponds to your role in the process, the sender/receiver value should correspond
to the value defined in the process model’s Focal Role property. You can use roles to
create publish/subscribe filters and transition conditions.
6 In the Sender Role field, type the name of the sender’s role.
7 On the Set TN Roles dialog, click OK. The Inputs and Outputs dialog reappears with
the newly added subscription in the Inputs box.
8 On the Inputs and Outputs dialog, click OK.
Guidelines for Using External Documents in the Process Model

Use the following guidelines when working with external document subscriptions.
If Needed, Enable the Step to Access External Document Contents
If the step subscribing to an external document needs information from the document
to do its work (e.g., to process the document), after generating the model, you must
enable a disabled flow service sequence. The disabled flow service sequence is part of
the model’s generated flow service (described in “How Modeler Generates Flow
Services for Flow steps” on page 148). The sequence is called Retrieving documents;
it contains the logic required to enable the step to retrieve the document from the
Trading Networks system for processing. By default, the sequence is disabled to avoid
undesired processing of large documents.
Note: The Retrieving documents flow service sequence consists of a BRANCH step
for each subscribed external document; the BRANCH step invokes wm.tn.doc:view,
which is a Trading Networks built-in service that retrieves documents from the
Trading Networks database.

Keeping Use of External Document Types Distinct Among Logical Servers

If two or more logical servers map to the same physical server that is running Trading
Networks, the external document types on the physical server are available to all
logical servers. If the logical servers will be remapped to multiple physical servers, for
example if your production environment has separate physical servers, you will need
to ensure that the external documents are distributed to the physical servers and that
the external document types stay identical across all physical servers. As a result, it is
a best practice that you keep the use of document types distinct among logical servers
as you draw a process model.
Subscribing to External Documents on the Start Step
It is strongly recommended that you use each Trading Networks document type as
the start step in only one process model. This recommendation is to make it easier for
you to keep track of what process model handles a Trading Networks document type.
If you choose to make the same Trading Networks document type the input to the
start step of more than one process model, keep in mind that at run time the PRT will
create a process instance using only one of the process models. Use subscription filters
on the start steps to indicate the process model that should get the Trading Networks
document based on fields in the Trading Networks document. For details on using
Modeler’s publish/subscribe filters, see “Using the Publish/Subscribe Filter” on
page 139.

Example of using subscription filters to distinguish the process model to receive a Trading Networks
document
Rather than use separate process models, you can put this type of logic in a single
process model that uses subscription filters or conditions on transitions to split the
processing logic.
Example using subscription filters

Example using conditions on transitions
Note: For details on specifying transition conditions, see “Building Transition Conditions”
on page 163.
Adding a Subscription to a Publishable IS Document

When adding a subscription to a publishable IS document, you can choose a pre-existing
document to subscribe to, or you can tell Modeler to create the document to which you
want to subscribe. If you choose to create a new document, Modeler creates an empty
document which you must edit for completeness in Developer. You must ensure the
document is complete before moving the process model into production.
To Add a Subscription to a Pre-Existing Document

Note: In the example above, the step has already been assigned two types of input
data. Adding input data to a step is described in “Adding Input Data” on page 122.
2 Click Add Subscription. The Add Subscription window appears. The window displays
a list of webMethods IS packages and external documents residing on the step’s
logical server.
3 Browse to the IS document to which you want to subscribe and select it.
4 In the Instance Name field, type an instance name for the document. For information on
instance names, see the note on page 109.

5 Click Add Document. The Inputs and Outputs dialog reappears displaying the newly
added subscription document. In the example below, the document “PO2” was
added.
To Add a Subscription to a New IS Document

2 Click Add Subscription. The Add Subscription window appears.

3 Click New Document Type. The New Document Type window appears.
4 Browse to the IS folder in which you want Modeler to create the new document type.
5 In the Document Type Name field, type a descriptive name for the new document type.
6 In the Instance Name field, type an instance name for the document type and click OK.
By default, Modeler populates the Instance Name field with the name of the document
type. For information on instance names, see the note on page 109.
7 Modeler launches Developer (if it was not already open) to the location of the new
document. If Developer was open, Modeler uses the open instance of Developer to
locate the new document.You can edit the empty document now, or at any time before
deploying the process model.
8 Return to Modeler’s Inputs and Outputs dialog and click OK.

Guidelines on Subscribing to IS Documents

Use the following guidelines when working with IS document subscriptions.
You should only subscribe to any particular IS document type once per process model. After a
step subscribes to an IS document, it is added to the pipeline and it is available as an
input to all steps downstream. Therefore, if a step downstream needs the same
document, assign the document to the step as input data rather than as a subscription.
Subscribing to the same IS document more than once per process model can cause
complications in the flow of execution.
For example, the following shows a process model that contains two steps (Step 1 and
Step 3) that both subscribe to the same IS document (Doc A) as input.
Process model that uses the same IS document more than one time
In the above sample, both Step 1 and Step 3 wait for Doc A. When Doc A arrives, Step 1
executes and continues on to Step 2, which because of the AND join, does not begin
until it also receives the document for which Step 2 is waiting. However, when Doc A
arrives, it is also sent to Step 3. Because there is an OR join between Step 2 and waiting
for the document for Step 3, Step 3 proceeds immediately after it receives Doc A. In this
situation, the document will be processed two times and the flow of execution might
not be what the designer intended.
Rather than subscribe to the same IS document in Step 3 as in Step 1, Step 3 could assign
the document as an input, rather than as a subscription. If you must subscribe to the
same IS document more than once in the same process model, but do not want
multiple steps to process each document, use publish/subscribe filters to limit the
steps that actually process the document.
In the above sample, you could set filters on Step 1 and Step 3 so they only receive Doc A
if a field in Doc A contains specified values. For example, you might set filters for Step 1
and Step 3 to indicate that Step 1 only receives the document when the field FirstTime
within the document is true and Step 3 receives the document when the field FirstTime
within the document is false.

Editing Subscription Documents

You can edit the instance name (or role) of an input subscription document. For
publishable IS document subscriptions only, you can also edit the contents of the
document.
Editing the Instance Name (or Role) of a Subscription Document

You can edit the instance name of any existing input subscription. For external document
subscriptions only, you can also edit the roles that you have assigned to the document.
To Edit the Name (or Role) of a Subscription Document
2 In the Inputs box, select the subscription document whose name you want to change
and click Edit Input. The Edit Input window appears.
3 In the Input Name field, type a new name for the document. (If the document is an
external document, you can also type new names for the Sender Role and Receiver Role.)
Click OK.
Editing the Contents of an Existing Subscription Document

If you need to edit the contents of an existing subscription document, you can open
webMethods Developer and edit the document at any time. Or, from the Modeler Inputs
and Outputs dialog, you can choose the Edit Document Type option. When you do so,
Modeler launches Developer at the selected document location. If Developer was already
open, Modeler uses the open instance of Developer to locate the selected document.

Important! You cannot use Modeler as a gateway to edit external documents; if you need to
edit external documents, you must do so independently.
To Edit the Contents of an Existing Subscription Document
2 From the Inputs box, choose the subscription document that you want to edit and
click Edit Document Type. If Developer was not open, Modeler launches Developer in a
separate window at the location of the selected document. If Developer was open,
Modeler uses the open instance of Developer to locate the selected document.
3 From the Developer menu, choose FileLock. This locks the document so that others
cannot modify the document while you are editing it.
4 Edit the document as needed.
5 Save your changes.
6 From the Developer menu, choose FileUnlock.

Deleting Subscription Documents

Use the following procedure to delete a subscription document.
To Delete an Existing Subscription Document
property, click Edit. The Inputs and Outputs dialog appears.
2 From the Inputs box, choose the subscription document that you want to delete and
click Delete. The document is deleted from the step.
Note: When you delete a subscription document, Modeler deletes the document from the
step and from the pipeline, but not from the server on which it resided.
Input Data
You add input data to a step rather than subscribe to a document when the data the step
needs is in the step pipeline. With the exception of external documents, this amounts to all
data (inputs, outputs, subscriptions, and publications) used upstream in the process. The
steps for adding and editing input data are described below.
Adding Input Data

Use the following procedure to add input data to a step.
To Add Input Data to a Step

Note: In the example above, the step has already been assigned an input in the form of
a publishable IS document subscription named “PO”.
2 Click Add Input. The Add Input window appears displaying the possible inputs for the
step. Possible inputs correspond to all data (excluding external document
subscriptions) used upstream in the process.
3 Select the desired input and click Add. The input data is added to the Inputs box.
4 Repeat steps 2 and 3 until you have added all desired inputs.

Editing Input Data Instance Names

You cannot edit the instance names of existing input data. Since input data corresponds to
information that was used upstream in a process, input data instance names are not meant
to be editable. However, if you change the instance name of output data, and the output
data is used downstream as an input, Modeler changes those downstream input names
accordingly. For example, assume the output of Step 1 is named “PO” and that Step 2
selects “PO” as input. If you change the output name of Step 1 from “PO” to “Doc”,
Modeler automatically changes the Step 2 “PO” input name to “Doc”.
Deleting Input Data

Use the following procedure to delete input data from a step.
To Delete Existing Input Data
2 In the Inputs box, select the input you want to delete and click Delete. The input is
deleted from the step.
Note: When you choose to delete existing input data, Modeler deletes the input data
from the step and from the pipeline, but not from the server on which it resided.
Assigning and Editing Step Outputs

You assign outputs to steps to indicate the data the step should produce. Outputs can be:
Publication documents, including IS documents or external documents. IS documents
are published to the Broker and added to the process pipeline. External documents
are not published anywhere or sent anywhere. For details on the purpose of assigning
external document publications, see “Publication and External Documents” on
page 136.
Output Data, including any IS document that you do not wish to publish to the Broker,
or any other non-document data type, such as a String. Output data is added to the
process pipeline.
Fields, including smaller pieces of data, such as Strings, characters, dates, integers, and
so on. Output fields are added to the process pipeline.

Publishing an IS Document
When adding a publication to an IS document, you can choose a pre-existing document to
publish, or you can tell Modeler to create the document that you want to publish. If you
choose to create a new document, Modeler creates an empty document which you must
edit for completeness in Developer. You must ensure the document is complete before
deploying the process model.
To Add a Publication to a Pre-existing IS Document
2 Click Add Publication. The Add Publication window appears. The window displays a
list of webMethods IS packages and external documents residing on the step’s logical
server.
3 Browse to the IS document that you want to publish and select it.

4 In the Instance Name field, type an instance name for the document and click Add
Document. (For information on instance names, see the note on page 109.) The Inputs
and Outputs dialog reappears displaying the document to be published in the
Outputs box. In the following example, the document is called “ProcessData”.
5 Repeat steps 2 through 4 for all documents that you want to publish.
To Add a Publication to a IS New Document
2 Click Add Publication. The Add Publication window appears. The window displays a
list of webMethods IS packages and external documents residing on the step’s logical
server.
4 Browse to the package and folder in which you want the new publication document
to reside.

5 In the Document Type Name field, type a descriptive name for the document type.
6 In the Instance Name field, type a document instance name and click OK. For
information on instance names, see the note on page 109.
locate the new document. You can edit the empty document now, or at any time
before moving the process model into production.
Editing Publication Documents

You can edit the instance name or contents of a publication document.
To Edit the Instance Name of an Existing Publication Document
2 In the Outputs box, select the publication document whose name you want to change
and click Edit Output. The Edit Output window appears.
3 In the Output Name field, type a new name for the publication document and click OK.

To Edit the Contents of an Existing Publication Document
2 From the Outputs box, choose the publication document that you want to edit and
click Edit Document Type. If Developer was not open, Modeler launches Developer in a
separate window at the location of the selected document. If Developer was open,
Modeler uses the open instance of Developer to locate the selected document.
3 Edit the document as needed.

Deleting Publication Documents

Use the following procedure to delete a subscription document from a step.
To Delete an Existing Publication Document
2 In the Outputs box, select the publication document that you want to delete and then
click Delete. The document is deleted from the step.
Note: When you delete a publication document, Modeler deletes the document from the
step and from the pipeline, but not from the server on which it resided.
Output Data
You add output data rather than publications to a step when you do not need to publish
the output data or document to the Broker. The steps for adding and editing output data
are described in the following sections.
Adding Output Data

When adding output data to a step, you can choose a pre-existing document to output, or
you can tell Modeler to create new (and empty) output document. If you choose to create
a new document, Modeler launches Developer in a separate window at the location that
you have specified for the new document. You must ensure the document is complete
before generating the process model.

To Add Pre-existing Output Data to a Step
2 Click Add Output. The Add Output window appears. The window displays a list of
webMethods IS packages and external documents residing on the step’s logical server.
3 Browse to the data or document that you want the step to output and select it.
4 In the Instance Name field, type an instance name and then click Add Document. The
Inputs and Outputs dialog reappears with the newly added data. In the following
example, the newly added output is named “Credit Results”.

To Add New Output Data to a Step
2 Click Add Output. The Add Output window appears.

4 Browse to the package and folder in which you want Modeler to generate the data or
document.

5 In the Document Type Name field, type a descriptive name for the document.
6 In the Instance Name field, type an instance name and then click OK.
locate the new document. you can edit the empty document now, or at any time
before deploying the process model.
Editing Output Data

When you change an output’s instance name, all downstream inputs that reference that
output will also be modified accordingly. For example, assume the output of Step 1 is
named “PO” and that Step 2 selects “PO” as input. If you change the output name of Step
1 from “PO” to “Doc”, Modeler automatically changes the Step 2 “PO” input name to
“Doc”. To change the instance names for existing output documents, use the procedure
below.
To Edit Existing Output Data Instance Names
property, select Edit. The Inputs and Outputs dialog appears
2 In the Outputs box, select the document whose instance name you want to change
3 In the Output Name field, type a new instance name and click OK.

Deleting Output Data

Use the following procedure to delete output data from a step.
To Delete Output Data
2 In the Outputs box, select the document you want to delete and click Delete. The
output is deleted from the step.
Note: When you delete an existing output document, Modeler deletes the document
from the step and from the pipeline, but not from the server on which it resided.
Fields
You can add small pieces of output data (i.e., fields) to a step, such as Strings, String tables,
Booleans, integers, dates, objects, and so on. The steps for adding and editing output
fields are described in the following sections.
Adding Fields
Use the following procedure to add output fields to a step.
To Add an Output Field to a Step

2 Click Add Field. The New Field window appears.
3 In the Field Name box, type an instance name for the field. For information on instance
names, see the note on page 109.
4 In the Field Type list, select the type of data that the step should output.
5 If you want the output data to be a List, check the List box.
Note: The only field type for which the List option is disabled is the String table type.
By definition, the String table type arranges data in lists, therefore, it is not necessary
to specify List for this data type.
6 On the New Field dialog, click OK.

7 Repeat steps 2 through 6 until all output fields have been added.
8 The Inputs and Outputs dialog reappears displaying the newly added output fields.
In the following example, the “Date” and “PO Number” output fields were added.

Editing Fields
If you want to change the instance names for existing output data fields, use the
procedure below.
To Edit the Instance Names of Existing Output Data Fields
2 In the Outputs box, select the output field whose instance name you want to change
3 In the Output Name field, type a new instance name and click OK.

Deleting Fields
Use the following procedure to delete fields from a step.
To Delete Existing Output Data Fields
2 In the Outputs box, select the output field that you want to delete and click Delete. The
output field is deleted from the step.
Note: When you delete existing output fields, Modeler deletes the fields from the step
and from the pipeline, but not from the server on which the fields resided.
Publication and External Documents

You can use Modeler’s inputs/outputs dialog to assign external document publications to
steps. However, keep in mind that this action does not cause the document to be sent or
published anywhere. Rather, you assign external document publications to a step to
enable the PRT to:
Use the conversation ID of the document to establish a correlation with the process
instance ID.
Use attributes of the document for use in downstream transitioning.
Use the sender/receiver role values in publish/subscribe filters and/or transition

conditions.
Having a Step Send an External Document

To have a step send an external document to somebody (e.g., a trading partner or Trading
Networks), you create the document and the send logic within the user-defined service
that a step invokes to perform its logic. This is the only way to have Modeler send an
external document to another party. For details on assigning logic to steps, see Chapter 7,
“Adding Logic to Steps”.

Controlling the Display of Inputs and Outputs
Controlling the Display of Inputs and Outputs

You can control the display of a process model’s inputs and outputs so that they display
in one of the following ways:
You can display the full names of inputs and outputs, where each input or output displays
with instance_name (document type_name). To do so, to go Tools Options and enable
Show Data Types. Then, enable Show Inputs/Outputs at the bottom of the Process window.
the following process model has full inputs and outputs on display.
Note: Subscription documents and publication document names appear with a dotted
border while all other inputs and output names appear with a solid border.
You can view only the instance names of inputs and outputs. To do so, to go Tools Options
and disable Show Data Types. Then, enable Show Inputs/Outputs at the bottom of the
Process window.
Note: You must exit and re-open the process model for the change to take effect.

See the following process model.
You can turn off the display of inputs and outputs completely. To do so, to go Tools Options
and disable Show Data Types. Then, disable Show Inputs/Outputs at the bottom of the
Process window.
Choosing Fields to Log For Monitoring

After you have generated the process and the process is running, you use webMethods
Monitor to view information about the process. If while monitoring the process you
would like to view specific information about a document’s fields, you must (at design
time) specify to log the fields of the document to the Process Audit Log. Use Modeler’s
Choose logged fields option to specify to log document fields, as described below.
Note: If you do not choose to log document fields to the Process Audit Log, when viewing
the process through Monitor, you will not be able to view any detailed information about
the document. Modeler makes document field logging available in conjunction with
specific process Logging Levels. For details, see “Logging Level Effect on Document Field
Logging” on page 261.

Using the Publish/Subscribe Filter
To Choose Fields to Log to the Process Audit Log
1 Right-click the step and select Choose logged fields; or, from the step’s Logged Fields
property, select Edit. The Choose Logged Fields window appears displaying all inputs
and outputs.
2 Browse the inputs and outputs for the fields that you want to log, and check the Log
box next to the fields that you want to log.
3 Click OK.

When step inputs and outputs are in the form of subscription or publication documents,
you can define publish/subscribe filters to restrict the documents that a step subscribes to or
publishes.
You define filters by specifying conditions that a document must meet to be used by the
step. For example, you might have a step that requires a cXML purchase order. However,
you only want the step to use the document if the total purchase amount (field TotalAmount
within the document) is greater than $10,000. In this case, you would set a filter indicating
that you only want the step to use the document if the field TotalAmount is greater than
10,000.

For publication and subscription documents that are external documents, you can also set
filters based on the roles that you assigned to the document.
To use the publish/subscribe filter, follow the steps below.
To Use the Publish/Subscribe Filter
1 Right-click the step and select Publish/Subscribe Filter; or, from the step’s
Publish/Subscribe Filter property, select Edit.
2 Choose either Inputs or Outputs according to the type of filter that you want to set up. A
menu of existing publications and subscriptions appears.
3 Choose the specific publication or subscription document on which you want to set
conditions. The Edit Conditions window appears.
4 Click Add to add a condition to the step.

5 Set up conditions by filling out the Field Name, Operator, Comparison Value/Field, AND/OR,
and Description fields. Use “Building Publish/Subscribe Conditions” on page 142 as a
guideline.
6 After setting up all conditions, click OK.

Building Publish/Subscribe Conditions

The following table provides descriptions of the fields that you can use to build
publish/subscribes conditions.
For this Field... Specify...

Field Name You can create publish/subscribe conditions using the following
information:
Data: If you chose to set a filter on a subscription document,
this folder contains the subscription document (and its
associated fields) that you selected. If you chose to set a filter
on a publication document, this folder contains the publication
document that you selected as well as the step’s subscription
documents. Select the field containing the information on
which you want to base the condition. For example, to build a
condition based on information in a document’s TotalAmount
field, select the TotalAmount field from the appropriate
document.
TN Participant: If the step’s publication or subscription
document is an external document, this folder contains these
documents, named according to the sender/receiver roles that
you assigned when adding the document to the step. If the
document is not an external document, this folder is empty.
Under the external document, the following information
appears. Select the type of information on which you want to
base the condition.
Profile Name: Possible values include user-defined profile
names defined on the Trading Networks system.
Extended Field Names: The specific names of the extended
fields used by the document’s sender or receiver. If the
sender or receiver did not use extended fields, no
extended fields appear.

Working with Global Data

Operator Specify the operator to use for the condition. The operators
available for the condition depend on the data type of the field
selected under Field Name. Data types such as byte arrays, objects,
lists, and tables will have only the operators exists and does not
exist. Other data types such as numeric fields will have the exists
and does not exist operators as well as comparison operators, such
as = (equals), != (does not equal), > (greater than), < (less than), >=
(greater than or equal to), <= (less than or equal to). String fields will
have all of the preceding operators as well as starts with, ends with,
contains, does not start with, does not end with, does not contain, exists,
and does not exist.
Comparison To complete the publish/subscribe condition, you can either enter
Value/Field a comparison value or select a field in a document from which you
want to compare values; you are comparing values or fields with
the value of the Field Name field. The value that you enter here must
be the of the same data type (e.g., String, integer, boolean, etc.) as
the data type of the Field Name selection. For example, if you
selected “PO Number” under Field Name, and the field was of the
data type “String”, you would enter or select a value consistent
with a String, such as “PO123”.
Note: If the field selected under Field Name is a byte array, list,
object, or table, you cannot enter values/fields here; rather, you
must select them.
AND/OR Use the AND/OR field to link multiple conditions using either the
AND or OR operator. To enable the AND/OR operator after
creating a condition, choose Add from the top of the dialog.
Description A detailed description of the condition. Optional.

Global data is available for use with BPEL processes or as inputs or outputs to web service
steps. Global data may be used in the following cases:
When designing a process to be exported to BPEL that should use Assign
activities to manipulate BPEL variables.
To provide parallel threads of execution in your process to operate on the same
set of data.

How Global Data Works

Global Data is managed at runtime by the process runtime environment, and is either
stored locally in the Integration Server, or written out to a database which is sharable
among Integration Servers, depending on the Volatile Global Data setting of the process
model. If Volatile Global Data is set to 'on', the data is local to each Integration Server. If it
is 'off' the data will be written to a database. The default data base that will be used is the
process audit database, but this can be changed in the Process Runtime configuration
home page of each Integration Server.
Using Global Data in Your Process

To manipulate Global Data in your process, use the predefined services in the
pub.PRT.assign package. All the predefined services are based on the BPEL specification.
These services allow you to copy between variables and XPath expressions and bindings
to Web Service Interactions (referred to as “Partner” in the predefined services names and
parameters). Refer to the webMethods Built-In Services Reference for a detailed description of
each assign service.
Note: Always call the service "pub.prt.globalData.lockGlobalData" in your flow before

working using any of the Assign services. It is not necessary to manually unlock the data.
If you want your work with Global Data to be exportable to BPEL Assign activities, you
need to put all of the Assign services within the Generated Flow of a Flow Step.
To define global data for use in a process, follow the steps below.
To define global data
1 Click the global data icon; or, from the process’s Global Data property, select Edit. The
global data dialog appears.
2 Click Add Document or Add Field to add a global data document or field.

Defining Data Properties and Data Aliases

To support BPEL processes, data properties and data aliases may be defined. To define
data properties for use in a process, follow the steps below.
To define data properties
1 From the process’s Data Properties property, select Edit. The Data Properties and Data
Property Aliases dialog appears.
2 Click Add. The Add Property dialog appears.
3 Type the name of the data property, choose the data type from the menu, and click
OK. The data property is added to the list.
4 To define a data property alias, click Add under Data Property Aliases and fill-in the
required information for the alias.


WEBMETHODS MODELER
CHAPTER 7
Adding Logic to Steps
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Working with Flow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Working with Workflow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Working with Correlation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

CHAPTER 7 Adding Logic to Steps
Overview
Logic tells a step how to complete its action—for example, how to process a document,
check credit, or approve a purchase order. You assign logic to steps in the form of services
(for flow steps) and workflows (for Workflow steps). You can create and assign step logic
at design time, or you can create it after generating the model and before deploying it.
In addition to the basic logic that steps require to complete their actions, a step may also
require a correlation service. Correlation services are flow or java services that steps (both
regular and Workflow steps) require to link inbound IS documents with the running
process instance. Details about correlation services are described in “Working with
Correlation Services” on page 152.
The following summarizes the types of logic that you add to steps:
Flow or Java Services that Perform Step Logic. The basic unit of logic that performs the
action of a flow step (i.e., non-Workflow step). Use webMethods Developer to create
the user-defined service, either at design time, or after process model generation. For
details, see “Working with Flow Step Logic” on page 148.
Workflows. The basic unit of logic that performs the action of a Workflow step.
Workflows represent the human interaction that is required for the business process,
for example, having a person approve a purchase order. Use webMethods Workflow
to design workflows. You can create Workflows at design time, or after process model
generation. For guidelines, see “Working with Workflow Step Logic” on page 151.
Flow or Java Services that Act as Correlation Services. The additional type of logic that
regular or Workflow steps might require to link an inbound IS document with the
running process instance. You create and assign correlation services to steps at design
time. For details, see “Working with Correlation Services” on page 152.
Note: For details on using webMethods Developer to create flow services, see webMethods
Developer User’s Guide.
Working with Flow Step Logic

The following sections describe information to keep in mind when working with flow
step logic.
How Modeler Generates Flow Services for Flow steps

When you generate a process model, for each flow step (i.e., non-Workflow step), Modeler
generates flow services. If the step specifies a user-defined service in the Service to Invoke
property, Modeler includes an INVOKE flow operation to invoke the user-defined
service. If you do not specify the Service to Invoke property, Modeler generates an empty
flow service. The generated flow service name corresponds to the value of the step’s

Working with Flow Step Logic
Generated Flow Service property; by default, Modeler gives the generated flow service the
name of the step.
Note: See “What Modeler Generates for a Process Model” on page 201 for details on where
Modeler generates flow services.
Guidelines for Working with Step Logic

After generating the model, you should view the generated flow services and the
user-defined services and edit them as necessary.
Step logic should adhere to the following general guidelines:
webMethods recommends that each generated flow service invoke a single
user-defined service. Packaging services this way makes it easier to replace the service
later if necessary.
When creating the service, try to make the logic as modular as possible. For example,
you may be able to use one “Check Credit” flow service across many process models.
Ensure the generated flow service’s Pipeline In elements map correctly to the
user-defined service’s Service In elements; make sure the user-defined service’s
Service Out elements map correctly to the generated flow service’s Pipeline Out
elements.
Note: By default, if the generated flow service and the user-defined service share
identical inputs and outputs, Modeler automatically maps pipeline-to-service inputs
and outputs. If the step did not specify a service to invoke, or if the service to invoke
contained different inputs and outputs than the step, more mapping work is required.
If you need to specify that a step invoke a completely different user-defined service
than the one currently established, keep the following in mind:
After specifying that a step invoke a different service, you need to regenerate the
process model for the new service to run at run time. You might need to edit the
generated flow service after regenerating to again ensure inputs and outputs are
mapped correctly and to make sure step logic is still packaged within a single flow
service.
Note: Depending on how alike the new service is to the old service, Modeler might 1)
replace the old service with the new service and automap inputs and outputs (if they
were identical) or 2) add the new service to the end of the generated flow service
while keeping all of the previous logic intact. In this case, a more significant amount
of generated flow service editing is required. Make sure you view the generated flow
service after generation and edit as necessary.

Important! At run time, the PRT saves information in the pipeline for its own use. The PRT
saves information in the generated flow service’s ProcessData variable. The information
in the ProcessData variable is for internal use only. Services that you code and that are
executed during the running of a process must not alter any information within this
variable.
PRT Services that You Might Want to Use in User-Defined Services

The webMethods WmPRT package contains a pub folder with services that you might
want to use in your user-defined services. Two of these services are described below. For
complete documentation on these services, see webMethods Built-In Services Reference.
Controlling the Process’s Run-Time Status

As a business process runs, the PRT determines the status for the process and its steps.
This status information is made visible to administrators through webMethods Monitor.
For example, by default, after a step fails, the PRT assigns a “Failed” status to the step, but
not to the entire process. However, there may be cases where you would want a process’s
status to be other than the default status. For example, you might want a process to carry
a “Failed” status if a single step fails.
At design time, you can use the pub.prt.admin:changeProcessStatus service under the WmPRT
package to designate that a process should carry a user-defined status at run time; use this
service within the logic of the appropriate step. For example, if you want Process A to
carry a “Failed” status if Step B fails, call the pub.prt.admin:changeProcessStatus service within
the logic of Step B. Administrators using webMethods Monitor to view Process A at run
time should see a “Failed” status after Step B fails.
Creating and Logging User-Defined Activity Messages

The WmPRT package contains a service that enables you to create and log user-defined
activity messages. The service is pub.prt.admin.log:logActivityMessages. Activity captured by
this service is viewable through webMethods Monitor at run time.
Selecting a Service to Invoke for a Step

To select that a step invoke an existing service at design-time, use the following
procedure.
To Select a Service to Invoke for a Step
1 Open the process model.

2 Right-click on the step that should invoke the service.
3 Choose Select Service to Invoke.

Working with Workflow Step Logic
4 Browse through the packages on the IS Server and select the service to invoke.
5 Click Select.
Working with Workflow Step Logic

When you generate a process model, for each Workflow step in the model, Modeler
generates Workflow projects, implementation modules, and Workflow tasks in the
webMethods Workflow environment.
Guidelines for Generated Workflow Components

After generating the process model and before deploying it, configure the generated
Workflow components using the following guidelines:
1 In the Workflow environment, create a Workflow document containing the data that
the generated Workflow components will need. For example, if the Workflow step is
an “Approve Purchase Order” step, the data in the document should contain all
pertinent information related to approving the purchase order (e.g., the purchase
order’s amount, the buyer’s credit limit, etc.).
2 In the generated implementation module, use the Workflow document that you
created as a blueprint to create a new data field. Map the data field from the Start
node of the generated implementation module to the newly created data field. Then,
map the newly created data field to the data field in the generated implementation
module’s Complete node.
3 Create a data field in the generated workflow and map the data from the
implementation module data field into the Workflow data field. Complete the
workflow.
For details on using webMethods Workflow, see the webMethods Workflow User’s Guide.
Selecting a Workflow to Invoke for a Step

To select that a Workflow step invoke an existing workflow at design-time, use the
following procedure.
To Select a Workflow to Invoke for a Workflow Step

2 Right-click on the Workflow step.

3 Choose Select Workflow to Invoke.
Note: A Workflow server connection dialog might appear if you are not connected to
the Workflow server. Enter your user name and password.
4 Browse to the Workflow project to invoke and click Select.
Working with Correlation Services

Some steps require correlation services in addition to the regular services or workflows that
perform the step’s work. Correlation services are needed to correlate an incoming IS
document with a specific instance of a running process. If the PRT cannot link an
incoming IS document with a running process instance, it will start a new instance of a
process upon receiving the IS document. While there may be some occasions where you
do not need to correlate a document to the process instance, depending on what is
happening in the process, there are many in which you do.
Assuming that you want an IS document to be part of the process instance, you must
select a correlation service for every step in the process (regular or Workflow) that subscribes to
an IS document.
Important! There is one scenario where the PRT correlates an IS document to the process
without a correlation service. That is when all of the following conditions are met: 1) the
step that subscribes to the IS document is the start step, 2) the step subscribes to only one
IS document, and 3) the step is the only step in the model subscribing any document at all
(whether an IS or an external document). If all of these criteria are met, you do not need to
assign the step a correlation service to correlate the document to the process.
You create a correlation service in order to output a correlation ID to the PRT. A correlation
ID is an identifier that is common to all IS documents that are to be processed in a single
process instance. Correlation IDs perform the same function for IS documents as
conversation IDs do for external documents. Details on creating correlation services are
provided in “Creating a Correlation Service” on page 155.
Checklist of Correlation Services Tasks

In general, for every process model, you should:
1 Determine which steps in the process, if any, require a correlation service.
2 Determine how you will create the correlation ID. See “Tips for Creating the
Correlation ID” on page 153.
3 Determine whether you need to create a correlation ID-to-PID mapping manually, or
whether the PRT will create the mapping automatically. See “Determining How the
Correlation ID-to-PID Mapping Will Be Created” on page 154.

4 If needed, create the mapping manually. See “You Must Manually Create the
Mapping” on page 154.
5 Create the correlation service. See “Creating a Correlation Service” on page 155.
6 Assign a correlation service to each step necessary. See “Assigning a Correlation
Service to a Step” on page 157.
7 Ensure you set the process model Local Correlation property appropriately. See
“Broadcasting Correlation IDs” on page 158 for details.
In addition, ensure that:
Each model uses unique correlation services; do not share a correlation service for use
in another process model
The correlation ID for each process is unique among all other correlation IDs
Tips for Creating the Correlation ID

Before you create a correlation service, you need to determine the method you will use to
form it. The correlation service should output a correlation ID that:
Is the same for all IS documents involved in an instance of a process
Is unique among all other correlation IDs
Contains 1-240 characters

Because the correlation ID must be the same for all documents involved in an instance of a
process, you will probably want to use information from within an IS document that is
common to all IS documents in a single process instance. For example, if you define a
process that processes an order, each document in the process might have a common
order ID that you could use when forming your correlation ID.
Because the correlation ID must be unique among all other correlation IDs, when forming
your process ID, include something that makes the correlation ID unique. Keep in mind
that you want to use something that is reproducible for all documents for a specific
process instance. For example, you would not want to use part of a timestamp because the
timestamp would be different when each document for a process instance arrives.
Examples to Use for Forming the Correlation IDs

You have a process that handles an order fulfillment process. The order is always
from a specific customer and the documents all contain the same order ID that
identifies the order being processed. You might form the correlation ID using the
customer ID number and the order ID.
You have created different process models that each handle a different type of order.
The documents to process all contain an order ID. You might form the correlation ID

by using the process model ID that is passed as input into the correlation service and
the order ID.
Determining How the Correlation ID-to-PID Mapping Will Be

Created
The PRT maintains a table of mappings in order to associate correlation IDs to process
instance IDs (PIDs). Before you create the correlation ID, you need to determine how the
correlation ID-to-PID mapping will be created. The correlation ID-to-PID mapping must
exist before the PRT can join a process’s IS documents to a running process instance. There
are two possible ways the mapping can be created.
The PRT Automatically Creates the Mapping

If the start step of a process is associated with a correlation service, the PRT does the
following when a correlation service runs:
If the correlation service returns a correlation ID, the PRT compares the correlation ID
to the mappings in the mapping table.
If it matches one, the IS document is joined to the process.
If it does not match one, a new process instance is started and the PRT creates a
new mapping for the correlation ID to the PID.
If the correlation service does not return a correlation ID, a new process instance is
started and no mappings are added to the mapping table.
You Must Manually Create the Mapping

There are some cases where you must manually create the mapping. In the scenario
described in the previous section, when the correlation service associated with a start step
output a new correlation ID, the PRT created the correlation ID-to-PID mapping.
However, if the first step to need a correlation service is not the start step, you must
manually create the mapping at some point before the step associated with the first IS
document runs.
There are two ways to create the mapping to link the IS document with the running
process instance:
Mapping Method 1: Use the establishCorrelation Service within Upstream Step Logic
One way that you can manually establish the mapping is to create the mapping using the
pub.prt.CorrelationService:establishCorrelation service in the WmPRT package. You can call the
pub.prt.CorrelationService:establishCorrelation service within the logic of any step upstream from
the step subscribing to an IS document. For example, if the first step to subscribe to an IS
document is Step 3, you must create the mapping within the logic of Step 1 or Step 2. For
detailed information on using establishCorrelation and other public correlation

services in the pub.prt.CorrelationService package, see the webMethods Built-In Services

Reference.
Mapping Method 2: Use the Conversation ID of the Start Step’s External Document
In addition to keeping mappings for correlation IDs to process instance IDs, the PRT also
separately maintains mappings between conversation IDs to process instance IDs.
Conversation IDs are the unique identifiers of external documents. The PRT uses
conversation IDs to link external documents to a running instance of a process.
When the PRT receives the first external document in a process, it automatically creates
the mapping to link the document’s conversation ID to the running process instance.
You can establish the mapping for a non-start step’s IS document by creating a correlation
service that treats the IS document’s correlation ID like the conversation ID of the start
step’s external document. To do so, in the Outputs of the correlation service, set the
CorrelateAsTN variable to True. For details, see the “Input/Output Specification for the
Correlation Service” on page 155.
Creating a Correlation Service

For a single process model, you might have one or more steps that require correlation
services. You can use the same correlation service for all steps or use different correlation
services for different steps. Whether you choose to use the same correlation service for all
steps or use different correlation services, all must return the same correlation ID for an
instance of the process.
Important! Do not use the same correlation service for more than one business process. In
addition, ensure that each correlation service creates a correlation ID that is unique among
all other correlation IDs.
Input/Output Specification for the Correlation Service

When your correlation service receives control, it is passed the following inputs:
Input variable Description

ProcessModelID String The ID of the process model with which this invocation of
the correlation service is involved, for example, "P100099FF3".
LogicalServer String The name of the logical server on which this correlation
service is running, for example, “Design_Server”.
ProcessStepID String The ID of the step in the model with which this invocation of
the correlation service is involved, for example, "N3".
DocumentName String The name of this document as used in the process model
(e.g. "OrderDocument").

Input variable Description

DocumentType String The name of this document type (e.g.
"orders.sap:OrderDocument").
Document document (IData object) The document.
Your correlation service should return the following output:
Output variable Description

ProcessCorrelationID String Optional. An identifier that is common to all IS
documents that are to be processed in a single instance of a
process. The PRT correlates the correlation ID that you specify
(in ProcessCorrelationID) with the actual process instance ID of
the running process.
All documents bound for the same instance of the process must
return the same correlation ID. By the same token, correlation
IDs must be unique across all process instances. For example,
"CUSTOMER-0003456977::ORDER-19477593-AR9-1000"
CorrelateAsTN String Optional.Whether you want the PRT to treat the
correlation ID you specify in ProcessCorrelationID exactly as if it
were a Trading Networks conversation ID. Use this to match IS
documents to a process that was started by a Trading Networks
document. Specify one of the following for CorrelateAsTN:
true to indicate you want the correlation ID treated as a
Trading Networks conversation ID
false to indicate that you do not want the correlation ID
treated as a Trading Networks conversation ID; this is the
default output value
For more information about the pub.prt:CorrelationService service (which is in the WmPRT
package), see the webMethods Built-In Services Reference.

Assigning a Correlation Service to a Step

The following sections describe how to assign a correlation service to a step, and how to
edit or delete an existing correlation service.
To Assign a Correlation Service to a Step

2 Right click on the step and choose Select Correlation Service; or, select the drop-down
menu of the step’s Correlation Service property. The IS packages associated with the
step’s logical server appear.
3 Browse to the correlation service and select it.
Editing an Existing Correlation Service

To edit an existing correlation service, open the service from within Developer and edit it.
Or, Modeler can launch Developer to edit the service, as described below.
To Edit an Existing Correlation Service

2 Right click on the step and choose Edit Correlation Service. The Developer appears at the
location of the correlation service so that you can edit the service.
3 From the Developer File menu, choose Lock. This locks the service so that others
cannot modify the service while you are editing it.
4 Edit the service as needed.
5 Save your changes.
6 From the Developer File menu, choose Unlock.
Deleting an Existing Correlation Service
To Delete a Correlation Service

2 Right click on the step and choose Remove Correlation Service. The correlation service is
removed from the step. It is not, however, removed from the server on which it
resided.

Broadcasting Correlation IDs

The process model Local Correlation specifies whether to broadcast correlation IDs to
different servers in the process. For important details on how to set this property in light
of your correlation ID usage, see “Managing Correlation IDs in a Distributed
Environment” on page 267.

WEBMETHODS MODELER
CHAPTER 8
Creating Step Transitions
Overview of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Transition Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Splitting, Branching, and Joining Logic in a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Building Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Guidelines for Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
The Appearance of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

C H A P T E R 8 C r e a t i n g S t e p Tr a n s i t i o n s
Overview of Transitions
You draw transitions (or lines) between steps to indicate the execution order of process
steps. Different transition types, the logic created by transition design (i.e., splits,
branches, and joins), as well as transition conditions, help you to create complex process
logic.
Modeler’s transition types are described below.
Normal. Normal transitions are the most common transition type in a given process
model; they are the only transition type on which you can place conditions. You place
conditions on transitions to affect whether control in the model should proceed in one
direction or another. For example, during the process you might need to approve an
item. After the step that determines whether the approval is granted, you use
transition conditions so the model transitions to one step if approval is granted and
another if approval was not granted. See “Building Transition Conditions” on page 163
for details. You can create an unlimited number of Normal transitions per step.
Retries Exceeded. Retries Exceeded transitions specify the number of times to execute a
step. At run time, if the process attempts to execute the step more than the number of
times that you specify, the process takes the Retries Exceeded transition. You can have
only one Retries Exceeded transition per step.
Timeout. Timeout transitions specify how long to wait for a given step to execute; they
are useful when you create joins that cause the process to wait for multiple events to
occur before continuing (e.g., AND joins). At run time, if the step’s timeout value is
exceeded, the process executes the step following the timeout transition. You can have
only one Timeout transition per step.
Error. Error transitions specify what step to execute if an error occurs for a step. At run
time, the errors transition is taken if the service executed by the step throws an
exception. You can specify only one Error transition per step.
Else. Else transitions specify what step to execute if no other transitions are followed.
At run time, if no other transitions from a step are followed, the process follows the
Else transition. You can specify only one Else transition per step.
Summary of Transitions Allowed Per Step

For any step in the process model, the step is allowed:
Any number of Normal transitions, to which you can assign conditions
One Retries Exceeded transition
One Timeout transition
One Error transition
One Else transition


Follow the steps below to create step transitions.
To Create Step Transitions
1 Place all steps associated with a given transition onto the canvas.
2 Draw transitions to steps as needed. Depending on how you draw transitions, you
might create splits, branches, or joins, described in “Splitting, Branching, and Joining
Logic in a Process” on page 163.
3 Specify the transition type:
a If it is a Normal, Error, Timeout, or Retries Exceeded transition, right-click on the
transition and choose Change Transition Type. Then choose Normal, Error, Timeout, or
Retries Exceeded. (The default transition type is Normal.)
b If it is an Else transition, right-click on the transition and choose Set as “else”
transition. The Edit Transition Conditions window appears. Check Set as “else”
transition and then click OK.
4 Set transition properties by right-clicking on the transition and choosing Properties.
For details, see “Transition Properties” on page 162.
5 Optional. To place conditions on a Normal transition, right-click on the transition and
choose Edit transition condition (or, choose Edit on the transition’s Properties panel). The
Edit Transition Conditions To Target Step window appears so that you can build the
condition. For steps on building transition conditions, see “Building Transition
Conditions” on page 163.
6 Ensure that all steps other than the process-wide error handling step are linked by
transitions. For details, see “Ensure a Clear Flow of Control” on page 168.

Transition Properties
After creating a transition, specify its properties. These are described below.

Label Name for the transition, e.g., “Step 4 to Type a name in the box
Step 5”. besides Label.
Description Full transition description. There is no Type a description in the
limit on description length. Edit box.
Transition The type of transition. Transition types Normal. To choose
Type include Normal, Error, Timeout, and another type, select a type
Retries Exceeded, and Else. For definitions, from the drop-down list.
see “Overview of Transitions” on
page 160. Note: To make this
transition an Else
transition, right-click on
the transition and choose
Set as “else” transition.
Condition Conditions on the transition, e.g., To enter a condition, click

transition to target step only if value of the Edit button.
Name field is “Authorized”. You can specify
conditions for Normal transitions only.
Note: For steps on setting transition

conditions, see “Building Transition
Line Style The type of line style (e.g., curved or The default line style
straight) for the transition. corresponds to the default
process Line Style,
specified at the bottom of
the process window.

Splitting, Branching, and Joining Logic in a Process
Splitting, Branching, and Joining Logic in a Process

Depending on how you design your transitions, you can create any of the following types
of logic:
Splits. Splits are created when you draw transitions from one step to two or more steps
without placing conditions on the transitions. At run time, all transitions are executed
and processing splits into two or more threads of execution.
Branches. Branches are created when you draw transitions from one step to two or
more steps and place conditions on the transitions. At run time, at most one transition
is executed. For details on building transition conditions, see “Building Transition
Joins. Joins are created when you do any of the following:
Specify multiple subscriptions for a step (including start steps)
Specify both an input transition and a subscription document for a step
Draw transitions from two or more steps to a single step
Building Transition Conditions

A transition condition defines the circumstances under which a step following a transition
executes. You assign transition conditions to Normal transitions only. You can define
transition conditions based on the following three types of process information.
Input or Output Data to the Current Step. The input or output data to the current step (i.e.,
the step that is the source of the transition). You can create conditions based on either
the existence of an input or output document, or on the value of the fields in an input
or output document.
Pipeline Data. Data that is in the pipeline as a result of upstream step processing.
Trading Networks (TN) Participants. Information about Trading Networks participants

involved in the process prior to a given transition.
Important! Do not assign conditions to transitions to and from external groups, as the PRT
ignores these transitions and groups.

Defining Transition Conditions

Use the following procedure to define a transition condition.
To Define a Transition Condition
1 Right-click the transition and select Edit transition condition; or, from the transition’s
Condition property, select Edit. The Edit Transition Conditions window appears.
2 To specify transition conditions, click Add.

3 Set up conditions by filling out the Field Name, Operator, Comparison Value/Field, AND/OR,
and Description fields. See “Edit Transition Conditions Window” on page 165. Click
OK.

Edit Transition Conditions Window

Field Name You can create transition conditions using the following
information:
Data: The Data folder contains the input and output documents
(and their fields), and output fields, for the step from which
the transition originates; the Data folder also contains pipeline
data available from upstream in the process. Select the
document, field, or pipeline data containing the information
on which you want to base the condition. For example, to
build a condition based on information in a document’s Date
field, select the Date field from the appropriate document.
Global Data: Conditions can be evaluated on any Global Data
defined for the process.
TN Participant: If the step’s publication or subscription
document is an external document, this folder contains these
documents, named according to the sender/receiver roles that
you assigned when adding the document to the step. Only
documents used prior to the transition appears in this folder. If
no external documents have been used in the process, this
folder is empty.
Note: You can use TN Participant information for transition
conditions even if the step from which the transition comes
does not run on a server that is running Trading Networks.
The only requirement for using these conditions is that the
Trading Networks information must be used upstream in the
process.
Under the external documents, the following information
appears. Select the type of information on which you want to
base the condition.
Profile Name: Possible values include user-defined profile
names defined on the Trading Networks system.
Extended Field Names: The specific names of the extended
fields used by the document’s sender or receiver. If the
sender or receiver did not use extended fields, no
extended fields appear.


Operator Specify the operator to use for the condition. The operators
available for the condition depend on the data type of the field
selected under Field Name. Data types such as byte arrays, objects,
lists, and tables will have only the operators exists and does not
exist. Other data types such as numeric fields will have the exists
and does not exist operators as well as comparison operators, such
as = (equals), != (does not equal), > (greater than), < (less than), >=
(greater than or equal to), <= (less than or equal to). String fields will
have all of the preceding operators as well as starts with, ends with,
contains, does not start with, does not end with, does not contain, exists,
and does not exist.
Comparison To complete the transition condition, you can either enter a
Value/Field comparison value or select a field in a document from which you
want to compare values; you are comparing values or fields with
the value of the Field Name field. The value that you enter here must
be the of the same data type (e.g., String, integer, boolean, etc.) as
the data type of the Field Name selection. For example, if you
selected “PO Number” under Field Name, and the field was of the
data type “String”, you would enter or select a value consistent
with a String, such as “PO123”.
Note: If the field selected under Field Name is a byte array, list,
object, or table, you cannot enter values/fields here; rather, you
must select them.
AND/OR Use the AND/OR field to link multiple conditions using either the
AND or OR operator. To enable the AND/OR operator after
creating a condition, choose Add from the top of the dialog.
Description Type a detailed description of the condition. Optional.

Defining Transition Conditions Using XPath Expressions

Use the following procedure to define a transition condition using an XPath expression.
To Define a Transition Condition using an XPath expression
1 Right-click the transition and select Edit transition condition; or, from the transition’s
Condition property, select Edit. The Edit Transition Conditions window appears.
2 To specify a transition condition using an XPath expression, click Use XPath Expression.
3 Enter the XPath expression in the Expression field. A description is optional.

4 Click OK.
Working with Global data in XPath

The following built-in BPEL functions can be used to access global data:
bpws:getVariableProperty(‘variableName’,’propertyName’)
bpws:getVariableData(‘variableName’,’partName’,’locationPath’)

Guidelines for Transitions

Use the following guidelines when working with transitions.
General Guidelines
Ensure Data for Transitions is in the Process at Run Time
When you draw your process model, be sure that the information needed for a
condition on a transition will always be available at run time. For example, consider
the following process model. In this process model, the transitions from Step 3 to Step 4
and Step 3 to Step 5 require information in the document that arrives in Step 2.
Process where data not available for condition if error transition is taken
In the above process model if Step 1 takes the error transition:

Step 2 will never be processed, so the document for which Step 2 waits will never enter
the process.
The conditions on the transitions from Step 3 to Step 4 and Step 3 to Step 5 cannot be
evaluated because the condition requires information from the document that was
supposed to arrive in Step 2.
Ensure a Clear Flow of Control
The order in which the steps are performed must be clear. Be sure all steps (in internal
groups and outside of any group) are linked together. The only exception to this rule
is the process-wide error step. For details, see “Process-Wide Error Steps” on page 87.
When considering the flow of control in a process model, you must ignore the
transitions to and from uncontrolled steps that are within external groups. Transitions
to and from steps in external groups, like the groups themselves, are purely for visual
aid and are ignored by the PRT.

Incorrect process model that does not have a clear flow of control
In the above process model, there is not a clear flow of control. All steps in internal groups
or outside of any group are not linked. The chain of steps breaks at the external group. The
order between the send order, wait for acknowledgement, and wait for response steps is not clearly
defined. To make the order clear, draw transitions between these steps as shown in the
below.
Process model that has a clear flow of control

Guidelines for Transitions that Create Splits and Joins

Keep splits and joins as simple as possible
Place join logic shortly after the split if you will rejoin the threads
Be careful using conditions with joins
See the following examples for details.
Use caution when using OR joins after splits
OR joins allow multiple threads of execution to run simultaneously after the join.
When the PRT encounters an OR join, it continues a thread for each transition coming
into the OR join. In the following sample process model, the numbers on the
transitions represent the number of threads processing.
OR joins and number of threads of execution
Six threads
arriving
Three threads
arriving at different
times. Each thread
continues.
If you want a single thread of execution to run after a join, do one of the following:
Place conditions on the splits before the OR join, so that at run time exactly one
transition out of the split executes. As a result, only one active transition will enter
the OR join.
Use an XOR join rather than an OR join. The XOR join continues processing the
first transition that enters the XOR join.
Use an AND join to wait for all transitions to arrive before continuing. When all
transitions have arrived, processing continues with a single thread.

Ensure conditions used with AND joins do not halt the process
When you have an AND join in your process and you place conditions on the splits
before the AND join or conditions on the transitions leading to the AND join, be sure
that all conditions can be met at run time. If all conditions are not met, processing will
halt.
Sample of a process model with conditions and an AND join
For example, in the above sample if at run time, the condition “X > 10” is not true
and/or the condition “Y > 10” is not true, the process halts. Step 3 cannot execute until
both the transition from Step 1 to Step 3 and the transition from Step 2 to Step 3 are
satisfied.
Use caution when using XOR joins and loops
The PRT will process an XOR join only a single time during a process. If there is a loop
in your logic that causes the XOR join to be evaluated a second time after it has
already been satisfied, processing will halt.
Sample model with an XOR join in a loop that causes processing to halt
In the above process model, the transitions from Step 2 and Step 3 are joined with an
XOR join. The first transition coming from either Step 2 or Step 3 will satisfy the XOR
join. When the XOR join is satisfied, the PRT executes Step 4, then Step 5. Step 5 loops
back to Step 1 and continues. However, the second time through the loop, Step 4 will

not execute. This is because the XOR join has already been satisfied the first time
through the loop and the PRT will not evaluate it again. Processing halts.
If you need to add this type of logic to your process model, use OR joins with
conditions as shown in the following sample.
Sample model that replaces XOR join in a loop with an OR join
Keep pipeline variables distinct among threads of split logic

When you split the logic in a process model and execute services that use pipeline
data in each thread of execution, keep your top-level pipeline data names distinct.
Although the threads of execution do not share pipeline data, when you do a join, the
pipeline data is merged. During the merge, top-level pipeline data without unique
names will be resolved to a single data item. It is unpredictable what value the data in
the resulting pipeline will have.

Pipeline variable names are not distinct
It is not predictable whether

the values in the resulting
pipeline will be from the
thread that executed Step A
or the thread that executed
Step B.
For example, in the above process model, it is not predictable whether pipeline
variable String1 will have the value from Step A or the value from Step B after the
pipeline is merged. Also note that although the String variables within the Document1
variable have different names for Step A and Step B (that is CustomerInfo and PartnerInfo),
when the pipeline is merged, only one Document1 variable remains and the variables
within are not merged.

To avoid problems with pipeline merging, keep the top-level pipeline variable names
distinct as shown in the sample below.
Pipeline variable names are distinct

The Appearance of Transitions
The Appearance of Transitions
Displaying/Hiding Transitions Types

If the Show Transition Conditions property is enabled, the transition type appears on the
transition in the model, with the exception of Normal transitions.
Visible Transition Types
To hide/display transition types, choose ToolsOptions and check or uncheck the Show
Transition Types property.
Controlling the Color of Transitions
Default Transitions
You can specify a default color for Normal transitions by choosing ToolsOptions and
selecting a color from the Line Color property.

Other Transitions
You can specify that the other transition types (Timeout, Error, and Retries Exceeded)
each display as distinct colors. To do so, choose ToolsOptions and enable Color Transition
Types.
Note: You cannot change the colors that Modeler assigns to these transition types.

WEBMETHODS MODELER
CHAPTER 9
Adding Groups to a Process Model
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Adding a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
External Groups and Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Resizing and Moving Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Changing the Appearance of Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

CHAPTER 9 Adding Groups to a Process Model
Overview
You can place steps into groups to represent different organizational boundaries or
different phases within the business process. Groups are represented by shaded
rectangles in the process model. Placing steps within groups can be a helpful visual aid
for complicated process models, but is never required. Use groups if they help you to
conceptualize phases of a model more easily.
There are two types of groups:
Internal groups Internal groups band together steps within the scope of the business
process. The group does not affect the way that the process runs. Steps in internal
groups (like steps outside of any group) must be complete (i.e., with logic, inputs and
outputs, etc.), as the PRT uses the steps to generate run-time elements. You might
create internal groups, for example, for steps performed by specific departments, such
as Accounting or Purchasing.
External groups External groups band together steps outside the scope of the business
process; they enable you to include these steps within the process to help you to
visualize the process from beginning to end. For example, it might be helpful to see a
step that waits for a document or sends an acknowledgement, even if the step is not
within the model’s scope. When you generate the model, no run-time elements are
created for steps in external groups. That is, the PRT ignores these steps. Use external
groups if it helps you to conceptualize a process from beginning to end.
The following process model includes both internal and external groups. The steps in the
internal group execute just as if they were outside of any group. The steps in the external
group are purely visual aids and are ignored by the PRT.

Adding a Group
Model with Internal and External Groups
Internal groups box steps

that are performed within
your enterprise
External groups box steps

that are performed outside
your enterprise.
Adding a Group
To add an internal or external group to a process model, use the following procedure.
To Add a Group to a Process Model
1 On the process model taskbar, select the Draw Group icon.

2 Drag the pointer across the canvas to form the group box (around existing steps if
desired). The Select Group Type window appears.

CHAPTER 9 Adding Groups to a Process Model
3 Select Internal group or External organization, depending on the type of group you are
creating. By default, an internal group appears as a shaded gray rectangle with solid
borders. By default, an external group appears as a shaded blue rectangle with dotted
borders.
External Groups and Step Transitions

You can draw transitions to and from external groups if it helps you to visualize
information flow, however, be aware that these transitions are ignored by the PRT.
Resizing and Moving Groups

You can click inside of a group and drag it to move it. To resize a group, hold the pointer
over the group’s edge until the double arrows appear and resize it as needed.
Changing the Appearance of Groups

By right-clicking on the group and selecting Visual Properties, you can change a group’s:
X-coordinate
Y-coordinate
Border width
Border height
Whether a border appears

Whether a background appears
Color of the backgrounds

WEBMETHODS MODELER
CHAPTER 10
Importing and Exporting BPEL Process Models
Importing BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Exporting Process Models in BPEL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

CHAPTER 10 Importing and Exporting BPEL Process Models
Importing BPEL Process Models

Complete the following steps to import a BPEL process model.
To import a BPEL process model
1 From the File menu, select Import.The Select import file dialog appears.
2 Select the desired .bpel file and click Open. The Select WSDL import file dialog
appears.
3 Select all of the .wsdl files associated with this process (using group select) and click
Open. The imported process appears, along with any warnings or errors encountered
during the import. Warnings are displayed identifying any unsupported BPEL
constructs skipped during import. If these warnings occur, your Modeler process may
not be functionally equivalent to the original BPEL process.
Note: Version 6.1 of Modeler does not support import of XSD schema files. In order to
import message types that have their parts defined in xsd documents, you must import
the xsd documents directly into the Integration Server using Developer.

BPEL Mappings
The process model created during the BPEL import process contains elements that are
mapped from the .bpel file and associated .wsdl files into the resulting process model.
Following is a list of these elements and a description of how each mapping approximates
the original BPEL element.
BPEL4WS Element Imported Process Model Element

Partner Links Web Service Interaction
Variables Global Data
Message and document type Integration server document definitions
definitions
BPEL Basic Activities:
<receive> Web Service Receive Step
<reply> Web Service Reply Step
<invoke> Web Service Invoke Step
<terminate> Terminate Step
<empty> Empty Step
<assign> Assign Services in PRT
<throw> Not supported
<wait> Flow step, with user-added code for the wait
time.
BPEL Structured Activities
<compensate> Not supported
<while> Transition from preceding activity defined by
the while condition expression followed by the
activities defined in the <while> activity that
transition back into the preceding activity.
<sequence> No effect, flow retains sequence
<scope> Not supported
<switch> Transitions logically equivalent to the switch
<flow> Transitions from preceding activity to each
activity defined in the <flow> activity.
<pick>
Multiple receive steps with XOR join

Partner Links
The information defined for Partner Links in the BPEL process is mapped to the Web
Service Interaction information in Modeler. This information includes the following:
Interaction Name - taken from the name of the partner link.
My Partner’s Port Type - the port type that is defined according to the
“partnerRole” attribute.
My Process’s Port Type - the port type that is defined according to the “myRole”
attribute.
This information is initially taken from the WSDL file that defines the interaction in the
BPEL process.
Variables, Message Types, and Document Type Definitions

BPEL variables become global data in Modeler when imported. Each complex message
type used in the process will be generated into a record at
<WSDL name>.MessageTypes:<name of message type in wsdl>.
Any complex document type definitions used by messages in the process are imported to
<WSDL name>.DocumentTypes:<documents contained in message type>.
A document containing all variables as its elements is created on the Integration Server at
<process name>.Design_Server.GlobalData:<process name>+GlobalData.
Use of this document type is optional and not required at process runtime.
For example, consider the following definition of variables:
<variables>

<variable name="input"
messageType="initiateLoanFlowSoapRequest"/>

<variable name="selectedLoanOffer"
messageType="onLoanFlowResultSoapRequest"/>
</variables>
The message types referred to by the above variables are as follows:

<message name="initiateLoanFlowSoapRequest">
<part name="parameters" element="initiateLoanFlow"/>
</message>
<message name="onLoanFlowResultSoapRequest">
<part name="parameters" element="onLoanFlowResult"/>
</message>

On import, the variables element will be converted into an IS record named

LoanFlow.Design_Server.GlobalData:LoanFlowGlobalData.LoanFlowGlobalData,
which will contain document references to the following:
initiateLoanFlowSoapRequest
onLoanFlowResultSoapRequest
These documents define the following message types:

initiateLoanFlowSoapRequest
onLoanFlowResultSoapRequest
These message types are imported as:

LoanFlow.MessageTypes:initiateLoanFlowRequest
LoanFlow.MessageTypes:onLoanFlowResultSoapRequest
BPEL Web Service Activities

The following activities are mapped directly to the corresponding type of web service
step:
Receive
The BPEL <receive> activity is imported as a web service receive step in the Modeler. For
example, the <receive> activity
<receive name="receiveInput" partnerLink="client"
portType="tns:LoanFlow"
operation="initiate" variable="input"
createInstance="yes"/>
will be imported as a web service receive step with the following properties:
portType = LoanFlow
operation = initiate
Output variable = input

Reply
The BPEL <reply> activity is imported as a web service reply step in the Modeler. For
example, the <reply> activity
<reply name = "UANG_SyncAccount_faultReply"
partnerLink = "partner"
portType = "wsdl1:Default"
operation = "Execute"
variable = "UANG_SyncAccount_fault"/>
will be imported as a web service receive step with the following properties:
portType = Default
operation = "Execute"
Input variable = "UANG_SyncAccount_fault"
Invoke
The BPEL <invoke> activity is imported as web service invoke step in the Modeler. For
example, the <invoke> activity
<invoke name="invokeCR" partnerLink="creditRatingService"
portType="crs:CreditRatingService" operation="process"
inputVariable="crInput" outputVariable="crOutput"/>
will be imported as a web service invoke step with the following properties:
portType = CreditRatingService
operation = process
inputVariable = "crInput"
outputVariable = "crOutput"
Terminate Activity
The BPEL <terminate> activity is imported as a terminate step.
Empty Activity
The BPEL <empty> activity is imported as an empty step.
Wait Activity
The BPEL <wait> activity is imported as a Modeler flow step. You will need to manually
set up the flow service to control the wait.

While Activity
The BPEL <while> activity is imported as a loop containing activities embedded in the
while activity. The loop is generated on the preceding activity. Consider the following
example of a while activity:
<assign>
<while condition="bpws:getVariableData(orderDetails) > 100">
<invoke>
</while>
This will be imported as an assign step which has a transition to an invoke step having
condition expression = "bpws:getVariableData(orderDetails) > 100". The invoke
step loops back to the assign step.
Assign Activity
Modeler performs BPEL <assign> within the logic of a webMethods flow service. The
flow service is created on import, and a Modeler flow step is used in the process to invoke
this flow. Consider the following example of an assign activity:
<assign>
<copy>
<from variable="PO" part="customerInfo"/>
<to variable="shippingRequest"part="customerInfo"/>
</copy>
</assign>
This assign activity will be generated into a flow service which will be invoking
pub.prt.assign:variableToVariable with input variables set to the following values:
variableNameFrom = "PO"
partFrom = "customerInfo"
queryFrom = ""
variableNameTo = "shippingRequest"
partTo = "customerInfo"
Please refer to the webMethods Built-In Services Reference for detailed information about
each assign activity type and its usage.
BPEL Structural Activities

The following is a list of BPEL structured activities and their equivalents in webMethods
Modeler:
Sequence
The activities contained in BPEL <sequence> activity on import are connected to each
other in the same order as they are defined in the sequence activity. This ensures their
order of execution.

Scope
Activities and their ordering in the BPEL <scope> activity is maintained, but scope-
specific constructs such as compensation and fault handling are currently ignored.
Switch
The BPEL <switch> activity will be imported as transitions from the preceding activity
for activities embedded the case and otherwise members. Consider the flowing pseudo
code example of switch activity:
<activity A>
<switch>
<case 'P'>
<activity B>
</case>
<case 'Q'>
<activity C>
</case>
<case 'R'>
<activity D>
</case>
<otherwise>
<activity E>
</otherwise>
</switch>
On import, activity A will be represented by a step in Modeler with transitions to four

activities, B, C, D, and E. The transitions will be controlled by condition statements
matching each of the cases. To preserve the ordering of a BPEL <switch>, additional logic
will be added to the condition statements generated for each transition. This is necessary
because Modeler does not support ordered evaluation of transitions.
To represent the <switch> from the example above, the following logic is used on
transitions in the Modeler:
- Transition from A to B if and only if 'P'.
- Transition from A to C if and only if 'Q' and not 'P'.
- Transition from A to D if and only if 'R' and not 'P' and not 'Q'.
- Transition from A to E if and only if no other transitions are taken
(using the Modeler's "Else" condition).

Flow without Links

A BPEL <flow> activity that does not define flow links will be imported as transitions
from the preceding activity for each activity defined in the flow link. Consider the flowing
pseudo code example of a BPEL <flow> activity:
<Activity A/>
<flow>
<Activity B/>
<Activity C/>
<Activity D/>
</flow>
The BPEL above will be imported as a single step A, with transitions to the three activities
A, B, and C.
Flow with Links

The BPEL <flow> activity with links will only differ in how the activities defined inside of
the flow activity are connected to each other. Links overrides any structural construct.
Pick
The BPEL <pick> activity is not currently fully supported, but Modeler approximates its
behavior. The <pick> activity is imported as receive step for each <onMessage> element
that transitions to the activities defined in the <onMessage> element, all followed by an
XOR join to the activity following the <pick>. Consider the following example of a pick
activity:
<pick>
<onMessage ...>
<activity A>
</onMessage>
<onMessage ...>
<activity B>
</onMessage>
<onMessage ...>
<activity C>
</onMessage>
</pick>
This will import as three web service receive steps, one for each message type, followed
by the corresponding activity A, B, or C. The steps for A, B and C will transition to a new
Empty Step in the Modeler with an 'XOR' join on it. This is not exactly functionally
equivalent to the BPEL <pick> because it allows that any of A, B, and C may execute.

Exporting Process Models in BPEL Format

Modeler processes can be exported to BPEL. Processes that invoke webMethods flow
services will automatically create WSDL files to describe those services and BPEL and
WSDL files describing the business process.
To create the most portable BPEL export code you should create your process using the
following Modeler constructs:
Web Service Steps to create BPEL Receive, Reply and Invoke Activities
Global Data to create BPEL Variables
Flow Steps invoking services that use the predefined PRT Assign services to create
BPEL Assign steps (See the webMethods Built-In Services Reference)
XPath expressions in Joins and Timeouts for BPEL join and timeout parameters.
BPEL Export Guidelines

A BPEL file, its associated WSDL file, and WSDL files that define the generated wrapper
flow service for IS steps and WSDL files for all web service receive steps will be generated
in the export process.
The process model that is exported in BPEL format defines the entire process model using
the <flow> activity with links as the transitions. The Web Service Interactions are
exported as partner links. The global data is exported as BPEL <variables>.
Each Web Service Step is exported as a BPEL <invoke>, <recieve>, or <reply> activity.
Flow Steps that invoke a flow service that uses the built-in PRT Assign services will be
exported as BPEL <assign> activities with copy statements derived from the logic in the
PRT Assign services. Empty Steps become BPEL <empty> activities and Terminate steps
become BPEL <terminate> activities.
Any other controlled Flow or Workflow steps in the process are converted into a
combination of BPEL invoke and receive activities, according to the document publication
and subscription properties of the step. There will be a BPEL <receive> activity for each
document subscription, a BPEL <invoke> activity for the step's generated service, and
additional <invoke> activities for each document publication.
The exported BPEL will contain partner links for of all of the Web Service Interactions
defined for the process model being exported, plus additional partner links that will be
created for any Flow or Workflow steps, based on the document publications or
subscriptions of that step:
The web service receive step exported for the subscription document creates a partner
link as <Flow_Step_Name>ReceiveService.
The web service invoke step exported for the generated wrapper flow service creates
<Flow_Step_Name>InvokeService.

The web service invoke step exported for the publication document creates a partner
link as <Flow_Step_Name>NotificationService.
The exported BPEL <variables> element will contain variables representing the process'
global data. There will also be variables created for any Flow and Workflow steps
according to the steps' inputs and outputs and document subscriptions and publications:
If the step has a subscription, that subscription will be represented in BPEL as a
<receive> activity, and a new variable will be created for use as that activity's
variable attribute. The variable will be defined as a message named
<Flow_Step_Name>ReceiveStepInput, and it will contain the subscribed document
type as one of its parts.
Variables are created for the input and the output data of the generated service of the
Modeler step and they will contain the input pipeline data and the output pipeline
data for that service, respectively.
If the step has a publication, that publication will be represented as a BPEL <invoke>
activity and a new variable will created for the input to that activity. The variable is
defined as a message named <Flow_Step_Name>NotificationStepInput, and it
contains the published document type as one of its parts.
The following WSDL files are exported along with BPEL process:
A WSDL file for the BPEL process interface. This defines the process level partner link
types, variables and port types. The partner link types created in this WSDL are either
based on web service interaction or are created for use with the WSDLs for the Flow
and Workflow steps. The variables created for this WSDL consist of the global data as
well as the pipeline line data for IS steps.
WSDL files for each Flow or Workflow step's generated wrapper service. This WSDL
defines the web service interface for the step's generated flow service.
WSDL files for each Web Service Step configured for receive. The web service step is
generated to Integration Server as a flow service that is exposed as a web service.

The following is an example of an exported BPEL process:
Example of Exported BPEL Process
<?xml version="1.0" encoding="UTF-8"?>

<process
expressionLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116"
name="BusinessProcess"
queryLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116"
suppressJoinFailure="no"
targetNamespace="http://najeeb:5555/BusinessProcess"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"
xmlns:wsdl0="http://demo.cxdn.com"
xmlns:wsdl1="http://samples.cxdn.com" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<partnerLinks>
<partnerLink name="Flow_StepInvokeService"
partnerLinkType="Flow_StepInvokeServiceLT" partnerRole="Flow_StepInvokeServicePartnerRole"/>
<partnerLink name="Workflow_StepInvokeService"
partnerLinkType="Workflow_StepInvokeServiceLT"
partnerRole="Workflow_StepInvokeServicePartnerRole"/>
<partnerLink myRole="CreditRatingService" name="ws_invoke" partnerLinkType="wsdl0:ws_invoke"/>
<partnerLink myRole="LoanFlow" name="ws_receive_reply"
partnerLinkType="wsdl1:ws_receive_reply" partnerRole="LoanFlowCallback"/>
</partnerLinks>
<variables>
<variable
messageType="wsdl1:LoanFlow_MessageTypes_pollLoanFlowResultSoapResponse"
name="pollLoanFlowResultSoapResponse"/>
<variable
messageType="wsdl1:LoanFlow_MessageTypes_onLoanFlowResultSoapRequest"
name="onLoanFlowResultSoapRequest"/>
<variable
messageType="wsdl1:LoanFlow_MessageTypes_initiateLoanFlowSoapRequest"
name="initiateLoanFlowSoapRequest"/>
<variable
messageType="wsdl1:LoanFlow_MessageTypes_initiateLoanFlowSoapResponse"
name="initiateLoanFlowSoapResponse"/>
<variable
messageType="wsdl0:CreditRatingService_MessageTypes_processCreditRatingServiceSoapRequest"
name="processCreditRatingServiceSoapRequest"/>
<variable
messageType="wsdl0:CreditRatingService_MessageTypes_processCreditRatingServiceSoapResponse"
name="processCreditRatingServiceSoapResponse"/>
<variable messageType="Flow_StepInvokeStepInput" name="Flow_StepInvokeStepInput"/>
<variable messageType="Flow_StepInvokeStepOutput" name="Flow_StepInvokeStepOutput"/>
<variable messageType="Workflow_StepInvokeStepInput" name="Workflow_StepInvokeStepInput"/>
<variable messageType="Workflow_StepInvokeStepOutput" name="Workflow_StepInvokeStepOutput"/>
</variables>

<flow>
<links>
<link name="Web_Service_StepA-to-Web_Service_Step"/>
<link name="Workflow_Step-to-Web_Service_Step1"/>
<link name="Web_Service_Step-to-Workflow_Step"/>
<link name="Web_Service_Step-to-Flow_Step"/>
<link name="Flow_Step-to-Web_Service_Step1"/>
</links>
<receive name="Web_Service_StepA" operation="onResult"
partnerLink="ws_receive_reply" portType="portType" variable="onLoanFlowResultSoapRequest">
<source linkName="Web_Service_StepA-to-Web_Service_Step"/>
</receive>
<invoke inputVariable="processCreditRatingServiceSoapRequest"
name="Web_Service_Step" operation="process"
outputVariable="processCreditRatingServiceSoapResponse"
partnerLink="ws_invoke" portType="portType">
<target linkName="Web_Service_StepA-to-Web_Service_Step"/>
<source linkName="Web_Service_Step-to-Flow_Step"/>
<source linkName="Web_Service_Step-to-Workflow_Step"/>
</invoke>
<invoke inputVariable="Workflow_StepInvokeStepInput"
name="Workflow_StepInvokeService"
operation="Workflow_StepInvokeServiceOperation"
outputVariable="Workflow_StepInvokeStepOutput"
partnerLink="Workflow_StepInvokeServiceLink" portType="Workflow_StepInvokeServicePortType">
<target linkName="Web_Service_Step-to-Workflow_Step"/>
<source linkName="Workflow_Step-to-Web_Service_Step1"/>
</invoke>
<invoke inputVariable="inputVariable"
joinCondition="getLinkStatus(Workflow_Step-to-Web_Service_Step1) and getLinkStatus(Flow_Step-
to-Web_Service_Step1)"
name="Web_Service_Step1" operation="pollResult"
outputVariable="pollLoanFlowResultSoapResponse"
partnerLink="ws_receive_reply" portType="portType">
<target linkName="Workflow_Step-to-Web_Service_Step1"/>
<target linkName="Flow_Step-to-Web_Service_Step1"/>
</invoke>
<invoke inputVariable="Flow_StepInvokeStepInput"
name="Flow_StepInvokeService"
operation="Flow_StepInvokeServiceOperation"
outputVariable="Flow_StepInvokeStepOutput"
partnerLink="Flow_StepInvokeServiceLink" portType="Flow_StepInvokeServicePortType">
<target linkName="Web_Service_Step-to-Flow_Step"/>
<source linkName="Flow_Step-to-Web_Service_Step1"/>
</invoke>
</flow>
</process>

BPEL Export Details

The following section defines the various partner links exported for each type of step
defined in the Model:
<partnerLinks>
<partnerLink name="Flow_StepInvokeService"
partnerLinkType="Flow_StepInvokeServiceLT"
partnerRole="Flow_StepInvokeServicePartnerRole"/>
The partner link for Flow_Step (IS step) defines partner role
"Flow_StepInvokeServicePartnerRole", which points to the port type defined by the
web service for generated wrapper flow service.
<partnerLink name="Workflow_StepInvokeService"
partnerLinkType="Workflow_StepInvokeServiceLT"
partnerRole="Workflow_StepInvokeServicePartnerRole"/>
The partner link for Workflow_Step defines partner role

"Workflow_StepInvokeServicePartnerRole", which points to the port type defined by
the web service for generated workflow.
<partnerLink myRole="CreditRatingService" name="ws_invoke"
partnerLinkType="wsdl0:ws_invoke"/>
The ws_invoke partner link points to the partner link type defined at wsdl0.
<partnerLink myRole="LoanFlow" name="ws_receive_reply"
partnerLinkType="wsdl1:ws_receive_reply"
partnerRole="LoanFlowCallback"/>
</partnerLinks>
The ws_receive_reply partner link points to the partner link type defined at wsdl0.
The following section defines the various variables defined for each type of process steps:
<variables>
<variable
messageType="wsdl1:LoanFlow_MessageTypes_pollLoanFlowResultSoapResponse"
name="pollLoanFlowResultSoapResponse"/>
The message “pollLoanFlowResultSoapResponse” points to the message type definition

at wsdl1.
<variable
messageType="wsdl1:LoanFlow_MessageTypes_onLoanFlowResultSoapRequest"
name="onLoanFlowResultSoapRequest"/>
<variable
messageType="wsdl1:LoanFlow_MessageTypes_initiateLoanFlowSoapRequest"
name="initiateLoanFlowSoapRequest"/>
<variable
messageType="wsdl1:LoanFlow_MessageTypes_initiateLoanFlowSoapResponse"
name="initiateLoanFlowSoapResponse"/>
<variable

messageType="wsdl0:CreditRatingService_MessageTypes_processCreditRatin
gServiceSoapRequest" name="processCreditRatingServiceSoapRequest"/>
<variable
messageType="wsdl0:CreditRatingService_MessageTypes_processCreditRatin
gServiceSoapResponse" name="processCreditRatingServiceSoapResponse"/>
<variable messageType="Flow_StepInvokeStepInput"
name="Flow_StepInvokeStepInput"/>
The “Flow_StepInvokeStepInput” message points to the input message defined for

wrapper flow service input.
<variable messageType="Flow_StepInvokeStepOutput"
name="Flow_StepInvokeStepOutput"/>
The “Flow_StepInvokeStepInput” message points to the input message defined for

wrapper flow service output.
<variable messageType="Workflow_StepInvokeStepInput"
name="Workflow_StepInvokeStepInput"/>
<variable messageType="Workflow_StepInvokeStepOutput"
name="Workflow_StepInvokeStepOutput"/>
</variables>
The flow activity below defines the equivalent activities of the above process model and
the links/connections between them.
<flow>
<links>
<link name="Web_Service_StepA-to-Web_Service_Step"/>
Defines the link between “web_service_stepA” to “Web_Service_Step”

<link name="Workflow_Step-to-Web_Service_Step1"/>
<link name="Web_Service_Step-to-Workflow_Step"/>
<link name="Web_Service_Step-to-Flow_Step"/>
<link name="Flow_Step-to-Web_Service_Step1"/>
</links>
The web service receive step equivalent activity.

<receive name="Web_Service_StepA" operation="onResult"
partnerLink="ws_receive_reply" portType="portType"
variable="onLoanFlowResultSoapRequest">
<source linkName="Web_Service_StepA-to-Web_Service_Step"/>
</receive>
The web service invoke step equivalent activity.

<invoke inputVariable="processCreditRatingServiceSoapRequest"
name="Web_Service_Step" operation="process"
outputVariable="processCreditRatingServiceSoapResponse"
partnerLink="ws_invoke" portType="portType">
<target linkName="Web_Service_StepA-to-Web_Service_Step"/>
<source linkName="Web_Service_Step-to-Flow_Step"/>

<source linkName="Web_Service_Step-to-Workflow_Step"/>
</invoke>
The workflow step equivalent web service invoke activity.

<invoke inputVariable="Workflow_StepInvokeStepInput"
name="Workflow_StepInvokeService"
operation="Workflow_StepInvokeServiceOperation"
outputVariable="Workflow_StepInvokeStepOutput"
partnerLink="Workflow_StepInvokeServiceLink"
portType="Workflow_StepInvokeServicePortType">
<target linkName="Web_Service_Step-to-Workflow_Step"/>
<source linkName="Workflow_Step-to-Web_Service_Step1"/>
</invoke>
The web service reply equivalent step with join condition based on getLinkStatus
function().
<invoke inputVariable="inputVariable"
joinCondition="getLinkStatus(Workflow_Step-to-Web_Service_Step1)
and getLinkStatus(Flow_Step-to-Web_Service_Step1)"
name="Web_Service_Step1" operation="pollResult"
outputVariable="pollLoanFlowResultSoapResponse"
partnerLink="ws_receive_reply" portType="portType">
<target linkName="Workflow_Step-to-Web_Service_Step1"/>
<target linkName="Flow_Step-to-Web_Service_Step1"/>
</invoke>
The flow step equivalent invoke activity.

<invoke inputVariable="Flow_StepInvokeStepInput"
name="Flow_StepInvokeService"
operation="Flow_StepInvokeServiceOperation"
outputVariable="Flow_StepInvokeStepOutput"
partnerLink="Flow_StepInvokeServiceLink"
portType="Flow_StepInvokeServicePortType">
<target linkName="Web_Service_Step-to-Flow_Step"/>
<source linkName="Flow_Step-to-Web_Service_Step1"/>
</invoke>
</flow>

Complete the following steps to export a process model in BPEL format.
To export a process model in BPEL format
1 Open the desired process model in Modeler.

2 From the File menu, select Export Current Process As, then BPEL Process.The Save export
file dialog appears.
3 Click Save. The Exported files dialog appears.


WEBMETHODS MODELER
CHAPTER 11
Generating Process Models
Overview of Process Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
What Modeler Generates for a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Validating a Process Model Before Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Before You Can Execute a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
STEP 1: Generating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
STEP 2: Optionally Adding Logic to Generated Run-time Elements . . . . . . . . . . . . . . . . . . 222
STEP 3: Making the Process Model Available for Monitoring . . . . . . . . . . . . . . . . . . . . . . . 222
STEP 4: Enabling Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

C H A P T E R 11 G e n e r a t i n g P r o c e s s M o d e l s
Overview of Process Generation

After you draw your process model, generate it to have Modeler generate the run-time
elements that will actually execute at run time. To generate the run-time elements,
Modeler uses the information in your process model, such as steps, publish/subscribe
filters, transitions, and conditions. Modeler places the generated run-time elements in the
underlying webMethods platform.
Architecture diagram for process generation
Modeler
Design IS
Server WmModeler
package
IS IS IS
Workflow
Each step in a process model is associated with a specific logical server. Modeler places
the run-time elements associated with a step on the physical server mapped to the logical
server for the step. For Workflow steps only, Modeler also places these run-time elements
on an Associated Server. To place the run-time elements on a server, Modeler accesses the
servers through the Design Server. The Design Server connects to the various servers in
the webMethods platform, as needed, during process generation. As a result, all physical
servers must be running and available when you generate the process model.

What Modeler Generates for a Process Model

What modeler generates depends on whether the step is associated with an Integration
Server, or the step is a Web Service or Workflow step.
Items Generated for Steps Associated with Integration

Servers
The name Modeler gives a generated run-time element and where Modeler places the
generated run-time element on the Integration Server depends on how you define the
properties for the process and for the steps. The following table lists each run-time
element that Modeler generates for steps associated with an Integration Server and
describes how process and step properties affect what Modeler generates:
Type of
Generated item property Property How Modeler uses property during generation
package process Package Name Modeler places all generated run-time
elements for the process model in the
package that you specify. If you specify
a package that does not currently exist,
Modeler creates it.
process Label If you do not specify the Package Name
property, Modeler uses the Label
property as the name of the package to
hold the generated run-time elements.
The Label property specifies the name of
the process model.
process Process Key If the name that Modeler is to use (either
from the Package Name or Label process
property) contains non-ASCII characters
(e.g., if it contains multibyte characters),
Modeler cannot use the name you
specify for the package. In this situation,
Modeler uses the value it defines for the
Process Key property.

Type of
IS folder for process Label Modeler creates an IS folder in the
the process package with the name of the process
model.
process Process Key If Label contains non-ASCII characters
(e.g., if it contains multibyte characters),
Modeler cannot use the name for this
folder. In this situation, Modeler uses the
value it defines for the Process Key
property.
IS folders for step Logical Server Modeler creates one IS folder named for
the logical each logical server referenced in the
servers process model. Modeler places the IS
folders for logical servers in the IS folder
for the process.
Important! The names you define for

logical servers using the webMethods
Administrator should be ASCII. Process
generation can fail on the Integration
Server when logical server names
contain multibyte characters.
trigger step Logical Server Modeler creates one trigger for each
logical server that is referenced in the
process model and places the trigger in
the IS folder for the corresponding
logical server.

Type of
flow services step Label Modeler creates one flow service for
each controlled step. By default,
Modeler gives the flow service the name
of the step, which is specified by the
Label step property.
step Generated The value of the Generated Flow Name step
Flow Name property overrides the default name for
a generated flow service. If you specify
the Generated Flow Name step property,
Modeler uses this name for the name of
the generated flow service instead of the
name of the step, which is specified by
the Label step property.
step Unique ID If the name that Modeler is to use (either
from the Label or Generated Flow Name
step properties) contains non-ASCII
characters (e.g., if it contains multibyte
characters), Modeler cannot use the
name you specify for the service name.
In this situation, Modeler uses the value
it defines for the Unique ID property.
step Service to If you specify the Service to Invoke
Invoke property, when Modeler generates the
flow service for the step, it includes an
INVOKE flow operation to invoke the
service you specify.
If you do not specify the Service to Invoke
property, Modeler generates an empty
flow service.
step Logical Server By default, Modeler places the generated
flow service in the IS folder it creates for
the logical server associated with the
step.

Type of
step Folder The value of the Folder step property
overrides the default IS folder where
Modeler places a generated flow service.
If you specify the Folder step property,
Modeler places the generated flow
service in the IS folder you specify. If the
IS folder you specify does not exist,
Modeler creates the IS folder in the
package for the process model.
process run- step Logical Server Modeler creates one process run-time
time script script for each logical server referenced
in the process model. It places all process
run-time scripts in the config\wmprt
directory of the package.
Sample Process Model and Generated Run-time Elements

The following shows a sample process model and describes the process and step
properties that Modeler uses during process generation.
Sample process model that describes properties for process generation

When the above process is generated, Modeler generates the following run-time elements:
Generated run-time elements for the process model

Package Name property is used for the name of the package.
Generated flow for Step3 is placed in the folder
“FolderProperty_Folder” that was specified on the Folder
property.
Generated flow service for Step2 is given the name

“SpecifiedServiceName” that was specified on the Generated
Flow Name property.
Generated flows for steps that do not use the Folder property
are placed in the folder named for the process model and then
within the folder for the appropriate logical server.
One trigger is generated for each logical server.
Items Generated for Web Service Steps

For Web Service steps, Modeler generates services depending on the Web Service activity:
Receive/Reply, or Invoke.
Web Service Receive/Reply Step

Modeler creates one flow service for each Web Service receive step. Modeler gives the
generated flow the name of the Web Service operation specified by the Operation step
property. This flow is generated to the IS folder, <processname>.<porttypename>. If the Web
Service receive step has one or more matching Web Service reply step(s), the generated
flow will invoke pub.publish:publishAndWait service, otherwise the pub.publish:publish service
will be invoked. The generated flow for a Web Service receive step essentially acts as a
listener for a Web Service invocation. It is not recommended that you modify this flow in
any way. Additional logic should be placed on a separate Flow step.
Web Service Invoke Step

Modeler does not generate flows for Web Service invoke steps. You are required to use
the built-in Assign services to set endpoint binding information before Process Runtime
can perform a Web Service invocation. Depending on the method of endpoint binding
you choose, place the necessary Assign service in the generated flow of any Flow step
prior to the Web Service invoke step. Refer to “Using Dynamic Binding” on page 100 and
the webMethods Built-In Services Reference for further details.

Items Generated for Workflow Steps

For each Workflow step, Modeler generates an implementation module that contains a
workflow. Modeler places the implementation module into a Workflow project.
Workflow items generated for a Workflow step
Workflow Project
Implementation Module An implementation module

can contain one or more
workflows. Modeler generates
an implementation module that
workflow contains a single workflow.
Workflow Step Generation and Multiple Servers

For Workflow steps only, Modeler generates items to two servers:
The physical Workflow server defined through each Workflow step’s logical server
assignment, and
The Associated Server defined through Modeler’s Server Connections dialog. The
Associated Server is a logical IS assigned to the process as a whole. By default,
Modeler assigns a process’s Associated Server to be the Design Server.
Important! Changing the default Associated Server could negatively impact process model
generation. To avoid generation problems associated with changing the default
Associated Server assignment, read “Consequences to Changing the Associated Server”
on page 208.
What Modeler Generates to Servers

The following table lists each run-time element that Modeler generates to both the
physical Workflow Server and the Associated Server for Workflow steps. It also describes
how process and step properties affect what Modeler generates.
Tip! It is recommended that when you supply values for properties that are used for
naming generated run-time elements, that you use only ASCII characters. Although
Modeler can successfully generate run-time elements that have names with multibyte
characters to webMethods Workflow, the webMethods Workflow user interfaces will be
unable to properly display the multibyte characters.

Type of How Modeler uses the property during

Generated item property Property generation
Project step Project If project that you specify in the
Project property does not exist,
Modeler generates it.
process Label If you do not specify the Project
property, Modeler generates a project
and uses the Label process property
for the name of the project.
step Version Modeler places the project (and all
other generated run-time elements
for the step) in the version of the
project that you select.
step Logical Server Modeler places the project that it
generates on the physical
webMethods Workflow server that is
mapped to this logical server.
Implementation step Label Modeler generates an
Module Unique ID implementation module and places it
in the project. By default, Modeler
names the implementation module
ProjectName_Label_UniqueID, where:
ProjectName is the name of the
project
Label is the value of the Label step
property
UniqueID is the value of the
UniqueID step property
step Implementation The value of Implementation Module
Module step property overrides the default
name for the generated
implementation module.
step Logical Server Modeler places the implementation
module that it generates on the
physical webMethods Workflow
server that is mapped to this logical
server.

Type of How Modeler uses the property during

Generated item property Property generation
Workflow step Workflow to Modeler references the workflow you
Invoke specify. If you do not specify the
Workflow to Invoke property, Modeler
generates an empty workflow.
step Label If Modeler generates an empty
Unique ID workflow, Modeler names the
generated workflow
ProjectName_Label_UniqueID, where:
ProjectName is the name of the
project
Label is the value of the Label step
property
UniqueID is the value of the
UniqueID step property
step Logical Server Modeler places the workflow that it
generates on the physical
webMethods Workflow server that is
mapped to this logical server.
Consequences to Changing the Associated Server

It is extremely important that all users who generate a process model have identical
Workflow Logical Server/Associated Server definitions. Keeping the default Associated
Server definition (the Design Server) means all users will have the same definition and
there will be no undesired generation consequences.
If you need to generate Workflow items to a logical IS other than the default Associated
Server (the Design Server), you can change the definition through Modeler’s Server
Connections dialog. However, this must be done on a user by user basis. If different users
have different associations, Workflow run-time elements will generate to the different
servers and the process model will not run as intended.
For details on using the Server Connections dialog, see “Managing Server Connections”
on page 231.

Validating a Process Model Before Generation
Validating a Process Model Before Generation

In some cases, particularly for larger and more complex process models, you may want to
validate the process model before generating it.
To validate a process model
1 If the process model you want to generate is not already open, open it.
2 Select ToolsValidate Business Process.
If Modeler encounters errors when validating the process model, it displays error
messages. The error messages are preceded with in the Implementation
Validation Messages dialog.
For a description of the errors and how to fix them, see “Troubleshooting Process
Generation” on page 216
Before You Can Execute a Process Model

You must take the following actions before you can execute a process that uses your
process model:
STEP 1: Generate the process model.

STEP 2: Optionally, add logic to the generated run-time elements.
STEP 3: Make the process model available for monitoring.
STEP 4: Enable the process model.
STEP 1: Generating a Process Model

You generate the process model using Modeler. When you generate the process model,
Modeler displays messages in the Implementation Generation Messages dialog as it
creates the run-time elements.
To generate a process model
1 If the process model you want to generate is not already open, open it.
2 Select ToolsGenerate Business Process.
If Modeler encounters errors when generating the process model, it displays error
messages. The error messages are preceded with in the Implementation

Generation Messages dialog. If Modeler encounters errors, it does not generate new
or update existing run-time elements.
For a description of the errors and how to fix them, see “Troubleshooting Process
Generation” on page 216.
Regenerating a Process Model

If you have already generated your process model and determine that you need to make
changes, you can make those changes. However, for the changes to be reflected in the
generated run-time elements, you need to generate the process model again.
Note: If you make visual changes, such as adding text, adding notes, or moving lines and
icons around, you do not need to regenerate.
Before You Can Execute a Regenerated Process Model

After updating your process model, take the following actions to update the generated
run-time elements and make the process model available for the PRT to use to execute
processes:
STEP 1: Regenerate the process model. The procedure for regenerating a process
model is the same procedure as when you initially generated the process.
STEP 2: Optionally, add logic to the generated run-time elements.
STEP 3: Make the process model available for monitoring.
STEP 4: Enable the process model if you have not previously enabled it or if you
disabled it.

Changes that Modeler Makes when Regenerating Integration Server Run-time

Elements
This section describes the changes that Modeler makes to the run-time elements that it
generates on an Integration Server. For information about regeneration and the changes to
Workflow steps, see “Changes that Modeler Makes when Regenerating Workflow Run-
time Elements” on page 215.
When you regenerate a process model, Modeler always regenerates the triggers and
process run-time scripts. Changes that Modeler makes to other generated run-time
elements are based on the changes that you make to the process model. The following
table lists changes you can make to your process model and the actions that Modeler takes
when regenerating the run-time elements based on those changes.
Change made to process model How Modeler handles the change during regeneration
Change the ‘Label’ process
property
If the Label process property is Modeler generates a new package using the new
being used for the name of the value of the Label property if the package does not
generated package (i.e., before already exist.
you made the change, the
Label property was the same Modeler does not rename the folder named for the
as the Package Name property) process model. Modeler continues to use the
original value of the Label process property for
this folder.
Modeler moves all generated flow services,
triggers, and process run-time scripts to the new
package.
If a step in the process model uses the Folder
property and the specified folder does not exist in
the new package, Modeler creates the folder in the
new package.
Modeler preserves the old package. The old
package still contains all folders that Modeler
previously generated. Additionally, Modeler
preserves all user-defined data in the package
(folders, flow services, triggers, etc.).
If the Label process property is Modeler makes no change. The folder named for
not being used for the name of the process model continues to use the original
the generated package (i.e., value of the Label process property.
you specified a different value
for the Package Name property)

Change the ‘Package Name’ Modeler generates a new package using the new
process property value of the Package Name property if the package
does not already exist.
Modeler moves all generated flow services,
triggers, and process run-time scripts to the new
package.
If a step in the process model uses the Folder
property and the specified folder does not exist in
the new package, Modeler creates the folder in the
new package.
Modeler preserves the old package. The old
package still contains all folders that Modeler
previously generated. Additionally, Modeler
preserves all user-defined data in the package
(folders, flow services, triggers, etc.).
Change the ‘Label’ step property
If the Label step property is Modeler renames the generated flow service for
being used for the name of the the step to the new value of the Label step
generated flow service (i.e., property.
before you made the change,
the Label property is the same
as the Generated Flow Name
property)
If the Label step property is not Modeler takes no action.

being used for the name of the
generated flow service (i.e.,
you specified a different value
for the Generated Flow Name
property)
Change the ‘Generated Flow Modeler renames the generated flow service for
Name’ property the step to the new value of the Generated Flow
Name step property.
Change the ‘Folder’ step property Modeler moves the generated flow service for the
step to the new folder specified by the Folder step
property.

Change the ‘Service to Invoke’ Modeler regenerates the flow service preserving
step property for a step all previous user-defined and generated logic.
Modeler appends a new INVOKE flow operation
to the end of the preserved logic in the flow
service to invoke the new service specified by the
Service to Invoke step property.
Change the ‘Logical Server’ step
property
If the newly selected logical If the package for the process model does not
server is associated with the already contain a folder for the newly selected
same physical server logical server, Modeler creates a new folder
named for the new value of the Logical Server
property.
Modeler moves all generated flow services and
triggers to the folder named for the newly selected
logical server.
If after the change the old logical server is no
longer referenced in the process model by any
other steps, Modeler removes the trigger and
process run-time script for the old logical server.
It does not delete the folder it generated for the
old logical server.
If the newly selected logical Modeler generates new flow services, trigger, and
server is associated with a process run-time script on the new physical
different physical server server.
Modeler removes the previously generated flow
service from the folder for the old logical server
on the old physical server.
If after the change the old logical server is no
longer referenced in the process model by any
other steps, Modeler removes the trigger and
process run-time script for the old logical server
from the old physical server. It does not delete the
folder it generated for the old logical server.

Delete a step from the process Modeler deletes the flow service that it generated
model for the step from the Integration Server
namespace.
If the deleted step is the only step that runs on a
specific logical server, the deletion of the step also
removes the reference to the specific logical
server. In this case, Modeler also removes the
trigger and process run-time script for the logical
server. It does not delete the folder it generated for
the logical server.
Change the Input/Output Modeler changes the Input/Output variables for
documents for a step the generated flow service.
Modeler preserves all mappings that are
associated with unchanged documents.

Changes that Modeler Makes when Regenerating Workflow Run-time Elements

This section describes the changes that Modeler makes to the run-time elements that it
generates on a Workflow server. For information about regeneration and the changes to
steps associated with an Integration Server, see “Changes that Modeler Makes when
Regenerating Integration Server Run-time Elements” on page 211.
Changes that Modeler makes to the run-time elements that it generates to a Workflow
server are based on the changes that you make to the process model. The following table
lists changes you can make to your process model and the actions that Modeler takes
when regenerating the run-time elements based on those changes.
Change the ‘Project’ or If the project that you specify does not exist,
‘Project’ and ‘Version’ step Modeler generates it.
properties
Modeler generates a new implementation module
in the newly specified project and version.
Note: You must clear the
Workflow to Invoke property If you did not use the Workflow to Invoke property
before you can change the to specify an existing workflow in the new project,
Project property. Modeler generates an empty workflow for the
new project.
Modeler preserves the old project,
implementation module, and workflow in the old
project.
If you added any logic to the old implementation
module or workflow, Modeler does not move it to
the newly created implementation module or
workflow.
Change the ‘Label’ process Modeler makes no change. If your current
property and/or the ‘Label’ step implementation module and/or workflow have
property names based on the old label fields, they will
continue to use the same names.
Change the ‘Logical Server’ step Modeler generates all run-time elements as
property and the new logical needed to the new physical server.
server is associated with a
different physical server Modeler preserves all old generated run-time
elements on the old physical server.
Change the ‘Implementation Modeler renames the generated implementation
Module’ step property for a step module to use the new name that you specify.

Clear the ‘Workflow to Invoke’ Modeler generates an empty workflow.
step property for a step
Modeler updates the generated implementation
module so that it invokes the newly created
empty workflow.
Modeler preserves the old workflow.
Change the ‘Workflow to Invoke’ Modeler updates the generated implementation
step property for a step module so that it invokes the newly specified
workflow.
Modeler preserves the old workflow.
Delete a Workflow step from the Modeler preserves all generated information for
process model the deleted step.
Troubleshooting Process Generation

The following lists the errors that you might encounter when generating a process model,
their causes, and the actions to take to resolve the errors.
Important! If Workflow steps inadvertently generate to multiple IS servers, make sure that
all users that have generated the model have the same Associated Server assignment. For
details on this issue, see “Consequences to Changing the Associated Server” on page 208.
AND/OR is not set in condition for node “stepname”.

Cause: The condition on a transition from the indicated step, stepname, contains multiple
conditions. However, you did not specify a value in the AND/OR column to indicate how
the conditions work together.
Response: Open the properties for the transition and edit the conditions to fill in the
AND/OR column.

Cannot determine a valid starting step.

Cause: Modeler cannot determine the step that starts your process. A start step is a step
that:
Has input that is set to a subscription of at least one external document
Has no incoming transitions from controlled steps

A process model must have at least one start step.
Response: Ensure the inputs for the start step of your process model has a subscription to
an external document.
External documents not defined on the server.

Cause: A step in your process model has input that is a subscription to a document or
output that is a publication of a document. However, the subscription/publication
document no longer exists. The IS or Broker document has been deleted from the
Integration Server.
Response: Either recreate the deleted document or update the process model to remove the
need for the deleted document.
Invalid Complex Join for step “stepname”.

Cause: The Join Type property for the indicated step, stepname, is set to Complex. However,
no complex join expressions were created for the join.
Response: Do one of the following:
Create complex join expressions for the join. To create the complex join expressions,
open the properties for the step and re-select Complex for the Join Type property.
Modeler displays the Join List dialog. Use the Join List dialog to specify the complex
join expressions.
Change the Join Type property to specify another type of join.
Invalid condition expression.

Cause: Your process model contains a transition condition that is not valid. A condition is
not valid if it contains an empty Field Name, Operator, or Comparison Value/Field.
Response: Open the properties for the transition and edit the conditions to correct any
invalid conditions.

Invalid inputs for step “stepname”.

Cause: You have a referenced process in your process model that transitions to the
indicated step, stepname. All transitions leading to step stepname are from referenced
processes. When all transitions leading to a step are from referenced processes, the step
cannot have inputs.
Response: Delete the inputs from step stepname.
Invalid Join for step “stepname”.

Cause: The indicated step, stepname, has a value for the Join Type property. However, the
join is not valid because the step has only:
One input transition and zero input documents
One input document and zero input transitions
The Join Type property is only valid when a step has:
Two or more input transitions
Two or more input documents
At least one input transition and at least one input document

Response: Remove the value for the Join Type property for the step.
Invalid outputs for step “stepname”.

Cause: The indicated step, stepname, transitions only to a referenced process. You have
defined outputs for step stepname. A step that transitions only to a referenced process
cannot have outputs associated with it.
Response: Delete the outputs from step stepname.
Invalid stop step “stepname”.

Cause: Modeler determined that the indicated step, stepname, is a stop step for your
process model. This step has outputs defined for it. Stop steps cannot have outputs.
Response: Delete the outputs from the stop step.
Invalid Web Service activity type for start step “stepname”.

Cause: A Web Service invoke or reply step is used as a start step in your process model.
Response: Ensure that the Web Service start step is a receive activity type.

Invalid Web Service receive step “stepname”. Cannot have multiple receive steps with the same port
type and operation.
Cause: webMethods platform uniquely identifies a Web Service receive step with in a
process model by its port type and operation. A process model with multiple Web Service
receive steps implementing the same operation violates this unique constraint.
Response: Each Web Service receive step within a single process model must implement a
different operation.
Nested process “ProcessName” publications don’t match following subscribing nodes

subscriptions.
Cause: The indicated referenced (or nested) process, ProcessName, in your process model
transitions to a step in your process model. The publications from the referenced process
do not match the subscriptions of the step.
Response: Update the referenced processes publications and/or the steps subscriptions so
that they match.
Nested process “ProcessName” subscriptions don’t match preceding publishing nodes

publications.
Cause: A step in your process model transitions to the indicated referenced (or nested)
process, ProcessName. The publications for the step do not match the subscriptions of the
referenced process.
Response: Update the publications of the step and/or the subscriptions of the referenced
process so that they match.
No external document is assigned to start step “stepname”.

Cause: Modeler determined that the indicated step, stepname, is a start step for your
process model. However, the input of this step does not have a subscription of an external
document. Start steps must subscribe to at least one external document.
Response: Update the inputs to the step, stepname, to add a subscription to an external
document.
No logical server assigned to step “stepname”.

Cause: The Logical Server property of the indicated step, stepname, has no value. Each
controlled step in your process model must be assigned to a logical server.
Response: Update the Logical Server property of the step, stepname, to specify a logical
server.

Please specify the type of join for step “stepname”.

Cause: The indicated step, stepname, has one of the following:
Two or more input transitions
Two or more input documents
At least one input transition and at least one input document

However, you did not specify the Join Type step property to indicate how the multiple
inputs should be joined.
Response: Update the step properties to specify the Join Type property.
Process model must be saved before it can be generated.

Cause: You have not saved the process model that you are about to generate.
Response: Save the process model; then generate the process model again.
Step “stepname” is duplicate. Please either rename the step or choose a different name for the flow
service.
Cause: You have more than one step in your process model named stepname and have not
used the Generated Flow Name step property for the steps to give unique names for the flow
services that Modeler is to generate.
Response: Do one of the following:
Rename your steps so that their names are unique.
Use the Generated Flow Name step property to identify unique names for the flow
services that Modeler is to generate.
Unable to connect to logical server “LogicalServerName”.

Cause: The physical Integration Server that maps to the indicated logical server,
LogicalServerName, is not currently running.
Response: Ensure all physical servers that are associated with the logical servers your
process model references are running.
Web Service reply step “stepname” does not have a matching receive step.
Cause: A Web Service reply step in your process model does not have a matching Web
Service receive step.
Response: Ensure that your process model contains one and only one Web Service receive
step with the same Web Service interaction, port type and operation as the Web Service
reply step.

Warning Messages
In the following cases, process generation is allowed, but it may cause runtime errors.
Found multiple Web Service replies to the Web Service Step “stepname”. Only the first reached reply
will be returned to the caller and subsequent replies will be ignored.
Caution: Ensure that the process model is designed in such way that only one Web Service
reply step is reached for any given runtime instance.
Operation “operation name” for Web Service step “stepname” expects output message type
“message type”, but output is not assigned.
Caution: Data returned from the Web Service operation will not be available for use by the
process model steps downstream.
Operation “operation name” for Web Service step “stepname” expects input message type “message
type”, but input is not assigned.
Caution: You will not be able to assign input data to the Web Service operation.
Web Service interaction and/or operation not defined on step “stepname”.

Caution: Process Runtime will not be able to run this step.
Web Service receive step “stepname” does not have a matching reply step.
Caution: If the process model is invoked as a BPEL process, no data will be returned to the
invoker.

STEP 2: Optionally Adding Logic to Generated Run-time

Elements
After generating the process model, you might want to add logic to the flow services
generated to Integration Servers or implementation modules and workflows generated to
webMethods Workflow servers.
Important! Never make changes to the generated triggers.
Adding Logic to Flow Services

After generating the process model, you might need to map data into the services that are
invoked by steps in your process model. You can also add logic to the services that your
steps invoke. For guidelines on how to map data and/or add logic to services, see
Chapter 7, “Working with Flow Step Logic”.
Adding Logic to Implementation Modules and Workflows

After you generate the process model, complete the logic for generated implementation
modules and workflows. For details, see Chapter 7, “Working with Workflow Step
Logic”.
STEP 3: Making the Process Model Available for Monitoring

To be able to monitor your processes using the webMethods Monitor, you need to move
the process model to the Process Audit Log. To do so, perform the following procedure.
To update a process model for monitoring
1 Start Modeler and connect it to the Design Server.

2 If the process model you want to be able to monitor is not already open, open it.
3 Select ToolsUpdate Model for Monitoring.
Note: The Update Model for Monitoring option is disabled if you have not defined an
Process Audit Log. To define an Process Audit Log, from the webMethods Server
Administrator, select the JDBC Pools option from the Settings menu of the navigation
area to associate the alias of a JDBC pool with the ProcessAudit functional alias.

STEP 4: Enabling Process Models
STEP 4: Enabling Process Models

After generating the process model and updating it for monitoring, the process model is
disabled until you enable it. The PRT will not use the process model for the execution of a
process until you enable the process model. You enable the process model using
webMethods Monitor.
To enable a process model
1 Open webMethods Monitor that is running on the Design Server.

2 Click the Process Models option from the Process menu of the navigation area.
3 Locate the process model you want to enable from the list of process models. The
process model will be in the Unused Process Models section of the screen because no
instances of this process model have been executed.
4 In the row for the process model that you want to enable, click No in the Enabled
column. When prompted to confirm your action, click OK.


WEBMETHODS MODELER
CHAPTER 12
Managing Process Models
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Updating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Versioning the Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Deleting Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Exporting and Importing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Managing Logical Servers and Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

CHAPTER 12 Managing Process Models
Overview
Tasks involved in managing process models include updating, regenerating, versioning,
deleting, importing/exporting, and managing logical servers and server connections
associated with a model. For details on monitoring running process models, see the
webMethods Integration Platform Logging and Monitoring Guide.
Updating Process Models

You can make visual updates to a process model without needing to regenerate it.
Examples of visual changes to a process model include moving transition lines or steps
around the canvas (without changing the order in which steps occur), or adding notes or
groups to the process model. Since these types of changes are not registered by the PRT,
you do not need to regenerate the model after making them.
Examples of changes that require you to regenerate the process model for the changes to
take effect include:
Changing the order in which steps execute
Changing the properties of steps or the process model
Changing transition types or transition conditions
Changing the services or workflows that a step invokes
Changing step inputs or outputs
Changing the logical servers associated with steps

For details on regenerating a process model, see “Regenerating a Process Model” on
page 210.
Note: If you make changes to the user-defined service that the generated flow service
invokes, you do not need to regenerate the process model. For details on editing services,
see Chapter 7, “Adding Logic to Steps”.

Versioning the Process Model
Versioning the Process Model

Modeler enables you to save a process model as a new version. When you save a process
model as a new version, Modeler creates an entirely separate process model using the
active process model as the template. This function is similar to a “Save As” function in a
word processing program. To Modeler, there is no connection between the new model
and the template model. The function is helpful if you need to create a new process model
similar to an existing model.
To Create a New Process Model by Saving it as a New Version
1 From an active process model, choose FileSave as New Version.

2 Enter a new name for the process model and choose OK.
3 Modify the new process model as necessary.
After you save a process model as a new version, the new model retains most of the
settings of the template process model, with a few important differences:
The process model’s Package property changes to the name of the new process model.
This ensures that when the new process model is generated, items are generated to a
different underlying location than the template model.
The steps’ Generated Flow Service and Folder properties revert to their default state,
which is empty.

Deleting Process Models

Modeler’s delete function deletes the process model definition from Modeler. It does not,
however, delete generated components (if they exist) from their respective servers. If you
want to delete generated items, you must do so manually.
To Delete an Existing Process Model
1 From an active process model, choose FileDelete Process. The Delete Process window
appears.
2 Browse to the process model that you want to delete and select it. Click Delete.
3 When prompted to confirm your action, click OK.

Exporting and Importing Process Models
Exporting and Importing Process Models

When you export or import a process model, the process model definition is moved from
one server to another, not the model’s generated elements (e.g., services, documents,
workflows, triggers, etc.). To have an imported process model run on a new server, the
generated elements must be moved manually, and then the model should be regenerated.
There are two export and import formats available.
Complete Model. This is the most commonly used export/import format. Use this format
to transfer a complete process model between different servers. When you export as a
Complete Model, a file of your choice is written and exported. The exported file itself
is not intended for use or modification. When the model is imported elsewhere, all
aspects of the model remain completely intact.
Portable Format. This format is provided for advanced users (e.g., programmers) who
might want to convert a process model to another format by modifying the exported
file. It also enables the loading of processes created with a third-party format. When
you export as Portable Format, a simple XML file is exported. After export, some of
the process model’s definitions (groups, referenced processes, etc.) are lost.
Note: The simple XML file created when exporting as Portable Format contains the process
model definition in BIML (Business Integrator Processing Language) format. For a
technical description of the BIML format, refer to the XML schema document at
webMethods\Modeler\etc\BIMLschema.xsd.
Note: For details on migrating process models from Business Integrator 4.6 to Modeler
6.0.1, see Appendix C, “Migrating 4.6 Process Models to Modeler 6.1”.
Exporting Process Models

You can export an active process model, or you can export multiple processes
simultaneously. See the following procedures.
To Export an Active Process Model
1 Start Modeler and open the process model that you want to export.
2 Select FileExport Current Process asComplete Model.
Note: If you want to export the model as Portable Format, choose FileExport Current
Process asPortable Format.

3 In the Save Export File dialog, browse to the directory where you want to save the
exported process model.
4 In the File Name dialog, type a file name for the exported process model. Click Save.
5 Modeler displays a confirmation message. Click OK.
To Export Other (or Multiple) Process Models
1 From the Modeler main menu, select FileExport Other Processes asComplete Model
.
Note: If you want to export the model as Portable Format, choose FileExport Other
Processes asPortable Format.
2 In the Select Processes For Export dialog, browse to and select the process model(s)
that you want to export.
3 Click Export.
4 In the Select Directory dialog box, browse to and select the directory where you want
to save the exported process model(s).
5 Click Select Directory. Modeler displays a confirmation message. Click OK.
Importing Process Models
To Import a Process Model
1 From the Modeler main menu, choose FileImport.

2 In the Select Import File dialog, browse to the process model that you want to import
and click Open.
3 If prompted to confirm the import, choose Yes.
4 After import, Modeler displays a confirmation message. Choose OK.

Managing Logical Servers and Server Connections
Managing Logical Servers and Server Connections

The following sections describe how to manage logical servers and server connections.
Managing Logical Servers in the Process

Modeler enables you to replace a model’s logical servers on a step by step basis, or, if you
need to replace all instances of a logical server in a process, on a process-wide basis. You
replace logical servers on a step by step basis by selecting a different logical server from
the step’s Logical Server property. To replace all instances of a logical server in a process
with another logical server, use the following procedure.
To Replace all Instances of a Logical Server in a Process Model

2 From Modeler’s main menu, select ToolsReplace Logical Server in Process.
3 From the Find Logical Server menu, select the logical server to be replaced.
4 From the Replace With menu, select the new logical server.
5 Click Replace All. A message appears stating how many server instances were
replaced.
6 If you are done replacing logical servers in the process, click Close.
Managing Server Connections

Modeler’s Server Connections dialog displays information about defined logical servers.
The dialog displays information about all logical servers that have been established for
the Design Server to which the Modeler is connected. These logical servers are defined
through webMethods Administrator. For instructions, see Chapter 3, “Configuring
webMethods Modeler”.

The Server Connections dialog displays:

All logical servers defined for the Design Server to which the Modeler is connected
The corresponding physical server addresses
Server connection statuses

In addition, you can take the following actions from the Server Connections dialog:
Connect to/disconnect from a logical server
Change the process’s Associated Server assignment
Important! This is the logical IS on which Workflow steps generate and execute.
Changing the default Associated Server could negatively impact process model
generation. To avoid generation problems associated with changing the default
Associated Server assignment, read “Consequences to Changing the Associated
Server” on page 208.
Refresh logical server information. For example, if logical servers have been added,
changed, or removed through webMethods Administrator, the Refresh option
prompts Modeler to retrieve the latest server information.
Use the following procedure to access the Server Connections dialog.
To Access the Server Connections Dialog
1 From Modeler’s main menu, select ViewServer Connections.

WEBMETHODS MODELER
CHAPTER 13
Moving Process Models to Production
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Identifying the Items You Need to Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Moving Items that Reside on Integration Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Moving Items that are Stored in Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Moving Items that Reside on webMethods Workflow Servers . . . . . . . . . . . . . . . . . . . . . . . 245
Moving Process Models to Production Process Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . 246

CHAPTER 13 Moving Process Models to Production
Overview
This chapter describes information to consider when you are ready to move your process
model and related information from your development environment to your production
environment.
In your development environment, you want to:
Create your process model.
Generate the process model to create the run-time elements in the underlying
systems.
Add additional data mapping and logic to the run-time elements, if necessary. For
example, map data into services, add logic to services, and/or design a human
workflow.
Test the business process to ensure it works as expected.
When you are satisfied that your business process runs as expected, move your process
model information from the development environment to the production environment.
To move the process model, you move items from your physical servers in your
development environment to physical servers in your production environment.
Servers and Moving Processes to Production

For you to be able to successfully move your business process, you must have a one-to-
one correspondence between the logical servers in your development environment and
the logical servers in your production environment. For example, if you have the logical
servers Accounting, Finance, and Purchasing in your development environment, you must also
have the logical servers Accounting, Finance, and Purchasing in your production environment.
Example of logical and physical servers in development vs. production environments
Development Production
Accounting
Finance
Purchasing Accounting Finance Purchasing
IS IS IS IS
All logical servers map to a single physical server. Each logical server maps to a different physical server.
The underlying physical servers do not have to match. For example, in the development
environment, all three logical servers (Accounting, Finance, and Purchasing) might map to a

Identifying the Items You Need to Move
single physical server. In your production environment, you might have the same three
logical servers mapped to three separate physical servers.
Items that You Need to Move

To move a business process from a development environment to a production
environment, you need to move the following items:
Run-time elements that Modeler generated based on the steps and transitions in your process
model. These are packages, flow services, triggers, process run-time scripts, Workflow
projects, and Workflow implementation modules. When you generated the process
model, Modeler created these items in the underlying Integration Servers and
webMethods Workflow server in the development environment. You need to move
these items to the appropriate Integration Servers and webMethods Workflow servers
in your production environment.
Items that your process model references. These are items that you referenced in steps and
conditions on transitions in your process model. Examples of referenced items are
services, publishable documents, Trading Networks profiles, Trading Networks
document types, Trading Networks document attributes, and/or workflows.
These items reside in the underlying Integration Servers, Trading Networks systems,
and webMethods Workflow servers in the development environment. You need to
move these items to the appropriate Integration Servers, Trading Networks systems,
and webMethods Workflow servers in your production environment.
Process model audit information. Your process model resides in the Modeler repository
in the development system. If you updated the process model for monitoring in the
development environment, the process model also resides in the Process Audit Log in
the development system. To be able to monitor your process models in the production
environment, the process models must reside in the Process Audit Log of the
production system.

From Modeler, you can generate a deployment list to identify many of the items you need
to move.
When creating the deployment list, Modeler uses information from the last time the
process model was generated. For example, it lists information about the physical servers
it last generated information to. If you have changed the logical-to-physical mappings
since the last generation, the changes will not be reflected in the deployment list.

Information the Deployment List Contains

In the deployment list, items are grouped by logical servers. The following table identifies
the information that Modeler lists for each logical server.
Type of server
associated with steps Information in deployment list
all Host name and port of the physical server to which the
logical server is mapped
Integration Servers Package name for the process
Trigger that Modeler generated for the logical server
Process run-time script for the logical server
Generated flow services
Correlation services
Documents that your process model references
Services that steps in your process invoke

Note: The deployment list contains only the specific service
identified by the Service to Invoke step property. The service
you identify using this property might invoke other
services, require IS specifications, IS document types, etc. It
is your responsibility to determine the items that your
services require and include them in the releases of the
packages you move to the production server.
Workflow Servers Project name for the process
Implementation modules generated for a step

Workflows that were generated or referenced by steps
Documents that your process references

The following shows a sample deployment list.
Sample deployment list
Name of the process model
Name of a logical server
Items on the logical server

“Accounting”
The name of the step with

which a service is
associated is listed in
parentheses

Generating the Deployment List

Perform the following procedure to generate the deployment list. If you want the
deployment list available for later viewing, you can save the deployment list in either .txt
or .html format. If you save the list in .txt format, use Microsoft WordPad to view the .txt
file.
Important! Before you can generate the deployment list, you must first generate the process.
To create the deployment list, Modeler using information that is saves during process
generation.
To
To generate the deployment list
1 From Modeler, select ViewDeployment Information.

2 To save the information to view later, click either Save to text file or Save to HTML file.
Moving Items that Reside on Integration Servers

To move items that reside on Integration Servers, use the package replication feature of
the Integration Server. To use package replication, from the webMethods Server
Administrator on the development servers, select Publishing from the Package menu to
access the Create Release screen. Use the Create Release screen to create distributable
releases of the packages that contain the items that you want to move. Then publish the
releases to the production servers. On the production servers, install the inbound
packages. For more information about how to create releases of packages and publish and
subscribe to those packages, see the webMethods Integration Server Administrator User’s
Guide .
When you move the items, you must take into consideration the logical-to-physical server
mappings. For example, assume you have a logical server named Accounting. In the
development environment, the Accounting server is mapped to a specific physical server
(e.g., devel.company.com:5555). In the production environment, the Accounting server is
mapped to a different physical server (e.g., acctg.company.com:5555). You need to move
the Accounting server items from the physical server in the development environment
(devel.company.com:5555) to the physical server in the production environment
(acctg.company.com:5555).

Moving Integration Server items from development servers to production servers
Accounting
=
Logical server s= Finance Accounting Finance Purchasing
Purchasing
IS IS IS IS
Accounting Items Accounting Items
Finance Items Finance Items
Purchasing Items Purchasing Items
Physical servers = devel.company.com:5555 acctg.company.com:5555 fin.company.com:5555 purch.company.com:5555
The items on Integration Servers that you need to move are run-time elements that
Modeler generated (PRT scripts, flow services, and triggers) and other items (e.g.,
services, publishable documents, etc.) that you referenced in your process model.
Moving Modeler Generated Run-time Elements

From the development Integration Servers, create releases of the packages containing the
generated run-time elements. Then publish the releases from the development Integration
Servers to the production Integration Servers.
Locating the Items to Include in the Release of the Package

The first step in creating the releases of packages is identifying the items you want to
move. To help you identify the items to include, you can generate a deployment list from
the Modeler. For instructions, see “Generating the Deployment List” on page 238.
Modeler places all generated run-time elements into a single package. You specify the
name of the package using the Package Name property for the process model. If you did not
specify the Package Name property, by default, the package is given the same name as your
process model. Use the deployment list to identify the generated run-time elements.
By default, Modeler places all run-time elements within a single folder in the package. The
folder has the same name as your process model. However, you can override the location
that Modeler places the generated flow services by using the Folder property for a step.
When you use the Folder property, you specify a specific folder within the package where
you want Modeler to place the generated flow services for a step.

The following table lists each generated run-time element and where you can locate the
item within the package based on whether the Folder property was used.
Default or
Run-time element Folder property Where Modeler places the run-time element
process run-time Either In the config\wmprt directory of the package.
scripts
triggers Either Modeler places triggers in the
ns/Model/LogicalServer folder where:
Model is the name of the process model
LogicalServer is the name of the logical

server with which the trigger is associated
flow services Default Modeler places flow services in the
ns/Model/LogicalServer folder where:
Model is the name of the process model
LogicalServer is the name of the logical

server with which the flow service is
associated
Used Folder Modeler places the flow service in the folder
property that you identified using the Folder property.
Tip! If you use the default location for all steps, all generated flow services and triggers
will be located in a folder that has the same name as the process model.
For more information about the items that Modeler generates and where Modeler places
these items, see Chapter 11, “Generating Process Models”.

Creating Releases Based on Your Logical-to-Physical Server Mappings

How you create the releases of the packages that you need to publish depends how
closely the logical-to-physical server mappings in your development environment mirror
the mappings in the production environment.
Mappings in the Development Environment Mirror the Production Environment Exactly

When the logical-to-server mappings in both environments mirror each other, you have
the same number of physical servers in both the development and production
environments and the logical-to-physical mappings are equivalent.
Example of development environment that exactly mirrors the production environment
Accounting Finance Purchasing Accounting Finance Purchasing
IS IS IS IS IS IS
In this situation, the move of the generated run-time elements is straight forward.
To move generated run-time elements when logical-to-physical mappings are the same
For each physical server in your development environment:

1 Create a release of the entire package for the process model.
2 After you have created the releases, publish and install the releases in the equivalent
physical server in the production environment.

Mappings in the Development Environment Do Not Mirror the Production Environment

The following shows examples of when the logical-to-physical mappings do not mirror
each other:
The number of physical servers in the development and production environments are
different.
Example of different number of physical servers
Accounting
Finance
Purchasing Accounting Finance Purchasing
IS IS IS IS
The logical-to-physical server mappings are not equivalent.
Example of logical-to-physical server mappings that are not equivalent
Accounting Accounting
Finance Purchasing Finance Purchasing
IS IS IS IS
When the logical-to-server mappings in the development and production environments

do not mirror each other, you need to make releases of packages that contain only a
portion of the package. The portion of the package for each release is the items associated
with a specific logical server. For example, if you have three logical servers named
Accounting, Finance, and Purchasing, you create a three releases of packages 1) for the items
associated with the Accounting logical server, 2) one for the items associated with the Finance
logical server, and 3) one for the items associated with the Purchasing logical server. Then
you can publish each release to the appropriate physical server in your production
environment.

To move generated run-time elements when logical-to-physical mappings are different
For each logical server:

1 Create a release of the portion of the package for your process model. You need to
include:
The process run-time script for the specific logical server. The process run-time
scripts are in the config\wmprt directory within the package. The name of the
script contains the name of the logical server. When creating the release, select the
appropriate run-time script.
The generated flow services and triggers associated with the specific logical server.
The flow services and triggers are located in the
ns/ProcessModelName/LogicalServerName folder where ProcessModelName is
the name of the process model and LogicalServerName is the name of the logical
server. When creating the release, select all files listed in this folder. Additionally,
include ns/ProcessModelName and ns/ProcessModelName/node.idf.
The manifest.v3 file.
Sample of selecting flow services and trigger information for a release
In addition to all items in

ns/ProcessModel/LogicalServer,
include ns/ProcessModel and
ns/ProcessModel/node.idf

If you used the Folder property to specify where to place generated flow services for
one or more steps, locate the generated flow services in the folders you specified and
include them in the release, as well. Be sure to include only the generated flow
services that are associated with the logical server for which you are making a release
of the package.
2 After you have created the releases, publish and install the releases in the equivalent
physical server in the production environment.
Moving Referenced Items

You also need to move the Integration Server items that you referenced in the steps and
conditions of your process model. These items include:
Services invoked by steps in the process model
Correlation services that your process model uses
IS document types or specifications used by services
Publishable documents that are input to or output from steps
IS documents or document types used in conditions on transitions

To help you identify some of the referenced items, you can generate the deployment list.
For more information, see “Generating the Deployment List” on page 238.
To move the referenced items, create releases of the packages that contain all the services,
IS document types, etc. that your process model references and publish them to the
appropriate physical servers in your production environment.

Moving Items that are Stored in Trading Networks
Moving Items that are Stored in Trading Networks

If your process model references items in Trading Networks, you will need to move those
items from your development environment to the production environment. To move
items that reside in Trading Networks, use the Trading Networks export and import
feature. The types of items your process model might reference from Trading Networks
include:
Profiles that you reference in conditions on transitions
TN document types that are input to or output from a step
Attributes associated with the TN document types
To
To move items stored in Trading Networks
1 From the development environment, use the Trading Networks Console to access the
Export Data dialog (from the File menu), which allows you to select the items you
want to export. Trading Networks creates an .xml file that contains the exported
items.
2 Move the .xml file to a location to which the production Trading Networks has access.
3 Use the Trading Networks Console in the production environment to access the
Import Data dialog (from the File menu).
4 From the Import Data dialog, select the .xml file you created in the development
environment. This allows you to import the data from the development environment
to your production environment.
For more information about how to export data from and import data to Trading
Networks, see the webMethods Trading Networks User’s Guide manual.
Moving Items that Reside on webMethods Workflow Servers

If your process model includes Workflow steps, you will need to move the
implementation modules, workflows, and all supporting items from your development
webMethods Workflow server to your production webMethods Workflow server. You
can determine the information you need to move by generating the deployment list. For
instructions, see “Generating the Deployment List” on page 238.
During your testing phase, in the webMethods Workflow environment you should have
created a deployment that contains the implementation modules, workflows, and all
supporting items in your development environment.
To move your tested deployment to your production environment, use the Workflow
Generator.

To move your tested Workflow deployment to your production environment
1 Access the Workflow Generator from the Tools menu of the Workflow Designer that is
connected to the webMethods Workflow server in your development environment.
2 Using the Workflow Generator, identify the webMethods Workflow server to which
you want to move the workflows. This server is known as the deployment server.
Specify the webMethods Workflow server in your production environment for the
deployment server.
3 Select the Install Deployment option from the Install menu to copy the previously
generated and tested deployment to your production environment.
The Workflow Generator will guide you through moving the Workflow items from
your development environment to your production environment.
For more information about deploying workflows, see the webMethods Workflow User’s
Guide.
Moving Process Models to Production Process Audit Log

To be able to monitor business processes in your production environment, the process
models must reside in the Process Audit Log in the production environment. For this
purpose, only the process audit log database needs to be moved. It is not necessary to
import the process model itself to the production environment.
The following tables must be exported:
WMCUSTOMFIELDDEFINITION
WMPROCESSDEFINITION
WMPROCESSIMAGE
WMSTEPDEFINITION
WMSTEPTRANISITONDEFINITION
Note: Scripts used to export the necessary tables are available on the webMethods
Advantage website.

WEBMETHODS MODELER
APPENDIX A
Tuning Performance and Quality of Service
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Quality of Service vs. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Configuring the System to Meet Your Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
STEP 1: Configure the Territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
STEP 2: Configure Process-Level Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
STEP 3: Optionally Modify Step Pipeline Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
A Note About Referenced Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

A P P E N D I X A Tu n i n g P e r f o r m a n c e a n d Q u a l i t y o f S e r v i c e
Overview
Service Pack 1 for webMethods Modeler 6.0.1, coupled with Service Pack 2 for Integration
Server 6.0.1, adds settings to the Modeler and PRT that let you tune performance and
quality of service levels to meet specific needs. This appendix provides a framework for
tuning these dispersed settings as a cross-functional unit, and for leveraging them for
your environment.
Backwards Compatibility
The performance and quality of service default settings are such that, out-of-the-box, all
process models created prior to the implementation of the new features (that is, prior to
the application of Modeler 6.0.1. SP1 and Integration Server 6.0.1 SP2), work exactly as
they did before. Specifically, all process models default to the highest quality of service—
the behavior prior to the existence of these settings.
Quality of Service vs. Performance

Quality of service is a measure of transactional reliability, visibility, and control. Generally,
high quality of service is achieved by persisting data as a process runs. Performance is a
measure of the time it takes a process instance to complete (latency), or, number of
instances completed per time period (throughput). Generally, high performance is
achieved by using volatile data storage (RAM) while a process runs. Each attribute is
achieved at the expense of the other. By definition, the higher the quality of service, the
lower the performance, and vice versa.
Maximum Quality of Service: Minimum Performance

When operating in a maximum quality of service (minimum performance) environment:
Benefits
Processes are guaranteed. They:
Automatically recover at the appropriate step in case of system failure; i.e., the
process is guaranteed to run to completion
webMethods Monitor provides maximum visibility and control. Use Monitor to:
View process status (Started, Suspended, Failed, Completed)
View step status (Completed, Started, Failed/Error, Waiting)
Suspend, resume, resubmit, or stop the process

Configuring the System to Meet Your Needs
View errors and activity messages

Edit and resubmit the step pipeline
Costs
Each process takes longer to complete, and/or fewer instances complete per time
period.
Maximum Performance: Minimum Quality of Service

When operating in a maximum performance (minimum quality of service) environment:
Benefits
Processes complete more quickly, and/or more instances complete per time period.
Costs
Process instances are not guaranteed. They:
Do not automatically recover in case of server failure; i.e, if a server fails, the
process does not run to completion.
There is no visibility or control via webMethods Monitor. You cannot:
View process status (Started, Suspended, Failed, Completed)
View step status (Completed, Started, Failed/Error, Waiting)
Suspend, resume, resubmit, or stop a process
View error or activity messages
Edit or resubmit the step pipeline
Configuring the System to Meet Your Needs

The level of performance and quality of service that you require depends on your business
needs. The settings are highly configurable. You can fine-tune your environment to a
quality of service or performance extreme (as in the previous scenarios), or to somewhere
in between.
For example, you might specify that a process be able to automatically recover at the last
process transition document, but not at the exact step of failure. Or, you might completely
disable automatic recovery yet enable manual step resubmission. You might need to
view/control the details of all steps, specific steps only, or no steps, but the process in
general.

Configuration Overview
The performance and quality of service settings are found on the Modeler and the PRT
home page and apply to three distinct levels of the environment: the PRTs in the territory,
processes, and individual steps. The choices that you make for the territory determine
how you can configure processes, and process settings determine how you can configure
steps. The following table summarizes the order of steps for tuning performance/quality
of service.
Step Description Perform this on... See page...

1 Configure the territory. PRT home page 250
2 Configure process-level settings. Modeler: 256
Process Model
Options
Process Model
Properties
3 Optionally change step pipeline Modeler Step Properties 269
logging.
STEP 1: Configure the Territory

Some choices that you need to make when configuring the territory include:
Whether to use a central or distributed Process Tracking Store
Which database to use for the Process Tracking Store

If using a distributed Process Tracking Store, which server should be the Process
Completion Tracking Server
Overview of Tuning the Territory

You tune the territory by tuning the PRT configuration settings of each integration server
in the territory.
Important! It is important that you tune the settings on each server consistently, so that the
territory functions as an interconnected unit. Step 5 of the following procedure explains
what is meant by consistent tuning.

To Tune The Territory
1 Start an integration server.

2 Open the PRT home page (http://localhost:5555/WmPRT).
3 Tune the settings using the following table for reference.
Setting Description Default

Central Check this box if you want to use a central (vs. On. The territory
Process distributed) Process Tracking Store. The Process is set up for
Tracking Tracking Store is where internal process transition central Process
Store documents are stored. For a comparison of the Tracking Store.
two store types, see “Choosing Central vs.
Distributed Process Tracking Store” on page 254.
Note: If you have a single IS environment, choose a
central Process Tracking Store.


Process Check this box if you would like this server to be Off. No server is
Completion the designated Process Completion Tracking designated as the
Tracking Server in the territory. This server tracks process default Process
Server completion in a distributed Process Tracking Store Completion
environment. For details, see “Choosing a Process Tracking Server.
Completion Tracking Server” on page 255.
Note: This option does not apply and should be
ignored when using a central Process Tracking
Store.
Important! A territory should contain only one
Process Completion Tracking Server.
Database Maximum number of times to try to connect to the 1000
Connection Process Tracking Store database.
Retries
Database How frequently to retry connection to the Process 5 seconds
Connection Tracking Store database.
Retry Time
Interval (sec)
Database How frequently the PRT removes information 600 seconds
Cleanup from the Process Tracking Store database.
Interval (sec)
Guidelines: The default (600 seconds; 10 minutes)
should be optimal for most situations and for
amply-sized databases. Clean the database
frequently enough to avoid constraining the size
limit, and not so frequently to cause excess
performance strain (e.g., you would not want to
clean the database every 5 seconds).


Associated The JDBC pool alias for the Process Tracking Store Identical to the
Pool Alias database. Process Audit
Log Pool Alias
Changing the default: To specify that Process
Tracking Store information be stored in a database
other than the Process Audit Log database:
1 Run (in your database editor) one of the
scripts provided to create the tables. Run the
script that corresponds to your database. The
scripts are located in the /config directory
under the WmPRT package:
tables-oracle.sql or
tables-sqlserver.sql
tables-db2.sql
2 In the Server Administrator, create a JDBC
pool that points to the database schema
containing these tables.
Note: Instructions for setting up JDBC pools
are provided in the webMethods Integration
Server Administrator’s Guide, “Configuring the
Server” chapter, “Configuring the JDBC
Connection Manager” section.
3 On the PRT home page, select the new JDBC
pool alias from the drop down list.
Join Queue The maximum length of time to wait between 10 seconds
Lock processing multiple join inputs received
Expiration simultaneously.
(sec)
Important: This is a fail-safe setting that should
rarely need to be used, nor the default modified. If
you have extremely high transaction volume,
however, you might increase it slightly.
Process Lock The maximum length of time to wait between 10 seconds
Expiration processing multiple process status changes
(sec) received simultaneously.


Step Lock The maximum length of time to wait between 10 seconds
Expiration processing multiple step inputs received
(sec) simultaneously.
4 After modifying any default values, click Submit to save changes.
Note: Clicking the Default button causes the PRT to revert to the default values.
5 Repeat steps 1-4 for all PRTs in a territory, ensuring values are tuned consistently. For
example, if using a central Process Tracking Store, ensure all servers have designated
a central Process Tracking Store and that each points to the same Associated Pool
Alias. Similarly, if using distributed Process Tracking Store, ensure all servers have
designated a distributed Process Tracking Store and that each server points to a
different Associated Pool Alias. If using a distributed Process Tracking Store, be sure
to assign only one Process Completion Tracking Server per territory.
6 Reload the WmPRT package, or restart the integration server.
Choosing Central vs. Distributed Process Tracking Store

The PRT uses internal process transition documents to pass control of execution from one
step to the next. These documents contain internal run-time data that tell the PRT what
has happened in the process so far, and what the next step is. The PRT publishes this data
to various servers via the Broker. When a server receives these documents, the server
temporarily stores them in a database until they are no longer needed. Specifically, the
server stores the data to an area called the Process Tracking Store. Various servers can store
process transition documents in either a central database location, or to a database
designated to each server.
Central Process Tracking Store

If you choose a central Process Tracking Store, all servers in the territory persist process
transition documents to a centralized database.
Use Case
Centralized process tracking is best used when:
The connection to the Process Tracking Store database is very reliable, and/or
Processes do not span geographically dispersed servers

Effects
The maximum possible performance level is decreased; that is, Volatile Tracking
mode is unavailable in a centralized, multi-server environment (although it is
available in a single-server environment). Volatile tracking may have a problem in
clusters (for non-optimized locally and processes with splits or joins). It will work for
both distributed and single server environments if you do not use clusters. For a
distributed environment, you will have to change the WMPRT home page to set
Central Process Tracking Store to off and Set one (and only one) of the servers to be a
tracking server. For details, see “Using Volatile Tracking” on page 262.
Distributed Process Tracking Store

If you choose distributed Process Tracking Store, each server in a territory persists process
transition documents to a different database.
Use Case
Distributed process tracking is best used when:
Connections to the Process Tracking Store database are unreliable, and/or
Processes span geographically dispersed servers
Effects
You can tune performance to a maximum level; that is, you can override persistence to
the Process Tracking Store for Volatile Tracking mode (RAM). For details, see “Using
Volatile Tracking” on page 262.
You need to choose a Process Completion Tracking Server. See “Choosing a Process
Completion Tracking Server”.
Choosing a Process Completion Tracking Server

In a central Process Tracking Store environment, each PRT can easily determine when a
process completes because this information is stored in a central database. However, in a
distributed Process Tracking Store setup, this information is distributed among several
databases and no server innately tracks a process’s completion. To be able to monitor
process completion in a distributed Process Tracking Store setup, you must choose a
single Process Completion Tracking Server to track this information. The server monitors
the Broker process thread count to determine when a process completes.
Important! Be sure to assign only one Process Completion Tracking Server per territory.

Single Server Environments

If your environment consists of only one integration server, you should choose a central
Process Tracking Store database. Single server environments may use Volatile Tracking
mode (for increased performance) described on “Using Volatile Tracking” on page 262.
STEP 2: Configure Process-Level Settings

The performance/quality of service settings at the process-level are geared to let you fine-
tune exactly:
How much process visibility and control you need in the Monitor. You choose exactly
how much information to persist to the Process Audit Log.
Whether certain phases of process execution can run in volatile mode (for faster
performance), or whether they need to be guaranteed (for greater reliability).
The general steps in process performance/quality of service tuning are:
Step Description
1 Choose global default process settings.
2 Tune individual process model settings.
Step 1: Choose Global Default Process Settings

The global setting that pertains to performance/quality of service is the Modeler Steps
Enable Resubmission option. This option specifies the default choice for step pipeline
logging, when pipeline logging is available (see the note below). That is, it specifies
whether you will typically want to log the step pipeline. You log a step’s pipeline when
you need to view complete step status details in Monitor, and when you need the ability
to resubmit the step.
If Steps Enable Resubmission is enabled, PRT by default logs each step’s pipeline. If it is
disabled, PRT by default does not log the pipeline of any step. You can easily override the
default on a step-by-step basis using step properties. That is, if the default is enabled (log
all step pipelines), you can turn logging off for specific steps. If it is disabled (log no step
pipelines), you can turn it on for specific steps. Therefore, you should configure this
option according to typical usage.
Note: Modeler makes selective step pipeline logging available when you set the model’s
Logging Level to Process and all steps. For details, see “Process and all steps” on page 261.
Note: Out-of-the-box, the Steps Enable Resubmission option is enabled.

To Change the Default Step Pipeline Logging Value
1 Start the Modeler.

2 Choose ToolsOptions.
3 Check or uncheck the Steps Enable Resubmission option to enable or disable it.
Important! Changing this parameter affects steps added to the process going forward. It
does not affect steps already in existence.
Tip! The step property that the Steps Enable Resubmission option corresponds to is
Step 2: Tune Individual Process Settings

You tune individual process settings by tuning process model properties. The procedure
for specifying process model properties is described in “Basic Steps in Process Model
Creation” on page 51 of this guide.
The following table summarizes the process model properties that impact performance
and quality of service. The descriptions in the table are only an overview; refer to the
section in “For details see...” for more comprehensive information.

Process
Model
Property Description Default For details, see...
Logging Determines the level of persistence to the Process “Choosing a
Level Process Audit Log, and hence the level of and All Logging Level”
visibility and control in webMethods Steps on page 260
Monitor.
Logging Levels are:
None
Errors Only
Process Only
Process and Start Steps

Volatile Specifies whether the integration servers Enabled “Using Volatile
Tracking hosting the process should store process Tracking” on
transition documents in the Process page 262
Tracking Store or in RAM. If this
property is enabled, servers store
documents in RAM. If it is disabled,
servers store documents in the Process
Tracking Store.
Volatile Specifies whether the Broker should Enabled “Using Volatile
Transition store process transition documents to Transition
Documents hard disk or in RAM. If this property is Documents” on
enabled, Broker uses RAM. If it is page 264
disabled, Broker uses disk.
Note: If the step is a Workflow step,
Broker always stores process transition
documents to hard disk, thus
guaranteeing Workflow’s receipt of the
document.

Process
Model
Property Description Default For details, see...
Optimize Specifies whether servers should publish Enabled “Optimizing the
Locally process transition documents between Process Locally”
execution of adjacent steps on the same on page 264
IS. A simpler method of passing control
between steps on the same IS is to
directly invoke them. This decreases
Broker traffic and increases performance.
If enabled, servers use the direct invoke
to pass control between steps on the
same IS. If disabled, servers publish
process transition documents between
execution of adjacent steps on the same
IS.
Local Specifies whether to save correlation IDs Enabled “Managing
Correlation on the local server that created them, or Correlation IDs
whether it is necessary to broadcast them in a Distributed
to different servers in the process. Environment”
on page 267
It might be necessary to broadcast these
IDs when 1) the process spans multiple
servers and 2) the territory uses a
distributed Process Tracking Store.
Broadcasting IDs ensures that if the step
that needs the correlation ID is on a
different server than that which created
the ID, the ID is received.
When enabled, correlation IDs are not
broadcast; when disabled, they are
broadcast (through the Broker) to all
servers in the process.
Note: If a process does not use correlation
services, this property is not applicable
and can be ignored.

Important! The defaults described above apply to new process models (i.e, process models
created and generated after the application of Modeler 6.0.1 Service Pack 1 and
Integration Server 6.0.1 Service Pack 2). The defaults for models created and generated
prior to the application of the service packs are modified to ensure models have the same
settings as before the application of service packs. This means that these models have
maximum quality of service default settings. The defaults for previously created models
are: Logging Level = Process and All Steps, Volatile Tracking = Disabled, Volatile
Transition Documents = Disabled, Optimize Locally = Disabled, Local Correlation =
Disabled.
Choosing a Logging Level

The process logging level determines how much information the PRT persists to the
Process Audit Log, and hence determines process visibility and control. The following
table describes the logging levels and their effects on quality of service. Keep in mind that
as the logging level increases, performance decreases.
Logging Level Description Effect

None The PRT does not log process You cannot view the process
status (Started, Suspended, through Monitor nor resubmit any
Failed, Completed) or step status of its steps.
(Completed, Started, Error,
Waiting).
Errors only Upon error, the PRT logs process You can view failed process status
status and the failed step pipeline. through Monitor and resubmit at
the failed step only.
Process only The PRT logs process status, but You can view process (but not
not step status. If a step fails, the step) status in the Monitor; you
failed step pipeline is logged. can resubmit the process (at a
failed step) only in the event of
step failure.

Logging Level Description Effect

Process and The PRT logs process and start You can view process and start
start steps step status, as well as the start step status; you can resubmit the
step pipeline. If a step fails, the process at the start step or at a
failed step pipeline is logged. failed step, in the event of step
failure.
Process and all The PRT logs the status of the You can view the status of a
steps process and all of its steps. process and all of its steps; you can
resubmit the process at any step
which has logged a pipeline. You
control which steps log the
pipeline.
When the Process and all steps
logging level is selected, Modeler
enables use of the Enable
Resubmission step property. Out-
of-the-box, all step pipelines are
logged (i.e. the Enable Resubmission
property is enabled).
To change the global default Enable
Resubmission value, see “Step 1:
Choose Global Default Process
Settings” on page 256.
To override a specific step’s log
pipeline value, see “STEP 3:
Optionally Modify Step Pipeline
Logging” on page 269.
Logging Level Effect on Document Field Logging

“Choosing Fields to Log For Monitoring” on page 138 explains how to choose document
fields to log to the Process Audit Log.
Modeler makes document field logging available in conjunction with all of the following
logging levels:
Process Only
Process and Start Step


Modeler prohibits document field logging in association with the remaining levels:
None
Errors only
Important! Keep in mind that logging document fields means persisting information and
thus impacts performance/quality of service. When setting or changing your level of
performance/quality of service, do not forget to consider the document logging settings.
For example, if you decide you need greater performance and change the Logging Level
from Process and All Steps to Process Only, remember that any document logging
parameters are still in effect until you manually change them.
Using Volatile Tracking

For a review of the Volatile Tracking property, see “Volatile Tracking” on page 258.
The state of Volatile Tracking impacts:
The reliability of the audit trail exposed through Monitor
Effect on Monitor Audit Trail

In Volatile Tracking mode, the PRT stores process and step iteration information in server
RAM rather than in the Process Tracking Store. Therefore, when a server fails in volatile
mode, iteration data is lost. Upon server recovery, the PRT executes steps as if for the first
time. If you have chosen a Logging Level in which the PRT logs step data (see “Choosing
a Logging Level” on page 260), the step iteration count will be inaccurate.
Example Scenario
Let’s examine the impact of enabling Volatile Tracking with the following process. In this
process:
Optimize Locally is enabled (and all steps execute on a single server)
Logging Level is Process and all steps
Server fails at step 4

Effect: When the server recovers, the process begins again at step 1. Steps 1, 2, and 3
execute again. Though it is the second iteration of these steps, the previous iteration data
stored in RAM was lost when the server failed. Therefore, upon recovery, the PRT
inaccurately records step iteration as the first iteration.
Note: The process recovers at step 1 rather than the failed step because the process has
enabled Optimize Locally (and all steps are on a single server). These factors are discussed in
detail in “Optimizing the Process Locally” on page 264.
Implications: It is harder to determine and address the negative effects of server failure
without being able to see in the Monitor accurate iteration count, and how much work
might have been duplicated.
Summary of Using Volatile Tracking
If you do not need an accurate step iteration trail in the Monitor and/or are not logging
information to the Process Audit Log, using this property increases performance without
undesired consequences. If however you need an exact audit trail and/or are logging step
information to the Process Audit Log, the cost of the inexact audit trail might outweigh
the performance benefits. Of course the costs of enabling this property depend on server
failure. If servers do not fail, it is safe to use Volatile Tracking.

Using Volatile Transition Documents

For a review of the Volatile Transition Documents property, see “Using Volatile Transition
Documents” on page 264.
The state of the Volatile Transition Documents property impacts:
Whether the process can automatically recover in case of server or Broker failure
Effect on Automatic Recovery

If you enable the Volatile Transition Documents property, the Broker stores all process
transition documents in Broker RAM. This means that if the server on which a step is
running fails, or the Broker fails, the process cannot automatically recover. The only
means you have of recovering the process instance is to manually resubmit steps through
the Monitor. The ability to resubmit steps depends on whether the step pipeline was
logged to the Process Audit Log. (See “Choosing a Logging Level” on page 260.)
Summary of Using Volatile Transition Documents

Storing process transition documents in Broker RAM enhances process performance.
However, the ability to automatically recover the process is lost. The only way to recover
a process instance upon server or Broker failure is to use the Monitor resubmit feature,
which depends on step pipeline logging. If neither the server nor the Broker fail, it is safe
to enable Volatile Transition Documents.
Optimizing the Process Locally

For a review of the Optimize Locally property, see “Optimize Locally” on page 259.
The state of the Optimize Locally property impacts:
The step at which the process automatically recovers in case of server failure
Effect on Where the Process Automatically Recovers

Assuming that a process can automatically recover (see “Using Volatile Transition
Documents” on page 264), it can recover only at the most recent process transition
document stored on the Broker. Since Optimize Locally determines when process transition
documents are published, it in effect determines where the process automatically
recovers.
Optimize Locally determines when process transition documents are published.
There are two possibilities:
Between steps executing on different servers (Optimize Locally is enabled), or
Between each and every step in the process regardless of server identity (Optimize
Locally is disabled)

Optimize Locally determines where the process automatically recovers.

There are two possibilities:
At the step associated with the most recent process transition document (Optimize
Locally is enabled), or,
At the precise step of failure (Optimize Locally is disabled). (If Optimize Locally is
disabled, the step of failure is the step associated with the most recent process
transition document.)
Example of a Process with Enabled Optimize Locally Property

To understand the impact of Optimize Locally on automatic recovery, see the following
example process.
The first step executes on Server 1 and the remaining steps execute on Server 2.
The server fails at step 4.

Effect: The PRT publishes process transition documents between steps 1 and 2 only.
Therefore, when the server fails at step 4, the process recovers at step 2.
Implications: Processes that recover past the point where the process failed might perform
work twice. In this example, the work performed during steps 2 and 3 is repeated.
Example of Process that Does Not Optimize Locally

Let’s examine the same scenario with Optimize Locally disabled. Again,
The first step executes on Server 1 and the remaining steps execute on Server 2.
The server fails at step 4.
Effect: The PRT publishes process transition documents between each step. When the
server fails at step 4, the process recovers at step 4.
Implications: The risk of work being duplicated is greatly decreased. Although it is possible
that upon recovery the process repeats some work done at the beginning of step 4 (before
the server failed), the maximum amount of work that can be repeated is decreased.
Summary of Optimize Locally
The possibility of duplicating work is the biggest risk when using Optimize Locally. How
detrimental work duplication would be probably depends on the specific process.
For example, you might not want to risk duplicating work for processes that store,
synchronize, or correlate data. For processes that do less significant work, the
performance benefits might outweigh the risks.

Of course, the risks associated with Optimize Locally depend on server failure. If a server
does not fail, it is safe to enable Optimize Locally.
Managing Correlation IDs in a Distributed Environment

For a review of the Local Correlation property, see “Local Correlation” on page 259.
The state of the Local Correlation property determines:
Whether different servers in the process are guaranteed to receive correlation IDs
The state of the Local Correlation property is only relevant when all of the following are
true:
Process uses at least one correlation service
Process is distributed over different servers
Territory uses distributed Process Tracking Store (see “Choosing Central vs.
Distributed Process Tracking Store” on page 254)
Note: The remainder of this section applies to processes that meet the above criteria. For a
review of when processes require correlation services, see “Working with Correlation
Services” on page 152.
Local Correlation Property’s Effect on Correlation ID Receipt

Distributed process tracking causes correlation IDs to be stored in different databases.
When a step outputs a correlation ID (via a correlation service), the PRT stores the ID to
the Process Tracking Store database specific to the server. If the step that needs the ID is
located on a different server than that which output the ID, you need to broadcast
correlation IDs. That is, you need to disable Local Correlation.

Example Scenario
In the following process:
The “processJob” step receives a document that needs to be correlated with the
process. The step generates to Server 2.
The “routerScheduleRequest” step invokes a correlation service to output the
correlation ID that “processJob” needs. The step generates to Server 1.
Effect: The PRT publishes the “routerScheduleRequest” correlation ID to the Broker.

Server 2 receives it and stores it in its Process Tracking Store database. Server 2 PRT
correlates the “processJob” document to the process.
Note: There is a slight delay between the PRT’s broadcast of the correlation ID to the
Broker, and the remote servers receiving it. It is possible that you could design a process in
such a way that a step receives the document that it needs to correlate before the server
receives the ID from the Broker.
If the Sample Process Had Not Broadcast Correlation IDs: The PRT would have begun a new
instance of the process at “processJob” step.

STEP 3: Optionally Modify Step Pipeline Logging
Designing the Model so That Broadcasting Is Not Necessary: Broadcasting correlation IDs to the
Broker (i.e, disabling Local Correlation), slightly detracts from performance. To avoid this,
you can instead design the process so that the steps publishing and the steps needing
correlation IDs are on the same server. In this case you could enable Local Correlation and
still be ensured documents correlate to the process successfully.
Note: Using the previous model as an example, you would assign the “ProcessJob” and
“routerScheduleRequest” steps the same physical server.
Summary of Local Correlation

It is important to consider how you will correlate documents into a process. You can do so
either by disabling Local Correlation or by process model design.
STEP 3: Optionally Modify Step Pipeline Logging

You might want some steps to have a pipeline logging setting other than the default. (The
default setting is described in “Step 1: Choose Global Default Process Settings” on
page 256.) Use the following procedure to change pipeline logging for individual steps.
To Modify Step Pipeline Logging for Individual Steps
1 Start the Modeler and open a business process.

2 Select the step whose pipeline logging you would like to change.
3 In the Step Properties panel, check or uncheck Enable Resubmission to enable or disable
step pipeline logging.
A Note About Referenced Processes

If you are running a process that invokes another process, the PRT follows the rules
below:
The PRT uses the parent process quality of service/performance settings to run the
parent process.
The PRT uses guaranteed process transition documents to transition into and out of
the child process.
The PRT uses the child process quality of service/performance settings to run the
inner steps of the child process.


WEBMETHODS MODELER
APPENDIX B
Guidelines for Working with Referenced Processes
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Referenced Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Referenced Process Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Design-Time Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Using the Hot-Swappable Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

APPENDIX B Guidelines for Working with Referenced Processes
Introduction
As described in “Referenced Process Steps” on page 89, steps within a process that invoke
a separate business process are known as referenced process steps. There are some special
design-time and run-time considerations to keep in mind when working with referenced
processes. This appendix provides information and guidelines to help you design process
models that contain referenced processes, and also to monitor running business processes
containing referenced processes.
Referenced Process Overview

The business process containing a referenced process is distinguished from other business
processes in that, at run time, more than one business process is intended to run. The
parent process is triggered when the Broker receives the start step’s subscription document.
The child process (or referenced process), which exists and runs independently of the
parent process, is triggered by its own subscription document.
Design Time
In designing business processes with referenced process steps, you should:
Understand (and complete as necessary) the additional properties that Modeler
provides for referenced process steps; these are defined in “Referenced Process Step
Properties” on page 273. These properties reflect the special design-time and run-time
considerations for processes containing referenced processes.
Understand the special design-time guidelines described in “Design-Time
Guidelines” on page 275, including:
How to assign inputs and outputs to referenced process steps; this process is
slightly more involved than the process described for general steps, in Chapter 6,
“Assigning Inputs and Outputs to Steps”.
When to assign a return join type to a referenced process step.
Run Time
When you monitor a business process that contains a referenced process, you can:
Monitor both the parent process and the child process, if both have started running.
Use the Monitor enable/disable toggle to swap one running referenced business
process for another, if the referenced process step’s Hot-Swappable property is enabled.
You enable or disable the Hot-Swappable property at design time. For details on
understanding and using the hot-swappable feature, see “Using the Hot-Swappable
Feature” on page 277.

Referenced Process Step Properties

In addition to the step properties available to all steps (described in Chapter 5, “Adding
Steps to a Process Model”), Modeler provides additional properties for referenced process
steps.
Property Definition
Process Reference The name of the child process to run. When you establish a
referenced process step, Modeler automatically populates the
Process Reference property with the name of the child process
inserted. If you would like to change the child process to run,
select a new process from the Process Reference drop down list.
Use caution when replacing one child process with another. See
“Related Considerations” on page 277 for details.
Hot-Swappable Controls the number of business processes that are triggered per
received subscription document, and enables one referenced
business process to be swapped for another at run time.
If enabled, all possible business processes will be triggered per
received subscription document, and swapping of referenced
business processes at run time is possible.
If disabled, only the business process identified in the Process
Reference property (above) is triggered. For details on hot-
swapping, see “Using the Hot-Swappable Feature” on page 277.

Property Definition
Return Join Type For referenced process steps whose child process contains more
than one possible end step, this join type designates the logic by
which the Modeler proceeds out of the referenced process step to
the next step in the parent process. This join type is necessary only
when a child process contains more than one possible end step,
and when the referenced process step is not the last step in the
parent process model. For an example of this type of child process,
see “Child Process (PO2 Process)” on page 276.
The types of joins are: AND, OR, XOR, and COMPLEX. For
complete definitions, see “Join Types” on page 89. If you assign a
step a return join type of AND (or COMPLEX with ANDs), you
must also assign the step a Return Timeout property, described
below.
Note: The Return Join Type property functions in the domain of

downstream transitioning; that is, how the referenced process step
proceeds to the next step; by contrast, the regular Join Type
property is a function of upstream transitioning; that is, how
upstream steps transition into a given step (including referenced
process steps).
Return Timeout Assigns a timeout value to referenced process steps whose return
join type is AND (or COMPLEX with ANDs); you do not need to
specify this property for any other return join type.
The Return Timeout Value is the time (in ms) by which the return
join type conditions must be met before the timeout transition
from the referenced process step will be taken. The timer begins
counting once the first return join condition is met (e.g., the first
input arrives).
Note: When you assign a Return Timeout value to a step, you must
also create a Timeout transition to another step, as described in

Design-Time Guidelines
Design-Time Guidelines
Use the following guidelines when designing business processes containing referenced
process steps.
Assigning Inputs and Outputs to Referenced Process Steps

When assigning inputs and outputs to referenced process steps, keep the following in
mind:
The input(s) that you assign to a referenced process step should be of the same
document type as the child process’s starting subscription document(s). (Instance
names, however, can be different.)
The available inputs to a referenced process step are (as with all steps) limited to those
documents used as output upstream in the (parent) process.
See the following parent and child processes for illustration:
Parent Process (PO1 Process)

Child Process (PO2 Process)
Looking at PO1 Process, we can see that a step upstream from the referenced process
step (PO2 Process), in this case Step 2, outputs an identical document type as the child
process’s starting subscription document (docType_auditCode). Therefore, Modeler
makes this document available as input to the referenced process step (PO2 Process).
Modeler automatically assigns outputs to referenced process steps such that all
publications of the end step(s) of the child process become the outputs of the
referenced process step. Using the above models again, notice that the child process’s
ending publication documents are docType_quoteRec and docType_projUpdate.
Modeler automatically populates the referenced process step’s outputs with these
documents. The outputs to a referenced process step are not editable.
Ensure your child and parent process outputs stay synchronized. If a child process’s
end step publications change after being established within a parent process, the
parent process does not automatically detect the change. Use Modeler’s Sync Outputs
feature to synchronize parent/child outputs. The Sync Outputs option is available from
the right-click menu of a referenced process step and on a referenced process step’s
Inputs/Outputs dialog.
Tip! If the Sync Outputs option is enabled, outputs need to be synchronized. If the Sync
Outputs option is disabled, the outputs should already be synchronized.

Using the Hot-Swappable Feature
Ensure child and parent process inputs stay synchronized. If a child process’s starting
subscriptions change after being established within a parent process, the parent
process’s referenced process step inputs must be manually updated to reflect the
child.
Related Considerations
Use caution when replacing one referenced process step with another. If the outputs
of the new child process are different than the previous process’s, all transition
conditions connecting the referenced process step to steps downstream will be lost. In
addition, once you replace one referenced process step with another, the action
cannot be undone.
Tip! For an alternate method of substituting one referenced process for another (in a
run-time environment only), you can use the hot-swappable feature, described in
“Using the Hot-Swappable Feature” on page 277.
Assigning a Return Join Type

Review the Return Join Type property from “Referenced Process Step Properties” on
page 273 to know when to assign a return join type to a step. Using the previous process
models for illustration, the referenced process step of PO1 Process (“PO2 Process”)
requires a return join type because the child process contains more than one end step and
the parent process continues after the referenced process step.
Using the Hot-Swappable Feature

At design time, you designate whether a particular referenced process step is hot-
swappable. At run time, a step’s hot-swappable status determines two things:
Whether, upon receipt of a given subscription document:
a All processes beginning with the document are triggered, or
b Only the specific child process identified in the referenced process step’s Process
Reference property is triggered
Whether referenced processes can be swapped at run time

If a Referenced Process Step is Hot-Swappable

When the child process’s subscription document is received, all business processes
that begin with that subscription document are triggered. Note that this is the default
behavior of Modeler and the PRT; it is only when a process contains referenced
process steps that you can limit the processes to be triggered to a single child process.
At run time, you can use the Monitor to swap one running child process for another,
as long as both processes are triggered by the same subscription document type.
To hot-swap, in Monitor:
a Disable the current child process (and all child processes triggered by the same
subscription document)
b Enable the new child process
Important! When hot-swapping, be careful that you disable all running processes with the
starting subscription document in question. Also, make sure that you enable only the
process to run in place of the child process. If you inadvertently leave more than one
process (with a given starting subscription document) enabled, all enabled processes will
run.
Note: Hot-swapping does not in any way alter the design of a parent or child process
model. Therefore, the process model picture does not reflect the hot-swapping, even
though it has occurred.
For details on using webMethods Monitor to enable and disable business processes, see
the webMethods Integration Platform Logging and Monitoring Guide.
If a Referenced Process Step is Not Hot-Swappable

When a child process’s triggering document is received, only the process identified in
the referenced process step’s Process Reference property runs. For a review of this
property, see “Referenced Process Step Properties” on page 273.
At run time, you cannot swap one running child process for another.

WEBMETHODS MODELER
APPENDIX C
Migrating 4.6 Process Models to Modeler 6.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Basic Steps in Process Model Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Ensuring the Model is 6.1-Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

APPENDIX C Migrating 4.6 Process Models to Modeler 6.1
Introduction
This appendix is for clients who maintain process models from Business Integrator
version 4.6 and who would like to import 4.6 models into Modeler 6.1. This appendix
outlines the basic concepts and steps in 4.6-to-6.1 process model migration.
Overview
When you migrate a 4.6 process model to Modeler 6.1, the design of the model is perfectly
preserved. That is, all steps, transitions, groups, subprocesses, referenced processes, notes,
and annotations remain intact in Modeler 6.1. In addition, the migration utility makes
some adjustments to the model’s settings to reflect the difference in functionality between
Business Integrator 4.6 and Modeler 6.1. However, additional manual adjustments to the
model are necessary before it is fully functional on the 6.1. platform and with your specific
setup.
Before you begin the export/import process, you should understand the differences in
functionality between Business Integrator 4.6 and Modeler 6.1. The following table
summarizes these major differences and how the migration utility handles them.
BI 4.6 and Modeler 6.1 Differences and How Migration Handles Them
BI 4.6 Modeler 6.1 Migration Notes

Servers Are Servers Are In Modeler 6.1, implementation systems no
Assigned via Assigned via longer exist. Instead, all steps are assigned a
Implementation Logical Server logical server to designate where step logic
Systems Assignments should generate and execute. When a 4.6 process
model is migrated, the migration utility uses a
step’s (or task’s) implementation system name to
generate a name for a 6.1 step’s logical server.
After migration, you must manually edit these
logical server names so that each step is assigned
a valid logical server. For details, see “Assign
Valid Logical Servers to Each Step” on page 283
of this appendix.
Steps Types Discreet Step In Modeler 6.1, there are three categories of step
Assigned via Types types: Flow, Web Service, and Workflow. In 4.6,
Implementation these discreet step types did not exist. During
Systems migration, the migration utility converts all 4.6
steps associated with a Workflow
implementation system into Workflow steps. All
other steps become flow steps. For a review of
Modeler 6.1 step types, see “Step Functions and
Step Types” on page 85 of this guide.

Overview

External Group Publications In Modeler 6.1, external groups are used purely
Transitions and as visual aid. Steps within external groups and
Designate Subscriptions transitions to/from external groups are aids that
Publications and are Assigned make it easier to conceptualize the phases of a
Subscriptions to Steps business process, but are themselves outside the
scope of the business process; at run time,
external groups (and their steps and transitions)
are meaningless.
In Business Integrator 4.6, documents sent to
external groups represented publications;
documents received from external groups
represented subscriptions. In Modeler 6.1,
publications and subscriptions are assigned to
steps themselves, rather than through external
group transitions.
The migration utility converts all 4.6 publications
and subscriptions (as implied by external group
transitions) to step publications and
subscriptions. As part of the migration process,
you should check all 6.1 step inputs and outputs
(including publications and subscriptions) to
ensure they are accurate and complete. For more
information, see “Check the Integrity of Step
Inputs and Outputs” on page 283 of this
appendix.


Transition Transition In Modeler 6.1, you assign each transition to be
Conditions Conditions one of several possible types, including Normal,
Assigned to Assigned to Retries Exceeded, Timeout, Error, and Else. You
Steps (Tasks) Transitions/ place transition conditions (such as transitioning
Existence of based on the value of a field in a document) on
Transition Normal transition types.
Types
In Business Integrator 4.6, transition types did
not exist, but could be implied through transition
conditions that were placed on steps (tasks)
themselves.
During migration, the migration utility attempts
to preserve all transition conditions to be
compatible with Modeler 6.1. This involves
converting some 4.6 transition conditions to
transition types. Depending on the design of the
4.6 transition conditions, some conditions may
not be preserved. You should carefully check the
integrity of migrated transitions (and their
conditions) and make any necessary adjustments.
For important details, see “Check the Integrity of
Transitions and Transition Conditions” on
page 283 of this appendix.
Basic Steps in Process Model Migration

The basic steps in 4.6-to-6.1 process model migration are as follows:
1 From Business Integrator 4.6, use the export function to export the process model. For
instructions, see the Business Integrator User’s Guide 4.6.
2 In Modeler 6.1, use the import function to import the process model. For instructions,
see “Importing Process Models” on page 230 of this guide.
3 Inspect the migrated process model and make necessary adjustments. For details, see
“Ensuring the Model is 6.1-Ready” on page 283 of this appendix.

Ensuring the Model is 6.1-Ready
Ensuring the Model is 6.1-Ready

Before attempting to run a migrated process model on the 6.1 platform, use the following
as guidelines for a 6.1 integrity check.
Assign Valid Logical Servers to Each Step

The migration utility uses a step’s (or task’s) implementation system name to generate a
name for a 6.1 step’s logical server. You need to edit these settings so that each step is
assigned a valid logical server. You assign logical servers via step properties, described in
“Flow Step Properties” on page 67 of this guide. For details on replacing all instances of a
logical server within a process, see “Managing Logical Servers and Server Connections”
on page 231.
Note: The migration utility sets an uncontrolled step’s logical server to empty, since these
steps do not need to be associated with servers.
Ensure All Documents in the Model Exist on the 6.1 Platform

The migration utility preserves all 4.6 document names in the 6.1 model. Make sure these
documents exist on the appropriate 6.1 logical servers before running the business
process.
Check the Integrity of Step Inputs and Outputs

The migration utility converts 4.6 model inputs and outputs (pipeline data) into 6.1 model
inputs and outputs. In addition, 4. 6 publications and subscriptions become 6.1
publications and subscriptions. Check the integrity of all inputs, outputs, publications,
and subscriptions and make any necessary adjustments.
Check the Integrity of Transitions and Transition Conditions

As explained in the last table row on page 282, the migration utility attempts to preserve
all 4.6 transition conditions to be compatible with Modeler 6.1. You should inspect
migrated transitions and transition conditions to ensure they are designed as intended.
Use the following information for reference.
Migration of Typical Transition Conditions

Most 4.6 transition conditions are converted to an equivalent transition condition in the
6.1 model. While in 4.6 conditions were assigned to a step, in 6.1 they are assigned directly
to a transition (specifically, a Normal transition). The migration should preserve all
transition condition logic.

Migration of Trading Networks “Status”-Based Transition Conditions

Modeler 6.1 provides transition types, including Normal, Retries Exceeded, Timeout,
Error, and Else transitions. To reflect this in the migrated model, the migration attempts to
convert transition conditions that reflect these types (e.g., Error, Retries Exceeded, etc.)
into a 6.1 transition type whenever possible. Specifically, the 4.6 transition conditions
based on Trading Networks “Status” are those that migration attempts to convert to 6.1
transition types, as follows:
This 4.6 TN “Status” Condition Becomes this 6.1 Transition Type

RetryCount Retries Exceeded
UnexpectedDoc None. This Status condition is not preserved
during the migration. You must manually
re-create this condition after migration.
Timeout Timeout
Exception Error
Note: For a detailed review of 6.1 transitions, see Chapter 8, “Creating Step Transitions” of
this guide.
If a 4.6 Step Has TN “Status” Conditions and Other Conditions

If a 4.6 step has TN “Status” conditions and other conditions, the migration does not
convert the TN “Status” condition to a corresponding transition type; however, all other
conditions should be preserved as usual. You must manually create a transition type to
correspond to the lost TN “Status” transition condition.
If a 4.6 Step Has More than One TN “Status” Condition

If a 4.6 step has more than one TN “Status” condition (and no other conditions), the
migration converts only the first TN “Status” condition to a 6.1 transition type. You must
manually create 6.1 transition types for any lost TN “Status” transition conditions.

Index
Index
Numerics subscribing to IS documents from 115

4.6 process model migration 280 use during process run time 29
Business Process Execution Language (BPEL) 32
business process management
A
and webMethods Modeler 17
activity messages
definition 17
PRT service that creates and logs 150
AND joins
C
and return join types 274
definition 89 canvas
forming 25 definition 41
run-time guidelines 171 working with grid settings 41
use with transition conditions 171 Central Process Tracking Store
annotations to process model defined 251, 254
notes 27 PRT setting 251
text 27 changeProcessStatus service
architecture description and usage 150
design time for process 20 changing
process generation 200 a process’s run-time status 150
run-time for processes 28 a step’s user-defined service 149
webMethods platform and webMethods Modeler 17 consequences to changing Associated Server 208
Associated Pool Alias, PRT setting 253 logical servers in process 231
Associated Server Modeler repository storage mechanism 47
and process generation 206 one referenced process step for another, caution 277
changing assignment 232 step icons 105
consequences to changing 208 updating process models 226
definition 206, 232 child process, definition 272
authentication, Modeler repository 21 collapsing several steps into single icon 25
Complete Model import/export format, defined 229
Complex join
B
and return join types 274
BIML schema document 229 definition 89
BPEL4WS 32
controlled steps
branches
and internal groups 26, 178
definition 25, 163 definition 23
forming 163
items generated for 28
Broker
controlling
and webMethods Modeler architecture 18 a process’s run-time status 150
description 18
appearance of groups 180
publishing IS documents to 125
display of transition types 175

Index
inputs/outputs display 137 start steps 85

logical server connection state 232 subprocesses 90
transition colors 175 subscriptions to steps 110
visual properties of steps 105 transition conditions 163
conventions used in this document 13 transitions 160, 161
correlation IDs Worklfow logic 151
and the Local Correlation property 59, 259, 267, 268
managing across distributed servers 59, 259, 267, 268 D
mapping to process instance ID (PID) 154 Database Cleanup Interval (sec), PRT setting 252
tips for creating 153 Database Connection Retries, PRT setting 252
correlation services Database Connection Retry Interval, PRT setting 252
and correlation ID 152 databases
checklist for working with 152 Process Audit Log
correlation ID-to-PID mapping 154 and Process Tracking Store (PRT) database 253
definition 152 changing from flat file to database storage 47
editing 157 description 19
importance of unique ID among all processes 153, 155 moving process model to for monitoring 246
importance of using in only one process model 153, 155 use during process run time 29
inputs and outputs 155 warning about Oracle database drivers 47
procedure for assigning to steps 157 PRT (Process Tracking Store)
procedure for creating 155 configuring 253
when steps don’t need 152 using central vs. distributed 254
when steps need 152 definitions
creating Associated Server 232
correlation ID-to-PID mapping 154 branches 25, 163
correlation services 152, 155 business process management 17
distinct pipeline variables for split logic threads 172 Central Process Tracking Store 251, 254
end steps 86 child and parent process 272
fields to log for monitoring 138 controlled and uncontrolled steps 23
groups 178, 179 correlation ID 152
inputs to steps 109 correlation services 148, 152
joins 88 Design Server 18
logic that affects step run-time status 150 Express Pipeline 55
logic to send external documents from steps 136 external documents 24
new process model version 227 filters 24, 139
outputs from steps 124 Focal Role 54
process models 51 generated flow services 148
process-wide error steps 87 groups, internal and external 26, 66, 178
publications from steps 125 hot-swappable 273, 277
publish/subscribe filters 140, 144, 145 input/output data 24, 108
referenced process steps 89, 272 IS documents 24
regular step logic 149 joins 25, 163
splits, branches, and joins 163 logical servers 20

Index
Modeler repository 18 development approach

modeling 16 description of types 30, 182, 197
performance 248 development environment
Process Completion Tracking Server 252 before deploying process models 234
process control documents 29 tasks to complete in 31
process models 22 vs. production environment 31
Process Reference property 273 diagrams
process run time (PRT) 29 process generation architecture 200
process run-time scripts 27 run-time architecture for processes 28
Process Tracking Store 251, 254 sample process model 22
process transition documents 29, 254 webMethods Modeler design-time architecture 20
publications and subscriptions 24, 108 webMethods platform and webMethods Modeler 17
quality-of-service 248 documentation
referenced process 25, 272 additional 13
referenced process steps 272 conventions used 13
return join type 274 feedback 13
return timeout 274 documents
sender/receiver roles 112 external, see external documents
splits 25, 163 process control documents 29
steps 23 process transition documents 29, 254
subprocess 25 publication, definition 108
territory 18 publishing from steps 24, 125
timeout value for steps 70, 75, 76, 80, 83 restricting documents used by process model 24, 139
top-down vs. bottom-up development approach 30 subscribing steps to 24, 110
transition types 26, 160 subscription, definition 108
transitions 25, 160 Trading Networks, see external documents
deleting using filters 24, 139
process models 228
steps in process models and process regeneration 214, 216 E
deploying process models Edit Transititon Conditions window 165
creating release of package for logical server 243 else transitions
items to move 235 creating 161
logical-to-physical server mappings 234, 238 definition 26, 160
moving items from Integration Servers 238 Empty Step Properties 82
moving Modeler generated items on Integration Servers 239 Enable Resubmission property 71, 77, 81, 256, 261, 269
moving to production audit logging database 246 error messages
moving Trading Networks information 245 issued during process generation 216
moving Workflow information 245 error transitions
using Trading Networks export/import data feature 245 creating 161
Design Server definition 26, 160
and the Associated Server 206, 208 Express Pipeline property 55
description 18 and step inputs/outputs 109
use at design time 21 defined 55

Index
external documents G
and sender/receiver roles 112 Generated Flow Name property
definition 108 how changing affects process model regeneration 212
deployinig with process model 245 use during process generation 203
enabling steps to access 112 generated flow services
guidelines for subscribing to start steps 113 definition 148
how to have steps send 136 guidelines for working with 148
inability to "publish" 136 mapping to user-defined services 149
keeping distinct among logical servers 113 generating process models
purpose of "publishing" 136 see process generation
sender role 112 generation package, description 18
subscribing steps to 110 global data
when to define 50 definition and overview 108
external groups working with global data 143
creating 179 groups
definition 26, 178 see also external groups
warning about transition conditions 163, 180 see also internal groups
definition 26, 66, 178
F how PRT ignores 26, 178
filters, definition 24, 139
flat file, changing from flat file to database storage 47 H
flow services Hot-Swappable property of referenced process steps
and step logic, overview 148 definition 273
caution about ProcessData variable 150 how process model design is not affected 278
completing logic after process generation 222 how state affects run-time actions 272
guidelines for designing step logic 149 if disabled 278
how Modeler generates flow services 149 if enabled 278
including in release of package for deploying process model importance of disabling all running processes when using 278
243
using instead of referenced process step substitution 277
location of those generated by Modeler 240, 243
using the hot-swappable feature 277
properties affecting generation of 203
Focal Role
I
and sender/receiver roles 112
property defined 54 icons for steps, changing 105
Folder property Implementation Module property
how changing affects process model regeneration 212 how changing affects process model regeneration 215
use during process generation 204 use during process generation 207
folders, IS implementation modules
properties affecting generation of 202 completing logic after process generation 222
properties affecting generation of 206

Index
input data J
assigning to steps 109 Join Queue Lock Expiration (sec), PRT setting 253
instance names 109 join types
subscriptions vs. input data 109 defined 89
input/output data return join types 274, 277
see also input data joins (join steps)
see also output data see also AND joins
changing and process regeneration 214 see also Complex joins
checking after 4.6 model migration 283 see also OR joins
definition and overview 24, 108 see also XOR joins
using in transition conditions 163 definition 25, 163
instance names of input data forming 25, 163
purpose and description 109 guidelines for creating 170
Integration Servers three ways to create 163
and the Associated Server 206 types, defined 89
and webMethods Modeler architecture 18 JPEG, of process model, creating 63
and Workflow step generation 206
items Modeler generates for processes 201
L
properties affecting flow services generated for processes 203
Label process property
properties affecting folders generated for processes 202
properties affecting generation of package 201 how changing affects process model regeneration 211, 215
use during process generation 201, 202, 207
properties affecting process run-time script generated for
processes 204 Label step property
properties affecting triggers generated for processes 202 how changing affects process model regeneration 212, 215
use at design time 21 use during process generation 203, 207, 208
use during process run time 28 Logging Level property 54, 258, 260, 262
internal groups Logical Server property
creating 179 defined 67, 72, 78, 82, 84
definition 26, 178 how changing affects process model regeneration 213, 215
IS documents use during process generation 202, 203, 204, 207, 208
editing contents 120 logical servers
editing instance names 120 see also Logical Server property
guidelines for subscribing steps to 119 and process generation 200
importance of using only once per model 119 assigning after 4.6 model migration 283
publishing to Broker 125 changing connection state 232
subscribing steps to 115 changing step by step vs. throughout process 231
when to create 31, 50, 183 creating release of package containing information for 243
IS folders, properties affecting generation of 202 defining and mapping to physical servers 44
definition 20
development vs. production 31

Index
keeping external documents distinct among 113 O

mappings and process deployment 234, 238 OR joins
overview 44 and return join types 274
refreshing information 232 caution about becoming start steps 85
viewing connection status 232 caution using after splits 170
definition 89
M Oracle database
managing warning for setting up as Modeler repository 47
logical server assignments 231 output data
process models 226 assigning to steps 124
server connections 231 types defined 124
mapping
correlation ID to process instance ID (PID) 154 P
generated flow to user-defined services 149 Package Name property
logical-to-physical server 44 how changing affects process model regeneration 212
mappings, logical-to-physical server use during process generation 201
and deploying process models 234, 238 package replication
procedure for defining 44 using to deploy process model information 239
menu options, defined 36 packages
migration of 4.6 process models generation, description 18
basic steps 282 modeler, description 18
differences in BI 4.6 and Modeler 6.0.1 280 properties affecting generation of 201
integrity check tasks 283 parent process, definition 272
overview 280 performance and quality-of-service
Modeler repository configuration overview 250
authentication 21 defined 248
changing from flat file to database storage 47 tuning, overview 248
description 18 warning about installing database with Oracle drivers 47
use at design time 21 physical servers
warning about installing with Oracle drivers 47 mapping to logical servers 44
monitoring process models relation to logical servers 20
choosing fields to log 138 viewing physical-to-logical mapping 232
controlling the information you monitor 54, 256 Portable format import/export format, defined 229
making models available for monitoring 222 prerequisites
overview 30 before you create process models 50
PRTservices that aid monitoring 150 before you subscribe to external documents 110
Process Audit Log
N see databases
normal transitions Process Completion Tracking Server
and transition conditions 163 choosing one for the territory 255
creating 161 defined 252
definition 26, 160 PRT setting 252
process control documents, definition 29

Index
process generation and information flow 109

and logical servers 200 and input/output data 108
completing logic after generating 222 guidelines for variable names 172
consequences to changing Associated Server 208 using in transition conditions 163
error messages and responses 216 when using an Express Pipeline 55, 109
items generated on Integration Servers 201 process run time (PRT)
items generated on Workflow Servers 205, 206 choosing distributed vs. central process tracking 254
overview 200 database (Process Tracking Store) 253
regeneration 210 definition 29
sample showing generated items 204 home page, configuring 251
steps to generate process 209 services to use in user-defined services 150
troubleshooting 216 tuning settings across the territory 250
when to regenerate 210 process run-time scripts
Workflow steps and multiple servers 206 and process model regeneration 211
Process Key property definition 27
use during process generation 201, 202 including in release of package to deploy 243
Process Lock Expiration (sec), PRT setting 253 location in Integration Server 240
process models properties affecting generation of 204
before you create 50 Process Tracking Store
collapsing several steps into single step 25 central vs. distributed 254
creating logic 148 defined 251, 254
creating Workflow logic 151 how type affects use of Volatile Tracking property 255
definition 22 role in territory configuration 250
deleting steps and process model regeneration 214, 216 process transition documents
deploying 233 defined 254
development approach 30, 182 process transition documents, definition 29, 254
exporting 229 Process window 39
generating 209 ProcessData variable
importing 229 in flow services, caution 150
making available for monitoring 222 production environment
migrating BI 4.6 to Modeler 6.0.1 280 logical-to-physical server mappings 234
Modeler stores in repository 21 moving process models to 233
moving to Process Audit Log for monitoring 246 tasks to complete in 32
moving to production 233 vs. development environment 32
prerequistites to executing after regenerating 210 profiles, Trading Networks
referencing previously defined 25 and the publish/subscribe filter 142
regenerating 210 deploying with process models 245
snapshot of sample 22 program code conventions in this document 13
transitions 25, 160 Project property
troubleshooting generation of 216 how changing affects process model regeneration 215
process pipeline use during process generation 207

Index
projects, Workflow pub.prt.admin.log

properties affecting generation of 206 logActivityMessages service 150
properties publishing documents
Folder, how changing affects process model regeneration 212 external, important information 136
Folder, use during process generation 204 IS, procedure 125
Generated Flow Name, how changing affects process model overview 24, 108
regeneration 212
Generated Flow Name, use during process generation 203 Q
Implementation Module, how changing affects process model quality-of-service and performance
regeneration 215
configuration overview 250
Implementation Module, use during process generation 207
defined 248
Label, how changing affects process model regeneration 211,
tuning, overview 248
212, 215
Label, use during process generation 201, 202, 203, 207, 208
Logical Server, how changing affects process model R
regeneration 213, 215 receiver roles, assigning to external documents 112
Logical Server, use during process generation 202, 203, 204, referenced processes
207, 208 and hot-swapping 277
of referenced process steps 273 and performance/quality-of-service settings 269
of regular steps 67 definition 25, 89
of transitions 162 working with 272
Package Name, how changing affects process model regenerating process models
regeneration 212 how Modeler makes changes to Integration Server 211
Package Name, use during process generation 201 how Modeler makes changes to Workflow Server 215
Process Key, use during process generation 201, 202 when to regenerate 210
Project, how changing affects process model regeneration releases of packages
215 creating to deploy process model information 239
Project, use during process generation 207 including information for a single logical server 243
Service to Invoke, how changing affects process model replacing
regeneration 213 logical servers in a process 231
Service to Invoke, use during process generation 203 one referenced process step for another, caution 277
Unique ID, use during process generation 203, 207, 208 repository, Modeler
Version, use during process generation 207 see Modeler repository
Workflow to Invoke, how changing affects process model Retreiving documents flow sequence
regeneration 216 importance of enabling 112
Workflow to Invoke, use during process generation 208 retries exceeded transitions
PRT (process run time) creating 161
choosing distributed vs. central process tracking 254 definition 26, 160
database (Process Tracking Store) 253 return join types
definition 29 defined 274
home page, configuring 251 when to assign to steps 277
services to use in user-defined services 150
tuning settings across the territory 250

Index
S start steps
sender role, assigning to external documents 112 and subscription documents 85, 110
sending external documents 136 defined 85
Server Connections dialog 231 guidelines for external document subscriptions 113
servers starting the Modeler 34
consequences to changing Associated Server 208 Step Lock Expiration (sec), PRT setting 254
logical, creating releases of package information for 243 steps
logical, definition 20 and step logic 148
mapping logical to physical 44 changing icons 105
mappings and process deployment 234, 238 collapsing into a subprocess 25
physical, relation to logical servers 20 controlling pipeline logging 54, 71, 77, 81, 258, 260, 261
service packs, Modeler and IS 71, 77, 81, 248 controlling visual properties of 105
Service to Invoke property definition and overview 23, 66
definition 68 enabling resubmission in Monitor 71, 77, 81, 256, 261
how changing affects process model regeneration 213 end steps 86
influence on generated flow services 149 how groups affect 178
use during process generation 149, 203 information flow into and out of 24, 108
services join steps 88
caution about ProcessData variable 150 overview 66
guidelines for working with step logic 149 process-wide error steps 87
helpful PRT services 150 properties of referenced process steps 273
how Modeler generates flow services for steps 149 properties of regular steps 67
important flow sequence for external document access 112 referenced process steps 25, 89, 272
mapping generated flow to user-defined 149 start steps 85
procedure for assigning to steps 150 step functions and types 85
properties affecting generation of 203, 204 subprocess steps 25, 90
relationship to steps 148 using filters 24, 139
replacing service a step invokes 149 Workflow step guidelines 104
Service to Invoke property 68, 149 Workflow steps overview 23
that control a process’s run-time status 150 Steps Enable Resubmission option 71, 77, 81, 256, 261
that create and log activity messages 150 subprocesses
that send external documents 136 accessing and editing 91
types that you can add to steps 148 definition 25, 90
working with correlation services 152 procedure for establishing 90
shutting down the Modeler 35 subscription documents
SP, Modeler and IS 71, 77, 81, 248 and start steps 85, 110
splits external, and start steps 113
definition 25, 163 overview and definition 24
forming 163 subscribing to external documents 110
guidelines for creating 170 subscribing to IS documents 115

Index
T number allowed per step 160

Terminate Step Properties 84 overview and definition 25, 160
territory procedure for creating 161
definition 18 properties defined 162
tuning PRT settings in a territory 250 retries exceeded defined 26, 160
timeout transitions timeout defined 26, 160
creating 161 to/from external groups 163, 180
definition 26, 160 types defined 26, 160
To-Do List triggers
overview 60 and process model regeneration 211
viewing 61 location of those generated by Modeler 240, 243
toolbar, main, defined 37 properties affecting generation of 202
toolbar, process, defined 40 troubleshooting
Trading Networks information for other webMethods components 13
deploying attributes with process models 245 Oracle database driver installation 47
deploying profiles with process models 245 process generation 216
deploying TN document types with process models 245 Workflow step generation and Associated Servers 208
ensuring profiles created 50 typographical conventions in this document 13
export/import data feature and deploying process models 245
participants, using in transition conditions 163 U
Trading Networks documents uncontrolled steps
see external documents and external groups 26, 178
transition conditions definition 23
and 4.6 model migration 283 Unique ID property
creating based on inputs/outputs 163 use during process generation 203, 207, 208
creating based on pipeline data 163 updating process models 226
creating based on Trading Networks participants 163 user-defined services
Edit Transition Conditions window 165 changing the service a step invokes 149
migration of 4.6 TN status conditions 284 mapping to generated flow services 149
overview 25, 163 procedure for assigning to a step 150
procedure for building 164, 167
sources of 163 V
to/from external groups 163, 180 Version step property
transitions defined 53
see also transition conditions use during process generation 207
controlling the color of 175 versioning process models
controlling the display of 175 overview and steps 227
creating splits, joins, and branches 25, 163 Version step property 53
else defined 26, 160 View Options, defined 41
error defined 26, 160 viewing
general guidelines for creating 168 server connections 232
guidelines for splits and joins 170 Volatile Tracking property
normal defined 160 relationship to type of Process Tracking Store 255

Index
W X
webMethods Modeler XOR joins
and business process management 17 and return join types 274
description 16, 18 caution using with loops 171
design-time architecture 20 definition 89
getting started 34
how it relates to webMethods platform 17
use at design time 20
webMethods Monitor
and webMethods Modeler architecture 19
description 19
use during process run time 30
webMethods platform
documents to communicate between components of 24, 108
relationship to webMethods Modeler 17
webMethods Trading Networks
documents to and from 24, 108
webMethods Workflow
and webMethods Modeler architecture 19
consequences of changing Associated Server 208
description 19
two servers Workflow steps generate to 206
use at design time 21
use during process run time 29
WmModeler package, description 18
Workflow logic
and deploying process models 245
assigning to steps 151
deploying workflows to production environment 245
guidelines 151
properties affecting generation of Workflow projects 207
properties affecting generation of workflows 208
Workflow Servers
items Modeler generates for processes 205, 206
properties affecting implementation modules generated for
processes 207
properties affecting projects generated for processes 207
properties affecting workflows generated for processes 208
Workflow to Invoke property
how changing affects process model regeneration 216
use during process generation 208

Index

Webmethods Modeler Users Guide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Webmethods Modeler Users Guide

Hochgeladen von

Copyright:

Verfügbare Formate

webMethods Modeler

Document ID: MOD-UG-61-20040322

About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2. Getting Started with webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

webMethods Modeler User’s Guide Version 6.1 3

Chapter 3. Configuring webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 4. Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 5. Adding Steps to a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 webMethods Modeler User’s Guide Version 6.1

Referenced Process Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 6. Assigning Inputs and Outputs to Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

webMethods Modeler User’s Guide Version 6.1 5

Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Chapter 7. Adding Logic to Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6 webMethods Modeler User’s Guide Version 6.1

Working with Correlation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Chapter 8. Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Chapter 9. Adding Groups to a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

webMethods Modeler User’s Guide Version 6.1 7

Resizing and Moving Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Chapter 10. Importing and Exporting BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 11. Generating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

8 webMethods Modeler User’s Guide Version 6.1

Before You Can Execute a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Chapter 12. Managing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Chapter 13. Moving Process Models to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

webMethods Modeler User’s Guide Version 6.1 9

Moving Referenced Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Appendix A. Tuning Performance and Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . 247

10 webMethods Modeler User’s Guide Version 6.1

Optimizing the Process Locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Appendix B. Guidelines for Working with Referenced Processes . . . . . . . . . . . . . . . . . . . 271

Appendix C. Migrating 4.6 Process Models to Modeler 6.1 . . . . . . . . . . . . . . . . . . . . . . . . 279

webMethods Modeler User’s Guide Version 6.1 11

12 webMethods Modeler User’s Guide Version 6.1

About This Book

webMethods Modeler User’s Guide Version 6.1 13

14 webMethods Modeler User’s Guide Version 6.1

What is the webMethods Modeler? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

webMethods Modeler and Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . 17

Modeler and the webMethods Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Modeler Design-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Participants in Process Modeling and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Bottom-Up Vs. Top-Down Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Phases of Development and Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Introduction to BPEL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

webMethods Modeler User’s Guide Version 6.1 15

Indicate the work or information flow

Analyze the business process

Document the business process and your procedures

What is the webMethods Modeler?

Workflows (human interactions)

16 webMethods Modeler User’s Guide Version 6.1

webMethods Modeler and Business Process Management

Modeler and the webMethods Platform

webMethods Platform Architecture and webMethods Modeler

Process Audit Log

webMethods Modeler User’s Guide Version 6.1 17

18 webMethods Modeler User’s Guide Version 6.1

Modeler Design-Time Environment

Elements of a process model

Approach to developing process models

On the Start menu, select ProgramswebMethodsModeler.

1 On the main toolbar, select ToolsOptions.