CICS Web Services configuration question

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Good morning,

We are in the process of implementing CICS Web Services as a provider in our shop - all homegrown code without any real expertise, so we are really starting from the ground floor.

We have defined our TCPIPService/Port and WEBService, and are using the default PIPELine "PIPEPR12". During the PIPELINE SCAN, CICS has defined the URIM.

Background:
- We currently are working on a service to do a single business logic function for a Requisition.
- We will be working on the rest of the purchasing stream - POs, Inventory Receiving, and Vouchering.

My question is:
- From a "best practice" and/or "performance" standpoint, do we need to have separate PIPELines or TCPIPServices for each WEBService?

I have done a lot of searching in the IBM RedBooks and through a lot of the PDFs/PPTs available online from various webcasts and can't find a definitive answer.

TIA for any advice/help.
Steve

John Poulakos · Posted: Tue Nov 05, 2019 8:59 pm

My advise is to keep it simple. Moving a webs service into production from a test environment is a pretty involved process. Don't make it more difficult. I configure multiple pipelines in test CICS, to facilitate different developers doing different things with web services. I may have two pipelines in production if I have a lot of web services, just to group them and provide some order. But, there isn't any particular benefit to be had from multiple pipelines.

More than one port definition may be used to provide different security at the port level. But if all of your web services use the same security, I don't see the need. Make sure each CICS region uses a different port though. Especially TEST and PRODUCTION CICS regions. You don't want to accidently direct a test web service to a production CICS region.

I don't know which kind of files your web services will use, but I would strongly recommend DB2. Early web services I created using VSAM all had to be changed to DB2 because VSAM presents far too many obstacles and performance issues.

I don't know what programming language you are using, but if it's COBOL or PL/1, I would use CICS container support to write the programs and use SmartBear SoapUI to test with. Once you understand how containers work, you can develop new web service providers in a matter of hours. I can put together a pretty complex web service and test it in SoapUI in 2 days.

John Poulakos · Posted: Tue Nov 05, 2019 9:25 pm

I should have said use CICS Channels and Containers. I always forget to say channels.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Thanks very much for the reply John!

I should have included a few more details in my original post.

For background, this is an existing procurement MF application and we are writing "wrapper" web service programs around the business logic for posting transactions through the procurement stream. This will eventually be the "back end" for transactions coming in from multiple points via a middleware setup.

We do have separate test/prod ports currently defined. All of the wrappers will be using the same security, but I was just worried that we would need to separate them at the port or pipeline level. Good to know that isn't necessary.

The application is a COBOL/CICS/DB2 application, so the wrappers are as well and will be using Channels/Containers with SOAP WSDL.

We picked up on the SmartBear SoapUI test package a bit ago - good to know it was the right choice! Really nice package for the price ($0)!

We had previously created a web service provider on the web/PC side and have the MF as requestor, so we do have a bit of familiarity with Channels/Containers at least.

It seems like we are just about there with everything - just need a few additional tweaks with our CICS configuration and firewalls.

Thanks again for your insight John!

John Poulakos · Posted: Wed Nov 06, 2019 12:23 am

Are your requests or responses single occurrences or arrays? Arrays can be a little tricky.

Did you define a CICS transaction to serve as the DB2 anchor?

Are you using wsdl or RestFul?

You can get a lot of the CICS setup and commands needed in the IBM CA1P SupportPac for web service samples.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

We are using WSDL for the data structure and have hooks to a CICS transaction.

I read quite a bit on how tricky arrays can be, so we've written them to be mostly limited and not too complex (no ODOs, only single-level, etc.).

I appreciate the tips!

John Poulakos · Posted: Wed Nov 06, 2019 2:47 am

If you need any help feel free to ask. I have about 6 years experience with mainframe web services using channels and containers. I have a "sniffer" program that will show you what your containers are doing, if you are interested. It works great but you have to restart your CICS region to turn it on and off.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Good afternoon John,

I've got nearly everything defined correctly, but am running into what must be a simple issue.

I'm trying to do a WSDL discovery (hostname/webservicename?wsdl) and am getting a DFHPI0603 message. This happens either by trying to browse it in Chrome, or by the SoapUI testbench...

From the KB article (https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.2.0/com.ibm.cics.ts.messages.doc/DFHPI/DFHPI0603I.html):
"... A URIMAP resource might be missing if the URI is trying to discover a WSDL file."
and also
"If the request is attempting to discover the WSDL for a web service, ensure a URIMAP resource is installed that can match the path of the URI to the location of the WSDL."

How can I match these up?

- The URI parm on the DFHLS2WS job points to the address of the WebService:
URI=http://<IP Address>:<port>/PostREQ
- The WSDL parm has the full UNIX path to the WSDL:
WSDL=/usr/local/cics/cicst5y/wsdl/PostREQ.wsdl
- The PIPELINE scan builds the URIMap ($111600), and it points to the WebService:
Webservice(PostREQ)
- The PATH shows the relative path of the URI parm from DFHLS2WS:
Path(/PostREQ)
- The WebService points to the correct PipeLine and URIMap:
Pipeline(PIPEPR12)
URIMap($111600)

Any pointers on where to look or what I'm missing? I tried dropping off the IP/Port in the URI in DFHLS2WS, but that just made the Address Location at the bottom of the generated WSDL invalid.

