A real-world digital transformation demo: Amplify Managed File Transfer

Digital transformation is one of the biggest business IT transitions at this time. At Axway, with Amplify Managed File Transfer, we work with clients across the Managed File Transfer space to bring digital transformation and simplify existing processes to deliver a more co-existing stack of services for organizations.

Digital transformation

Here in the Sydney office, we brainstormed and came up with a POC (Proof of Concept) to demonstrate how and what an end-to-end Digital Transformation solution using AMPLIFY MFT would look like using relevant solutions. It’s paramount for the POC to resonate with clients on their day-to-day MFT operations and show the business benefits.

The final solution is a mobile/tablet app that fuses two accounts, shows lists of files and file transfer status for each one of these accounts. And it all takes less than two minutes to onboard a customer!

Here we look at each component (product) and discuss its part in the final solution and provide steps to replicate the solution on your end.

The following components are used in delivering our POC

• MFT ST (Secure Transport). Since most/all customers use ST in Australia, we went ahead and built the solution on ST, version 5.3.6, on our “reference environment.” The solution should also work in newer versions of ST as well.
• Amplify API Management Platform is an integral part of the final solution offering. Alternatively, one could utilize as well to group and orchestrate multiple APIs into a single API.
• Tablet/smartphone app was built using the Axway Appcelerator Solution. The source code is attached and will also be made available on GitHub.  

Details of digital transformation

Secure Transport. Most Axway customers in Australia and APAC utilize ST as their MFT solution. Hence, we have selected ST as the base product of our POC. Beginning with version 5.3.0, ST has enabled a rich list of granular APIs for easy integration and automation.

These APIs are quite thorough. Multiple APIs may need to be called for what may seem like a single operation from the Web UI. Depending on the user role, different sets of APIs are made available for both “Admin” and “End-User” account types.

• Admin APIs: These APIs replicate most of the ST Admin UI capabilities. In our POC, we have used the following Admin APIs:
  • “account” API: CRUD operations under “account” API offers a list of functionalities. “account” API is used for
    • Creating an account
    • Configuring the account
    • Provisioning a user for the account
  • “sites” API: Enables creation of a “Transfer Site”
  • “subscriptions” API: This is a three-step process. Create subscription -> Get Subscription ID -> Configure (link to “transfer site”) subscription

Overall, there are seven API calls made in this example to provide an account that is ready to push/pull files.

If you are interested in seeing the full list of admin APIs available, you can access and browse them within your ST environment via “Your_ST_Admin_URL:444/api/v1.4/docs”

• End-User APIs: These APIs are the restricted, end-user APIs that enables account owners/users to transfer, inquire file transfer and status, etc.

Following “end-user/account” APIs are used in our example:

• “files” API: Lists the files in logged-in user’s account at the top level. This enables users to proactively check to see if expected files are received or sent (file deletion/rename upon delivery).

• “transfers” API shows the default file transfer history of an end-user. Again, the same API is used to display details of a transfer by providing additional parameters.

You can access and browse the “end-user/account” APIs within your ST environment via “Your_ST_Admin_URL/api/v1.4/docs”

API Gateway

As mentioned, API Gateway is an integral part of the solution. We already saw that provisioning an account, transfer site and subscription require seven API calls. This number may change depending on the level of modification and customization one would like to apply on an account.

While the API enablement of ST is great for automation and integration, this can be further simplified for developer/end-user consumption. For example, using API Gateway, we can orchestrate the seven API calls into a single end-URL API for developers.

Developers don’t have to worry about which API to call and the sequence to follow or need to have a good understanding of how Secure Transport works. Without the API Gateway (or API Builder) a normal schedule to use the ST APIs to onboard an account would result in (for the specific example):

• 1. ”account” API call: to create the shell account
• 2. “account” API call: to configure the account to allow REST API calls
• 3. “account” API call: to add the user to the account (login, password, etc.)
• 4. “sites” API call: to create a Transfer Site
• 5. “subscriptions” API call: to create a Subscription (push/pull files)
• 6. “subscriptions” API call: to get the ID of the Subscription created above
• 7. “subscriptions” API call: to associate the “subscription” with the “Transfer Site” created

