What the term means
File content conversion is a message transformation step. The transport can stay a file while the content changes shape: CSV, fixed-length text or another source layout goes in, XML comes out. On the outbound side it runs the other way, flattening XML back into something a legacy receiver can read.
The name is a little misleading, because nothing about the file changes — no extension is rewritten, no archiving happens. What changes is the content: how the bytes are grouped into records and fields, and what those groups are called once they are XML elements.
This is different from renaming a file extension. A reliable conversion maps fields, delimiters, records, character encoding and optional values so the receiver gets predictable data rather than something that merely parses.
Where it runs
Content conversion is a property of the adapter channel, not of the mapping. It runs in the file or SFTP adapter as the message enters or leaves the pipeline, which means it happens before the first message mapping sees anything.
That ordering is the source of a lot of confusion. When conversion produces XML that is subtly wrong — a header line swallowed as data, a field shifted by one position — the fault surfaces later as a mapping exception or a receiver-side error. People then debug the mapping, which is downstream of the actual problem.
The practical rule: if the incoming XML is not shaped the way your mapping expects, stop looking at the mapping and look at the channel.
The two directions
The same feature is configured on both sides of an interface, but the work is not symmetric.
- Sender channel — flat file to XML. The adapter reads the file, splits it into records and fields using your parameters, and builds an XML document whose element names come from your configuration.
- Receiver channel — XML to flat file. The adapter walks the XML and writes it back out as delimited or fixed-length text, which is the configuration people find fiddlier because the receiver is usually a legacy system with rigid expectations.
A single interface often has both — a CSV arrives, gets converted and mapped, and leaves as a differently shaped flat file for the target system.
Describing the file to the adapter
Conversion is driven entirely by a description of the file. You are not writing code; you are telling the adapter where records end, where fields end, and what to call each one. The three that matter most:
- Recordset Structure — the shape of the document, written as node names with their cardinality, for example
Data,*for unlimited repetitions of a node called Data. - fieldSeparator — the character that splits a record into fields. A comma for CSV,
\tfor tab-delimited. - endSeparator — what marks the end of a record, usually a newline.
Around those sit parameters for skipping preamble lines, splitting by fixed width instead of delimiters, naming fields explicitly, handling quoted values, and recognising which record type a given line is when a file mixes several. Each one is covered in content conversion parameters.
If you would rather see it applied, the CSV to XML walkthrough takes one file end to end.
What it will not do
Knowing the boundaries saves a lot of time, because several of them produce failures that do not look like boundary problems.
- It will not read encrypted files. The adapter has to parse the payload to convert it, so an encrypted file has to be decrypted first — by modules, in a specific order. This is covered in content conversion with PGP.
- It is not a mapping. Conversion gives you structure. Renaming elements, changing values, joining fields, applying lookups — that is mapping work, and it happens after.
- It does not validate your data. A file that parses cleanly can still be semantically wrong. Conversion only guarantees the shape.
- It has no opinion about correctness. If your separators are wrong but self-consistent, you get well-formed XML containing nonsense. Nothing errors.
Content Converter vs Content Modifier
A Content Converter changes the representation of the message body. A Content Modifier is better suited to setting or replacing headers, properties and small body fragments. Reaching for the wrong one is a common source of configuration that looks correct but never fires.
The two are compared properly in Content Converter vs Content Modifier, including why a Content Modifier placed where a Converter belongs will silently do nothing.
Why it fails
Most failures are a misunderstanding of the source file rather than a mistake in the tool. Delimiter mismatches, encoding conflicts, field length errors and missing key fields account for the large majority, and they are distinguishable from each other quickly — you do not need to re-read the whole configuration each time.
Compare raw payload bytes rather than rendered text. An editor that silently normalises line endings will hide the problem you are hunting. Check byte order marks, trailing delimiters, escaped quotes, namespace handling and the receiver's expected root element, in that order.
The error guide works through each cause and what it looks like from the outside.
PI/PO vs Cloud Integration
Since PI/PO reaches end of support in 2027, many of these interfaces are being rebuilt on SAP Cloud Integration. The concept survives the move; the configuration does not.
Cloud Integration handles CSV to XML through a converter driven by an XSD rather than by separator parameters. In practice that means the incoming file often has to be brought into a different structure than the one PI/PO produced, which in turn means the existing mappings need revisiting — not just the channel settings ported across.
The practical implication for a migration: treat the conversion step as a redesign, not a copy. Interfaces that worked for years on a PI/PO recordset definition are the ones most likely to need mapping changes.
Where to go next
- Content conversion parameters — the full reference, one parameter at a time.
- CSV to XML, step by step — a worked example end to end.
- Content conversion errors — what each failure actually means.
- Content conversion with PGP — when the file arrives encrypted.