Webmethods Modeler Users Guide

webMethods Modeler User’s Guide

VERSION 6.1

webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA 703.460.2500 http://www.webmethods.com

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

Copyright © 2002-2004 by webMethods, Inc. All rights reserved, including the right of reproduction in whole or in part in any form.

Document ID: MOD-UG-61-20040322

Contents

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

13

Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What is Modeling? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What is the webMethods Modeler? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Modeler and Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modeler and the webMethods Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modeler Design-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design-time Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlled and Uncontrolled Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps and Information Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple Steps Represented as a Single Icon in the Process Model . . . . . . . . . . . . . . Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run-time Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Participants in Process Modeling and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bottom-Up Vs. Top-Down Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Top-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bottom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phases of Development and Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Production Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction to BPEL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 2. Getting Started with webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating the Workflow Client Directory from Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connecting to a Different Design Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shutting Down the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Familiarizing Yourself with the Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

webMethods Modeler User’s Guide Version 6.1

15 16 16 17 17 19 20 22 23 23 24 25 25 26 27 27 28 30 30 30 31 31 31 32 32

33 34 34 34 35 35 36

3

Contents

Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . View Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36 37 39 40 41 41

Chapter 3. Configuring webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Defining Servers Where Process Steps Will Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Logical Servers and Their Physical Server Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Logical Servers and Their Physical Server Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . For More Information on Server Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Modeler Repository Storage Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44 44 45 47 47

Chapter 4. Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Before Creating a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Steps in Process Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Model Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks in the To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Model Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow Step Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps Outside of the Scope of the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quick Reference of Basic Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving a Process Model as a JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50 51 51 60 60 60 60 61 61 61 62 63

Chapter 5. Adding Steps to a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Service Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empty Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminate Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step Functions and Step Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process-Wide Error Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Join Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Join Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

66 67 72 77 82 84 85 85 86 87 88 89

webMethods Modeler User’s Guide Version 6.1

Contents

Referenced Process Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subprocess Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing and Editing a Subprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restoring a Subprocess to the Main Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Web Service Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Port Types from a WSDL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Web Service Port Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining New Process Port Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Web Service Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Service Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Binding for Web Service Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Static Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Dynamic Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Deployment-time Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping WSDL Elements to EndPointReference Document Fields . . . . . . . . . . . . . . . . . . Web Service Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Service Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Guidelines on Using Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling the Visual Properties of Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing a Step’s Icon Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling the Display of Step Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89 90 91 91 92 92 94 95 96 97 97 98 99 99 100 101 101 103 104 104 105 105 105

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

webMethods Modeler User’s Guide Version 6.1

108 108 109 109 109 110 110 112 115 119 120 120 120 122

5

Contents

Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Input Data Instance Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning and Editing Step Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publishing an IS Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Publication Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Publication Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publication and External Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Having a Step Send an External Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling the Display of Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choosing Fields to Log For Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Publish/Subscribe Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building Publish/Subscribe Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with Global Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How Global Data Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Global Data in Your Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Data Properties and Data Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122 122 124 124 124 125 127 129 129 129 132 133 133 133 135 136 136 136 137 138 139 142 143 144 144 145

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

6

148 148 148 149 150 150 150 150 151 151 151

webMethods Modeler User’s Guide Version 6.1

Contents

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

152 152 153 153 154 154 154 154 155 155 155 157 157 157 158

Chapter 8. Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Overview of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of Transitions Allowed Per Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Step Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transition Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Splitting, Branching, and Joining Logic in a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Transition Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Edit Transition Conditions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Transition Conditions Using XPath Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with Global data in XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Guidelines for Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Guidelines for Transitions that Create Splits and Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Appearance of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying/Hiding Transitions Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling the Color of Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

160 160 161 162 163 163 164 165 167 167 168 168 170 175 175 175 175 176

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

webMethods Modeler User’s Guide Version 6.1

7

Contents

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

Chapter 10. Importing and Exporting BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . 181 Importing BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BPEL Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partner Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variables, Message Types, and Document Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . BPEL Web Service Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminate Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empty Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wait Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . While Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assign Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BPEL Structural Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow without Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow with Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting Process Models in BPEL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BPEL Export Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BPEL Export Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

182 183 184 184 185 185 186 186 186 186 186 187 187 187 187 188 188 189 189 189 190 190 194

Chapter 11. Generating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Overview of Process Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Modeler Generates for a Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Items Generated for Steps Associated with Integration Servers . . . . . . . . . . . . . . . . . . . . . . . . . Sample Process Model and Generated Run-time Elements . . . . . . . . . . . . . . . . . . . . . . . . Items Generated for Web Service Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Service Receive/Reply Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Service Invoke Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Items Generated for Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow Step Generation and Multiple Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Modeler Generates to Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consequences to Changing the Associated Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Validating a Process Model Before Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

200 201 201 204 205 205 205 206 206 206 208 209

webMethods Modeler User’s Guide Version 6.1

Contents

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

209 209 210 210 211 215 216 221 222 222 222 222 223

Chapter 12. Managing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Versioning the Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting and Importing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Logical Servers and Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Logical Servers in the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

226 226 227 228 229 229 230 231 231 231

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

webMethods Modeler User’s Guide Version 6.1

234 234 235 235 236 238 238 239 239 241 241 242

9

Contents

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

244 245 245 246

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

10

248 248 248 248 248 249 249 249 249 249 250 250 250 254 254 254 255 255 255 255 255 256 256 256 257 260 261 262 262 262 264 264 264

webMethods Modeler User’s Guide Version 6.1

Contents

Optimizing the Process Locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effect on Where the Process Automatically Recovers . . . . . . . . . . . . . . . . . . . . . . . . Example of a Process with Enabled Optimize Locally Property . . . . . . . . . . . . . . . . . Example of Process that Does Not Optimize Locally . . . . . . . . . . . . . . . . . . . . . . . . . Managing Correlation IDs in a Distributed Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Correlation Property’s Effect on Correlation ID Receipt . . . . . . . . . . . . . . . . . . . Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of Local Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STEP 3: Optionally Modify Step Pipeline Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Note About Referenced Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

264 264 265 266 267 267 268 269 269 269

Appendix B. Guidelines for Working with Referenced Processes . . . . . . . . . . . . . . . . . . . 271 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Referenced Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Referenced Process Step Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design-Time Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Inputs and Outputs to Referenced Process Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning a Return Join Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Hot-Swappable Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . If a Referenced Process Step is Hot-Swappable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . If a Referenced Process Step is Not Hot-Swappable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

272 272 272 272 273 275 275 277 277 277 278 278

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

280 280 282 283 283 283 283 283 283 284 284 284

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

webMethods Modeler User’s Guide Version 6.1

11

Contents

12

webMethods Modeler User’s Guide Version 6.1

About This Book

About This Book This guide is for users of webMethods Modeler. It provides procedures for how to use webMethods Modeler to build, generate, and deploy business process models. With webMethods Modeler, you can create easy-to-understand, visually-based, process automation solutions that integrate the pillars of integration.

Document Conventions Convention

Description

Bold

Identifies elements on a screen.

Italic

Identifies variable information that you must supply or change based on your specific situation or environment. Identifies terms the first time they are defined in text. Also identifies service input and output variables.

Narrow font

Identifies storage locations for services on the webMethods Integration Server using the convention folder.subfolder:service.

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

Additional Information The webMethods Advantage Web site at http://advantage.webmethods.com provides you with important sources of information about the webMethods Integration Platform: Troubleshooting Information. webMethods provides troubleshooting information for many webMethods components in the webMethods Knowledge Base. Documentation Feedback. To provide documentation feedback to webMethods, go to the Documentation Feedback Form on the webMethods Bookshelf. Additional Documentation. All webMethods documentation is available on the webMethods Bookshelf.

webMethods Modeler User’s Guide Version 6.1

13

About This Book

14

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

1

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

webMethods Modeler User’s Guide Version 6.1

15

CHAPTER 1 Concepts

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

What is the webMethods Modeler? webMethods Modeler is a design-time tool that you use to draw business process models. However, webMethods Modeler goes beyond modeling the business process. After you draw the process model, webMethods Modeler allows you to generate the components needed to execute your business process in the underlying webMethods platform. With webMethods Modeler, you can create easy-to-understand, visually-based, process automation solutions that integrate any or all of the following pillars of integration: Internal systems and applications Databases/data warehouses Trading Partners Web services Mainframes Workflows (human interactions) The graphical modeling capabilities of webMethods Modeler provide a high-level view of the business process, including the interaction across the pillars of integration. You can quickly and easily create visual models that represent the flow of information within the enterprise and beyond by placing icons representing steps in the process onto a screen window. If multiple steps in a process occur within an internal group (e.g., accounting department) or an external partner group (e.g., buyer), you can box the steps together to designate that the steps are performed by that specific internal or external group. If your business process involves many steps, you can collapse steps to make the process model visually simpler, but can still easily access and traverse the collapsed steps. You can make your process model self-describing by using specialized icons for different steps and annotating the process model with text labels and notes.

16

webMethods Modeler User’s Guide Version 6.1

webMethods Modeler and Business Process Management

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

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

Modeler

Process Audit Log Design Server

Modeler repository

IS

IS

IS

WmModeler package

Broker

webMethods Modeler User’s Guide Version 6.1

IS WmMonitor package

Monitor

Workflow

17

CHAPTER 1 Concepts

Component

Description

Modeler

webMethods Modeler is a Java GUI. It is the tool that is described in this manual and that you use to draw and generate business process models.

Design Server

The Design Server is an Integration Server to which you connect the Modeler. You install the WmModeler package on the Design Server machine. The WmModeler package contains the services that are needed to load and store process model definitions, which are maintained in the Modeler repository. The WmModeler package also installs the services required to generate the run-time components required to execute process models.

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

18

webMethods Modeler User’s Guide Version 6.1

Modeler Design-Time Environment

Component

Description

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.

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

webMethods Modeler User’s Guide Version 6.1

19

CHAPTER 1 Concepts

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

Modeler

Design Server

Modeler repository

IS

IS

IS

IS

Accounting

Customer Info

Partner Gateway

WmModeler package

Logical Server Names = Utility Services

Workflow

Component

Description

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.

20

webMethods Modeler User’s Guide Version 6.1

Modeler Design-Time Environment

Component

Description

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.

webMethods Modeler User’s Guide Version 6.1

21

CHAPTER 1 Concepts

Process Models Process models are the diagrams that illustrate a business process that you create using the Modeler. Sample Process Model Internal groups box steps that are performed within your enterprise

Steps represent an automated process performed by a computer or a manual step performed by a person. Transitions are lines between steps that indicate the flow of execution.

External groups box steps that are performed outside your enterprise.

A process model consists of: Steps Transitions Groups (optional) Annotations (optional)

22

webMethods Modeler User’s Guide Version 6.1

Modeler Design-Time Environment

Steps Steps are the basic unit of work in a business process. A step can represent an automated process performed on an Integration Server (e.g., executing a service), a manual step performed by a person (via webMethods Workflow), or a visual aid that identifies a task that an external organization performs. Steps can also depict a service that you want executed if an error or timeout occurs in the process. You add a step to a process model by placing an icon on the screen. You can use the default icon for a step or select a different icon. You might select a different icon to make your process model more self-describing. For example, you might use an icon of a truck to represent a step that represents an item is to be shipped to a buyer. The Modeler provides three main kinds of steps: Flow steps, Workflow steps, and Web Service steps. Flow steps. Flow steps represent automated processes, such as executing a service. This can include steps that execute when another step or the process times out or encounters an error. When you generate the process model, the Modeler generates flow services, triggers, and process run-time scripts as the run-time elements for this type of step. Workflow steps. Workflow steps are manual steps that require human intervention. A person performs this type of step using webMethods Workflow. You add a Workflow step that references a human workflow in the webMethods Workflow system. When you generate the process model, the Modeler generates a webMethods Workflow project and implementation module that contains the reference to the human workflow. Web Service steps. Web Service steps allow you to define and manage relationships between BPEL partners and define web service interactions. These steps are designed to replicate the BPEL invoke, receive, and reply activities. Controlled and Uncontrolled Steps At design time, you have the option of placing steps into groups, either internal or external. Groups provide visual and conceptual demarcations to a process model that make it easier to understand. By placing steps into groups, you create two new step categories: controlled or uncontrolled. Controlled steps are those within an internal group or outside of any group. Most steps in a typical process model are controlled steps. They include Flow steps or Workflow steps for which Modeler generates run-time elements (e.g., flow services, triggers, process run-time scripts, and Workflow elements). Uncontrolled steps are those that you include in the process model purely as a visual aid. They identify tasks that an external organization (e.g., a trading partner) performs. You add uncontrolled steps to your process model to make the model easier to understand and more self-describing. They are not necessary. When you generate the process model, the Modeler does not generates any run-time element for this type of step.

webMethods Modeler User’s Guide Version 6.1

23

CHAPTER 1 Concepts

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

24

webMethods Modeler User’s Guide Version 6.1

Modeler Design-Time Environment

Multiple Steps Represented as a Single Icon in the Process Model There are two ways you can represent multiple steps using a single icon in a process model: referenced processes and subprocesses. Referenced processes are pointers to another process model that you have previously defined. The ability to reference a process inside another process model allows you to reuse steps and simplify your design. To edit a referenced process, you must open the original process. When you edit a referenced process, the changes are automatically reflected in all processes that reference it. For example, if process model A and B reference process model C, you must open and update C to make changes to it. The changes that you make in process model C take affect in process models A and B. Subprocesses are a collection of steps in your process model that you collapse into a single icon. Create subprocesses in your process model to combine several steps to make the process model visually simpler. You can easily descend into the collapsed steps to view them.

Transitions You draw transitions (or lines) between steps to indicate the execution order of the steps within the process model. To control the flow of execution, you can place conditions on transitions. The condition affects whether a transition is taken or not. For example, during the process model you might need to approve an item. After the step that determines whether the approval is granted, you would use transition conditions so the model transitions to one step if approval is granted and another if approval was not granted. Using transitions you can create splits, branches, and joins. Splits. You create splits when you draw transitions from one step to two or more steps without placing conditions on the transitions. At run time, all transitions are executed and processing splits into two or more threads of execution. Branches. You create branches when you draw transitions from one step to two or more steps and place conditions on the transitions, so at run time, at most one transition is executed. Joins. You create joins when you draw transitions from two or more steps to a single step, merging multiple threads of execution to return to a single thread of execution. You can also create a join by subscribing to multiple documents, or by subscribing to a document that also has an input transition.

webMethods Modeler User’s Guide Version 6.1

25

CHAPTER 1 Concepts

You can also create the following types of transitions to handle special conditions that might occur for a particular step: Retries Exceeded. The step property Retry Count specifies the number of times to execute a step. At run time, if the process attempts to execute the step more times than Retry Count specifies, then the process takes the Retries Exceeded transition. Timeout. When you create joins that cause the process to wait for multiple events to occur before continuing (e.g., AND joins), you can specify how long to wait for all the events to occur. At run time, if the amount of time you specify is exceeded, the process will take the timeout transition. This relative timeout can be set for a number of milliseconds or based on an XPath condition. You can also set an absolute timeout for a join condition that will cause the process to continue until a set date and time, or based on an XPath condition. Error. An error transition incorporates general error handling for a step. At run time, the error transition is taken if the service executed by the step throws an exception. Else. Else transitions specify what step should execute if no other transitions are followed. At run time, if no other transitions from a step are followed, the Else transition will be followed.

Groups You can place steps into groups to represent different organizational boundaries within the business process model. Groups are represented by shaded rectangles in the process model. Placing steps within groups can be a helpful visual aid for complicated process models, but is never required. There are two types of groups: internal and external. Internal groups Steps within internal groups (as with steps outside of any group) are steps within the scope of the business process. That is, they are controlled steps. You might use internal groups to specify different departments within the process (for example, accounting or purchasing) that complete a specific grouping of steps. External groups You place steps within external groups to visualize steps that occur outside of the scope of the business process, for example, a step that waits for a document or sends an acknowledgement. Since steps in external groups are by definition outside the scope of the process, they are known as uncontrolled steps. That is, when you generate the process model, the process run ignores these steps completely; no run-time elements are generated for these steps. Use external groups if it helps you to conceptualize steps in a process that occur outside of the scope of the process.

26

webMethods Modeler User’s Guide Version 6.1

Process Execution

Annotations You can annotate your process model by labeling steps, transitions, groups. Additionally, you can place notes and explanatory text anywhere on your process model. Note–text that is enclosed in a shaded box Text–lines of text without a border or background The annotations you add to your process model help describe your business process and make it self-describing.

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

webMethods Modeler User’s Guide Version 6.1

27

CHAPTER 1 Concepts

Run-time Architecture The following shows the run-time architecture for executing business processes that you design using webMethods Modeler. Run-time Architecture for Business Processes

Process Audit Log

P R T

IS

P R T

IS

P R T

Broker

28

IS

P IS R WmMonitor T package

Monitor

Workflow

Component

Description

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.

webMethods Modeler User’s Guide Version 6.1

Process Execution

Component

Description

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.

webMethods Modeler User’s Guide Version 6.1

29

CHAPTER 1 Concepts

Component

Description

Monitor

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

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

Bottom-Up Vs. Top-Down Approach You can approach process model design in two ways. You can use a top-down or bottomup 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

30

webMethods Modeler User’s Guide Version 6.1

Phases of Development and Production

the services associated with steps will execute. When you generate a process model created in this way, Modeler generates empty flow services to the Integration Server(s) and empty implementation modules and workflows to Workflow. Later, you use Developer or Workflow to fill in the logic.

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

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

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

webMethods Modeler User’s Guide Version 6.1

31

CHAPTER 1 Concepts

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

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

32

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

2

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

webMethods Modeler User’s Guide Version 6.1

