Introduction to webMethods Fabric 6.5 and 6.5.1.pdf

Introduction to webMethods Fabric

VERSION 6.5 AND 6.5.1

webMethods, Inc. South Tower 3877 Fairfax Ridge Road Fairfax, VA 22030 USA 703.460.2500 http://www.webmethods.com

webMethods Access, webMethods Administrator, webMethods Broker, webMethods Dashboard, webMethods Developer, webMethods Fabric, webMethods Glue, webMethods Installer, webMethods Integration Server, webMethods Mainframe, webMethods Manager, webMethods Modeler, webMethods Monitor, webMethods Optimize, webMethods Portal, webMethods Servicenet, webMethods Trading Networks, and webMethods Workflow are trademarks of webMethods, Inc. webMethods and the webMethods logo are registered trademarks of webMethods, Inc. Acrobat and Adobe are registered trademarks, and Reader is a trademark of Adobe Systems Incorporated. Amdocs is a registered trademark, and ClarifyCRM is a trademark of Amdocs. Ariba is a registered trademark of Ariba, Inc. BEA, BEA WebLogic Server, Jolt, and Tuxedo are registered trademarks, and BEA WebLogic Platform is a trademark of BEA Systems, Inc. Action Request System, BMC Software, PATROL, and Remedy are registered trademarks of BMC Software, Inc. BroadVision is a registered trademark of BroadVision, Inc. ChemeStandards and CIDX are trademarks of Chemical Industry Data Exchange. Unicenter is a registered trademark of Computer Associates International, Inc. PopChart is a registered trademark of CORDA Technologies, Inc. Kenan and Arbor are registered trademarks of CSG Systems, Inc. Data Connection and SNAP‐IX are registered trademarks of Data Connection Corporation. DataDirect, DataDirect Connect, and SequeLink are registered trademarks of DataDirect Technologies. D&B and D‐U‐N‐S are registered trademarks of Dun & Bradstreet Corporation. Entrust is a registered trademark of Entrust, Inc. papiNet is a registered trademark of the European Union and the United States. Financial Information eXchange, F.I.X, and F.I.X Protocol are trademarks of FIX Protocol Ltd. UCCnet and eBusinessReady are registered trademarks, and 1SYNC and Transora are trademarks of GS1 US. Hewlett‐Packard, HP, HP‐UX, OpenView, PA‐RISC, and SNAplus2 are trademarks of Hewlett‐Packard Company. i2 is a registered trademark of i2 Technologies, Inc. AIX, AS/400, CICS, DB2, Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, z/OS, and WebSphere are registered trademarks; and Communications System for Windows NT, DB2 Universal Database, IMS, MVS, and SQL/DS are trademarks of IBM Corporation. InnoDB is a trademark of Innobase Oy. Itanium is a registered trademark of Intel Corporation. JBoss is a registered trademark, and JBoss Group is a trademark of Jboss, Inc. Linux is a registered trademark of Linus Torvalds. W3C is a registered trademark, and X Window System is a trademark of the Massachusetts Institute of Technology. MetaSolv is a registered trademark of Metasolv Software, Inc. ActiveX, Microsoft, Outlook, Visual Basic, Windows, and Windows NT are registered trademarks; and Windows Server is a trademark of Microsoft Corporation. Six Sigma is a registered trademark of Motorola, Inc. Firefox is a registered trademark, and Mozilla is a trademark of the Mozilla Foundation. MySQL is a registered trademark of MySQL AB. nCipher is a trademark of nCipher Corporation Ltd. Teradata is a registered trademark of NCR International, Inc. Netscape is a registered trademark of Netscape Communications Corporation. ServletExec is a registered trademark, and New Atlanta is a trademark of New Atlanta Communications, LLC. SUSE is a registered trademark of Novell, Inc. Appia is a registered trademark and Javelin Technologies is a trademark of NYFIX, Inc. CORBA is a registered trademark of Object Management Group, Inc. JD Edwards, OneWorld, Oracle, PeopleSoft, Siebel, and Vantive are registered trademarks, and PeopleSoft Pure Internet Architecture and WorldSoftware are trademarks of Oracle Corporation. Infranet and Portal are trademarks of Portal Software, Inc. Red Hat is a registered trademark of Red Hat, Inc. PIP and RosettaNet are trademarks of RosettaNet, a non‐profit organization. SAP and R/3 are registered trademarks of SAP AG. SWIFT and SWIFTNet are registered trademarks of Society for Worldwide Interbank Financial Telecommunication SCRL. SPARC and SPARCStation are registered trademarks of SPARC International, Inc. SSA is a registered trademark, and Baan and SSA Global are trademarks of SSA Global Technologies, Inc. EJB, Enterprise JavaBeans, Java, JavaServer, JDBC, JSP, J2EE, Solaris, Sun, and Sun Microsystems are registered trademarks; and Java Naming and Directory Interface, SOAP with Attachments API for Java, JavaServer Pages, and SunSoft are trademarks of Sun Microsystems, Inc. Sybase is a registered trademark of Sybase, Inc. VERITAS is a registered trademark, and VERITAS Cluster Server is a trademark of Symantec Corporation. UNIX is a registered trademark of The Open Group. Unicode is a trademark of Unicode, Inc. VeriSign is a registered trademark of Verisign, Inc. All other marks are the property of their respective owners. Copyright © 2004‐2006 by webMethods, Inc. All rights reserved, including the right of reproduction in whole or in part in any form. Document ID: WEBM-INTRO-65-20060630

Contents

Contents Chapter 1. Integrating the Extended Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Today’s Integration Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Integration Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrating Systems Inside and Outside the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An Enterprise-Wide Integration Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comprehensive Support for Resources Inside the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . Comprehensive Support for Resources Outside the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . Scalable Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strong Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Personalized Access to Information that Your Users Require . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing and Managing Integrated Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing and Optimizing Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Comprehensive Solution for End-to-End Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 2. webMethods Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Components for Design, Production, and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Integration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Trading Networks and eStandard Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Manager Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Workflow Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Trading Networks Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Portal Portlet Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administrative and Monitoring Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Manager Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . webMethods Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction to webMethods Fabric Version 6.5 and 6.5.1

7 8 9 9 10 11 11 11 12 13 13 13 14 15

17 18 20 20 21 23 24 25 27 28 29 29 31 31 33 34 36 37 38 38 39 40

3

Contents

webMethods Optimize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 webMethods Portal Administration Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Chapter 3. Key Concepts, Features, and Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Business Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task-Based User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customizable Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Securing Access to the Integration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Securing Behind Your Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Securing the Other Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clustered Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tuning Performance of Individual Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44 44 45 45 46 46 47 48 48 49 49 50 51 52 53 53 53 54 55 56 57 57 58 58

Chapter 4. Common Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exchanging Documents with Business Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Business Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Integration Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Design and Development Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizing Information Across the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Business Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Integration Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Design and Development Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

62 62 62 63 65 66 67 67 67 68 69


Contents

Automating a Multi-Step Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Business Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Integration Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Design and Development Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring and Controlling the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix A. Summary of webMethods Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70 70 70 72 73

75

Design-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Run-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Administrative Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


81

5

Contents

6


CHAPTER

1

Integrating the Extended Enterprise Today’s Integration Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Integrating Systems Inside and Outside the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Designing and Managing Integrated Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A Comprehensive Solution for End-to-End Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15


7

CHAPTER 1 Integrating the Extended Enterprise

Today’s Integration Challenge The past decade produced unprecedented leaps in computing technology. Not surprisingly, this astonishing growth also produced an unruly explosion of applications, data, and single‐purpose business processes, both inside and outside the enterprise. Today, a typical enterprise hosts an assortment of databases, legacy applications, custom software, and packaged applications that frequently span time zones, languages, and currencies. Additionally, the widespread use of the Internet and open standards makes it possible, indeed expected, for an enterprise to integrate its systems with those of its business partners in real time. Today’s enterprise hosts an unruly assortment of applications, systems, and manual operations

The challenge for today’s integration professional is to harness the assets of these diverse systems into powerful and efficient business processes, creating composite solutions that span applications, information systems, and manual operations.

8


Integrating Systems Inside and Outside the Enterprise

webMethods Integration Solution webMethods software enables the end‐to‐end solutions that today’s businesses demand. With proven integration technology and sophisticated design tools, webMethods provides a globally scalable and extendable infrastructure for automating business processes across the extended enterprise. Through a powerful set of components designed specifically for developing, deploying, managing, and optimizing integration solutions, webMethods software allows you to: Leverage your investment in information technology by integrating existing systems instead of deploying new monolithic systems or making sweeping changes to existing applications. Shorten development cycles with sophisticated and easy‐to‐use modeling tools, reducing development costs and allowing you to reap the intended benefits of a solution more quickly. Streamline business processes internally and externally, yielding benefits such as reduced operating costs, increased productivity, lower error rates, and improved customer relations. Provide your user community personalized access to information relevant to their job functions resulting in increased productivity and collaboration. Additionally, as a recognized leader in the development and support of open computing standards, webMethods delivers a future‐ready infrastructure that allow you to leverage technologies such as Web services, while preserving your existing investment in technology and integration.

Integrating Systems Inside and Outside the Enterprise Integration technology allows diverse systems, applications, and processes to share data and logic. It enables you to develop powerful new applications by leveraging existing IT assets instead of replacing them. The reasons for implementing an integration solution vary from organization to organization. Typically, however, organizations want to: Reduce time and errors by automating manual interfaces between systems. Gain access to comprehensive, up‐to‐the‐minute business information by aggregating data from multiple systems. Reduce data latency by automating the flow of data from one system to another. Keep information synchronized across multiple data stores. Regardless of the reason, the objectives of integration technology are to facilitate the fluid exchange of data and logic among resources and to support the easy development and management of complex business processes.


9


An Enterprise-Wide Integration Backbone webMethods software enables the exchange of data and logic by serving as an enterprise‐wide integration backbone. Resources that you want to integrate connect to the integration backbone instead of directly to each other. Resources you want to integrate connect to the integration backbone

webMethods provides the infrastructure and connective logic that enable diverse resources to operate in a cohesive and unified manner. It performs the essential work of transporting information among resources, dispatching documents according to established business rules, and invoking processes on target systems. It also hosts integration logic, performs data transformation, and supports both synchronous (RPC and request/reply) and asynchronous (messaging) modes of interaction among resources.

10


Integrating Systems Inside and Outside the Enterprise

Comprehensive Support for Resources Inside the Enterprise webMethods software supports a wide range of systems and applications. Among the resources that it can integrate are: Commercial packaged applications such as SAP R/3, Siebel, i2, JD Edwards, Oracle Applications, and PeopleSoft Databases such as Oracle, SQL Server, Informix, Sybase, and DB2, as well as any ODBC‐ or JDBC‐compliant data store Legacy CICS‐ and IMS/TM‐based applications Custom applications written in C/C++, COM, Java, and EJB

Comprehensive Support for Resources Outside the Enterprise Although the widespread use of the Internet makes integration among trading partners possible, there is no single standard for exchanging business information this way. Instead, the Internet offers a variety of ways to transport and encode documents, an array of e‐commerce standards defining how to exchange business information, and a variety of document formats. As a result, each of your business partners might use a different standard (or even a proprietary format) to send and receive business documents. webMethods software supports a wide range of established and emerging standards so you can implement solutions with virtually any trading partner that is connected to the Internet. These include: Transport standards such as HTTP, HTTPS, FTP, and SMTP Message formats such as MIME and S/MIME Data standards such as XML, XML Schema, and EDI, as well as custom flat file formats with delimited fixed‐ or variable‐length records Protocols such as SOAP, XML RPC, and ebXML Industry standards such as RosettaNet, UCCnet, SWIFT FIN, and CIDX Chem eStandards Standards such as Web services and WSDL

