webmethods modeler users guide

webMethods, Inc.3930 Pender DriveFairfax, VA 22030USA703.460.2500http://www.webmethods.com

webMethods ModelerUser’s Guide

VERSION 6.1

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15What is Modeling? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16What is the webMethods Modeler? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16webMethods Modeler and Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Modeler and the webMethods Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Modeler Design-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Design-time Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Controlled and Uncontrolled Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Steps and Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Multiple Steps Represented as a Single Icon in the Process Model . . . . . . . . . . . . . . 25

Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Process Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Run-time Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Participants in Process Modeling and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Bottom-Up Vs. Top-Down Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Top-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Bottom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Phases of Development and Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31The Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31The Production Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

Chapter 2. Getting Started with webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Starting the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Updating the Workflow Client Directory from Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Connecting to a Different Design Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Shutting Down the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Familiarizing Yourself with the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

webMethods Modeler User’s Guide Version 6.1 3

C o n t e n t s

Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Main Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Process Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Process Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41View Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Chapter 3. Configuring webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Defining Servers Where Process Steps Will Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Defining Logical Servers and Their Physical Server Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 44Editing Logical Servers and Their Physical Server Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 45For More Information on Server Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Changing the Modeler Repository Storage Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 4. Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Before Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Basic Steps in Process Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Process Model Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51The To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Tasks in the To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Process Model Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Step Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Workflow Step Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Steps Outside of the Scope of the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Viewing the To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Quick Reference of Basic Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Saving a Process Model as a JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 5. Adding Steps to a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Flow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Workflow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Web Service Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Empty Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Terminate Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Step Functions and Step Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Start Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85End Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Process-Wide Error Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Join Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Join Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4 webMethods Modeler User’s Guide Version 6.1

Contents

Referenced Process Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Subprocess Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Accessing and Editing a Subprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Restoring a Subprocess to the Main Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Working with Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Defining Web Service Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Importing Port Types from a WSDL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Defining Web Service Port Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Defining New Process Port Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Adding Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Defining Web Service Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Web Service Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Binding for Web Service Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Using Static Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Using Dynamic Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Using Deployment-time Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Mapping WSDL Elements to EndPointReference Document Fields . . . . . . . . . . . . . . . . . . 101

Web Service Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Web Service Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Guidelines on Using Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Controlling the Visual Properties of Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Changing a Step’s Icon Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Controlling the Display of Step Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

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

Types of Inputs and Outputs Available to Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108How Information Flows through the Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Are Step Inputs/Outputs Required or Optional? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Assigning and Editing Step Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Subscription Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Adding a Subscription to an External Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Guidelines for Using External Documents in the Process Model . . . . . . . . . . . . . . . . 112

Adding a Subscription to a Publishable IS Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Guidelines on Subscribing to IS Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Editing Subscription Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Editing the Instance Name (or Role) of a Subscription Document . . . . . . . . . . . . . . . 120Editing the Contents of an Existing Subscription Document . . . . . . . . . . . . . . . . . . . . 120

Deleting Subscription Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122


C o n t e n t s

Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Adding Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Editing Input Data Instance Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Deleting Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Assigning and Editing Step Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Publishing an IS Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Editing Publication Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Deleting Publication Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Adding Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Editing Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Deleting Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Adding Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Editing Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Deleting Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Publication and External Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Having a Step Send an External Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Controlling the Display of Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Choosing Fields to Log For Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Using the Publish/Subscribe Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Building Publish/Subscribe Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Working with Global Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

How Global Data Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Using Global Data in Your Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Defining Data Properties and Data Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Chapter 7. Adding Logic to Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Working with Flow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

How Modeler Generates Flow Services for Flow steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Guidelines for Working with Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

PRT Services that You Might Want to Use in User-Defined Services . . . . . . . . . . . . . . . . . 150Controlling the Process’s Run-Time Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Creating and Logging User-Defined Activity Messages . . . . . . . . . . . . . . . . . . . . . . . 150

Selecting a Service to Invoke for a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Working with Workflow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Guidelines for Generated Workflow Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Selecting a Workflow to Invoke for a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151


Contents

Working with Correlation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Checklist of Correlation Services Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Tips for Creating the Correlation ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Examples to Use for Forming the Correlation IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Determining How the Correlation ID-to-PID Mapping Will Be Created . . . . . . . . . . . . . . . . . . . . 154

The PRT Automatically Creates the Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154You Must Manually Create the Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Mapping Method 1: Use the establishCorrelation Service within Upstream Step Logic 154Mapping Method 2: Use the Conversation ID of the Start Step’s External Document . 155

Creating a Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Input/Output Specification for the Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Assigning a Correlation Service to a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Editing an Existing Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Deleting an Existing Correlation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Broadcasting Correlation IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Chapter 8. Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Overview of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Summary of Transitions Allowed Per Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Transition Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Splitting, Branching, and Joining Logic in a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Building Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Defining Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Edit Transition Conditions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Defining Transition Conditions Using XPath Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Working with Global data in XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Guidelines for Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Guidelines for Transitions that Create Splits and Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

The Appearance of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Displaying/Hiding Transitions Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Controlling the Color of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Default Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Other Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Chapter 9. Adding Groups to a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Adding a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179External Groups and Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180


C o n t e n t s

Resizing and Moving Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Changing the Appearance of Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

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

BPEL Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Partner Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Variables, Message Types, and Document Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 184BPEL Web Service Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Terminate Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Empty Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Wait Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186While Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Assign Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187BPEL Structural Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Flow without Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Flow with Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Pick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Exporting Process Models in BPEL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190BPEL Export Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190BPEL Export Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Chapter 11. Generating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Overview of Process Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200What Modeler Generates for a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Items Generated for Steps Associated with Integration Servers . . . . . . . . . . . . . . . . . . . . . . . . . 201Sample Process Model and Generated Run-time Elements . . . . . . . . . . . . . . . . . . . . . . . . 204

Items Generated for Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Web Service Receive/Reply Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Web Service Invoke Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Items Generated for Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Workflow Step Generation and Multiple Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206What Modeler Generates to Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Consequences to Changing the Associated Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Validating a Process Model Before Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209


Contents

Before You Can Execute a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209STEP 1: Generating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Regenerating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Before You Can Execute a Regenerated Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . 210Changes that Modeler Makes when Regenerating Integration Server Run-time Elements 211Changes that Modeler Makes when Regenerating Workflow Run-time Elements . . . . . . . 215

Troubleshooting Process Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

STEP 2: Optionally Adding Logic to Generated Run-time Elements . . . . . . . . . . . . . . . . . . . . . . . . . . 222Adding Logic to Flow Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Adding Logic to Implementation Modules and Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

STEP 3: Making the Process Model Available for Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222STEP 4: Enabling Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Chapter 12. Managing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Updating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Versioning the Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Deleting Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Exporting and Importing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Exporting Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Importing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Managing Logical Servers and Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Managing Logical Servers in the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Managing Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

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

Servers and Moving Processes to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Items that You Need to Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Identifying the Items You Need to Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Information the Deployment List Contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Generating the Deployment List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Moving Items that Reside on Integration Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Moving Modeler Generated Run-time Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Locating the Items to Include in the Release of the Package . . . . . . . . . . . . . . . . . . . . . . . 239Creating 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


C o n t e n t s

Moving Referenced Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Moving Items that are Stored in Trading Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Moving Items that Reside on webMethods Workflow Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Moving Process Models to Production Process Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

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

Backwards Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Quality of Service vs. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Maximum Quality of Service: Minimum Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Maximum Performance: Minimum Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Configuring the System to Meet Your Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

STEP 1: Configure the Territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Overview of Tuning the Territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Choosing Central vs. Distributed Process Tracking Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Central Process Tracking Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Distributed Process Tracking Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Choosing a Process Completion Tracking Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Single Server Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

STEP 2: Configure Process-Level Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Step 1: Choose Global Default Process Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Step 2: Tune Individual Process Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Choosing a Logging Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Logging Level Effect on Document Field Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Using Volatile Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Effect on Monitor Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Using Volatile Transition Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Effect on Automatic Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Summary of Using Volatile Transition Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 264


Contents

Optimizing the Process Locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Effect on Where the Process Automatically Recovers . . . . . . . . . . . . . . . . . . . . . . . . 264Example of a Process with Enabled Optimize Locally Property . . . . . . . . . . . . . . . . . 265Example of Process that Does Not Optimize Locally . . . . . . . . . . . . . . . . . . . . . . . . . 266

Managing Correlation IDs in a Distributed Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Local Correlation Property’s Effect on Correlation ID Receipt . . . . . . . . . . . . . . . . . . . 267Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Summary of Local Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

STEP 3: Optionally Modify Step Pipeline Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269A Note About Referenced Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Appendix B. Guidelines for Working with Referenced Processes . . . . . . . . . . . . . . . . . . . 271Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Referenced Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Design Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Referenced Process Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Design-Time Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Assigning Inputs and Outputs to Referenced Process Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Related Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Assigning a Return Join Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Using the Hot-Swappable Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

If a Referenced Process Step is Hot-Swappable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278If a Referenced Process Step is Not Hot-Swappable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

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

Assign Valid Logical Servers to Each Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Ensure All Documents in the Model Exist on the 6.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 283Check the Integrity of Step Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Check the Integrity of Transitions and Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Migration of Typical Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Migration of Trading Networks “Status”-Based Transition Conditions . . . . . . . . . . . . . . . . . 284If a 4.6 Step Has TN “Status” Conditions and Other Conditions . . . . . . . . . . . . . . . . . . . . . 284If a 4.6 Step Has More than One TN “Status” Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285


C o n t e n t s


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 Convent ions

Addit ional Informat ionThe 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.

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 font

Identifies characters and values that you must type exactly or 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.


http://advantage.webmethods.com

http://advantage.webmethods.com/troubleshooting

http://advantage.webmethods.com/docfeedback

http://advantage.webmethods.com/Bookshelf

http://advantage.webmethods.com/Bookshelf

A b o u t T h i s B o o k


W E B M E T H O D S M O D E L E R

C H A P T E R1
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


C H A P T E R 1 C o n c e p t s

What is Model ing?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 ManagementBusiness 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 Plat formThe following shows the architecture of the webMethods platform and how Modeler fits into this architecture.

webMethods Platform Architecture and webMethods Modeler

IS

Broker Workflow

Monitor

Process Audit Log

Modeler

Design Server

IS Modeler

repository

IS ISWmModeler

packageWmMonitor

package



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 repository

