Propagate SOAPFAULT to locally-optimized WebServices

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.

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

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.

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?