Scalable Architecture You use webMethods components in a distributed architecture. This architecture allows growth from a simple, departmental‐level configuration to a global, enterprise‐wide integration backbone that can handle thousands of documents per second.


11


This flexible design lets you deploy an integration backbone incrementally, connecting systems and resources one‐by‐one, over time. You can deploy webMethods components in a variety of clustered and fully‐distributed configurations so you can balance workloads and increase throughput in high‐traffic areas. A distributed architecture allows you to scale to your needs

Strong Security Controls Rigorous security measures are essential for any integration solution, but they are especially crucial when you are integrating systems over the Internet. In an Internet‐based solution, sensitive information from your enterprise travels over a public network. In a tightly integrated solution, you might even grant trading partners some level of access to your internal systems. webMethods provides the safeguards necessary to assure the security of the integration backbone and the systems that it integrates. Data is secured for transport through the use of data encryption, digital signatures, and signature verification. Access to the webMethods components is controlled through X.509 client certificates, access control lists, and IP address filters. As described later in this book, you can use a ‘reverse invoke’ configuration to shield it from direct access by clients outside the enterprise.

12


Designing and Managing Integrated Business Processes

Personalized Access to Information that Your Users Require webMethods provides a standards‐based, portal presentation platform that allows you to offer your users personalized access to information, applications, and business processes that are relevant to them. You can build a set of Web‐based portal pages that incorporate multiple resources. Rather than interacting with many different resources, your users simply access the single set of Web‐based portal pages. If you have legacy databases and middleware systems, you can integrate access to them through portal pages and leverage this existing technology rather than discard it. You can group related information from multiple resources on one portal page, allowing users to view all relevant information about a subject from a single location rather than accessing multiple applications to obtain the information. Additionally, if action is required, users can take action from the portal page. You grant access to information on a portal page based on who a user is. As a result, multiple users accessing the same portal page might view different content based on their access privileges. webMethods allows you to strictly manage how users access and interact with information.

Designing and Managing Integrated Business Processes Today, integration involves more than simply gluing dissimilar systems together. Today’s integration solutions deliver business process integration, that is, the end‐to‐end integration of an entire business process (including steps that involve human interaction). To successfully implement a comprehensive process‐integration solution, you need specialized design and management tools.

Designing Business Processes webMethods provides an easy‐to‐use graphical tool for modeling business processes. The tool lets you visually depict the flow of information among systems, organizations, and people. After you define the model, the tool automatically generates code for the underlying system components.


13


Modeling a business process

Managing and Optimizing Business Processes webMethods provides real‐time, graphical views that let you monitor, manage, and optimize your end‐to‐end solutions. System‐management views allow an IT administrator to spot bottlenecks and inefficiencies as information flows among systems. Business‐process views allow an analyst to examine the status of a particular process and perform control functions such as suspending steps and resubmitting documents. Business process owners receive early information about inefficient bus processes and root cause information to proactively repair problems to bring business processes back into optimal efficiencies.

14


A Comprehensive Solution for End-to-End Integration

Real-time views allow you to monitor the status of a business process

A Comprehensive Solution for End-to-End Integration From design to execution to management, webMethods provides the industry’s most comprehensive solution for linking applications, processes, people, and systems. Read on to learn about: webMethods components Key features and capabilities Examples of common integration problems that webMethods solves


15


16


CHAPTER

2

webMethods Components Components for Design, Production, and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Run-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Design-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Administrative and Monitoring Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


17

CHAPTER 2 webMethods Components

Components for Design, Production, and Management Use webMethods components to design, execute, manage, and optimize integration solutions. Components fall into three basic categories: run‐time components, design‐time components, and administrative components. Component Type

Description

Run-Time

These components execute integration solutions that you develop. The run‐time components are: webMethods Integration Server webMethods Broker webMethods Adapters webMethods Mainframe webMethods Trading Networks and eStandard Modules webMethods Workflow webMethods Manager Server webMethods Servicenet webMethods Portal

18


Components for Design, Production, and Management

Component Type

Description

Design-Time

These components provide tools for developing and testing integration solutions. The design‐time components are: webMethods Modeler webMethods Workflow Designer webMethods Developer webMethods Trading Networks Console webMethods Portal Portlet Developer

Administrative and Monitoring

These components let you configure the run‐time environment and monitor the execution of integration solutions that are executing at run time. The administrative components are: webMethods Administrator webMethods Manager Console webMethods Monitor webMethods Optimize webMethods Portal Administration Dashboard


19


Run-Time Components The following run‐time components execute the integration solutions that you develop. webMethods Integration Server webMethods Broker webMethods Adapters webMethods Mainframe webMethods Trading Networks and eStandard Modules webMethods Workflow webMethods Manager Server webMethods Servicenet webMethods Portal These components perform the work of routing information among resources, transforming and validating data, executing integration logic, and invoking processes on target systems.

webMethods Integration Server webMethods Integration Server is the central run‐time component and the primary engine for the execution of integration logic. It is the main entry point for the systems and applications that you want to integrate. webMethods Integration Server connects internal and external resources to the integration backbone

HTTP /HTTPS

EMAIL

Integration Server

20

FTP


Run-Time Components

webMethods Integration Server plays the following key roles: Hosts adapters. The Integration Server hosts adapters, which are special modules that link the back‐end resources in your enterprise to the integration backbone. Adapters interact directly with the applications and systems that you want to integrate. A single Integration Server can host one or more adapters. For more information about adapters, see “webMethods Adapters” on page 23. Serves as a business-to-business gateway. The Integration Server is the central point of contact between integration backbone and systems outside the enterprise. It provides the underlying support for transporting and encoding business documents using the open standards of the Internet. It also hosts modules that provide support for e‐commerce standards such as EDI, RosettaNet, and ebXML. Executes integration logic. The Integration Server performs the work of retrieving data from one resource and delivering it to another by executing integration logic. Integration logic is housed in units called services. In an integration solution, you build services to perform work such as retrieving (or receiving) data from a resource, executing calculations, applying business rules, transforming data, and delivering data to other resources. Services are described in more detail later in this book. Hosts utilities and administrator tools. The Integration Server provides the run‐time environment for logging subsystems and many of its monitoring and management components. An integration backbone must include at least one Integration Server. If your enterprise has many resources and systems to integrate, you will probably deploy multiple Integration Servers and divide the resources among them. You can also deploy Integration Servers in clustered configurations to achieve load‐balancing, high availability, or both. Clustering is described in more detail later in this book. To Learn More: See the webMethods Integration Server Administrator’s Guide.

webMethods Broker webMethods Broker is a high‐speed message router. It is the primary component of what is generally referred to as the “message backbone” or “message facility.” Along with supporting features provided by the other components, webMethods Broker facilitates asynchronous, message‐based solutions using the publish‐and‐subscribe model. The publish‐and‐subscribe model is a specific type of message‐based solution in which resources exchange messages (carrying documents) anonymously through a message broker. Under this model, applications that produce information make that information available in specific types of documents that they publish to a Broker. Applications that require information subscribe to the specific types of documents that they need.


21


A Broker routes messages between webMethods components

Integration Server

Integration Server

Broker

Workflow Server

The role of a Broker is to route documents between information producers (publishers) and information consumers (subscribers). webMethods components such as the Integration Server and the Workflow Server function as both publishers and subscribers. They interact with the Broker using a proprietary protocol. The Broker maintains a list of subscribers that are interested in receiving certain types of documents. When a component publishes a document, the Broker queues the document for the subscribers of that particular document type. When a subscriber receives a document from its queue, an action is triggered on the subscriber’s system that processes the document. For example, you might develop an integration solution in which the Integration Server publishes a “new employee document” to the Broker each time a new employee record is added to a Human Resources system. Subscribers of “new employee documents,” which might include an Integration Server that hosts a connection to a database application or a Workflow Server that manages a manual task, receive documents from the Broker and process the information that they contain. You can use multiple Brokers that operate in groups called territories. Territories enable a distributed group of Brokers to act as an administrative unit. They also support scalability

22


Run-Time Components

and allow you to segment traffic across multiple Brokers. Territories are described in more detail later in this book. Note: If you use only a single Integration Server and no Workflow component, you might not require a Broker. You can perform publish‐and‐subscribe interactions locally within an Integration Server if the adapted resources are all connected to the same Integration Server. To Learn More: See the webMethods Broker Administrator’s Guide and Publish‐Subscribe Developer’s Guide.

webMethods Adapters Adapters run on the Integration Server. They connect the back‐end resources in your enterprise (for example, a customer database, a Human Resources application, an inventory system) to the integration backbone. An adapter exposes the data and business logic associated with a particular back‐end resource to the Integration Server. An adapter allows you to incorporate a resource in an integration solution without having to build complex custom code or understand the low‐ level details of the resource or its transport protocol. The adapter handles the low‐level work of connecting to the resource, managing communications, encoding and decoding data, and invoking processes via the resource’s API. webMethods adapters interact with back-end resources

Adapter

ERP System

Integration Server Adapter

Adapter

JDBC Database

CRM System

Note: Some earlier webMethods adapters do not execute on the Integration Server. Instead, they function as free‐standing clients of the webMethods Broker. If your site uses these types of adapters, a Broker is required.


23


At run time, the Integration Server initiates a process on a back‐end resource via an adapter service. An adapter service runs on the Integration Server and uses the functions of the adapter to invoke specific processes on a resource. (For example, an adapter service might query a database, post a journal entry to a general ledger application, or delete an item from an inventory system). Because adapter services execute on the Integration Server, they also have full access to the server’s file handling (XML and flat file) and transport (HTTP, FTP, SMTP) capabilities. A back‐end resource can initiate actions via an adapter notification. An adapter notification alerts that there are changes to the back‐end system that, in turn, require actions from other systems and applications. For example, a Human Resources system might generate an adapter notification when a new employee is added to its database. When the Integration Server receives the notification, it could add a work request to the IT department’s work‐order system, update the expense‐reporting application in accounting, and forward the employee’s record to the company’s group insurance provider. An Integration Server requires an adapter for each type of resource with which it interacts. webMethods provides adapters for a broad range of databases and business systems, such as those listed under “Comprehensive Support for Resources Inside the Enterprise” on page 11. To Learn More: See the user’s guide for the specific adapter that you are using. These guides are installed on the Integration Server with the adapter software.

webMethods Mainframe The webMethods Mainframe component allows you to include processes on IBM‐compatible mainframe computers in an integration solution. It functions as an agent between the Integration Server and online applications running under CICS (Customer Information Control System) or IMS/DC (Information Management System/Data Communications) on the mainframe. In addition to the request‐reply transactions commonly used to interact with mainframe computers, the webMethods Mainframe component also allows subscriptions to publishing events that occur on the mainframe. The webMethods Mainframe component sits between the Integration Server and the mainframe. It communicates with the mainframe computer over either a TCP/IP (Transmission Control Protocol/Internet Protocol) network or an SNA (Systems Network Architecture) network. When communicating over an SNA network, webMethods Mainframe connects through an SNA communications server.

24


Run-Time Components

webMethods Mainframe component interacts with CICS and IMS applications

Integration Server Integration Server

SNA

Mainframe Component TCP/IP Mainframe CICS or IMS Application

Note: Conceptually, you can think of the Mainframe component as an adapter that does not run on the Integration Server. Depending on the capabilities of your mainframe computer, the webMethods Mainframe component can submit requests using screen‐based transactions or message‐based transactions. Screen‐based transactions simulate the actions of a user at a 3270 terminal and extract information from the screens that the mainframe returns. This approach is non‐invasive, quick to implement, and requires no changes to host transactions. Message‐ based transactions make direct calls to the application using a variety of communications channels. This approach often results in better performance and better utilization of mainframe CPU resources than screen‐scraping integration techniques. At run time, the Integration Server executes services that pass requests to the webMethods Mainframe component. The webMethods Mainframe component submits the request to the mainframe computer and returns the result to the Integration Server. The Mainframe component is an optional component in the integration backbone. You install this component only if you need to integrate IBM‐compatible mainframe applications with your other resources. To Learn More: See the webMethods Mainframe Administrator’s Guide and the webMethods Mainframe Developer’s Guide.