The Modeler repository is a storage area that Modeler uses to save (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

Modeler Design-Time EnvironmentwebMethods 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

Process Audit Log

The Process Audit Log is a database that the Integration Servers in 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.




Design-time ArchitectureThe following shows the design-time architecture for creating process models using webMethods Modeler.

Design-time Architecture


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.

Workflow

Modeler

Modelerrepository

Design Server

IS IS IS

Logical Server Names = Accounting Customer Info Partner GatewayUtility Services

ISWmModeler

package



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 repository

The Modeler saves information about the process models that you 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.




Process ModelsProcess models are the diagrams that illustrate a business process that you create using the Modeler.

Sample Process Model

A process model consists of:

Steps

Transitions

Groups (optional)

Annotations (optional)

Internal groups box stepsthat are performed within

your enterprise

Steps represent anautomated process

performed by a computer ora manual step performed by

a person.

Transitions are linesbetween steps thatindicate the flow of

execution.

External groups box stepsthat are performed outside

your enterprise.



StepsSteps 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.



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.

TransitionsYou 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.



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.

GroupsYou 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

AnnotationsYou 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 Execut ionProcesses 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.



Run-time ArchitectureThe following shows the run-time architecture for executing business processes that you design using webMethods Modeler.

Run-time Architecture for Business Processes


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.

IS

Broker Workflow

IS ISPRT

PRT

PRT

ISPRT

Monitor

Process Audit Log

packageWmMonitor


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 Log

The PRT logs audit data about running processes to the Process 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.




Part icipants in Process Model ing and Implementat ionThere 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 ApproachYou 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

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.



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-UpIn 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.

Phases of Development and Product ionThe following sections describe which phases of process model creation or management are associated with which type of environment.

The Development EnvironmentDesigning. 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.

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”.



The Production EnvironmentDeploying. 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

Introduct ion to BPEL SupportModeler 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.

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”

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.jsphttp://www-106.ibm.com/developerworks/webservices/library/ws-bpel/http://ifr.sap.com/bpel4ws/http://www.siebel.com/bpel



C H A P T E R2
Gett ing 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


C H A P T E R 2 G e t t i n g S t a r t e d w i t h w e b M e t h o d s M o d e l e r

OverviewThis chapter describes how to start and exit the Modeler, and introduces you to the Modeler’s user interface.

Start ing the ModelerBefore 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.

On the Start menu, select Programs webMethods Modeler.

At the shell prompt, type Modeler Installation Directory/bin/runbi.sh.

Updating the Workflow Client Directory from ModelerTo 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.

To start the Modeler on Microsoft Windows

To

To start the Modeler on UNIX


Connecting to a Different Design Server

Connect ing to a Di f ferent Design ServerYou can change the Design Server to which Modeler is connected at any time. To do so, use the following procedure.

1 While running Modeler, choose Session Close Design Server connection from the menu bar. The session with that Design Server closes.

2 From the menu bar, choose Session Connect 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.

Shutt ing Down the ModelerTo shut down the Modeler, follow the single step procedure below.

Select File Exit.

To connect to a different Design Server

To shut down the Modeler



Famil iar iz ing Yourself with the ModelerThe main Modeler window consists of:

Menu bar

Main toolbar

Process toolbar

Process window

Canvas

View options

Main Modeler Window

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.

Menu barMain toolbar

Process toolbar

Canvas

Process window

View Options


Familiarizing Yourself with the Modeler

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 ToolbarThe main toolbar provides several icons to access common functions. The icons and their descriptions are provided below.

This icon...

Represents...

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.



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.

This icon...

Represents...



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

The Process window consists of:

Process toolbar

Canvas

View options

Properties (optional)

To Do List (optional)

Process toolbar

Canvas

View options



Process ToolbarThe 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.



CanvasThe 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.

1 On the main toolbar, select Tools Options.

2 Check or uncheck the Show Grid option.

On the View Options area at the bottom of the Process window, check or uncheck Show Grid.

View OptionsThe 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.

To specify the default grid setting

To change the grid setting of the active 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.



C H A P T E R3
Configuring webMethods Modeler
Defining Servers Where Process Steps Will Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Changing the Modeler Repository Storage Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


C H A P T E R 3 C o n f i g u r i n g w e b M e t h o d s M o d e l e r

Defining Servers Where Process Steps Wil l ExecuteDuring 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 MappingsUse the following procedure to define a logical server and its physical server mapping.

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 Logical Servers and Their Physical Server Mappings


Defining Servers Where Process Steps Will Execute

3 In the Add Logical Server page, specify the following information:

4 Click Add Logical Server.

5 Click Return to Logical Servers to return to the previous page.

Edit ing Logical Servers and Their Physical Server MappingsUse the following procedure to edit a logical server or its physical server mapping.

1 Log in to the webMethods Administrator, if you are not already.

2 Click the Logical Servers menu of the Navigation panel.

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.

Editing Logical Servers and Their Physical Server Mappings



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 ManagementFor 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 MechanismWhen 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.

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.

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.

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.

Changing the Modeler Repository Configuration from Flat File to Database

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.

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.

Note: The process model data remains in the XML file, and is also migrated to the database.



C H A P T E R4
Creat ing 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


C H A P T E R 4 C r e a t i n g a P r o c e s s M o d e l

Before Creat ing a Process ModelThe 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 Creat ionAn overview of the steps in process model creation is described below.

1 Start webMethods Modeler. For instructions, see Chapter 2, “Getting Started with webMethods Modeler”.

2 Open a new process model by selecting File New.

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 File Save. 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 Propert iesWhile 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.

To Create a Process 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.

Note: You should assign each process model a unique name.

Before saving a new model, the model is titled “New Process”. When you save the model, you type the model name.

Description Description of the process model, e.g., “Purchase order with Viva Italia July 2003”. There is no limit on the description length.

Choose Edit to enter a description.

Package Name

The name of the package to which Modeler will generate the process model components (e.g., flow services, triggers, etc.). Upon generation, Modeler creates a package with this name on each physical Integration Server associated with the process.

Modeler auto-populates this property with the process model name (i.e., the name that you assigned using the Label property described above). You may choose any name you like.

Process Key The internally-generated unique ID that Modeler assigns to the process model.

This is a read-only property.

Created by The Username of the person who initially created the process model.

The Username corresponds to the Modeler User login name. This is a read-only property.

Last Modification

The Username of the person who made the last Save to the process model, and the time/date stamp of the Save.

The Username corresponds to the Modeler User login name. This is a read-only property.

Last Generation

The date and time that the process model was last generated.


Last Model Update

The date and time that the process model was last updated for monitoring; that is, 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.



Process Model Properties

Version The process model version.

Note: For important information on versioning a process model, see “Versioning the Process Model” on page 227.

Modeler assigns each new process model a Version value of 1. If you select File Save as New Version, Modeler increments the version by a value of 1, but you can specify a different value if you prefer.

Global Data The Global Data dialog. This dialog displays global data elements defined for this process.

Choose Edit to display the Global Data dialog.

Data Properties

The Data Properties and Data Properties Aliases dialog. This dialog displays data properties and aliases defined for this process.

Choose Edit to display the Data Properties and Data Properties Aliases dialog.

Web Service Interactions

The Web Service Interactions dialog. This dialog displays web service interactions defined for this process. Web service interactions correspond to the BPEL PartnerLink construct.

Choose Edit to display the Web Service Interactions dialog.

Web Service Ports

The Web Service Ports dialog. This dialog displays the web service ports defined for the process.

Choose Edit to display the Web Service Ports dialog.

Error Step The process-wide error step for the process model. This is the step to be invoked when any step not associated with its own error step encounters an error.

Select the appropriate step from the drop down.




Focal Role The unique name for the participant hosting the controlled steps (i.e., for your role) in the process. The value can be 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.

“Focal Role”. To change this, type a name in the Focal Role box.

Logging Level The precise level of information to persist 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 Transitions

Turns on transition logging. Check the box to turn on transition logging.




Express Pipeline

Whether to use a complete or abridged (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.

Disabled




Volatile Tracking

Whether the integration servers hosting the process should store process transition documents in the Process Tracking Store or in RAM. If this property is enabled, servers store these documents in RAM. If it is disabled, servers store documents in the Process Tracking Store.

For new processes (i.e, those created and generated after the application of Modeler 6.0.1 SP1 and Integration Server 6.0.1 SP2), the 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 Transition Documents

Whether the Broker should store process transition documents to hard disk or in RAM. If this property is enabled, Broker uses RAM. If it is 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.






Optimize Locally

Whether servers should publish process transition documents between execution of adjacent steps on the same 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 Correlation

Whether to save correlation IDs on the local server that created them, or whether it is necessary to broadcast them to different servers in the process.

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. Details about when and how to use correlation services are provided on “Working with Correlation Services” on page 152.






The To-Do ListModeler 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.

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

Process Model TasksThe 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 TasksAfter 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

Note: You cannot edit items in the To-Do List in any way; the list is read-only.


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 TasksIn 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 ProcessModeler 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 ListTo view the To-Do List for a process model, use the following procedure.

On the process toolbar, click the Show/Hide button. The To-Do List and Properties windows appear; or

On the menu bar, select View To Do List. The To-Do List appears.

Viewing the To-Do List



Quick Reference of Basic Act ionsThe following table describes how to perform basic actions in process model creation.

To... Perform this procedure...

Start a new process model

On the menu bar, select File New.

Open an existing process model

On the menu bar, select File Open.

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 steps

Press CTRL and then click each step; or, draw the pointer around 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 transitions

Position your cursor over a step until an arrow appears; click the 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 to the process model

On the main toolbar, select Undo.

Redo an action to the process model

On the main toolbar, select Redo.

Save a process model

On the menu bar, select File Save.


Saving a Process Model as a JPEG

Saving a Process Model as a JPEGYou can save the picture of the process model (in JPEG format) using the following procedure.

1 On the menu bar, choose File Save as JPEG.

2 Choose the name and location for the JPEG.

3 Click Save.

To Save a Process Model as a JPEG



C H A P T E R5
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


C H A P T E R 5 A d d i n g S t e p s t o a P r o c e s s M o d e l

OverviewSteps 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 model.

You add a step to a process model by placing its icon onto the 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 properties to steps.

You must assign step properties to all steps within the control of the business process (i.e., all steps not within external groups). For details, see “Flow Step Properties” on page 67.

Assign inputs and outputs to steps.

Inputs and outputs specify the information that should flow from one step to the next. For details, see Chapter 6, “Assigning Inputs and Outputs to Steps”.

Add logic to steps.

Logic specifies how steps perform their actions, for example, 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 between steps.

You draw transitions between steps to indicate the order in which 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 groups.

Modeler provides the option to place steps within groups if you 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

Flow Step Propert iesAs 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.

Note: The step name should be unique.

“Flow Step”. To change this, type a new name under the step or in the box next to the Label property.

Description Step description, e.g., “This step sends a purchase order to XYZ Corp.”. There is no limit to the length of the description.


Unique ID The internally-generated unique ID that Modeler assigns to the step.


Logical Server The logical server on which Modeler will generate and execute step logic.

Note: For details on replacing all existing logical servers in a process, see “Managing Logical Servers and Server Connections” on page 231.

The server designated as the Design Server. To change this, select a server from the drop-down list. Available servers correspond to those that have been set up through webMethods Administrator.



Folder The namespace folder to which Modeler will generate step components (e.g., flow services, triggers, etc.).

Upon generation, Modeler places this folder on each physical Integration Server associated with the process.

Note: This folder is located under the IS package corresponding to the process Package Name property.

Select a pre-existing folder from the list; or, leave this property blank and Modeler generates a folder named: ProcessName/LogicalServer Name.

Generated Flow Name

Name for the step’s generated flow service. Each step generates a flow service which in turn invokes another service (specifiable via Service to Invoke) to perform the step’s logic.

Equivalent to step name. You can override this by typing a new name in the box beside Generated Flow Name.

Service to Invoke

Flow or java service which the generated flow service will invoke to perform the step’s logic. Specifying a service to invoke at this time is optional; alternately, you can specify this after generating the model.

Important! Chapter 7, “Adding Logic to Steps”, provides important guidelines for creating the services that steps invoke.

If you specify a pre-existing Service to Invoke, Modeler generates a flow service with an INVOKE flow operation to invoke the specified service.

If you do not specify the Service to Invoke property, Modeler does nothing and you must create this service manually.

Correlation Service

Correlation service for the step. You assign these services to connect IS documents with the process instance; these services are 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.

To select a service, click the arrow and browse to the service.




Transitions The list of transitions (and transition-related properties) associated with the step. A transition can be one of five types: Normal, Error, Timeout, Retries Exceeded, and Else.

Note: For details, see “Overview of Transitions” on page 160.

Transition properties and their defaults are described on “Transition Properties” on page 162.

Retry Count The number of times to execute the step if the step fails.

Note: When you assign a Retry Count to a step, you must also create a Retries Exceeded transition to another step, as described in Chapter 8, “Creating Step Transitions”.

To change the default, type another number in the box next to Retry Count.

Join Type Join type associated with the step. You need to assign join types to steps that have multiple subscriptions or multiple input 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.

To choose a join type, select one from the drop-down list.




Join Timeout Timeout value for steps that are AND joins (or COMPLEX joins containing AND logic). You do not need to specify this property for any other type of join step.

Relative: The Timeout Value is the time (in 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”.

None. To define a Timeout Value, click Edit, choose the Timeout Type, then enter either a time in milliseconds or an XPath condition.

Step Timeout Timeout value for steps that are not based on a condition.

Relative: The Timeout Value is the time (in ms) during which step execution will occur before the timeout action will be taken. The 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.

Absolute: You can also set an absolute timeout for a step that will cause the step to execute until a set date and time, or based on an XPath condition.





Publish/Subscribe Filter

The publish/subscribe filter associated with the step. Filters enable you to specify conditions that the subscription or publication document must meet in order to be used by the step, e.g., subscribe to this document only when Field X has a value less than 10.

Note: For details, see “Using the Publish/Subscribe Filter” on page 139.

To assign a publish/subscribe filter, choose Edit. Details are provided in “Using the Publish/Subscribe Filter” on page 139.

Inputs/Outputs

The inputs and outputs (such as IS documents, external documents, etc.) associated with the step. This is the 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”.

To assign inputs and outputs to steps, click Edit.

Logged Fields Fields of the input/output documents that you want to log to the Process Audit Log so that you can view the fields in the Monitor.

Note: For details, see “Choosing Fields to Log For Monitoring” on page 138.

To choose document fields, click Edit.

Enable Resubmission

Whether to log this step’s pipeline to the Process Audit Log. If enabled, PRT logs the step pipeline. If disabled, PRT does not log the step pipeline.

Only steps whose pipelines were logged can be viewed in detail or resubmitted via webMethods Monitor.

This property is available only when the process model Logging Level property is “Process and All Steps”. When this property is available, it is enabled out-of-the-box; however, the default state of this property is controlled through Tools Options Steps Enable Resubmission.




Workf low Step Propert iesAfter adding a Workflow step, define its properties. These are described in the table below.

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



Label The name of the Workflow step.

Note: Assign steps a unique name.

“Workflow Step”. To change this, type a new name under the step or in the box next to the Workflow step Label property.

Description Workflow step description, e.g., “Approve purchase order”. There is no limit to the length of the description.




Logical Server The logical server on which the Workflow step’s components (i.e., implementation modules, projects, workflows) should generate and execute.

Important! For Workflow steps only, Modeler generates logic to two servers: the server defined here, and an Associated Server. Read “Workflow Step Generation and Multiple Servers” on page 206 for details.

To select a server, choose one from the drop-down list. This logical server should correspond to the physical Workflow server. Available servers correspond to those that have been set up through webMethods Administrator.


Workflow Step Properties

Project The Workflow project associated with the Workflow step. This project will contain an implementation module, which will in turn contain a workflow.

Select or type the name of a pre-existing project; or, type a name for a 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 Module

The implementation module associated with the Workflow step.

Type a name for the implementation module which Modeler will generate.

Note: If you leave this property blank, Modeler generates an implementation module named: StepName_IM.

Workflow to Invoke

The workflow associated with the Workflow step.

Select or type the name 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 Service












Workflow Step Properties


Possible join types are: AND, OR, XOR, and COMPLEX. For details, see “Join Steps” on page 88.















Publish/Subscribe Filter

The publish/subscribe filter associated with the step. Filters enable you to specify conditions that the subscription or publication document must meet in order to be used by the step, e.g., subscribe to this document only when Field X has a value less than 10.

Note: For details, see “Using the Publish/Subscribe Filter” on page 139.

To assign a publish/subscribe filter, choose Edit. Then choose Inputs or Outputs, and then choose the document on which you will base the filter.

Inputs/Outputs

The inputs and outputs (such as IS documents, external documents, etc.) associated with the step. This is the 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”.

To assign inputs and outputs to steps, click Edit.



Web Service Step Properties

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

Logged Fields Fields of the input/output documents that you want to log to the Process Audit Log so that you can view the fields in the Monitor.

Note: For details, see “Choosing Fields to Log For Monitoring” on page 138.

To choose document fields, click Edit.

Enable Resubmission







Label The name of the Web Service step.


“Web Service Step”. To change this, type a 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 Service Step”. There is no limit to the length of the description.




Logical Server The logical server on which the Web Service step’s components should generate and execute.

Default is Design Server. To select a server, choose one from the drop-down list. Available servers correspond to those that have been set up through webMethods Administrator.

Web Service Configuration

The Web Service configuration associated with the Web Service step.

Click Edit to display 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 Configuration dialog.

Operation The Web Service operation associated with the step.

The Web Service operation is set in the Web Service Configuration dialog.

Correlation Service







Enable Resubmission







Empty Step Propert iesThe 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 new name under the step or in the box next to the Empty step Label property.

Description Empty step description, e.g., “Invoke Search”. There is no limit to the length of the description.




Logical Server The logical server on which the Empty step’s components should generate and execute.






Empty Step Properties













Terminate Step Propert iesThe 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 new name under the step or in the box next to the Terminate step Label property.

Description Terminate step description, e.g., “End of Process”. There is no limit to the length of the description.




Logical Server The logical server on which the Terminate step’s components should generate and execute.



Step Functions and Step Types

Step Funct ions and Step TypesYou 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 StepsYou 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.

Join Type Join type associated with the step. The Terminate step will execute when process control is passed to it from any incoming transition and the join condition is satisfied.





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 StepsAs 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 StepsYou 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.

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

To Establish a Process-Wide Error Step



Join StepsJoin 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”.

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.

To Establish a Referenced Process Step



Example of 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 StepsYou 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.

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.)

To Edit a Referenced Process Step

To Establish a Subprocess Step



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.

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.

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.

From within a process model, select the subprocess icon, right-click, and select Extract steps from subprocess.

To Access and Edit a Subprocess

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.

To Restore a Subprocess to the Main Canvas



Working with Web Service StepsModeler 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 Interact ionsBefore 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


Working with Web Service Steps

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.

1 Choose File New 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 View Web Service Interactions to display the Web Service Interactions dialog.

To Define a Web service interaction



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 File Save 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 FileUse 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 TypesThere 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 TypesUse the Web Service Interactions dialog 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.

To define new process port types



Adding Web Service StepsFollow these instructions to add web service steps to your process.

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 ConfigurationUse the Web Service Configuration dialog to define the activity for the web service step. The choices are:

Invoke

Receive

Reply

1 Right-click on the web service step and choose Web Service Configuration from the menu. The Web Service Configuration dialog appears.

To add a Web service step

To Define Web service configuration



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 InvokeTo invoke a web service you use a Web Service Invoke step.

1 Select the Add new Web Service step button and place the step on the process model canvas.

2 Right-click on the web service step and choose Web Service Configuration from the 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.

To Define a Web Service Invoke step



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 InvokeThe 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 BindingFor 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.

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.

To use static binding



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=basicuser=Administratorpassword=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 BindingFor dynamic binding of WSDL to an endpoint reference, you will need to create an assign step which transitions to the web service invoke step.


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=basicuser=Administratorpassword=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.


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 bind the assign step from pipeline data

To bind the assign step from global data




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 BindingFor 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.


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 FieldsWSDL elements map to EndPointReference document fields as follows:

To copy binding from another web service interaction

To use deployment-time binding

WSDL Element EndPointReference Field

<soap:address location='address-value'/> address

<portType name='portType-value'/> portType

<soap:body namespace='namespace-value'/><operation name='operation-value'/><soap:operation soapAction=’soapAction-value'/><soap:binding style='style-value'/><soap:binding transport='transport-value'/>

operation.namespaceName operation.localNameoperation.Service.soapActionbinding.soapBinding.soapStylebinding.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:

Web Service ReceiveTo perform web service receive in Modeler, you define a web service receive step.



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 or New Global Data from the Input Variable drop down list.



At this point your web service receive step will be completely configured within the process model. Generate the model to create the process package.

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

To Define a Web Service Receive step



Web Service ReplyA 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.



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 or New Global Data from the Input Variable drop down list.



At this point your web service receive step will be completely configured within the process model. Generate the model to create the process package.

Guidel ines on Using Workf low StepsUse 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.

To Define a Web Service Reply step


Controlling the Visual Properties of Steps

Control l ing the Visual Propert ies of StepsThere 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 TypeModeler 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.

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 OutputsFor steps on how to control the display of step inputs and outputs, see “Controlling the Display of Inputs and Outputs” on page 137.

Note: You cannot change the icon for Workflow steps.

To Change the Icon of a Single Step



C H A P T E R6
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


C H A P T E R 6 A s s i g n i n g I n p u t s a n d O u t p u t s t o S t e p s

OverviewStep 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 StepsThere 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.

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.

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.


Assigning and Editing Step Inputs

How Information Flows through the Business ProcessEach 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.

Assigning and Edit ing Step InputsThe 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 DocumentsStart 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.

.

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

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



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.



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: 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.

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

Adding a Subscription to a Publishable IS DocumentWhen 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.


Note: For details on specifying transition conditions, see “Building Transition Conditions” on page 163.

To Add a Subscription to a Pre-Existing Document



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.

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.



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 DocumentsYou 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.


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.

To Edit the Name (or Role) of a 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 File Lock. 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 File Unlock.


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



Deleting Subscription Documents Use the following procedure to delete a subscription document.

1 Right-click on the step and choose Edit Inputs/Outputs; or, from the step’s Inputs/Outputs 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.

Input DataYou 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 Delete an Existing Subscription Document

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.

To Add Input Data to a Step



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.


Note: In the example above, the step has already been assigned an input in the form of a publishable IS document subscription named “PO”.



Editing Input Data Instance NamesYou 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.


2 In the Inputs box, select the input you want to delete and click Delete. The input is deleted from the step.


Assigning and Edit ing Step OutputsYou 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.

To Delete Existing Input Data

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

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.


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.

To Add a Publication to a Pre-existing IS Document



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.



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.

To Add a Publication to a IS New Document



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.

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 moving the process model into production.


Editing Publication DocumentsYou can edit the instance name or contents of a 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 Instance Name 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.


To Edit the Contents of an Existing Publication Document



Deleting Publication DocumentsUse the following procedure to delete a subscription document from a step.


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.

Output DataYou 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 DataWhen 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 Delete an Existing Publication Document

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.




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 Pre-existing 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.

To Add New Output Data to a Step



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.

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.


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.

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 In the Outputs box, select the document whose instance name you want to change and click Edit Output. The Edit Output window appears.

3 In the Output Name field, type a new instance name and click OK.


To Edit Existing Output Data Instance Names



Deleting Output Data Use the following procedure to delete output data from a step.


2 In the Outputs box, select the document you want to delete and click Delete. The output is deleted from the step.


FieldsYou 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 Delete Output Data

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.

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.

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.


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.



Editing FieldsIf you want to change the instance names for existing output data fields, use the procedure below.


2 In the Outputs box, select the output field whose instance name you want to change and click Edit Output. The Edit Output window appears.

3 In the Output Name field, type a new instance name and click OK.


To Edit the Instance Names of Existing Output Data Fields



Deleting Fields Use the following procedure to delete fields from a step.


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.


Publ icat ion and External DocumentsYou 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 DocumentTo 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”.

To Delete Existing Output Data Fields

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.


Controlling the Display of Inputs and Outputs

Control l ing 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.

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: Subscription documents and publication document names appear with a dotted border while all other inputs and output names appear with a solid border.

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 Fie lds to Log For MonitoringAfter 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

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.

Using the Publ ish/Subscribe Fi l terWhen 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.

To Choose Fields to Log to the Process Audit Log



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.

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.

To Use the Publish/Subscribe Filter


Using the Publish/Subscribe Filter

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 Condit ionsThe 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

Working with Global DataGlobal 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.

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 Value/Field

To complete the publish/subscribe condition, you can either enter 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.




How Global Data WorksGlobal 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 ProcessTo 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.

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.

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.

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.

To define global data


Working with Global Data

Defining Data Propert ies and Data AliasesTo support BPEL processes, data properties and data aliases may be defined. To define data properties for use in a process, follow the steps below.

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.

To define data properties



C H A P T E R7
Adding Logic to Steps
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Working with Flow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Working with Workflow Step Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

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


C H A P T E R 7 A d d i n g L o g i c t o S t e p s

OverviewLogic 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.

Working with Flow Step LogicThe following sections describe information to keep in mind when working with flow step logic.

How Modeler Generates Flow Services for Flow stepsWhen 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

Note: For details on using webMethods Developer to create flow services, see webMethods Developer User’s Guide.


Working with Flow Step Logic

Generated Flow Service property; by default, Modeler gives the generated flow service the name of the step.

Guidelines for Working with Step LogicAfter 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.

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: See “What Modeler Generates for a Process Model” on page 201 for details on where Modeler generates flow services.

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.

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.



PRT Services that You Might Want to Use in User-Defined ServicesThe 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.

Select ing a Service to Invoke for a StepTo select that a step invoke an existing service at design-time, use the following procedure.

1 Open the process model.

2 Right-click on the step that should invoke the service.

3 Choose Select Service to Invoke.

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.

To Select a Service to Invoke for a Step


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 Workf low Step LogicWhen 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 ComponentsAfter 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.

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


2 Right-click on the Workflow step.

To Select a Workflow to Invoke for a Workflow Step



3 Choose Select Workflow to Invoke.

4 Browse to the Workflow project to invoke and click Select.

Working with Correlat ion ServicesSome 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.

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 TasksIn 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.

Note: A Workflow server connection dialog might appear if you are not connected to the Workflow server. Enter your user name and password.

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.


Working with Correlation Services

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 IDBefore 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 IDsYou 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 Correlat ion ID-to-PID Mapping Wil l 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 ServiceFor 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.

Input/Output Specification for the Correlation ServiceWhen your correlation service receives control, it is passed the following inputs:

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 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").



Your correlation service should return the following output:

For more information about the pub.prt:CorrelationService service (which is in the WmPRT package), see the webMethods Built-In Services Reference.

DocumentType String The name of this document type (e.g. "orders.sap:OrderDocument").

Document document (IData object) The document.

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

Input variable Description



Assigning a Correlat ion Service to a StepThe following sections describe how to assign a correlation service to a step, and how to edit or delete an existing correlation service.


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.


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


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.

To Assign a Correlation Service to a Step

To Edit an Existing Correlation Service

To Delete a Correlation Service



Broadcasting Correlat ion IDsThe 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.



C H A P T E R8
Creat ing Step Transit ions
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 Transi t ionsYou 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 Transit ions Allowed Per StepFor 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


Creating Step Transitions

Creat ing Step Transit ionsFollow the steps below 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.

To Create Step Transitions



Transi t ion Propert iesAfter creating a transition, specify its properties. These are described below.


Label Name for the transition, e.g., “Step 4 to Step 5”.

Type a name in the box besides Label.

Description Full transition description. There is no limit on description length.

Type a description in the Edit box.

Transition Type

The type of transition. Transition types include Normal, Error, Timeout, and Retries Exceeded, and Else. For definitions, see “Overview of Transitions” on page 160.

Normal. To choose another type, select a type from the drop-down list.

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., transition to target step only if value of Name field is “Authorized”. You can specify conditions for Normal transitions only.

Note: For steps on setting transition conditions, see “Building Transition Conditions” on page 163.

To enter a condition, click the Edit button.

Line Style The type of line style (e.g., curved or straight) for the transition.

The default line style corresponds to the default process Line Style, specified at the bottom of the process window.


Splitting, Branching, and Joining Logic in a Process

Spl i t t ing, Branching, and Joining Logic in a ProcessDepending 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 Conditions” on page 163.

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

Bui lding Transit ion Condit ionsA 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 Transit ion Condit ionsUse the following procedure 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.

To Define a Transition Condition


Building Transition Conditions

Edit Transit ion Condit ions 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 Value/Field

To complete the transition condition, you can either enter 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 Type a detailed description of the condition. Optional.



Building Transition Conditions

Defining Transit ion Condit ions Using XPath ExpressionsUse the following procedure 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 XPathThe following built-in BPEL functions can be used to access global data:

bpws:getVariableProperty(‘variableName’,’propertyName’)bpws:getVariableData(‘variableName’,’partName’,’locationPath’)

To Define a Transition Condition using an XPath expression



Guidel ines for Transit ionsUse the following guidelines when working with transitions.

General GuidelinesEnsure 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.


Guidelines for Transitions

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 Transit ions that Create Spli ts and JoinsKeep 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

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.

Three threadsarriving at differenttimes. Each threadcontinues.

Six threadsarriving



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

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.

It is not predictable whetherthe values in the resultingpipeline will be from thethread that executed Step Aor the thread that executedStep B.



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 Transi t ions

Displaying/Hiding Transit ions TypesIf 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 Tools Options and check or uncheck the Show Transition Types property.

Controll ing the Color of Transit ions

Default TransitionsYou can specify a default color for Normal transitions by choosing Tools Options and selecting a color from the Line Color property.



Other TransitionsYou can specify that the other transition types (Timeout, Error, and Retries Exceeded) each display as distinct colors. To do so, choose Tools Options and enable Color Transition Types.

Note: You cannot change the colors that Modeler assigns to these transition types.



C H A P T E R9
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


C H A P T E R 9 A d d i n g G r o u p s t o a P r o c e s s M o d e l

OverviewYou 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

Adding a GroupTo add an internal or external group to a process model, use the following procedure.

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.

To Add a Group to a Process Model

External groups box stepsthat are performed outside

your enterprise.

Internal groups box stepsthat are performed within

your enterprise


C H A P T E R 9 A d d i n g G r o u p s t o a P r o c e s s M o d e l

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 Transit ionsYou 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 GroupsYou 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 GroupsBy 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



C H A P T E R10
Import ing and Export ing BPEL Process Models
Importing BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Exporting Process Models in BPEL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190


C H A P T E R 1 0 I m p o r t i n g a n d E x p o r t i n g B P E L P r o c e s s M o d e l s

Import ing BPEL Process ModelsComplete the following steps 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.

To import a BPEL process model


Importing BPEL Process Models

BPEL MappingsThe 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 definitions

Integration server document definitions

BPEL Basic Activities:

<receive>

<reply>

<invoke>

<terminate>

<empty>

<assign>

<throw>

<wait>

Web Service Receive Step

Web Service Reply Step

Web Service Invoke Step

Terminate Step

Empty Step

Assign Services in PRT

Not supported

Flow step, with user-added code for the wait time.

BPEL Structured Activities

<compensate>

<while>

Not supported

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>

<scope>

<switch>

<flow>

<pick>

No effect, flow retains sequence

Not supported

Transitions logically equivalent to the switch

Transitions from preceding activity to each activity defined in the <flow> activity.

Multiple receive steps with XOR join


Partner LinksThe 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 Definit ionsBPEL 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 Activit iesThe following activities are mapped directly to the corresponding type of web service step:

ReceiveThe 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 = LoanFlowoperation = initiateOutput variable = input



ReplyThe 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 = Defaultoperation = "Execute"Input variable = "UANG_SyncAccount_fault"

InvokeThe 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 = CreditRatingServiceoperation = processinputVariable = "crInput"outputVariable = "crOutput"

Terminate ActivityThe BPEL <terminate> activity is imported as a terminate step.

Empty ActivityThe BPEL <empty> activity is imported as an empty step.

Wait ActivityThe 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 ActivityThe 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 ActivityModeler 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 Activit iesThe following is a list of BPEL structured activities and their equivalents in webMethods Modeler:

SequenceThe 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.



ScopeActivities and their ordering in the BPEL <scope> activity is maintained, but scope-specific constructs such as compensation and fault handling are currently ignored.

SwitchThe 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 LinksA 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 LinksThe 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.

PickThe 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.



Export ing Process Models in BPEL FormatModeler 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 GuidelinesA 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.


Exporting Process Models in BPEL Format

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>



BPEL Export Detai lsThe 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> <variablemessageType="wsdl1:LoanFlow_MessageTypes_pollLoanFlowResultSoapResponse" name="pollLoanFlowResultSoapResponse"/>

The message “pollLoanFlowResultSoapResponse” points to the message type definition at wsdl1.

<variablemessageType="wsdl1:LoanFlow_MessageTypes_onLoanFlowResultSoapRequest" name="onLoanFlowResultSoapRequest"/> <variablemessageType="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"/>

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.

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.

To export a process model in BPEL format



C H A P T E R11
Generat ing 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 Generat ionAfter 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

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.

Workflow

Design Server

IS

IS

IS IS

WmModeler package

Modeler


What Modeler Generates for a Process Model

What Modeler Generates for a Process ModelWhat modeler generates depends on whether the step is associated with an Integration Server, or the step is a Web Service or Workflow step.

I tems Generated for Steps Associated with Integrat ion ServersThe 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:

Generated itemType of 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.



IS folder for the process

process Label Modeler creates an IS folder in the 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 the logical servers

step Logical Server Modeler creates one IS folder named for each logical server referenced in the 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.




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 Flow Name

The value of the Generated Flow Name step 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 Invoke

If you specify the Service to 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.




Sample Process Model and Generated Run-time ElementsThe 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

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-time script

step Logical Server Modeler creates one process run-time 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.




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

Generated run-time elements for the process model

I tems Generated for Web Service StepsFor Web Service steps, Modeler generates services depending on the Web Service activity: Receive/Reply, or Invoke.

Web Service Receive/Reply StepModeler 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 StepModeler 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.

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 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.

Generated flow service for Step2 is given the name “SpecifiedServiceName” that was specified on the Generated Flow Name property.



I tems Generated for Workflow StepsFor 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 Step Generation and Multiple ServersFor 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.

What Modeler Generates to ServersThe 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.


Workflow Project

An implementation module can contain one or more workflows. Modeler generates an implementation module that contains a single workflow.workflow

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.

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.



Generated itemType of property Property

How Modeler uses the property during 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.


step LabelUnique ID

Modeler generates an 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 Module

The value of Implementation 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.



Consequences to Changing the Associated ServerIt 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.

Workflow step Workflow to Invoke

Modeler references the workflow you specify. If you do not specify the Workflow to Invoke property, Modeler generates an empty workflow.

step LabelUnique ID

If Modeler generates an empty 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.

Generated itemType of property Property

How Modeler uses the property during generation


Validating a Process Model Before Generation

Val idat ing a Process Model Before Generat ionIn some cases, particularly for larger and more complex process models, you may want to validate the process model before generating it.

1 If the process model you want to generate is not already open, open it.

2 Select Tools Validate 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 ModelYou must take the following actions before you can execute a process that uses your process model:

STEP 1: Generat ing a Process ModelYou 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.

1 If the process model you want to generate is not already open, open it.

2 Select Tools Generate Business Process.

If Modeler encounters errors when generating the process model, it displays error

messages. The error messages are preceded with in the Implementation

To validate a 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.

To generate a process model



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 ModelIf 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.

Before You Can Execute a Regenerated Process ModelAfter 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:

Note: If you make visual changes, such as adding text, adding notes, or moving lines and icons around, you do not need to regenerate.

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.


STEP 1: Generating a Process Model

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 being used for the name of the generated package (i.e., before you made the change, the Label property was the same as the Package Name property)

Modeler generates a new package using the new value of the Label property if the package does not already exist.

Modeler does not rename the folder named for the 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 not being used for the name of the generated package (i.e., you specified a different value for the Package Name property)

Modeler makes no change. The folder named for the process model continues to use the original value of the Label process property.



Change the ‘Package Name’ process property

Modeler generates a new package using the new 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 being used for the name of the generated flow service (i.e., before you made the change, the Label property is the same as the Generated Flow Name property)

Modeler renames the generated flow service for the step to the new value of the Label step property.

If the Label step property is not being used for the name of the generated flow service (i.e., you specified a different value for the Generated Flow Name property)

Modeler takes no action.

Change the ‘Generated Flow Name’ property

Modeler renames the generated flow service for 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’ step property for a step

Modeler regenerates the flow service preserving 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 server is associated with the same physical server

If the package for the process model does not already contain a folder for the newly selected 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 server is associated with a different physical server

Modeler generates new flow services, trigger, and process run-time script on the new physical 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 model

Modeler deletes the flow service that it generated 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 documents for a step

Modeler changes the Input/Output variables for 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 ‘Project’ and ‘Version’ step properties

Note: You must clear the Workflow to Invoke property before you can change the Project property.

If the project that you specify does not exist, Modeler generates it.

Modeler generates a new implementation module in the newly specified project and version.

If you did not use the Workflow to Invoke property to specify an existing workflow in the new project, 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 property and/or the ‘Label’ step property

Modeler makes no change. If your current implementation module and/or workflow have names based on the old label fields, they will continue to use the same names.

Change the ‘Logical Server’ step property and the new logical server is associated with a different physical server

Modeler generates all run-time elements as needed to the new physical server.

Modeler preserves all old generated run-time elements on the old physical server.

Change the ‘Implementation Module’ step property for a step

Modeler renames the generated implementation module to use the new name that you specify.



Troubleshooting Process GenerationThe following lists the errors that you might encounter when generating a process model, their causes, and the actions to take to resolve the errors.

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.

Clear the ‘Workflow to Invoke’ step property for a step

Modeler generates an empty workflow.

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’ step property for a step

Modeler updates the generated implementation module so that it invokes the newly specified workflow.

Modeler preserves the old workflow.

Delete a Workflow step from the process model

Modeler preserves all generated information for the deleted step.


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.



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 MessagesIn 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: Optional ly Adding Logic to Generated Run-t ime 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.

Adding Logic to Flow ServicesAfter 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 WorkflowsAfter 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 Avai lable for Monitor ingTo 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.

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 Tools Update Model for Monitoring.

Important! Never make changes to the generated triggers.

To update a process 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: Enabl ing Process ModelsAfter 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.

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.

To enable a process model



C H A P T E R12
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


C H A P T E R 1 2 M a n a g i n g P r o c e s s M o d e l s

OverviewTasks 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.

Updat ing Process ModelsYou 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 ModelModeler 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.

1 From an active process model, choose File Save 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.

To Create a New Process Model by Saving it as a New Version



Delet ing Process ModelsModeler’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.

1 From an active process model, choose File Delete 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.

To Delete an Existing Process Model


Exporting and Importing Process Models

Export ing and Import ing Process ModelsWhen 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.

Exporting Process ModelsYou can export an active process model, or you can export multiple processes simultaneously. See the following procedures.

1 Start Modeler and open the process model that you want to export.

2 Select File Export Current Process as Complete Model.

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”.

To Export an Active Process Model

Note: If you want to export the model as Portable Format, choose File Export Current Process as Portable 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.

1 From the Modeler main menu, select File Export Other Processes as Complete Model.

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

1 From the Modeler main menu, choose File Import.

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.

To Export Other (or Multiple) Process Models

Note: If you want to export the model as Portable Format, choose File Export Other Processes as Portable Format.

To Import a Process Model


Managing Logical Servers and Server Connections

Managing Logical Servers and Server Connect ionsThe following sections describe how to manage logical servers and server connections.

Managing Logical Servers in the ProcessModeler 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.


2 From Modeler’s main menu, select Tools Replace 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 ConnectionsModeler’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”.

To Replace all Instances of a Logical Server in a Process Model



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

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.

1 From Modeler’s main menu, select View Server Connections.

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.

To Access the Server Connections Dialog



C H A P T E R13
Moving Process Models to Product ion
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


C H A P T E R 1 3 M o v i n g P r o c e s s M o d e l s t o P r o d u c t i o n

OverviewThis 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 ProductionFor 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

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

Development ProductionAccountingFinancePurchasing FinanceAccounting Purchasing

All logical servers map to a single physical server. Each logical server maps to a different physical server.

ISIS ISIS


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.

I tems that You Need to MoveTo 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.

Ident i fying the I tems You Need to MoveFrom 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 ContainsIn 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


Identifying the Items You Need to Move

The following shows a sample deployment list.

Sample deployment list

The name of the step withwhich a service is

associated is listed inparentheses

Name of a logical server

Items on the logical server“Accounting”

Name of the process model



Generating the Deployment ListPerform 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.

1 From Modeler, select View Deployment Information.

2 To save the information to view later, click either Save to text file or Save to HTML file.

Moving I tems that Reside on Integrat ion ServersTo 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).

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


Moving Items that Reside on Integration Servers

Moving Integration Server items from development servers to production servers

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-t ime ElementsFrom 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 PackageThe 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.

Development ProductionAccountingFinancePurchasing

FinanceAccounting Purchasing

IS

Logical server =

Physical servers = devel.company.com:5555 acctg.company.com:5555 fin.company.com:5555 purch.company.com:5555

Accounting ItemsFinance ItemsPurchasing Items

ISAccounting Items

IS

Purchasing Items

acctg.company.com:5555

IS

Finance Items

Logical server s=



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.

For more information about the items that Modeler generates and where Modeler places these items, see Chapter 11, “Generating Process Models”.

Run-time elementDefault or Folder property Where Modeler places the run-time element

process run-time scripts

Either In the config\wmprt directory of the package.

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 property

Modeler places the flow service in the folder 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.



Creating Releases Based on Your Logical-to-Physical Server MappingsHow 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

In this situation, the move of the generated run-time elements is straight forward.

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.

IS ISIS

Development Production


ISAccounting Items

Purchasing ItemsFinance Items

IS


ISAccounting Items

Purchasing ItemsFinance Items

To move generated run-time elements when logical-to-physical mappings are the same



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

The logical-to-physical server mappings are not equivalent.

Example of logical-to-physical server mappings that are not equivalent

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.

Development ProductionAccountingFinancePurchasing FinanceAccounting Purchasing

ISAccounting ItemsFinance ItemsPurchasing Items

ISAccounting Items

IS

Purchasing Items

IS

Finance Items

Development Production

AccountingFinance Finance

AccountingPurchasing

ISAccounting ItemsFinance Items

IS IS

Purchasing Items

IS

Finance ItemsAccounting Items

Purchasing Items

Purchasing



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

To move generated run-time elements when logical-to-physical mappings are different

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 I temsYou 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 I tems that are Stored in Trading NetworksIf 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

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 I tems that Reside on webMethods Workf low ServersIf 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

To move items stored in Trading Networks



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 Product ion Process Audit LogTo 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

To move your tested Workflow deployment to your production environment

Note: Scripts used to export the necessary tables are available on the webMethods Advantage website.



A P P E N D I XA
Tuning Performance and Qual i ty 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

OverviewService 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 Compatibi l i tyThe 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.

Qual i ty of Service vs. PerformanceQuality 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 PerformanceWhen operating in a maximum quality of service (minimum performance) environment:

BenefitsProcesses 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

CostsEach process takes longer to complete, and/or fewer instances complete per time period.

Maximum Performance: Minimum Quality of ServiceWhen operating in a maximum performance (minimum quality of service) environment:

BenefitsProcesses complete more quickly, and/or more instances complete per time period.

CostsProcess 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

Configur ing the System to Meet Your NeedsThe 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 OverviewThe 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 1: Conf igure the Terr i torySome 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 Terri toryYou tune the territory by tuning the PRT configuration settings of each integration server in the territory.

Step Description Perform this on... See page...

1 Configure the territory. PRT home page 250

2 Configure process-level settings. Modeler:

Process Model Options


256

3 Optionally change step pipeline logging.

Modeler Step Properties 269

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.


STEP 1: Configure 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.

To Tune The Territory

Setting Description Default

Central Process Tracking Store

Check this box if you want to use a central (vs. distributed) Process Tracking Store. The Process Tracking Store is where internal process transition documents are stored. For a comparison of the 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.

On. The territory is set up for central Process Tracking Store.



Process Completion Tracking Server

Check this box if you would like this server to be the designated Process Completion Tracking Server in the territory. This server tracks process completion in a distributed Process Tracking Store environment. For details, see “Choosing a Process 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.

Off. No server is designated as the default Process Completion Tracking Server.

Database Connection Retries

Maximum number of times to try to connect to the Process Tracking Store database.

1000

Database Connection Retry Time Interval (sec)

How frequently to retry connection to the Process Tracking Store database.

5 seconds

Database Cleanup Interval (sec)

How frequently the PRT removes information from the Process Tracking Store database.

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).