As you can see, implementing ST APIs on their own would require multiple API calls. While this is not an issue, the developers (internal or external) would also need to familiarize themselves with each one of these APIs at every step. Using the API Gateway, we can further improve and simplify the basic offering to create something customized to meet the exact requirements of the organization and developers.

A quick summary of the benefits

1. Build custom APIs that meet the exact requirements of the organization. Expose only what is relevant and safe to share.
2. Minimalize the set of parameters in API calls to make it intuitive and easy to use. Implement by API developers, improve the developer experience.
3. Remove the complexities around implementing logic inside applications.
4. Reflect changes in ST APIs with little or no impact on developers.
5. API flow control and management.
6. Added security.

In addition, the API policies (flows) created can be reused by other API policies in the API Gateway. This reduces the effort required by API teams to build and deploy new APIs.

Below is the screenshot of the “onboard customer” API policy. As you can see, it exposes a single API end-point.

Note that we are creating two accounts in our example. Our sample API policy is basic and doesn’t handle every failure situation, yet fully functional for customer demonstration. To hide the complexity from developers and keep the required parameters to a minimum, some fields are entered as static values in policies.

You have two options to replicate the API policy above

1. Import the policies included.
2. Create your own by using the example policy as a sample template.

Notes

Update “User Connection – GET,” “Admin Connection” and “Admin Connection – GET” policies to reflect your ST IP/URL

• ST Admin user is configured within “Environment Configuration -> Users and Groups -> Users.” In our case credentials are “admin-admin”

Hint: You can remove reliance on this configuration and ask admin user for login details, like in “File Lis” and “Transfer History” policies.

• Transfer Site policy needs to be updated to reflect the second account’s IP address/URL (in this case it is hosted on the same machine as your ST) and ST’s port configuration for “ssh” file transfer protocol.

Once the policy is created and deployed, the end-point URLs need to be used within the mobile application.

Alternatively, for a more complete solution, you should deploy the API end-points through API Manager. 

Axway Appcelerator Mobile Application. What better way is there to demonstrate a POC where customers/users can install and interact with a POC solution directly from their mobile devices?

Our mobile app was built to display some of the most common features and capabilities requested by customers:

• Further, simplify the onboarding process to enable BUs (business units) to take ownership of customer/account onboarding. This would significantly reduce the effort, cost and time to onboard customers.
• “Where is my file” and “status of my file transfer.”

The mobile app showcases the following three functionalities

1. Onboard two accounts and provision one of these accounts with “Transfer Site” and “Subscription” to transfer file(s) into the other account.
2. Show the list of files in an end user’s account.

Display the history of file transfers for an end-user account. Users can get detailed information on a particular transfer as well.

When you import th code, there are a few places where the code needs to be updated to reference the end-URLs, where the MFT ST APIs are deployed. Code in orange color is to be updated in your controller (.js) files.

xhr.open(‘POST’, ‘http://192.168.2.138:8080/onboard’);

xhr.open(‘GET’, ‘http://192.168.2.138:8080/listTransfers??limit=10‘);

xhr.open(‘GET’, ‘http://192.168.2.138:8080/listTransfers?/’ + args.transferID);

xhr.open(‘GET’, ‘http://192.168.2.138:8080/listTransfers?/’ + args.transferID);

var credentials = Ti.Utils.base64encode((“admin:admin”)).toString();

Above, replace admin/admin ST admin credentials with your ST’s admin credentials.

Note that Mobile App is only tested on iOS, iPhone and iPad. This may require small modifications to work on Android devices (navigation window implementation). The outcome, when demonstrated with the capabilities, had our customers and partners very excited.

Check out this great video for more MFT information.

Some of the ideas and benefits shared by customers and partners were:

• Reduce possible manual human errors.
• Quicker time-to-market solutions.
• Integration with CI/CD and other application and third-party solutions.
• Reduced expertise in MFT ST, intuitive solutions.
• Reduce cost and time for customer onboarding.
• Consolidation of file transfer solutions.
• Quicker issue-to-resolution times.
• Proactive monitoring.
• A delegation of processes to BUs

Simply visit our developer portal for tutorials, demos and articles to turbocharge your MFT services!