webMethods Trading Networks and eStandard Modules webMethods Trading Networks is a component that runs on the Integration Server. You use Trading Networks to build, manage and analyze your network of trading partners in a document‐oriented exchange scenario. A trading partner can be any system, inside or outside your enterprise, that produces or consumes business documents. Conceptually, Trading Networks is a format‐neutral, business‐document gateway that can recognize and process multiple XML and structured flat‐file formats that flow


25


between distributed trading partners. It is also the base for support of numerous eBusiness Standards (eStandards) such as RosettaNet, EDI, ebXML messaging service, SWIFT FIN, and CIDX. These eStandards use features of the Trading Networks component to carry out the processing behavior that is specific to their protocol. webMethods Trading Networks acts as a business document gateway

Integration Server

HTTP

EDI

E-MAIL XML

Trading Networks FTP

RosettaNet EDI Module RNet Module

webMethods Trading Networks maintains profiles of the trading partners with which you transact business. It also maintains descriptions of the types of documents that you and your partners exchange. When Trading Networks receives a document at run time, it dispatches the document to the appropriate process based on processing rules that you specify. A processing rule specifies the actions that Trading Networks is to execute when it receives a document matching the rule’s criteria. For example, a processing rule might instruct Trading Networks to submit incoming purchase order documents to a service that posts them to an order‐entry application in your Sales department. Another processing rule might instruct Trading Networks to submit incoming invoices to a service that passes them to a financial application in your Accounting department. In each case, the processing rule might also instruct Trading Networks to validate the document’s contents and digital signature before passing the document to a service for processing. The Trading Networks component includes a design‐time tool, Trading Networks Console, that you use to configure your trading network. For more information about this tool, see “webMethods Trading Networks Console” on page 36. To Learn More: See webMethods Trading Networks Concepts Guide, webMethods Trading Networks User’s Guide, webMethods Trading Networks Built‐In Services Reference, and webMethods Trading Networks Web Manager Administrator’s Guide.

26


Run-Time Components

webMethods Workflow webMethods Workflow directs the execution of workflows. A workflow is a series of tasks performed by one or more people (participants) at execution time. Approval and review processes are examples of work that is commonly implemented through workflows. Workflows are also often used for exception handling in otherwise automated processes. A workflow is a message‐driven process. When a participant is required to perform a task, the Workflow component issues a message to that participant. When the participant completes the task, the Workflow component issues a message to the next participant in the workflow. A workflow can contain complex sequences whose flow of execution is directed by routing decisions, timers, and join conditions. The Workflow component is made up of a Workflow Server, which orchestrates the execution of a workflow by routing messages to the appropriate participants at the appropriate time, and a Workflow client, which participants use to view and complete their pending tasks. The client presents task‐related information (for example, the details of an expense report to be approved) to participants through a custom Java or HTML user interface that you tailor to the task. The Workflow Server is a client of the Broker. The Broker provides the underlying publish‐and‐subscribe messaging infrastructure upon which workflows are implemented. This allows you to incorporate a human workflow in an integration solution in the same way you would any other resource. The Workflow component subscribes to documents that are required to launch a workflow; it publishes documents that need to be shared with other resources connected to the integration backbone. webMethods Workflow Server manages the execution of manual tasks

Workflow Client Workflow Client

Workflow Server

Workflow Client

Broker

For example, suppose certain invoices require management approval before they are submitted to your accounts payable application for payment. The Integration Server would publish those invoices to the Broker, and the Workflow Server would subscribe to them. When an invoice arrives in its queue on the Broker, the Workflow Server would receive the invoice and launch the workflow that routes the invoice to the appropriate


27


manager for approval. After the manager reviews and approves the invoice, Workflow Server would publish the invoice back to the Broker and the Integration Server would fetch it and then post it to the accounts payable system. In addition to directing the execution of workflows, the Workflow Server tracks run‐time activity. You can view, stop, suspend, and resume workflow processes from the Business Monitoring pages in My webMethods. You build and deploy workflows (including the customized interfaces that participants use to view and execute tasks) using Workflow Designer. For more information about this tool, see “webMethods Workflow Designer” on page 33. To Learn More: See the webMethods Workflow Concepts Guide and the webMethods Workflow User’s Guide.

webMethods Manager Server webMethods Manager is a systems management facility based on the Open Management Interface (OMI). OMI is a programmatic interface that enables systems management applications to access and manage resources. It was jointly developed by webMethods and Hewlett‐Packard and is based on the open standards of XML, SOAP, and HTTP. webMethods Manager is made up of two pieces: Manager Server and Manager Console. Manager Server is described below. For more information about Manager Console, see “webMethods Manager Console” on page 39. Manager Server maintains information about the resources that you want to manage. Resources you can manage include webMethods components such as Integration Servers, Brokers, webMethods Mainframe, and Workflow Servers, as well as business processes that you have modeled with webMethods Modeler. A resource that you want to manage is represented by a managed object on the Manager Server. The managed object maintains operational attributes (status information) about the resource it represents and provides notifications when certain types of events (such as a failure) occur on the resource. The managed object also includes a set of operations (actions) that it can perform on the resource. Systems management applications use the OMI API to interact with managed objects via SOAP and HTTP. The API enables a systems management application to monitor statistics of interest (for example, the size of a message queue), detect component failures in near real‐time (for example, to sense whether an Integration Server has stopped functioning), and execute basic functions against a resource (for example, to restart a Broker). To Learn More: See the webMethods Manager Server Administrator’s Guide and the webMethods Manager Server Programmer’s Guide.

28


Run-Time Components

webMethods Servicenet webMethods Servicenet is an Enterprise Service‐Oriented Architecture (SOA) infrastructure for building, deploying, and managing applications based on Web services standards. The SOA capabilities run between the service providers and the service consumers. Due to the SOA infrastructure, in addition to simply hosting individual Web services, webMethods Servicenet allows you to assemble large, dynamic, robust, managed, business systems out of your Web services. The resulting business systems are distributed, componentized, standards‐based, open, scalable, and vendor‐neutral. As a part of your integration backbone, webMethods Servicenet allows access into legacy systems, effectively allowing you to incorporate all IT assets into the SOA. Because webMethods Servicenet is standards‐based, it can incorporate all Web services, including those exposed using proprietary integration products from other vendors, application servers, and the new generation of service‐oriented application modules being developed by package application vendors. Features of webMethods Servicenet include: Integrated UDDI server. webMethods Servicenet uses its own native, distributed, replicating UDDI implementation that provides an enterprise‐wide index of all manageable services that are queried to obtain the WSDL, and thus endpoint, at runtime. Dynamic discovery and binding. webMethods Servicenet enables automatic failover and load‐balancing across services when operating conditions reach thresholds outlined by Service Level Agreements. It supports flexible, location‐transparent systems that are not‐tied to physical endpoints which enables the movement of business logic to new host systems without needing to change consumer code. XML message processing that enables you to apply rules to the processing of XML message traffic to perform filtering, monitoring, and transformations based on conditions such as XPath expressions. For example, a set of rules can transform a message to change the behavior of the endpoint. To Learn More: See the webMethods Servicenet User’s Guide and webMethods Servicenet Administrator’s Guide.

webMethods Portal webMethods Portal is a powerful framework for rapid composite application assembly. Built completely around Web services, webMethods Portal provides a robust composite application development environment that includes powerful visual design and development tools, a sophisticated user management system, advanced personalization capabilities, role‐based security, and an out‐of‐box document management and collaboration system. It allows users to participate in business processes across the enterprise. It provides more effective filtering, focusing on diverse and valuable


29


information, applications, and services to help organizations achieve their most pressing goals. webMethods Portal leverages existing IT investments and consolidates information resources—including structured data in enterprise applications and unstructured data such as documents and presentations—from a single, unified interface. Using webMethods Portal, an IT organization can reduce its application backlog and become more strategically aligned with the business through the re‐use and re‐purposing of existing IT assets that can be assembled into new composite applications. Features of webMethods Portal include: Enhanced user, group, and role management. Seamless integration with existing user directories such as Microsoft Active Directory and LDAP eliminate the need to replicate or synchronize user and group data. Single Sign-On via SAML. Expanded support for the Security Assertion Markup Language (SAML) enables webMethods Portal to be configured for single sign‐on with other Web applications or sites that conform to the SAML standard. Support for External Policy Engines. webMethods Portal supports the delegation of authorization services for portal access control to external security policy engines. This promotes the reuse of existing security infrastructure and allows for the implementation of a standardized and consistent application security model that promotes reuse of existing security policies across a variety of application infrastructures. Content Syndication. webMethods Portal provides a powerful, generic Really Simple Syndication (RSS) viewer portlet that can automatically display RSS feeds from any external RSS provider. All external RSS information and related metadata is automatically indexed by the embedded search engine allowing users to quickly add syndicated content to any composite application or portal site. To Learn More: See the Getting Started with webMethods Portal, the webMethods Portal Design Guide, and the webMethods Portal Administrator’s Guide.

30


Design-Time Components

Design-Time Components The following design‐time components enable you to build, test, and deploy integration solutions. webMethods Modeler webMethods Workflow Designer webMethods Developer webMethods Trading Networks Console webMethods Portal Portlet Developer

webMethods Modeler webMethods Modeler is a graphical tool you use to design and implement business processes. A business process is a multi‐step interaction among participating systems, people, and trading partners. A business process can be fully automated (involve only interaction among computer systems) or include varying degrees of human interaction (for example, review and approval steps). It can be brief or long‐running. Some business processes transpire over days or weeks. Modeler lets you describe the interactions and relationships of a sequence of activities in a process using common process‐modeling constructs. This top‐down approach to integration allows a business analyst or someone with expertise in your company’s procedures and business rules to model a process without having to understand the technical aspects of the actual systems being integrated. After a business process is defined, the analyst uses Modeler to generate the underlying code that implements the design in the webMethods components. For example, a business analyst might use Modeler to describe the sequence of automated and manual activities that occur when a new employee joins the company. These might include tasks such as adding the employee to various departmental databases, issuing work requests to the facilities and IT groups, and enrolling the employee to the company’s group health plan. After the analyst completes the design, Modeler generates the underlying control logic for the individual steps in the business process. Process models designed with Modeler describe a sequence of steps and specifies how information flows among them. In general, a process model is composed of steps, transitions, and documents. A step can represent the following: A unit of work performed by a service on an Integration Server. Human interaction defined by a task or workflow on a Workflow Server.


31


A call to or from a Web service. An out‐of‐process activity that is performed by a trading partner or other external entity that consumes or produces documents at execution time. A transition represents the flow of control or passing of information between steps. A transition can explicitly connect one step to another or it can define a conditional transition such as a branch or a join. A transition can also specify the action that is to be taken if a step fails to execute or throws an error. Documents represent the data consumed by (input) or produced by (output) a step. webMethods Modeler lets you visually define a business processes

When you generate an implementation of a process, Modeler connects to the participating servers (that is, the Integration Servers and/or Workflow Servers that execute one or more steps in the process) and generates run‐time logic for each step. On an Integration Server,

32



Modeler generates flow services, triggers, and process run‐time scripts. On a Workflow Server, it generates an implementation module and an empty workflow. Note: With Modeler, you can take a top‐down or bottom‐up approach when developing a process model. That is, you can either describe the high‐level process first and fill in the details of the individual steps afterwards. Or you can build the individual steps first and then use Modeler to assemble them into a process. Modeler runs as a client of a design server, which is an Integration Server equipped with the Modeler Design Package. The design server interacts with the central repository where process models are stored. Modeler also dynamically connects to other participating servers at various times during the design process when it needs to store information to or read information from those components. To Learn More: See the webMethods Modeler User’s Guide and Getting Started with Business Process Management.