600 seconds




Associated Pool Alias

The JDBC pool alias for the Process Tracking Store database.

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.

Identical to the Process Audit Log Pool Alias

Join Queue Lock Expiration (sec)

The maximum length of time to wait between processing multiple join inputs received simultaneously.

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.

10 seconds

Process Lock Expiration (sec)

The maximum length of time to wait between processing multiple process status changes received simultaneously.


10 seconds




4 After modifying any default values, click Submit to save changes.

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 StoreThe 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 StoreIf 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

Step Lock Expiration (sec)

The maximum length of time to wait between processing multiple step inputs received simultaneously.


10 seconds


Note: Clicking the Default button causes the PRT to revert to the default values.



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 StoreIf 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 EnvironmentsIf 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: Conf igure Process-Level Sett ingsThe 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 1: Choose Global Default Process Sett ingsThe 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.

Step Description

1 Choose global default process settings.

2 Tune individual process model settings.

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.


STEP 2: Configure Process-Level Settings

1 Start the Modeler.

2 Choose Tools Options.

3 Check or uncheck the Steps Enable Resubmission option to enable or disable it.

Step 2: Tune Individual Process Sett ingsYou 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.

To Change the Default Step Pipeline Logging Value

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 Enable Resubmission.



Process Model Property Description Default For details, see...