33

CHAPTER 2 Getting Started with webMethods Modeler

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

Starting the Modeler Before you start the Modeler, make sure the Design Server to which you will connect the Modeler is running. The Design Server is an integration server on which the WmModeler package is installed. To start the Modeler on Microsoft Windows On the Start menu, select ProgramswebMethodsModeler. To start the Modeler on UNIX To

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

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

34

webMethods Modeler User’s Guide Version 6.1

Connecting to a Different Design Server

Connecting to a Different Design Server You can change the Design Server to which Modeler is connected at any time. To do so, use the following procedure. To connect to a different Design Server 1

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

2

From the menu bar, choose SessionConnect to Design Server. The Open Session to Design Server window appears.

3

Select the new Design Server, enter your Username and Password, then click OK.

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

webMethods Modeler User’s Guide Version 6.1

35

CHAPTER 2 Getting Started with webMethods Modeler

Familiarizing Yourself with the Modeler The main Modeler window consists of: Menu bar Main toolbar Process toolbar Process window Canvas View options Main Modeler Window Menu bar Main toolbar Process window

Process toolbar

Canvas

View Options

Menu Bar The Modeler menu options are: File: Use to create, open, close, save, rename, delete, import, export, and print process models. In addition, use it to exit the Modeler. Edit: Use to undo and redo recent actions, as well as to delete steps in a process model.

36

webMethods Modeler User’s Guide Version 6.1

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

webMethods Modeler User’s Guide Version 6.1

37

CHAPTER 2 Getting Started with webMethods Modeler

This icon...

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

38

webMethods Modeler User’s Guide Version 6.1

Familiarizing Yourself with the Modeler

Process Window The Process window is where you design your process model. The Process window appears when you create a new process model or open an existing process model. Process Window Process toolbar

Canvas

View options

The Process window consists of: Process toolbar Canvas View options Properties (optional) To Do List (optional)

webMethods Modeler User’s Guide Version 6.1

39

CHAPTER 2 Getting Started with webMethods Modeler

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

Represents... Zoom Out. Zooms out of a subprocess and into its parent process. Zoom In. Zooms in to the subprocess of a selected step. Switch to Edit. De-selects the item that is currently selected. For example, if you select New Step and then decide you don’t want to insert a new step, clicking Switch to Edit de-selects the new step so that you can choose again. Delete. Deletes the selected item, e.g., a step. Insert a Predefined Service or Process. Opens a list of services and processes that you can insert into the active process. New Flow Step. Places a new Flow step onto the canvas. New Workflow Step. Places a new Workflow step onto the canvas. New Web Service Step. Places a new Web Service step onto the canvas. New Empty Step. Places a new Empty step onto the canvas. New Terminate Step. Places a new Terminate step onto the canvas. Group. Draws a group box around steps so that you can visually describe whether the steps are internal or external to your organization. Note. Adds a box in which you can type text to make the process model more self-describing. Text. Enables you to type text (without a box) to make the process model more self-describing. Show/Hide Properties Window and To-Do List. Shows or hides the Properties window and the To-Do List.

40

webMethods Modeler User’s Guide Version 6.1

Familiarizing Yourself with the Modeler

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

On the main toolbar, select ToolsOptions.

2

Check or uncheck the Show Grid option.

To change the grid setting of the active canvas On the View Options area at the bottom of the Process window, check or uncheck Show Grid.

View Options The View Options area at the bottom of the Process window contains the following settings to control the look of the canvas and the objects on the canvas. This option...

Represents... Zoom. Zooms in or out of the picture on the canvas. Line Style. Assigns either a curved or straight line style to the transitions in the process model. Show Inputs/Outputs. Shows or hides the inputs and outputs associated with each step. Show Grid. Shows or hides the grid on the active canvas. Overrides the default grid setting. Snap to Grid. Controls whether the Modeler forces objects on the canvas to adhere to the grid parameters.

webMethods Modeler User’s Guide Version 6.1

41

CHAPTER 2 Getting Started with webMethods Modeler

42

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

3

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

webMethods Modeler User’s Guide Version 6.1

43

CHAPTER 3 Configuring webMethods Modeler

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

Defining Logical Servers and Their Physical Server Mappings Use the following procedure to define a logical server and its physical server mapping. Defining Logical Servers and Their Physical Server Mappings

44

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.

webMethods Modeler User’s Guide Version 6.1

Defining Servers Where Process Steps Will Execute

3

In the Add Logical Server page, specify the following information: For this parameter...

Specify...

Name

The name you give the logical server. Important! The name is managed by the system and cannot be edited once given.

Type

The type of physical server: Integration Server or Workflow.

Description (optional)

The description that describes the functionality of the logical server.

Physical Server

The name of the physical server to map to the logical server. The physical server list is comprised of the registered servers in webMethods Administrator. For information on registering servers, see the “Managing Resources” chapter of the webMethods Administrator User’s Guide. Note: You do not have to choose a physical server to be mapped to the logical server at this time. If you prefer, you can add the physical server mapping using the Edit function at a later time.

4

Click Add Logical Server.

5

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

Editing Logical Servers and Their Physical Server Mappings Use the following procedure to edit a logical server or its physical server mapping. Editing Logical Servers and Their Physical Server Mappings 1

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

2

Click the Logical Servers menu of the Navigation panel.

webMethods Modeler User’s Guide Version 6.1

45

CHAPTER 3 Configuring webMethods Modeler

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

46

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

webMethods Modeler User’s Guide Version 6.1

Changing the Modeler Repository Storage Mechanism

For More Information on Server Management For more information on managing logical and physical servers, or on using webMethods Administrator, see the webMethods Administrator User’s Guide.

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

From webMethods Modeler, export all process models to a temporary storage location. Use the Complete Model export option. For details on exporting process models, see “Exporting and Importing Process Models” on page 229. Note: The process model data previously stored in the flat file is converted to an XML file and exported to the directory of your choice.

2

Change the Modeler Repository configuration from flat file to database on the Modeler home page at http://Integration Server_host:Integration Server_port/WmModeler. For instructions on configuring the Modeler Repository to write to a database, see the “Configure the Modeler Repository to Write to a Database” section of the webMethods Integration Platform Installation Guide. Important! If you use an Oracle database, you must use a SequelLink driver and a SequelLink server to run on the same machine as the database. If you do not, Modeler performance will be unacceptably slow.

3

Restart the Integration Server and webMethods Modeler.

4

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

webMethods Modeler User’s Guide Version 6.1

47

CHAPTER 3 Configuring webMethods Modeler

48

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

4

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

webMethods Modeler User’s Guide Version 6.1

49

CHAPTER 4 Creating a Process Model

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

50

webMethods Modeler User’s Guide Version 6.1

Basic Steps in Process Model Creation

Basic Steps in Process Model Creation An overview of the steps in process model creation is described below. To Create a Process Model 1

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

2

Open a new process model by selecting FileNew.

3

Set the process model properties. For descriptions of process model properties, see “Process Model Properties” on page 51.

4

Build the model by adding steps and step transitions. (You might also want to add groups or annotations.) For more information on defining these items, see: To add steps, see Chapter 5, “Adding Steps to a Process Model”. To create step transitions, see Chapter 8, “Creating Step Transitions”. To add groups, see Chapter 9, “Adding Groups to a Process Model”.

5

Use the To-Do List to ensure that you have completed all tasks associated with the model and its steps. For details on using the To-Do List, see “The To-Do List” on page 60.

6

Save the process model by selecting FileSave. In the Save dialog, select the folder in which you want to save the process model; or, click New to create a new folder. Type a name for the model in the Save As dialog if you haven’t already, and then click Save.

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

webMethods Modeler User’s Guide Version 6.1

51

CHAPTER 4 Creating a Process Model

Property

Description

Default

Label

Process model name.

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

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

52

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.

This is a read-only property.

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.

This is a read-only property.

webMethods Modeler User’s Guide Version 6.1

Process Model Properties

Property

Description

Default

Version

The process model version.

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

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

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.

webMethods Modeler User’s Guide Version 6.1

53

CHAPTER 4 Creating a Process Model

Property

Description

Default

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.

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

Note: If a process does not use external documents, you can ignore this property. 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.

Process and All Steps

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

54

Turns on transition logging.

Check the box to turn on transition logging.

webMethods Modeler User’s Guide Version 6.1

Process Model Properties

Property

Description

Default

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.

Disabled

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.

webMethods Modeler User’s Guide Version 6.1

55

CHAPTER 4 Creating a Process Model

Property

Description

Default

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.

56

webMethods Modeler User’s Guide Version 6.1

Process Model Properties

Property

Description

Default

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.

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.

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.

webMethods Modeler User’s Guide Version 6.1

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.

57

CHAPTER 4 Creating a Process Model

58

Property

Description

Default

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.

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.

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.

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.

webMethods Modeler User’s Guide Version 6.1

Process Model Properties

Property

Description

Default

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.

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.

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.

webMethods Modeler User’s Guide Version 6.1

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.

59

CHAPTER 4 Creating a Process Model

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

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

Process Model Tasks The general process model tasks in a To-Do List are: Add starting step for the process Choose error handling step Add a step to the canvas

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

60

webMethods Modeler User’s Guide Version 6.1

The To-Do List

In Modeler, the checklist for a new step looks like the following:

In addition to these general tasks, Modeler can add items to a step’s checklist in response to the way that the model is designed. For example, Modeler can add the following items: Set join type (if a join step has been established) Set expression for complex join (if a complex join step has been established)

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

Steps Outside of the Scope of the Process Modeler does not generate a checklist for steps outside of the control of the process (i.e., steps within external groups) because you do not need to assign properties to these types of steps.

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

webMethods Modeler User’s Guide Version 6.1

61

CHAPTER 4 Creating a Process Model

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

62

To...

Perform this procedure...

Start a new process model

On the menu bar, select FileNew.

Open an existing process model

On the menu bar, select FileOpen.

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

webMethods Modeler User’s Guide Version 6.1

Saving a Process Model as a JPEG

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

On the menu bar, choose FileSave as JPEG.

2

Choose the name and location for the JPEG.

3

Click Save.

webMethods Modeler User’s Guide Version 6.1

63

CHAPTER 4 Creating a Process Model

64

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

5

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

webMethods Modeler User’s Guide Version 6.1

65

CHAPTER 5 Adding Steps to a Process Model

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

66

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

webMethods Modeler User’s Guide Version 6.1

Flow Step Properties

Flow Step Properties As you establish steps, you define their properties. These are defined in the table below. Note: You do not need to assign properties to steps within external groups. 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

The name of the step.

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

Note: The step name should be unique.

Description

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

Choose Edit to enter a description.

Unique ID

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

This is a read-only property.

Logical Server

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

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

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

webMethods Modeler User’s Guide Version 6.1

67

CHAPTER 5 Adding Steps to a Process Model

Property

Description

Default

Folder

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

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

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

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

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

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.

If you do not specify the Service to Invoke property, Modeler does nothing and you must create this service manually. To select a service, click the arrow and browse to the service.

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.

68

webMethods Modeler User’s Guide Version 6.1

Flow Step Properties

Property

Description

Default

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.

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

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

The number of times to execute the step if 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”.

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.

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

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

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.

webMethods Modeler User’s Guide Version 6.1

69

CHAPTER 5 Adding Steps to a Process Model

Property

Description

Default

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.

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

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

None. To define a Timeout Value, click Edit, choose the Timeout Type, then enter either a time in milliseconds or 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.

70

webMethods Modeler User’s Guide Version 6.1

Flow Step Properties

Property

Description

Default

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.

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

Note: For details, see “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).

To assign inputs and outputs to steps, click Edit.

Note: For details on assigning inputs and outputs, see Chapter 6, “Assigning Inputs and Outputs to Steps”. Logged Fields

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

To choose document fields, click Edit.

Note: For details, see “Choosing Fields to Log For Monitoring” on page 138. 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.

webMethods Modeler User’s Guide Version 6.1

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

71

CHAPTER 5 Adding Steps to a Process Model

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

Workflow Step Properties After adding a Workflow step, define its properties. These are described in the table below. 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

The name of the Workflow step.

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

Note: Assign steps a unique name.

Description

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

Choose Edit to enter a description.

Unique ID

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

This is a read-only property.

Logical Server

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

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.

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.

72

webMethods Modeler User’s Guide Version 6.1

Workflow Step Properties

Property

Description

Default

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

webMethods Modeler User’s Guide Version 6.1

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.

73

CHAPTER 5 Adding Steps to a Process Model

Property

Description

Default

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.

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

Important! In many cases, though not all, it will be necessary to assign correlation services to steps. For criteria, see“Working with Correlation Services” on page 152. Transitions

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

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

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

The number of times to execute the step if 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”.

74

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

webMethods Modeler User’s Guide Version 6.1

Workflow Step Properties

Property

Description

Default

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.

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

Possible join types are: AND, OR, XOR, and COMPLEX. For details, see “Join Steps” on page 88. Note: When a step is an AND join step (or a COMPLEX join step containing AND logic), you must also assign a Timeout Value for the step using the Timeout Value property described below. Join Timeout

Timeout value for steps that are AND joins (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.

None. To define a Timeout Value, click Edit, choose the Timeout Type, then enter either a time in milliseconds or 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”.

webMethods Modeler User’s Guide Version 6.1

75

CHAPTER 5 Adding Steps to a Process Model

Property

Description

Default

Step Timeout

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

None. To define a Timeout Value, click Edit, choose the Timeout Type, then enter either a time in milliseconds or an XPath 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.

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.

Note: For details, see “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).

To assign inputs and outputs to steps, click Edit.

Note: For details on assigning inputs and outputs, see Chapter 6, “Assigning Inputs and Outputs to Steps”.

76

webMethods Modeler User’s Guide Version 6.1

Web Service Step Properties

Property

Description

Default

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.

To choose document fields, click Edit.

Note: For details, see “Choosing Fields to Log For Monitoring” on page 138. 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-thebox; however, the default state of this property is controlled through ToolsOptionsSteps Enable Resubmission.

Web Service Step Properties After adding a Web Service step, define its properties. These are described in the table below. 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

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.

Note: Assign steps a unique name.

webMethods Modeler User’s Guide Version 6.1

77

CHAPTER 5 Adding Steps to a Process Model

Property

Description

Default

Description

Web Service step description, e.g., “Web Service Step”. There is no limit to the length of the description.

Choose Edit to enter a description.

Unique ID

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

This is a read-only property.

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

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.

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

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.

78

webMethods Modeler User’s Guide Version 6.1

Web Service Step Properties

Property

Description

Default

Transitions

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

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

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

The number of times to execute the step if 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”.

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.

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

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

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.

webMethods Modeler User’s Guide Version 6.1

79

CHAPTER 5 Adding Steps to a Process Model

Property

Description

Default

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.

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

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

None. To define a Timeout Value, click Edit, choose the Timeout Type, then enter either a time in milliseconds or 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.

80

webMethods Modeler User’s Guide Version 6.1

Web Service Step Properties

Property

Description

Default

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.

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-ofthe-box; however, the default state of this property is controlled through ToolsOptionsSteps Enable Resubmission.

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

webMethods Modeler User’s Guide Version 6.1

81

CHAPTER 5 Adding Steps to a Process Model

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

Description

Default

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.

Note: Assign steps a unique name.

Description

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

Choose Edit to enter a description.

Unique ID

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

This is a read-only property.

Logical Server

The logical server on which the Empty 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.

Transitions

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

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

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

82

webMethods Modeler User’s Guide Version 6.1

Empty Step Properties

Property

Description

Default

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.

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

Possible join types are: AND, OR, XOR, COMPLEX and XPath. For details, see “Join Steps” on page 88. Note: When a step is an AND join step (or a COMPLEX join step containing AND logic), you must also assign a Timeout Value for the step using the Timeout Value property described below. Join Timeout

