File content conversion is an important part of enterprise system integration. Businesses frequently exchange data between SAP applications, databases, third-party platforms, and legacy systems, but these systems do not always use the same file formats. One application may generate a CSV or fixed-width text file, while another expects structured XML.
File content conversion helps bridge this gap by transforming data into a format that the receiving system can process. In SAP Process Integration (PI) and Process Orchestration (PO), File Content Conversion (FCC) provides a built-in way to convert supported flat-file structures into XML and convert suitable XML structures back into text files.
When files contain sensitive information, such as financial transactions or customer records, the integration process may also need PGP encryption and decryption. In these scenarios, the order of processing matters: encrypted data must be decrypted before the underlying file content can be parsed, while outgoing content generally needs to be converted before it is encrypted.
This guide explains how file content conversion works in SAP PI/PO, when to use FCC, how to approach PGP-enabled file integration, and how to troubleshoot common problems.
What Is File Content Conversion?
File content conversion is the process of transforming data from one file structure or representation into another so that different applications can exchange information successfully.
For example, a supplier might send an order file containing comma-separated values, while the SAP integration flow expects an XML message. File content conversion can parse the incoming records and produce an XML structure that the integration process can map and route.
Similarly, an SAP application may generate XML data that an external payroll, logistics, or reporting system expects as a text file. The conversion process can produce the required flat-file output when the source structure and configuration are compatible.
Common file formats and structures include:
- CSV files containing comma-separated values.
- Pipe-delimited or tab-delimited text files.
- Fixed-width records with predefined field positions.
- XML documents containing structured business data.
- Text-based transaction files exchanged with external systems.
The conversion process does not automatically resolve every difference between two applications. Field names, record structures, date formats, business rules, and mandatory values may still require message mapping or additional processing.
What Is File Content Conversion in SAP PI/PO?
In SAP Process Integration and Process Orchestration, File Content Conversion is a capability of the File Adapter that supports conversion between flat-file content and XML-compatible message structures.
SAP PI/PO acts as middleware between connected applications. It receives messages, applies routing and transformation logic, and delivers the resulting data to the destination system.
Without suitable conversion, an integration flow may receive a text file that downstream processing cannot interpret as the expected XML message. FCC helps prepare the payload for integration processing or produce a compatible text file at the receiver side.
There are two common conversion scenarios.
Sender-Side File Content Conversion
Sender-side FCC is used when a source system supplies a supported flat file that needs to become an XML message.
A typical example is an external supplier sending a CSV file containing order details. The sender File Adapter reads the file and applies the configured content conversion rules. The resulting XML message can then enter the integration flow for mapping, validation, routing, and delivery.
Receiver-Side File Content Conversion
Receiver-side FCC is used when the integration flow produces XML, but the destination expects a flat file.
For example, an SAP application might produce employee payment information in XML, while an external system expects a pipe-delimited text file. Receiver-side conversion can generate the required output structure when the XML hierarchy and conversion configuration are compatible.
The key difference is the direction of transformation: sender-side conversion typically prepares incoming flat-file data for XML processing, while receiver-side conversion prepares XML data for flat-file delivery.
How Does File Content Conversion Work?
A standard integration scenario can be understood through five stages.
1. Source File Creation
The source application creates a file in an agreed format. This may be a CSV, a fixed-width text file, or another supported flat-file structure.
Both systems must agree on the file’s field order, record layout, character encoding, and other relevant formatting rules.
2. File Adapter Processing
The sender File or FTP Adapter reads the file according to its configured transport and file-processing settings.
The adapter identifies the file and applies the configured conversion rules where applicable.
3. Content Parsing and XML Generation
FCC interprets the flat-file structure using parameters such as field separators, record definitions, and field mappings. It then produces the corresponding XML representation.
The exact parameters depend on the file layout and the SAP PI/PO release.
4. Message Mapping and Integration Processing
Once the message is available in XML form, the integration flow can perform further transformations.
Message Mapping may be needed to rename elements, rearrange fields, combine values, apply business rules, or transform the source structure into the target data type.
Basic format conversion and business transformation are related but different tasks. FCC can handle suitable file-structure conversion, while more complex logic may require message mapping or additional processing.
5. Delivery to the Target System
The receiver adapter delivers the transformed message to the destination. Depending on the interface, the output may be an XML document, a text file, or another supported payload format.
Monitoring and validation help confirm that the message has been processed successfully and that the destination receives the expected content.
Important FCC Parameters in SAP PI/PO
Correct configuration is essential for reliable file content conversion. Parameter names and availability may differ by adapter and SAP release, so use the documentation for the actual environment when configuring a production interface.
Field Separator
The field separator identifies the character that separates fields in a delimited text file.
For example, consider this record:
1001, John Smith,5000
If commas separate the fields, the intended values are an employee ID, an employee name, and a salary.
A pipe-delimited record such as 1001|John Smith|5000 requires a different separator configuration.
A common error occurs when the configured delimiter does not match the actual file format.
End Separator or Record Separator
The record separator identifies how records end or how the file’s records are separated. Many text files use line breaks, but the exact representation can vary between systems and operating environments.
Incorrect record-separator settings can cause multiple records to be combined or a record to be parsed incorrectly.
Recordset Structure
The recordset structure defines how records are organized and how often particular record types may occur.
Simple files may contain repeated records of one type. More complex files can include headers, detail records, and trailers.
For example, a transaction file might contain a header with the batch identifier, multiple transaction records, and a trailer with the total number of records. The conversion configuration must reflect the actual layout rather than assume every line has the same meaning.
Document Name and Related Structure Settings
Depending on the scenario, the configuration may include a document name and other settings needed to generate the expected XML structure.
These values should be consistent with the message types and data structures defined for the interface.
Character Encoding
Character encoding determines how text characters are represented in the file. UTF-8 is common, but the source and destination may use other encodings.
An encoding mismatch can cause names, symbols, or special characters to appear incorrectly even when the delimiter configuration is correct.
Always test files containing non-ASCII characters if the business data includes them.
How to Configure File Content Conversion in SAP PI/PO
The exact configuration depends on whether the file is being received or sent, the adapter type, the file layout, and the SAP PI/PO version. The following workflow provides a practical starting point.
Step 1: Analyze the Source and Target Formats
Before creating integration objects, obtain representative source files and confirm the expected destination structure.
Document the field order, delimiter, record boundaries, character encoding, mandatory fields, and any header or trailer records.
Also identify whether the source file is encrypted. If it is PGP-encrypted, the standard FCC process cannot parse the encrypted payload directly.
Step 2: Define the Data Types in ESR
In the Enterprise Services Repository (ESR), create the data types and message types required by the integration scenario.
For an incoming CSV file, the XML data type should represent the fields and repeating records that the integration flow needs to process.
For an outgoing file, define the XML structure that can be converted into the destination’s required text layout.
Step 3: Configure the Sender Communication Channel
For an inbound flat-file scenario, configure the sender File or FTP Adapter according to the source system’s transport and file-processing requirements.
Select the appropriate message protocol and configure File Content Conversion where supported and suitable for the scenario.
Enter the required conversion parameters and ensure they match the actual file structure.
Step 4: Configure Message Mapping Where Required
Create a message mapping when the source and target structures differ or when business transformation logic is necessary.
For example, the source may contain a complete text line while the target requires separate XML elements for an employee ID, name, and amount.
A mapping can extract the required values and populate the corresponding target fields. If a custom user-defined function is used, handle delimiters, empty fields, unexpected field counts, and invalid input carefully.
Step 5: Configure the Receiver Channel
For an outgoing flat-file scenario, configure the receiver adapter and its conversion settings so that the generated file matches the destination’s expected layout.
Validate the output structure, field order, record boundaries, encoding, and file naming rules.
Step 6: Test and Activate the Integration
Test the configuration using representative sample files before processing production data.
Check the generated XML or flat-file output against the expected structure. Include both valid records and realistic edge cases, such as empty fields, special characters, missing values, and unexpected line endings.
Activate the required integration objects and use the relevant monitoring tools to investigate any failures.
File Content Conversion with PGP Encryption and Decryption
Some integrations require both file conversion and secure data exchange. PGP, commonly used to refer to OpenPGP-based encryption, can protect file contents so that only the intended recipient with the appropriate private key can decrypt them.
In a typical public-key encryption workflow, the sender encrypts the data using the recipient’s public key. The recipient uses the corresponding private key to decrypt it.
Encryption and file content conversion serve different purposes:
- File content conversion changes the representation or structure of the payload.
- PGP encryption protects the payload from unauthorized reading.
- PGP decryption makes the protected payload available for subsequent processing.
- Digital signature verification, when used, helps verify the origin and integrity of a signed message.
A file may require both operations, but they must occur in the correct order.
Why Standard FCC Cannot Directly Parse a PGP-Encrypted File
A PGP-encrypted file contains encrypted data rather than the original readable CSV or text records. The FCC parser cannot interpret those records until the payload has been decrypted.
Trying to run ordinary flat-file conversion against encrypted content can lead to processing failures.
The general solution is to place the decryption step before the component that parses the flat file. For outgoing files, convert the XML to the required flat-file format before encrypting the resulting payload.
The actual adapter modules and configuration must be verified against the SAP PI/PO version, installed components, and specific interface design.
Inbound Scenario: PGP Decryption Followed by Flat-File Conversion
Consider a supplier that sends an encrypted CSV file to an organization. The SAP integration flow must decrypt the file, interpret its fields, and map the information into the required XML structure.
A typical processing sequence is:
- The sender adapter receives or picks up the encrypted file.
- The configured PGP decryption component decrypts the payload using the appropriate private key and associated configuration.
- The decrypted flat-file content is parsed or transformed into the required XML-compatible structure.
- Message Mapping applies any required field extraction and business transformations.
- The integration flow routes the resulting message to the destination system.
The important requirement is that decryption occurs before the flat-file content is parsed.
Configure the Sender Module Sequence Carefully
In some SAP PI/PO implementations, adapter modules such as Localejbs/PGPDecryption and AF_Modules/MessageTransformBean are used for PGP decryption and message transformation.
The specific module sequence and parameters depend on the implementation. Do not copy a module list into a different environment without checking module availability, required configuration, and SAP documentation for that release.
The standard channel processing components must also be retained in the appropriate order for the configured scenario.
Create the Required Mapping
After the payload has been converted into a suitable XML representation, create the message mapping needed to populate the target data type.
If each source line is represented as a string, a user-defined function may be used to split it into fields. However, splitting a CSV line at every comma is not reliable for all CSV files: a quoted field can contain a comma as part of its value.
For robust processing, use a parser that follows the actual file format or define a strict input specification that excludes unsupported CSV constructs. Validate the number of fields and handle malformed records explicitly.
Outbound Scenario: XML-to-Flat-File Conversion Followed by PGP Encryption
The reverse scenario occurs when SAP generates XML data, but the recipient requires an encrypted CSV or text file.
For example, an organization may need to send payment instructions to an external service provider. The receiver expects a specific text layout and will only accept a PGP-encrypted file.
A typical processing sequence is:
- The SAP integration flow produces the target XML message.
- The required transformation converts the XML data into the recipient’s flat-file format.
- The resulting file content is encrypted using the recipient’s public key.
- The receiver adapter delivers the encrypted file through the configured transport.
- The recipient decrypts the file using the corresponding private key.
In some SAP PI/PO implementations, modules such as Localejbs/AF_Modules/StrictXml2PlainBean and Localejbs/PGPEncryption may be used for XML-to-plain-text conversion and encryption.
These names are implementation-specific. Verify that the modules are installed and appropriate for the relevant SAP release before using them.
Validate the Outgoing File Before Encryption
Before encrypting the payload, confirm that the plain-text file has the correct field order, delimiter, character encoding, line endings, and any required header or trailer records.
Encryption can protect a file, but it cannot correct an incorrectly generated file structure.
Also confirm that the recipient’s public key is valid and that the recipient can decrypt a test file successfully.
Common File Content Conversion Problems and Solutions
Troubleshooting is easier when the team distinguishes between file-format problems, transformation problems, and encryption problems.
Incorrect Delimiter Configuration
Symptom: Fields appear merged, shifted, or missing in the generated XML.
Possible cause: The configured field separator does not match the source file.
Solution: Inspect the raw input file, confirm the actual delimiter, and test the conversion using a small representative sample. Check whether quoted fields or embedded delimiters require a more capable parser.
Incorrect Record Structure
Symptom: The generated XML contains unexpected elements or does not represent the source records correctly.
Possible cause: The recordset configuration does not match the source file, or the file contains multiple record types that have not been accounted for.
Solution: Document the source layout, configure the relevant record definitions, and test headers, details, and trailers separately where applicable.
PGP Decryption Failure
Symptom: The message fails during the decryption stage, potentially with an error indicating that the file is not a valid PGP message.
Possible causes: The payload is not a valid encrypted PGP message, the wrong key is configured, the file has been altered or truncated, or the encryption format is incompatible with the installed module.
Solution: Verify the original file, confirm the appropriate private key and configuration, check that the payload has not been corrupted, and review the relevant SAP error logs. SAP documents a specific knowledge-base issue involving PGP decryption errors with File Content Conversion; the exact error context should be checked before applying a fix.
XML-to-Text Conversion Produces Invalid Output
Symptom: The destination receives a file, but its fields or records do not match the expected layout.
Possible cause: The XML structure is not compatible with the configured conversion, or the mapping has produced unexpected elements or values.
Solution: Compare the XML input with the expected structure, inspect the conversion parameters, and validate the plain-text output before encryption or delivery.
Character Encoding Problems
Symptom: Names, special symbols, or non-English characters appear corrupted.
Possible cause: The source and target use incompatible encodings, or the conversion process interprets the file using an incorrect character set.
Solution: Confirm the encoding of the source file and the destination requirements. Test representative special characters and use compatible encoding settings throughout the integration flow.
Missing or Empty Fields
Symptom: Some records contain missing values or the mapping produces incomplete XML.
Possible cause: The source file contains empty fields, unexpected separators, or fewer values than the mapping expects.
Solution: Define how empty values should be handled, validate field counts, and test incomplete records. Do not silently substitute values when doing so could change the business meaning of the data.
Security Best Practices for PGP-Enabled File Conversion
When a file contains financial, employee, customer, or other confidential information, security must be considered throughout the integration process.
Protect private keys. Private keys and their passphrases should be accessible only to authorized components and administrators. Do not store secrets in plain-text configuration files or expose them in logs.
Use the recipient’s correct public key. Confirm the key’s identity, validity, and suitability before encrypting sensitive data. Establish a controlled process for key rotation and expiration.
Verify digital signatures where required. Encryption and digital signatures are different functions. If the interface requires proof of origin or integrity, configure signature verification and define how failures will be handled.
Avoid logging sensitive payloads. Monitoring should provide enough information to diagnose failures without unnecessarily exposing decrypted business data.
Restrict access to temporary files. Decrypted payloads and intermediate files should be protected, retained only as required, and removed according to the organization’s security and retention policies.
Test recovery and failure handling. Define what happens when decryption, validation, conversion, or delivery fails. Prevent duplicate processing and ensure that failed messages can be investigated without weakening security controls.
Best Practices for Reliable File Content Conversion
A reliable FCC implementation should be designed for maintainability as well as successful conversion.
- Document the source and target file formats before configuration.
- Use representative sample files, including edge cases.
- Keep conversion rules aligned with the agreed interface specification.
- Separate simple format conversion from complex business mapping.
- Validate field counts, mandatory values, and record boundaries.
- Test encryption and decryption independently from conversion where practical.
- Monitor message failures and retain useful diagnostic information without exposing sensitive content.
- Document module sequences and key dependencies.
- Retest the interface after SAP upgrades, module changes, or changes to the file layout.
- Maintain clear ownership for certificate and key management.
For high-volume interfaces, measure processing time and resource usage under realistic workloads. Large files, complex mappings, and repeated processing can affect system performance, so performance testing should reflect expected production volumes.
Conclusion
File content conversion is a practical capability for integrating applications that exchange data in different file formats. In SAP PI/PO, FCC can simplify supported flat-file-to-XML and XML-to-flat-file transformations, while message mapping handles additional structural or business requirements.
When PGP encryption is involved, processing order becomes critical. Decrypt incoming encrypted files before parsing their contents, and convert outgoing data to the required flat-file structure before encryption.
Successful implementations combine accurate conversion parameters, suitable message mapping, verified cryptographic configuration, representative testing, and secure error handling. By documenting the file format, validating each processing stage, and following SAP-version-specific guidance, teams can build integrations that are easier to troubleshoot, maintain, and operate reliably.
Frequently Asked Questions
A: File Content Conversion is a File Adapter capability in SAP PI/PO that converts supported flat-file structures into XML and suitable XML structures into text files. It uses configured file-layout parameters and does not replace message mapping when complex business transformations are required.
A: No. The encrypted payload must first be decrypted before the underlying flat-file content can be parsed. In a PGP-enabled inbound scenario, configure the appropriate decryption step before the conversion or parsing step.
A: For inbound encrypted files, the usual order is decryption followed by parsing or conversion and then any required message mapping. For outbound files, transform the XML into the required flat-file structure before encrypting it for the recipient.
A: FCC is useful when the main requirement is to convert a supported flat-file layout into XML or produce a compatible flat file from XML. Message mapping is appropriate when fields must be rearranged, values transformed, structures changed, or business rules applied.
A: Start by identifying the stage where the message fails. Inspect the source file, conversion settings, generated XML, mapping results, and relevant adapter logs. For PGP-related failures, separately validate the encrypted payload, key configuration, and decryption process.
A: No. File content conversion changes the payload format; it does not encrypt the information. Sensitive data may require PGP encryption, secure transport, access controls, key management, and appropriate monitoring and retention policies.