A Device Logistics Provider Runs Its Returns-to-SAP Interchange on Files.com Through a Decade of Protocol Change

A device reverse-logistics provider handles return management for wireless carriers and device makers, and it runs the line-of-business system behind device returns and warranty claims for one of the largest wireless carriers in the United States. From its earliest years, the company's differentiator was information: clients could see the state of their returned inventory at any time. So every phone that moves through the operation is also a chain of data events. Purchase orders, sales orders, and warehouse confirmations have to land in the carrier's ERP for the physical logistics to count. The returns business works only if the file exchange behind it does.

One Encrypted Exchange Point for Every Partner

In 2012, the channel carrying that data was a set of FTP servers the company ran itself, the primary delivery method for data to and from every customer. The company wanted every credential and every file encrypted in transit and at rest, on an exchange point it did not have to host.

That was the bar the company's HIPAA and Sarbanes-Oxley obligations set for encrypted credentials and encrypted data in transit. Meanwhile the volume of unattended, system-to-system traffic across the partner base kept growing.

The server was hard to replace because everything pointed at it belonged to somebody else. Partner firewall teams had whitelisted its addresses. Partner ERP jobs, scripted lftp transfers, and desktop clients logged into it on schedules the company did not control. Every one of those connections had to keep working with no new software and no rewritten transfer job on the partner's side.

That constraint was the specification for what came next. The replacement had to keep speaking FTP, FTPS, and SFTP exactly as the partners already did. It had to give each partner its own folder tree and its own credentials, carry the company's name on a branded domain, and present fixed, dedicated IP addresses a partner's firewall could pin. And it had to encrypt everything, in transit and at rest, without asking the far side to change anything beyond a hostname. The company selected Files.com to be that exchange point. It became the layer that would absorb a decade of security change without forcing the company to rebuild the carrier integration.

A Cutover the Customer Ran on Its Own

The company's director responsible for the estate ran the 2012 migration. The legacy and Files.com sites operated in parallel through the spring, with a hard shutdown of the old servers in April 2012. The director wrote the partner-facing migration notice, published the site's IP list and FTP data-port range so partner network teams could whitelist the connection, and onboarded the whole heterogeneous client base onto the new site.

The Interchange Between the Returns System and the Carrier's SAP

The integration that shows what the exchange point became was built in 2014, when the company connected its returns system directly to the carrier's SAP landscape. The returns system uploads XML data feeds to Files.com. On the other side, the carrier's SAP PI environment polls the site, pulls the feeds, and loads them as IDOCs: purchase order creates, sales order creates, warehouse confirmations. The exchange is fully automated in both directions, machine to machine, with no human in the loop to route around a failure. Each complete feed turns the movement of physical devices into the corresponding ERP event.

Files.com carries the parts of that arrangement neither endpoint could. Each partner exchanges files in its own folder tree under its own credentials. Dedicated IP addresses let the carrier's firewall pin the connection with a standing wildcard whitelist. Transfers run over explicit FTPS with TLS 1.2. Because downstream processing depends on complete files, the company's upload program verifies every upload against Files.com's file history.

A TLS 1.2 Mandate That Did Not Become a Rebuild

The hard part of a long partner integration is that the partner's side keeps moving, on the partner's schedule. In 2017 the carrier mandated TLS 1.2 across its estate, and SAP PI has rigid expectations about FTPS modes, ports, and cipher suites that the company does not get to choose. Over 2017 and 2018, the company and the carrier's SAP Basis team tested FTPS and worked through port and cipher-suite compatibility until the SAP handshake succeeded. SSL certificate renewals were coordinated the same way. Through all of it, the exchange pattern never changed. The mandate landed as protocol configuration on Files.com, not as a rebuild of the integration.

Ten Years, Thousands of Files a Day, One Exchange Pattern

With the Files.com exchange in production, the company replaced servers it hosted itself with an interchange that has now carried its largest partner integration for more than a decade. The results are the kind that only show up over years:

• Thousands of XML files move through the site every day for the carrier's SAP process, continuously for more than a decade, with nobody touching a file.
• The pattern absorbs peaks: a backlog of accumulated traffic once cleared in a single day, with thousands of files moving in each direction.
• The carrier's firewall whitelist structure against the site has held for more than ten years, through a TLS mandate, cipher-suite negotiations, and certificate rotations, without the integration being rebuilt.
• Every partner exchange runs encrypted in transit and at rest, the configuration the company's HIPAA and Sarbanes-Oxley obligations call for, on infrastructure the company no longer hosts.

The pattern also compounds. Onboarding the next partner stopped being an infrastructure question: it is a folder tree, a credential, and the published IP list, on the same site the strictest partner already connects to. The company has run that motion repeatedly, bringing manufacturers and additional partners onto the same exchange.

The Layer That Absorbs the Churn

More than a decade on, what changed is what the company's most important connection is made of. Before Files.com, the link to its customers was a set of FTP servers the company hosted itself. Today, when the carrier's requirements move, and they always do (new TLS versions, new cipher policies, new certificates), the work is a negotiation over settings rather than a project against infrastructure. The endpoints of a long integration never stay still: the returns system evolved, the carrier's SAP landscape was retested and retightened more than once, and the security bar kept rising. The integration itself is still the one built in 2014, because the layer between the endpoints, Files.com, absorbed the churn on both sides' behalf.