This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
We don't have control over the WSDL for a requestor, specifically soap:address. The following is from the DFHWS2LS URI description:
In a service requester, the URI of the target web service is not specified with this parameter. CICS does not generate a URIMAP resource for a service requester. You can define your own URIMAP resource for service requesters to use when they make client requests to the URI of the target web service. When a service requester issues the INVOKE SERVICE command, CICS uses the
soap:address
location from thewsdl:port
specified in the web service description if present. You can override that and specify a different URI using the URIMAP or URI options on the INVOKE SERVICE command.So,
if the soap:address has a HTTPS for the scheme, then when we do the INVOKE SERVICE, CICS will attempt to establish the SSL session. If we are using AT-TLS for outbound conversations, we don't need CICS to do the SSL session establishment. What can be done to prohibit CICS from trying to establish the SSL session if the scheme is HTTPS? We are currently modifying the soap:address to change the scheme to HTTP but if we do that then we need to add a port 443 (or whatever we have defined to AT-TLS for the remote provider) to have AT-TLS see that we are attempting to contact the provider via SSL. If we don't add the port and the scheme is HTTP, we will end up with a unencrypted session.
If we don't modify the the soap:address to replace the scheme, we end up with CICS doing the SSL session establishment, violating our directive to have AT-TLS manange all SSL sessions.
This is not a proxy situation and no URI or URIMAP is specified for the remote provider.
If that is the case then maybe an additional parameter for the XWBOPEN exit would do the trick. i.e. it is self contained to the proxy case and entirely controlled by the user.
Please can you clarify if this requirement only relates to the use of a proxy with outbound web requests.