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 Future consideration
Created by Guest
Created on Jun 30, 2021

Add Support for the MFT Managed Call API to the MQWeb REST Interface

The primary reason for the requests, is that we are upgrading customer MFT implementation and moving away from Ant and the fte* commands to Python scripting. We found that Ant and the fte* commands are way to expensive to use as they require a JVM to spin up, and while the Python MQ XML interface is great and works well, we are trying to leverage REST API’s and the MQWeb REST support for ManagedTransfers which works great and gives us everything we need to simplify things , if we had the ManagedCall support, it would allow us to complete the move from having to use the Python MQ XML interface and be completely REST, JSON API based.

Idea priority High
  • Guest
    Reply
    |
    Nov 15, 2021

    Hello,

    Thank you for clarifying. Your comments helped.

    Thanks


  • Guest
    Reply
    |
    Nov 12, 2021

    HI,

    So, today we leverage the MQ Interface to submit just a Managed Call request to an agent so that it can invoke a Program or script etc, that runs at an Agent. This does NOT need to do any Transfer of files, it just invokes a executable and captured the stdout/stderr and rc codes. It is a documented interface which was mainly used via the Ant interface, however we have found that since ant is Java based, it is simply not suitable for our needs.

    We use this as part of a modern MQ based ETL/ELT type solution build on Python since it has such powerful data capabilities. With the Managed Call, we can effectively orchestrate ETL/ETL functions across multiple Agents and benefit from the excellent MQ/MFT Audit Events to help with the Track & Trace which includes very flexible metadata based on variables which allow us to corollate events and also employ a simple yet very effective orchestration.


    Below is an example of a Managed Call request which we submit via MQ to an Agent. Would be great if we could do this via the REST API as it would allow for the full power of the MFT Agents to be realized outside of transferring data.

    <?xml version="1.0" encoding="UTF-8"?>

    <request version="6.00" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="FileTransfer.xsd">

    <managedCall>

    <originator>

    <hostName>DELL-510R</hostName>

    <userID>xmftq1rm</userID>

    </originator>

    <agent QMgr="ITXQM" agent="HQ_AGENT1"/>

    <transferSet priority="0">

    <metaDataSet>

    <metaData key="SenderID">HQ_AGENT1</metaData>

    <metaData key="mqaCompId">2</metaData>

    <metaData key="mqaCompName">Demo Inc</metaData>

    <metaData key="mqaDeptName">SAPFIN</metaData>

    <metaData key="mqaDocId">${jobId}</metaData>

    <metaData key="mqaDocType">SAPFIN</metaData>

    <metaData key="mqaJobId">${jobId}</metaData>

    <metaData key="mqaRouteURL">http://192.168.1.108/GTM</metaData>

    <metaData key="mqaSLAClass">SAPFIN</metaData>

    <metaData key="mqaServiceName">SAP_FIN_Enrich</metaData>

    </metaDataSet>

    <call>

    <command name="python.sh" retryCount="0" retryWait="0" successRC="0" type="executable">

    <argument>SAP_Enrich.py</argument>

    <argument>-j</argument>

    <argument>${jobId}</argument>

    <argument>-a</argument>

    <argument>${agent}</argument>

    <argument>-t</argument>

    <argument>/home/itx/monitors/${NextMC_Cal}</argument>

    </command>

    </call>

    </transferSet>

    <job>

    <name>SAP_FIN_Enrich</name>

    </job>

    </managedCall>

    </request>


  • Guest
    Reply
    |
    Nov 12, 2021

    Hello,

    Thanks for raising this RFE. I have some queries regarding the RFE. Appreciate if you could provide your comments.

    1) MFT Transfer REST API provides postSourceCall, postDestinationCall, preDestinationCall, preSourceCall attributes through which commands/scripts can be executed. I was wondering if these meet your requirements?

    2) As far as I know, there is no specific command (like fteCreateTransfer command) to execute a managed call. So how have you been using the managedCall functionality? is it by putting XML message to agent's command queue or running it via resource monitor?


    Thank you

  • Admin
    Mark Taylor
    Reply
    |
    Aug 11, 2021

    This is something we hope to add in a future MFT update

0 MERGED

[Copy] Add Support for the MFT Managed Call API to the MQWeb REST Interface

Merged
The primary reason for the requests, is that we are upgrading customer MFT implementation and moving away from Ant and the fte* commands to Python scripting. We found that Ant and the fte* commands are way to expensive to use as they require a JVM...
about 3 years ago in MQ, MQ Advanced & MQ Appliance 0 Future consideration