No Desktop in the Loop: Ediwise Replaced CoreFTP With Files.com for Its OpenText VAN Exchange

Ediwise sells paper inventory software and EDI transaction services into the pulp-and-paper supply chain. Its systems are trusted by 450 newspapers and more than 25 mills and warehouses to track paper through its whole life cycle and move the X12 and papiNet documents that keep newsprint 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. Ediwise 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 Ediwise and its trading partners, in both directions, on an endpoint Ediwise cannot change.

The Only Client That Would Talk to OpenText

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

The reason was compatibility. OpenText's FTPS endpoints are not standard, and OpenText recommends its own tooling rather than ordinary commercial FTP client software. When Ediwise originally built the exchange, exactly one desktop client, CoreFTP, turned out to connect reliably. 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 450 newspapers and more than 25 mills and warehouses depended on the one client that happened to work, and on the scripts and hands that drove it.

An Endpoint Ediwise Could Not Change

The workflow survived because Ediwise 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 Ediwise 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 connected.

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.

Ediwise 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, Ediwise 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 Ediwise'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 compatibility problem 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 Ediwise'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, Ediwise 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 the one desktop client that happened to be compatible; Files.com speaks to the VAN's FTPS endpoints directly.
• VAN traffic flows through the same platform as Ediwise'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. A mandated VAN with quirky endpoints did not get to dictate Ediwise's tooling or keep a human in the loop. Files.com connected to the endpoint as it is, and the quirks stopped being Ediwise's problem.