An Online Retailer Replaced ShareFile with Files.com as the SFTP Landing Zone Feeding Its Webshop

A European online retailer sells home, garden and DIY goods in dozens of countries. It serves customers through its own webshop and marketplace channels, with product data and catalogue operations at the centre of its IT estate.

What the retailer has never had is a physical store. The shelf its customers browse is product data. Every item in the catalogue reaches the storefront as files: product descriptions, inventory counts, images. Those files are produced by teams in Asia, and they have to flow continuously into the e-commerce platform serving every country the retailer sells in. No person carries them. The pipeline is machine-to-machine, and the layer it runs over sits in the critical path of the entire retail operation.

Product Data That Outgrew a File-Sharing Tool

The layer carrying that pipeline was ShareFile: internal systems depositing product, inventory and image files at one end, an integration platform collecting them at the other, all day, at growing volumes. The volume outgrew it. The retailer hit technical difficulties and server-load issues on ShareFile as the traffic climbed.

The product-data pipeline had outgrown a file-sharing tool. For a retailer whose only shelf is the webshop, the feed of catalogue and inventory data has to keep moving at whatever volume the catalogue reaches, and the retailer wanted it on a landing zone built for that load.

The pipeline was also not a point-to-point transfer that could be patched around. Files originated from teams on two continents. They landed in staging folders at high volume and high churn, and on the far side MuleSoft, the retailer’s integration platform, collected everything over SFTP on its own schedule and routed it onward into the webshop and Salesforce. The volume was only going up.

What the Replacement Had to Do

The pipeline itself was sound. MuleSoft owned the orchestration, scheduling and routing, and the webshop and Salesforce sat downstream of it. None of that needed rebuilding. What needed replacing was the ground underneath: the place where files land, wait, and get collected.

That ground had to present a standard SFTP endpoint, so MuleSoft’s existing SFTP connector could keep collecting without custom development. It had to stay available, because business-critical processes depended on files moving. It had to give the integration a machine identity of its own rather than a person’s login, keep high-churn staging folders from accumulating without limit, and hold the data in Europe.

The retailer selected Files.com to be that landing zone.

An SFTP Landing Zone Built for Machines

The retailer placed the landing zone in the Files.com Germany region, so the product data stayed in Europe. Internal systems delivered product, inventory and image files, in XML, CSV and JPG, into staging folders over SFTP.

The collection side ran on a dedicated Files.com service account scoped to the MuleSoft integration. MuleSoft retained its existing SFTP connector, leaving the rest of the pipeline untouched.

The staging folders also maintained themselves. Files.com retention policies expired staged files on a schedule, so landing zones that turned over files every day stayed working folders instead of becoming unbounded archives.

Tens of Thousands of Files in One Folder, and the Layer Holds

• A single inventory staging folder carries tens of thousands of files and hundreds of gigabytes, and it grows every day. The SFTP layer absorbs it.
• Product, inventory and image data from teams in Asia reaches a storefront selling in dozens of countries with no person in the path: systems deposit, MuleSoft collects, the webshop and Salesforce update.
• Usage stepped up well beyond its starting baseline, and a second team at the retailer adopted Files.com.

The Ground Under the Pipeline

Today, a team in Asia finishes a batch of product images, a system drops them on Files.com, MuleSoft collects them, and the storefront updates in dozens of countries.

The retailer did not rebuild its pipeline. What the company recognised is that the layer between its systems is infrastructure, not file sharing, and it moved that layer onto Files.com, a platform built to be hammered by machines rather than browsed by people. The pipeline that outgrew a sharing tool now grows every day on a platform designed for exactly that load.