I know it's got to be something simple....

Thanks for any help!
Steve

John Poulakos · Posted: Thu Nov 14, 2019 7:51 am

Have you set up SoapUI correctly with the wsdl as a project and manually entered your web service provider address and name?

I assume you have done these things, but it doesn't hurt to verify. If not, I can step you through what is needed.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Yes, SoapUI looks good. I also verified with the network people on both ends that the port and SOAP traffic are being permitted according to the logs. The error in CICS happens for both SoapUI and a generic WSDL discovery browse by Chrome.

I even copied the DFHLS2WS generated WSDL from the UNIX library to a text document and verified it against Use [URL] BBCode for External Links and got no errors.

I feel like it's right there, but I've forgotten just a little (or stupid) thing....

Thanks, I really appreciate all of your help and guidance!

John Poulakos · Posted: Thu Nov 14, 2019 9:49 pm

Why are you using Web service discovery? That introduces complexity you don't want when you are testing your first web service provider. Keep it simple, Hard code the address. In your SOAPUI web service, under Request1, you code the address in the box on top as something like this:
http:/10.133.40.20:41000/test/TestService

Where:
10.133.40.20 is the address of your mainframe
41000 is the name of the port you assigned
test is the name of the CICS transaction
Test Service is the name of your web service provider

Of course, these are not real values, just examples.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Sorry, I might be using wrong terminology.

What I am trying to get is just the XML of the WSDL to verify we're good to that point. Using your example:
http:/10.133.40.20:41000/test/TestService?WSDL

And am expecting to get back the XML document.

John Poulakos · Posted: Thu Nov 14, 2019 10:06 pm

SoapUI will take care of that. If you give it bad wsdl, it will complain.
Here's a sample of the Request1 it creates. It should be all you need to see:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sci0="http://www.SCI02WS.SCI02RQI.Request.com">
<soapenv:Header/>
<soapenv:Body>
<sci0:SCI02WSOperation>
<sci0:SciStatRequest>
<sci0:DocType>?</sci0:DocType>
<sci0:DocBatch>?</sci0:DocBatch>
<sci0:DocID>94020578</sci0:DocID>
</sci0:SciStatRequest>
</sci0:SCI02WSOperation>
</soapenv:Body>
</soapenv:Envelope>

John Poulakos · Posted: Thu Nov 14, 2019 10:32 pm

I will try to "discover" one of my web services in my test environment. As I recall, it requires some things to be set up that I don't normally use. This could take awhile.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Awesome, thank you!

John Poulakos · Posted: Thu Nov 14, 2019 10:57 pm

I tried to discover the web service for the sample I showed you. It didn't work for me, either. I did verify the web service worked fine in SOAPUI:

<SOAP-ENV:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sci0="http://www.SCI02WS.SCI02RQI.Request.com" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SCI02WSOperationResponse xmlns="http://www.SCI02WS.SCI02RSI.Response.com">
<SciStatResponse>
<SciCompletion>ROWS SELECTED: 0001</SciCompletion>
<SciArray>
<ResType>PD</ResType>
<ResBatch>327</ResBatch>
<ResDocId>94020578</ResDocId>
<ResMessID>F063</ResMessID>
<ResMessTxt>DOC PROCESSED AND ACCEPTED</ResMessTxt>
<ResDate>2019/05/14 15:40:03.2520</ResDate>
</SciArray>
</SciStatResponse>
</SCI02WSOperationResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The version of CICS we have is a 3.2, which may be too old for Discover.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Can you see if your CICS logs had a DFHPI0603 (it's in our MSGUSR DD under the CICS listing).

(As info, we're on CICS TS 5.2.)

John Poulakos · Posted: Fri Nov 15, 2019 3:37 am

My version of CICS simply ignores Discover and gives an internal server error, no DFH messages of any kind.

I suggest using my manual SOAP testing method to see if you can get your web service to work and worry about discover later.

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Well, I'm back and stuck again. Sorry, but I need another knock on the head to see what I'm doing wrong. Sorry if this is too much (or not enough) info.

Thanks for all your insight!

When I'm trying to hit this via SoapUI, I'm not getting any errors in the CICS logs, but SoapUI is throwing this when I try to create the project:

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Forgot to add the input cards to DFHLS2WS:

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

FYI,

Also checked the "SoapUI Log" button at the bottom of the UI window and got additional messages:

John Poulakos · Posted: Tue Nov 19, 2019 1:19 am

I am not at work today, but I will be back tomorrow and will try to step you through what needs to be done. But, I need to ask why you have libraries that show as (removed) and why there is no transaction ID?

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

Thanks for the update. No worries about the delays. I'm sure there will be more with the holidays coming next week too. I'm just glad you're helping as best you can!

For the (removed) items, I just pulled them out since they have identifying info in the path names.

Here's the DFHLS2WS parms again, but with some made up path names to show relative locations:

John Poulakos · Posted: Tue Nov 19, 2019 1:33 am

I wish I was there; we could probably get all of this sorted out in a day or two.
It looks like a lot of configuration issues. Hard to see the full picture. But, we will keep at it!

SickPup404 · New User Joined: 04 Nov 2019 Posts: 22 Location: USA

You're exactly right!

Awesome! Thanks again for everything.