No Desktop in the Loop: An EDI Software Provider Replaced CoreFTP With Files.com for Its OpenText VAN Exchange

A supply-chain EDI software provider sells inventory software and EDI transaction services into the pulp-and-paper industry. Publishers, mills, and warehouses use its systems to track paper through its whole life cycle and move the X12 and papiNet documents that keep it flowing.

That work is time-sensitive by design. A shipment manifest that arrives late is paper that is not where a press expects it to be. The provider positions itself as the direct liaison that handles transaction failures immediately. The business sits between publishers, mills, and warehouses, which means its own transfers run against endpoints other parties control. The most important of those is a value-added network: the OpenText (GXS) VAN that carries X12 traffic between the provider and its trading partners, in both directions, on an endpoint the provider cannot change.

A Desktop Client in the Middle of a Machine-to-Machine Exchange

An exchange the provider describes as essential to its business ran through hand-driven scripts on a desktop FTP client.

The reason was the endpoint's client requirement. OpenText's FTPS endpoints require a specific client implementation, and OpenText recommends its own tooling. When the company originally built the exchange, it built it on the desktop client that met that requirement, CoreFTP. So the workflow was built around it: scripts driven through CoreFTP moved outbound X12 documents to the VAN and collected inbound documents from it, against a continuous stream of production EDI files.

That put a person and a desktop tool in the middle of what is, by nature, a machine-to-machine interchange. The exchange supporting the company's publishers, mills, and warehouses depended on one desktop client, and on the scripts and hands that drove it.

An Endpoint the Provider Could Not Change

The workflow stayed in place because the provider could not change the partner-mandated VAN. Any replacement had to speak to OpenText's FTPS servers as they were, in both directions, without interrupting production traffic. The CoreFTP workflow met that bar, so it stayed. Even as the company consolidated its trading-partner file transfer onto Files.com, with partners connecting over SFTP and its Azure Logic Apps platform orchestrating the workflows, the VAN exchange kept running on the desktop because nothing else in the estate yet met the VAN's client requirement.

It could not stay there. A hand-run workflow does not scale with a transaction business. What replaced it had to move documents in both directions unattended and land that traffic in the same place the rest of the transfer estate already lived, with no custom client anywhere in the path.

The provider made Files.com the interchange point with the VAN itself.

A Send Folder, a Receive Folder, and No Desktop in Between

Using Files.com Remote Server Mounts and Remote Server Sync, the company connected the platform directly to OpenText's FTPS endpoints. Outbound X12 traffic lands in a send folder on the Files.com site, and Files.com delivers it to the VAN. Inbound traffic is pulled from the VAN into a receive folder, where the provider's systems collect it. The Logic Apps integration platform works against those folders the same way it works against everything else on the site.

The client requirement did not disappear; it moved to where it belongs. Files.com holds the FTPS connection to the VAN's servers, so no client is installed anywhere and no script has to be run by hand. And because the folders sit on the same site that already fronts the provider's trading partners, each provisioned as its own user with a write-only inbound folder, the VAN traffic joined the governed hub instead of running beside it. The same mount-and-sync pattern reaches partner FTPS endpoints as well, so connecting to a third-party server is a configuration on the platform rather than a project on a desktop.

The Essential Exchange Runs Unattended

With Files.com connected to the VAN, the provider replaced a hand-run desktop workflow with an unattended, folder-driven exchange.

• Two-way X12 traffic with OpenText moves machine to machine, with no scripts to run and no person in the loop.
• The exchange no longer depends on a single desktop client; Files.com speaks to the VAN's FTPS endpoints directly.
• VAN traffic flows through the same platform as the provider's trading-partner transfers, so it carries the same permissions and activity logging as the rest of the estate instead of running as a side channel.

The VAN Still Sets the Rules, but Not the Tooling

For a company whose whole business is moving its industry's documents between parties it does not control, the interchange it describes as essential now runs on the same terms as everything else it operates: unattended, logged, and independent of any single machine or tool. The VAN's client requirement did not get to dictate the provider's tooling or keep a human in the loop. Files.com connected to the endpoint as it is, and meeting that requirement stopped being the provider's problem.