webMethods Workflow Designer You use Workflow Designer to develop and deploy workflows. Workflows are processes made up of steps that one or more people carry out. Workflow Designer user interface


33


Workflow Designer allows you to model tasks that make up a human‐based flow of work and define the roles of its participants. A task is the unit of work that a Workflow participant must complete before the workflow can proceed. When you build a workflow with Designer, you insert control elements that govern the sequencing of tasks. These include routers, which split a workflow into branches based on specified conditions, joins, which wait for two or more tasks to complete before allowing the workflow to proceed, and timers which launch tasks based on scheduled or elapsed time. A role is an abstract label that represents a job function. For example, a contract‐approval process might include roles such as ‘Approver’ and ‘Legal Advisor.’ Roles have user‐ defined properties. An approver’s role, for example, might have properties such as ‘department’ and ‘authorization limit.’ You use roles and their properties to define distribution rules. A distribution rule specifies to whom the Workflow Server is to distribute tasks at execution time. For example, a distribution rule might distribute tasks to approvers having authorization limits greater than a specified amount. Besides providing tools for designing a workflow model, Designer also provides the tools you use to create user interfaces, called task views. Participants use task views to view and complete their tasks. A task view can display information produced by any previous task or service. You can present different task views to participants based on criteria such as their role. You can present task views using a Java or HTML‐based interface. Workflow Designer operates as a client of the Workflow Server. It is one of several tools that are packaged with the Workflow client. To Learn More: See the webMethods Workflow Concepts Guide and the webMethods Workflow User’s Guide.

webMethods Developer webMethods Developer is a graphical development tool that you use to build, edit, and test integration logic. It provides an integrated development environment in which to develop the logic and supporting elements that carry out the work of an integration solution. It also provides tools for testing and debugging the solutions you create.

34



webMethods Developer

webMethods Developer lets you rapidly construct integration logic with an easy‐to‐use implementation language called the webMethods Flow Language, or flow. Flow provides a set of simple but powerful constructs that you use to specify a sequence of actions (steps) that the Integration Server will execute at run time. Coupled with Developer’s easy‐to‐use graphical interface and its drag‐and‐drop data mapping capability, flow allows you to quickly develop integration logic without low‐level coding. Note: Although you can implement most integration solutions using flow and the Integration Server’s library of built‐in services, you can also build services using Java, C/C++, or Visual Basic (or any other COM/DCOM‐based component) if your solution requires specialized integration logic that webMethods does not provide out of the box. Apart from providing tools for constructing services, Developer provides additional editors and tools for creating various elements that support the execution of an integration solution. For example, you use Developer to create the document types and schemas used for data validation and to define triggers that launch the execution of services when certain documents are published.


35


Developer also provides specialized editors for creating logic for specific run‐time components and facilities. For example, it supplies the tools you use to create: Adapter services. Services that invoke specific processes on a back‐end resource (for example, query an customer database, post a journal entry to a general ledger application, or delete an item from an inventory system). Adapter notifications. Alerts that back‐end systems issue to initiate an action. Web Services Definition Language (WSDL) documents. Interface definitions that expose services on the Integration Server to external clients as Web services. Web service connectors. Proxy services that allow Web services located on remote servers to be invoked. Transaction definitions. Interface definitions used to submit transactions to a mainframe computer. Host connection pools. Parameters that define how to connect to and interact with a particular application region on the mainframe (IMS or CICS). Flat file schemas. Metadata that define how to parse and validate the contents of flat files for use by back‐end systems. To Learn More: See the webMethods Developer User’s Guide, the webMethods Integration Server Built‐In Services Reference, the Web Services Developer’s Guide, the webMethods Mainframe Developer’s Guide, the Flat File Schema Developer’s Guide, and the adapter user’s guides.

webMethods Trading Networks Console webMethods Trading Networks Console is the tool you use to configure the Trading Networks component. You use Trading Networks Console to define partner profiles, Trading Networks document types, and processing rules. A partner profile provides specific information about a particular trading partner. The profile encompasses both technical information (for example, connection information, such as an HTTP port number) and business‐level information (for example, payment terms). A Trading Networks document type describes a particular type of business document that you want to exchange with your trading partners. It can specify an industry‐ standard type like those defined by cXML, CBL, OAG, and EDI or a customized business document. A processing rule specifies how a particular type of document is to be processed. For example, the processing rule for a purchase order might tell Trading Networks to verify the sender’s signature and then submit it to your order‐management system. These elements direct the operation of the Trading Networks run‐time component. They are the building blocks you use to link to external partners (buyers, suppliers, strategic

36



partners) and marketplaces. For information about the Trading Networks run‐time component, see “webMethods Trading Networks and eStandard Modules” on page 25. To Learn More: See webMethods Trading Networks Concepts Guide, webMethods Trading Networks User’s Guide, webMethods Trading Networks Built‐In Services Reference, and webMethods Trading Networks Web Manager Administrator’s Guide.

webMethods Portal Portlet Developer webMethods Portal provides a framework called the portlet controller that helps to create portlets with multiple pages and actions. The framework consists of run‐time, base portlet classes, declaration in the portlet descriptor, JSP tag library, and the Portlet Developer plug‐in to the Eclipse IDE. A portlet is a key component of the portal framework. A portlet is a server‐side, mini‐ application that resides on the Portal server or a piece of functionality that runs on the back end of the Portal server. A portlet may or may not have a user interface (UI). Architecturally, a portlet is made up of JSP files, XML files, Java classes, and other UI components. All of the UI components within webMethods Portal exist as portlets. The portlet controller introduces two main concepts: portlet layout and portlet method. In a JSP‐based portlet, the portlet layout is a JSP and the metadata associated with it. A portlet method is an actual Java method defined in the portlet bean class plus the metadata about it. You can think of the multi‐page portlet as a small Web application with a navigation model, state, and supported actions. This small Web application can be built using a collection of portlet layouts, methods, and a navigation logic. Some common navigation models are supported by the Portlet Developer: Wizard. The portlet has one or more layouts that the user can step through sequentially. At the end of the sequence, some final action is typically performed, based on the data collected on all pages. Tabs. The portlet has one or more independent layouts. At the top of each layout there is a tab control that displays one tab for each portlet layout. Clicking the tab makes the corresponding layout active. For an example of a tabs portlet, log on to Introduction to webMethods Fabric as the portal administrator and navigate as follows: A portlet is not limited to a single navigation model. Deploying portlets in your Portal server provides a way to bring together disparate data sources, such as XML, Web services, SQL data sources, back‐end systems, enterprise applications, and information stored in the Portal server. To Learn More: See the webMethods Portal Design Guide.


37


Administrative and Monitoring Components You use the following components to configure, monitor, and manage running resources and processes connected to the integration backbone. webMethods Administrator webMethods Manager Console webMethods Monitor webMethods Optimize webMethods Portal Administration Dashboard

webMethods Administrator webMethods Administrator allows you to configure and administer all your webMethods servers with a single, browser‐based interface. It allows access to the administrative interfaces for webMethods servers (for example, the administrative interfaces for the Integration Server, the webMethods Mainframe component, and the webMethods Broker). webMethods Administrator

webMethods Administrator is hosted on an Integration Server. When you connect to it with a browser, it displays a set of links to the administrative interfaces for your various webMethods servers.

38


Administrative and Monitoring Components

The Administrator’s interface is customizable. You can add links, remove links, or group links into folders. You can also configure the Administrator to display different links for different administrators. For example, your network administrator might require links to all of the webMethods servers in your enterprise, but an administrator of a development system might need links only to those servers that he or she is responsible for maintaining. The Administrator does not prevent you from accessing a server’s administrative interface directly. You can continue to open a server’s administrative interface by pointing your browser directly at that server. However, if you are using several webMethods servers, the Administrator provides you with a convenient, central interface from which to manage them. To Learn More: See the webMethods Administrator User’s Guide.

webMethods Manager Console webMethods Manager is a systems management facility based on the Open Management Interface (OMI). OMI is a programmatic interface that enables systems management applications to access and manage resources. It was jointly developed by webMethods and Hewlett‐Packard and is based on the open standards of XML, SOAP, and HTTP. webMethods Manager is made up of two pieces: Manager Console and Manager Server. Manager Console is described below. For more information about Manager Server, see “webMethods Manager Server” on page 28. Manager Console is an OMI‐compliant systems management console that you can use to manage your webMethods components. It provides a central point from which to monitor, control, and analyze an entire integration backbone. With Manager Console, for example, you can monitor message queues on the Broker, view the error log on the Integration Server, and detect business process outages. Manager Console also provides analytical tools to examine statistics captured by managed objects and generate alerts based on thresholds that you specify. For example, you might configure Manager Console to issue an alert when a particular queue grows larger than 100 documents. If your organization uses a systems management tool to manage its IT infrastructure, and that tool is OMI‐compliant, you can manage the integration backbone with your existing tool instead of, or in addition to, using Manager Console. (HP OpenView, CA Unicenter, and PATROL from BMC Software are examples of OMI‐compliant management tools.) By linking webMethods Manager to your existing system management tool, you can monitor and manage the resources of the integration backbone (including business processes that run on it) along with the other systems and applications in your enterprise. This approach provides a comprehensive view of your entire IT infrastructure. If a business process fails, an operator or administrator can more quickly determine, for example, whether the failure was caused by an adapter or an application on a back‐end system. Additionally, linking the integration backbone to your existing system management tool provides a global vantage point from which you can evaluate the performance of your entire IT infrastructure. It enables you to know, for example,


39


whether a particular business process might be improved by tuning the software, hardware, or network on which that process is running. To Learn More: See the webMethods Optimize and Manager Console User’s Guide and the webMethods Optimize and Manager Console Administrator’s Guide.

webMethods Monitor webMethods Monitor is an administrative tool that you use to examine instances of business processes, workflows, services, 4.x Enterprise adapter integrations, and documents that are being processing or that are finished being processed. Besides viewing status information about your processes, workflows, services, 4.x activations, and documents, you can use Monitor to perform control tasks such as suspending or resuming business processes or editing and resubmitting a document. webMethods Monitor retrieves information about processes, workflows, services, 4.x activations, and documents by querying the logging database. The logging database maintains a permanent record of certain types of activity, as follows: Processes and workflows that are running or have finished running. In addition to maintaining the overall status of a process or workflow (for example, whether the process or workflow is currently running or completed), the logging database maintains specific details about the services, workflow tasks, and documents that make up the individual steps. Services that you elect to audit. When you create a service, you specify whether it should generate log entries. You can elect to generate log entries when a service starts and when the service completes successfully or fails. You can also opt to include the input data for the service with the log entry, as well as user‐defined messages and user‐ specified data field values. 4.x activations. When you create a 4.x Enterprise adapter integration, you specify whether it should generate log entries. You can elect to generate log entries when a 4.x activation starts and when it completes successfully or fails. You can also opt to log the document that triggered the activation, as well as user‐defined messages and user‐specified data field values. Documents that you elect to log. You can configure the Broker to store certain types of documents in the logging database when they are published. For example, you might configure Broker to save a copy of every purchase order that is published. Similarly, you can instruct Trading Networks to log a copy of certain documents that your trading partners submit. To Learn More: See the webMethods Monitor User’s Guide.

webMethods Optimize webMethods Optimize provides visibility and control of IT operations, business processes, and transactions for real‐time decision‐making and leverages webMethods

40


Administrative and Monitoring Components

