Web Services Developer’s Guide

VERSION 6.0.1

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

Copyright © 2003 by webMethods, Inc. All rights reserved, including the right of reproduction in whole or in part in any form.
webM-IS-WS-20030320
 Contents

Contents

Chapter 1. About this Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Welcome! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Program Code Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Viewing this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Printing this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
What Is a Web Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Using webMethods Software to Invoke Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Using webMethods Software to Create Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
What Is a WSDL Document? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Information Required to Generate a WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
About Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
XML Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Integration Server Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 3. Creating and Running a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . 19

Creating a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Supporting Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Example Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Testing a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 4. Generating a WSDL Document that Uses the SOAP RPC Protocol . . . . . . . . 25
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Service Requirements When Using the Default SOAP RPC Processor . . . . . . . . . . . . . . . . . . . . . . . 26
Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 5. Generating a WSDL Document that Uses the SOAP Message Protocol . . . . 33
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Service Requirements When Using the Default SOAP Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Web Services Developer’s Guide Version 6.0.1 3

Contents

Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Input Signature Requirements When Using the Default SOAP Processor . . . . . . . . . . . . . . . . . 35
Output Signature Requirements When Using the SOAP Default Processor . . . . . . . . . . . . . . . . 36
Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 6. Generating a WSDL Document that Uses the HTTP POST or GET Protocol . . 45
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Service Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Input and Output Signature Requirements .......................................... 47
Text/XML Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
URL Encoded Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Appendix A. WSDL Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Basic Elements in WSDL Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
The Address Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
WSDL Namespace Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Sample WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Appendix B. Web Service-Related Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Message Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Web Service-Related Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Messages Received When Generating a WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Messages Received When Creating a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . 71

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4 Web Services Developer’s Guide Version 6.0.1

 CHAPTER 1
About this Book

Welcome! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Viewing this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Printing this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Web Services Developer’s Guide Version 6.0.1 5

CHAPTER 1 About this Book

Welcome!
This guide is for users who want to create Web services and incorporate Web services into
the solutions they develop. This guide explains how to generate WSDL documents for
webMethods Web services and use webMethods software to call Web services located on
remote servers.

Conventions

Typographical Conventions
This document uses the following typographical conventions:

Convention Example
Procedures are designated by a blue To create a flow service
box in the left column. Procedures
are presented as a series of
numbered steps. 1 On the File menu, click New.

Terms that identify elements, The Service field on the Properties tab specifies
options, selections, and commands the name of the requested service.
on the screen are shown in bold.
Storage locations for services on the pub.client:smtp sets a MIME-type e-mail message.
Integration Server are shown in a
narrow font using the convention
folder.subfolder:service.
Characters that you must type Type: *Administrators*
exactly are shown in a typewriter
font.
Variable information that you must Log on to the proxy server with:
change (based on your specific
USER proxy_user
situation or environment) is shown
PASS proxy_password
in italics.
Input and output variables for a A service in the flow takes a document list
service are shown in italics. called LineItems.
Messages that the system displays The server returns the following error to the
on the console are shown in a user:
typewriter font.
Server has reached client limit.

Keyboard keys are shown in Press ENTER; then press TAB.

uppercase.

6 Web Services Developer’s Guide Version 6.0.1

 Conventions

Convention Example
Keys that you must press Press CTRL+ALT+M.
simultaneously are joined with the
“+” symbol.
Directory paths are shown with the webMethods6\IntegrationServer\config
“\” directory delimiter unless the
subject is UNIX specific. In these
cases, the “/” is used. If you are
working in a UNIX environment,
substitute a “/” for the “\” shown in
the procedures in this book.
Information that you must read
before beginning a procedure or Important! If the folder is not already
that alerts you to negative open in the Navigation Panel, open it
consequences of certain actions is before you start the following
presented using this notation. procedure.

Notes that provide related, but non-

critical, information are presented Note: When you start the product, you
using this notation. are prompted to log on to a
webMethods Integration Server.

Helpful information (such as

shortcuts and alternatives) is Tip! You can also use CTRL+C to copy
presented using this notation. an object.

Program Code Conventions

For programming code and command syntax, this document uses the following
typographical conventions:

Convention Example
Keywords and values that you must type %CoSymbol%
exactly as printed are shown in typewriter
font.
Variable values or parameters that you must %VarName%
supply are shown in italics.
Keywords or values that are optional are %loop LoopVar [null=NullValue]%
enclosed in [ ]. Do not type the [ ] symbols in
your own code.

Web Services Developer’s Guide Version 6.0.1 7

CHAPTER 1 About this Book

Related Documentation
The following documents are companions to this guide. Some documents are in PDF
format and others are in HTML.

Refer to this book... For...

Introduction to An overview of the webMethods Integration Platform and
Integration with how you use it to integrate business processes across
webMethods applications, information systems, people, and companies.
You will find this book at:
webMethods6\doc\IntroToIntegration.pdf
webMethods Developer Information about using webMethods Developer to create
User’s Guide and test services and client applications. This book is for
developers.
You will find this book at:
webMethods6\Developer\doc\ISDeveloperGuide.pdf
webMethods Integration Information about using the Integration Server
Server Administrator’s Administrator to configure, monitor, and control the
Guide webMethods Integration Server. This book is for server
administrators.
You will find this book at:
webMethods6\IntegrationServer\doc\ISAdministratorsGuide.pdf
webMethods Built-In Descriptions of services that are installed on your
Services Reference Guide Integration Server. This book for is for developers.
You will find this book at:
webMethods6\Developer\doc\ISBuiltInServicesGuide.pdf
webMethods Integration Descriptions of the Java classes you use to create services.
Server Java API This reference is for developers who build services using
Reference Java.
You will find this book at:
webMethods6\IntegrationServer\doc\api\Java\index.html

8 Web Services Developer’s Guide Version 6.0.1

 Viewing this Document

Refer to this book... For...

webMethods Developer Information about the controls in the webMethods
Online Help Developer application windows and step-by-step
procedures describing how to perform tasks with the
webMethods Developer.
You can access the online reference by clicking Help in an
application window or dialog box.
webMethods Integration Information about the controls in the webMethods
Server Administrator’s Integration Server Administrator screens and step-by-step
Online Help procedures describing how to perform tasks with the
Integration Server Administrator.
You can access the online reference by clicking the Help link
on an Integration Server Administrator screen.

Viewing this Document

To view this document, which is in PDF format, you must have Acrobat Reader 4.0 or later
installed on your system. If you have an earlier version of Acrobat Reader, you will
receive the following error message when you open this document and Acrobat Reader
will not display the images in this document:
Could not find the ColorSpace named ‘Cs8.’

If you do not have this software or you do not have the correct version, you can download
a free copy from:
http://www.adobe.com/supportservice/custsupport/download.html.

Printing this Guide

To produce a hard copy of this guide, print this document from Acrobat Reader.

Web Services Developer’s Guide Version 6.0.1 9

CHAPTER 1 About this Book

10 Web Services Developer’s Guide Version 6.0.1

 CHAPTER 2
Concepts

What Is a Web Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Using webMethods Software to Invoke Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Using webMethods Software to Create Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

What Is a WSDL Document? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Information Required to Generate a WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Web Services Developer’s Guide Version 6.0.1 11

CHAPTER 2 Concepts

What Is a Web Service?

Web services are building blocks for creating open, distributed systems. A Web service is a
collection of functions that are packaged as a single unit and published to a network for
use by other software programs. For example, you could create a Web service that checks
a customer’s credit or tracks delivery of a package. If you want to provide higher-level
functionality, such as a complete order management system, you could create a Web
service that contains other Web services that each perform an order management function.

Using webMethods Software to Invoke Web Services

You can use webMethods Integration Server and webMethods Developer to invoke Web
services located on remote servers. To do so, you generate a Web service connector from the
WSDL document for the remote Web service, then run the connector. A Web service
connector is a flow service that has an input and output signature that corresponds to the
input and output messages from the WSDL document from which it was created.

Using webMethods Software to Create Web Services

You can use Integration Server and Developer to turn any service in any Integration
Server package into a Web service. Integration Server provides an environment for
executing services efficiently and securely. It receives and decodes requests from clients,
calls the requested services, and encodes and returns the output to the clients. Integration
Server also provides an extensive library of built-in services. Developer is the integrated
development environment (IDE) that you use to create services on Integration Server.
Integration Server’s service-oriented architecture makes it ideal for use in integration
scenarios because it separates implementation from presentation. When a client
application wants to invoke a Web service, the client need know only the service’s name,
inputs, and outputs. The client does not need to know how the service is implemented (for
example, in Java or C) or what kind of back-end system it accesses.
Similarly, the Web service implementation (that is, the back-end business logic) does not
need to know what kind of client invoked it. A client can use HTTP/HTTPS, FTP, or SMTP
to invoke the same service. You do not need to have multiple versions of the same service
because the webMethods content handler layer takes care of all marshalling and
unmarshalling between the protocol layer and the implementation layer.

12 Web Services Developer’s Guide Version 6.0.1

 What Is a WSDL Document?

Integration Server’s service-oriented architecture

transports HTTP/S FTP SMTP

content handlers XML SOAP RPC SOAP MSG EDI

webMethods invoke handler

example service types Flow Java COM C/C++

With webMethods software, you can create Web services using programming languages
such as Java, C/C++, or COM. You can also create Web services from existing back-end
systems, without producing custom code or reconfiguring the back-end systems, using
webMethods adapters.

What Is a WSDL Document?

A Web Services Description Language (WSDL) document is an XML document that describes
Web services that are accessible over a network. The WSDL document for a Web service
contains all the information a Web service consumer needs to send data to the Web
service, invoke the Web service, and receive data from the Web service.
A Web service provider can:
Create the WSDL document and supporting files for a service.

Upload the WSDL document and files to a publicly accessible server.

Use a Web services registry to publish a URL that identifies the location of the WSDL
document.

Note: A Web service provider can also distribute a WSDL document and supporting files
to Web service consumers directly.

Web service consumers can:

Browse the registry and locate the service.

Use the URL to download the WSDL document.

The WSDL document for a Web service describes the following:
Logic the Web service performs.

Location of the Web service.

Web Services Developer’s Guide Version 6.0.1 13

CHAPTER 2 Concepts

Method to use to access the Web service, including the protocol that the Web service
consumer must use to invoke the Web service and receive a response.
Input parameters that the Web service consumer must supply to the Web service and
the output parameters that the Web service returns.

Information Required to Generate a WSDL Document

When you generate a WSDL document for a Web service, you provide the following
information:

Information Description

Web service location Production Integration Server on which the Web service will
reside.
Protocol Protocol that Web service consumers must use to communicate
with the Web service. You can specify the SOAP RPC, SOAP
message (document), HTTP POST, or HTTP GET protocol.
Transport Request transport mechanism that Web service consumers must
use to invoke the Web service. You can specify HTTP or HTTPS,
depending on the port you are using.
Service signature Input parameters the Web service requires and output
parameters the Web service produces.
The service for which you generate a WSDL document, and the
input and output parameters that compose the service’s
signature, must meet certain requirements. These requirements
differ depending on the protocol you select for Web service
consumers to communicate with the Web service. For more
information about these requirements, see the individual
chapters that describe how to generate WSDL documents for
each type of protocol.
Target namespace Namespace to which elements, attributes, and type definitions
in the generated WSDL document will belong.

The subsystem of Integration Server that generates WSDL documents is called the WSDL
generator. The WSDL generator creates a WSDL document using the information you
provide along with information from the service.

14 Web Services Developer’s Guide Version 6.0.1

 Information Required to Generate a WSDL Document

About Namespaces
Namespaces are collections of names (for example, the names of XML Schema elements,
Integration Server document types, or Integration Server services). A namespace name is
associated with each collection to provide context for the named entities within the
collection. This helps prevent conflicts when the scope of a named entity extends beyond
its current context.
The following sections describe XML namespaces and namespace use within the
Integration Server.

