IBM Z Software


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).


Shape the future of IBM!

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:

Search existing ideas

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 your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

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.

Add a new idea Subscribe
Status Not under consideration
Workspace CICS Transaction Server for z/OS
Categories Runtime
Created by Guest
Created on Apr 18, 2013

RELATED IDEAS

Propagate SOAPFAULT to locally-optimized WebServices

With Webservices, a service-provider can issue SOAP-Faults to return information to the service-consumer. These SOAP-faults are modeled within the wsdl.

If the service-consumer uses the INVOKE SERVICE command to call a WebService that runs locally in CICS, then CICS optimizes that call internal to an EXEC CICS LINK. That offers the best possible performance. But if the WebService-Provider uses an EXEC CICS SOAPFAULT CREATE, then that soapfault will not be delivered to the locally requester (only remote service-providers gets that information). The container DFHWS-BODY is not available for a local service-consumer.

Because of this, the Service-Provider in CICS must now differentiate between local calls and remote calls and also the Service-Requester must differentiate between Service-Calls to local WebServices and remote WebServices.
This stops the implementation of platform-independent Service-Providers and makes an Consumer dependent from the location of the Service-Provider.

Suggested solution: Because CICS knows, that the WebService-Request comes from a local consumer, CICS should put the content of the "CREATE SOAPFAULT" to the container DFHWS-BODY, as described in the documentation for Service-Calls to external providers.

Idea priority High
  • Guest
    Reply
    |     May 19, 2016

    We have assessed this requirement. We have no current plans for this to be implemented and so this requirement is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

  • Guest
    Reply
    |     Oct 5, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - Servers and Systems Software
    Product family - Transaction Processing
    Product - CICS Transaction Server

    For recording keeping, the previous attributes were:
    Brand - WebSphere
    Product family - Transaction Processing
    Product - CICS Transaction Server

  • Guest
    Reply
    |     Apr 23, 2013

    You're right. The response code from the INVOKE command is not enough, we need the information in the SOAPFault, because different SOAPFaults for the same operation are possible.

    To use another optimised version can be a solution, but we have currently no need to place any own message-handler in that pipeline. But we need the original SOAPFault. And we need the SOAPFault in exactly the same format as when we call a remote service. The mapping from the SOAPfault to XML is currently done by CICS and not by an own handler, so we think CICS should do it also in the most optimised version.

    To store that information in another container is no option for us, because the service-requester must than differentiate between locally-optimised and remote services. But we want to implement platform-independent services. What is, if we move the Service-Provider from CICS to another platform. Then all service-requester must change their SOAPFault-handling.

    At the end of the day we think CICS should give us the information about the SOAPFault in exactly the same way and format for remote-services and locally-optimised services.

  • Guest
    Reply
    |     Apr 22, 2013

    There should be a response code from the INVOKE command to indicate that a Fault was returned. Presumably in the requirement scenario, it isn't enough just to know that there was a failure, you actually need to see the XML for the failure.

    There are several levels of local optimisation available in CICS. It sounds like the most optimised version is being used; this means that no XML gets generated. If one of the less optimised options were used, the XML for the SOAPFault would be produced, but would drive more CPU in doing so. There's more information here:

       http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=%2Fcom.ibm.cics.ts.webservices.doc%2Fconcepts%2Fdfhws_pipelineoptions.html

    Alternatively, the provider application could store data in a container that the requester application could read back later on.



    Would any of those options satisfy the requirement?

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.