Fabric to achieve business activity monitoring (BAM): event management, alerts, root cause analysis, learning, prediction, and recommendations. By combining real‐time information and business event analysis, webMethods Optimize quickly and effectively identifies conditions that require immediate action, enhancing business operations through continuous process improvement. It monitors business processes by tracking key performance indicators (KPIs) that relate to operational factors such as margin, revenue, customer satisfaction, and inventory levels. webMethods Optimize compares actual performance to rules you establish. If a monitored item goes out of compliance with a rule, Manager Console and Optimize alert you so you can address the problem. Features of webMethods Optimize include: Automatic threshold generation that results from analyzing performance at regular intervals and learning what the normal performance thresholds are. Performance‐based alerts that are sent when performance violates user‐defined rules. Problem predictions generated by analyzing historic performance data during problem periods and comparing it to real‐time performance data. Six Sigma compatibility that enables you to perform Six Sigma analysis of your data so you can identify and eliminate defects in your business processed. To Learn More: See the webMethods Optimize and Manager Console User’s Guide and the webMethods Optimize and Manager Console Administrator’s Guide.

webMethods Portal Administration Dashboard As stated in “webMethods Portal” on page 29, webMethods Portal is a component that provides a powerful framework for rapid composite application assembly. The webMethods Portal Administration Dashboard allows portal administrators to efficiently manage their portal deployments. It also delivers a powerful framework that allows portal administrators to selectively delegate specific administrative functions to other administrators or IT staff. The Administration Dashboard provides one‐stop access to the following administrative tasks that you can perform for your portal deployment: Analyze portal usage patterns to optimize portal performance View log files for troubleshooting Manage the look‐and‐feel of your portal deployment Manage portal users and delegated administrators, for example, grant users access to information included in the portal deployment To Learn More: See the webMethods Portal Administrator’s Guide.


41


42


CHAPTER

3

Key Concepts, Features, and Capabilities Business Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Monitoring and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


43

CHAPTER 3 Key Concepts, Features, and Capabilities

Business Integration Business integration creates information systems by connecting all the disparate IT elements of the enterprise. The basic building blocks of business integration are documents and services.

Documents Documents are objects that you use to encapsulate and exchange data among the participating resources and systems in an integration solution. Documents provide the data on which services and workflows operate. In a general sense, a document represents the body of data that a resource passes to webMethods components (or vice versa). Often, it represents a business event such as placing an order (a purchase order document), shipping goods (a shipping notice), or adding a new employee (a new employee record). However, a document can also simply represent an arbitrary set of parameters that a particular procedure takes as input or produces as output. For example, a service that performs a database query requires a ‘document’ that contains a query statement. This service would produce a ‘document’ containing the results of the query. webMethods components accept documents in a variety of formats. An external trading partner, for example, might submit purchase orders and invoices in XML, EDI, binary, or flat file format. Moreover, back‐end systems and applications typically produce documents (results of procedures that you invoke) in proprietary formats that are associated with their particular APIs. After the documents are received, they are converted to an internal format that webMethods components act upon. A document remains in this internal format as it travels through the integration backbone (for example, from Integration Server to Broker to Workflow Server). If the document must be sent to a particular back‐end application or system, an adapter automatically encodes the document in the format that the resource requires. Documents are usually associated with a document type. A document type is a named schema‐like definition that describes the structure of a particular kind of document. You might, for example, create a document type named ShipNotice that describes the structure of a shipping notice, or a document type named EmpRec that describes the layout of an employee record. webMethods components can use document types to validate instances of documents at run time. Document types also play a key role in a pub/sub solution, because they determine how a document is routed. For example, if a component publishes a document of type EmpRec, that document is distributed to (that is, it is queued for) subscribers of document type EmpRec. To Learn More: See the webMethods Developer User’s Guide and Publish‐Subscribe Developer’s Guide.

44


Business Integration

Services Services are method‐like units of logic that operate on documents. They are executed by the Integration Server. You build services to carry out work such as extracting data from documents, interacting with back‐end resources (for example, submitting a query to a database or executing a transaction on a mainframe computer), and publishing documents to the Broker. The Integration Server is installed with an extensive library of built‐in services for performing common integration tasks. Adapters and other add‐on packages provide additional services that you use to interact with specific resources or applications. webMethods graphical implementation language, flow, enables you to quickly aggregate services into powerful sequences called flow services. Because systems rarely produce data in the exact format that other systems need, you commonly need to build flow services to perform data transformation. Data transformation resolves differences in the way data is represented within documents that applications and systems exchange. With Developer, you can specify the following types of transformations: Name transformations. This type of transformation resolves differences in the way elements are named (for example, when one system uses the name telephone to represent a phone number and another uses the name phoneNumber). Structural transformations. This type of transformation resolves differences in the data types used to represent elements in a document (for example, when one system encodes a phone number as a simple, top‐level element named telephone and another nests the phone number in a record‐like structure named CustomerInfo). Value transformations. This type of transformation resolves differences in the way values are expressed (for example, when systems use different notations for values such as standard codes, units of currency, dates, or weights and measures). Services operate on documents that are represented in the webMethods internal document format. A service takes a document as input and produces a document as output. The elements a service expects to find in the input document it receives and the elements it produces in its output document are collectively referred to as the service’s signature.

Web Services Web services expose logic to clients using Internet standards such as Web Service Definition Language (WSDL) and Simple Object Access Protocol (SOAP). webMethods provides out‐of‐the‐box support for Web services from both the Web service provider and Web service consumer perspectives. As a Web service provider, the Integration Server can expose any of its services as a Web service. This simple but powerful capability enables you to extend the existing data and logic on your back‐end resources to any Web service‐compliant client inside or outside the enterprise.


45


As a Web service consumer, the Integration Server can invoke a Web service anywhere on the Internet (or your intranet). This feature enables you to easily incorporate a third‐party process, such as a credit authorizer or package tracker, into an integration solution. In addition, webMethods provides Web service management through Servicenet. Servicenet provides a container‐independent view of an organization’s Web services and tracks detailed performance metrics on which users can be alerted. It also acts as a single security model that can enforce security standards on services that do not have inherent security. To Learn More: See the Web Services Developer’s Guide and the webMethods Servicenet User’s Guide.

Management For many organizations, a true business solution involves more than simply linking disparate IT assets. It involves creating and implementing complex business processes and human tasks and interactions. Basic building blocks of business process management are human workflows and process modeling.

Workflows Workflows describe the human tasks incorporated into business processes. They identify who preforms a task, when the task is performed, and how the task relates to other tasks or automated operations in the business process. In addition to planning the human tasks and incorporating them into business processes, you must be able to address unique situations, handle emergencies, and track the progress of the various tasks. Using webMethods Workflow, business users can create sophisticated, multi‐step workflows that include both people and applications. Within these workflows, designers can create tasks to represent user interaction with the system, define business rules, and control the flow of steps throughout the overall integration system. webMethods Workflow provides: Graphically designed workflows Time‐based management of information Capacity to create user interfaces Project management features Integration with existing applications Seamless integration with webMethods Modeler To Learn More: See the webMethods Workflow Concepts Guide and the webMethods Workflow User’s Guide.

46


Management

Processes A process is an orchestrated sequence of steps among systems, people, and trading partners. A step in a process represents: A unit of work performed by a service (integration logic executed by the Integration Server). Human interaction defined by a task (a single manual step) or workflow (a sequence of manual steps) on a Workflow Server. A call to or from a Web service. An out‐of‐process activity that is performed by a trading partner or other external entity that consumes or produces documents at execution time. The steps in a process interact through the asynchronous exchange of transition documents; they do not call one another directly. When a step in a multi‐step process completes, it publishes a transition document containing its results. This action causes the next step in the process, which is a subscriber of the transition document, to execute. You define a process using webMethods Modeler. This tool produces a process model that specifies the sequence of steps in a process. Modeler stores process models in a central repository that maintains information about all the processes you define. Process model in Modeler


47


webMethods provides a process run‐time facility that manages the execution of a process. This facility is made up of a process run‐time engine (sometimes referred to simply as process run time) that resides on each Integration Server. A server uses its process run‐time engine to manage the execution of its fragment of a process. For example, when the process run‐time engine on an Integration Server receives a transition document, it logs the beginning of the step, invokes the service for that step, and logs the completion of the step when the service finishes. If there are subsequent steps in the process, the process run‐time publishes the appropriate transition document, which is then received and processed by the process run‐time on the server that has the next step. The status of an instance of a process is maintained in an audit log. You can view and manage (suspend, restart, and so forth) a process instance using webMethods Monitor. If you are using webMethods Manager, you can also monitor processes for failures and outages. To Learn More: See the webMethods Modeler User’s Guide, Getting Started with Business Process Management, and the webMethods Monitor User’s Guide.

Monitoring and Optimization As organizations place increasing emphasis on improving how they deliver their goods and services, they need real‐time performance measurements for proactive management and optimization at every step. Key concepts of business activity monitoring are key performance indicators, rules, system monitoring, and business monitoring.

Key Performance Indicators System and business data is monitored via key performance indicators (KPIs). KPIs are quantifiable measurements that reflect the critical success factors of an organization. KPIs monitor data for exceptions and trends and help you answer questions such as: How many orders over $10,000 are stuck in this process? Which orders are for customer X? What is the revenue for the Southeast Region? What is the queue length for this operating system? For example, in an order management process, you might define KPIs for how many orders were received, their dollar amounts, and whether they were processed successfully. You can also define KPIs that compare volume by order channel or cycle time by customer type.

48


Monitoring and Optimization

In Manager Console and Optimize, KPIs consist of the following: Dimensions, such as customer, region, dealer, or sales person. Event maps, which associate business data, such as dimensions, with a particular business process. Facts, which are measurable values, such as revenue or queue length, that are used for calculation or analysis. KPI definitions, which associate a fact with a dimension, such as revenue by region or queue length by host KPI hierarchies, which determine how dimensions are related. Manager Console uses these relationships to aggregate and organize data on My webMethods business process and system monitoring pages.

Rules Manager Console and Optimize evaluate data against rules you define. A rule specifies conditions under which a process or resource becomes problematic and requires user attention. You can define KPI rules, event rules, and threshold rules. When you define a rule, you identify the type of data to which to apply the rule (for example, Broker queue length). During rule definition, you also indicate whether you want to create fingerprints for the rule (KPI rules only), identify the users to whom to send alerts when the rule is violated, and specify other actions to perform when a rule violation occurs (for example, send an SNMP alert to an SNMP manager or invoke a Web service).

System Monitoring System monitoring focuses on monitoring the performance of your webMethods components. The system monitoring application must know what components are deployed into the environment, what data points to collect and analyze, and how to respond to abnormal operating conditions. webMethods Manager searches your environment to identify the webMethods components you have installed and running. It is pre‐configured with KPIs to collect specific data for those components. It also supports user‐defined KPIs so you can tailor webMethods Manager to meet your needs. webMethods Manager Server monitors the system and operational data associated with webMethods run‐time components, such as Integration Servers, Broker Servers, Brokers, and adapters and reports the status of these components on webMethods Manager Console.


49


Manager Console indicates out of compliance conditions

webMethods Manager Console enables you to access the resource information maintained by Manager Server. It allows you to monitor the status of individual managed objects as well as the overall status of your system, and it provides alerting capabilities to ensure that you know immediately when a problem condition exists. To Learn More: See the webMethods Optimize and Manager Console User’s Guide the webMethods Optimize and Manager Console Administrator’s Guide, and the webMethods Manager Server Administrator’s Guide.

