CICS Web Services configuration question

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

A little more background for later when you have time:

- I have authority to make changes where needed in the Unix libraries.
- I can view just about all the CICS configurations needed in our development region.
- Our CICS support group can take a bit of time to make configuration changes.
- I am the one running the DFHLS2WS job and the pipeline scans.
- Two firewalls are in the mix: mainframe side and inter/intranet. Both are maintained by other groups. Mainframe side is quick responding, but inter/intranet side can take a week or more. (I think everything is good to go on the firewalls.)

So pretty much the only thing we rely on someone else doing on the mainframe is the initial setup of the service/pipe/port/etc.

John Poulakos · Posted: Tue Nov 19, 2019 8:42 pm

You are (or should be) attempting to get the web service functioning on your desktop. All that requires is SOAPUI installed on your desktop PC and a valid address into your mainframe. There should be little security to deal with at this point. OK. Lets start with some basics:

1. I would remove the 88 levels from your response copybook.
2. You need to define a CICS transaction in your LS2WS parms if you use DB2. (TRANSACTION=PREQ)
3. Just specify the transaction and web service name in the uri parm
(URI=PREQ/PostREQ) It makes things much easier to keep track of.
4. Run your LS2WS job and check the log. Report back.

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

OK,

Yes, this is from my desktop to the mainframe (connections verified to pass firewalls on both ends).

Did #1-4, and pipeline scan, then SoapUI. Results below. (DFHLS2WS completed successfully.)

(Sorry for the delay in responding. Other priorities and vacation time. I'm sure there will be more this week as well. Hope you have a great holiday!)

Thanks!
Steve

SoapUI error window when trying to connect:

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

Some success finally!!!!

I was thinking back on what I had done before and remembered my post from Mon Nov 18, 2019 @ 2:05 pm.

I copied the newly generated WSDL from the WSDL unix folder to the BIND folder, then SoapUI successfully pulled the full WSDL!!!!

I even tried Chrome and it worked too!

As time permits, I might go back and change things back to see what breaks it (the 88's, the missing TRANSACTION in the LS2WS, or the URI parm, whatever).

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

Good afternoon,

I was able to successfully GET the inbound SOAP document from the DFHWS-DATA container and return messages to the SoapUI test.

I've now made changes to the inbound & outbound copybooks (added fields and changed names).

Now when I test in SoapUI, I get:

John Poulakos · Posted: Tue Dec 10, 2019 2:24 am

Delete the old project from SOAPUI and create a new project with the changed wsdl.

Unless you bury a version ID in your wsdl (MyTestProviderV1, MyTestProviderV2, etc.) do not rely on discover to find the current version. You will also need to have your code support more than one version if the possibility exists that a client won't have the latest version of wsdl. One of the containers will give you the name being invoked.

Why are you putting wsdl in the bind folder?

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

Good morning John,

Thanks for the reply, I hadn't considered the client not having the correct WSDL version. I'll give that a shot.

I ran across this post while researching not being able to discover the WSDL last month (see my post from Nov 18, 2019 2:05 pm). After I copied the WSDL to the Bind folder, LS2WS succeeded in making two URIMs for the transaction (PHRI/PostREQ) as well as the WSDL (PHRI/PostREQ?wsdl).

Thanks again for all your assistance through this!
Steve

John Poulakos · Posted: Tue Dec 10, 2019 11:02 pm

That makes some sense.
Tell me, how are you getting the wsdl from the unix folder to your desktop to add it to SOAPUI?

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

Via discovery. I browse to the web service address in SoapUI:
http:1.2.3.4:5/PHRI/PostREQ?wsdl

and SoapUI populates the XML window. I can then fill in the document (SoapUI puts "?" in the fields) and then do the POST.

John Poulakos · Posted: Wed Dec 11, 2019 12:25 am

The resources I have available with this client require me to do a lot manually. It's more cumbersome, as I have to manually extract wsdl from unix folder and create a SOAP project. But, that would explain why there are some differences in what you are doing.

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

OK, after beating my head on the wall all day yesterday, I made no further changes to the copybooks so the WSDL was stable at the end of the day (and SoapUI was still failing with the DFHPI1007 message).

CICS bounce of the test region over night picked up the changes and everything is back in business. I think CICS must have been caching the old version. Looks like in our environment a bounce is needed (in addition to the Pipeline SCAN) to pick it up. Good to know.

Over the next few weeks I'll be building out the complexity (adding occurs, making some fields optional/required, etc.). I'll post back if I run into additional speed bumps.

I really appreciate everything you did to help John!
Steve

John Poulakos · Posted: Thu Dec 12, 2019 1:45 am

A pipeline scan and newcopy of the program, in addition to making sure the wsdl is being used by SOAPUI, is all that should be needed to invoke changes, assuming the web service was already functioning. Otherwise, you have issues that need to be addressed.

Arrays require special handling and nested containers. If you don't know how to do them, it can be endlessly frustrating. In addition, you need to cap the amount of data you can return to a web client. A decent mainframe can bury a server in a matter of seconds. I can provide some samples if needed.