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 Delivered
Workspace z/OS Connect
Created by Guest
Created on Oct 18, 2016

RELATED IDEAS

z/OS Connect API - allow to set HTTP response status code in the API

z/OS Connect API - allow to set HTTP response status code in the API

When a client submits an API request to z/OS Connect, it receives a response (with JSON payload), and an HTTP status code. However, the status code does not reflect any non-fatal errors from the back end service.

i.e. A client submits an API request to z/OS Connect, the transformation completes, the service is found and invoked, the service encounters an non-fatal error condition (i.e. in CICS), but completes. The end return code to the client is "200 OK", not reflecting the error in CICS. The client receives the OK, and needs to examine the payload if any conditions are indicated.

If the HTTP status code can be set in the API response, i.e. by mapping a response field, then the status code received by the client can immediately indicate a condition, and the client can take actions based on the status code.

Idea priority High
  • Guest
    Reply
    |     Jan 8, 2019

    Hello,

    you may be also interested in the following RFE about appropriate HTTP error response codes:

    https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=128788

    Best regards,
    Robert Recknagel.

  • Guest
    Reply
    |     Dec 21, 2018

    This requirement is addressed by z/OS Connect Enterprise Edition V3.0.16 / APAR PH05647:
    http://www-01.ibm.com/support/docview.wss?crawler=1&uid=swg1PH05647

    The API toolkit V3.0.6.0 has been enhanced to allow the definition of multiple response codes for an API operation. Rules that are specified for each response code are used to determine the HTTP status code, and unique response mapping, that are returned in the HTTP response.

    For further details about Multiple HTTP Response Codes, refer to the “How to define multiple response codes” topic in the z/OS Connect EE V3.0 Knowledge Center:
    https://www.ibm.com/support/knowledgecenter/SS4SVW_3.0.0/designing/api_multi_resp.html

  • Guest
    Reply
    |     Oct 8, 2018

    Please allow devs to set the API response code. e.g. App needs to return back a 201 or 202 in some cases depending on business logic.

  • Guest
    Reply
    |     Apr 19, 2018

    (tried to post the comment before, this may be a duplicate)

    Additional request from the developers:

    Enable z/OS Connect to use a different response schema for each status code response. This as per the Swagger standard at:
    https://swagger.io/docs/specification/describing-responses/

    The schemas should be defined on the z/OS side (eg. in the CICS program), and then referred in the API.. As we spoke on our of the lab calls, maybe doable with REDEFINES.

    An example from the Swagger link above:

    responses:
    '200':
    description: Success
    content:
    application/json:
    schema:
    $ref: '#/components/schemas/User'

    # These two error responses have the same schema
    '400':
    description: Bad request
    content:
    application/json:
    schema:
    $ref: '#/components/schemas/Error'
    '404':
    description: Not found
    content:
    application/json:
    schema:
    $ref: '#/components/schemas/Error_404' <----- I changed this one to be different

  • Guest
    Reply
    |     Jun 6, 2017

    Hello,

    we would also like to have a function that enables z/OS Connect to interpret error responses from IMS - both those which are send by IMS or IMS Connect itself and those which are created by IMS transactions. z/OS Connect then sends a HTTP error code which corresponds to the IMS internal problem including a corresponding message. For some problems there are already HTTP error codes which can be used, for others the possibilty to have user-defined HTTP error codes and messages would be good.

    Best regards,
    Robert Recknagel.

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.