Business Monitoring While system monitoring helps track and maintain the health of your deployed assets, business monitoring shows you the health of your business processes, including all automated and human interactions. True business process monitoring provides real‐time data to ensure that you know the state of your business processes at all time. It can also provide predictive capabilities that indicate that a problem could develop, allowing to you respond and prevent business process failures before they occur. webMethods Optimize enables you to monitor business processes developed with webMethods Business Process Management tools and business processes developed with external tools. Using a sophisticated collection of KPIs, user‐defined rules, and alerts, Optimize collects, analyzes, and displays performance data for your business processes. It maintains a history of analysis results that it compares to real‐time data to quickly identify potential problems in a business process, enabling a timely, preventative response.

50


Accessibility

Optimize reports on a process

To Learn More: See the webMethods Optimize and Manager Console User’s Guide and the webMethods Optimize and Manager Console Administrator’s Guide.

Accessibility A complete integration solution requires access points for managers, business analysts, and other users. Providing one entry point to multiple components enables a holistic view of your enterprise. Organizing information and functionality logically rather than by component improves user effectiveness and productivity. Enabling user, group, and role‐based access protects sensitive data. Key elements of accessibility are task‐based entry points and customization.


51


Task-Based User Interfaces A task‐based user interface provides views and capabilities based on tasks that are more closely aligned with users and roles than with specific components in your environment. My webMethods offers task‐based views of your enterprise. It provides these functional tasks for administrative and monitoring components: Task

Description

Components

Business Monitoring

Use to monitor information associated with business processes.

Monitor Optimize Workflow

System Monitoring

Use to monitor the operational data associated with webMethods components such as Integration Servers, Broker Servers, Brokers, and adapters.

Manager Console Optimize

Integration Monitoring

Use to monitor activations, services, and documents that are associated with your integration solutions.

Monitor

Web Services Management

Use to manage your Web services.

Servicenet

Rule Administration

Use to manage KPI, event, and threshold rules.

Manager Console Optimize

User Administration

Use this functional task to manage users, groups, and roles.

Manager Console Monitor Optimize Servicenet Workflow

Data Management

Use to archive and delete logging data from Process Audit Log database.

Monitor

webMethods Configuration

Use to view the status of Manager Console and Optimize controllers, data handlers, and satellites. Also use to configure server locations, data filters, KPIs and business processes.

Manager Console Monitor Optimize

To Learn More: See Getting Started with My webMethods.

52


Security

Customizable Interfaces In addition to the My webMethods user interfaces that provide out‐of‐the‐box views of your environment, you can create custom interfaces to match your specific business needs. webMethods Access combines the My webMethods Server and the Portlet Developer to offer an interface design environment. You can build custom composite application frameworks and extend the capabilities of My webMethods with powerful visual design and development tools, a sophisticated user management system, advanced personalization capabilities, role‐based security, and out‐of‐box document management and collaboration systems. To Learn More: See the webMethods Access Documentation Supplement the webMethods Portal Administrator’s Guide, and the webMethods Portal Design Guide.

Security Security is a critical aspect of any networked environment. webMethods offers a range of protective features that you can tailor to suit the security needs of your installation. These features include perimeter defenses such as authentication and firewall protections. They also include mechanisms for protecting data that travels over the network and ways to assure the validity of documents that your business sends and receives.

Securing Access to the Integration Server As webMethods primary outward‐facing component, the Integration Server provides strong security protections for access control, authentication, and data privacy. Access Control. The Integration Server provides access control at multiple levels of granularity. At the broadest level are the port controls. These access controls allow you to configure the server’s listening ports to only accept requests from specified addresses or domains. They also allow you to restrict which resources are accessible through an individual port. At the finest level are the resource controls. These controls let you restrict access to individual resources on the server (to specific services, for example). You establish this type of control using access control lists (ACL). An ACL specifies which groups of users are authorized to use a resource. When the Integration Server executes a service, it first determines whether the client requesting the service belongs to the service’s ACL. If the client is not a member of the ACL, the Integration Server rejects the request.


53


Authentication. The Integration Server supports standard user name/password authentication over HTTP, HTTPS, FTP, and e‐mail connections. If your site uses either Lightweight Directory Access Protocol (LDAP) or Network Information Service (NIS) for user and group information, you can configure the Integration Server to authenticate clients against one of those directories. For an authentication system that is not supported out of the box (such as a custom‐built system or a system such as Kerberos) you can build and install a plug‐in module that enables the Integration Server to work with that system. For HTTPS connections, the Integration Server authenticates clients using X.509 v3 digital certificates. Depending on your security policy, you can configure the server to “request” or “require” certificates on a port‐by‐port basis. When a port requires certificates, the server rejects any request that is not accompanied by a certificate. When a port requests certificates, the server reverts to user name/password authentication if a client does not provide a certificate. Data privacy. Data exchanged over the Integration Server’s secure sockets layer (SSL) is protected during transport with data encryption. The Integration Server supports 1024‐ or 2048‐bit public keys and 128‐bit private keys for maximum protection. You may optionally use SSL accelerators such as nCipher’s nFast or nForce products to reduce the performance burden incurred by using SSL. Additionally, the Integration Server supports the exchange of digitally signed documents. A digital signature identifies and authenticates the document’s originator. Moreover, it ensures that only the intended parties can read a document and it prevents a document from being tampered with once it has been signed. The Integration Server supports the S/MIME and PKCS #7 standards for digital signatures. It provides services for signing documents that you want to exchange with other parties and for validating the signatures on documents that you receive. This functionality is also built into many webMethods e‐commerce components such as Trading Networks and the RosettaNet Module.

Securing Behind Your Firewall Most enterprises shield their internal systems from direct Internet access through a system of inner and outer firewalls. Between the firewalls, in what is called the demilitarized zone (DMZ), they place servers that process requests from the Internet. Depending on your specific firewall configuration and the security policies in place at your enterprise, you can deploy the Integration Server in a number of possible configurations within or behind the DMZ. For example, you can deploy the Integration Server in the DMZ and then configure the inner firewall to permit traffic to flow between that server and the other webMethods components. Or you might deploy the Integration Server behind the inner firewall and use a reverse proxy server in the DMZ to pass requests back to the Integration Server. Both of these configurations require punching a ‘hole’ in the inner firewall for inbound Internet traffic. Most security administrators want to minimize the number of holes in the inner firewall because they represent potential avenues of entry for attackers.

54


Security

To eliminate this exposure, you can deploy the Integration Server in a unique reverse‐ invoke configuration. In this configuration, you deploy two Integration Servers. One server sits in the DMZ and is called the reverse invoke server. The other sits behind the inner firewall and is called the internal server. Reverse invoke configuration Outer Firewall

Inner Firewall

DMZ

proprietary

Reverse Invoke Server

protocol

Internal Integration Server

Under a reverse invoke configuration, the reverse invoke server receives requests from the Internet (which have been filtered by the outer firewall) and passes those requests back to the internal server through a reserved port using a secure, proprietary protocol. This eliminates the need to open a hole in the inner‐firewall for inbound Internet traffic.

Securing the Other Components As the primary entry point, the Integration Server provides several layers of security. Other webMethods components provide additional security features relating to the particular role they serve. For example, the Broker uses certificates to authenticate its client requests. You tailor the security features of the other webMethods components to meet the needs of your enterprise. To Learn More: See the webMethods Integration Server Administrator’s Guide and the webMethods Security Best Practices documents available for specific components.


55


Scalability webMethods flexible architecture allows you to scale smoothly to support global deployments and enterprise‐level transaction volumes. This extensible design allows you to deploy an integration backbone incrementally, adding components when and where they are needed. For example, you might start with a basic department‐level solution consisting of an Integration Server that links two back‐end systems. As your needs grow, you extend the integration backbone by deploying additional Integration Servers and Workflow Servers, tying them together with a messaging backbone made up of one or more Brokers. Flexible distributed architecture allows the integration backbone to extend easily

WS MF TN

IS

IS

Broker

IS

IS

IS

Broker

IS

IS

Broker

IS

WS

webMethods flexible architecture can also be selectively bolstered in areas of high traffic. By deploying components in clustered configurations and territories, you can eliminate performance bottlenecks and streamline the overall workload.

56


Scalability

Clustered Configurations Clustering allows a group of Integration Servers to act as a single entity. A clustered configuration increases throughput and improves performance by distributing requests among a group of servers. When Integration Servers operate in a cluster, clients submit their requests to a server in the cluster. When the request is received, it is automatically directed to a server in the cluster using either a least‐recently‐used or fewest‐pending‐ requests technique, depending on how the cluster is configured. Because this activity is transparent to the client, clustering makes multiple Integration Servers look and behave as one. For example, a high‐volume database solution might overwhelm a single Integration Server. But a clustered configuration can execute multiple requests simultaneously, thereby boosting performance and throughput significantly. Besides the built‐in clustering capability that the Integration Server provides, you can also use third‐party load balancers such as Cisco’s Local Director. External hardware‐based products like this can provide high‐performance load balancing using algorithms that are based on network metrics.

Territories To increase the messaging facility capacity, you deploy multiple Brokers in a distributed configuration called a territory. A territory disperses the overall message load across multiple Brokers. Brokers within a territory appear as a single entity for development and administrative purposes even though they each have their own set of direct clients (that is, Integration Servers and Workflow Servers) and might themselves be distributed across departmental or geographic boundaries. The Brokers in a territory share knowledge of document types and subscriptions. When a client publishes a document to a Broker, the Broker checks whether clients of other Brokers in the territory subscribe to the document. If so, the Broker distributes the document to those Brokers. The distribution of documents among Brokers in a territory is completely transparent to the publishing client. A publisher has no knowledge of other Brokers in the territory. It simply publishes a document to its local Broker, and the local Broker does the work of distributing it to the appropriate Brokers in the territory.


57


Tuning Performance of Individual Components webMethods components are individually designed for high performance and enterprise‐ level traffic volumes. For example, the Integration Server supports scalability with a highly threaded run‐time environment that allows multiple instances of a service to execute in the same process space. Furthermore, it allows you to cache results of selected services in memory, which eliminates the need for a service to re‐execute if the Integration Server receives a series of identical client requests. The Broker and the Integration Server also provide memory‐based and disk‐based document queuing options. These options enable you to tune run‐time performance by logging only critical documents to persistent storage, while relegating non‐critical documents to faster memory‐based queues. Other run‐time components offer similar controls for optimizing performance. To Learn More: See the webMethods Integration Server Administrator’s Guide, the webMethods Integration Server Clustering Guide, and the webMethods Broker Administrator’s Guide.

Reliability Due to webMethods distributed architecture and support for clustered components, availability and fault tolerance are assured. The distributed architecture eliminates the single‐point‐of‐failure liability associated with pure hub‐and‐spoke systems. It lets you distribute work across multiple components so that the failure of a single component (such as the failure of a Broker or an Integration Server) affects only the clients associated with that component. Other webMethods components and their clients continue to operate. Any documents generated for the failed component are queued to be delivered once the component becomes available. To further insulate from the effects of a component failure, you can deploy key components redundantly, in clustered and high‐availability configurations. By clustering the Integration Servers as described in “Clustered Configurations” on page 57 you not only increase its speed, you increase its reliability as well. If one Integration Server in the cluster fails or must be taken down for maintenance, the remaining servers in the cluster can continue processing client requests. Alternatively, for critical solutions that demand automatic fault detection and fail‐over mechanisms, you can deploy Integration Server and Broker components in high‐ availability configurations using third‐party, fault‐tolerant servers and clusters of high‐ availability hardware. Using management agents, these products continuously monitor the equipment on which a component runs and, if a failure occurs, will automatically swap the component and its active processes to a backup node. For example, when the Broker is deployed in a high‐availability configuration, it typically runs on a primary node in a cluster. In the case of a failure, a backup Broker is automatically started on a secondary node, and state information (including in‐progress documents) is migrated to the backup Broker. The reconnect capability built into

58


Reliability

