Why the built-in conversion stops
Content conversion has to read the payload. It splits the file into records, splits records into fields, and names the result — none of which is possible on a payload that is still encrypted.
That is the whole reason PGP interfaces need adapter modules where an unencrypted interface needs only channel settings. The conversion does not stop working; it stops being able to start.
So the design question becomes an ordering question: get the payload into a readable state, convert it, and — in the other direction — convert it first and encrypt afterwards.
Sender channel: decrypt, then convert
For a file arriving encrypted that needs to become XML, the module chain runs:
Localejbs/PGPDecryption— decrypts the incoming message. This has to be first; nothing downstream can read the payload until it has run.AF_Modules/MessageTransformBean— performs the flat-file to XML conversion using the recordset and separator settings, exactly as the built-in conversion would.CallSAPAdapter— the default module, which stays last.
The conversion parameters themselves do not change. The same Recordset Structure, separators and field names from the parameter reference apply — they are simply applied by a module rather than by the adapter directly.
Receiver channel: convert, then encrypt
Outbound, the order inverts:
Localejbs/AF_Modules/StrictXml2PlainBean— converts the XML into the flat format the receiver expects.Localejbs/PGPEncryption— encrypts the resulting message.
Encrypting before converting would leave nothing readable to convert, so the sequence is not a preference. It is the same constraint as the sender side, seen from the other end.
The UDF that does the splitting
The receiver direction usually needs an advanced user-defined function in the message mapping as well. The plain-text module produces the record as a single string, so something has to split that line at its delimiters and build the target structure from the parts.
This is a common place to lose time. The module chain looks correct, the file is produced, and the fields are wrong — because the splitting logic lives in the mapping, not in the channel, and it is easy to spend the afternoon reading the channel configuration instead.
It also means a PGP receiver interface has two places where delimiters are declared: the channel and the UDF. When the delimiter changes, both have to change. They drift.
Why the order is not negotiable
Adapter modules execute in the order they are listed, and each one sees what the previous one produced. Get the order wrong and the failure is rarely a clean error — a module simply runs against a payload that is not what it expects, and either does nothing or produces something malformed.
This is the same class of problem as Content Converter versus Content Modifier: configuration that is individually correct, arranged so that it cannot work. Nothing is broken, so nothing is reported.
Checking it worked
Test with a genuinely encrypted file from the sending system and the matching key in the keystore. A file you encrypt yourself will not expose the key and alias problems that cause most of these failures, which means a passing test tells you less than it appears to.
- Confirm the decryption step produced a readable payload before checking anything about the conversion.
- Compare the decrypted bytes against an unencrypted file from the same source — they should be identical. If they are not, the problem is upstream of conversion entirely.
- Check that the XML produced by the sender chain matches what the mapping expects, since mapping failures here look like conversion failures.
- On the receiver side, decrypt the produced file and inspect it — do not assume the module chain worked because no error was raised.
If something is failing and you are not sure which stage it is, the symptom-by-symptom breakdown in the error guide is a faster route than re-reading the module list.