File Content Conversion parameters in SAP PI/PO control how the adapter identifies records, separates fields, constructs XML elements, and handles differences between the expected and actual file structure. The most important settings include fieldSeparator, fieldNames, recordsetStructure, keyFieldName, and fieldFixedLengths.
Selecting the correct parameters depends on the source file layout. A simple CSV file needs different parsing rules from a fixed-width document or a file containing headers, transaction records, and trailers.
1. fieldSeparator: Identifying Individual Data Fields
The NameA.fieldSeparator parameter specifies the character or string separating individual fields within a record.
For example, consider this pipe-delimited inventory record:
The pipe character separates four values representing a product ID, product name, quantity, and price.
Setting Item.fieldSeparator=| instructs the adapter to identify each field at the pipe separator.
This parameter is particularly useful for CSV files, tab-delimited records, and other formats where field positions are determined by delimiters rather than fixed character lengths.
An incorrect fieldSeparator can prevent the adapter from dividing the record into the expected fields. Before configuring this setting, inspect the source file rather than assuming that every text file uses commas.
2. fieldNames: Defining XML Element Names
The NameA.fieldNames parameter assigns names to the fields extracted from each source record. These names determine the corresponding elements in the generated XML structure.
For a comma-separated record containing three values, the configuration might be:
Item.fieldNames=ProductID,ProductName,Quantity Item.fieldSeparator=,
Input:
The resulting XML record can contain ProductID, ProductName, and Quantity elements populated with the corresponding values.
The fieldNames configuration must match the expected source field sequence. When delimiter-based parsing is used, the formatting of fieldNames must also follow the applicable separator rules.
Changing a field name does not transform the meaning of the data. For example, renaming Quantity to Price will not perform a calculation or convert the underlying value.
3. recordsetStructure: Controlling Record Types and Occurrences
The Recordset Structure parameter defines which substructures can appear within a recordset and how many times each substructure is expected.
Consider a sales order file containing one header record followed by multiple item records.
An illustrative structure is:
Here, Header represents one header record, while Item represents a variable number of item records. The asterisk allows zero or more occurrences.
A file could contain:
H,ORD5001,2026-10-08 I,SKU101,2 I,SKU205,5
The first record contains order information, while the following records represent individual items.
The configuration must also identify which incoming line belongs to each substructure. For variable substructure layouts, this typically involves the Key Field Name and structure-specific key values.
Recordset Structure defines record organization. It should not be confused with Recordsets per Message, which controls how recordsets are grouped into integration messages.
4. keyFieldName and keyFieldValue: Distinguishing Record Types
A file containing different record types needs a reliable way to identify each line.
The Key Field Name parameter identifies the field used to distinguish substructures, while NameA.keyFieldValue defines the expected value for each record type.
Using the preceding sales order example:
Key Field Name = RecordType Header.keyFieldValue=H Item.keyFieldValue=I
The configuration identifies lines beginning with H as header records and lines beginning with I as item records, provided that the key field is defined consistently in the corresponding substructures.
For this approach, the key field must be included in each applicable structure definition. The Key Field Type determines how the configured values are compared.
Incorrect key values may cause the adapter to assign records to the wrong structure or fail during conversion.
5. fieldFixedLengths: Parsing Fixed-Width Files
Not every flat file uses commas, pipes, or tabs. Some legacy applications store fields at predefined character positions.
The NameA.fieldFixedLengths parameter specifies the expected length of each field.
For example:
Item.fieldFixedLengths=3,6,4
Input:
The adapter can interpret the record as three fields:
| Field | Value | Length |
|---|
| Product Code | ABC | 3 |
| Product Name | WIDGET | 6 |
| Quantity | 0012 | 4 |
Unlike delimiter-based conversion, fixed-width parsing depends on the assigned field lengths.
The NameA.fieldFixedLengthType parameter determines whether those lengths are measured in characters or bytes. This distinction matters when files contain multibyte characters, because the number of bytes may differ from the number of visible characters.
Incorrect field lengths can shift the parsing position and produce values containing parts of adjacent fields.
6. enclosureSign: Handling Delimiters Inside Field Values
CSV data sometimes contains separators that belong to a field value rather than separating two fields.
Consider this customer record:
1001,"Acme, West Division",500
The comma inside the customer name is part of the value. It should not create another field.
The NameA.enclosureSign parameter identifies the text enclosure character, such as a quotation mark.
When configured appropriately, the adapter treats enclosed text as a single field even when that text contains the normal field separator.
Related parameters include NameA.enclosureSignEnd, NameA.enclosureSignEscape, and NameA.enclosureConversion. These control closing enclosures, escaped enclosure characters, and whether enclosure characters are retained or removed.
For CSV files with quoted customer names, product descriptions, or address fields, testing enclosure behavior is essential.
7. beginSeparator and endSeparator: Managing Record Boundaries
The NameA.beginSeparator parameter identifies an optional string before the first field of a record, while NameA.endSeparator identifies a string following the final field.
These settings are useful when input records contain prefixes, closing characters, or specific line-ending sequences.
The endSeparator setting requires particular attention because line endings are not always identical across operating systems or file-generation applications.
A file may contain line feed characters, carriage returns, or a combination of both. If the configured boundary does not match the incoming data, conversion can fail or interpret the record incorrectly.
Before changing record separators, inspect the raw file encoding and line-ending characters using a suitable text or hexadecimal editor.
8. missingLastFields and additionalLastFields: Handling Unexpected Columns
Real integration files do not always match the expected structure. A source system may omit optional trailing values or introduce an additional column.
The NameA.missingLastFields parameter controls how the adapter handles records containing fewer fields than expected.
| Value | Behavior |
|---|
ignore | Omit missing trailing fields from the generated XML |
add | Include the configured fields with empty values |
error | Stop conversion when required trailing fields are missing |
The NameA.additionalLastFields parameter controls records containing more fields than configured. It supports the values ignore and error.
For example, if an interface expects ProductID, Quantity, and Price but receives only ProductID and Quantity, missingLastFields determines how the incomplete record is handled.
For integrations where every field must be present, explicit error handling can prevent incomplete records from continuing unnoticed.
For interfaces with genuinely optional fields, adding empty XML elements may be more appropriate, provided the receiving message structure supports them.
The behavior of missing and additional fields can differ depending on whether fixed-length parsing is configured. Both parameters should therefore be set explicitly and tested with realistic input files.
For help diagnosing field-count and separator problems, see Common File Content Conversion Errors.
9. Other FCC Parameters Worth Understanding
Several additional settings influence how FCC constructs and packages the output.
- Document Offset: Specifies how many initial lines to skip before processing. This is useful when incoming files include a column-heading row.
- ignoreRecordsetName: Controls whether the recordset wrapper element appears in the generated XML.
- Recordset Sequence: Determines how the adapter identifies recordset boundaries when the sequence or number of substructures varies.
- Recordsets per Message: Controls how many recordsets are grouped into a single integration message. The default asterisk setting includes all recordsets in one message.
- fieldContentFormatting: Controls whitespace handling. The value trim removes leading and trailing spaces, while nothing preserves them.
These settings should be selected according to the actual input format and expected XML structure, rather than enabled without a specific requirement.
Which FCC Parameters Should You Choose?
The correct combination depends on what the source file contains and how the receiving interface expects the data to be structured.
| Input Requirement | Relevant Parameter |
|---|
| Comma or pipe-delimited records | fieldSeparator |
| XML names for extracted fields | fieldNames |
| Fixed-width data | fieldFixedLengths |
| Quoted values containing delimiters | enclosureSign |
| Header, item, and trailer records | recordsetStructure |
| Identification of different record types | keyFieldName and keyFieldValue |
| Missing trailing columns | missingLastFields |
| Unexpected additional columns | additionalLastFields |
| Initial lines that should be skipped | Document Offset |
| Multiple recordsets per integration message | Recordsets per Message |
One important distinction is that Document Offset is used to skip initial lines during sender-side conversion. The receiver-side NameA.addHeaderLine parameter serves a different purpose: it controls header-line generation when XML is converted into a text file.
For the complete channel setup process, refer to the FCC Configuration Guide.
Always validate parameter choices against the SAP PI/PO adapter version, message structure, and representative input files before deploying an integration to production.
