DeKalb County Ends Manual Delivery of Oracle EBS Workers' Compensation Files with Files.com

DeKalb County is the county government for the eastern side of metropolitan Atlanta. It is Georgia's fourth-most populous county, home to more than 760,000 residents. Roughly 7,000 employees deliver county services, supported by central IT within the county's Department of Innovation & Technology.

One of its central systems is Oracle E-Business Suite, the county's ERP. Among its scheduled jobs is the workers-compensation extract: a recurring file of employee data that is produced inside the ERP but consumed outside it. An ERP is good at generating output on a schedule. Getting that output out of the ERP is a separate problem, and for the workers-compensation extract, the county's answer was a person.

Using its existing Files.com SFTP endpoint, the county turned that handoff into a scheduled system-to-system transfer without middleware or an ERP rewrite—a design that has run since 2017.

An Extract on a Schedule, a Delivery by Hand

The extract came out of EBS on a recurring basis. Its delivery did not. Someone had to take the output off the ERP's application server and move it along by hand, every cycle. That made a routine transfer of sensitive employee data a standing manual chore, and it made the flow exactly as reliable as the person carrying it. The job ran on schedule; the file moved on availability.

The step survived because removing it was nobody's single job. Making a legacy ERP push files securely on its own touched three teams at once: the systems administrators who manage keys on the application server, the Oracle EBS architects who own the county-maintained outbound module, and whoever runs the endpoint on the receiving side.

Keys on the ERP Server, an Endpoint on the County's Domain

The EBS transfer module already spoke SFTP, so the county needed an always-available endpoint that accepted SSH keys and exposed a host identity the ERP could verify—without putting new software between systems.

The county already ran such an endpoint. Its SFTP service was Files.com, presented on the county's own domain. The county made that endpoint the extract's destination.

In late 2017, the pieces came together across those three teams. The county's systems administration team generated an SSH key pair on the EBS application server, and the public key went onto the Files.com user the job would authenticate as. Host-key verification, the step where the connecting server confirms it is talking to the genuine endpoint, was worked through with Files.com's support engineers. Then the county's Oracle EBS architects configured the workers-compensation outbound module to push its files over SFTP on schedule.

That was the whole build. Nothing was rewritten, and nothing was installed between the two systems. The ERP's own scheduler drives the transfer, and Files.com is simply the SFTP server on the other end, speaking a protocol the ERP already knew. Because the Files.com endpoint carries the county's domain and dedicated IP addresses, it behaves like county infrastructure: a stable address the ERP's configuration and the county's network rules can rely on for years.

Running System-to-System Since 2017

Once the module went into production:

• Workers-compensation files move from the EBS application server to the county's Files.com endpoint every cycle, with no one touching them.
• Delivery follows the ERP's schedule rather than a person's availability. The extract leaves the moment the job runs.
• Every run is a logged transfer in the site's activity history, giving county IT a record it can export when it needs to investigate access.

The design also generalizes. Nothing in it is specific to workers' compensation: it is a scheduled job, an SSH key, a Files.com user, and a folder. Any county system that speaks SFTP can deliver its output to the same endpoint the same way.

No One Carries the File Anymore

Before late 2017, a recurring extract of employee data left the county's ERP only when a person moved it. Now it leaves on its own, every cycle, and no one at DeKalb County has to carry it. The fix required no middleware and no ERP modernization. It required a managed SFTP endpoint the ERP could authenticate to with a key, and Files.com was already there, on the county's own domain, waiting for the job to connect.