Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Coupling MFT APIs in Your Design/Code: Good or Bad?

DZone 's Guide to

Coupling MFT APIs in Your Design/Code: Good or Bad?

Is coupling MFT APIs in your code bad?

· Integration Zone ·
Free Resource

Recently, I was doing a code review for one of our customer interfaces and came across some code portions that made me think about posting this article. The interface was file-based, where the system running the integration logic writes a file outcome to its local file system or network file system attached to the machine. The final expected action is to move those files written to the dedicated local folder to a remote file system via SFTP.

To manage these kinds of file-based activities, the organization already procured a Managed File Transfer server, which is very good at its own work. However, the strange thing I noticed is that in the integration code, right after the local file is written, the integration system itself is kicking in the MFT event action to move the files from local to remote SFTP. I find this peculiar because, in my opinion, MFT is not exactly meant to be used this way. The reason why enterprises procure MFT licenses is to get rid of such file-based actions or operations in the business logic designs/interfaces.

The ideal way should be that the interface should write its file in its local/attached file system and rub its hands together, saying job done. MFT then comes into the picture without former systems interference and actions its jobs in whatever way configured. This way, these two are completely uncoupled and clean.

Should the customer decide to change their MFT server from ‘X’ to ‘Y’? It will not matter, as the ‘Y’ is also going to accomplish the same job as ‘X’ even without the interfaces knowledge. It's the same way interface logic can be changed any way, and as long as the file comes as an outcome, that is all that matters.

The whole point I am trying to make is that designs should be planned and should fit the enterprise environments as per their toolsets, product suites, etc. Systems dedicated to do their jobs should only do that job. I understand that these systems come with internal APIs, and questions may arise asking why we have been provided with those APIs. My answer for those questions would be those APIs are meant for custom frameworks that you can develop to have customized features on top of out-of-the-box features.

What should we do?

  1. Always design your interfaces without any coupling to products/tools.
  2. Make sure the products your enterprise procure are only doing their job and nothing else.
  3. Think about disposable design and architecture wherever applicable.
  4. The same rules should apply to products too. Do not invoke any business interface services directly from products/tools like MFT. You should try to avoid such kinds of coupling as much as possible.

Hit me with your opinions if you think otherwise.

Topics:
coupling ,design and development ,integration ,mft apis

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}