Timeout value for steps that are AND joins (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.

None. To define a Timeout Value, click Edit, choose the Timeout Type, then enter either a time in milliseconds or 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”.

webMethods Modeler User’s Guide Version 6.1

83

CHAPTER 5 Adding Steps to a Process Model

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

Description

Default

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.

Note: Assign steps a unique name.

84

Description

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

Choose Edit to enter a description.

Unique ID

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

This is a read-only property.

Logical Server

The logical server on which the Terminate 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.

webMethods Modeler User’s Guide Version 6.1

Step Functions and Step Types

Property

Description

Default

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.

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

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.

Step Functions and Step Types You add steps to a process model by placing icons onto the canvas. Modeler’s main three step types are Flow steps, Workflow steps, and Web Service steps. Beyond this, some steps can be thought of as being a specific step type due to their special function in a process (e.g., steps that start or end a process, join multiple threads of logic, or perform error handling); you might also think of steps that you establish in a unusual way as being a distinct step type (e.g., subprocess and referenced process steps). Steps that represent special functions in a process, or that you establish in an unusual way, are described in the following sections.

Start Steps You establish a start step for a process by virtue of its transitions (it has outgoing but no incoming transitions) and by virtue of its subscription document. A start step must subscribe to at least one document. The arrival of this document is the trigger that tells the PRT to begin running the process. For details on subscribing to a document, see “Assigning and Editing Step Inputs” on page 109. Note: Typically, you will want to establish only one start step per process model, but Modeler places no limits on the number of allowable start steps. Important! Use caution with steps that are OR joins because OR join steps that subscribe to a document can start a new process instance (at the OR join step) at run time. See the following process model for illustration.

webMethods Modeler User’s Guide Version 6.1

85

CHAPTER 5 Adding Steps to a Process Model

Example of an OR join step as a possible start step

In the above model, if the subscription document for Step 3 arrives before Step 2 executes, the PRT kicks off a new instance of the process starting at Step 3. There is no way to prevent this from occurring, so consider whether using an AND join would work just as well or better. For details on join steps, see “Join Steps” on page 88.

End Steps As the name implies, the end step is the step that you intend to be the last step in the model to run. End steps should have input transitions but no output transitions. (End steps can, however, publish documents.) However, in reality, many steps might be the last step in the model to run. For example, if timeouts and errors occur, steps that follow timeout and error transitions become the last step to run. Or, a process-wide error step might be the last step to run. In the following process model, the Send Confirmation step is the target end step, while the Send Error step might actually become the end step in the event that the error transitions are taken.

86

webMethods Modeler User’s Guide Version 6.1

Step Functions and Step Types

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

Within a process model, access process model properties.

2

From the Error Step property pull-down, select a standalone step to be the processwide error step. See the process-wide error step in the following model.

Model Containing a Process-Wide Error Step

webMethods Modeler User’s Guide Version 6.1

87

CHAPTER 5 Adding Steps to a Process Model

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

When you create a join, you must specify a join type for the step that is receiving the join (i.e., the join step). You assign a join type using Step Properties.

88

webMethods Modeler User’s Guide Version 6.1

Step Functions and Step Types

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

Referenced Process Steps Steps that invoke an entirely separate business process are known as referenced process steps. For important details on creating process models that contain referenced processes, see Appendix B, “Guidelines for Working with Referenced Processes”. To Establish a Referenced Process Step 1

While working in a business process, select Insert from the process toolbar.

2

From the Insert window, choose a process and click Insert and Close.

3

Place the step onto the canvas and name it.

As shown in the sample model below, referenced process step icons (see the “PO process” step) are distinct from the icons of other steps.

webMethods Modeler User’s Guide Version 6.1

89

CHAPTER 5 Adding Steps to a Process Model

Example of a referenced process step

To Edit a Referenced Process Step 1

2

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.

Edit the process. When you edit a referenced process, the changes are automatically reflected in all processes that reference it. In this case, all changes take effect in process models A, B, and C.

Subprocess Steps You can collapse several steps into a single icon to make a complex model visually cleaner. Unlike referenced process steps, subprocess steps simply provide a single visual container for steps within the same process model, rather than pointing to an entirely separate business process. The subprocess does not affect the way steps execute.You can easily descend into a subprocess to view its steps. To Establish a Subprocess Step

90

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

webMethods Modeler User’s Guide Version 6.1

Step Functions and Step Types

3

Right-click and select Collapse to subprocess. The single subprocess icon appears in place of the collapsed steps.

Accessing and Editing a Subprocess You can easily descend into subprocess steps for viewing or editing. To Access and Edit a Subprocess 1

Double-click the subprocess step; or, select it and click the Zoom into icon from the process toolbar. The collapsed steps appear, along with arrows depicting which step precedes and follows the subprocess, as shown below.

Note: If you create a subprocess out of steps not yet linked by transitions, the subprocess will not contain the “from” and “to” arrows depicted above because Modeler does not know which steps precede and follow the subprocess. You must establish the steps that precede and follow the subprocess at some point before generation. When you do, ensure that the subprocess contains the “from” and “to” arrows depicted above, and that the arrows are connected to the correct steps. 2

To exit the subprocess and return to the main canvas, select the Zoom out icon from the process toolbar.

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

webMethods Modeler User’s Guide Version 6.1

91

CHAPTER 5 Adding Steps to a Process Model

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

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

92

webMethods Modeler User’s Guide Version 6.1

Working with Web Service Steps

or an underscore and may contain no spaces. For full details on NCName compliance see:

The port types you define in your web service interaction will depend on the type of interaction you are trying to model: If you are invoking a web service of a partner, then you will need to choose the port type for that web service as My Partner's Port Type when configuring the web service interaction. You should import the port type definition from a WSDL file. See “Defining Web Service Port Types” on page 95. If your process is invoked using a web service call from an external entity, you will need to create a new port type for the My Process' Port Type half of the web service interaction. In creating a new port type for your process you will define the operations and their inputs and outputs. See “Defining Web Service Port Types” on page 95. If you have a series of calls and responses between the web service of your partner and your process, you may define both My Partner's Port Type and My Port Type in a single web service interaction. Follow these steps to define web service interactions in Modeler. To Define a Web service interaction 1

Choose FileNew to open a new process model.

2

Set the process model properties. For descriptions of process model properties, see Chapter 4, “Process Model Properties”.

3

Choose ViewWeb Service Interactions to display the Web Service Interactions dialog.

webMethods Modeler User’s Guide Version 6.1

93

CHAPTER 5 Adding Steps to a Process Model

4

Click Add. A new web service interaction field is displayed.

5

Type the name of the web service interaction in the Interaction Name field.

6

Define port type information for My Partner’s Port Type and/or My Process’s Port Type.

7

Choose FileSave to enter a name for the process model and save it. The web service interactions defined in this procedure are now available for use in this process.

Importing Port Types from a WSDL File Use the Web Service Interactions dialog to import port types from a WSDL file. To import port types from a WSDL file 1

94

Choose ViewWeb Service Interactions to display the Web Service Interactions dialog.

webMethods Modeler User’s Guide Version 6.1

Working with Web Service Steps

2

Click Import Port Type from WSDL. The Select WSDL Import file dialog appears.

3

Navigate to the desired folder, select the WSDL file and click Open to import port types from the WSDL file.

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

webMethods Modeler User’s Guide Version 6.1

95

CHAPTER 5 Adding Steps to a Process Model

Defining New Process Port Types Use the Web Service Interactions dialog to define new process port types. To define new process port types

96

1

Choose ViewWeb Service Interactions to display the Web Service Interactions dialog.

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.

webMethods Modeler User’s Guide Version 6.1

Working with Web Service Steps

Adding Web Service Steps Follow these instructions to add web service steps to your process. To add a Web service step 1

Click the Web Service step icon

2

Click the canvas to place the web service step in the process.

3

Type the step name in the highlighted name field.

in the toolbar.

Defining Web Service Configuration Use the Web Service Configuration dialog to define the activity for the web service step. The choices are: Invoke Receive Reply To Define Web service configuration 1

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

webMethods Modeler User’s Guide Version 6.1

97

CHAPTER 5 Adding Steps to a Process Model

2

Choose the activity type for the Web Service step.

3

Continue defining the following web service configuration for the step: Interaction Port Type Operation Input Variable Output Variable

The following sections outline the steps to configuring Web Service Invoke, Receive, and Reply steps.

Web Service Invoke To invoke a web service you use a Web Service Invoke step. To Define a Web Service Invoke step 1

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

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

98

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.

webMethods Modeler User’s Guide Version 6.1

Working with Web Service Steps

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

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

Using Static Binding For static binding of an endpoint reference to a web service interaction, you will need to create a flow step which transitions to the web service invoke step. To use static binding 1

Lock global data, using the pub.prt.globalData:lockGlobalData service, mapping the input ProcessData fields ProcessInstanceID, ProcessIteration and ProcessStepID to their counterparts in the service input.

2

Define an EndPointReference document that contains all of the necessary binding information for the web service you wish to invoke.

3

Assign this Endpoint Reference to the “value” document of the pub.prt.assign:literalToPartner service.

webMethods Modeler User’s Guide Version 6.1

99

CHAPTER 5 Adding Steps to a Process Model

4

If the web service is running on a webMethods Integration Server, you must also assign authentication data for the literalToPartner service. If using the default Integration Server configuration, this can be set to: type=basic user=Administrator password=manage

5

Statically assign the partnerTo value for the literalToPartner service to the name of the web service interaction of the web service invoke step you wish to bind.

Using Dynamic Binding For dynamic binding of WSDL to an endpoint reference, you will need to create an assign step which transitions to the web service invoke step. To bind the assign step from pipeline data 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

Map an EndPointReference document from your process to the “value” document in the pub.prt.assign:literalToPartner service.

3

If the web service is running on a webMethods Integration Server, you must also assign authentication data for the literalToPartner service. If using the default Integration Server configuration, this can be set to: type=basic user=Administrator password=manage

4

Statically assign the partnerTo value for the literalToPartner service to the name of the web service interaction of the web service invoke step you wish to bind.

To bind the assign step from global data

100

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

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.

webMethods Modeler User’s Guide Version 6.1

Working with Web Service Steps

To copy binding from another web service interaction 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

Statically assign the partnerFrom, roleFrom and partnerTo values, all of which are set in the process Modeler using the web service interactions definitions.

Using Deployment-time Binding For deployment-time binding of WSDL to an endpoint reference, one will need to create an assign step which transitions to the web service invoke step, as with static and dynamic binding. To use deployment-time binding 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

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 /packages/<package-name>/config/wsdl/ directory. If deployed at runtime, the WmPRT package will need to be

reloaded in order to deploy the WSDL.

Mapping WSDL Elements to EndPointReference Document Fields WSDL elements map to EndPointReference document fields as follows: WSDL Element

EndPointReference Field

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

address

<portType name='portType-value'/>

portType

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

operation.namespaceName operation.localName operation.Service.soapAction binding.soapBinding.soapStyle binding.soapBinding.soapTransport

Note: For each operation per port type, these mappings are made (a port type can have multiple operations)

webMethods Modeler User’s Guide Version 6.1

101

CHAPTER 5 Adding Steps to a Process Model

The following is a sample WSDL file, showing the elements to be mapped: urn_xmethods-delayed-quotes.wsdl ------------------------------- <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 name='getQuoteRequest1'> <part name='symbol' type='xsd:string'/> <portType name='net.xmethods.services.stockquote.StockQuotePortType'>

<soap:binding style='rpc' transport='http://schemas.xmlsoap.org/soap/http'/> <soap:operation soapAction='urn:xmethods-delayed-quotes#getQuote'/> <soap:body use='encoded' namespace='urn:xmethods-delayed-quotes' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'/>

<soap:body use='encoded' namespace='urn:xmethods-delayed-quotes' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'/>

<service name='net.xmethods.services.stockquote.StockQuoteService'> <documentation>net.xmethods.services.stockquote.StockQuote web service <port name='net.xmethods.services.stockquote.StockQuotePort' binding='tns:net.xmethods.services.stockquote.StockQuoteBinding'> <soap:address location='http://66.28.98.121:9090/soap'/>

102

webMethods Modeler User’s Guide Version 6.1

Working with Web Service Steps

This WSDL can be represented as an EndPointReference document as follows: EndPointReference document: -------------------------address=http://66.28.98.121:9090/soap portType=net.xmethods.services.stockquote.StockQuotePortType auth type=null user=null operation namespaceName=urn:xmethods-delayed-quotes localName=getQuote soapAction=urn:xmethods-delayed-quotes#getQuote binding soapStyle=rpc soapTransport=http://schemas.xmlsoap.org/soap/http

Web Service Receive To perform web service receive in Modeler, you define a web service receive step. To Define a Web Service Receive step 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 Receive button.

4

Select the Web Service Interaction for this step from the Interaction drop down list.

5

Select the web service operation to be invoked from the Operation drop down list.

6

Select the input data for the web service by selecting either an existing pipeline input or New Global Data from the Input Variable drop down list. If New Global Data was chosen, enter the global data Instance Name.

7

Select the output variable from the Output Variable drop down list. Choose either New Global Data or New Pipeline Data and enter the Instance Name for either data format.

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

webMethods Modeler User’s Guide Version 6.1

103

CHAPTER 5 Adding Steps to a Process Model

Web Service Reply A Web Service Reply Step is used to send a synchronous response to a preceding Web Service Receive call. In order to perform web service reply, you must define both a web service receive step and a web service reply step in the process modeler. The reply will be associated with the receive only if the same Web Service Interaction is declared for both steps. To Define a Web Service Reply step 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 Reply button.

4

Select the Web Service Interaction for this step from the Interaction drop down list.

5

Select the web service operation to be invoked from the Operation drop down list.

6

Select the input data for the Web Service by selecting either an existing pipeline input or New Global Data from the Input Variable drop down list. If New Global Data was chosen, enter the global data Instance Name.

7

Select the output variable from the Output Variable drop down list. Choose either New Global Data or New Pipeline Data and enter the Instance Name for either data format.

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

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

104

webMethods Modeler User’s Guide Version 6.1

Controlling the Visual Properties of Steps

Controlling the Visual Properties of Steps There are two types of visual step properties that you can control: A step’s icon type The display of a step’s inputs and outputs

Changing a Step’s Icon Type Modeler provides many types of icons to help you make process models as visually intuitive as possible. You can specify a default icon for steps, as well as change step icons individually. Note: You cannot change the icon for Workflow steps.

To Change the Icon of a Single Step 1

From within a process model, right-click on a step.

2

Select Change Image. The Choose Image dialog appears.

3

Select an icon and click OK.

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

webMethods Modeler User’s Guide Version 6.1

105

CHAPTER 5 Adding Steps to a Process Model

106

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

6

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

webMethods Modeler User’s Guide Version 6.1

107

CHAPTER 6 Assigning Inputs and Outputs to Steps

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

Types of Inputs and Outputs Available to Steps There are two main types of inputs and outputs that you can assign to steps in the process model. Publication/subscription documents. Publication and subscription documents are documents that your process model is to publish or to which your process is to create a subscription. These publications and subscriptions allow your process model to send information to and receive information from applications or entities external to your process model. The types of documents that you can publish and/or to which you can subscribe are: IS documents that are exchanged through the Broker. This type of document allows communication between the various webMethods components. IS documents used in the process become part of the process pipeline. External documents that are exchanged through webMethods Trading Networks. Examples of these types of documents are purchase orders, confirmations, acknowledgements, etc. External documents never become part of the process pipeline. Note: There is an important functional difference between publishing an external document and publishing an IS document. For details, see “Publication and External Documents” on page 136. Input/output data. In contrast to publications and subscriptions, input and output data is data that is in the process pipeline. Specifically, input data is data or documents that Modeler makes available as input to steps because they exist in the process pipeline. Output data is data or documents that you specify steps should produce, thereby adding the data to the process pipeline. Global data. Provides an alternative means to share data across Flow Steps and Web Service Steps. Global data is accessible from within any Flow Step in a single process via predefined services, and it can be selected as inputs and outputs to Web Service Steps. You can also use global data to define data properties and data property aliases.

108

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Inputs

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

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

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

webMethods Modeler User’s Guide Version 6.1

109

CHAPTER 6 Assigning Inputs and Outputs to Steps

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

Adding a Subscription to an External Document When Trading Networks receives a document identical to a document that a process step subscribes to, Trading Networks passes the document to the PRT to become part of the running process. The following procedure describes how to assign an external document subscription to a step. For important guidelines on working with steps with external subscriptions, see “Guidelines for Using External Documents in the Process Model” on page 112. Note: Ensure the external document exists on the step’s logical server prior to assigning the subscription. .

To Add a Subscription to an External Document

110

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

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Inputs

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.

webMethods Modeler User’s Guide Version 6.1

111

CHAPTER 6 Assigning Inputs and Outputs to Steps

Note: When you subscribe to an external document, you are prompted to select roles for the document’s sender and receiver. If the document’s sender/receiver role corresponds to your role in the process, the sender/receiver value should correspond to the value defined in the process model’s Focal Role property. You can use roles to create publish/subscribe filters and transition conditions. 6

In the Sender Role field, type the name of the sender’s role.

7

On the Set TN Roles dialog, click OK. The Inputs and Outputs dialog reappears with the newly added subscription in the Inputs box.

8

On the Inputs and Outputs dialog, click OK.

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

112

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Inputs

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.

webMethods Modeler User’s Guide Version 6.1

113

CHAPTER 6 Assigning Inputs and Outputs to Steps

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

114

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Inputs

Example using conditions on transitions

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

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

webMethods Modeler User’s Guide Version 6.1

115

CHAPTER 6 Assigning Inputs and Outputs to Steps

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.

116

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.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Inputs

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.

6

On the Inputs and Outputs dialog, click OK.

To Add a Subscription to a New IS Document 1

Right-click on the step and choose Edit Inputs/Outputs; or, from the step’s Inputs/Outputs property, select Edit. The Inputs and Outputs dialog appears.

webMethods Modeler User’s Guide Version 6.1

117

CHAPTER 6 Assigning Inputs and Outputs to Steps

118

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.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Inputs

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.

webMethods Modeler User’s Guide Version 6.1

119

CHAPTER 6 Assigning Inputs and Outputs to Steps

Editing Subscription Documents You can edit the instance name (or role) of an input subscription document. For publishable IS document subscriptions only, you can also edit the contents of the document. Editing the Instance Name (or Role) of a Subscription Document You can edit the instance name of any existing input subscription. For external document subscriptions only, you can also edit the roles that you have assigned to the document. To Edit the Name (or Role) of a Subscription Document 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 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.

4

On the Inputs and Outputs dialog, 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.

120

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Inputs

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

From the Inputs box, choose the subscription document that you want to edit and click Edit Document Type. If Developer was not open, Modeler launches Developer in a separate window at the location of the selected document. If Developer was open, Modeler uses the open instance of Developer to locate the selected document.

3

From the Developer menu, choose FileLock. This locks the document so that others cannot modify the document while you are editing it.

4

Edit the document as needed.

5

Save your changes.

6

From the Developer menu, choose FileUnlock.

7

Return to Modeler’s Inputs and Outputs dialog and click OK.

webMethods Modeler User’s Guide Version 6.1

121

CHAPTER 6 Assigning Inputs and Outputs to Steps

Deleting Subscription Documents Use the following procedure to delete a subscription document. To Delete an Existing 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.

Note: When you delete a subscription document, Modeler deletes the document from the step and from the pipeline, but not from the server on which it resided.

Input Data You add input data to a step rather than subscribe to a document when the data the step needs is in the step pipeline. With the exception of external documents, this amounts to all data (inputs, outputs, subscriptions, and publications) used upstream in the process. The steps for adding and editing input data are described below.

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

122

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.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step 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”. 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.

5

On the Inputs and Outputs dialog, click OK.

webMethods Modeler User’s Guide Version 6.1

123

CHAPTER 6 Assigning Inputs and Outputs to Steps

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

Deleting Input Data Use the following procedure to delete input data from a step. To Delete Existing Input Data 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 Inputs box, select the input you want to delete and click Delete. The input is deleted from the step. Note: When you choose to delete existing input data, Modeler deletes the input data from the step and from the pipeline, but not from the server on which it resided.

3

On the Inputs and Outputs dialog, click OK.

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

124

webMethods Modeler User’s Guide Version 6.1

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. To Add a Publication to a Pre-existing IS Document 1

Right-click on the step and choose Edit Inputs/Outputs; or, from the step’s Inputs/Outputs property, select Edit. The Inputs and Outputs dialog appears.

2

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

webMethods Modeler User’s Guide Version 6.1

125

CHAPTER 6 Assigning Inputs and Outputs to Steps

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.

6

On the Inputs and Outputs dialog, click OK.

To Add a Publication to a IS New Document

126

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

Click New Document Type. The New Document Type window appears.

4

Browse to the package and folder in which you want the new publication document to reside.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Outputs

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.

8

Return to Modeler’s Inputs and Outputs dialog and click OK.

Editing Publication Documents You can edit the instance name or contents of a publication document. To Edit the Instance Name of an Existing Publication Document 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 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.

4

On the Inputs and Outputs dialog, click OK.

webMethods Modeler User’s Guide Version 6.1

127

CHAPTER 6 Assigning Inputs and Outputs to Steps

To Edit the Contents of an Existing Publication Document

128

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

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.

4

Return to Modeler’s Inputs and Outputs dialog and click OK.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Outputs

Deleting Publication Documents Use the following procedure to delete a subscription document from a step. To Delete an Existing Publication Document 1

Right-click on the step and choose Edit Inputs/Outputs; or, from the step’s Inputs/Outputs property, select Edit. The Inputs and Outputs dialog appears.

2

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

Note: When you delete a publication document, Modeler deletes the document from the step and from the pipeline, but not from the server on which it resided.

Output Data You add output data rather than publications to a step when you do not need to publish the output data or document to the Broker. The steps for adding and editing output data are described in the following sections.

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

webMethods Modeler User’s Guide Version 6.1

129

CHAPTER 6 Assigning Inputs and Outputs to Steps

To Add Pre-existing Output Data to a Step

130

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

5

On the Inputs and Outputs dialog, click OK.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Outputs

To Add New Output Data to a Step 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 Output. The Add Output window appears.

3

Click New Document Type. The New Document Type window appears.

4

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

webMethods Modeler User’s Guide Version 6.1

131

CHAPTER 6 Assigning Inputs and Outputs to Steps

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.

8

Return to Modeler’s Inputs and Outputs dialog and click OK.

Editing Output Data When you change an output’s instance name, all downstream inputs that reference that output will also be modified accordingly. For example, assume the output of Step 1 is named “PO” and that Step 2 selects “PO” as input. If you change the output name of Step 1 from “PO” to “Doc”, Modeler automatically changes the Step 2 “PO” input name to “Doc”. To change the instance names for existing output documents, use the procedure below. To Edit Existing Output Data Instance Names

132

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.

4

On the Inputs and Outputs dialog, click OK.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Outputs

Deleting Output Data Use the following procedure to delete output data from a step. To Delete Output Data 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 you want to delete and click Delete. The output is deleted from the step. Note: When you delete an existing output document, Modeler deletes the document from the step and from the pipeline, but not from the server on which it resided.

3

On the Inputs and Outputs dialog, click OK.

Fields You can add small pieces of output data (i.e., fields) to a step, such as Strings, String tables, Booleans, integers, dates, objects, and so on. The steps for adding and editing output fields are described in the following sections.

Adding Fields Use the following procedure to add output fields to a step. To Add an Output Field to a Step 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.

webMethods Modeler User’s Guide Version 6.1

133

CHAPTER 6 Assigning Inputs and Outputs to Steps

2

Click Add Field. The New Field window appears.

3

In the Field Name box, type an instance name for the field. For information on instance names, see the note on page 109.

4

In the Field Type list, select the type of data that the step should output.

5

If you want the output data to be a List, check the List box. Note: The only field type for which the List option is disabled is the String table type. By definition, the String table type arranges data in lists, therefore, it is not necessary to specify List for this data type.

134

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.

9

On the Inputs and Outputs dialog, click OK.

webMethods Modeler User’s Guide Version 6.1

Assigning and Editing Step Outputs

Editing Fields If you want to change the instance names for existing output data fields, use the procedure below. To Edit the Instance Names of Existing Output Data Fields 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 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.

4

On the Inputs and Outputs dialog, click OK.

webMethods Modeler User’s Guide Version 6.1

135

CHAPTER 6 Assigning Inputs and Outputs to Steps

Deleting Fields Use the following procedure to delete fields from a step. To Delete Existing Output Data Fields 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 output field that you want to delete and click Delete. The output field is deleted from the step. Note: When you delete existing output fields, Modeler deletes the fields from the step and from the pipeline, but not from the server on which the fields resided.

3

On the Inputs and Outputs dialog, click OK.

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

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

136

webMethods Modeler User’s Guide Version 6.1

Controlling the Display of Inputs and Outputs

Controlling the Display of Inputs and Outputs You can control the display of a process model’s inputs and outputs so that they display in one of the following ways: You can display the full names of inputs and outputs, where each input or output displays with instance_name (document type_name). To do so, to go Tools  Options and enable Show Data Types. Then, enable Show Inputs/Outputs at the bottom of the Process window. the following process model has full inputs and outputs on display.

Note: Subscription documents and publication document names appear with a dotted border while all other inputs and output names appear with a solid border. You can view only the instance names of inputs and outputs. To do so, to go Tools  Options and disable Show Data Types. Then, enable Show Inputs/Outputs at the bottom of the Process window. Note: You must exit and re-open the process model for the change to take effect.

webMethods Modeler User’s Guide Version 6.1

137

CHAPTER 6 Assigning Inputs and Outputs to Steps

See the following process model.

You can turn off the display of inputs and outputs completely. To do so, to go Tools  Options and disable Show Data Types. Then, disable Show Inputs/Outputs at the bottom of the Process window.

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

138

webMethods Modeler User’s Guide Version 6.1

Using the Publish/Subscribe Filter

To Choose Fields to Log to the Process Audit Log 1

Right-click the step and select Choose logged fields; or, from the step’s Logged Fields property, select Edit. The Choose Logged Fields window appears displaying all inputs and outputs.

2

Browse the inputs and outputs for the fields that you want to log, and check the Log box next to the fields that you want to log.

3

Click OK.

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

webMethods Modeler User’s Guide Version 6.1

139

CHAPTER 6 Assigning Inputs and Outputs to Steps

For publication and subscription documents that are external documents, you can also set filters based on the roles that you assigned to the document. To use the publish/subscribe filter, follow the steps below. To Use the Publish/Subscribe Filter

140

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.

webMethods Modeler User’s Guide Version 6.1

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.

webMethods Modeler User’s Guide Version 6.1

141

CHAPTER 6 Assigning Inputs and Outputs to Steps

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

Specify...

Field Name

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

142

webMethods Modeler User’s Guide Version 6.1

Working with Global Data

For this Field...

Specify...

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.

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

webMethods Modeler User’s Guide Version 6.1

143

CHAPTER 6 Assigning Inputs and Outputs to Steps

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

Using Global Data in Your Process To manipulate Global Data in your process, use the predefined services in the pub.PRT.assign package. All the predefined services are based on the BPEL specification. These services allow you to copy between variables and XPath expressions and bindings to Web Service Interactions (referred to as “Partner” in the predefined services names and parameters). Refer to the webMethods Built-In Services Reference for a detailed description of each assign service. Note: Always call the service "pub.prt.globalData.lockGlobalData" in your flow before working using any of the Assign services. It is not necessary to manually unlock the data. If you want your work with Global Data to be exportable to BPEL Assign activities, you need to put all of the Assign services within the Generated Flow of a Flow Step. To define global data for use in a process, follow the steps below. To define global data

144

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.

webMethods Modeler User’s Guide Version 6.1

Working with Global Data

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

From the process’s Data Properties property, select Edit. The Data Properties and Data Property Aliases dialog appears.

2

Click Add. The Add Property dialog appears.

3

Type the name of the data property, choose the data type from the menu, and click OK. The data property is added to the list.

4

To define a data property alias, click Add under Data Property Aliases and fill-in the required information for the alias.

webMethods Modeler User’s Guide Version 6.1

145

CHAPTER 6 Assigning Inputs and Outputs to Steps

146

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

7

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

webMethods Modeler User’s Guide Version 6.1

147

CHAPTER 7 Adding Logic to Steps

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

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

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

148

webMethods Modeler User’s Guide Version 6.1

Working with Flow Step Logic

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

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

webMethods Modeler User’s Guide Version 6.1

149

CHAPTER 7 Adding Logic to Steps

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

PRT Services that You Might Want to Use in User-Defined Services The webMethods WmPRT package contains a pub folder with services that you might want to use in your user-defined services. Two of these services are described below. For complete documentation on these services, see webMethods Built-In Services Reference. Controlling the Process’s Run-Time Status As a business process runs, the PRT determines the status for the process and its steps. This status information is made visible to administrators through webMethods Monitor. For example, by default, after a step fails, the PRT assigns a “Failed” status to the step, but not to the entire process. However, there may be cases where you would want a process’s status to be other than the default status. For example, you might want a process to carry a “Failed” status if a single step fails. At design time, you can use the pub.prt.admin:changeProcessStatus service under the WmPRT package to designate that a process should carry a user-defined status at run time; use this service within the logic of the appropriate step. For example, if you want Process A to carry a “Failed” status if Step B fails, call the pub.prt.admin:changeProcessStatus service within the logic of Step B. Administrators using webMethods Monitor to view Process A at run time should see a “Failed” status after Step B fails. Creating and Logging User-Defined Activity Messages The WmPRT package contains a service that enables you to create and log user-defined activity messages. The service is pub.prt.admin.log:logActivityMessages. Activity captured by this service is viewable through webMethods Monitor at run time.

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

150

1

Open the process model.

2

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

3

Choose Select Service to Invoke.

webMethods Modeler User’s Guide Version 6.1

Working with Workflow Step Logic

4

Browse through the packages on the IS Server and select the service to invoke.

5

Click Select.

Working with Workflow Step Logic When you generate a process model, for each Workflow step in the model, Modeler generates Workflow projects, implementation modules, and Workflow tasks in the webMethods Workflow environment.

Guidelines for Generated Workflow Components After generating the process model and before deploying it, configure the generated Workflow components using the following guidelines: 1

In the Workflow environment, create a Workflow document containing the data that the generated Workflow components will need. For example, if the Workflow step is an “Approve Purchase Order” step, the data in the document should contain all pertinent information related to approving the purchase order (e.g., the purchase order’s amount, the buyer’s credit limit, etc.).

2

In the generated implementation module, use the Workflow document that you created as a blueprint to create a new data field. Map the data field from the Start node of the generated implementation module to the newly created data field. Then, map the newly created data field to the data field in the generated implementation module’s Complete node.

3

Create a data field in the generated workflow and map the data from the implementation module data field into the Workflow data field. Complete the workflow.

For details on using webMethods Workflow, see the webMethods Workflow User’s Guide.

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

Open the process model.

2

Right-click on the Workflow step.

webMethods Modeler User’s Guide Version 6.1

151

CHAPTER 7 Adding Logic to Steps

3

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

4

Browse to the Workflow project to invoke and click Select.

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

Checklist of Correlation Services Tasks In general, for every process model, you should:

152

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.

webMethods Modeler User’s Guide Version 6.1

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 ID Before you create a correlation service, you need to determine the method you will use to form it. The correlation service should output a correlation ID that: Is the same for all IS documents involved in an instance of a process Is unique among all other correlation IDs Contains 1-240 characters Because the correlation ID must be the same for all documents involved in an instance of a process, you will probably want to use information from within an IS document that is common to all IS documents in a single process instance. For example, if you define a process that processes an order, each document in the process might have a common order ID that you could use when forming your correlation ID. Because the correlation ID must be unique among all other correlation IDs, when forming your process ID, include something that makes the correlation ID unique. Keep in mind that you want to use something that is reproducible for all documents for a specific process instance. For example, you would not want to use part of a timestamp because the timestamp would be different when each document for a process instance arrives.

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

webMethods Modeler User’s Guide Version 6.1

153

CHAPTER 7 Adding Logic to Steps

by using the process model ID that is passed as input into the correlation service and the order ID.

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

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

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

154

webMethods Modeler User’s Guide Version 6.1

Working with Correlation Services

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

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

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

Description

ProcessModelID

String The ID of the process model with which this invocation of the correlation service is involved, for example, "P100099FF3".

LogicalServer

String The name of the logical server on which this correlation service is running, for example, “Design_Server”.

ProcessStepID

String The ID of the step in the model with which this invocation of the correlation service is involved, for example, "N3".

DocumentName

String The name of this document as used in the process model (e.g. "OrderDocument").

webMethods Modeler User’s Guide Version 6.1

155

CHAPTER 7 Adding Logic to Steps

Input variable

Description

DocumentType

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

Document

document (IData object) The document.

Your correlation service should return the following output: Output variable

Description

ProcessCorrelationID

String Optional. An identifier that is common to all IS documents that are to be processed in a single instance of a process. The PRT correlates the correlation ID that you specify (in ProcessCorrelationID) with the actual process instance ID of the running process. All documents bound for the same instance of the process must return the same correlation ID. By the same token, correlation IDs must be unique across all process instances. For example, "CUSTOMER-0003456977::ORDER-19477593-AR9-1000"

CorrelateAsTN

String Optional.Whether you want the PRT to treat the correlation ID you specify in ProcessCorrelationID exactly as if it were a Trading Networks conversation ID. Use this to match IS documents to a process that was started by a Trading Networks document. Specify one of the following for CorrelateAsTN: true to indicate you want the correlation ID treated as a Trading Networks conversation ID false to indicate that you do not want the correlation ID treated as a Trading Networks conversation ID; this is the default output value

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

156

webMethods Modeler User’s Guide Version 6.1

Working with Correlation Services

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

Open the process model.

2

Right click on the step and choose Select Correlation Service; or, select the drop-down menu of the step’s Correlation Service property. The IS packages associated with the step’s logical server appear.

3

Browse to the correlation service and select it.

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

Open the process model.

2

Right click on the step and choose Edit Correlation Service. The Developer appears at the location of the correlation service so that you can edit the service.

3

From the Developer File menu, choose Lock. This locks the service so that others cannot modify the service while you are editing it.

4

Edit the service as needed.

5

Save your changes.

6

From the Developer File menu, choose Unlock.

Deleting an Existing Correlation Service To Delete a Correlation Service 1

Open the process model.

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.

webMethods Modeler User’s Guide Version 6.1

157

CHAPTER 7 Adding Logic to Steps

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

158

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

8

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

webMethods Modeler User’s Guide Version 6.1

159

C H A P T E R 8 C r e a t i n g S t e p Tr a n s i t i o n s

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

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

160

webMethods Modeler User’s Guide Version 6.1

Creating Step Transitions

Creating Step Transitions Follow the steps below to create step transitions. To Create Step Transitions 1

Place all steps associated with a given transition onto the canvas.

2

Draw transitions to steps as needed. Depending on how you draw transitions, you might create splits, branches, or joins, described in “Splitting, Branching, and Joining Logic in a Process” on page 163.

3

Specify the transition type: a

If it is a Normal, Error, Timeout, or Retries Exceeded transition, right-click on the transition and choose Change Transition Type. Then choose Normal, Error, Timeout, or Retries Exceeded. (The default transition type is Normal.)

b

If it is an Else transition, right-click on the transition and choose Set as “else” transition. The Edit Transition Conditions window appears. Check Set as “else” transition and then click OK.

4

Set transition properties by right-clicking on the transition and choosing Properties. For details, see “Transition Properties” on page 162.

5

Optional. To place conditions on a Normal transition, right-click on the transition and choose Edit transition condition (or, choose Edit on the transition’s Properties panel). The Edit Transition Conditions To Target Step window appears so that you can build the condition. For steps on building transition conditions, see “Building Transition Conditions” on page 163.

6

Ensure that all steps other than the process-wide error handling step are linked by transitions. For details, see “Ensure a Clear Flow of Control” on page 168.

webMethods Modeler User’s Guide Version 6.1

161

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

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

Description

Default

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.

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: To make this transition an Else transition, right-click on the transition and choose Set as “else” transition. To enter a condition, click the Edit button.

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

162

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.

webMethods Modeler User’s Guide Version 6.1

Splitting, Branching, and Joining Logic in a Process

Splitting, Branching, and Joining Logic in a Process Depending on how you design your transitions, you can create any of the following types of logic: Splits. Splits are created when you draw transitions from one step to two or more steps without placing conditions on the transitions. At run time, all transitions are executed and processing splits into two or more threads of execution. Branches. Branches are created when you draw transitions from one step to two or more steps and place conditions on the transitions. At run time, at most one transition is executed. For details on building transition conditions, see “Building Transition 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

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

webMethods Modeler User’s Guide Version 6.1

163

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

Defining Transition Conditions Use the following procedure to define a transition condition. To Define a Transition Condition

164

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.

webMethods Modeler User’s Guide Version 6.1

Building Transition Conditions

Edit Transition Conditions Window For this Field...

Specify...

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.

webMethods Modeler User’s Guide Version 6.1

165

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

For this Field...

Specify...

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.

166

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.

webMethods Modeler User’s Guide Version 6.1

Building Transition Conditions

Defining Transition Conditions Using XPath Expressions Use the following procedure to define a transition condition using an XPath expression. To Define a Transition Condition using an XPath expression 1

Right-click the transition and select Edit transition condition; or, from the transition’s Condition property, select Edit. The Edit Transition Conditions window appears.

2

To specify a transition condition using an XPath expression, click Use XPath Expression.

3

Enter the XPath expression in the Expression field. A description is optional.

4

Click OK.

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

webMethods Modeler User’s Guide Version 6.1

167

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

Guidelines for Transitions Use the following guidelines when working with transitions.

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

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

168

webMethods Modeler User’s Guide Version 6.1

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

webMethods Modeler User’s Guide Version 6.1

169

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

Guidelines for Transitions that Create Splits and Joins Keep splits and joins as simple as possible Place join logic shortly after the split if you will rejoin the threads Be careful using conditions with joins See the following examples for details. Use caution when using OR joins after splits OR joins allow multiple threads of execution to run simultaneously after the join. When the PRT encounters an OR join, it continues a thread for each transition coming into the OR join. In the following sample process model, the numbers on the transitions represent the number of threads processing. OR joins and number of threads of execution

Three threads arriving at different times. Each thread continues.

Six threads arriving

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.

170

webMethods Modeler User’s Guide Version 6.1

Guidelines for Transitions

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

webMethods Modeler User’s Guide Version 6.1

171

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

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.

172

webMethods Modeler User’s Guide Version 6.1

Guidelines for Transitions

Pipeline variable names are not distinct It is not predictable whether the values in the resulting pipeline will be from the thread that executed Step A or the thread that executed Step B.

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

webMethods Modeler User’s Guide Version 6.1

173

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

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

174

webMethods Modeler User’s Guide Version 6.1

The Appearance of Transitions

The Appearance of Transitions Displaying/Hiding Transitions Types If the Show Transition Conditions property is enabled, the transition type appears on the transition in the model, with the exception of Normal transitions. Visible Transition Types

To hide/display transition types, choose ToolsOptions and check or uncheck the Show Transition Types property.

Controlling the Color of Transitions Default Transitions You can specify a default color for Normal transitions by choosing ToolsOptions and selecting a color from the Line Color property.

webMethods Modeler User’s Guide Version 6.1

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

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

176

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

9

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

webMethods Modeler User’s Guide Version 6.1

177

CHAPTER 9 Adding Groups to a Process Model

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

178

webMethods Modeler User’s Guide Version 6.1

Adding a Group

Model with Internal and External Groups

Internal groups box steps that are performed within your enterprise

External groups box steps that are performed outside your enterprise.

Adding a Group To add an internal or external group to a process model, use the following procedure. To Add a Group to a Process Model 1

On the process model taskbar, select the Draw Group icon.

2

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

webMethods Modeler User’s Guide Version 6.1

179

CHAPTER 9 Adding Groups to a Process Model

3

Select Internal group or External organization, depending on the type of group you are creating. By default, an internal group appears as a shaded gray rectangle with solid borders. By default, an external group appears as a shaded blue rectangle with dotted borders.

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

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

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

180

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

10

Importing and Exporting BPEL Process Models Importing BPEL Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Exporting Process Models in BPEL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

webMethods Modeler User’s Guide Version 6.1

181

CHAPTER 10 Importing and Exporting BPEL Process Models

Importing BPEL Process Models Complete the following steps to import a BPEL process model. To import a BPEL process model 1

From the File menu, select Import.The Select import file dialog appears.

2

Select the desired .bpel file and click Open. The Select WSDL import file dialog appears.

3

Select all of the .wsdl files associated with this process (using group select) and click Open. The imported process appears, along with any warnings or errors encountered during the import. Warnings are displayed identifying any unsupported BPEL constructs skipped during import. If these warnings occur, your Modeler process may not be functionally equivalent to the original BPEL process.

Note: Version 6.1 of Modeler does not support import of XSD schema files. In order to import message types that have their parts defined in xsd documents, you must import the xsd documents directly into the Integration Server using Developer.

182

webMethods Modeler User’s Guide Version 6.1

Importing BPEL Process Models

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

Imported Process Model Element

Partner Links

Web Service Interaction

Variables

Global Data

Message and document type definitions

Integration server document definitions

BPEL Basic Activities:

Web Service Receive Step



Web Service Reply Step



Web Service Invoke Step



Terminate Step

<empty>

Empty Step



Assign Services in PRT



Not supported

<wait>

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

BPEL Structured Activities

Not supported

<while>

Transition from preceding activity defined by the while condition expression followed by the activities defined in the <while> activity that transition back into the preceding activity.

<sequence>

No effect, flow retains sequence

<scope>

Not supported

<switch>

Transitions logically equivalent to the switch



Transitions from preceding activity to each activity defined in the activity.



Multiple receive steps with XOR join

webMethods Modeler User’s Guide Version 6.1

183

CHAPTER 10 Importing and Exporting BPEL Process Models

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

Variables, Message Types, and Document Type Definitions BPEL variables become global data in Modeler when imported. Each complex message type used in the process will be generated into a record at <WSDL name>.MessageTypes:. 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:

The message types referred to by the above variables are as follows: <message name="initiateLoanFlowSoapRequest"> <part name="parameters" element="initiateLoanFlow"/> <message name="onLoanFlowResultSoapRequest"> <part name="parameters" element="onLoanFlowResult"/>

184

webMethods Modeler User’s Guide Version 6.1

Importing BPEL Process Models

On import, the variables element will be converted into an IS record named LoanFlow.Design_Server.GlobalData:LoanFlowGlobalData.LoanFlowGlobalData, which will contain document references to the following: initiateLoanFlowSoapRequest onLoanFlowResultSoapRequest

These documents define the following message types: initiateLoanFlowSoapRequest onLoanFlowResultSoapRequest

These message types are imported as: LoanFlow.MessageTypes:initiateLoanFlowRequest LoanFlow.MessageTypes:onLoanFlowResultSoapRequest

BPEL Web Service Activities The following activities are mapped directly to the corresponding type of web service step:

Receive The BPEL activity is imported as a web service receive step in the Modeler. For example, the activity

will be imported as a web service receive step with the following properties: portType = LoanFlow operation = initiate Output variable = input

webMethods Modeler User’s Guide Version 6.1

185

CHAPTER 10 Importing and Exporting BPEL Process Models

Reply The BPEL activity is imported as a web service reply step in the Modeler. For example, the activity

will be imported as a web service receive step with the following properties: portType = Default operation = "Execute" Input variable = "UANG_SyncAccount_fault"

Invoke The BPEL activity is imported as web service invoke step in the Modeler. For example, the activity

will be imported as a web service invoke step with the following properties: portType = CreditRatingService operation = process inputVariable = "crInput" outputVariable = "crOutput"

Terminate Activity The BPEL activity is imported as a terminate step.

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

Wait Activity The BPEL <wait> activity is imported as a Modeler flow step. You will need to manually set up the flow service to control the wait.

186

webMethods Modeler User’s Guide Version 6.1

Importing BPEL Process Models

While Activity The BPEL <while> activity is imported as a loop containing activities embedded in the while activity. The loop is generated on the preceding activity. Consider the following example of a while activity: <while condition="bpws:getVariableData(orderDetails) > 100">

This will be imported as an assign step which has a transition to an invoke step having condition expression = "bpws:getVariableData(orderDetails) > 100". The invoke step loops back to the assign step.

Assign Activity Modeler performs BPEL 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:

This assign activity will be generated into a flow service which will be invoking pub.prt.assign:variableToVariable with input variables set to the following values: variableNameFrom = "PO" partFrom = "customerInfo" queryFrom = "" variableNameTo = "shippingRequest" partTo = "customerInfo"

Please refer to the webMethods Built-In Services Reference for detailed information about each assign activity type and its usage.

BPEL Structural Activities The following is a list of BPEL structured activities and their equivalents in webMethods Modeler:

Sequence The activities contained in BPEL <sequence> activity on import are connected to each other in the same order as they are defined in the sequence activity. This ensures their order of execution.

webMethods Modeler User’s Guide Version 6.1

187

CHAPTER 10 Importing and Exporting BPEL Process Models

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

Switch The BPEL <switch> activity will be imported as transitions from the preceding activity for activities embedded the case and otherwise members. Consider the flowing pseudo code example of switch activity: <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 - Transition from A to C if - Transition from A to D if - Transition from A to E if (using the Modeler's "Else"

188

and only if and only if and only if and only if condition).

'P'. 'Q' and not 'P'. 'R' and not 'P' and not 'Q'. no other transitions are taken

webMethods Modeler User’s Guide Version 6.1

Importing BPEL Process Models

Flow without Links A BPEL 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 activity:

The BPEL above will be imported as a single step A, with transitions to the three activities A, B, and C.

Flow with Links The BPEL activity with links will only differ in how the activities defined inside of the flow activity are connected to each other. Links overrides any structural construct.

Pick The BPEL activity is not currently fully supported, but Modeler approximates its behavior. The activity is imported as receive step for each element that transitions to the activities defined in the element, all followed by an XOR join to the activity following the . Consider the following example of a pick activity:

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 because it allows that any of A, B, and C may execute.

webMethods Modeler User’s Guide Version 6.1

189

CHAPTER 10 Importing and Exporting BPEL Process Models

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

BPEL Export Guidelines A BPEL file, its associated WSDL file, and WSDL files that define the generated wrapper flow service for IS steps and WSDL files for all web service receive steps will be generated in the export process. The process model that is exported in BPEL format defines the entire process model using the activity with links as the transitions. The Web Service Interactions are exported as partner links. The global data is exported as BPEL . Each Web Service Step is exported as a BPEL , , or activity. Flow Steps that invoke a flow service that uses the built-in PRT Assign services will be exported as BPEL activities with copy statements derived from the logic in the PRT Assign services. Empty Steps become BPEL <empty> activities and Terminate steps become BPEL 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 activity for each document subscription, a BPEL activity for the step's generated service, and additional 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 ReceiveService. The web service invoke step exported for the generated wrapper flow service creates InvokeService.

190

webMethods Modeler User’s Guide Version 6.1

Exporting Process Models in BPEL Format

The web service invoke step exported for the publication document creates a partner link as NotificationService. The exported BPEL 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 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 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 activity and a new variable will created for the input to that activity. The variable is defined as a message named 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.

webMethods Modeler User’s Guide Version 6.1

191

CHAPTER 10 Importing and Exporting BPEL Process Models

The following is an example of an exported BPEL process: Example of Exported BPEL Process <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"/>

192

webMethods Modeler User’s Guide Version 6.1

Exporting Process Models in BPEL Format

<source linkName="Web_Service_StepA-to-Web_Service_Step"/> <source linkName="Web_Service_Step-to-Flow_Step"/> <source linkName="Web_Service_Step-to-Workflow_Step"/> <source linkName="Workflow_Step-to-Web_Service_Step1"/> <source linkName="Flow_Step-to-Web_Service_Step1"/>

webMethods Modeler User’s Guide Version 6.1

193

CHAPTER 10 Importing and Exporting BPEL Process Models

BPEL Export Details The following section defines the various partner links exported for each type of step defined in the Model: <partnerLinks> <partnerLink name="Flow_StepInvokeService" partnerLinkType="Flow_StepInvokeServiceLT" partnerRole="Flow_StepInvokeServicePartnerRole"/>

The partner link for Flow_Step (IS step) defines partner role "Flow_StepInvokeServicePartnerRole", which points to the port type defined by the web service for generated wrapper flow service. <partnerLink name="Workflow_StepInvokeService" partnerLinkType="Workflow_StepInvokeServiceLT" partnerRole="Workflow_StepInvokeServicePartnerRole"/>

The partner link for Workflow_Step defines partner role "Workflow_StepInvokeServicePartnerRole", which points to the port type defined by the web service for generated workflow. <partnerLink myRole="CreditRatingService" name="ws_invoke" partnerLinkType="wsdl0:ws_invoke"/>

The ws_invoke partner link points to the partner link type defined at wsdl0. <partnerLink myRole="LoanFlow" name="ws_receive_reply" partnerLinkType="wsdl1:ws_receive_reply" partnerRole="LoanFlowCallback"/>

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:

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

webMethods Modeler User’s Guide Version 6.1

Exporting Process Models in BPEL Format

messageType="wsdl0:CreditRatingService_MessageTypes_processCreditRatin gServiceSoapRequest" name="processCreditRatingServiceSoapRequest"/>

The “Flow_StepInvokeStepInput” message points to the input message defined for wrapper flow service input.

The “Flow_StepInvokeStepInput” message points to the input message defined for wrapper flow service output.

The flow activity below defines the equivalent activities of the above process model and the links/connections between them.

Defines the link between “web_service_stepA” to “Web_Service_Step”

The web service receive step equivalent activity. <source linkName="Web_Service_StepA-to-Web_Service_Step"/>

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

webMethods Modeler User’s Guide Version 6.1

195

CHAPTER 10 Importing and Exporting BPEL Process Models

<source linkName="Web_Service_Step-to-Workflow_Step"/>

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

The web service reply equivalent step with join condition based on getLinkStatus function().

The flow step equivalent invoke activity. <source linkName="Flow_Step-to-Web_Service_Step1"/>

196

webMethods Modeler User’s Guide Version 6.1

Exporting Process Models in BPEL Format

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

Open the desired process model in Modeler.

2

From the File menu, select Export Current Process As, then BPEL Process.The Save export file dialog appears.

3

Click Save. The Exported files dialog appears.

webMethods Modeler User’s Guide Version 6.1

197

CHAPTER 10 Importing and Exporting BPEL Process Models

198

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

11

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

webMethods Modeler User’s Guide Version 6.1

199

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

Overview of Process Generation After you draw your process model, generate it to have Modeler generate the run-time elements that will actually execute at run time. To generate the run-time elements, Modeler uses the information in your process model, such as steps, publish/subscribe filters, transitions, and conditions. Modeler places the generated run-time elements in the underlying webMethods platform. Architecture diagram for process generation

Modeler

Design Server

IS

IS WmModeler package

IS

IS

Workflow

Each step in a process model is associated with a specific logical server. Modeler places the run-time elements associated with a step on the physical server mapped to the logical server for the step. For Workflow steps only, Modeler also places these run-time elements on an Associated Server. To place the run-time elements on a server, Modeler accesses the servers through the Design Server. The Design Server connects to the various servers in the webMethods platform, as needed, during process generation. As a result, all physical servers must be running and available when you generate the process model.

200

webMethods Modeler User’s Guide Version 6.1

What Modeler Generates for a Process Model

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

Items Generated for Steps Associated with Integration Servers The name Modeler gives a generated run-time element and where Modeler places the generated run-time element on the Integration Server depends on how you define the properties for the process and for the steps. The following table lists each run-time element that Modeler generates for steps associated with an Integration Server and describes how process and step properties affect what Modeler generates:

Generated item

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

webMethods Modeler User’s Guide Version 6.1

201

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

Generated item IS folder for the process

IS folders for the logical servers

Type of property

Property

How Modeler uses property during generation

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.

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

202

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.

webMethods Modeler User’s Guide Version 6.1

What Modeler Generates for a Process Model

Generated item

Type of property

Property

How Modeler uses property during generation

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

webMethods Modeler User’s Guide Version 6.1

Logical Server

By default, Modeler places the generated flow service in the IS folder it creates for the logical server associated with the step.

203

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

Generated item

process runtime script

Type of property

Property

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

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.

Sample Process Model and Generated Run-time Elements The following shows a sample process model and describes the process and step properties that Modeler uses during process generation. Sample process model that describes properties for process generation

204

webMethods Modeler User’s Guide Version 6.1

What Modeler Generates for a Process Model

When the above process is generated, Modeler generates the following run-time elements: Generated run-time elements for the process model Package Name property is used for the name of the package. Generated flow for Step3 is placed in the folder “FolderProperty_Folder” that was specified on the Folder property.

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

Items Generated for Web Service Steps For Web Service steps, Modeler generates services depending on the Web Service activity: Receive/Reply, or Invoke.

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

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

webMethods Modeler User’s Guide Version 6.1

205

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

Items Generated for Workflow Steps For each Workflow step, Modeler generates an implementation module that contains a workflow. Modeler places the implementation module into a Workflow project. Workflow items generated for a Workflow step

Workflow Project Implementation Module workflow

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

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

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

206

webMethods Modeler User’s Guide Version 6.1

What Modeler Generates for a Process Model

Generated item

Type of property

Property

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

Label Unique ID

Modeler generates an implementation module and places it in the project. By default, Modeler names the implementation module ProjectName_Label_UniqueID, where:

Implementation Module

How Modeler uses the property during generation

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

webMethods Modeler User’s Guide Version 6.1

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.

207

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

Generated item

Type of property

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

Label Unique ID

If Modeler generates an empty workflow, Modeler names the generated workflow ProjectName_Label_UniqueID, where:

Property

How Modeler uses the property during generation

ProjectName is the name of the project Label is the value of the Label step property UniqueID is the value of the UniqueID step property step

Logical Server

Modeler places the workflow that it generates on the physical webMethods Workflow server that is mapped to this logical server.

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

208

webMethods Modeler User’s Guide Version 6.1

Validating a Process Model Before Generation

Validating a Process Model Before Generation In some cases, particularly for larger and more complex process models, you may want to validate the process model before generating it. To validate a process model 1

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

2

Select ToolsValidate Business Process. If Modeler encounters errors when validating the process model, it displays error messages. The error messages are preceded with Validation Messages dialog.

in the Implementation

For a description of the errors and how to fix them, see “Troubleshooting Process Generation” on page 216

Before You Can Execute a Process Model You must take the following actions before you can execute a process that uses your process model: STEP 1:

Generate the process model.

STEP 2:

Optionally, add logic to the generated run-time elements.

STEP 3:

Make the process model available for monitoring.

STEP 4:

Enable the process model.

STEP 1: Generating a Process Model You generate the process model using Modeler. When you generate the process model, Modeler displays messages in the Implementation Generation Messages dialog as it creates the run-time elements. To generate a process model 1

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

2

Select ToolsGenerate Business Process. If Modeler encounters errors when generating the process model, it displays error messages. The error messages are preceded with

webMethods Modeler User’s Guide Version 6.1

in the Implementation

209

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

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

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

Before You Can Execute a Regenerated Process Model After updating your process model, take the following actions to update the generated run-time elements and make the process model available for the PRT to use to execute processes:

210

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.

webMethods Modeler User’s Guide Version 6.1

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

webMethods Modeler User’s Guide Version 6.1

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

211

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

Change made to process model Change the ‘Package Name’ process property

How Modeler handles the change during regeneration 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

212

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.

webMethods Modeler User’s Guide Version 6.1

STEP 1: Generating a Process Model

Change made to process model Change the ‘Service to Invoke’ step property for a step

How Modeler handles the change during regeneration 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.

webMethods Modeler User’s Guide Version 6.1

213

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

Change made to process model Delete a step from the process model

How Modeler handles the change during regeneration 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.

214

webMethods Modeler User’s Guide Version 6.1

STEP 1: Generating a Process Model

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 made to process model 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.

How Modeler handles the change during regeneration 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.

Change the ‘Implementation Module’ step property for a step

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

webMethods Modeler User’s Guide Version 6.1

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

215

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

Change made to process model Clear the ‘Workflow to Invoke’ step property for a step

How Modeler handles the change during regeneration 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.

Troubleshooting Process Generation The following lists the errors that you might encounter when generating a process model, their causes, and the actions to take to resolve the errors. Important! If Workflow steps inadvertently generate to multiple IS servers, make sure that all users that have generated the model have the same Associated Server assignment. For details on this issue, see “Consequences to Changing the Associated Server” on page 208.

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

216

webMethods Modeler User’s Guide Version 6.1

STEP 1: Generating a Process Model

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.

webMethods Modeler User’s Guide Version 6.1

217

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

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.

218

webMethods Modeler User’s Guide Version 6.1

STEP 1: Generating a Process Model

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.

webMethods Modeler User’s Guide Version 6.1

219

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

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.

220

webMethods Modeler User’s Guide Version 6.1

STEP 1: Generating a Process Model

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

webMethods Modeler User’s Guide Version 6.1

221

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

STEP 2: Optionally Adding Logic to Generated Run-time Elements After generating the process model, you might want to add logic to the flow services generated to Integration Servers or implementation modules and workflows generated to webMethods Workflow servers. Important! Never make changes to the generated triggers.

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

Adding Logic to Implementation Modules and Workflows After you generate the process model, complete the logic for generated implementation modules and workflows. For details, see Chapter 7, “Working with Workflow Step Logic”.

STEP 3: Making the Process Model Available for Monitoring To be able to monitor your processes using the webMethods Monitor, you need to move the process model to the Process Audit Log. To do so, perform the following procedure. To update a process model for monitoring 1

Start Modeler and connect it to the Design Server.

2

If the process model you want to be able to monitor is not already open, open it.

3

Select ToolsUpdate Model for Monitoring. Note: The Update Model for Monitoring option is disabled if you have not defined an Process Audit Log. To define an Process Audit Log, from the webMethods Server Administrator, select the JDBC Pools option from the Settings menu of the navigation area to associate the alias of a JDBC pool with the ProcessAudit functional alias.

222

webMethods Modeler User’s Guide Version 6.1

STEP 4: Enabling Process Models

STEP 4: Enabling Process Models After generating the process model and updating it for monitoring, the process model is disabled until you enable it. The PRT will not use the process model for the execution of a process until you enable the process model. You enable the process model using webMethods Monitor. To enable a process model 1

Open webMethods Monitor that is running on the Design Server.

2

Click the Process Models option from the Process menu of the navigation area.

3

Locate the process model you want to enable from the list of process models. The process model will be in the Unused Process Models section of the screen because no instances of this process model have been executed.

4

In the row for the process model that you want to enable, click No in the Enabled column. When prompted to confirm your action, click OK.

webMethods Modeler User’s Guide Version 6.1

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

224

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

12

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

webMethods Modeler User’s Guide Version 6.1

225

CHAPTER 12 Managing Process Models

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

Updating Process Models You can make visual updates to a process model without needing to regenerate it. Examples of visual changes to a process model include moving transition lines or steps around the canvas (without changing the order in which steps occur), or adding notes or groups to the process model. Since these types of changes are not registered by the PRT, you do not need to regenerate the model after making them. Examples of changes that require you to regenerate the process model for the changes to take effect include: Changing the order in which steps execute Changing the properties of steps or the process model Changing transition types or transition conditions Changing the services or workflows that a step invokes Changing step inputs or outputs Changing the logical servers associated with steps For details on regenerating a process model, see “Regenerating a Process Model” on page 210. Note: If you make changes to the user-defined service that the generated flow service invokes, you do not need to regenerate the process model. For details on editing services, see Chapter 7, “Adding Logic to Steps”.

226

webMethods Modeler User’s Guide Version 6.1

Versioning the Process Model

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

From an active process model, choose FileSave as New Version.

2

Enter a new name for the process model and choose OK.

3

Modify the new process model as necessary.

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

webMethods Modeler User’s Guide Version 6.1

227

CHAPTER 12 Managing Process Models

Deleting Process Models Modeler’s delete function deletes the process model definition from Modeler. It does not, however, delete generated components (if they exist) from their respective servers. If you want to delete generated items, you must do so manually. To Delete an Existing Process Model

228

1

From an active process model, choose FileDelete Process. The Delete Process window appears.

2

Browse to the process model that you want to delete and select it. Click Delete.

3

When prompted to confirm your action, click OK.

webMethods Modeler User’s Guide Version 6.1

Exporting and Importing Process Models

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

Exporting Process Models You can export an active process model, or you can export multiple processes simultaneously. See the following procedures. To Export an Active Process Model 1

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

2

Select FileExport Current Process asComplete Model. Note: If you want to export the model as Portable Format, choose FileExport Current Process asPortable Format.

webMethods Modeler User’s Guide Version 6.1

229

CHAPTER 12 Managing Process Models

3

In the Save Export File dialog, browse to the directory where you want to save the exported process model.

4

In the File Name dialog, type a file name for the exported process model. Click Save.

5

Modeler displays a confirmation message. Click OK.

To Export Other (or Multiple) Process Models 1

From the Modeler main menu, select FileExport Other Processes asComplete Model

.

Note: If you want to export the model as Portable Format, choose FileExport Other Processes asPortable Format. 2

In the Select Processes For Export dialog, browse to and select the process model(s) that you want to export.

3

Click Export.

4

In the Select Directory dialog box, browse to and select the directory where you want to save the exported process model(s).

5

Click Select Directory. Modeler displays a confirmation message. Click OK.

Importing Process Models To Import a Process Model

230

1

From the Modeler main menu, choose FileImport.

2

In the Select Import File dialog, browse to the process model that you want to import and click Open.

3

If prompted to confirm the import, choose Yes.

4

After import, Modeler displays a confirmation message. Choose OK.

webMethods Modeler User’s Guide Version 6.1

Managing Logical Servers and Server Connections

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

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

Open the process model.

2

From Modeler’s main menu, select ToolsReplace Logical Server in Process.

3

From the Find Logical Server menu, select the logical server to be replaced.

4

From the Replace With menu, select the new logical server.

5

Click Replace All. A message appears stating how many server instances were replaced.

6

If you are done replacing logical servers in the process, click Close.

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

webMethods Modeler User’s Guide Version 6.1

231

CHAPTER 12 Managing Process Models

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

232

From Modeler’s main menu, select ViewServer Connections.

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

CHAPTER

13

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

webMethods Modeler User’s Guide Version 6.1

233

CHAPTER 13 Moving Process Models to Production

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

Servers and Moving Processes to Production For you to be able to successfully move your business process, you must have a one-toone correspondence between the logical servers in your development environment and the logical servers in your production environment. For example, if you have the logical servers Accounting, Finance, and Purchasing in your development environment, you must also have the logical servers Accounting, Finance, and Purchasing in your production environment. Example of logical and physical servers in development vs. production environments

Development

Production

Accounting Finance Purchasing

Accounting

IS

IS

All logical servers map to a single physical server.

Finance

IS

Purchasing

IS

Each logical server maps to a different physical server.

The underlying physical servers do not have to match. For example, in the development environment, all three logical servers (Accounting, Finance, and Purchasing) might map to a

234

webMethods Modeler User’s Guide Version 6.1

Identifying the Items You Need to Move

single physical server. In your production environment, you might have the same three logical servers mapped to three separate physical servers.

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

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

webMethods Modeler User’s Guide Version 6.1

235

CHAPTER 13 Moving Process Models to Production

Information the Deployment List Contains In the deployment list, items are grouped by logical servers. The following table identifies the information that Modeler lists for each logical server. Type of server associated with steps

Information in deployment list

all

Host name and port of the physical server to which the logical server is mapped

Integration Servers

Package name for the process Trigger that Modeler generated for the logical server Process run-time script for the logical server Generated flow services Correlation services Documents that your process model references Services that steps in your process invoke Note: The deployment list contains only the specific service identified by the Service to Invoke step property. The service you identify using this property might invoke other services, require IS specifications, IS document types, etc. It is your responsibility to determine the items that your services require and include them in the releases of the packages you move to the production server.

Workflow Servers

Project name for the process Implementation modules generated for a step Workflows that were generated or referenced by steps Documents that your process references

236

webMethods Modeler User’s Guide Version 6.1

Identifying the Items You Need to Move

The following shows a sample deployment list. Sample deployment list

Name of the process model Name of a logical server

Items on the logical server “Accounting”

The name of the step with which a service is associated is listed in parentheses

webMethods Modeler User’s Guide Version 6.1

237

CHAPTER 13 Moving Process Models to Production

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

To generate the deployment list To

1

From Modeler, select ViewDeployment Information.

2

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

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

238

webMethods Modeler User’s Guide Version 6.1

Moving Items that Reside on Integration Servers

Moving Integration Server items from development servers to production servers

Development Accounting Finance Purchasing

= Logical server s=

IS Accounting Items Finance Items Purchasing Items Physical servers =

devel.company.com:5555

Production Accounting

IS

Finance

IS

Purchasing

IS

Accounting Items Finance Items

acctg.company.com:5555

Purchasing Items

fin.company.com:5555 purch.company.com:5555

The items on Integration Servers that you need to move are run-time elements that Modeler generated (PRT scripts, flow services, and triggers) and other items (e.g., services, publishable documents, etc.) that you referenced in your process model.

Moving Modeler Generated Run-time Elements From the development Integration Servers, create releases of the packages containing the generated run-time elements. Then publish the releases from the development Integration Servers to the production Integration Servers.

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

webMethods Modeler User’s Guide Version 6.1

239

CHAPTER 13 Moving Process Models to Production

The following table lists each generated run-time element and where you can locate the item within the package based on whether the Folder property was used. Default or Folder property

Where Modeler places the run-time element

process run-time scripts

Either

In the config\wmprt directory of the package.

triggers

Either

Run-time element

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. For more information about the items that Modeler generates and where Modeler places these items, see Chapter 11, “Generating Process Models”.

240

webMethods Modeler User’s Guide Version 6.1

Moving Items that Reside on Integration Servers

Creating Releases Based on Your Logical-to-Physical Server Mappings How you create the releases of the packages that you need to publish depends how closely the logical-to-physical server mappings in your development environment mirror the mappings in the production environment. Mappings in the Development Environment Mirror the Production Environment Exactly When the logical-to-server mappings in both environments mirror each other, you have the same number of physical servers in both the development and production environments and the logical-to-physical mappings are equivalent. Example of development environment that exactly mirrors the production environment

Development

Accounting

IS

Finance

IS

Production Purchasing

IS

Accounting Items

Accounting

IS

Finance

Purchasing

IS

IS

Accounting Items Finance Items

Purchasing Items

Finance Items

Purchasing Items

In this situation, the move of the generated run-time elements is straight forward. To move generated run-time elements when logical-to-physical mappings are the same For each physical server in your development environment: 1

Create a release of the entire package for the process model.

2

After you have created the releases, publish and install the releases in the equivalent physical server in the production environment.

webMethods Modeler User’s Guide Version 6.1

241

CHAPTER 13 Moving Process Models to Production

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

Development Accounting Finance Purchasing

IS Accounting Items Finance Items Purchasing Items

Production Accounting

IS

Finance

Purchasing

IS

IS

Accounting Items Finance Items

Purchasing Items

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

Development Accounting Finance

IS

Production Purchasing

IS

Accounting Items Finance Items

Finance

IS

Accounting Purchasing

IS Accounting Items

Purchasing Items

Finance Items

Purchasing Items

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.

242

webMethods Modeler User’s Guide Version 6.1

Moving Items that Reside on Integration Servers

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

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

In addition to all items in ns/ProcessModel/LogicalServer, include ns/ProcessModel and ns/ProcessModel/node.idf

webMethods Modeler User’s Guide Version 6.1

243

CHAPTER 13 Moving Process Models to Production

If you used the Folder property to specify where to place generated flow services for one or more steps, locate the generated flow services in the folders you specified and include them in the release, as well. Be sure to include only the generated flow services that are associated with the logical server for which you are making a release of the package. 2

After you have created the releases, publish and install the releases in the equivalent physical server in the production environment.

Moving Referenced Items You also need to move the Integration Server items that you referenced in the steps and conditions of your process model. These items include: Services invoked by steps in the process model Correlation services that your process model uses IS document types or specifications used by services Publishable documents that are input to or output from steps IS documents or document types used in conditions on transitions To help you identify some of the referenced items, you can generate the deployment list. For more information, see “Generating the Deployment List” on page 238. To move the referenced items, create releases of the packages that contain all the services, IS document types, etc. that your process model references and publish them to the appropriate physical servers in your production environment.

244

webMethods Modeler User’s Guide Version 6.1

Moving Items that are Stored in Trading Networks

Moving Items that are Stored in Trading Networks If your process model references items in Trading Networks, you will need to move those items from your development environment to the production environment. To move items that reside in Trading Networks, use the Trading Networks export and import feature. The types of items your process model might reference from Trading Networks include: Profiles that you reference in conditions on transitions TN document types that are input to or output from a step Attributes associated with the TN document types To move items stored in Trading Networks To

1

From the development environment, use the Trading Networks Console to access the Export Data dialog (from the File menu), which allows you to select the items you want to export. Trading Networks creates an .xml file that contains the exported items.

2

Move the .xml file to a location to which the production Trading Networks has access.

3

Use the Trading Networks Console in the production environment to access the Import Data dialog (from the File menu).

4

From the Import Data dialog, select the .xml file you created in the development environment. This allows you to import the data from the development environment to your production environment.

For more information about how to export data from and import data to Trading Networks, see the webMethods Trading Networks User’s Guide manual.

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

webMethods Modeler User’s Guide Version 6.1

245

CHAPTER 13 Moving Process Models to Production

To move your tested Workflow deployment to your production environment 1

Access the Workflow Generator from the Tools menu of the Workflow Designer that is connected to the webMethods Workflow server in your development environment.

2

Using the Workflow Generator, identify the webMethods Workflow server to which you want to move the workflows. This server is known as the deployment server. Specify the webMethods Workflow server in your production environment for the deployment server.

3

Select the Install Deployment option from the Install menu to copy the previously generated and tested deployment to your production environment. The Workflow Generator will guide you through moving the Workflow items from your development environment to your production environment.

For more information about deploying workflows, see the webMethods Workflow User’s Guide.

Moving Process Models to Production Process Audit Log To be able to monitor business processes in your production environment, the process models must reside in the Process Audit Log in the production environment. For this purpose, only the process audit log database needs to be moved. It is not necessary to import the process model itself to the production environment. The following tables must be exported: WMCUSTOMFIELDDEFINITION WMPROCESSDEFINITION WMPROCESSIMAGE WMSTEPDEFINITION WMSTEPTRANISITONDEFINITION

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

246

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

APPENDIX

A

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

webMethods Modeler User’s Guide Version 6.1

247

A P P E N D I X A Tu n i n g P e r f o r m a n c e a n d Q u a l i t y o f S e r v i c e

Overview Service Pack 1 for webMethods Modeler 6.0.1, coupled with Service Pack 2 for Integration Server 6.0.1, adds settings to the Modeler and PRT that let you tune performance and quality of service levels to meet specific needs. This appendix provides a framework for tuning these dispersed settings as a cross-functional unit, and for leveraging them for your environment.

Backwards Compatibility The performance and quality of service default settings are such that, out-of-the-box, all process models created prior to the implementation of the new features (that is, prior to the application of Modeler 6.0.1. SP1 and Integration Server 6.0.1 SP2), work exactly as they did before. Specifically, all process models default to the highest quality of service— the behavior prior to the existence of these settings.

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

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

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

248

webMethods Modeler User’s Guide Version 6.1

Configuring the System to Meet Your Needs

View errors and activity messages Edit and resubmit the step pipeline

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

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

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

Costs Process instances are not guaranteed. They: Do not automatically recover in case of server failure; i.e, if a server fails, the process does not run to completion. There is no visibility or control via webMethods Monitor. You cannot: View process status (Started, Suspended, Failed, Completed) View step status (Completed, Started, Failed/Error, Waiting) Suspend, resume, resubmit, or stop a process View error or activity messages Edit or resubmit the step pipeline

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

webMethods Modeler User’s Guide Version 6.1

249

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

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

Description

Perform this on...

See page...

1

Configure the territory.

PRT home page

250

2

Configure process-level settings.

Modeler:

256

Process Model Options Process Model Properties 3

Optionally change step pipeline logging.

Modeler Step Properties

269

STEP 1: Configure the Territory Some choices that you need to make when configuring the territory include: Whether to use a central or distributed Process Tracking Store Which database to use for the Process Tracking Store If using a distributed Process Tracking Store, which server should be the Process Completion Tracking Server

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

250

webMethods Modeler User’s Guide Version 6.1

STEP 1: Configure the Territory

To Tune The Territory 1

Start an integration server.

2

Open the PRT home page (http://localhost:5555/WmPRT).

3

Tune the settings using the following table for reference. Setting

Description

Default

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

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

Note: If you have a single IS environment, choose a central Process Tracking Store.

webMethods Modeler User’s Guide Version 6.1

251

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

Setting

Description

Default

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.

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

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.

252

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.

600 seconds

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

webMethods Modeler User’s Guide Version 6.1

STEP 1: Configure the Territory

Setting

Description

Default

Associated Pool Alias

The JDBC pool alias for the Process Tracking Store database.

Identical to the Process Audit Log Pool Alias

Changing the default: To specify that Process Tracking Store information be stored in a database other than the Process Audit Log database: 1

Run (in your database editor) one of the scripts provided to create the tables. Run the script that corresponds to your database. The scripts are located in the /config directory under the WmPRT package: tables-oracle.sql or tables-sqlserver.sql tables-db2.sql

2

In the Server Administrator, create a JDBC pool that points to the database schema containing these tables. Note: Instructions for setting up JDBC pools are provided in the webMethods Integration Server Administrator’s Guide, “Configuring the Server” chapter, “Configuring the JDBC Connection Manager” section.

3

On the PRT home page, select the new JDBC pool alias from the drop down list.

Join Queue Lock Expiration (sec)

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

Process Lock Expiration (sec)

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

10 seconds

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

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.

webMethods Modeler User’s Guide Version 6.1

253

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

Setting

Description

Default

Step Lock Expiration (sec)

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

10 seconds

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

After modifying any default values, click Submit to save changes. Note: Clicking the Default button causes the PRT to revert to the default values.

5

Repeat steps 1-4 for all PRTs in a territory, ensuring values are tuned consistently. For example, if using a central Process Tracking Store, ensure all servers have designated a central Process Tracking Store and that each points to the same Associated Pool Alias. Similarly, if using distributed Process Tracking Store, ensure all servers have designated a distributed Process Tracking Store and that each server points to a different Associated Pool Alias. If using a distributed Process Tracking Store, be sure to assign only one Process Completion Tracking Server per territory.

6

Reload the WmPRT package, or restart the integration server.

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

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

254

webMethods Modeler User’s Guide Version 6.1

STEP 1: Configure the Territory

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

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

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

webMethods Modeler User’s Guide Version 6.1

255

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

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

STEP 2: Configure Process-Level Settings The performance/quality of service settings at the process-level are geared to let you finetune exactly: How much process visibility and control you need in the Monitor. You choose exactly how much information to persist to the Process Audit Log. Whether certain phases of process execution can run in volatile mode (for faster performance), or whether they need to be guaranteed (for greater reliability). The general steps in process performance/quality of service tuning are: Step

Description

1

Choose global default process settings.

2

Tune individual process model settings.

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

256

webMethods Modeler User’s Guide Version 6.1

STEP 2: Configure Process-Level Settings

To Change the Default Step Pipeline Logging Value 1

Start the Modeler.

2

Choose ToolsOptions.

3

Check or uncheck the Steps Enable Resubmission option to enable or disable it. Important! Changing this parameter affects steps added to the process going forward. It does not affect steps already in existence. Tip! The step property that the Steps Enable Resubmission option corresponds to is Enable Resubmission.

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

webMethods Modeler User’s Guide Version 6.1

257

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

Process Model Property Logging Level

Description

Default

For details, see...

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

Process and All Steps

“Choosing a Logging Level” on page 260

Logging Levels are: None Errors Only Process Only Process and Start Steps Process and All Steps 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.

Enabled

“Using Volatile Transition Documents” on page 264

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.

258

webMethods Modeler User’s Guide Version 6.1

STEP 2: Configure Process-Level Settings

Process Model Property Optimize Locally

Description

Default

For details, see...

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.

Enabled

“Optimizing the Process Locally” on page 264

Enabled

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

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

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.

webMethods Modeler User’s Guide Version 6.1

259

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

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

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

260

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.

webMethods Modeler User’s Guide Version 6.1

STEP 2: Configure Process-Level Settings

Logging Level

Description

Effect

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. Outof-the-box, all step pipelines are logged (i.e. the Enable Resubmission property is enabled). To change the global default Enable Resubmission value, see “Step 1: Choose Global Default Process Settings” on page 256. To override a specific step’s log pipeline value, see “STEP 3: Optionally Modify Step Pipeline Logging” on page 269.

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

webMethods Modeler User’s Guide Version 6.1

261

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

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

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

262

webMethods Modeler User’s Guide Version 6.1

STEP 2: Configure Process-Level Settings

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

webMethods Modeler User’s Guide Version 6.1

263

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

Using Volatile Transition Documents For a review of the Volatile Transition Documents property, see “Using Volatile Transition Documents” on page 264. The state of the Volatile Transition Documents property impacts: Whether the process can automatically recover in case of server or Broker failure Effect on Automatic Recovery If you enable the Volatile Transition Documents property, the Broker stores all process transition documents in Broker RAM. This means that if the server on which a step is running fails, or the Broker fails, the process cannot automatically recover. The only means you have of recovering the process instance is to manually resubmit steps through the Monitor. The ability to resubmit steps depends on whether the step pipeline was logged to the Process Audit Log. (See “Choosing a Logging Level” on page 260.) Summary of Using Volatile Transition Documents Storing process transition documents in Broker RAM enhances process performance. However, the ability to automatically recover the process is lost. The only way to recover a process instance upon server or Broker failure is to use the Monitor resubmit feature, which depends on step pipeline logging. If neither the server nor the Broker fail, it is safe to enable Volatile Transition Documents.

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

264

webMethods Modeler User’s Guide Version 6.1

STEP 2: Configure Process-Level Settings

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.

webMethods Modeler User’s Guide Version 6.1

265

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

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.

266

webMethods Modeler User’s Guide Version 6.1

STEP 2: Configure Process-Level Settings

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

Managing Correlation IDs in a Distributed Environment For a review of the Local Correlation property, see “Local Correlation” on page 259. The state of the Local Correlation property determines: Whether different servers in the process are guaranteed to receive correlation IDs The state of the Local Correlation property is only relevant when all of the following are true: Process uses at least one correlation service Process is distributed over different servers Territory uses distributed Process Tracking Store (see “Choosing Central vs. Distributed Process Tracking Store” on page 254) Note: The remainder of this section applies to processes that meet the above criteria. For a review of when processes require correlation services, see “Working with Correlation Services” on page 152. Local Correlation Property’s Effect on Correlation ID Receipt Distributed process tracking causes correlation IDs to be stored in different databases. When a step outputs a correlation ID (via a correlation service), the PRT stores the ID to the Process Tracking Store database specific to the server. If the step that needs the ID is located on a different server than that which output the ID, you need to broadcast correlation IDs. That is, you need to disable Local Correlation.

webMethods Modeler User’s Guide Version 6.1

267

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

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

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

268

webMethods Modeler User’s Guide Version 6.1

STEP 3: Optionally Modify Step Pipeline Logging

Designing the Model so That Broadcasting Is Not Necessary: Broadcasting correlation IDs to the Broker (i.e, disabling Local Correlation), slightly detracts from performance. To avoid this, you can instead design the process so that the steps publishing and the steps needing correlation IDs are on the same server. In this case you could enable Local Correlation and still be ensured documents correlate to the process successfully. Note: Using the previous model as an example, you would assign the “ProcessJob” and “routerScheduleRequest” steps the same physical server. Summary of Local Correlation It is important to consider how you will correlate documents into a process. You can do so either by disabling Local Correlation or by process model design.

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

Start the Modeler and open a business process.

2

Select the step whose pipeline logging you would like to change.

3

In the Step Properties panel, check or uncheck Enable Resubmission to enable or disable step pipeline logging.

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

webMethods Modeler User’s Guide Version 6.1

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

270

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

APPENDIX

B

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

webMethods Modeler User’s Guide Version 6.1

271

APPENDIX B Guidelines for Working with Referenced Processes

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

Referenced Process Overview The business process containing a referenced process is distinguished from other business processes in that, at run time, more than one business process is intended to run. The parent process is triggered when the Broker receives the start step’s subscription document. The child process (or referenced process), which exists and runs independently of the parent process, is triggered by its own subscription document.

Design Time In designing business processes with referenced process steps, you should: Understand (and complete as necessary) the additional properties that Modeler provides for referenced process steps; these are defined in “Referenced Process Step Properties” on page 273. These properties reflect the special design-time and run-time considerations for processes containing referenced processes. Understand the special design-time guidelines described in “Design-Time Guidelines” on page 275, including: How to assign inputs and outputs to referenced process steps; this process is slightly more involved than the process described for general steps, in Chapter 6, “Assigning Inputs and Outputs to Steps”. When to assign a return join type to a referenced process step.

Run Time When you monitor a business process that contains a referenced process, you can: Monitor both the parent process and the child process, if both have started running. Use the Monitor enable/disable toggle to swap one running referenced business process for another, if the referenced process step’s Hot-Swappable property is enabled. You enable or disable the Hot-Swappable property at design time. For details on understanding and using the hot-swappable feature, see “Using the Hot-Swappable Feature” on page 277.

272

webMethods Modeler User’s Guide Version 6.1

Referenced Process Step Properties

Referenced Process Step Properties In addition to the step properties available to all steps (described in Chapter 5, “Adding Steps to a Process Model”), Modeler provides additional properties for referenced process steps. 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 hotswapping, see “Using the Hot-Swappable Feature” on page 277.

webMethods Modeler User’s Guide Version 6.1

273

APPENDIX B Guidelines for Working with Referenced Processes

Property

Definition

Return Join Type

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

Return Timeout

Assigns a timeout value to referenced process steps whose return join type is AND (or COMPLEX with ANDs); you do not need to specify this property for any other return join type. The Return Timeout Value is the time (in ms) by which the return join type conditions must be met before the timeout transition from the referenced process step will be taken. The timer begins counting once the first return join condition is met (e.g., the first input arrives). Note: When you assign a Return Timeout value to a step, you must also create a Timeout transition to another step, as described in Chapter 8, “Creating Step Transitions”.

274

webMethods Modeler User’s Guide Version 6.1

Design-Time Guidelines

Design-Time Guidelines Use the following guidelines when designing business processes containing referenced process steps.

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

webMethods Modeler User’s Guide Version 6.1

275

APPENDIX B Guidelines for Working with Referenced Processes

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.

276

webMethods Modeler User’s Guide Version 6.1

Using the Hot-Swappable Feature

Ensure child and parent process inputs stay synchronized. If a child process’s starting subscriptions change after being established within a parent process, the parent process’s referenced process step inputs must be manually updated to reflect the child.

Related Considerations Use caution when replacing one referenced process step with another. If the outputs of the new child process are different than the previous process’s, all transition conditions connecting the referenced process step to steps downstream will be lost. In addition, once you replace one referenced process step with another, the action cannot be undone. Tip! For an alternate method of substituting one referenced process for another (in a run-time environment only), you can use the hot-swappable feature, described in “Using the Hot-Swappable Feature” on page 277.

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

Using the Hot-Swappable Feature At design time, you designate whether a particular referenced process step is hotswappable. 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

webMethods Modeler User’s Guide Version 6.1

277

APPENDIX B Guidelines for Working with Referenced Processes

If a Referenced Process Step is Hot-Swappable When the child process’s subscription document is received, all business processes that begin with that subscription document are triggered. Note that this is the default behavior of Modeler and the PRT; it is only when a process contains referenced process steps that you can limit the processes to be triggered to a single child process. At run time, you can use the Monitor to swap one running child process for another, as long as both processes are triggered by the same subscription document type. To hot-swap, in Monitor: a

Disable the current child process (and all child processes triggered by the same subscription document)

b

Enable the new child process

Important! When hot-swapping, be careful that you disable all running processes with the starting subscription document in question. Also, make sure that you enable only the process to run in place of the child process. If you inadvertently leave more than one process (with a given starting subscription document) enabled, all enabled processes will run. Note: Hot-swapping does not in any way alter the design of a parent or child process model. Therefore, the process model picture does not reflect the hot-swapping, even though it has occurred. For details on using webMethods Monitor to enable and disable business processes, see the webMethods Integration Platform Logging and Monitoring Guide.

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

278

webMethods Modeler User’s Guide Version 6.1

WEBMETHODS MODELER

APPENDIX

C

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

webMethods Modeler User’s Guide Version 6.1

279

APPENDIX C Migrating 4.6 Process Models to Modeler 6.1

Introduction This appendix is for clients who maintain process models from Business Integrator version 4.6 and who would like to import 4.6 models into Modeler 6.1. This appendix outlines the basic concepts and steps in 4.6-to-6.1 process model migration.

Overview When you migrate a 4.6 process model to Modeler 6.1, the design of the model is perfectly preserved. That is, all steps, transitions, groups, subprocesses, referenced processes, notes, and annotations remain intact in Modeler 6.1. In addition, the migration utility makes some adjustments to the model’s settings to reflect the difference in functionality between Business Integrator 4.6 and Modeler 6.1. However, additional manual adjustments to the model are necessary before it is fully functional on the 6.1. platform and with your specific setup. Before you begin the export/import process, you should understand the differences in functionality between Business Integrator 4.6 and Modeler 6.1. The following table summarizes these major differences and how the migration utility handles them. BI 4.6 and Modeler 6.1 Differences and How Migration Handles Them

280

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.

webMethods Modeler User’s Guide Version 6.1

Overview

BI 4.6

Modeler 6.1

Migration Notes

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.

webMethods Modeler User’s Guide Version 6.1

281

APPENDIX C Migrating 4.6 Process Models to Modeler 6.1

BI 4.6

Modeler 6.1

Migration Notes

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.

Basic Steps in Process Model Migration The basic steps in 4.6-to-6.1 process model migration are as follows:

282

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.

webMethods Modeler User’s Guide Version 6.1

Ensuring the Model is 6.1-Ready

Ensuring the Model is 6.1-Ready Before attempting to run a migrated process model on the 6.1 platform, use the following as guidelines for a 6.1 integrity check.

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

Ensure All Documents in the Model Exist on the 6.1 Platform The migration utility preserves all 4.6 document names in the 6.1 model. Make sure these documents exist on the appropriate 6.1 logical servers before running the business process.

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

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

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

webMethods Modeler User’s Guide Version 6.1

283

APPENDIX C Migrating 4.6 Process Models to Modeler 6.1

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

Becomes this 6.1 Transition Type

RetryCount

Retries Exceeded

UnexpectedDoc

None. This Status condition is not preserved during the migration. You must manually re-create this condition after migration.

Timeout

Timeout

Exception

Error

Note: For a detailed review of 6.1 transitions, see Chapter 8, “Creating Step Transitions” of this guide.

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

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

284

webMethods Modeler User’s Guide Version 6.1

Index

Index Numerics 4.6 process model migration 280

A activity messages PRT service that creates and logs 150 AND joins and return join types 274 definition 89 forming 25 run-time guidelines 171 use with transition conditions 171 annotations to process model notes 27 text 27 architecture design time for process 20 process generation 200 run-time for processes 28 webMethods platform and webMethods Modeler 17 Associated Pool Alias, PRT setting 253 Associated Server and process generation 206 changing assignment 232 consequences to changing 208 definition 206, 232 authentication, Modeler repository 21

B BIML schema document 229 BPEL4WS 32 branches definition 25, 163 forming 163 Broker and webMethods Modeler architecture 18 description 18 publishing IS documents to 125

webMethods Modeler User’s Guide Version 6.1

subscribing to IS documents from 115 use during process run time 29 Business Process Execution Language (BPEL) 32 business process management and webMethods Modeler 17 definition 17

C canvas definition 41 working with grid settings 41 Central Process Tracking Store defined 251, 254 PRT setting 251 changeProcessStatus service description and usage 150 changing a process’s run-time status 150 a step’s user-defined service 149 consequences to changing Associated Server 208 logical servers in process 231 Modeler repository storage mechanism 47 one referenced process step for another, caution 277 step icons 105 updating process models 226 child process, definition 272 collapsing several steps into single icon 25 Complete Model import/export format, defined 229 Complex join and return join types 274 definition 89 controlled steps and internal groups 26, 178 definition 23 items generated for 28 controlling a process’s run-time status 150 appearance of groups 180 display of transition types 175

285

Index

inputs/outputs display 137 logical server connection state 232 transition colors 175 visual properties of steps 105 conventions used in this document 13 correlation IDs and the Local Correlation property 59, 259, 267, 268 managing across distributed servers 59, 259, 267, 268 mapping to process instance ID (PID) 154 tips for creating 153 correlation services and correlation ID 152 checklist for working with 152 correlation ID-to-PID mapping 154 definition 152 editing 157 importance of unique ID among all processes 153, 155 importance of using in only one process model 153, 155 inputs and outputs 155 procedure for assigning to steps 157 procedure for creating 155 when steps don’t need 152 when steps need 152 creating correlation ID-to-PID mapping 154 correlation services 152, 155 distinct pipeline variables for split logic threads 172 end steps 86 fields to log for monitoring 138 groups 178, 179 inputs to steps 109 joins 88 logic that affects step run-time status 150 logic to send external documents from steps 136 new process model version 227 outputs from steps 124 process models 51 process-wide error steps 87 publications from steps 125 publish/subscribe filters 140, 144, 145 referenced process steps 89, 272 regular step logic 149 splits, branches, and joins 163

286

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

D Database Cleanup Interval (sec), PRT setting 252 Database Connection Retries, PRT setting 252 Database Connection Retry Interval, PRT setting 252 databases Process Audit Log and Process Tracking Store (PRT) database 253 changing from flat file to database storage 47 description 19 moving process model to for monitoring 246 use during process run time 29 warning about Oracle database drivers 47 PRT (Process Tracking Store) configuring 253 using central vs. distributed 254 definitions Associated Server 232 branches 25, 163 business process management 17 Central Process Tracking Store 251, 254 child and parent process 272 controlled and uncontrolled steps 23 correlation ID 152 correlation services 148, 152 Design Server 18 Express Pipeline 55 external documents 24 filters 24, 139 Focal Role 54 generated flow services 148 groups, internal and external 26, 66, 178 hot-swappable 273, 277 input/output data 24, 108 IS documents 24 joins 25, 163 logical servers 20

webMethods Modeler User’s Guide Version 6.1

Index

Modeler repository 18 modeling 16 performance 248 Process Completion Tracking Server 252 process control documents 29 process models 22 Process Reference property 273 process run time (PRT) 29 process run-time scripts 27 Process Tracking Store 251, 254 process transition documents 29, 254 publications and subscriptions 24, 108 quality-of-service 248 referenced process 25, 272 referenced process steps 272 return join type 274 return timeout 274 sender/receiver roles 112 splits 25, 163 steps 23 subprocess 25 territory 18 timeout value for steps 70, 75, 76, 80, 83 top-down vs. bottom-up development approach 30 transition types 26, 160 transitions 25, 160 deleting process models 228 steps in process models and process regeneration 214, 216 deploying process models creating release of package for logical server 243 items to move 235 logical-to-physical server mappings 234, 238 moving items from Integration Servers 238 moving Modeler generated items on Integration Servers 239 moving to production audit logging database 246 moving Trading Networks information 245 moving Workflow information 245 using Trading Networks export/import data feature 245 Design Server and the Associated Server 206, 208 description 18 use at design time 21

287

development approach description of types 30, 182, 197 development environment before deploying process models 234 tasks to complete in 31 vs. production environment 31 diagrams process generation architecture 200 run-time architecture for processes 28 sample process model 22 webMethods Modeler design-time architecture 20 webMethods platform and webMethods Modeler 17 documentation additional 13 conventions used 13 feedback 13 documents external, see external documents process control documents 29 process transition documents 29, 254 publication, definition 108 publishing from steps 24, 125 restricting documents used by process model 24, 139 subscribing steps to 24, 110 subscription, definition 108 Trading Networks, see external documents using filters 24, 139

E Edit Transititon Conditions window 165 else transitions creating 161 definition 26, 160 Empty Step Properties 82 Enable Resubmission property 71, 77, 81, 256, 261, 269 error messages issued during process generation 216 error transitions creating 161 definition 26, 160 Express Pipeline property 55 and step inputs/outputs 109 defined 55

webMethods Modeler User’s Guide Version 6.1

Index

external documents and sender/receiver roles 112 definition 108 deployinig with process model 245 enabling steps to access 112 guidelines for subscribing to start steps 113 how to have steps send 136 inability to "publish" 136 keeping distinct among logical servers 113 purpose of "publishing" 136 sender role 112 subscribing steps to 110 when to define 50 external groups creating 179 definition 26, 178 warning about transition conditions 163, 180

F filters, definition 24, 139 flat file, changing from flat file to database storage 47 flow services and step logic, overview 148 caution about ProcessData variable 150 completing logic after process generation 222 guidelines for designing step logic 149 how Modeler generates flow services 149 including in release of package for deploying process model 243 location of those generated by Modeler 240, 243 properties affecting generation of 203 Focal Role and sender/receiver roles 112 property defined 54 Folder property how changing affects process model regeneration 212 use during process generation 204 folders, IS properties affecting generation of 202

288

G Generated Flow Name property how changing affects process model regeneration 212 use during process generation 203 generated flow services definition 148 guidelines for working with 148 mapping to user-defined services 149 generating process models see process generation generation package, description 18 global data definition and overview 108 working with global data 143 groups see also external groups see also internal groups definition 26, 66, 178 how PRT ignores 26, 178

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

I icons for steps, changing 105 Implementation Module property how changing affects process model regeneration 215 use during process generation 207 implementation modules completing logic after process generation 222 properties affecting generation of 206

webMethods Modeler User’s Guide Version 6.1

Index

input data assigning to steps 109 instance names 109 subscriptions vs. input data 109 input/output data see also input data see also output data changing and process regeneration 214 checking after 4.6 model migration 283 definition and overview 24, 108 using in transition conditions 163 instance names of input data purpose and description 109 Integration Servers and the Associated Server 206 and webMethods Modeler architecture 18 and Workflow step generation 206 items Modeler generates for processes 201 properties affecting flow services generated for processes 203 properties affecting folders generated for processes 202 properties affecting generation of package 201 properties affecting process run-time script generated for processes 204 properties affecting triggers generated for processes 202 use at design time 21 use during process run time 28 internal groups creating 179 definition 26, 178 IS documents editing contents 120 editing instance names 120 guidelines for subscribing steps to 119 importance of using only once per model 119 publishing to Broker 125 subscribing steps to 115 when to create 31, 50, 183 IS folders, properties affecting generation of 202

289

J Join Queue Lock Expiration (sec), PRT setting 253 join types defined 89 return join types 274, 277 joins (join steps) see also AND joins see also Complex joins see also OR joins see also XOR joins definition 25, 163 forming 25, 163 guidelines for creating 170 three ways to create 163 types, defined 89 JPEG, of process model, creating 63

L Label process property how changing affects process model regeneration 211, 215 use during process generation 201, 202, 207 Label step property how changing affects process model regeneration 212, 215 use during process generation 203, 207, 208 Logging Level property 54, 258, 260, 262 Logical Server property defined 67, 72, 78, 82, 84 how changing affects process model regeneration 213, 215 use during process generation 202, 203, 204, 207, 208 logical servers see also Logical Server property and process generation 200 assigning after 4.6 model migration 283 changing connection state 232 changing step by step vs. throughout process 231 creating release of package containing information for 243 defining and mapping to physical servers 44 definition 20 development vs. production 31

webMethods Modeler User’s Guide Version 6.1

Index

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

M managing logical server assignments 231 process models 226 server connections 231 mapping correlation ID to process instance ID (PID) 154 generated flow to user-defined services 149 logical-to-physical server 44 mappings, logical-to-physical server and deploying process models 234, 238 procedure for defining 44 menu options, defined 36 migration of 4.6 process models basic steps 282 differences in BI 4.6 and Modeler 6.0.1 280 integrity check tasks 283 overview 280 Modeler repository authentication 21 changing from flat file to database storage 47 description 18 use at design time 21 warning about installing with Oracle drivers 47 monitoring process models choosing fields to log 138 controlling the information you monitor 54, 256 making models available for monitoring 222 overview 30 PRTservices that aid monitoring 150

N normal transitions and transition conditions 163 creating 161 definition 26, 160

290

O OR joins and return join types 274 caution about becoming start steps 85 caution using after splits 170 definition 89 Oracle database warning for setting up as Modeler repository 47 output data assigning to steps 124 types defined 124

P Package Name property how changing affects process model regeneration 212 use during process generation 201 package replication using to deploy process model information 239 packages generation, description 18 modeler, description 18 properties affecting generation of 201 parent process, definition 272 performance and quality-of-service configuration overview 250 defined 248 tuning, overview 248 warning about installing database with Oracle drivers 47 physical servers mapping to logical servers 44 relation to logical servers 20 viewing physical-to-logical mapping 232 Portable format import/export format, defined 229 prerequisites before you create process models 50 before you subscribe to external documents 110 Process Audit Log see databases Process Completion Tracking Server choosing one for the territory 255 defined 252 PRT setting 252 process control documents, definition 29

webMethods Modeler User’s Guide Version 6.1

Index

process generation and logical servers 200 completing logic after generating 222 consequences to changing Associated Server 208 error messages and responses 216 items generated on Integration Servers 201 items generated on Workflow Servers 205, 206 overview 200 regeneration 210 sample showing generated items 204 steps to generate process 209 troubleshooting 216 when to regenerate 210 Workflow steps and multiple servers 206 Process Key property use during process generation 201, 202 Process Lock Expiration (sec), PRT setting 253 process models before you create 50 collapsing several steps into single step 25 creating logic 148 creating Workflow logic 151 definition 22 deleting steps and process model regeneration 214, 216 deploying 233 development approach 30, 182 exporting 229 generating 209 importing 229 making available for monitoring 222 migrating BI 4.6 to Modeler 6.0.1 280 Modeler stores in repository 21 moving to Process Audit Log for monitoring 246 moving to production 233 prerequistites to executing after regenerating 210 referencing previously defined 25 regenerating 210 snapshot of sample 22 transitions 25, 160 troubleshooting generation of 216 process pipeline

291

and information flow 109 and input/output data 108 guidelines for variable names 172 using in transition conditions 163 when using an Express Pipeline 55, 109 process run time (PRT) choosing distributed vs. central process tracking 254 database (Process Tracking Store) 253 definition 29 home page, configuring 251 services to use in user-defined services 150 tuning settings across the territory 250 process run-time scripts and process model regeneration 211 definition 27 including in release of package to deploy 243 location in Integration Server 240 properties affecting generation of 204 Process Tracking Store central vs. distributed 254 defined 251, 254 how type affects use of Volatile Tracking property 255 role in territory configuration 250 process transition documents defined 254 process transition documents, definition 29, 254 Process window 39 ProcessData variable in flow services, caution 150 production environment logical-to-physical server mappings 234 moving process models to 233 tasks to complete in 32 vs. development environment 32 profiles, Trading Networks and the publish/subscribe filter 142 deploying with process models 245 program code conventions in this document 13 Project property how changing affects process model regeneration 215 use during process generation 207

webMethods Modeler User’s Guide Version 6.1

Index

projects, Workflow properties affecting generation of 206 properties Folder, how changing affects process model regeneration 212 Folder, use during process generation 204 Generated Flow Name, how changing affects process model regeneration 212 Generated Flow Name, use during process generation 203 Implementation Module, how changing affects process model regeneration 215 Implementation Module, use during process generation 207 Label, how changing affects process model regeneration 211, 212, 215 Label, use during process generation 201, 202, 203, 207, 208 Logical Server, how changing affects process model regeneration 213, 215 Logical Server, use during process generation 202, 203, 204, 207, 208 of referenced process steps 273 of regular steps 67 of transitions 162 Package Name, how changing affects process model regeneration 212 Package Name, use during process generation 201 Process Key, use during process generation 201, 202 Project, how changing affects process model regeneration 215 Project, use during process generation 207 Service to Invoke, how changing affects process model regeneration 213 Service to Invoke, use during process generation 203 Unique ID, use during process generation 203, 207, 208 Version, use during process generation 207 Workflow to Invoke, how changing affects process model regeneration 216 Workflow to Invoke, use during process generation 208 PRT (process run time) choosing distributed vs. central process tracking 254 database (Process Tracking Store) 253 definition 29 home page, configuring 251 services to use in user-defined services 150 tuning settings across the territory 250

292

pub.prt.admin.log logActivityMessages service 150 publishing documents external, important information 136 IS, procedure 125 overview 24, 108

Q quality-of-service and performance configuration overview 250 defined 248 tuning, overview 248

R receiver roles, assigning to external documents 112 referenced processes and hot-swapping 277 and performance/quality-of-service settings 269 definition 25, 89 working with 272 regenerating process models how Modeler makes changes to Integration Server 211 how Modeler makes changes to Workflow Server 215 when to regenerate 210 releases of packages creating to deploy process model information 239 including information for a single logical server 243 replacing logical servers in a process 231 one referenced process step for another, caution 277 repository, Modeler see Modeler repository Retreiving documents flow sequence importance of enabling 112 retries exceeded transitions creating 161 definition 26, 160 return join types defined 274 when to assign to steps 277

webMethods Modeler User’s Guide Version 6.1

Index

S sender role, assigning to external documents 112 sending external documents 136 Server Connections dialog 231 servers consequences to changing Associated Server 208 logical, creating releases of package information for 243 logical, definition 20 mapping logical to physical 44 mappings and process deployment 234, 238 physical, relation to logical servers 20 service packs, Modeler and IS 71, 77, 81, 248 Service to Invoke property definition 68 how changing affects process model regeneration 213 influence on generated flow services 149 use during process generation 149, 203 services caution about ProcessData variable 150 guidelines for working with step logic 149 helpful PRT services 150 how Modeler generates flow services for steps 149 important flow sequence for external document access 112 mapping generated flow to user-defined 149 procedure for assigning to steps 150 properties affecting generation of 203, 204 relationship to steps 148 replacing service a step invokes 149 Service to Invoke property 68, 149 that control a process’s run-time status 150 that create and log activity messages 150 that send external documents 136 types that you can add to steps 148 working with correlation services 152 shutting down the Modeler 35 SP, Modeler and IS 71, 77, 81, 248 splits definition 25, 163 forming 163 guidelines for creating 170

293

start steps and subscription documents 85, 110 defined 85 guidelines for external document subscriptions 113 starting the Modeler 34 Step Lock Expiration (sec), PRT setting 254 steps and step logic 148 changing icons 105 collapsing into a subprocess 25 controlling pipeline logging 54, 71, 77, 81, 258, 260, 261 controlling visual properties of 105 definition and overview 23, 66 enabling resubmission in Monitor 71, 77, 81, 256, 261 end steps 86 how groups affect 178 information flow into and out of 24, 108 join steps 88 overview 66 process-wide error steps 87 properties of referenced process steps 273 properties of regular steps 67 referenced process steps 25, 89, 272 start steps 85 step functions and types 85 subprocess steps 25, 90 using filters 24, 139 Workflow step guidelines 104 Workflow steps overview 23 Steps Enable Resubmission option 71, 77, 81, 256, 261 subprocesses accessing and editing 91 definition 25, 90 procedure for establishing 90 subscription documents and start steps 85, 110 external, and start steps 113 overview and definition 24 subscribing to external documents 110 subscribing to IS documents 115

webMethods Modeler User’s Guide Version 6.1

Index

T Terminate Step Properties 84 territory definition 18 tuning PRT settings in a territory 250 timeout transitions creating 161 definition 26, 160 To-Do List overview 60 viewing 61 toolbar, main, defined 37 toolbar, process, defined 40 Trading Networks deploying attributes with process models 245 deploying profiles with process models 245 deploying TN document types with process models 245 ensuring profiles created 50 export/import data feature and deploying process models 245 participants, using in transition conditions 163 Trading Networks documents see external documents transition conditions and 4.6 model migration 283 creating based on inputs/outputs 163 creating based on pipeline data 163 creating based on Trading Networks participants 163 Edit Transition Conditions window 165 migration of 4.6 TN status conditions 284 overview 25, 163 procedure for building 164, 167 sources of 163 to/from external groups 163, 180 transitions see also transition conditions controlling the color of 175 controlling the display of 175 creating splits, joins, and branches 25, 163 else defined 26, 160 error defined 26, 160 general guidelines for creating 168 guidelines for splits and joins 170 normal defined 160

294

number allowed per step 160 overview and definition 25, 160 procedure for creating 161 properties defined 162 retries exceeded defined 26, 160 timeout defined 26, 160 to/from external groups 163, 180 types defined 26, 160 triggers and process model regeneration 211 location of those generated by Modeler 240, 243 properties affecting generation of 202 troubleshooting information for other webMethods components 13 Oracle database driver installation 47 process generation 216 Workflow step generation and Associated Servers 208 typographical conventions in this document 13

U uncontrolled steps and external groups 26, 178 definition 23 Unique ID property use during process generation 203, 207, 208 updating process models 226 user-defined services changing the service a step invokes 149 mapping to generated flow services 149 procedure for assigning to a step 150

V Version step property defined 53 use during process generation 207 versioning process models overview and steps 227 Version step property 53 View Options, defined 41 viewing server connections 232 Volatile Tracking property relationship to type of Process Tracking Store 255

webMethods Modeler User’s Guide Version 6.1

Index

W

X

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

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

webMethods Modeler User’s Guide Version 6.1

295

Index

296

webMethods Modeler User’s Guide Version 6.1