webMethods network protocol allows Broker clients to automatically re‐establish sessions with the backup server and continue processing. To Learn More: See the webMethods Integration Server Clustering Guide, the webMethods Broker High Availability Option for HP‐UX MC/ServiceGuard Cluster Installation Guide, the webMethods Broker High Availability Option for Sun Cluster 3.1 Installation Guide, the webMethods Broker High Availability Option for Windows NT and Windows 2000 Cluster Installation Guide, the webMethods Broker High Availability Option for VERITAS Cluster for Solaris 3.5 Installation Guide, and the webMethods Broker High Availability Option for AIX HACMP 4.4.x and 4.5.x Installation Guide. Contact a webMethods representative to receive the Broker documents.


59


60


CHAPTER

4

Common Solutions Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Exchanging Documents with Business Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Synchronizing Information Across the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Automating a Multi-Step Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


61

CHAPTER 4 Common Solutions

Overview This chapter provides examples of ways you can implement webMethods components to solve common business problems. These examples illustrate many of the capabilities of webMethods components and describe how you would combine the various components to achieve a particular solution.

Exchanging Documents with Business Partners The following example illustrates how you might use webMethods components to streamline interactions between your enterprise and its external business partners.

The Business Problem Three large customers have asked your company to begin accepting electronic purchase orders that are generated by their purchasing systems. Customer A will submit purchase orders using the EDI protocol. Customer B will submit orders via HTTP in a custom XML document format. Customer C will batch orders into a flat file and send the file to you via FTP. The customers also require: Acknowledgments when a purchase order has been successfully received by your company. E‐mail notification when an order cannot be accepted. Assurance that purchase orders are permanently logged on your system exactly as they are received. Assurance that your system will not accept the same purchase order twice. Your company wants to integrate this new ‘pipe’ for incoming orders with your existing order management system, which will continue to accept orders through the existing channels (telephone, e‐mail, fax). Additionally, your company wants to streamline the process of getting new orders into the production database by replacing the current e‐mail‐based mechanism with an automatic process that updates the production database when a new order is added to the order‐management system.

62


Exchanging Documents with Business Partners

The Integration Solution The integration solution for this type of business problem would consist of two functional pieces: An outward‐facing piece that uses the Trading Networks component to interact with the business partners. A back‐end piece that uses the adapter components to interact with the order‐ management and production applications inside the enterprise. These two pieces interact through the messaging facility. Solution is made up of two functional pieces that interact through the messaging facility Outward-Facing Piece

Back-End Piece

Adapter Trading Networks

Order-Mgmt System

Broker Production Database

Adapter

In this solution, the Trading Networks piece serves as the gateway between the systems within your enterprise and those of your business partners. It acts as the central ‘inbox’ for the purchase orders that your customers will submit. Note: Because Customer A will submit its orders in EDI format, the Integration Server on which Trading Networks is installed must be equipped with the webMethods EDI Module. The XML and flat‐file formats that the other partners will use are supported out of the box. At run time, the Trading Networks portion of the solution will: Receive the purchase orders that the partners submit. Write the purchase orders into a permanent message log to maintain an audit‐trail of the documents it receives. Execute specified ‘screening’ steps such as verifying digital signatures and validating document structure and content.


63


Transform the purchase orders from the various customer formats to the standard document structure that your enterprise uses to represent a new order. (This is generally referred to as the document’s canonical form.) Publish the new orders to the messaging facility, making them available to the back‐ end components that consume order documents. Return an order receipt document to the customer when the order is successfully published. Return an e‐mail notification to a specified contact when an order cannot be processed. The back‐end piece of this solution uses adapter components to interact with the order‐ management and production applications inside the enterprise. This interaction is achieved through adapter services that you build to perform specific tasks, such as adding an order to the order‐management system. In this example, the adapter services are tied to triggers that cause them to execute automatically when certain types of documents are published. (A trigger creates a subscription to a specified document type.) At run time, this portion of the solution will: Submit the order documents (published by Trading Networks) to the order‐ management system. Publish an order confirmation when a new order is successfully added or an order error if the order is declined or cannot otherwise be processed. Update the production database when an order confirmation is published. When the adapter for the order‐management system publishes an order confirmation or an order rejection, Trading Networks routes the document to the customer using the appropriate transport and document format. The following diagram shows the flow of a successfully placed order.

64


Exchanging Documents with Business Partners

The flow of an order from a trading partner

Subscribes to order 2 1

Trading Networks 4b

Subscribes to order confirmation

3

Broker

Publishes order

4a

Adapter For Order-Mgmt System

Publishes order confirmation

Subscribes to order confirmation

Adapter For Production Database

Note: This particular example illustrates an asynchronous solution that uses the publish‐ and‐subscribe model to link the Trading Networks piece to the back‐end systems. You could also implement a synchronous solution in which Trading Networks invokes the adapter services directly.

General Design and Development Steps To implement this solution, you would perform the following general steps: 1

Use Trading Networks Console to register the three business partners on the Trading Networks component by creating a profile for each partner.

2

Use Trading Networks Console to specify how Trading Networks will recognize the three different styles of purchase orders that your trading partners will submit.

3

Use Trading Networks Console to create a processing rule for each purchase order style. Each processing rule will specify: Any pre‐processing steps (for example, signature verification and content validation) that are to be performed on the purchase order. The service that will process the purchase order.

4

Use Developer to build the services that will process the purchase orders (that is, build the services that the processing rules point to). For this solution, the services will convert an incoming purchase order to a canonical order document and then publish the order document to the messaging facility.

5

Use Developer to create an adapter notification that monitors the order database and automatically publishes an order confirmation document when a new order is placed.


65


6

Use Developer to build the services that will process the documents that this solution publishes. For this solution, you would build services to do the following: Add an order to the order system and publish an order error if the order is not processed successfully. Update the production system when an order confirmation is published. Submit order confirmations and order errors to the Trading Networks component for distribution to trading partners.

7

Use Developer to create triggers that will cause the appropriate service (created above) to execute when an order, order confirmation, or order error document is published.

Deployment Considerations The way in which you might deploy this solution would depend on factors such as expected volume, geographical location of the back‐end resources, and security policies of your site. For example, you could do any of the following: Deploy all components (Trading Networks and the adapters) on a single Integration Server or cluster of Integration Servers. (Because all components reside on a single Integration Server, this configuration does not require a Broker, although you could choose to include one.) Deploy Trading Networks on an Integration Server, the two adapters on another Integration Server, and deploy a Broker to facilitate messaging between the two servers. Deploy Trading Networks on one Integration Server, the order‐management adapter on a second Integration Server, and the production database adapter on a third Integration Server. This configuration would also require one or more Brokers to facilitate messaging among the three servers. Note: The deployment examples above do not address security considerations. You would generally deploy these configurations behind a DMZ or a reverse‐invoke server. Depending on your needs, webMethods flexible architecture enables you to tailor the configuration to your particular solution and the environment in which it will run.

66


Synchronizing Information Across the Enterprise

Synchronizing Information Across the Enterprise The following example describes how you might use webMethods components to keep information stores across the enterprise up to date by automatically propagating changes from one system to another.

The Business Problem Within your enterprise, each of the following systems maintains information about your customers. The order‐management system in the Sales department. The customer relationship management system (CRM) in the Customer Care organization. A CICS‐based financial system on the mainframe used by the Accounting department. A database application used by the Production and Shipping departments. Currently, customer information is captured by the order‐management system when a new customer places its first order. Each week, the administrator of the order‐ management system exports new customer records and e‐mails them to the administrators of the other applications. When received, each administrator uses his or her own ad hoc process to apply the updates to their respective systems. Some administrators do this more consistently than others. Consequently, transactions are often rejected because a customer has not yet been added to a particular system, resulting in reduced productivity and delays in responding to customer requests. To ensure that the customer base is up to date across all systems, your company wants to automatically update all of its back‐end systems when a new customer places an order.

The Integration Solution The solution for this type of problem (propagating data across two or more systems) uses webMethods adapter components to interact with the various back‐end systems. The adapter components interact with each another via the messaging facility. Because this solution interacts with a system that runs under CICS, it includes the webMethods Mainframe component. This component will act like an ‘adapter’ for the mainframe CICS application.


67


Systems interact through the messaging facility

1 Order-Mgmt System

Adapter

2a

Publishes newCustomer

Subscribes to newCustomer

Adapter


Mainframe Component

Broker

CRM System

2b Adapter

2c


Production Database

CICS-based Accounting Application

To propagate data among systems, this solution implements the publish‐and‐subscribe model. That is, when a customer is added to the order‐management system, the order‐ management adapter publishes a new customer document. The other adapters subscribe to new customer documents and automatically update their respective systems when a new customer document is published. The following describes the flow of work among the systems: An adapter notification monitors the order‐management system and automatically publishes a new customer document when a customer record is added to the database. Adapter services, which subscribe to new customer documents through triggers, update their respective back‐end systems when a new customer document is published.

General Design and Development Steps To implement this solution, you would perform the following general steps:

68

1

Use Developer to create an adapter notification that monitors the order‐management system and publishes a new customer document when a new customer record is successfully inserted into the customer database.

2

Use Developer to create the services that will update the individual back‐end systems.

3

Use Developer to create triggers that will execute the appropriate service (created in step 2) when a new customer document is published.


Synchronizing Information Across the Enterprise

Key Cross-Referencing and Echo Suppression webMethods provides two special tools for data‐propagation solutions: key cross‐referencing and echo suppression. Key cross-referencing is a technique for normalizing the primary keys that participants use to identify records in their databases. In the example above, each back‐end system has a customer database whose primary key is the customer’s account number. However, this account number, or key, is different on each system. Customer A might be known as account ‘123’ in the order management system, ‘ABC’ in the customer‐care system, and ‘XYZ’ in the financial system. If the financial system were to receive a document for account 123, it would not be able to process that document successfully. To solve this problem, participants exchange documents using a standard, intermediate key known as a canonical key. webMethods maintains a key cross‐reference table that correlates canonical keys with their native counterparts. At run time, subscribers and publishers use the built‐in services on the Integration Server to convert canonical keys to and from the native keys of their respective back‐end systems. Echo suppression is a mechanism to suppress redundant, circular updates in multi‐way synchronizations. In a one‐way propagation, such as the one described above, updates flow in only one direction (meaning that a single source system issues the updates and publishes them to one or more subscribers). However, in a multi‐way solution, all participants act as publishers and subscribers. Because participants receive the same documents that they publish, a multi‐way solution must take special steps to prevent a document from being reapplied to the back‐end system on which it originated (that is, to prevent a document from echoing back to its source). With webMethods, echo suppression is accomplished using a technique known as latching. A latch is a switch in the key cross‐reference table that indicates the state of a particular record in a back‐end system. Using a built‐in service on the Integration Server, a participant closes the applicable latch before it publishes an update. Participating subscribers check their respective latches (also with a built‐in service) when they receive a document and act upon it only if the latch is open. For more information about key cross‐referencing and echo suppression, see the Publish‐Subscribe Developer’s Guide.

Deployment Options You can deploy webMethods components for this solution in various configurations. For example, you could: Deploy all the adapters on a single Integration Server or cluster of Integration Servers. This configuration does not require a Broker. —OR— Divide the adapters among two or more Integration Servers. This configuration requires one or more Brokers to facilitate messaging among the adapters. The configuration that works best for your site will depend on factors such as throughput requirements and the geographical location of the back‐end resources.


69


Automating a Multi-Step Business Process The following example describes how you might use webMethods to automate a business process that involves both computer‐based and manual tasks.

The Business Problem When a new employee joins your company, a variety of tasks have to be executed, such as acquiring computer equipment, creating a user account, adding the employee to the payroll and benefits systems, and updating the corporate directory. Currently, this activity is jointly orchestrated by the recruiter in the Human Resources department and by the hiring manager. However, this approach is time consuming and error prone. Hiring managers are not always certain which steps they are required to execute and often do not know how or when to initiate the steps. As a result, new employees are often idle for days waiting for the resources that they need to begin their jobs. Additionally, the process consumes an excessive amount of recruiter and manager time. Your company wants to streamline the process to ensure that new employees have the resources they need to perform their work assignments on their very first day on the job.