Logging Level

Determines the level of persistence to the Process Audit Log, and hence the level of visibility and control in webMethods Monitor.

Logging Levels are:

None

Errors Only

Process Only

Process and Start Steps



“Choosing a Logging Level” on page 260

Volatile Tracking

Specifies whether the integration servers hosting the process should store process transition documents in the Process 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.

Enabled “Using Volatile Tracking” on page 262

Volatile Transition Documents

Specifies whether the Broker should store process transition documents to hard disk or in RAM. If this property is enabled, Broker uses RAM. If it is 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.

Enabled “Using Volatile Transition Documents” on page 264



Optimize Locally

Specifies whether servers should publish process transition documents between execution of adjacent steps on the same 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.

Enabled “Optimizing the Process Locally” on page 264

Local Correlation

Specifies whether to save correlation IDs on the local server that created them, or whether it is necessary to broadcast them to different servers in the process.

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.

Enabled “Managing Correlation IDs in a Distributed Environment” on page 267

Process Model Property Description Default For details, see...



Choosing a Logging LevelThe 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.

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.

Logging Level Description Effect

None The PRT does not log process status (Started, Suspended, Failed, Completed) or step status (Completed, Started, Error, Waiting).

You cannot view the process through Monitor nor resubmit any of its steps.

Errors only Upon error, the PRT logs process status and the failed step pipeline.