XML Namespaces
By the World Wide Web Consortium (http://www.w3.org) definition, an XML namespace is
a collection of names identified by a URI reference. XML namespaces help avoid naming
conflicts by differentiating between element types or attributes with the same name in an
XML document. As long as these like-named element types or attributes reside in
different namespaces, they are considered different entities.
You can define a prefix to represent an XML namespace URI. Prefixes provide a way to
shorten the reference to the XML namespace URI. In the following XML Schema example,
the prefix address represents the XML namespace URI http://www.example.com:
xmlns:address="http://www.example.com"

You can use this prefix elsewhere in the XML document, in conjunction with an element's
local name attribute, to represent the full URI with which the prefix is associated. For
example:
<address:street>123 Main Street</address:street>

The name of an element type or attribute is referred to as its local name. When an element
type or attribute is associated with a namespace, its name (whether prefaced by a prefix or
not) is also known as an XML namespace qualified name (QName).

Integration Server Namespaces

All webMethods entities that you save on an Integration Server, including services and
document types, have a unique name. This unique name has two parts: the name of the
entity (its local name) and the folder path in which it resides (its Integration Server namespace
name). For example, a service called myService that resides in the folder structure
topFolder\childFolder is represented in the Integration Server as
topFolder.childFolder:myService, where topFolder.childFolder is the service's folder name and
myService is the service's element name. An Integration Server namespace (folder path)
cannot contain two different components with the same local name.

Web Services Developer’s Guide Version 6.0.1 15

CHAPTER 2 Concepts

Specifying Universal Names for Integration Server Services

When an Integration Server service is used as a SOAP Web service, the Integration Server
identifies the service using a unique public identifier called a universal name. Similar in
structure to a QName in an XML namespace, a universal name consists of a namespace
name and a local name. These names are determined as follows:
The namespace name is specified as a URI and can consist of any combination of
characters that form a valid absolute URI (for example,
http://www.gsx.com/gl/journals).
The local name follows the same construction rules as NCNames in XML Schema
(that is, it must conform to the naming conventions specified in
http://www.w3.org/TR/REC-xml-names/#NT-NCName).
For more information about what makes up a valid URI and how to construct local
names, see the SOAP Developer’s Guide.

Note: The universal name should conform to the XML QName naming conventions
specified in http://www.w3.org/TR/REC-xml-names/#NT-QName.

Universal names can be explicit or implicit.

An explicit universal name is a universal name that you specifically assign to a service
by completing the Namespace name and Local name fields on the service's Settings tab in
Developer.
For more information about specifying an explicit universal name, see the webMethods
Developer User’s Guide.
An implicit universal name is automatically derived from the name of the service
itself. The implicit name acts as the universal name when a service does not have an
explicit universal name. The server derives an implicit name as follows:
The namespace name is the literal string http://localhost followed by the fully
qualified name of the folder in which the service resides on the Integration Server.
The local name is the unqualified name of the service.

Associating Integration Server Fields with XML Namespaces

Although it is not always necessary to do so, you can associate the name of an Integration
Server field (such as an IS document variable) with an XML namespace. When you do so,
the local name is the name of the field and the XML namespace name is the URI that
identifies the namespace. You can also include a prefix as part of the name.

Note: The WSDL generator defines prefixes in WSDL documents to represent specific
namespaces that identify a binding’s protocol. For more information about these prefixes
and their associated namespaces, see Appendix A, “WSDL Documents”.

16 Web Services Developer’s Guide Version 6.0.1

 Information Required to Generate a WSDL Document

In Developer, you assign XML namespaces and prefixes to Integration Server fields as
follows:
To assign an XML namespace to an Integration Server field, complete the XML
Namespace field on the General tab of the field’s Properties dialog box.
To assign a prefix to an Integration Server field, precede the field name with the prefix
followed by a colon (for example, prefix:variableName).

Note: In most cases, if you use a prefix you must also supply an XML namespace. For more
information, see the chapters in this guide for generating WSDL documents for each type
of protocol.

Web Services Developer’s Guide Version 6.0.1 17

CHAPTER 2 Concepts

18 Web Services Developer’s Guide Version 6.0.1

 CHAPTER 3
Creating and Running a Web Service Connector

Creating a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Testing a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Web Services Developer’s Guide Version 6.0.1 19

CHAPTER 3 Creating and Running a Web Service Connector

Creating a Web Service Connector

Because a Web service connector is a flow service, you lock, test, debug, and call the
connector using same procedures you would use to lock, test, debug, and call a flow
service.

Note: The Web Service Connector wizard requires you to specify a WSDL document that
resides either on the Internet or on your local file system. If you do not have a WSDL
document and you would like to use Developer to create one, see the chapters in this
guide for generating WSDL documents that use the SOAP RPC, SOAP Message, HTTP
POST, or HTTP GET protocols.

To create a Web service connector

1 Click on the main toolbar. Developer opens the New wizard.

2 Click Web Service Connector, then click Next. The wizard displays the New Web Service
Connector panel.
3 Identify the folder in which you want to store the connector by clicking the folder in
the Folder box, then click Next. The wizard displays the next panel.
4 In the Choose a .wsd or .wsdl file box, do one of the following:
If you want to create a Web service connector from a WSDL document that resides
on the Internet, enter the URL for the document. The URL must begin with http://
or https://.

Note: If the Web site on which the document resides is password protected, you
must download the WSDL document to your local file system, then create the
Web service connector.

If you want to create a Web service connector from a WSDL document that resides
on your local file system, click to navigate to and select the document.
5 Click Finish. Developer validates the WSDL document you selected, creates the
connector and supporting Integration Server elements, and saves the connector and
the elements to the folder you specified. For information about the IS elements that
Developer generates, see “Supporting Elements” on page 21.

Note: If Developer cannot create or cannot completely generate a Web service connector
from the WSDL document because the WSDL document is invalid or is missing WSDL
elements, Developer displays error messages or warning messages. For more information
about errors that can occur when generating connectors, see Appendix B, “Web Service-
Related Errors and Warnings”.

20 Web Services Developer’s Guide Version 6.0.1

 Creating a Web Service Connector

Supporting Elements
When Developer creates a Web service connector from a WSDL document, it also creates
supporting IS elements. Each of the IS elements that Developer creates corresponds to an
element in the WSDL document.
The following table identifies the IS elements that Developer might create when it
generates a Web service connector.

This IS element... Corresponds to this WSDL element...

Folder Each unique <portType> element in the WSDL document.
The subfolder name corresponds to the portType name.
Web service Each unique <operation> element in a <portType> element.
connector The Web service connector name corresponds to the
operation name.
docType folder All of the IS document types generated from the messages in
the WSDL document.
IS document type Each <message> element in the WSDL document. The IS
document type name corresponds to the message name.
When creating the IS document type for the input message,
Developer inserts the _port and auth variables into the IS
document type. The Web service connector uses the _port
variable as the switch value in the BRANCH on '/_port' step to
determine which network address and binding to use to
invoke the Web service. Integration Server uses the auth
variable to authenticate the user name and password the
Web service connector is using to call the Web service.
IS schema Each target namespace to which the element declarations,
attribute declarations, and type definitions that define the
message parts (input and output signature) belong.

Example Web Service Connector

The following Web service connector was generated from a WSDL document that
describes a Web service that authorizes a credit card. The WSDL document specified:
An input message named AuthorizeCreditCardInput that specified the inputs Name,
CreditCardType, CreditCardNumber, and ExpirationDate.
An output message named AuthorizeCreditCardOutput that specified the output
isAuthorized.
A <binding> element that specified SOAP RPC as the protocol.

Web Services Developer’s Guide Version 6.0.1 21

CHAPTER 3 Creating and Running a Web Service Connector

A <service> element that contained one <port> named

AuthorizeCreditCardPortType.
A single <operation> element named AuthorizeCreditCard.
On the Input/Output tab for the Web service connector, note that the Web service connector
uses references to the input and output IS document types to define the service signature.

Input/Output tab for a Web service connector

Developer creates these

elements from the
WSDL document.

The IS document type

generated from the
input message is used
to declare the input
signature.

The IS document type

generated from the
output message is used
to declare the output
signature.

Developer inserts flow steps into the Web service connector by following an internal
template for inserting input data into the service request, sending the request, processing
the response, and adding service output values to the pipeline. The template that
Developer follows depends on the protocol specified in the WSDL document. The
following illustration shows the Web service connector generated for the Web service that
performs credit card authorization.

22 Web Services Developer’s Guide Version 6.0.1

 Testing a Web Service Connector

Web service connector for credit card authorization Web service

This BRANCH step

contains a child step for
each named port.

This BRANCH step

contains a child step for
each named binding.

This SEQUENCE
corresponds to a binding
for the SOAP RPC
protocol.

Note: The $default port corresponds to the first named <port> element in the WSDL
document.

Testing a Web Service Connector

You can test a Web service in Developer using the Run command on the Test menu. When
you execute a service with the Run command, Developer invokes the service and receives
its results. The service executes once, from beginning to end (or until an error condition
forces it to stop) on the server on which you have an open session.
Before Developer invokes the Web service, it prompts you for input values. You can type
the input values into the dialog box provided by Developer or load the values from a file
that was saved during an earlier test. Results from the service are returned to Developer
and displayed on the Results tab.
For more information about testing flow services, see the webMethods Developer User’s
Guide.

To test a Web service connector

1 In the Navigation Panel, click the Web service connector you want to run.

2 Click . Developer displays the Input for ‘connector’ dialog box. The dialog box shows
the inputs required by the remote Web service.
3 Provide the input values, then click OK. Developer runs the connector, which calls the
remote Web service, and displays the results on the Results tab.

Web Services Developer’s Guide Version 6.0.1 23

CHAPTER 3 Creating and Running a Web Service Connector

24 Web Services Developer’s Guide Version 6.0.1

 CHAPTER 4
Generating a WSDL Document that Uses the SOAP RPC
Protocol

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Service Requirements When Using the Default SOAP RPC Processor . . . . . . . . . . . . . . . . 26

Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Web Services Developer’s Guide Version 6.0.1 25

CHAPTER 4 Generating a WSDL Document that Uses the SOAP RPC Protocol

Overview
When you specify SOAP RPC as the protocol for Web service consumers to use to
communicate with a Web service, the RPC processor will receive SOAP messages that call
the service. You can select either the default RPC processor or a registered, custom-built
SOAP RPC processor (for example, an access-controlled RPC processor). The processor
you select will receive requests for the Web service.
The Web service for which you are generating the WSDL document will be a target service
of the selected processor. Consequently, the service needs to conform to the target service
requirements for the specified processor.
If you select a custom SOAP RPC processor, make sure the service for which you are
generating the WSDL document conforms to the target service requirements for the
custom processor. The following section explains the service requirements if you want to
use the default SOAP RPC processor to receive and send SOAP messages for the service.
For information about creating custom SOAP RPC processors, see the SOAP Developer’s
Guide.

Service Requirements When Using the Default SOAP RPC

Processor
When you use the default SOAP RPC processor to process remote procedure calls, the
target service for which you are generating the WSDL document must meet this
requirement:
If you specify a universal name for the service, you must include both a namespace
name and a local name. The namespace name must consist of a valid URI. The local
name must conform to the naming conventions specified in
http://www.w3.org/TR/REC-xml-names/#NT-NCName. The universal name should
conform to the XML QName naming conventions specified in
http://www.w3.org/TR/REC-xml-names/#NT-QName.

Note: You assign a universal name to a service in Developer by completing the

Namespace name and Local name fields on the service's Settings tab.

In addition to this requirement, webMethods recommends the following:

Check the target service’s Execute ACL permission to ensure that consumers of the
service can invoke it.
The RPC WSDL generator represents all document variables as closed complex types
in the WSDL (that is, all child variables are declared). To ensure interoperability with
other Web service vendors, avoid producing pipeline variables that you do not
declare in the output signature.

26 Web Services Developer’s Guide Version 6.0.1

 Input and Output Signature Requirements

Input and Output Signature Requirements

When you specify SOAP RPC as the protocol for accessing a Web service, the WSDL
generator creates the input and output messages for the WSDL document from the
signature specified on the Input/Output tab of the service.
If you want to use the default SOAP RPC processor to process remote procedure calls, the
service’s input and output signature must meet the requirements listed in the table below.
The other chapters that describe how to generate WSDL documents also contain this table
so you can easily compare requirements across protocols.

Service signature requirements for the SOAP RPC protocol

Case Applies? Notes

Field types at the top level

Top-level strings are allowed. Yes

Top-level objects and documents are allowed. Yes
Top-level string, object, and document lists Yes
are allowed.
Top-level string tables are allowed. Yes
Field types below the top level

Strings, objects, and documents are allowed. Yes

String, object, and document lists are allowed. Yes
String tables are allowed. Yes
Field names

Field names can contain a prefix without an Yes

associated XML namespace.
Field names can be associated with an XML Yes
namespace without a prefix.
Field names must conform to QName lexical No If the names do not conform, the RPC WSDL
rules (that is, the prefix and local name must generator encodes the names according to the
conform to NCName rules specified in rules specified in
http://www.w3.org/TR/ http://www.w3.org/2000/xp/Group/2/06/LC/so
REC-xml-names/#NT-NCName). ap12-part2.html#namemap.
String field names can begin with the Yes The WSDL generator encodes the names
character @ or be named *body. according to the rules specified in
http://www.w3.org/2000/xp/Group/2/06/LC/so
ap12-part2.html#namemap.

Web Services Developer’s Guide Version 6.0.1 27

CHAPTER 4 Generating a WSDL Document that Uses the SOAP RPC Protocol

Case Applies? Notes

Fields of type other than scalar string can have Yes The WSDL generator encodes the names
names that begin with the character @ or be according to the rules specified in
named *body. http://www.w3.org/2000/xp/Group/2/06/LC/so
ap12-part2.html#namemap.
Duplicate field names

Fields at the same level (that is, beneath the

same parent field in the input or output of the
same signature) can have the same name and
Same type and properties. Yes
Different type and properties. Yes However, the WSDL generator uses only one
field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
More than one field named *body can occur at Yes The WSDL generator encodes the names
the same level. according to the rules specified in
http://www.w3.org/2000/xp/Group/2/06/LC/so
ap12-part2.html#namemap.
However, the WSDL generator uses only one
field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
Duplicate field names that begin with the Yes The WSDL generator encodes the names
character @ can repeat at the same level. according to the rules specified in
http://www.w3.org/2000/xp/Group/2/06/LC/so
ap12-part2.html#namemap.
However, the WSDL generator uses only one
field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
Fields at different levels can have the same
name and
Different or no XML namespace values, Yes
even though they may have different type
and properties.

28 Web Services Developer’s Guide Version 6.0.1

 Input and Output Signature Requirements

Case Applies? Notes

Duplicate XML namespace values and the Yes
same type and properties.
Duplicate XML namespace values and Yes
different type and properties.
Field properties

Document or Document list type fields can be Yes However, the Integration Server displays a
open (that is, contain a check mark in the Allow warning and marks the documents as “closed.”
unspecified fields check box on the Constraints
tab of the Variable Properties dialog box).
Top-level fields must be associated with an No The Integration Server ignores the XML
XML namespace. namespace value if present.
Fields beneath the top level must be No The Integration Server ignores the XML
associated with an XML namespace. namespace value if present.
Recursive documents are allowed. Yes The Integration Server will generate the WDSL
document but cannot create a Web service
connector from the WSDL document.
Field type constraints

Object constraints are allowed. Yes However, the WSDL generator does not
represent them in the WSDL document.
Strings constrained by older schema types Yes However, the WSDL generator maps them into
(types defined before the W3C XML 2001 2001 XML Schema types.
Schema recommendations) are allowed.

Note: By default, a field must exist at run time, can contain a null value, and (for document
type fields), cannot contain unspecified fields. If you change a field's default properties,
the WSDL generator reflects those changes in the schema section of the WSDL document.
However, the message element of a WSDL document cannot define these properties.
Therefore, when you use the WSDL document to generate a Web service connector, the
Integration Server uses the default properties for all top-level fields.

Web Services Developer’s Guide Version 6.0.1 29

CHAPTER 4 Generating a WSDL Document that Uses the SOAP RPC Protocol

Generating the WSDL Document

To create a WSDL document that specifies the SOAP RPC protocol, you do the following:

Stage Description

1 Identify the service for which you want to generate a WSDL document.

2 Specify the protocol and transport mechanism for Web service consumers to
use to communicate with the Web service.

3 Specify the target namespace for the WSDL document.

4 Generate the WSDL document.

Stage 1 To identify the Web service

1 In the Navigation Panel, select the service for which you want to generate a WSDL
document.
2 On the Tools menu, click Generate WSDL. Developer opens the Generate WSDL dialog
box.

Generate WSDL dialog box

3 In the Host box, type the numeric IP address or domain name of the host machine on
which the Web service will reside at production time.
By default, the Host box identifies the Integration Server on which the Web service
currently resides; that is, the Integration Server to which you are currently connected.

30 Web Services Developer’s Guide Version 6.0.1

 Generating the WSDL Document

You do not need to specify http:// or https:// as part of the host name; the WSDL
generator automatically adds http:// or https:// (based on the transport
mechanism you specify in the Via Transport box) to the host name when it compiles the
network address for the Web service.
4 In the Port box, type the number of the port you want to use to accept requests for the
Web service from Web service consumers.
By default, the Port box identifies the port you used to connect to the current
Integration Server. If you want to use a different port, type the number of that port in
the Port box.
The port you identify must be able to accept either HTTP requests or HTTPS requests.
If you do not require that requests from Web service consumers be sent securely,
specify a port that accepts HTTP requests. If you want requests from Web service
consumers to be sent securely, specify a port that accepts HTTPS requests.

Stage 2 To specify the protocol

1 Under Protocol, click SOAP-RPC.

2 Under Via Transport, click the request transport mechanism that is accepted by the port
you specified in the Port box. If the port accepts HTTP requests, click HTTP. If the port
accepts HTTPS requests, click HTTPS.
3 From the Directive list, select the directive of the SOAP processor to which you want
requests for this service directed. If you want requests for this service routed to the
Integration Server’s default SOAP RPC processor, click rpc. If you want to use a
custom RPC processor that is registered on your Integration Server, select its
directive.

Note: The Directive list displays all registered SOAP processors on the Integration
Server to which you are currently connected. If you plan to move the service to a
production Integration Server, make sure the directive you select corresponds to a
SOAP processor that is registered on the production server as well.

Important! If you specify anything other than the default SOAP RPC processor, be
certain that the directive belongs to a SOAP RPC processor. Otherwise, requests for
this service will not be processed correctly.

For information about creating and registering your own SOAP RPC processor, see
the SOAP Developer’s Guide.

Web Services Developer’s Guide Version 6.0.1 31

CHAPTER 4 Generating a WSDL Document that Uses the SOAP RPC Protocol

Stage 3 To specify the target namespace for the WSDL document

1 In the Target Namespace box, specify the target namespace for the WSDL document.
By default, the Target Namespace box displays http://host/ as the target namespace,
where host is the name of the server you are currently logged on to. If you want to
specify a different namespace, type the URI for that namespace in the box.
2 Click OK. Developer displays a dialog box that prompts you for a location and name
for the generated WSDL document.

Stage 4 To generate the WSDL document

1 Under Save in, select the directory in which you want to save the generated WSDL
document.
2 In the File name field, specify a name for the WSDL document. By default, Developer
assigns the document the name serviceName.wsdl.
3 Click Save. The WSDL generator generates the WSDL document. Developer then
displays a message that lists the WSDL document file and the directory in which it
stored the file.
4 Click OK.

Note: If an error occurs during WSDL generation, Developer displays a message to

that effect.

32 Web Services Developer’s Guide Version 6.0.1

 CHAPTER 5
Generating a WSDL Document that Uses the SOAP Message
Protocol

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Service Requirements When Using the Default SOAP Processor . . . . . . . . . . . . . . . . . . . . 34

Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Web Services Developer’s Guide Version 6.0.1 33

CHAPTER 5 Generating a WSDL Document that Uses the SOAP Message Protocol

Overview
When you specify SOAP messaging as the protocol for Web service consumers to use to
communicate with a Web service, you can select the SOAP processor you want to use to
handle messages sent by the Web service consumers. You can select either the default
SOAP processor or a registered, custom-built SOAP processor (for example, an access-
controlled processor). The processor you select will receive, process, and send SOAP
messages that call the service.
The Web service for which you are generating the WSDL document will be a target service
of the selected processor. Consequently, the service needs to conform to the target service
requirements for the specified processor.
If you select a custom SOAP processor, make sure the service for which you are
generating the WSDL document conforms to the target service requirements for the
custom processor. The following section explains the service requirements if you want to
use the default SOAP processor to receive and send SOAP messages for the service. For
information about creating custom SOAP processors, see the SOAP Developer’s Guide.

Service Requirements When Using the Default SOAP Processor

If you want to use the default SOAP processor to handle the SOAP message request and
response for the service, the target service for which you are generating the WSDL
document must meet these requirements:
The service input signature must contain a soapRequestData object and a
soapResponseData object, and its output signature must contain a soapResponseData
object. You can use pub.soap.utils:requestResponseSpec to specify the inputs and outputs
for the service.
The service should use the SOAP data-retrieval services, such as pub.soap.utils:getBody,
pub.soap.utils:getHeader, pub.soap.utils:getBodyEntries, and pub.soap.utils:getHeaderEntries to
extract elements from SOAP message objects. These services return the requested
element as an XML node (or an array of XML nodes). To extract data from the
returned node, you query it using the pub.xml:queryXMLNode service or convert it to a
document using the pub.xml:xmlNodeToDocument service. For more information about
these services, see the webMethods Built-In Services Reference Guide.
To ensure interoperability with other Web service vendors, you must provide a
universal name for the target service. The universal name must include both a
namespace name, which must consist of a valid URI, and a local name, which must
conform to the naming conventions specified in http://www.w3.org/TR/REC-xml-
names/#NT-NCName. The universal name should conform to the XML QName
naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-
QName.

34 Web Services Developer’s Guide Version 6.0.1

 Input and Output Signature Requirements

Note: You assign a universal name to a service in Developer by completing the

Namespace name and Local name fields on the service's Settings tab.

In addition to these requirements, you should also check the target service’s Execute ACL
permission to ensure that consumers of the service can invoke it.
For more information about creating a target service for the default SOAP processor, see
the SOAP Developer’s Guide.

Input and Output Signature Requirements

When you specify SOAP messaging as the protocol for accessing a Web service, you
specify an IS document type or XML Schema component to represent the input and
output signature of the service. The signature describes the XML documents that the
service requires as input and produces as output.
The WSDL generator does not create the input and output messages for the WSDL
document from the signature specified on the Input/Output tab of the service. This is
because target services for the default processor and custom SOAP processors must have
a soapRequestData object and a soapResponseData as input and produce a soapResponseData
object as output. While this signature requirement is necessary for the processor, it does
not provide meaningful signature information for WSDL documents generated for the
services used with these processors. In an XML Schema definition, a soapRequestData
object and a soapResponseData object would be represented as elements of type anytype.
To produce a meaningful, descriptive signature for the WSDL document, you can select an
IS document type or an XML schema element declaration to represent the service input
and output signature.

Input Signature Requirements When Using the Default SOAP

Processor
When you specify the default SOAP processor for handling the SOAP message requests
and responses for a service, the IS document type or XML Schema component that you
select for the input signature must follow some naming and property requirements.
The requirements are a result of the default SOAP processor’s routing behavior. The
default processor routes messages to services by matching the fully expanded QName of
the message body’s first element to the universal name of the target service. If the QName
of the message body’s first part does not resolve to the universal name of the service, the
Integration Server returns an error message stating that the service cannot be found.
If you specify the default SOAP processor for handling the SOAP message requests and
responses for the service, the IS document type or XML Schema element declaration that
describes the input signature must meet the following requirements:
The IS document type or XML Schema component must contain at least one field.

Web Services Developer’s Guide Version 6.0.1 35

CHAPTER 5 Generating a WSDL Document that Uses the SOAP Message Protocol

The top-level fields of an IS document type or XML Schema component must be

associated with an XML namespace and include an XML namespace prefix. The first
top-level field’s XML Namespace property must match the Namespace name value of the
service’s explicit universal name and its local name must match the Local name value of
the service’s explicit universal name.

Important! To ensure interoperability with other Web service vendors, the Namespace
name value of the service’s explicit universal name must be a valid URI.

For example, suppose that the explicit universal name of the service
gl.journals:journalEntry has a namespace name of http://www.exprint.com/GL/ and a
local name of JournalEntry. The first top-level field of the IS document type that
describes the input signature must be named prefix:JournalEntry, where prefix
represents the XML namespace URI. Additionally, the value of the XML Namespace
property for the JournalEntry field must be http://www.exprint.com/GL/.

Note: The WSDL generator treats variables with the same QName as identical variables
even if the variables are declared as different types.

If a top-level field of the service’s input and output signature is of type String, the field
must be namespace qualified (that is, the Content type box on the Constraints tab of the
Properties panel contains a valid URI).
See the table on page 37 for additional requirements that apply to IS document types and
XML Schema element declarations used to represent the input or output signatures of a
WSDL document.

Output Signature Requirements When Using the SOAP

Default Processor
If you are using an IS document type or XML Schema element declaration to describe the
output signature, the IS document type or XML Schema component must meet the
following requirement:
If a top-level field of the service’s input and output signature is of type String, the field
must be namespace qualified (that is, the Content type box on the Constraints tab of the
Properties panel contains a valid URI).
The following table lists additional requirements for developing the service’s input and
output signature and how they apply to the SOAP MSG protocol. The other chapters that
describe how to generate WSDL documents also contain this table so you can easily
compare requirements across protocols.

36 Web Services Developer’s Guide Version 6.0.1

 Input and Output Signature Requirements

Service signature requirements for the SOAP MSG protocol

Case Applies? Notes

Field types at the top level

Top-level strings are allowed. Yes

Top-level objects and documents are allowed. Yes
Top-level string, object, and document lists No Including a string, object, or document list at
are allowed. the top level will not result in a WSDL
generation error. However, top-level lists
cannot be represented in a WSDL document.
Top-level string tables are allowed. No
Field types below the top level

Strings, objects, and documents are allowed. Yes

String, object, and document lists are allowed. Yes
String tables are allowed. No
Field names

Field names can contain a prefix without an No

associated XML namespace.
Field names can be associated with an XML Yes Omitting the prefix will not result in a WSDL
namespace without a prefix. generation error. However, the target SOAP
message service may have runtime mapping
errors when handling namespace qualified
messages.
Field names must conform to QName lexical Yes
rules (that is, the prefix and local name must
conform to NCName rules specified in
http://www.w3.org/TR/
REC-xml-names/#NT-NCName).
String field names can begin with the Yes Naming a top-level field *body, or beginning
character @ or be named *body. the name of a top-level field with the character
@, will not result in a WSDL generation error.
However, because mixed content models or
attributes cannot be represented in a WSDL
document’s message element, these fields will
not appear in a client generated from this
WSDL document.
Fields of type other than scalar string can No
have names that begin with the character @ or
be named *body.

Web Services Developer’s Guide Version 6.0.1 37

CHAPTER 5 Generating a WSDL Document that Uses the SOAP Message Protocol

Case Applies? Notes

Duplicate field names

Fields at the same level (that is, beneath the

same parent field in the input or output of the
same signature) can have the same name and
Same type and properties. Yes
Different type and properties. Yes However, the WSDL generator uses only one
field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
More than one field named *body can occur at No
the same level.
Duplicate field names that begin with the No
character @ can repeat at the same level.
Fields at different levels can have the same
name and
Different or no XML namespace values, Yes
even though they may have different type
and properties.
Duplicate XML namespace values and the Yes
same type and properties.
Duplicate XML namespace values and Yes However, the WSDL generator uses only one
different type and properties. field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
Field properties

Document or Document list type fields can be Yes

open (that is, contain a check mark in the Allow
unspecified fields check box on the Constraints
tab of the Variable Properties dialog box).
Top-level fields must be associated with an Yes
XML namespace.
Fields beneath the top level must be No
associated with an XML namespace.

38 Web Services Developer’s Guide Version 6.0.1

 Generating the WSDL Document

Case Applies? Notes

Recursive documents are allowed. Yes The Integration Server will generate the WDSL
document but cannot create a Web service
connector from the WSDL document.
Field type constraints

Object constraints are allowed. Yes However, the WSDL generator does not
represent them in the WSDL document.
Strings constrained by older schema types Yes However, the WSDL generator maps them into
(types defined before the W3C XML 2001 2001 XML Schema types.
Schema recommendations) are allowed.

Note: By default, a field must exist at run time, can contain a null value, and (for document
type fields), cannot contain unspecified fields. If you change a field's default properties,
the WSDL generator reflects those changes in the schema section of the WSDL document.
However, the message element of a WSDL document cannot define these properties.
Therefore, when you use the WSDL document to generate a Web service connector, the
Integration Server uses the default properties for all top-level fields.

Generating the WSDL Document

To create a WSDL document that specifies the SOAP messaging protocol, you do the
following:

Stage Description

1 Identify the service for which you want to generate a WSDL document.

2 Specify the protocol and transport mechanism for Web service consumers to
use to communicate with the Web service.

3 Specify the input signature for the Web service.

4 Describe the output format of the Web service.

5 Specify the target namespace for the generated WSDL document.

6 Generate the WSDL document.

Web Services Developer’s Guide Version 6.0.1 39

CHAPTER 5 Generating a WSDL Document that Uses the SOAP Message Protocol

Stage 1 To identify the Web service

1 In the Navigation Panel, select the service for which you want to generate a WSDL
document.
2 On the Tools menu, click Generate WSDL. Developer opens the Generate WSDL dialog
box.

Generate WSDL dialog box

3 In the Host box, type the numeric IP address or domain name of the host machine on
which the Web service will reside at production time.
By default, the Host box identifies the Integration Server on which the Web service
currently resides; that is, the Integration Server to which you are currently connected.
You do not need to specify http:// or https:// as part of the host name; the WSDL
generator automatically adds http:// or https:// (based on the transport
mechanism you specify in the Via Transport box) to the host name when it compiles the
network address for the Web service.
4 In the Port box, type the number of the port you want to use to accept requests for the
Web service from Web service consumers.
By default, the Port box identifies the port you used to open the current Integration
Server. If you want to use a different port, type the number of that port in the Port box.
The port you identify must be able to accept either HTTP requests or HTTPS requests.
If you do not require that requests from Web service consumers be sent securely,
specify a port that accepts HTTP requests. If you want requests from Web service
consumers to be sent securely, specify a port that accepts HTTPS requests.

40 Web Services Developer’s Guide Version 6.0.1

 Generating the WSDL Document

Stage 2 To specify the protocol

1 Under Protocol, click SOAP-MSG. Developer enables the Directive, Input, and Output
boxes.

Important! To ensure interoperability with other Web service providers, the Namespace
name value of the service’s explicit universal name must be a valid URI. Use the
Settings tab to assign a universal name to a service.

2 Under Via Transport, click the request transport mechanism that is accepted by the port
you specified in the Port box. If the port accepts HTTP requests, click HTTP. If the port
accepts HTTPS requests, click HTTPS.
3 From the Directive list, select the process directive for the SOAP processor you want to
use to receive, process, and send SOAP messages that invoke the target service. If you
want to use the default processor, click default.

Note: The Directive list displays all registered SOAP processors on the Integration
Server to which you are currently connected. If you plan to move the service to a
production Integration Server, make sure the directive you select corresponds to a
SOAP processor that is registered on the production server as well.

Stage 3 To describe the input signature for the Web service

You can describe the input signature for the WSDL document using an IS document type
or using an element declaration from an XML Schema. Use one of the following
procedures to define the input message for the Web service.

Web Services Developer’s Guide Version 6.0.1 41

CHAPTER 5 Generating a WSDL Document that Uses the SOAP Message Protocol

To describe the input signature using an IS document type

1 Next to the Input box on the Generate WSDL dialog box, click . Developer opens the
Select Input/Output Constraint dialog box.

Select Input/Output Constraint dialog box

2 Under Choose Constraint Type, click Document Type.

3 Identify the IS document type you want to use to describe the input signature. You
can either type the fully qualified name of the IS document type in the Name box or
click the IS document type in the Folder box.
4 Click OK. Developer closes the dialog box and displays the fully qualified name of the
IS document type in the Input box on the Generate WSDL dialog box.

To describe the input signature using an XML Schema

1 Next to the Input field, click . Developer opens the Select Input/Output Constraint
dialog box.
2 Under Choose Constraint Type, click Schema Component.
3 In the text field, after http://, type the Web location and name of the XML Schema that
contains the element declaration you want to use to describe the input signature.

Important! The XML Schema you identify must be located on the Web and must be
accessible to consumers of the WSDL.

42 Web Services Developer’s Guide Version 6.0.1

 Generating the WSDL Document

4 Click Load. Developer groups the element declarations in the XML Schema under the
ELEMENTS heading. Expand the heading to view the global element declarations in
the XML Schema.
5 Select the global element declaration that you want to use to represent the input
signature.
6 Click OK. Developer closes the dialog box and displays the name of the selected
element declaration in the Input box on the Generate WSDL dialog box.

Stage 4 To describe the output signature for the Web service

You can describe the output signature for the WSDL document using an IS document type
or using an element declaration from an XML Schema. See “To describe the input
signature for the Web service” on page 41 for instructions.

Stage 5 To specify the target namespace for the WSDL document

1 In the Target Namespace box, specify the target namespace for the WSDL document.
By default, the Target Namespace box displays http://host/ as the target namespace,
where host is the name of the server you are currently logged on to. If you want to
specify a different namespace, type the URI for that namespace in the box.
2 Click OK. Developer displays a dialog box that prompts you for a location and name
for the generated WSDL document.

Stage 6 To generate the WSDL document

1 Under Save in, select the directory in which you want to save the generated WSDL
document.
2 In the File name field, specify a name for the WSDL document. By default, Developer
assigns the document the name serviceName.wsdl.
3 Click Save. The WSDL generator generates the WSDL document. Developer then
displays a message that lists the WSDL document file and the directory in which it
stored the file.
4 Click OK.

Note: If an error occurs during WSDL generation, Developer displays a message to

that effect.

Web Services Developer’s Guide Version 6.0.1 43

CHAPTER 5 Generating a WSDL Document that Uses the SOAP Message Protocol

44 Web Services Developer’s Guide Version 6.0.1

 CHAPTER 6
Generating a WSDL Document that Uses the HTTP POST or
GET Protocol

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Service Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Web Services Developer’s Guide Version 6.0.1 45

CHAPTER 6 Generating a WSDL Document that Uses the HTTP POST or GET Protocol

Overview
When you specify HTTP POST as the protocol for Web service consumers to use to
communicate with a Web service, you can specify text/XML or URL encoded as the input
format for the service. When you select HTTP GET as the protocol, Developer
automatically sets the input format to URL encoded.
When you specify HTTP POST or HTTP GET as the protocol for the WSDL document,
keep the following points in mind:
When you select URL encoded as the input format, the WSDL generator uses the
input parameters declared on the Input/Output tab of the service to create the input
message for the WSDL document. However, for the URL encoded input format, the
input signature can only contain String variables. The input signature should not
contain document, document list, Object, Object list, String list, or String table
variables because these variables cannot be represented in name=value pairs in the
HTTP request.
When you select text/XML as the input format, you can select an IS document type or
XML Schema component (element declaration) to describe the incoming XML
document.
For the HTTP protocols, Developer selects text/XML as the output format. You must
select an IS document type or XML Schema component (element declaration) to
represent the outbound XML document.
For more information about describing the service input and output for the HTTP
protocols, see “Input and Output Signature Requirements” on page 47.

Service Requirements
When you specify HTTP POST or HTTP GET as the protocol for a WSDL document, the
target service for which you are generating the WSDL document must meet these
requirements:
The service must return an XML document to Web service consumers. When
generating a WSDL document, the WSDL generator assumes that all services invoked
via an HTTP request will return an XML document (text/xml content). To return an
XML document, a service can do one of the following:
Call the pub.flow:setResponse service. This service takes any string and returns it as
the body of an HTTP response. For more information about the pub.flow:setResponse
service, see the webMethods Built-In Services Reference Guide.
Create and assign an XML output template to the service. You can use an XML
output template to extract values from the pipeline and insert those values as
element content in an XML tag. For more information about output templates, see
DSPs and Output Templates Developer’s Guide.

46 Web Services Developer’s Guide Version 6.0.1

 Input and Output Signature Requirements

Important! You must use the pub.flow:setResponse service or an XML output template to
return an XML document, or Integration Server will return an HTML document to the
HTTP request.

If you select HTTP POST as the protocol and text/XML as the input format, the service
input signature must include an object type named node. When webMethods
Integration Server receives an HTTP POST request where the Content-Type header is
text/XML, the server automatically parses the body of the request (the XML
document) and passes it as an XML node to the service specified in the request’s URL.
To extract data from the returned node, you query it using the pub.xml:queryXMLNode
service or convert it to a document using the pub.xml:xmlNodeToDocument service.

Note: An XML node is an element-based representation of an XML document. The

node expresses a document in a tree-like structure that allows the data within it to be
addressed and linked into services.

Because an XML node object does not provide meaningful signature information for
the WSDL document, you can select an IS document type or XML Schema component
to describe the input signature. The IS document type or XML Schema component
you select describes the XML document the service expects as input. See “Input and
Output Signature Requirements” for more information about specifying IS document
types and XML Schema components.
In addition to these requirements, you should also check the target service’s Execute ACL
permission to ensure that consumers of the service can invoke it.

Input and Output Signature Requirements

When you specify HTTP POST or GET as the protocol for accessing a Web service, you can
specify an IS document type or an XML Schema element declaration to represent the
input and output signature of the service. The signature describes the XML documents the
service requires as input and produces as output.

Text/XML Requirements
The following table lists the requirements for developing the service’s input and output
signature when text/XML is selected as the input or output format. The other chapters that
describe how to generate WSDL documents also contain this table so you can easily
compare requirements across protocols.

Web Services Developer’s Guide Version 6.0.1 47

CHAPTER 6 Generating a WSDL Document that Uses the HTTP POST or GET Protocol

Service signature requirements when text/XML is specified as the input or output format

Case Applies? Notes

Field types at the top level

Top-level strings are allowed. Yes

Top-level objects and documents are allowed. Yes
Top-level string, object, and document lists No Including a string, object, or document list at
are allowed. the top level will not result in a WSDL
generation error. However, top-level lists
cannot be represented in a WSDL document.
Top-level string tables are allowed. No
Field types below the top level

Strings, objects, and documents are allowed. Yes

String, object, and document lists are allowed. Yes
String tables are allowed. No
Field names

Field names can contain a prefix without an No

associated XML namespace.
Field names can be associated with an XML No
namespace without a prefix.
Field names must conform to QName lexical Yes
rules (that is, the prefix and local name must
conform to NCName rules specified in
http://www.w3.org/TR/
REC-xml-names/#NT-NCName).
String field names can begin with the Yes Naming a top-level field *body, or beginning
character @ or be named *body. the name of a top-level field with the character
@, will not result in a WSDL generation error.
However, because mixed content models or
attributes cannot be represented in a WSDL
document’s message element, these fields will
not appear in a client generated from this
WSDL document.
Fields of type other than scalar string can have No
names that begin with the character @ or be
named *body.

48 Web Services Developer’s Guide Version 6.0.1

 Input and Output Signature Requirements

Case Applies? Notes

Duplicate field names

Fields at the same level (that is, beneath the

same parent field in the input or output of the
same signature) can have the same name and
Same type and properties. Yes
Different type and properties. Yes However, the WSDL generator uses only one
field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
More than one field named *body can occur at No
the same level.
Duplicate field names that begin with the No
character @ can repeat at the same level.
Fields at different levels can have the same
name and
Different or no XML namespace values, Yes
even though they may have different type
and properties.
Duplicate XML namespace values and the Yes
same type and properties.
Duplicate XML namespace values and Yes However, the WSDL generator uses only one
different type and properties. field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
Field properties

Document or Document list type fields can be Yes

open (that is, contain a check mark in the Allow
unspecified fields check box on the Constraints
tab of the Variable Properties dialog box).
Top-level fields must be associated with an No
XML namespace.
Fields beneath the top level must be No
associated with an XML namespace.

Web Services Developer’s Guide Version 6.0.1 49

CHAPTER 6 Generating a WSDL Document that Uses the HTTP POST or GET Protocol

Case Applies? Notes

Recursive documents are allowed. Yes The Integration Server will generate the WDSL
document but cannot create a Web service
connector from the WSDL document.
Field type constraints

Object constraints are allowed. Yes However, the WSDL generator does not
represent them in the WSDL document.
Strings constrained by older schema types Yes However, the WSDL generator maps them into
(types defined before the W3C XML 2001 2001 XML Schema types.
Schema recommendations) are allowed.

Note: By default, a field must exist at run time, can contain a null value, and (for document
type fields), cannot contain unspecified fields. If you change a field's default properties,
the WSDL generator reflects those changes in the schema section of the WSDL document.
However, the message element of a WSDL document cannot define these properties.
Therefore, when you use the WSDL document to generate a Web service connector, the
Integration Server uses the default properties for all top-level fields.

In addition, The WSDL generator treats variables with the same QName as identical
variables even if the variables are declared as different types.

URL Encoded Requirements

The following table lists the requirements for developing the service’s signature when
URL encoded is selected as the input format. The other chapters that describe how to
generate WSDL documents also contain this table so you can easily compare requirements
across protocols.

Service signature requirements when URL encoded is specified as the input format

Case Applies? Notes

Field types at the top level

Top-level strings are allowed. Yes

Top-level objects and documents are allowed. No
Top-level string, object, and document lists No
are allowed.
Top-level string tables are allowed. No
Field types below the top level

50 Web Services Developer’s Guide Version 6.0.1

 Input and Output Signature Requirements

Case Applies? Notes

Strings, objects, and documents are allowed. n/a The URL encoded input format does not
support documents.
String, object, and document lists are allowed. n/a The URL encoded input format does not
support documents.
String tables are allowed. n/a The URL encoded input format does not
support documents.
Field names

Field names can contain a prefix without an No

associated XML namespace.
Field names can be associated with an XML No
namespace without a prefix.
Field names must conform to QName lexical Yes
rules (that is, the prefix and local name must
conform to NCName rules specified in
http://www.w3.org/TR/
REC-xml-names/#NT-NCName).
String field names can begin with the No
character @ or be named *body.
Fields of type other than scalar string can have n/a The URL encoded input format supports only
names that begin with the character @ or be scalar string fields.
named *body.
Duplicate field names

Fields at the same level (that is, beneath the

same parent field in the input or output of the
same signature) can have the same name and
Same type and properties. Yes
Different type and properties. Yes However, the WSDL generator uses only one
field’s type and properties for all fields with
that name at that level. Because the method
used to select the field is not defined,
webMethods recommends avoiding this case.
More than one field named *body can occur at No Fields cannot contain asterisks (*) anywhere in
the same level. the field name.
Duplicate field names that begin with the No Fields cannot contain the character @ anywhere
character @ can repeat at the same level. in the field name.
Fields at different levels can have the same
name and

Web Services Developer’s Guide Version 6.0.1 51

CHAPTER 6 Generating a WSDL Document that Uses the HTTP POST or GET Protocol

Case Applies? Notes

Different or no XML namespace values, n/a The URL encoded input format does not
even though they may have different type support XML namespaces.
and properties.
Duplicate XML namespace values and the n/a The URL encoded input format does not
same type and properties. support XML namespaces.
Duplicate XML namespace values and n/a The URL encoded input format does not
different type and properties. support XML namespaces.
Field properties

Document or Document list type fields can be n/a The URL encoded input format does not
open (that is, contain a check mark in the Allow support Document or Document list type
unspecified fields check box on the Constraints fields.
tab of the Variable Properties dialog box).
Top-level fields must be associated with an No The URL encoded input format does not
XML namespace. support XML namespaces. Therefore, fields
must not be associated with an XML namespace.
Fields beneath the top level must be n/a The URL encoded input format does not
associated with an XML namespace. support documents.
Recursive documents are allowed. n/a The URL encoded input format does not
support documents.
Field type constraints

Object constraints are allowed. Yes However, the WSDL generator does not
represent them in the WSDL document.
Strings constrained by older schema types Yes However, the WSDL generator maps them into
(types defined before the W3C XML 2001 2001 XML Schema types.
Schema recommendations) are allowed.

Note: By default, a field must exist at run time, can contain a null value, and (for document
type fields), cannot contain unspecified fields. If you change a field's default properties,
the WSDL generator reflects those changes in the schema section of the WSDL document.
However, the message element of a WSDL document cannot define these properties.
Therefore, when you use the WSDL document to generate a Web service connector, the
Integration Server uses the default properties for all top-level fields.

In addition, The WSDL generator treats variables with the same QName as identical
variables even if the variables are declared as different types.

52 Web Services Developer’s Guide Version 6.0.1

 Generating the WSDL Document

Generating the WSDL Document

To create a WSDL document that specifies the HTTP POST or HTTP GET protocol, you do
the following:

Stage Description

1 Identify the service for which you want to generate a WSDL document.

2 Specify the protocol and transport mechanism for Web service consumers to
use to communicate with the Web service.

3 Specify the input format of the Web service.

4 Describe the output format of the Web service.

5 Specify the target namespace for the generated WSDL document.

6 Generate the WSDL document.

Stage 1 To identify the Web service

1 In the Navigation Panel, select the service for which you want to generate a WSDL
document.
2 On the Tools menu, click Generate WSDL. Developer opens the Generate WSDL dialog
box.

Generate WSDL dialog box

Web Services Developer’s Guide Version 6.0.1 53

CHAPTER 6 Generating a WSDL Document that Uses the HTTP POST or GET Protocol

3 In the Host box, type the numeric IP address or domain name of the host machine on
which the Web service will reside at production time.
By default, the Host box identifies the Integration Server on which the Web service
currently resides; that is, the Integration Server to which you are currently connected.
You do not need to specify http:// or https:// as part of the host name; the WSDL
generator automatically adds http:// or https:// (based on the transport
mechanism you specify in the Via Transport box) to the host name when it compiles the
network address for the Web service.
4 In the Port box, type the number of the port you want to use to accept requests for the
Web service from Web service consumers.
By default, the Port box identifies the port you used to open the current Integration
Server. If you want to use a different port, type the number of that port in the Port box.
The port you identify must be able to accept either HTTP requests or HTTPS requests.
If you do not require that requests from Web service consumers be sent securely,
specify a port that accepts HTTP requests. If you want requests from Web service
consumers to be sent securely, specify a port that accepts HTTPS requests.

Stage 2 To specify the protocol

1 Under Protocol, click HTTP-POST or HTTP-GET. Developer changes the boxes on the
dialog box. The following figure shows an example of the dialog box when you click
HTTP-POST; when you click HTTP-GET, the dialog box is similar, except that the Input
format and Input boxes are disabled.

Generate WSDL dialog box with HTTP-POST selected

54 Web Services Developer’s Guide Version 6.0.1

 Generating the WSDL Document

2 Under Via Transport, click the request transport mechanism that is accepted by the port
you specified in the Port box. If the port accepts HTTP requests, click HTTP. If the port
accepts HTTPS requests, click HTTPS.
3 The Integration Server’s default directive for invoking services via an HTTP request is
invoke. If you need to specify another directive for Web service consumers to use to
invoke the service, type the directive in the Directive box.
4 By default, the Path box provides the path to the Web service as it currently exists in
the Navigation Panel. If the Web service will reside in a different folder at production
time, type the path to that folder in the Path box. Use the format
folder.subfolder.subfolder/service.
5 If you selected HTTP-GET as the protocol for Web service consumers to use to
communicate with the Web service, skip to “To describe the output signature for the
Web service” on page 57. If you selected HTTP-POST, continue with “To specify the
input format of the Web service (HTTP-POST protocol only)” on page 55.

Stage 3 To specify the input format of the Web service (HTTP-POST protocol only)

If you selected HTTP-POST as the protocol for Web service consumers to use to
communicate with the Web service, you must specify the input format in which the
Web service requires input. You can specify the input format in one of the following
ways:

If the Web service expects input in the form of... Take this action...

Name=value pairs in the POST that Click URL encoded in the Input format
invokes the Web service list, then skip to “To describe the
output signature for the Web service”
on page 57. The WSDL generator
uses the input signature on the
Input/Output tab of the Web service to
create the input message for the
WSDL document.
An XML document, and you want to Go to “To describe the input
describe the input signature for the WSDL signature using an IS document
document using an IS document type type” on page 56.
An XML document, and you want to Go to “To describe the input
describe the input signature for the WSDL signature using an XML Schema” on
document using an element declaration page 56.
from an XML Schema

Web Services Developer’s Guide Version 6.0.1 55

CHAPTER 6 Generating a WSDL Document that Uses the HTTP POST or GET Protocol

To describe the input signature using an IS document type

1 In the Input format list on the Generate WSDL dialog box, click text/xml.

2 Next to the Input box, click . Developer opens the Select Input/Output Constraint dialog
box.

Select Input/Output Constraint dialog box

3 Under Choose Constraint Type, click Document Type.

4 Identify the IS document type you want to use to describe the input format. You can
either type the fully qualified name of the IS document type in the Name box or click
the IS document type in the Folder box.
5 Click OK. Developer closes the dialog box and displays the fully qualified name of the
IS document type in the Input box on the Generate WSDL dialog box.

To describe the input signature using an XML Schema

1 In the Input format list, click text/xml.

2 Next to the Input field, click . Developer opens the Select Input/Output Constraint
dialog box.
3 Under Choose Constraint Type, click Schema Component.
4 In the text field, after http://, type the Web location and name of the XML Schema that
contains the element declaration you want to use to describe the input signature.

56 Web Services Developer’s Guide Version 6.0.1

 Generating the WSDL Document

Important! The XML Schema you identify must be located on the Web and must be
accessible to consumers of the WSDL.

5 Click Load. Expand the ELEMENTS headings to view the global element declarations
in the XML Schema.

Note: If an XML Schema definition does not contain an element declaration, Developer
does not display the ELMENTS heading.

6 Select the global element declaration that you want to use to represent the input
signature.
7 Click OK. Developer closes the dialog box and displays the name of the selected
element in the Input box on the Generate WSDL dialog box.

Stage 4 To describe the output signature for the Web service

Describe the XML document the Web service produces as output. Complete the Output
format box using the instructions in “To specify the input format of the Web service (HTTP-
POST protocol only)” on page 55.

Stage 5 To specify the target namespace for the WSDL document

1 In the Target Namespace box, specify the target namespace for the WSDL document.
By default, the Target Namespace box displays http://host/ as the target namespace,
where host is the name of the server you are currently logged on to. If you want to
specify a different namespace, type the URI for that namespace in the box.
2 Click OK. Developer displays a dialog box that prompts you for a location and name
for the generated WSDL document.

Stage 6 To generate the WSDL document

1 Under Save in, select the directory in which you want to save the generated WSDL
document.
2 In the File name field, specify a name for the WSDL document. By default, Developer
assigns the document the name serviceName.wsdl.
3 Click Save. The WSDL generator generates the WSDL document. Developer then
displays a message that lists the WSDL document file and the directory in which it
stored the file.
4 Click OK.

Web Services Developer’s Guide Version 6.0.1 57

CHAPTER 6 Generating a WSDL Document that Uses the HTTP POST or GET Protocol

Note: If an error occurs during WSDL generation, Developer displays a message to

that effect.

58 Web Services Developer’s Guide Version 6.0.1

 APPENDIX A
WSDL Documents

Basic Elements in WSDL Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

WSDL Namespace Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Sample WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Web Services Developer’s Guide Version 6.0.1 59

APPENDIX A WSDL Documents

Basic Elements in WSDL Documents

The following table describes the basic elements in a WSDL document.

Element Description
<definitions> Contains the elements that describe a Web service.
<types> Contains the type definitions that describe the data that is received
and sent by the Web service. The <types> element can reference
entire XML Schemas and can contain simple type definitions,
complex type definitions, and element declarations. The type
definitions and element declarations help define the input and
output parameters for the Web service. WSDL uses XML Schema as
its native type system.
<message> Specifies the data that is received and sent by the Web service. A
<message> element describes a set of input parameters or a set of
output parameters. Each <message> element can contain one or
more <part> elements. A <part> element associates a piece of data
with a name and a type definition or element declaration. The type
definition or element declaration referenced by the <part> element
can be defined, declared, or referenced in the <types> element.
<operation> Specifies the messages that are received and sent by the Web service.
Within the <operation> element, the <input> element identifies the
message whose parts specify the input parameters to the Web
service while the <output> element identifies the message whose
parts specify the output parameters of the Web service. Essentially,
the operation specifies the signature for the Web service. An
<operation> element is declared within a <portType> element.
<portType> Defines a named set of operations. The <portType> element
associates a port type name with a set of operations. A <portType>
element can contain multiple operations.
<binding> Specifies the protocol and message format to use to access the
operations in a port type. Each <binding> element can specify only
one protocol for a port type; however, a WSDL document can define
more than one binding for a single port type. A WSDL document
should include one <binding> element for each protocol that it
supports.

60 Web Services Developer’s Guide Version 6.0.1

 WSDL Namespace Declaration

Element Description
<port> Associates a binding with a network address. Together, the binding
and network address specify how to invoke a Web service. Each port
can specify only one network address for a binding; however,
multiple ports can be defined for a single Web service. Port elements
are defined within the <service> element.
<service> Groups ports that can be used to call Web services. A <service>
element can contain many ports.

The Address Element

The <address> element in the <port> element specifies the location of a Web service.
More specifically, the <address> element carries a location attribute that specifies the
network address for a service. The WSDL generator creates a value for this attribute using
the protocol, transport, host, port, and directive information that you provide when you
generate the WSDL document.
For WSDL documents that specify SOAP-RPC or SOAP-MSG as the protocol, the
location attribute in the <address> element has this format:

transport://host:port/soap/directive
For WSDL documents that specify HTTP-POST or HTTP-GET as the protocol, the
location attribute in the <address> element is used with the location attribute in the
<operation> element to specify the URL used to call the service. For WSDL documents
that specify HTTP-POST and HTTP-GET as the protocol, the location attribute in the
<address> element has this format, where directive is almost always invoke:

transport://host:port/directive
The location attribute in the <operation> element specifies the fully qualified path
name of the service on the webMethods Integration Server and has this format:
folder.subfolder/service

WSDL Namespace Declaration

WSDL documents use the namespace http://schemas.xmlsoap.org/wsdl/ to qualify the
elements and attributes used to create the framework of WSDL documents. By
convention, the WSDL namespace is given the prefix wsdl. The primary purpose of the
WSDL namespace is to distinguish WSDL-related elements and attributes from elements
and attributes defined in other namespaces.
The following namespace prefixes are commonly found in a WSDL document and are
inserted in WSDL documents generated by the WSDL generator. The WSDL generator is
the subsystem of Integration Server that generates the WSDL document for a service.

Web Services Developer’s Guide Version 6.0.1 61

APPENDIX A WSDL Documents

Prefix Namespace URI Description

mime http://schemas.xmlsoap.org/wsdl/mime/ Namespace defined by the WSDL

specification for associating a
binding with the MIME protocol.
wsdl http://schemas.xmlsoap.org/wsdl/ WSDL namespace for the WSDL
framework.
webM http://www.webMethods.com/ Deprecated. This prefix is no
noNamespace longer used.
soap http://schemas.xmlsoap.org/wsdl/soap/ Namespace defined by the WSDL
specification for associating a
binding with the SOAP protocol.
http http://schemas.xmlsoap.org/wsdl/http/ Namespace defined by the WSDL
specification for associating a
binding with the HTTP GET and
HTTP POST protocols.
xsd http://www.w3.org/2001/XMLSchema W3C XML 2001 Schema.
tns The target namespace for the WSDL The namespace to which elments
document in the WSDL document belong.
This includes elements such as
<types>, <portType>,
<operation>, <message>, and
<binding>. Elements and type
definitions defined within the
<schema> tag (contained in the
<types> element) belong to a
different target namespace.

Note: In an XML schema definition,

the target namespace defines the
namespace to which the element
declarations, attribute
declarations, and type definitions
belong.

62 Web Services Developer’s Guide Version 6.0.1

 Sample WSDL Document

Sample WSDL Document

The following figure shows a sample WSDL document.

<?xml version="1.0" encoding="UTF-8"?>

The definitions element <wsdl:definitions name="AuthenticateUser"
is the root element of targetNamespace="http://www.example.com/"
the WSDL document. xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
The WSDL document xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
uses these Namespace xmlns:tns="http://www.example.com"
prefixes.
xmlns:xsd="http://www.w3.org/2001/XMLSchema"

A types element <wsdl:types>

encloses the data types <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
associated with the parts targetNamespace="http://localhost/AuthenticateUser/AuthenticateUser"
in a message. xmlns:tns="http://localhost/AuthenticateUser/AuthenticateUser">

<xsd:complexType name="__AuthenticateUserInput">
<xsd:sequence>
<xsd:element name="userName" nillable="true" type="xsd:string"/>
<xsd:element name="password" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="__AuthenticateUserOutput">
<xsd:sequence>
<xsd:element name="isValid" nillable="true" type="xsd:boolean"/>
</xsd:sequence>
</xsd:complexType>

</xsd:schema>
</wsdl:types>

The message specifies <wsdl:message name="AuthenticateUserInput">

the name and type of <wsdl:part name="userName" type="xsd:string"/>
data exchanged by the <wsdl:part name="password" type="xsd:string"/>
Web service. </wsdl:message>

<wsdl:message name="AuthenticateUserOutput">
<wsdl:part name="isValid" type="xsd:boolean"/>
</wsdl:message>

Web Services Developer’s Guide Version 6.0.1 63

APPENDIX A WSDL Documents

A portType groups the <wsdl:portType name="AuthenticateUserPortType">

operations performed by <wsdl:operation name="AuthenticateUser">
the Web service. <wsdl:input message="tns:AuthenticateUserInput"/>
<wsdl:outputmessage="tns:AuthenticateUserOutput"/>
</wsdl:operation>
</wsdl:portType>

A binding describes the <wsdl:binding name="AuthenticateUserBinding"

data format and type="tns:AuthenticateUserPortType">
protocol for a port type. <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="rpc"/>
<wsdl:operation name="AuthenticateUser">
<soap:operation soapAction="" />
<wsdl:input>
Each operation
identifies the data <soap:body
(messages) sent and encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
received by the Web namespace="http://www.example.com" use="encoded"/>
service. </wsdl:input>
<wsdl:output>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://www.example.com" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>

A service is a collection <wsdl:service name="AuthenticateUserService">

of ports. <wsdl:port name="AuthenticateUserPort0"
binding="tns:AuthenticateUserBinding">
A port associates a <soap:address location="http://localhost:5555/soap/rpc"/>
binding with a network </wsdl:port>
address.
</wsdl:service>

</wsdl:definitions>

64 Web Services Developer’s Guide Version 6.0.1

 APPENDIX B
Web Service-Related Errors and Warnings

Message Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Web Service-Related Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Web Services Developer’s Guide Version 6.0.1 65

Appendix B Web Service-Related Errors and Warnings

Message Display
When you generate a WSDL document or create a Web service connector from a WSDL
document, Developer displays a message that indicates whether the process completed
successfully.
If the process completed successfully but warnings occurred, Developer displays a
message to that effect. If the process did not complete successfully, Developer displays a
message that says errors occurred.
When you click Details on the message dialog box, Developer provides information similar
to the information in the message dialog box shown below.

Name and location of WSDL document

in which error or warning occurred.

Location of the error

or warning in the
WSDL document.

Message code.

WSDL elements
that caused the
error or warning.

Note: When generating a Web service connector, Developer might generate some of the
flow steps in the Web service connector or some of the supporting IS elements (IS
document types, folders, or IS schemas) before it encounters errors or warnings. The
generated elements appear in the Navigation Panel.

66 Web Services Developer’s Guide Version 6.0.1

 Web Service-Related Errors and Warnings

Web Service-Related Errors and Warnings

Following are the error messages and warning messages that can occur when
webMethods Developer generates a WSDL document or creates a Web service connector
using a WSDL document.

Messages Received When Generating a WSDL Document

[ISC.0077.9014] Document to XSD error: Field {0} cannot be represented in XML Schema. The field
name does not conform to the XML NCName definition.
The name of an IS document type variable or XML Schema element in the input signature
used to generate a WSDL document contains characters that cannot be mapped to XML
Schema.
Field names used in the input signature must conform to the QName lexical rules
specified in http://www.w3.org/TR/REC-xml-names/#NT-QName and the XML
namespace and local naming conventions specified rules specified in
http://www.w3.org/TR/REC-xml-names/#NT-NCName.

[ISC.0082.9106] Warning: Complex type {0} is recursive. webMethods Integration Server does not
support creating a document type from an XSD with a recursive complex type.
The IS document type selected to describe the input or output signature contains a
recursive document type reference (for example, the IS document type contains a
document reference to itself). Because recursive document type references correspond to
recursive complex type definitions in XML Schema, the WSDL generator can successfully
create the WSDL file. However, the Integration Server does not support creating IS
document types from XML Schemas with recursive complex type definitions.
Consequently, the Integration Server will not be able to create a Web service connector
from the generated WSDL document.

[ISC.0124.9001] Document to XSD warning: For interoperability reasons, the <any> type is not used in
SOAP RPC WSDL. Document {0} will be defined as closed in the XSD.
The IS document type you are using to generate a WSDL document contains variables of
type Document or Document list. These variables are open (that is, their Allow unspecified
fields property is set to true).
To resolve this warning, clear the Allow unspecified fields check box on the Constraints tab of
the Variable Properties dialog box. Then, regenerate the WSDL document.

Web Services Developer’s Guide Version 6.0.1 67

Appendix B Web Service-Related Errors and Warnings

[ISC.0124.9002] Document to XSD error: Document {0} cannot be represented in XML Schema. This
document contains a *body field constrained by a simple type and fields that would be represented as
elements in the XSD. XSD could describe this document if the simple type constraint was removed or
the non-attribute fields were deleted.
The IS document type you are using to generate a WSDL document contains a variable
named *body that is constrained by a simple type. The IS document type also contains
fields that are mapped as elements (not attributes) in the XSD. This combination cannot be
mapped in an XSD.
In a mixed content environment, the Integration Server can only map complex type
definitions of simple content (that is, an IS document type containing attributes and a
*body variable with or without a simple type constraint) or complex type definitions of
complex content (that is, an IS document type containing attributes and/or elements and a
*body variable that is not constrained).

To resolve this error, do one of the following:

Remove the non-attribute fields.

Remove the *body variable’s simple type constraint by selecting No Constraints

Specified in the Content Type field of the Constraints tab on the variable’s Properties dialog
box.

[ISC.0124.9003] Document to XSD error: Referenced document type {0} does not exist.
The IS document type you are using to generate a WSDL document contains a reference to
a nonexistent document type.
To resolve this error, restore the nonexistent document type or remove the reference to it.

[ISC.0124.9004] Document to XSD error: Field {0} is a String table. String tables cannot be represented
in XML Schema.
The IS document type you are using to generate a WSDL document contains String table
variables. XML Schema does not support multi-dimensional arrays.
To resolve this error, remove the String table variable from the IS document type or select
a different IS document type.

[ISC.0124.9005] Document to XSD error: Field {0} cannot be represented in XML Schema. The field
name contains a prefix but an XML Namespace property is not assigned to the field.
The IS document type you are using to generate a WSDL document contains a top-level
variable whose name includes a prefix (that is, the name is in the format prefix:local name).
This variable is not associated with an XML namespace.
To resolve this error, do one of the following:
Associate the variable with an XML namespace by selecting the variable in Developer,
selecting EditProperties, and then typing the namespace for the variable in the XML
Namespace field on the General tab.

68 Web Services Developer’s Guide Version 6.0.1

 Web Service-Related Errors and Warnings

Remove the prefix.

Important! Some protocols require the use of a prefix. Before removing the prefix, check
the service signature’s input and output requirements as documented for each
protocol in this guide.

[ISC.0124.9006] Document to XSD error: Field {0} cannot be represented in XML Schema. The field
name does not conform to the XML NCName definition.
The IS document type you are using to generate a WSDL document contains field names
that do not conform to the XML NCName definition.
To resolve this error, rename the fields to conform to the QName lexical rules specified in
http://www.w3.org/TR/REC-xml-names/#NT-QName and the XML namespace and local
naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName.

[ISC.0124.9007] Document to XSD error: Document {0} cannot be represented in XML Schema. The
document contains multiple *body fields.
The IS document type or XML Schema element declaration you are using to generate a
WSDL document contains more than one field named *body at the same level.
To resolve this error, remove or rename the duplicate *body fields.

[ISC.0124.9008] Document to XSD error: Document {0} cannot be represented in XML Schema. The
document contains multiple attributes of the same name at the same level.
The IS document type or XML Schema element declaration you are using to generate a
WSDL document contains attributes at the same level with the same name.
To resolve this error, remove or rename the duplicate attributes.

[ISC.0124.9009] Document to XSD error: Field {0} cannot be represented in XML Schema. Attributes
cannot have dimension greater than 0.
The IS document type or XML Schema element declaration you are using to generate a
WSDL document contains array or table type attributes. XML Schema does not support
multi-dimensional attributes.
To resolve this error, remove the attribute from the IS document type or redefine its type
to String.

[ISC.0124.9011] Document to XSD error: Simple type {0} does not exist.
The IS document type you are using to generate a WSDL document contains a reference to
a nonexistent simple type that has been applied to a variable as a content type constraint.
To resolve this error, do one of the following:

Web Services Developer’s Guide Version 6.0.1 69

Appendix B Web Service-Related Errors and Warnings

Restore the nonexistent simple type by generating a schema on the server that defines
the missing type. To do so, you can either create a schema from an XSD or enable or
import a package that contains a schema with the missing type.
Remove the reference to the missing type by selecting No Constraints Specified in the
Content Type field of the Constraints tab on the variable’s Properties dialog box.

[ISS.0092.9032] Error: Input signature cannot be used to generate WSDL using URL Encoded format.
Field {0} cannot be represented in XML Schema. The field name does not conform to the XML NCName
definition.
A top-level IS document type variable or XML Schema element in the input signature
used to generate a WSDL document is named *body or contains the characters *, @, or :.
These characters represent XML Schema components (mixed content, attributes, and XML
namespace prefixes) that are not applicable to URL encoded parameters.
When URL encoded is specified as the input format for the HTTP POST or HTTP GET
protocols, field names used in the input signature must conform to the QName lexical
rules specified in http://www.w3.org/TR/REC-xml-names/#NT-QName and the XML
namespace and local naming conventions specified rules specified in
http://www.w3.org/TR/REC-xml-names/#NT-NCName.

[ISS.0092.9033] Error: Input signature cannot be used to generate WSDL using URL Encoded format.
Fields cannot have XML Namespace values.
The input signature used to generate a WSDL document contains fields that are associated
with an XML namespace. Fields must not be associated with an XML namespace when
you select either of the following:
HTTP GET as the protocol

HTTP POST as the protocol and URL encoded as the input format

[ISS.0092.9039] Error: URL encoding does not support input variables other than strings and string
lists.
The input parameters declared on the Input/Output tab contain a variable that is not a String
or a String list. When URL encoded is specified as the input format for the HTTP POST or
HTTP GET protocols, Integration Server uses the input parameters declared on the
Input/Output tab of the service to construct the input message for the WSDL document. For
the URL encoded input format, the input signature can contain only String and String list
variables. The input signature should not contain document, document list, Objects,
Object lists, or String table variables because these variables cannot be represented in
name=value pairs in the HTTP request.

[ISS.0092.9042] Error: text/xml does not support string tables.

When you generate a WSDL document and specify HTTP POST or HTTP GET as the
protocol, you can select an IS document type to describe the format of the XML document
expected by or produced by the service. The IS document type cannot contain a String

70 Web Services Developer’s Guide Version 6.0.1

 Web Service-Related Errors and Warnings

table variable because multi-dimensional arrays cannot be represented in an XML

Schema. (Developer generates an XML Schema to define types for variables in the IS
document type.)
To resolve this error, remove the String table variable from the IS document type, or select
a different IS document type.

Messages Received When Creating a Web Service Connector

[ISS.0092.9001] Server Error: {0}
A server error occurred while Developer was generating the Web service connector.
Click Details on the message dialog box to view the errors.

[ISS.0092.9002] Warning: Document does not contain service element, no ports were generated for
any Web Service Connector.
The WSDL document does not contain a <service> element, and therefore does not
contain any <port> elements. (A <service> element is a collection of <port> elements.)
Developer generates the Web service connector, but the Web service connector will not
specify any flow MAP steps for setting the port information. In the Web service connector,
the BRANCH on '/_port' step contains a child port MAP step for each unique <port>
associated with the <operation>. The BRANCH on '/_port' step will not contain child port
MAP steps. The Web service connector cannot execute successfully without port
information because the port information specifies the network address for invoking the
Web Service.

[ISS.0092.9003] Error: SOAP binding does not contain extended element

http://schemas.xmlsoap.org/wsdl/soap/binding, binding was not created.
The <binding> element is missing the <soap:binding> element. If the WSDL document
specifies SOAP as a protocol, the <binding> element must contain <soap:binding> as
the first child element.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. (In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.)

[ISS.0092.9004] Error: SOAP binding does not contain transport value, binding was not created.
In the WSDL document, the <soap:binding> element contains a transport attribute but
no value is specified for it. The transport value indicates which transport of SOAP the
binding uses. It is required for a SOAP binding and its value must be
http://schemas.xmlsoap.org/soap/http.

Web Services Developer’s Guide Version 6.0.1 71

Appendix B Web Service-Related Errors and Warnings

Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.

[ISS.0092.9005] Error: SOAP binding has an unsupported transport value, binding was not created.
In the WSDL document, the transport attribute in the <soap:binding> element specifies
an unsupported SOAP transport. Developer can generate a binding for a SOAP binding
only if the transport value is http://schemas.xmlsoap.org/soap/http.
webMethods Developer generates the Web service connector, but the Web service
connector does not contain a SEQUENCE step that corresponds to this binding. In the
Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step
for each unique <binding> associated with an <operation>.

[ISS.0092.9006] Error: SOAP binding does not contain a transport attribute, binding was not created.
In the WSDL document, the <soap:binding> element does not contain a transport
attribute. The transport value indicates which transport of SOAP the binding uses. It is
required for a SOAP binding. The transport attribute value must be
http://schemas.xmlsoap.org/soap/http.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.

[ISS.0092.9007] Error: SOAP binding has an unrecognized style value, binding was not created.
In the WSDL document, the <soap:binding> element specifies a value other than rpc or
document for the style attribute.

Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.

[ISS.0092.9008] Error: HTTP binding does not contain extended element

http://schemas.xmlsoap.org/wsdl/http/binding, binding was not created.
The <binding> element is missing the <http:binding> element. If the WSDL document
specifies HTTP as a protocol, the <binding> element must contain <http:binding> as
the first child element.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.

72 Web Services Developer’s Guide Version 6.0.1

 Web Service-Related Errors and Warnings

[ISS.0092.9009] Error: HTTP binding does not contain required verb attribute, binding was not created.
In the WSDL document, the <http:binding> element does not contain the verb attribute.
The value of the verb attribute must be GET or POST.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.

[ISS.0092.9010] Error: HTTP binding has an unsupported verb attribute, binding was not created.
In the WSDL document, the <http:binding> element specifies a verb attribute value
other than GET or POST.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. (In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.)

[ISS.0092.9011] Error: Mime binding style is unsupported, binding was not created.
The WSDL document specifies a MIME binding style for the entire <binding>.
webMethods Developer only supports the MIME binding style to describe the inputs and
outputs of an HTTP binding. webMethods Developer cannot generate a binding when the
MIME binding style is specified outside of the HTTP binding context.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. (In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique
<binding> associated with an <operation>.)

[ISS.0092.9013] Warning: The operation's binding does not have any ports, no ports were generated
for the Web Service Connector.
Developer cannot find a <port> element that corresponds to a particular <binding>
element. A <port> element specifies a network address or endpoint for a binding.
Developer generates the Web service connector, but does not generate any MAP steps for
setting the binding and address information. In a Web service connector, the BRANCH on
'/_port' step contains a child portName MAP step for each <port> associated with the
<operation>. When this warning occurs, the BRANCH on '/_port' step contains no child
portName MAP steps.

Web Services Developer’s Guide Version 6.0.1 73

Appendix B Web Service-Related Errors and Warnings

[ISS.0092.9014] Warning: The operation does not have any valid ports, no ports were generated for the
Web Service Connector.
The WSDL document does not contain any valid <port> elements for an <operation>.
The WSDL document might not contain any <port> elements or a <port> element might
reference a non-existent <binding> element. (A <binding> element associates a protocol
with an <operation>.)
Developer generates the Web service connector, but does not generate any portName MAP
steps for setting the binding and address information. In a Web service connector, the
BRANCH on '/_port' step contains a child portName MAP step for each <port> associated
with the <operation>. When this warning occurs, the BRANCH on '/_port' step contains
no child portName MAP steps.

[ISS.0092.9015] Warning: Port does not have a valid binding type, port was not generated.
The WSDL document contains a <port> element that does not contain the binding
attribute.
Developer generates the Web service connector, but does not generate a MAP step for this
port. In a Web service connector, the BRANCH on '/_port' step contains a child portName
MAP step for each <port> associated with the <operation>. The portName MAP step sets
the binding and address information for a port.

[ISS.0092.9016] Warning: Port does not have a location value, port was not generated.
Within the <port> element, the <address> element does not specify a value for the
location attribute. The location attribute specifies the network address or endpoint for
the service.
Developer generates a Web service connector, but without the network address,
webMethods Developer cannot generate a MAP step for this port. In a Web service
connector, the BRANCH on '/_port' step contains a child portName MAP step for each
<port> associated with the <operation>. The portName MAP step sets the binding and
address information for a port.

[ISS.0092.9017] Warning: Port does not have required address element, port was not generated.
The selected WSDL document does not contain an <address> element within the
specified <port> element. The <address> element carries an attribute that specifies the
location or network address for of the Web service.
Developer generates a Web service connector, but does not generate a MAP step for this
port. The portName MAP step sets the binding and address information for a port. Without
the <address> element, Developer cannot set the address information and therefore
cannot generate a MAP step.

74 Web Services Developer’s Guide Version 6.0.1

 Web Service-Related Errors and Warnings

[ISS.0092.9018] Warning: Port does not have required location attribute, port was not generated.
Within the <port> element, the <address> element does not carry the location attribute.
The location attribute specifies the network address for the service.
Developer generates a Web service connector, but does not generate a MAP step for this
port. The portName MAP step sets the binding and address information for a port. Without
the location attribute, Developer cannot set the address information, and therefore
cannot generate a MAP step.

[ISS.0092.9019] Warning: Port does not have a location value, port was not generated.
Within the <port> element, the <address> element does not specify a value for the
location attribute. The location attribute specifies the network address or endpoint for
the service.
Developer generates a Web service connector, but without the network address,
Developer cannot generate a MAP step for this port. The portName MAP step set the
binding and address information for a port. In a Web service connector, the BRANCH on
'/_port' step contains a child portName MAP step for each <port> associated with the
<operation>.

[ISS.0092.9020] Error: Operation is not referenced by any binding, Web Service Connector was not
created.
The WSDL document does not specify a <binding> element for the <operation>. Each
<operation> within a <portType> element needs to correspond to an <operation>
element within a <binding> element. Without a binding, the WSDL document does not
provide any information about how to invoke the Web service.
Developer does not generate a Web service connector for the <operation>.

[ISS.0092.9021] Error: Input and Output messages missing, invalid operation, Web Service Connector
was not created.
In the WSDL document, the <operation> element within a <portType> element does not
declare an input message or an output message. For Developer to generate a Web service
connector for the <operation>, the <operation> element must contain at least one
<input> element and at least one <output> element.

Developer does not generate a Web service connector for the <operation>.

[ISS.0092.9022] Error: Input message missing, Notification operations not supported. Web Service
Connector was not created.
In the WSDL document, the <operation> element does not declare an input message, but
it does declare an output message. In other words, the <operation> element does not
contain a child <input> element, but does contain a child <output> element. This
structure corresponds to the grammar for a notification operation. Developer does not
generate Web service connectors for notification operations.

Web Services Developer’s Guide Version 6.0.1 75

Appendix B Web Service-Related Errors and Warnings

[ISS.0092.9023] Error: Output message precedes Input message, Solicit Response operations not
supported. Web Service Connector was not created.
In the WSDL document, the <operation> element declares an <output> element (output
message) before the <input> element (input message). This describes a solicit-response
operation. Developer does not generate Web service connectors for solicit-response
operations.

[ISS.0092.9024] Error: HTTP binding has mime multipart Input. Multipart Input is not supported.
Binding was not generated.
The <binding> element specifies a multi-part MIME binding for the operation.
webMethods Developer does not support this type of binding.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding
associated with an operation.

[ISS.0092.9025] Error: HTTP Binding input is of type http:urlReplacement. http:urlReplacement is not

supported. Binding was not generated.
The <binding> element specifies <http:urlReplacement> as the binding for the
operation input. Developer does not support this type of binding for the input message.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding
associated with an operation.

[ISS.0092.9026] Error: HTTP Binding input is of an unknown type. Binding was not generated.
The input binding specifies an unknown binding type. When the protocol is HTTP POST,
the <mime:content> element for the input binding must specify text/xml, text/plain,
or application/x-www-form-urlencoded for the type attribute. (The <mime:mimeXml>
element is also valid for the input binding.) When the protocol is HTTP GET, the input
binding must contain the child element <http:urlEncoded>.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. (In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding
associated with an operation.)

[ISS.0092.9027] Error: HTTP Binding output mime parts are missing. Binding was not generated
completely.
The <binding> element specifies MIME binding for the output message, but the output
binding does not specify a message part for the <mime:content> element or the output
binding is missing <mime:part> elements.

76 Web Services Developer’s Guide Version 6.0.1

 Web Service-Related Errors and Warnings

Developer generates the Web service connector and generates a SEQUENCE step that
corresponds to this binding. (In the Web service connector, the BRANCH on '/binding'
step contains a child SEQUENCE step for each unique binding associated with an
operation.) However, Developer does not generate a complete binding because the output
binding in the WSDL document does not provide the part name information that
Developer needs to link the service results to variables in the pipeline. Specifically, the
Web service connector does not contain the BRANCH on '/numParts' step for this binding.

[ISS.0092.9028] Error: HTTP Binding output mime part is missing its type. Binding was not generated
completely.
The <binding> element specifies MIME binding for the output message, but the
<mime:content> element for the output binding does not specify a value for the type
attribute. The type attribute specifies the MIME type.
Developer generates the Web service connector and generates a SEQUENCE step that
corresponds to this binding. (In the Web service connector, the BRANCH on '/binding'
step contains a child SEQUENCE step for each unique binding associated with an
operation.) However, Developer does not generate a complete binding because the output
binding in the WSDL document does not provide the part name information that
Developer needs to link the service results to variables in the pipeline. Specifically, in the
Web service connector, the BRANCH on '/loopCount' step does not have a child
SEQUENCE step for linking the output message part to the pipeline.

[ISS.0092.9029] Warning: Generated Document Type, {IS document type name}, already exists in
namespace.
The IS document type that Developer generated for the input or output message already
exists in the server namespace. Developer will not generate a duplicate IS document type.

[ISS.0092.9030] Error: Input does not have a valid message reference, Web Service Connector was not
created.
Within the <operation> element, the message attribute for the <input> element does not
reference a <message> element within the WSDL. Developer cannot find the message
specified by the message attribute, or the message attribute does not have a value.
Developer does not generate a Web service connector for the <operation>.

Note: The message attribute value must be a QName.

[ISS.0092.9031] Error: Output does not have a valid message reference, Web Service Connector was
not created.
Within the <operation> element, the message attribute for the <output> element does
not reference a <message> element within the WSDL. Developer cannot find the message
specified by the message attribute or the message attribute does not have a value.
Developer does not generate a Web service connector for the <operation>.

Web Services Developer’s Guide Version 6.0.1 77

Appendix B Web Service-Related Errors and Warnings

Note: The message attribute value must be a QName.

[ISS.0092.9032] Error: Invalid schema definition for Input signature. Web Service Connector was not
created.
The XML Schema definition that contains element declarations or type definitions for the
<part> elements in the input message is invalid. Alternatively, the XML Schema
definition does not contain the element declarations or type definitions referenced by the
<part> elements. Developer does not generate a Web service connector for the
<operation>.

Note: This error message is usually accompanied by specific IS schema generation errors.
For more information about errors that occur when generating an IS schema from an XML
Schema, see the webMethods Developer User’s Guide.

[ISS.0092.9033] Error: Invalid schema definition for Output signature. Web Service Connector was not
created.
The XML Schema definition that contains element declarations or type definitions for the
<part> elements in the output message is invalid. Alternatively, the XML Schema
definition does not contain the element declarations or type definitions referenced by the
<part> elements. Developer does not generate a Web service connector for the
<operation>.

Note: This error message is usually accompanied by specific IS schema generation errors.
For more information about errors that occur when generating an IS schema from an XML
Schema, see the webMethods Developer User’s Guide.

[ISS.0092.9034] Warning: Found port with an invalid binding reference, the port was not generated.
In the WSDL document, a <port> element contains a binding attribute that references a
<binding> that does not exist within the WSDL document. Developer cannot find the
<binding> element specified by the binding attribute.

Developer generates the Web service connector, but does not generate a MAP step for this
port. The portName MAP steps set the binding and address information for a port. In a
Web service connector, the BRANCH on '/_port' step contains a child portName MAP step
for each <port> associated with the <operation>.

Note: The binding attribute value must be a QName.

78 Web Services Developer’s Guide Version 6.0.1

 Web Service-Related Errors and Warnings

[ISS.0092.9035] Warning: Found service with no ports.

In the WSDL document, a <service> element contains no <port> elements. Developer
generates a Web service connector, but if the WSDL document does not contain any
<service> elements that provide port and address information for an operation, the Web
service connector will be incomplete.

[ISS.0092.9036] Error: Could not process document. Found binding with an invalid PortType
reference, no Web Service Connectors were created.
In a <binding> element, the type attribute specifies a <portType> that does not exist in
the WSDL document. Developer does not generate a Web service connector.

Note: The type attribute value must be a QName.

[ISS.0092.9037] Error: HTTP Binding input type could not be found. Binding was not generated.
Developer cannot determine the input MIME type for the HTTP binding.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. (In the Web service
connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each
unique binding associated with an operation.)

[ISS.0092.9038] Error: Unknown binding style was found, binding was not created.
The <binding> element specifies a protocol other than SOAP, HTTP, or MIME.
Developer generates the Web service connector, but the Web service connector does not
contain a SEQUENCE step that corresponds to this binding. (In the Web service connector,
the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding
associated with an operation.)

[ISS.0092.9040] Error: PortType name is zero length, Web Service Connector was not created.
In the WSDL document, the <portType> element carries the name attribute, but the name
attribute does not have a value. Developer does not generate a Web service connector.

[ISS.0092.9041] Error: Operation name is zero length, Web Service Connector was not created.
In the WSDL document, the <operation> element carries the name attribute, but the
name attribute does not have a value. Developer does not generate a Web service
connector.

[ISS.0092.9043] Error: Schema Error: error text

The XML Schema definition that defines the types and elements for the input and/or
output message parts is invalid. The schema errors are listed. For information about errors
that occur when Integration Server processes an XML Schema definition, see webMethods
Developer User’s Guide.

Web Services Developer’s Guide Version 6.0.1 79

Appendix B Web Service-Related Errors and Warnings

[ISS.0092.9102] fileName: Not a valid web service description document.

The file you selected to generate the Web service connector is not a .wsdl or .wsd file. You
can only generate Web service connectors from files with a .wsdl or .wsd file name
extension.

[ITD.0012.0011] Web Service Connector created successfully but with warnings.

Developer generated the Web service connector successfully; however, warnings
occurred.
Click Details on the message dialog box to view the warnings.

[ITD.0012.0012] Error occurred while creating Web Service Connector.

Developer did not generate a Web service connector. Click Details on the message dialog
box to view the errors.

80 Web Services Developer’s Guide Version 6.0.1

 Index

Index

A G
API Generate WSDL command 26
related documentation 8 generating WSDL documents
describing service signature 35
B HTTP GET protocol 46
binding element, in WSDL document 60 HTTP POST protocol 46
process overview 14
SOAP Message protocol 34
C
SOAP RPC protocol 26
conventions used in this document
program code conventions 7
H
typographical conventions 6
creating HTTP GET protocol
Web service connectors 20 input and output signature requirements 47
WSDL documents service requirements for generating WSDL documents 46
describing service signature 35 specifying for WSDL documents 46
HTTP GET protocol 46 text/xml restrictions 47
HTTP POST protocol 46 URL encoded restrictions 46, 50
process overview 14 HTTP POST protocol
SOAP Message protocol 34 input and output signature requirements 47
SOAP RPC protocol 26 service requirements for generating WSDL documents 46
specifying for WSDL documents 46
text/xml restrictions 47
D
URL encoded restrictions 46, 50
default SOAP processor, using as directive for WSDL document
26, 34
definitions element, in WSDL document 60
I
docType folder, for Web service connector 21 input signature
documentation describing for WSDL documents 27, 35, 47
printing 9 HTTP GET requirements 47
program code conventions used 7 HTTP POST requirements 47
related manuals 8 SOAP Message requirements 35
typographical conventions used 6 SOAP RPC requirements 27
viewing 9
L
E local name, definition of 16
elements, in a WSDL document 60
errors M
Web service connector generation 71 message element, in WSDL document 60
WSDL document generation 67 messages related to Web services 66

Web Services Developer’s Guide Version 6.0.1 81

Index

N specifying for WSDL documents 26

namespace
definition of 16 T
explicit name 16 text/xml restrictions, for WSDL documents 47
implicit name 16 types element, in WSDL document 60
in WSDL documents 61 typographical conventions 6
universal name 16
U
O universal name 16
operation element, in WSDL document 60 URL encoded restrictions, for WSDL documents 46, 50
output signature
describing for WSDL documents 27, 35, 47 V
HTTP GET requirements 47 viewing this document in PDF format 9
HTTP POST requirements 47
SOAP Message requirements 35
W
SOAP RPC requirements 27
warnings
Web service connector generation 71
P
WSDL document generation 67
part element, in WSDL document 60 Web service connector
PDF, viewing 9 creating 20
port element, in WSDL document 61 definition of 12
portType element, in WSDL document 60 example 21
prefix 15 generation errors and warnings 66
printing this guide 9 supporting elements 21
program code conventions 7 Web services
and WSDL documents 13
S definition of 12
service element, in WSDL document 61 description 13
services messages related to 66
generating WSDL documents for 14 Web Services Description Language. See WSDL.
HTTP GET requirements 46 WSDL documents 35
HTTP POST requirements 46 definition of 13
signature requirements 14 elements 60
SOAP Message requirements 34 example of 63
SOAP RPC requirements 26 generating
SOAP Message protocol describing signature with SOAP MSG protocol 35
input and output signature requirements 35 HTTP GET protocol 46
service requirements for default processor 34 HTTP POST protocol 46
specifying for WSDL documents 34 process overview 14
SOAP RPC protocol service requirements 46
input and output signature requirements 27 SOAP Message protocol 34
service requirements for default processor 26

82 Web Services Developer’s Guide Version 6.0.1

 Index

SOAP RPC protocol 26 identically named variables 36, 50, 52

Web service connectors from 20 SOAP Message requirements 35
generation errors and warnings 66 SOAP RPC requirements 27
input signature specifying 35
HTTP GET requirements 47 using to create Web service connectors 20, 32, 43
HTTP POST requirements 47 using with default SOAP processor 34
identically named variables 36, 50, 52 Web services 13
SOAP Message requirements 35 WSDL generator, definition of 14
SOAP RPC requirements 27
specifying 35 X
namespaces 61 XML namespace
output signature definition of 15
HTTP GET requirements 47 prefix 15
HTTP POST requirements 47

Web Services Developer’s Guide Version 6.0.1 83

Index

84 Web Services Developer’s Guide Version 6.0.1