In large organization’s journey to digital, Managed File Transfer (MFT) owners are often left behind as they are not able to cope with new application development methods and architecture.
Despite big efforts made recently to build a Center of Excellence and/or Shared Service for MFT and propose “one stop shopping” for this robust and heavy load ready integration method, business application owners are reluctant to use MFT for their new projects.
The truth is that traditional MFT solutions present a functional limitation preventing it from addressing the necessary reactivity requested by business and to fit into DevOps initiatives.
A modern solution starts with REST API. For a long time, MFT products were coming with API support. Axway Transfer CFT for instance has for years come with a web service interface and also with API for Java, COBOL, and C to mention the most obvious ones.
This was useful and used for sure but it doesn’t answer the problem exposed above.
So, what is the point? There are several indeed:
- Today everything talks with everything through REST API. It is light to use and efficient. That makes whatever existed looking old and obsolete
- REST API are easy to expose, understand, use, update through the swagger interface
- Using API Management tools allows one to centralize information. It acts as a repository to access and consume MFT services
But this only addresses the usability of the API, the other point is what can we improve using the API?
Here are two examples:
- Configuring and provisioning file transfers, using API to:
- Create, update and deploy a file transfer route at the same time the application requires it. Thus introducing the file transfer within the application lifecycle and the MFT service within the DevOps initiative.
- Integrate provisioning of partners with workflow and applications, managing the partner lifecycle to ease on-boarding and maintain information accuracy over time.
- Integrating with applications to have the file being transferred within the business process, i.e. an order created through a business application is triggering a file transfer to send the bill of material to the logistician. That means the interface application doesn’t need to rely on technical MFT parameters. The MFT service is designed to translate the business Id used into the appropriate technical parameters to initiate the transfer.
Providing these two levels of API, respectively at design and run phase makes MFT part of modern IT.
More information on Digital MFT Shared Service on: www2.axway.com/boost/2