You can view failed process status through Monitor and resubmit at the failed step only.

Process only The PRT logs process status, but not step status. If a step fails, the failed step pipeline is logged.

You can view process (but not step) status in the Monitor; you can resubmit the process (at a failed step) only in the event of step failure.



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


Process and start steps

The PRT logs process and start step status, as well as the start step pipeline. If a step fails, the failed step pipeline is logged.

You can view process and start step status; you can resubmit the process at the start step or at a failed step, in the event of step failure.

Process and all steps

The PRT logs the status of the process and all of its steps.

You can view the status of a 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 Description Effect



Modeler prohibits document field logging in association with the remaining levels:

None

Errors only

Using Volatile TrackingFor 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

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.



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.

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.

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.



Using Volatile Transition DocumentsFor 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 LocallyFor 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 EnvironmentFor 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)

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.

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.



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.

If the Sample Process Had Not Broadcast Correlation IDs: The PRT would have begun a new instance of the process at “processJob” step.

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.


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.

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: Opt ional ly Modify Step Pipel ine LoggingYou 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.

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 ProcessesIf 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.

Note: Using the previous model as an example, you would assign the “ProcessJob” and “routerScheduleRequest” steps the same physical server.

To Modify Step Pipeline Logging for Individual Steps



A P P E N D I XB
Guidel ines 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


