Skip to Main Content
Integration


This is an IBM Automation portal for Integration 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.


Status Not under consideration
Created by Guest
Created on Apr 1, 2024

Get a full standard and compliant Rest API for MQ

Hello,

I recently tried to take advantage of Terraform (IaC) to manage my MQ Objects. And unfortunately, I faced multiple full-stops.

1) There is no MQ (Objects) provider for terraform (not a big issue as I chose to use Rest API Mastercard provider)
2) Only Queues (and Messages) as objects are supporting POST DELETE and PATCH operations
3) Even when trying to create queues POST method is returning 201 with 'no body (no business_id)' so terraform is not able to persist object state in terraform.tfstate
4) PATCH option is returning 204 !!! so no body can be added...

 

I did a proof of concept, and with a little piece of pyhton code acting as a proxy between terraform and MQ Api, I managed to fix all problems and get full live-cycle for queues. But as only queue is available as object, this is too limited. 

Can you please develop a full MQ API as 'objects', instead of a MQ Api as 'mqsc command' and have POST and PATCH return at least the objectid ?  

 

Thanks a lot

Idea priority Medium
  • Guest
    Reply
    |
    Apr 25, 2024

    apparently IBM just announced to buy HashiCorp (owner of Terraform), so maybe this should be put back to under review and be re-evaluated at a later stage this year...


  • Admin
    Mark Taylor
    Reply
    |
    Apr 8, 2024

    As Matt has said, the strategic solution is the JSON-formatted commands described. Defining and maintaining disparate formats, one for each MQSC command/object type, is not a sustainable approach. The common JSON mechanism makes knowledge easily transferrable from other MQ administrative interfaces such as MQSC.

  • Guest
    Reply
    |
    Apr 3, 2024

    Hello Matthew,

    I know that I can do this way, but it's definitely not the way I want to do ... The requirements I have are to use terraform to deploy 'objects' and take advantage of its stateful properties. So I need to manage all objects the same way I manage queues.

    I really would like you consider my request and deliver a fully compliant Rest API. I don't imagine it requires you so many efforts to produce it, (as you previously did in older versions). I don't understand why you changed strategy during the last years and chose to do everything as MQSC commands.

  • Admin
    Matthew Leming
    Reply
    |
    Apr 3, 2024

    Hello,

    You can run any MQSC command using the approach described here: https://www.ibm.com/docs/en/ibm-mq/9.3?topic=adminactionqmgrqmgrnamemqsc-post-json-formatted-command .
    This is the recommended approach going forwards.

    Regards, Matt.