The Integration Solution The solution for this type of problem (a complex sequence of tasks executed by various people and computers) is an automated business process that you design and generate with webMethods Modeler. The following diagram shows how the process model for this solution might look.

70


Automating a Multi-Step Business Process

Process model for a new employee

Each icon in the process model represents a unit of work (a step) that is carried out by a service on an Integration Server or a manual series of tasks that is managed by the Workflow component. Here is the general flow of work in this model: 1

The hiring manager initiates the process by selecting the “Start New Hire” task in the Workflow client after a candidate has formally accepted an offer and agreed to a start date. The hiring manager provides information such as start date, equipment requirements, title, and salary. This step produces a document called a New Hire Submittal.

2

A recruiter in the Human Resources department uses the Workflow client to view New Hire Submittals. The recruiter verifies that the information is accurate and enters whatever additional information is needed to establish a record for this employee in the HR database. The recruiter completes this step by either authorizing the submittal, returning it to the hiring manager for revision, or terminating the hiring process.

3

An adapter service adds the new hire to the HR employee database. If this step is successful, a New Employee Notice is generated and the downstream steps are actuated. If not, the submittal is returned to Human Resources for follow‐up. Note: Steps 4 – 6 can occur in parallel.

4

The Integration Server invokes a Web service that submits a work order to the IT department requesting computer equipment and a user account for the new employee.


71


5

An administrator in the Facilities department uses the Workflow client to view the New Employee Notice. To complete this step, the administrator enters the employee’s assigned office address and telephone number, which actuates a service that adds the new employee to the corporate directory.

6

The HR department collects payroll‐withholding and benefit information from the employee on the employee’s first day of work. To complete this step, the recruiter adds this information to the New Hire Submittal, which actuates: A Web service that adds the employee to your company’s payroll service provider. A service that e‐mails enrollment information to the medical/dental benefits provider. A task that tells the Training department to schedule the new employee for orientation training.

Basic Design and Development Steps To implement this solution, one or more Integration Servers, a Broker, and the Workflow component are required. With these components in place, you would perform the general steps described below. Configure webMethods Modeler so that it knows about the Integration Servers and Workflow Servers. Build a model of the process with webMethods Modeler. Generate an implementation of the finished model. This creates the underlying code that propels the process from one step to another at run time. In addition, it creates “stubs” for the services and workflows that will carry out the work for each step. Implement the stub services and workflows by building the integration logic and workflow tasks that will carry out the work of each step at run time. Define roles for the workflow participants and the task views that these participants will use to execute their tasks. Note: This example illustrates the top‐down development approach, where you draw the process model first and insert the logic into the generated stub services and workflows afterwards. You can also use a bottom‐up approach by building the necessary services and workflows first, and then creating a process model whose steps you associate with the services, and workflows that you have already created. Whether you use the top‐down or bottom‐up approach, or a mixture of the two, is a matter of preference.

72


Automating a Multi-Step Business Process

Monitoring and Controlling the Process After the hiring manager initiates the process, the process is tracked by the process run‐ time facility and can be viewed with webMethods Monitor. You can suspend or terminate a process using webMethods Monitor, too. The following shows the progress on an instance of the hew‐hire process. It shows that, for this instance, the first step is complete.

Check marks indicate steps that are complete

You can also use webMethods Manager to continually monitor a business process for errors and issue an alert if one of its supporting components fails.


73


74


APPENDIX

A

Summary of webMethods Components Design-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Run-Time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Administrative Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78


75

APPENDIX A Summary of webMethods Components

Design-Time Components The following table briefly describes the webMethods design‐time components. Design-Time Components webMethods Modeler

Tool you use to create business process models.

webMethods Workflow Designer

Tool you use to create workflows (sequences of tasks that are performed by people).

webMethods Developer

Tool you use to build services and other elements such as: Document types Schemas Triggers WSDL Documents Web Service Connectors Additionally supports plug‐in editors that you use to build elements associated with add‐on components such as adapters. These include: Adapter Services Adapter Notifications Mainframe Transaction Definitions Mainframe Host Connection Pools

webMethods Trading Networks Console

76

Tool you use to build and edit elements (partner profiles, document types, processing rules and so forth) that Trading Networks uses to interact with external partners and marketplaces.


Run-Time Components

Run-Time Components The following table briefly describes the webMethods run‐time components. Run-Time Components webMethods Integration Server

Serves as the primary engine for the execution of integration logic. Hosts adapters. Serves as the main entry point for the systems and applications that you want to integrate. Hosts many webMethods utilities and administrative tools.

webMethods Broker

Routes messages and is the primary component of what is generally referred to as the “message backbone” or “message facility.” Facilitates asynchronous, message‐ based solutions using the publish‐and‐subscribe model.

webMethods Adapters

Links the Integration Server to back‐end applications and systems. Adapters run on the Integration Server and handle the low‐level work of connecting to a resource, managing communications, encoding and decoding data, and invoking processes via the resource’s API.

webMethods Mainframe

Links an Integration Server to applications running under CICS or IMS/DC on a mainframe. Conceptually, webMethods Mainframe is like an adapter that does not run on the Integration Server.

webMethods Manager Server

Maintains information about the resources that you want to manage. Resources can include webMethods components such as Integration Servers, Brokers, webMethods Mainframe, and Workflow Servers, as well as business processes that you have modeled with webMethods Modeler.

webMethods Servicenet

Manages Web services. Has a central registry for Web services, enforces security, tracks performance, and alerts when service activity falls out of compliance.


77


Run-Time Components webMethods Trading Networks and eStandards Modules

Serves as a format‐neutral, document gateway that enables the flow of business documents between the webMethods components and external trading partners. Runs on the Integration Server. Trading Networks is also the component on which the webMethods eBusiness modules (e.g., RosettaNet, EDI, ebXML messaging service, SWIFT, FIX, and CIDX) operate.

webMethods Workflow

Manages the execution of workflows (sequences of tasks performed by people).

Administrative Components The following table briefly describes the webMethods administrative components. Administrative and Monitoring Components webMethods Administrator

Tool you use to configure and administer the webMethods servers. It provides browser‐based access to administrative interfaces of webMethods servers.

webMethods Monitor

Tool you use to examine instances of business processes, workflows, services, 4.x Enterprise adapter integrations, and documents that the integration is processing or has finished processing. Also used to perform control tasks such as suspending or resuming business processes and resubmitting documents. Provides the ability to monitor Trading Network activity by linking to the monitoring feature in Trading Networks Console.

78


Administrative Components

Administrative and Monitoring Components webMethods Manager Console

Component that enables you to monitor and manage the operation your integration backbone using the systems management console provided by webMethods (Manager Console) or using an OMI‐ compliant console such as HP OpenView, CA Unicenter, or PATROL from BMC Software.

webMethods Optimize

Component that monitors business processes. Analyzes KPIs and automated and dynamic performance thresholds. Provides predictive capabilities to identify problems before they happen.


79


80


Index

Index Numerics 3270 terminal screens 25

A access control 53 ACLs (Access Control Lists) 53 adapter notifications 24, 36 adapter services 24, 36 adapters 21, 23 administrative components 18, 78 Administrator 38 asynchronous messaging 21 audit logs 40 authentication 54

B b2b applications 11, 25 b2b solution, example of 62 benefits of integration 9 BMC PATROL 39 Broker 21 business gateway 21 Business Monitoring task 52 business problems 62 business process dimensions 49 event maps 49 business process integration 13 business process models 31, 40, 47

C CA Unicenter 39 canonical document 64 canonical key 69 CICS 11, 24 CIDX Chem eStandards 11, 25 clusters 57 COM 35


common solutions 62 components 18 administrative 78 design-time 76 run-time 77 console, for Manager 39

D data encryption 54 Data Management task 52 data mapping 45 data privacy 54 data propagation solution 67 data transformations 45 DB2 11 DCOM 35 Designer 33 design-time components 18, 31, 76 Developer 34 digital certificates 54 dimensions description 49 distribution rules 34 DMZ 54 document type 44 documents 32, 44 logging 40

E ebXML 11, 21, 25 echo suppression 69 e-commerce 11, 21, 25 EDI 11, 21, 25 encryption 54 enterprise applications integration 11 enterprise backbone 10 event maps description 49

81

Index

examples 62 b2b solution 62 integrated business process 70 synchronization solution 67

F fail-over mechanisms 58 fault detection 58 firewall 54 flat file formats 11 flat file schemas 36 flow language 35 FTP 11

H high-availability configuration 58 host connection pools 36 HP OpenView 39 HTTP 11 HTTPS 11 human-based tasks 34

I i2 11 IBM-compatible mainframes 24 IMS 11, 24 Informix 11 integration benefits 9 integration challenge 8 integration logic 21 Integration Monitoring task 52 Integration Server 20 internal server 55

J JD Edwards 11 JDBC database 11

K Kerberos 54 key cross-referencing 69

82

L LDAP 54 logging documents 40

M Mainframe component 24 Manager 39 Manager Console 39 Manager Server 39 message broker 21 MIME 11 Modeler 31 Monitor 40 monitoring business process models 40 monitoring business processes 14, 40 monitoring components 18 monitoring services 40 My webMethods Business Monitoring 52 Data Management 52 Integration Monitoring 52 Rule Administration 52 System Monitoring 52 User Administration 52 Web Services Management 52 webMethods Configuration 52

N notifications, from adapters 24

O ODBC database 11 OMI 39 OpenView 39 Oracle 11 overview of integration 8

P PeopleSoft 11 PKCS #7 54 portlet controller 37 private keys 54


Index

process model 47 creating with Modeler 31 documents 32 example of 70 overview of 31 steps 31 transitions 32 process run-time facility 48 processing rules 26 propagation solution 67 proxy server 54 public keys 54 publish-and-subscribe model 21

R reliability 58 reverse invoke configuration 55 roles 34 RosettaNet 11, 21, 25 routers 34 RPC 11 Rule Administration task 52 run-time components 18, 20, 77

S S/MIME 11, 54 SAP 11 scalability 11, 56 security 12, 53 services 21, 40, 45 Siebel 11 signature, of a service 45 SMTP 11 SNA network 24 SOAP 11 solutions, examples of 62 SQL Server 11 SSL 54 steps in a process 31 supported systems and applications 11 SWIFT FIN 11, 25 Sybase 11


synchronization solution, example of 67 System Monitoring task 52

T task views 34 tasks 34 Business Monitoring 52 Data Management 52 Integration Monitoring 52 Rule Administration 52 System Monitoring 52 User Administration 52 Web Services Management 52 webMethods Configuration 52 TCP/IP 24 territories 22, 57 timers 34 Trading Networks 25 Trading Networks Console 26 transaction definitions 36 transformations 45 transitions in a process 32, 47

U UCCNET 11 UniCenter 39 User Administration task 52

V Visual Basic 35

W Web services 11, 36, 45 Web Services Management task 52 webMethod Mainframe 24 webMethods Adapters 23 webMethods Broker 21 webMethods components, summary 75 webMethods Configuration task 52 webMethods Developer 34 webMethods Integration Server 20 webMethods Manager 39

83

Index

webMethods Modeler 31 webMethods Trading Networks 25 webMethods Workflow 27 webMethods Workflow Designer 33 Workflow client 27 Workflow component 27 Workflow Designer 33 Workflow Server 27 WSDL 11, 36, 45

X x.509 certificates 54 XML 11 XML Schema 11

84


Introduction to webMethods Fabric 6.5 and 6.5.1.pdf

Recommend Documents