A P P E N D I X B G u i d e l i n e s f o r W o r k i n g w i t h R e f e r e n c e d P r o c e s s e s

Introduct ionAs 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 OverviewThe 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 TimeWhen 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

Referenced Process Step Propert iesIn 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.

Referenced Process Step Properties

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.



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 Chapter 8, “Creating Step Transitions”.

Property Definition


Design-Time Guidelines

Design-Time Guidel inesUse the following guidelines when designing business processes containing referenced process steps.

Assigning Inputs and Outputs to Referenced Process StepsWhen 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 ConsiderationsUse 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.

Assigning a Return Join TypeReview 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 FeatureAt 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

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.



I f a Referenced Process Step is Hot-SwappableWhen 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

For details on using webMethods Monitor to enable and disable business processes, see the webMethods Integration Platform Logging and Monitoring Guide.

I f a Referenced Process Step is Not Hot-SwappableWhen 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.

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.



A P P E N D I XC
Migrat ing 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


A P P E N D I X C M i g r a t i n g 4 . 6 P r o c e s s M o d e l s t o M o d e l e r 6 . 1

Introduct ionThis 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.

OverviewWhen 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 Assigned via Implementation Systems

Servers Are Assigned via Logical Server Assignments

In Modeler 6.1, implementation systems no longer exist. Instead, all steps are assigned a logical server to designate where step logic 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 Assigned via Implementation Systems

Discreet Step Types

In Modeler 6.1, there are three categories of step types: Flow, Web Service, and Workflow. In 4.6, these discreet step types did not exist. During 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 Transitions Designate Publications and Subscriptions

