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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
The RFE has been declined because looking at the workload of the CICS development team for the next year, we do not anticipate being able to address this requirement in the next 12 months. Furthermore, looking at the list of RFEs against webservices, this would not be at the top of the list.
Can you please explain, why the RFE is declined.
Kind Regards
Helmut Roese
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
This is a candidate for a future release.
Hello,
that's a very good requirement. I agree with Helmut, that some fields are well-known and described from W3C. Parsing and propagating the string should be possible and makes coding much easier, because I have no reason to implement an own parsing. I prefer to make an API-call, not an SPI-call or is there a reason for SPI?
I would furthermore extend the requirement to support additionaly so-called "modelled Soapfaults". In WSDL it's possible to define SOAPfaults at each operation. That faults are described via xsd-schema, so you could convert it in a language-structure and propagate it like a "normal" Webservice-Response. The language-structure could be generated at DFHWS2LS. All other "unmodelled" faults, maybe Server-Faults, etc. are accessible with the fields in INQ SOAPFAULT.
Best regards,
Juergen
The description of the SOAPFAULT-handling is very complex and requires a lot of interaction. Therefore the INQ SOAPFAULT could be a much more practical and effective way to handle it.
Even if there is a lot of unstructured information in a SOAPFAULT, the possible fields are limited as described in the W3C specification. Therefore an equivalent to the SOAPFAULT CREATE with corresponding syntax should be possible. The SOAPFAULT INQ shall use the same fields as the SOAPFAULT CREATE. And if the fields are longer than the CICS supplied defaults (i.e. ROLE up to 2056 characterrs) the command shall raise LENGERR condition and the RESP2-field can show the field in error.
We don't currently have a SOAPFAULT INQUIRE command, though there's no reason not to add one. However, it would be of limited usefulness as the interesting part of a SOAPFault is the XML content, and that's fault specific. Even if the WSDL document lists some potential SOAPFaults that may be received, there would always be a potential for unexpected response formats.
What we do have in CICS TS V4.1 and above is an API for parsing XML. That can be used to provide a library of transformation routines. You can ask CICS to describe the first tag in a block of XML, and if that tag is included in the transformation library, you can ask CICS to perform that transformation. This concept is described more fully here: http://www-304.ibm.com/support/docview.wss?uid=swg21389533 .
Do you have any comments on this ?