A file drop is an integration in which a producer places a file where a consumer can retrieve and process it. Its contract includes the file’s contents, the signal that it is complete, and the meaning of successful processing. The folder path describes only one part of that contract.
A transfer can finish while the business operation remains incomplete. The receiving program might reject a record, stop after updating half the accounts, or process the same delivery again following a restart. Each outcome requires an agreed interpretation.
Completion has to be observable
The presence of a filename does not establish that its writer has finished. A consumer that starts too early can read a partial file and treat missing records as an intentional omission.
A completion marker, a documented transfer status, or an agreed rename procedure can provide a readiness signal. The selected mechanism must work on the actual storage and transport. Rename atomicity, locking behavior, and concurrent access cannot be inferred from a folder name or from success on a different operating system.
Apache Camel 4.18.x exposes several file-consumption and completion options while warning that detecting concurrent writes depends on the environment. Selecting an option is the start of a compatibility test, including interrupted writes and producer restarts.
Syntax and meaning are separate
A CSV parser interprets delimiters and quoting. It still needs a schema explaining what each field represents. An account identifier containing leading zeros, a decimal amount, and a timestamp have different conversion rules even when all arrive as text.
RFC 4180 describes a CSV grammar that permits quoted commas and line breaks. Under that grammar, splitting every physical line on commas is insufficient. The RFC is informational; an existing feed must be inspected to determine its actual dialect.
The contract should specify encoding, column order, headers, empty and null values, units, date interpretation, and schema changes. Fixed-width exchanges need equivalent rules for byte positions, record variants, and padding. An extension cannot supply these decisions.
Delivery needs an identity
A filename can identify a business period, a delivery attempt, or a unique dataset. These meanings produce different retry behavior. If a corrected file reuses yesterday’s name, a consumer that ignores previously seen names could discard the correction.
Suppose a producer sends a daily invoice extract, then resends it after an uncertain acknowledgment. The consumer needs to distinguish repeating the same extract from receiving an amended extract. A delivery identifier, revision rule, and retained processing result can make that distinction explicit.
Deduplication also needs a business boundary. Recognizing the same file twice does not prevent duplicate invoices if the first attempt committed some rows before failing and the retry starts from the beginning.
Acceptance belongs to the receiver
Transport confirmation establishes a transport result. Business acceptance requires evidence from parsing and processing. Useful reconciliation can account for accepted records, rejected records, totals, and downstream actions against the delivered input.
A rejection should retain enough context for correction without silently changing the original. The process needs an owner for unresolved records and a rule for whether accepted records remain committed when other records fail.
An empty delivery also needs meaning. It might report no activity, indicate an upstream extraction failure, or act as a scheduled heartbeat. The consumer cannot choose safely among those interpretations without a contract.
Changing the transport preserves the questions
Replacing a folder with a queue or API changes how data moves. Completion, identity, semantic interpretation, correction, and replay remain application responsibilities, although a different transport can supply different supporting mechanisms.
A governed file exchange can be sufficient for a scheduled workload. Its acceptance test should demonstrate late arrivals, malformed input, duplicate delivery, partial processing, and recovery. The deciding evidence is whether the complete exchange meets the business timing and recovery requirements.