Publications and Subscriptions are Assigned to Steps

In Modeler 6.1, external groups are used purely as visual aid. Steps within external groups and transitions to/from external groups are aids that make it easier to conceptualize the phases of a 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.




Basic Steps in Process Model Migrat ion 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.

Transition Conditions Assigned to Steps (Tasks)

Transition Conditions Assigned to Transitions/ Existence of Transition Types

In Modeler 6.1, you assign each transition to be one of several possible types, including Normal, Retries Exceeded, Timeout, Error, and Else. You place transition conditions (such as transitioning based on the value of a field in a document) on Normal transition 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.



Ensuring the Model is 6.1-Ready

Ensuring the Model is 6.1-ReadyBefore 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 StepThe 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.

Ensure All Documents in the Model Exist on the 6.1 PlatformThe 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 Transit ions and Transit ion Condit ionsAs 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 ConditionsMost 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.

Note: The migration utility sets an uncontrolled step’s logical server to empty, since these steps do not need to be associated with servers.



Migration of Trading Networks “Status”-Based Transition ConditionsModeler 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:

If a 4.6 Step Has TN “Status” Conditions and Other ConditionsIf 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.

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.


Index

Index

Numerics4.6 process model migration 280

Aactivity messages

PRT service that creates and logs 150AND joins

and return join types 274definition 89forming 25run-time guidelines 171use with transition conditions 171

annotations to process modelnotes 27text 27

architecturedesign time for process 20process generation 200run-time for processes 28webMethods platform and webMethods Modeler 17

Associated Pool Alias, PRT setting 253Associated Server

and process generation 206changing assignment 232consequences to changing 208definition 206, 232

authentication, Modeler repository 21

BBIML schema document 229BPEL4WS 32branches

definition 25, 163forming 163

Brokerand webMethods Modeler architecture 18description 18publishing IS documents to 125

subscribing to IS documents from 115use during process run time 29

Business Process Execution Language (BPEL) 32business process management

and webMethods Modeler 17definition 17

Ccanvas

definition 41working with grid settings 41

Central Process Tracking Storedefined 251, 254PRT setting 251

changeProcessStatus servicedescription and usage 150

changinga process’s run-time status 150a step’s user-defined service 149consequences to changing Associated Server 208logical servers in process 231Modeler repository storage mechanism 47one referenced process step for another, caution 277step icons 105updating process models 226

child process, definition 272collapsing several steps into single icon 25Complete Model import/export format, defined 229Complex join

and return join types 274definition 89

controlled stepsand internal groups 26, 178definition 23items generated for 28

controllinga process’s run-time status 150appearance of groups 180display of transition types 175


I n d e x

inputs/outputs display 137logical server connection state 232transition colors 175visual properties of steps 105

conventions used in this document 13correlation IDs

and the Local Correlation property 59, 259, 267, 268managing across distributed servers 59, 259, 267, 268mapping to process instance ID (PID) 154tips for creating 153

correlation servicesand correlation ID 152checklist for working with 152correlation ID-to-PID mapping 154definition 152editing 157importance of unique ID among all processes 153, 155importance of using in only one process model 153, 155inputs and outputs 155procedure for assigning to steps 157procedure for creating 155when steps don’t need 152when steps need 152

creatingcorrelation ID-to-PID mapping 154correlation services 152, 155distinct pipeline variables for split logic threads 172end steps 86fields to log for monitoring 138groups 178, 179inputs to steps 109joins 88logic that affects step run-time status 150logic to send external documents from steps 136new process model version 227outputs from steps 124process models 51process-wide error steps 87publications from steps 125publish/subscribe filters 140, 144, 145referenced process steps 89, 272regular step logic 149splits, branches, and joins 163

start steps 85subprocesses 90subscriptions to steps 110transition conditions 163transitions 160, 161Worklfow logic 151

DDatabase Cleanup Interval (sec), PRT setting 252Database Connection Retries, PRT setting 252Database Connection Retry Interval, PRT setting 252databases

Process Audit Logand Process Tracking Store (PRT) database 253changing from flat file to database storage 47description 19moving process model to for monitoring 246use during process run time 29warning about Oracle database drivers 47

PRT (Process Tracking Store)configuring 253using central vs. distributed 254

definitionsAssociated Server 232branches 25, 163business process management 17Central Process Tracking Store 251, 254child and parent process 272controlled and uncontrolled steps 23correlation ID 152correlation services 148, 152Design Server 18Express Pipeline 55external documents 24filters 24, 139Focal Role 54generated flow services 148groups, internal and external 26, 66, 178hot-swappable 273, 277input/output data 24, 108IS documents 24joins 25, 163logical servers 20


I n d e x

Modeler repository 18modeling 16performance 248Process Completion Tracking Server 252process control documents 29process models 22Process Reference property 273process run time (PRT) 29process run-time scripts 27Process Tracking Store 251, 254process transition documents 29, 254publications and subscriptions 24, 108quality-of-service 248referenced process 25, 272referenced process steps 272return join type 274return timeout 274sender/receiver roles 112splits 25, 163steps 23subprocess 25territory 18timeout value for steps 70, 75, 76, 80, 83top-down vs. bottom-up development approach 30transition types 26, 160transitions 25, 160

deletingprocess models 228steps in process models and process regeneration 214, 216

deploying process modelscreating release of package for logical server 243items to move 235logical-to-physical server mappings 234, 238moving items from Integration Servers 238moving Modeler generated items on Integration Servers 239moving to production audit logging database 246moving Trading Networks information 245moving Workflow information 245using Trading Networks export/import data feature 245

Design Serverand the Associated Server 206, 208description 18use at design time 21

development approachdescription of types 30, 182, 197

development environmentbefore deploying process models 234tasks to complete in 31vs. production environment 31

diagramsprocess generation architecture 200run-time architecture for processes 28sample process model 22webMethods Modeler design-time architecture 20webMethods platform and webMethods Modeler 17

documentationadditional 13conventions used 13feedback 13

documentsexternal, see external documentsprocess control documents 29process transition documents 29, 254publication, definition 108publishing from steps 24, 125restricting documents used by process model 24, 139subscribing steps to 24, 110subscription, definition 108Trading Networks, see external documentsusing filters 24, 139

EEdit Transititon Conditions window 165else transitions

creating 161definition 26, 160

Empty Step Properties 82Enable Resubmission property 71, 77, 81, 256, 261, 269error messages

issued during process generation 216error transitions

creating 161definition 26, 160

Express Pipeline property 55and step inputs/outputs 109defined 55


I n d e x

external documentsand sender/receiver roles 112definition 108deployinig with process model 245enabling steps to access 112guidelines for subscribing to start steps 113how to have steps send 136inability to "publish" 136keeping distinct among logical servers 113purpose of "publishing" 136sender role 112subscribing steps to 110when to define 50

external groupscreating 179definition 26, 178warning about transition conditions 163, 180

Ffilters, definition 24, 139flat file, changing from flat file to database storage 47flow services

and step logic, overview 148caution about ProcessData variable 150completing logic after process generation 222guidelines for designing step logic 149how Modeler generates flow services 149including in release of package for deploying process model

243location of those generated by Modeler 240, 243properties affecting generation of 203

Focal Roleand sender/receiver roles 112property defined 54

Folder propertyhow changing affects process model regeneration 212use during process generation 204

folders, ISproperties affecting generation of 202

GGenerated Flow Name property

how changing affects process model regeneration 212use during process generation 203

generated flow servicesdefinition 148guidelines for working with 148mapping to user-defined services 149

generating process modelssee process generation

generation package, description 18global data

definition and overview 108working with global data 143

groupssee also external groupssee also internal groupsdefinition 26, 66, 178how PRT ignores 26, 178

HHot-Swappable property of referenced process steps

definition 273how process model design is not affected 278how state affects run-time actions 272if disabled 278if enabled 278importance of disabling all running processes when using 278using instead of referenced process step substitution 277using the hot-swappable feature 277

Iicons for steps, changing 105Implementation Module property


implementation modulescompleting logic after process generation 222properties affecting generation of 206


I n d e x

input dataassigning to steps 109instance names 109subscriptions vs. input data 109

input/output datasee also input datasee also output datachanging and process regeneration 214checking after 4.6 model migration 283definition and overview 24, 108using in transition conditions 163

instance names of input datapurpose and description 109

Integration Serversand the Associated Server 206and webMethods Modeler architecture 18and Workflow step generation 206items Modeler generates for processes 201properties affecting flow services generated for processes 203properties affecting folders generated for processes 202properties affecting generation of package 201properties affecting process run-time script generated for

processes 204properties affecting triggers generated for processes 202use at design time 21use during process run time 28

internal groupscreating 179definition 26, 178

IS documentsediting contents 120editing instance names 120guidelines for subscribing steps to 119importance of using only once per model 119publishing to Broker 125subscribing steps to 115when to create 31, 50, 183

IS folders, properties affecting generation of 202

JJoin Queue Lock Expiration (sec), PRT setting 253join types

defined 89return join types 274, 277

joins (join steps)see also AND joinssee also Complex joinssee also OR joinssee also XOR joinsdefinition 25, 163forming 25, 163guidelines for creating 170three ways to create 163types, defined 89

JPEG, of process model, creating 63

LLabel process property

how changing affects process model regeneration 211, 215use during process generation 201, 202, 207

Label step propertyhow changing affects process model regeneration 212, 215use during process generation 203, 207, 208

Logging Level property 54, 258, 260, 262Logical Server property

defined 67, 72, 78, 82, 84how changing affects process model regeneration 213, 215use during process generation 202, 203, 204, 207, 208

logical serverssee also Logical Server propertyand process generation 200assigning after 4.6 model migration 283changing connection state 232changing step by step vs. throughout process 231creating release of package containing information for 243defining and mapping to physical servers 44definition 20development vs. production 31


I n d e x

keeping external documents distinct among 113mappings and process deployment 234, 238overview 44refreshing information 232viewing connection status 232

Mmanaging

logical server assignments 231process models 226server connections 231

mappingcorrelation ID to process instance ID (PID) 154generated flow to user-defined services 149logical-to-physical server 44

