The short answer
Content Converter changes what the payload is. Content Modifier changes things about the payload — headers, properties, and small fragments of the body.
One reshapes the message. The other adjusts it. They are not alternatives to each other, and the confusion between them is mostly caused by the names being equally vague.
What Content Converter does
Content conversion turns a flat file into XML, or XML back into a flat file. AF_Modules/MessageTransformBean is the module that performs it, driven by the recordset structure and separator settings in the channel.
The input and output are structurally different things. A file that was lines of text becomes a document with elements; the receiver of that step cannot be the same code that read the original. That is the clearest way to tell the two apart in practice: if the payload before and after cannot be consumed by the same receiver, you are looking at a conversion.
The full configuration is covered in content conversion parameters.
What Content Modifier does
A Content Modifier sets or replaces values: adapter-specific message attributes, headers, properties, and short stretches of the message body. It is configuration rather than transformation — you are stating that a field should hold a particular value, not describing how to parse anything.
Typical uses are stamping a constant into a header the receiver requires, injecting a filename or timestamp into a property, or setting an adapter attribute that controls how the message is handled downstream.
The tell: the payload in and the payload out are recognisably the same document. Something about it changed; the thing itself did not.
Why order matters
Adapter modules run in the order they are listed. When an interface needs both, conversion comes first and modification after — because a modifier can only act on structure that already exists.
This is also where the module sequence for encrypted files comes from. PGP handling has to be ordered relative to the conversion step: decrypt before it, encrypt after it. That sequence is laid out in content conversion with PGP.
The silent failure
The reason this pair causes so much wasted time is that choosing wrongly usually produces no error at all. The channel starts, messages process, monitoring shows green, and the effect you configured simply never happens.
Nothing is broken, so nothing is reported. You are left reading configuration that looks correct — because it is correct, for a job that is not the one being done.
When something you configured has no visible effect, that is the shape of the problem to suspect first, before you start checking values for typos.
Choosing between them
- The payload changes shape — text becomes XML, XML becomes text. That is conversion, and the channel configuration is where it belongs.
- A header, property or attribute needs a value. That is a Content Modifier.
- A constant or dynamic value needs to land in a specific part of the body. Content Modifier, provided you are replacing a value rather than restructuring the document.
- Fields need renaming, values need mapping, records need joining. Neither — that is message mapping, which runs after the adapter has finished.
If you are still deciding whether conversion is the right tool at all, the content conversion overview covers what it does and, just as usefully, what it will not do.