The OPERATION specified was not in the Web service binding file.
What is the binding file and where is it created for the sample application ?
The OPERATION is internal to the application so how can it be not found ?
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Have you gone through Creating a SOAP web service and verified that each and every step listed has been performed? If not, you should start by doing so.
The error messages appear to indicate your CICS web service environment is not set up correctly. The manual will help you do so. You may need your site support group to perform some of the steps since application programmers might not have the authority to do all of them.
Quote:
The OPERATION is internal to the application so how can it be not found ?
If you didn't set up the binding file following the steps in the manual, then it is impossible for the OPERATION to exist in it.
I can do whatever I want on the test LPAR.
I followed the doc for deploying the catalog sample app and performed every step.
What manual are you referring to ?
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
The manual is Configuring and the heading is Creating the web services infrastructure and the section is Configuring your CICS system for web services with the chapter on Creating a SOAP web service. Click on the link and make sure you've followed the steps -- you do NOT just decide to start using web services in CICS; there's a lot of set up to be done before you can expect to get any results.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
For CICS 4.1, I found:
Quote:
Configuring your CICS system for Web services
Before you can use Web services, your CICS® system must be correctly configured.
Procedure
Ensure that you have installed Language Environment® support for PL/I.
Activate z/OS® Support for Unicode. You must enable the z/OS conversion services and install a conversion image that specifies the data conversions that you want CICS to perform between SOAP messages and an application program. For more information, see z/OS Support for Unicode: Using Conversion Services.
CICS resources for Web services
These CICS resources support Web services in CICS.
Configuring CICS to use the WebSphere MQ transport
To use the WebSphere® MQ transport with Web services in CICS, you must configure your CICS region accordingly.
and
Quote:
CICS resources for Web services
These CICS® resources support Web services in CICS.
PIPELINE
A PIPELINE resource definition is required for every Web service. It provides information about the message handler programs that act on a service request and on the response. Typically, a single PIPELINE definition defines an infrastructure that can be used by many applications. The information about the message handlers is supplied indirectly: the PIPELINE specifies the name of a z/OS UNIX file thatcontains an XML description of the handlers and their configuration.
A PIPELINE resource that is created for a service requester cannot be used for a service provider, and vice versa. The two sorts of PIPELINE are distinguished by the contents of the pipeline configuration file that is specified in the CONFIGFILE attribute: for a service provider, the top-level element is <provider_pipeline>; for a service requester, it is <requester_pipeline>.
WEBSERVICE
A WEBSERVICE resource definition is required only when the mapping between application data structure and SOAP messages has been generated using the CICS Web services assistant. It defines aspects of the run time environment for a CICS application program deployed in a Web services setting.
Although CICS provides the usual resource definition mechanisms for WEBSERVICE resources, they are typically created automatically from a Web service binding file when the pickup directory for the PIPELINE is scanned. This can occur when the PIPELINE resource is installed or as a result of a PERFORM PIPELINE SCAN command. The attributes applied to the WEBSERVICE resource in this case come from a Web services binding file, which is created by the Web services assistant; information in the binding file comes from the Web service description, or is supplied as a parameter of the Web services assistant.
A WEBSERVICE resource that is created for a service requester cannot be used for a service provider, and vice versa. The two sorts of WEBSERVICE are distinguished by the PROGRAM attribute: for a service provider, the attribute must be specified; for a service requester, it must be omitted.
URIMAP
A URIMAP definition is required in a service provider when it contains information that maps the URI of an inbound Web service request to the other resources (such as the PIPELINE) that will service the request.
A URIMAP definition is also required if you are using HTTP basic authentication, because the URIMAP specifies that the service requester user ID information is passed in an HTTP authorization header to the service provider. For more information about HTTP basic authentication, see HTTP basic authentication.
Although CICS provides the usual resource definition mechanisms, for service providers deployed using the CICS Web services assistant, the URIMAP resources are typically created automatically from a Web service binding file when the pickup directory for the PIPELINE is scanned. This scan occurs when the PIPELINE resource is installed or as a result of a PERFORM PIPELINE SCAN command. The attributes applied to the URIMAP resource in this case come from a Web services binding file, which is created by the Web services assistant; information in the binding file comes from the Web service description or is supplied as a parameter of the Web services assistant.
TCPIPSERVICE
A TCPIPSERVICE definition is required in a service provider that uses the HTTP transport. It contains information about the port on which inbound requests are received.
The resources that are required to support a particular application program depend on the following criteria:
Whether the application program is a service provider or a service requester.
Whether the application is deployed with the CICS Web services assistant.
Service requester or provider CICS Web services assistant used PIPELINE required WEBSERVICE required URIMAP required TCPIPSERVICE required
Provider Yes Yes Yes (but see note 1) Yes (but see note 1) See note 2
No Yes No Yes See note 2
Requester Yes Yes Yes No No
No Yes No No No
Notes
When the CICS Web service assistant is used to deploy an application program, the WEBSERVICE and URIMAP resources can be created automatically when the pickup directory of the PIPELINE is scanned. This scan occurs when the PIPELINE resource is installed or as a result of a PERFORM PIPELINE SCAN command.
A TCPIPSERVICE resource is required when the HTTP transport is used. When the WebSphere® MQ transport is used, a TCPIPSERVICE resource is not required.
Typically, when you deploy many Web services applications in a CICS system, you have more than one of each type of resource. In this case, you can share some resources between applications.
Table 1. Resources available for each file and resourceFile or resource Number and type of resource
Pipeline configuration file
More than one PIPELINE resource that refers to the file.
PIPELINE resource
More than one URIMAP resource that refers to the PIPELINE.
More than one WEBSERVICE resource that refers to the PIPELINE.
More than one Web service binding file in the pickup directory of the PIPELINE .
Web service binding file
Just one URIMAP resource that is automatically generated from the binding file. But you can define further URIMAPs using RDO.
Just one WEBSERVICE resource that is automatically generated from the binding file. But you can define further WEBSERVICEs using RDO.
WEBSERVICE
More than one URIMAP resource. If the WEBSERVICE resource is automatically generated from the binding file, there is just one corresponding URIMAP resource. But you can define further URIMAP resources using RDO.
URIMAP
Just one TCPIPSERVICE when it is explicitly named in the URIMAP resource.
TCPIPSERVICE
Many URIMAP resources.
and
Quote:
Configuring CICS to use the WebSphere MQ transport
To use the WebSphere® MQ transport with Web services in CICS®, you must configure your CICS region accordingly.
Procedure
Include the following WebSphere MQ library in the STEPLIB concatenation in your CICS procedure. Include the library after the CICS libraries to ensure that the correct code is used.
thlqual.SCSQAUTH
where thlqual is the high-level qualifier for the WebSphere MQ libraries.
Include the following WebSphere MQ libraries in the DFHRPL concatenation in your CICS procedure. Again, include the libraries after the CICS libraries to ensure that the correct code is used.
thlqual.SCSQCICS
thlqual.SCSQLOAD
thlqual.SCSQAUTH
where thlqual is the high-level qualifier for the WebSphere MQ libraries. If you are using the CICS-WebSphere MQ API-crossing exit (CSQCAPX), also add the name of the library that contains the load module for the program. The SCSQCICS library is required only if you want to run WebSphere MQ supplied samples. Otherwise it can be removed from the CICS procedure.
Install an MQCONN resource definition for the CICS region. The MQCONN resource definition specifies the attributes of the connection between CICS and WebSphere MQ, including the name of the default WebSphere MQ queue manager or queue-sharing group for the connection. For information on how to do this, see Setting up an MQCONN resource definition.
Specify the CICS system initialization parameter MQCONN=YES to start the CICS-WebSphere MQ connection automatically at CICS initialization.
An MQCONN resource definition must be installed before CICS can start the connection to WebSphere MQ. When you start the connection automatically at CICS initialization, for an initial or cold start, the MQCONN resource definition must be present in one of the groups named in the list or lists named by the GRPLIST system initialization parameter. For a warm or emergency start of CICS, the MQCONN resource definition must have been installed by the end of the previous CICS run.
If you are using the CICS-WebSphere MQ adapter in a CICS system that has interregion communication (IRC) to remote CICS systems, ensure that the IRC facility is OPEN before you start the adapter, by specifying the CICS system initialization parameter IRCSTRT=YES. The IRC facility must be OPEN if the IRC access method is defined as cross-memory; that is, ACCESSMETHOD(XM).
Ensure that the coded character set identifiers (CCSIDs) used by your queue manager and by CICS, and the UTF-8 and UTF-16 code pages are configured to z/OS® conversion services. The CICS code page is specified in the LOCALCCSID system initialization parameter.
Update your CICS CSD as follows:
If you do not share your CSD with earlier releases of CICS, remove the groups CSQCAT1 and CSQCKB, and any copies of those groups or of items from those groups, from your CSD. You must also delete the CKQQ TDQUEUE from group CSQCAT1. The definition for CKQQ is now supplied in the CICS CSD group DFHDCTG.
If you do share your CSD with earlier CICS releases, ensure that CSQCAT1 and CSQCKB, and any copies of those groups or of their content, are not installed for CICS TS 4.1 or CICS TS 3.2. You must also delete the CKQQ TDQUEUE from group CSQCAT1. The definition for CKQQ is now supplied in the CICS CSD group DFHDCTG. For CICS TS releases earlier than CICS TS 3.2, install the CSQCAT1 and CSQCKB groups as part of a group list, after installing DFHLIST, to override group DFHMQ and correctly install the required definitions.
Update the WebSphere MQ definitions for the dead-letter queue, default transmission queue, and CICS-WebSphere MQ adapter objects. You can use the sample CSQ4INYG, but you might need to change the initiation queue name to match the default initiation queue name in the MQINI resource definition for your CICS region. You can use this member in the CSQINP2 DD concatenation of the queue manager startup procedure, or you can use it as input to the COMMAND function of the CSQUTIL utility to issue the required DEFINE commands. Using the CSQUTIL utility is preferable because you do not then have to redefine these objects each time that you restart WebSphere MQ.
The WebSphere MQ transport
CICS can receive and send SOAP messages to WebSphere MQ (WMQ) using the WMQ transport, both in the role of service provider and service requester.
Defining local queues in a service provider
To use the WebSphere MQ transport in a service provider, you must define one or more local queues that store request messages until they are processed, and one trigger process that specifies the CICS transaction that will process the request messages.
Defining local queues in a service requester
When you use the WebSphere MQ transport for outbound requests in a service requester, you can specify in the URI for the target Web service that your responses should be returned on a predefined reply queue. If you do so, you must define each reply queue with a QLOCAL object.
The URI for the WMQ transport
When communication between the service requester and service provider uses WMQ, the URI of the target is in a form that identifies the target as a queue and includes information to specify how the request and response should be handled by WMQ.
Configuring CICS to support persistent messages
CICS provides support for sending persistent messages using the WMQ transport protocol to a Web service provider application that is deployed in a CICS region.
Persistent message processing
When a Web service request is received in a WMQ persistent message, CICS creates a unique BTS process with the process type DFHMQSOA. Data relating to the inbound request is captured in BTS data-containers that are associated with the process.
So according to what you've said, you set up LE support for PL/I and you activated z/OS support for Unicode, along with installing the conversion image(s) you need -- this may not be needed depending upon which release of z/OS you're running. And you've installed the PIPELINE resource definition for your Web service. And if you used the CICS Web services assistant, you've added the PERFORM PIPELINE SCAN to your code. And you've defined your web service binding file with the WSBIND attribute of the WEBSERVICE resource. And you've used DFHWS2LS or DFHLS2WS with your WSDL. Remember, all this has to be completed before you can use CICS web services -- the link you quoted appears to assume that all this has already been done.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
I found this in the CICS 5.2 manuals:
Quote:
Before you can plan to use SOAP web services in CICS®, you need to consider these questions for each application.
Before you begin
Do you plan to deploy your CICS application in the role of a service provider or a service requester?
You may have a pair of applications that you want to connect using CICS support for web services. In this case, one application will be the service provider; the other will be the service requester.
Do you plan to use your existing application programs, or write new ones?If your existing applications are designed with a well defined interface to the business logic, you will probably be able to use them in a web services setting, either as a service provider or a service requester. However, in most cases, you will need to write a wrapper program that connects your business logic to the web services logic.
If you plan to write new applications, you should aim to keep your business logic separated from your web services logic, and, once again, you will need to write a wrapper program to provide this separation. However, if your application is designed with web services in mind, the wrapper might be simpler to write.
Do you intend to use SOAP messages?SOAP is fundamental to the web services architecture, and much of the support that is provided in CICS assumes that you will use SOAP. However, there may be situations where you want to use other message formats. For example, you might have developed your own message formats that you want to deploy with the CICS web services infrastructure. You can do this with CICS, but you will not be able to use some of the functions that CICS provides, such as the web services assistant, and the SOAP message handlers.
If you decide not to use SOAP, your application programs will be responsible for parsing inbound messages, and constructing outbound messages.
Do you intend to use the CICS web services assistant to generate the mappings between your data structures and SOAP messages?The assistant provides a rapid deployment of many applications into a web services setting with little or no additional programming. And when additional programming is required, it is usually straightforward, and can be done without changing existing business logic.
However, there are cases which are better handled without using the web services assistant. For example, if you have existing code that maps data structures to SOAP messages, there is no advantage in reengineering your application with the web services assistant.
Although the CICS web services assistant supports the most common data types and structures, there are some that are not supported. In this situation, you should check the list of unsupported data types and structures for the language in question, and consider providing a program layer that maps your application data to a format that the assistant can support. If this is not possible, you will need to parse the message yourself. For details on what the assistant can and cannot support, see High-level language and XML schema mapping.
If you decide not to use the CICS web services assistant, you can use a tool such as Rational® Developer for System z® to create the necessary artifacts, and you can then provide your own code for parsing inbound messages, and constructing outbound messages. You can also use the provided vendor interface API.
Do you intend to use an existing service description, or create a new one?In some situations, you will be obliged to use an existing service description as a starting point. For example:•Your application is a service requester, and it is designed to invoke an existing web service.
•Your application is a service provider, and you want it to conform to an existing industry-standard service description.
In other situations, you may need to create a new service description for your application.
Planning a SOAP service provider application
In general, CICS applications should be structured to ensure separation of business logic and communications logic. Following this practice will help you to deploy new and existing applications in a web service provider in a straightforward way. You will, in some situations, need to interpose a simple wrapper program between your application program and CICS web service support.
Planning a SOAP service requester application
In general, CICS applications should be structured to ensure separation of business logic and communications logic. Following this practice will help you to deploy new and existing applications in a web service requester in a straightforward way. You will, in almost every situation, need to interpose a simple wrapper program between your application program and CICS web service support.
In MSGUSR the following message shows up during startup:
WEBSERVICE inquireCatalogClient is now INSERVICE and is ready for use.
Here is the current status of the installed WebServices.
These were all created by the sample application RDO definitions:
I WEBSERVICE
STATUS: RESULTS - OVERTYPE TO MODIFY
Webs(dispatchOrder ) Pip(EXPIPE02)
Ins Ccs(00000)
Webs(dispatchOrderEndpoint ) Pip(EXPIPE01)
Ins Ccs(00000) Uri($557140 ) Pro(DFH0XODE) Com
Webs(inquireCatalog ) Pip(EXPIPE01)
Ins Ccs(00000) Uri($557141 ) Pro(DFH0XCMN) Com
Webs(inquireCatalogClient ) Pip(EXPIPE02)
Ins Ccs(00000)
Webs(inquireCatalogWrapper ) Pip(EXPIPE01)
Ins Ccs(00000) Uri($557142 ) Pro(DFH0XICW) Cha
Webs(inquireSingle ) Pip(EXPIPE01)
Ins Ccs(00000) Uri($557143 ) Pro(DFH0XCMN) Com
Webs(inquireSingleClient ) Pip(EXPIPE02)
Ins Ccs(00000)
Webs(inquireSingleWrapper ) Pip(EXPIPE01)
Ins Ccs(00000) Uri($557144 ) Pro(DFH0XISW) Cha
Webs(placeOrder ) Pip(EXPIPE01)
Ins Ccs(00000) Uri($557145 ) Pro(DFH0XCMN) Com
Obviously something isn't right for WEBSERVICE inquireCatalogClient which is driven by transid ECLI
UNICODE conversion setup was done as instructed.
The instructions I followed didn't mention anything about PL/1. The sample application is written in COBOL.
PIPELINE, TCPIPSERVICE , WEBSERVICE and URIMAP resource definitions were all created by the RDO groups provided for the sample application by IBM.
The name of the operation is contained in the WSDL for the target Web service so my question is where do I need to look to see the contents of the WSDL and what operations it supports ?
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
The Implementing CICS Web Services Redbook (SG24-7657) has this starting on page 46 (emphasis added by me):
Quote:
We go through the following steps:
1. We generate the wsbind and WSDL files (application developer).
a. We first create an HFS directory in which to store the generated files. For
example, we might create a directory named
/u/SharedProjectDirectory/MyFirstWebServiceProvider.
b. We next run the DFHLS2WS program. The input we provide to the
program includes the following information:
• The names of the partitioned data set members that contain the high
level language structures that the application program uses to describe
the Web service request and the Web service response.
• The fully qualified HFS names of the wsbind file and of the file into
which the Web service description is to be written (the WSDL file).
• The relative URI that a client uses to access the Web service.
• How CICS should pass data to the target application program
(COMMAREA or container).
Typically, an application developer would perform this step.
2. Create a TCPIPSERVICE resource definition (system programmer).
The resource definition should specify PROTOCOL(HTTP) and supply
information about the port on which inbound requests are received.
Typically, a system programmer would perform this step.
3. Create a PIPELINE resource definition (system programmer).
a. Create a service provider pipeline configuration file.
A pipeline configuration file is an XML file that describes, among other
things, the message handler programs and the SOAP header processing
programs that CICS invokes when it processes the pipeline.
b. Create an HFS directory in which to store installable wsbind and WSDL files.
We call this directory the “pickup” directory since CICS picks up the
wsbind and WSDL files from this directory and store them on a “shelf”
directory.
c. Create an HFS directory for CICS in which to store installed wsbind files.
We call this directory the “shelf” directory.
d. Create a PIPELINE resource definition to handle the Web service request.
• Specify the CONFIGFILE attribute to point to the file created in step 3a.
• Specify the WSDIR attribute to point to the directory created in step 3b.
• Specify the SHELF attribute to point to the directory created in step 3c.
e. Copy the wsbind and WSDL files created in step 1 to the pickup directory created in step 3b.
4. Install the TCPIPSERVICE and PIPELINE resource definitions (system
programmer).
When the CICS system programmer installs the PIPELINE definition, CICS
scans the pickup directory for wsbind files. When CICS finds the wsbind file
created in step 1, CICS dynamically creates and installs a WEBSERVICE
resource definition for it. CICS derives the name of the WEBSERVICE
definition from the name of the wsbind file. The WEBSERVICE definition
identifies the name of the associated PIPELINE definition and points to the
location of the wsbind file in the HFS.
During the installation of the WEBSERVICE resource:
– CICS dynamically creates and installs a URIMAP resource definition.
CICS bases the definition on the URI specified in the input to DFHLS2WS
(see step 1) and stored by DFHLS2WS in the wsbind file.
– CICS uses the wsbind file to create main storage control blocks to map the inbound service request (XML) to a COMMAREA or a container and to
map to XML the outbound COMMAREA or container that contains the
response data.
5. Publish WSDL to clients.
a. Customize the location attribute on the <address> element in the WSDL
file so that its value specifies the TCP/IP server name of the machine
hosting the service and the port number defined in step 2.
b. Publish the WSDL to any parties wishing to create clients to this Web
service.
So the answer to your question is that you need to look wherever YOU set up the WSDL file; we don't know this because YOU did it. If you didn't set up the WSDL file, you should find out who did it and get the location from them. If there is no WSDL file, then that could be a clue as to why your process isn't working.
I will investigate this further. Thanks for the help.
All the resource definitions for the sample application were supposed to be provided by IBM.
The IBM doc outlines the required steps to deploy the sample application and I followed those steps to the letter.
The application developer in this case is IBM as they claim to provide a fully functional sample application to demonstrate the use of web services.