mappings, logical-to-physical serverand deploying process models 234, 238procedure for defining 44

menu options, defined 36migration of 4.6 process models

basic steps 282differences in BI 4.6 and Modeler 6.0.1 280integrity check tasks 283overview 280

Modeler repositoryauthentication 21changing from flat file to database storage 47description 18use at design time 21warning about installing with Oracle drivers 47

monitoring process modelschoosing fields to log 138controlling the information you monitor 54, 256making models available for monitoring 222overview 30PRTservices that aid monitoring 150

Nnormal transitions

and transition conditions 163creating 161definition 26, 160

OOR joins

and return join types 274caution about becoming start steps 85caution using after splits 170definition 89

Oracle databasewarning for setting up as Modeler repository 47

output dataassigning to steps 124types defined 124

PPackage Name property


package replicationusing to deploy process model information 239

packagesgeneration, description 18modeler, description 18properties affecting generation of 201

parent process, definition 272performance and quality-of-service

configuration overview 250defined 248tuning, overview 248warning about installing database with Oracle drivers 47

physical serversmapping to logical servers 44relation to logical servers 20viewing physical-to-logical mapping 232

Portable format import/export format, defined 229prerequisites

before you create process models 50before you subscribe to external documents 110

Process Audit Logsee databases

Process Completion Tracking Serverchoosing one for the territory 255defined 252PRT setting 252

process control documents, definition 29


I n d e x

process generationand logical servers 200completing logic after generating 222consequences to changing Associated Server 208error messages and responses 216items generated on Integration Servers 201items generated on Workflow Servers 205, 206overview 200regeneration 210sample showing generated items 204steps to generate process 209troubleshooting 216when to regenerate 210Workflow steps and multiple servers 206

Process Key propertyuse during process generation 201, 202

Process Lock Expiration (sec), PRT setting 253process models

before you create 50collapsing several steps into single step 25creating logic 148creating Workflow logic 151definition 22deleting steps and process model regeneration 214, 216deploying 233development approach 30, 182exporting 229generating 209importing 229making available for monitoring 222migrating BI 4.6 to Modeler 6.0.1 280Modeler stores in repository 21moving to Process Audit Log for monitoring 246moving to production 233prerequistites to executing after regenerating 210referencing previously defined 25regenerating 210snapshot of sample 22transitions 25, 160troubleshooting generation of 216

process pipeline

and information flow 109and input/output data 108guidelines for variable names 172using in transition conditions 163when using an Express Pipeline 55, 109

process run time (PRT)choosing distributed vs. central process tracking 254database (Process Tracking Store) 253definition 29home page, configuring 251services to use in user-defined services 150tuning settings across the territory 250

process run-time scriptsand process model regeneration 211definition 27including in release of package to deploy 243location in Integration Server 240properties affecting generation of 204

Process Tracking Storecentral vs. distributed 254defined 251, 254how type affects use of Volatile Tracking property 255role in territory configuration 250

process transition documentsdefined 254

process transition documents, definition 29, 254Process window 39ProcessData variable

in flow services, caution 150production environment

logical-to-physical server mappings 234moving process models to 233tasks to complete in 32vs. development environment 32

profiles, Trading Networksand the publish/subscribe filter 142deploying with process models 245

program code conventions in this document 13Project property



I n d e x

projects, Workflowproperties affecting generation of 206

propertiesFolder, how changing affects process model regeneration 212Folder, use during process generation 204Generated Flow Name, how changing affects process model

regeneration 212Generated Flow Name, use during process generation 203Implementation Module, how changing affects process model

regeneration 215Implementation Module, use during process generation 207Label, how changing affects process model regeneration 211,

212, 215Label, use during process generation 201, 202, 203, 207, 208Logical Server, how changing affects process model

regeneration 213, 215Logical Server, use during process generation 202, 203, 204,

207, 208of referenced process steps 273of regular steps 67of transitions 162Package Name, how changing affects process model

regeneration 212Package Name, use during process generation 201Process Key, use during process generation 201, 202Project, how changing affects process model regeneration

215Project, use during process generation 207Service to Invoke, how changing affects process model

regeneration 213Service to Invoke, use during process generation 203Unique ID, use during process generation 203, 207, 208Version, use during process generation 207Workflow to Invoke, how changing affects process model

regeneration 216Workflow to Invoke, use during process generation 208

PRT (process run time)choosing distributed vs. central process tracking 254database (Process Tracking Store) 253definition 29home page, configuring 251services to use in user-defined services 150tuning settings across the territory 250

pub.prt.admin.loglogActivityMessages service 150

publishing documentsexternal, important information 136IS, procedure 125overview 24, 108

Qquality-of-service and performance

configuration overview 250defined 248tuning, overview 248

Rreceiver roles, assigning to external documents 112referenced processes

and hot-swapping 277and performance/quality-of-service settings 269definition 25, 89working with 272

regenerating process modelshow Modeler makes changes to Integration Server 211how Modeler makes changes to Workflow Server 215when to regenerate 210

releases of packagescreating to deploy process model information 239including information for a single logical server 243

replacinglogical servers in a process 231one referenced process step for another, caution 277

repository, Modelersee Modeler repository

Retreiving documents flow sequenceimportance of enabling 112

retries exceeded transitionscreating 161definition 26, 160

return join typesdefined 274when to assign to steps 277


I n d e x

Ssender role, assigning to external documents 112sending external documents 136Server Connections dialog 231servers

consequences to changing Associated Server 208logical, creating releases of package information for 243logical, definition 20mapping logical to physical 44mappings and process deployment 234, 238physical, relation to logical servers 20

service packs, Modeler and IS 71, 77, 81, 248Service to Invoke property

definition 68how changing affects process model regeneration 213influence on generated flow services 149use during process generation 149, 203

servicescaution about ProcessData variable 150guidelines for working with step logic 149helpful PRT services 150how Modeler generates flow services for steps 149important flow sequence for external document access 112mapping generated flow to user-defined 149procedure for assigning to steps 150properties affecting generation of 203, 204relationship to steps 148replacing service a step invokes 149Service to Invoke property 68, 149that control a process’s run-time status 150that create and log activity messages 150that send external documents 136types that you can add to steps 148working with correlation services 152

shutting down the Modeler 35SP, Modeler and IS 71, 77, 81, 248splits

definition 25, 163forming 163guidelines for creating 170

start stepsand subscription documents 85, 110defined 85guidelines for external document subscriptions 113

starting the Modeler 34Step Lock Expiration (sec), PRT setting 254steps

and step logic 148changing icons 105collapsing into a subprocess 25controlling pipeline logging 54, 71, 77, 81, 258, 260, 261controlling visual properties of 105definition and overview 23, 66enabling resubmission in Monitor 71, 77, 81, 256, 261end steps 86how groups affect 178information flow into and out of 24, 108join steps 88overview 66process-wide error steps 87properties of referenced process steps 273properties of regular steps 67referenced process steps 25, 89, 272start steps 85step functions and types 85subprocess steps 25, 90using filters 24, 139Workflow step guidelines 104Workflow steps overview 23

Steps Enable Resubmission option 71, 77, 81, 256, 261subprocesses

accessing and editing 91definition 25, 90procedure for establishing 90

subscription documentsand start steps 85, 110external, and start steps 113overview and definition 24subscribing to external documents 110subscribing to IS documents 115


I n d e x

TTerminate Step Properties 84territory

definition 18tuning PRT settings in a territory 250

timeout transitionscreating 161definition 26, 160

To-Do Listoverview 60viewing 61

toolbar, main, defined 37toolbar, process, defined 40Trading Networks

deploying attributes with process models 245deploying profiles with process models 245deploying TN document types with process models 245ensuring profiles created 50export/import data feature and deploying process models 245participants, using in transition conditions 163

Trading Networks documentssee external documents

transition conditionsand 4.6 model migration 283creating based on inputs/outputs 163creating based on pipeline data 163creating based on Trading Networks participants 163Edit Transition Conditions window 165migration of 4.6 TN status conditions 284overview 25, 163procedure for building 164, 167sources of 163to/from external groups 163, 180

transitionssee also transition conditionscontrolling the color of 175controlling the display of 175creating splits, joins, and branches 25, 163else defined 26, 160error defined 26, 160general guidelines for creating 168guidelines for splits and joins 170normal defined 160

number allowed per step 160overview and definition 25, 160procedure for creating 161properties defined 162retries exceeded defined 26, 160timeout defined 26, 160to/from external groups 163, 180types defined 26, 160

triggersand process model regeneration 211location of those generated by Modeler 240, 243properties affecting generation of 202

troubleshootinginformation for other webMethods components 13Oracle database driver installation 47process generation 216Workflow step generation and Associated Servers 208

typographical conventions in this document 13

Uuncontrolled steps

and external groups 26, 178definition 23

Unique ID propertyuse during process generation 203, 207, 208

updating process models 226user-defined services

changing the service a step invokes 149mapping to generated flow services 149procedure for assigning to a step 150

VVersion step property

defined 53use during process generation 207

versioning process modelsoverview and steps 227Version step property 53

View Options, defined 41viewing

server connections 232Volatile Tracking property

relationship to type of Process Tracking Store 255


Index

WwebMethods Modeler

and business process management 17description 16, 18design-time architecture 20getting started 34how it relates to webMethods platform 17use at design time 20

webMethods Monitorand webMethods Modeler architecture 19description 19use during process run time 30

webMethods platformdocuments to communicate between components of 24, 108relationship to webMethods Modeler 17

webMethods Trading Networksdocuments to and from 24, 108

webMethods Workflowand webMethods Modeler architecture 19consequences of changing Associated Server 208description 19two servers Workflow steps generate to 206use at design time 21use during process run time 29

WmModeler package, description 18Workflow logic

and deploying process models 245assigning to steps 151deploying workflows to production environment 245guidelines 151properties affecting generation of Workflow projects 207properties affecting generation of workflows 208

Workflow Serversitems Modeler generates for processes 205, 206properties affecting implementation modules generated for

processes 207properties affecting projects generated for processes 207properties affecting workflows generated for processes 208

Workflow to Invoke propertyhow changing affects process model regeneration 216use during process generation 208

XXOR joins

and return join types 274caution using with loops 171definition 89


I n d e x
