Content Modifier in SAP CPI: Headers, Properties & Body

What is the content modifier in SAP CPI?

If you have spent even a week building integration flows in SAP Cloud Integration, you have already met the content modifier. It sits in almost every inflow, quietly doing the small jobs that make the rest of the flow work. It sets a value that a router needs later, adds a header that the receiver expects, or rewrites the whole payload before it goes out.

Yet a lot of beginners treat it like a black box. They copy a configuration from a tutorial, it works once, and then it breaks the moment the payload changes. This guide explains what the content modifier really does, how the three tabs differ, and how to set headers, properties and body values without guessing.

The content modifier is a message transformer step in SAP Cloud Integration (often called SAP CPI), which runs as part of SAP Integration Suite on SAP BTP. It lets you change the message that is moving through your iFlow. You can create or delete headers, create or delete exchange properties, and replace the message body.

Every message in an iFlow is carried inside an object called an exchange. The exchange holds the headers, the properties and the body. The content modifier is your hand on all three. It does not call another system and it does not map fields from one structure to another. For that you would use a mapping step. Think of it as a small, fast editor that works on the message in place.

Quick facts about the content modifier

Item	Detail
Where to find it	Palette > Transformation > Content Modifier
Tabs available	Message Header, Exchange Property, Message Body
Actions on headers and properties	Create or delete
Body options	One body value, written as a constant or an expression
Default expression language	Camel Simple Expression Language, written as $[...]
Works on	The current exchange only, nothing is stored after the message ends
Typical use	Preparing values for routers, mappings, adapters and error handling
Needs scripting?	No, most jobs can be done through the configuration screen

Headers, properties and body: the basic difference

Before you open the step, you need to be clear about what each of the three parts is for. Most mistakes in real projects come from putting a value in the wrong place.

Part	What it is	Does it reach the receiver?
Header	Small pieces of metadata that travel with the message, such as an order ID, a content type or an authorization value.	It can. Receiver adapters such as HTTP or SOAP may send headers along, depending on what is allowed.
Property	A working value that lives only inside the iFlow for the duration of one message run.	No. Properties stay inside the integration engine and are never sent out.
Body	The actual payload, such as the XML or JSON document being processed.	Yes. The body is what the receiver gets.

A good rule of thumb: if the receiving system needs the value, think header or body. If only your own iFlow needs it, make it a property. Properties are safer because they cannot leak into an outbound call by accident.

How to add a content modifier to an iFlow

The steps are the same whether you are building a new flow or editing an old one.

Open your integration flow in the designer and switch to edit mode. In the palette on the left, open Transformation and pick Content Modifier. Click inside the iFlow pool, and place the step on the sequence flow where you want it to run. Connect it with the steps before and after it. Select the step and use the properties area below to fill in the Message Header, Exchange Property and Message Body tabs.

Position matters more than people think. The step only sees what exists at that point in the flow. If you try to read an XPath value after a mapping has already changed the structure, the path will return nothing. Put the content modifier before the mapping if you need the original payload, and after it if you need the new one.

How to set headers in the content modifier

Open the Message Header tab and click Add. A new row appears with a few fields. Here is what each one means.

Field	What to enter
Action	Create adds or overwrites a header. Delete removes one.
Name	The header name. Names are case sensitive in most adapters, so keep the spelling consistent.
Type	Where the value comes from, for example Constant, XPath, Header, Property or Expression.

Table 1: Example of a fixed value

If the receiver always needs the same text, such as a system name, set Type to Constant and type the text in the Value field. No data type is needed here.

Careful with header names

Some header names are reserved or filtered. The HTTP-based adapters, for example, do not forward every header, and the Allowed Headers setting in the runtime configuration of the iFlow decides which ones pass through. If a header you set never shows up at the receiver, check that setting first. Also avoid names that start with Camel, since they are used by the engine internally.

How to set exchange properties

The Exchange Property tab looks almost the same as the header tab, and that is on purpose. You add a row, choose an action, name it, pick a type and give a value. The difference is where the value ends up. A property is invisible to the outside world, which makes it ideal for values that you want to keep for later steps.

When to use a property

Storing a value before a splitter or a mapping changes the payload, so you can use it again afterward. Holding a flag that a router uses to choose a path. Keeping the original message ID or a customer key for logging and error handling. Saving a value from one branch of a multicast so another step can use it.

Example: keeping the customer ID safe

Suppose the incoming payload has a Customer ID, but the next step is a mapping that drops it. Before the mapping, add a content modifier. Create a property named customer Id, use XPath, and point it at /Order/Customer/ID. After the mapping, you can still read it with ${property.CustomerId}, for instance to build a log message or to call a lookup.

Headers or properties: which one should you pick?

Question	Header	Property
Can the receiver see it?	Possibly	Never
Good for routing logic?	Works, but not ideal	Yes, the preferred choice
Risk of leaking data	Higher	Very low
Survives across steps?	Yes, until removed or replaced	Yes, for the whole message run
How to read it	${header.name}	${property.name}

Source types you can use for values

The Type column is where the content modifier becomes powerful. Instead of typing a fixed value, you can pull one from many places.

Type	What it does	Sample value
Constant	Uses text exactly as typed.	ORDER_SYSTEM
XPath	Reads a value from the XML body.	/Order/Header/OrderID
Header	Copies the value of another header.	SAP_MessageProcessingLogID
Property	Copies an existing property.	customerId
Expression	Builds a value with Simple Expression Language.	${header.OrderNumber}-${date:now:yyyyMMdd}
Local Variable	Reads a variable that lives within the current iFlow.	lastRunTime
Global Variable	Reads a variable shared across iFlows in the same tenant.	sharedCounter
Number Range	Takes the next number from a defined range.	OrderNumberRange
External Parameter	Reads a configurable parameter set at deployment.	{{ReceiverURL}}

External parameters deserve special mention. They let you change a value, such as a URL or a company code, without touching the iFlow design. You write the name inside double curly braces, and then give the real value when you configure the flow. It keeps the same iFlow usable across development, test and production.

How to set the message body

The Message Body tab is simpler. It has one editor, and whatever you type there replaces the current body. Be careful with this point. Anything that was in the body before is gone once this step runs. If you still need that content, store it in a property or a header first.

You can write a plain constant, such as a fixed XML snippet, or you can mix in expressions. For example, a body like this builds a small notification message:

<Notification><OrderId>${header.OrderNumber}</OrderId><Customer>${property.customerId}</Customer></Notification>

When the step runs, the expressions are replaced by the actual values. This is a handy way to build an email text, a small request for a lookup call, or a response message for a sender that waits for a reply.

Things to watch in the body

Special characters such as an ampersand or a less-than sign need to be escaped in XML.
Reading the original body with ${in.body} lets you wrap or reuse the existing content.
Large payloads are better handled with a mapping or a script, not typed into the body field.
If the body field is left empty, the existing body stays untouched, so only fill it when you really want a change.

A full example, step by step

Let us put everything together with a small scenario. A web shop sends an order in XML. You want to call a backend service that needs the order number in a header, and you want to keep the customer ID for logging.

Add a content modifier right after the sender. In the Message Header tab, create OrderNumber with XPath /Order/Header/OrderID and data type java.lang.String. In the Exchange Property tab, create customerId with XPath /Order/Customer/ID. In the Exchange Property tab, add a second property named processedOn with Type Expression and Value ${date:now:yyyy-MM-dd}. In the Message Body tab, enter a short request that uses ${header.OrderNumber}. Run the iFlow with tracing turned on and check each step in the message processing log.

This takes about five minutes to configure, and it covers the three most common jobs the content modifier does in real projects.

One more thing worth doing at the end: open the message processing log and look at the headers and properties after the step. Seeing the real values, instead of trusting what you typed, is the fastest way to catch a typo in a name or a path that points to the wrong node. Most content modifier problems are found within a minute of reading the trace.

Common mistakes and how to avoid them

Mistake	How to fix it
XPath returns an empty value	Check the namespace. If the XML uses one, define it in the iFlow namespace mapping or use a path that ignores it.
Header not reaching the receiver	Review the Allowed Headers setting and the adapter settings.
Body disappears after the step	Store the old body in a property first, or leave the body tab empty.
Wrong data type on XPath	Set java.lang.String unless you truly need another type.
Value works in test but not in production	Use external parameters so each environment has its own setting.
Using a property name that already exists	Properties get overwritten without warning, so use clear and unique names.

Best practices that save time later

Give headers and properties clear names. A name like customerId tells the next developer more than prop1 ever will.
Use one content modifier for one purpose where possible. A step that sets five unrelated things gets hard to read.
Add a Default value when the source may be empty, so the flow does not fail on a null.
Delete headers you no longer need before the receiver call, especially anything sensitive.
Test with trace enabled during development. The log shows the headers and properties after every step.
Use external parameters for anything that changes between systems.

Frequently asked questions

What is the content modifier used for in SAP CPI?

It is used to create or delete headers and exchange properties and to change the message body inside an iFlow. It prepares data for later steps such as routers, mappings and receiver adapters.

What is the difference between a header and a property in SAP CPI?

A header travels with the message and can be passed to a receiver, depending on the adapter. A property lives only inside the iFlow and is never sent out. Use properties for internal values.

Can the content modifier read values from the payload?

Yes. For XML payloads, choose the XPath type and enter the path. For JSON, convert the payload to XML first, or use a script step, since XPath works on XML.

Does the content modifier overwrite the existing body?

Yes, when you enter something in the Message Body tab, it replaces the current body. If the tab is empty, the body is left as it is.

How do I read a header or property later in the flow?

Use the Simple Expression Language. Write ${header.name} for a header and ${property.name} for a property.

Can I use a content modifier more than once in the same iFlow?

Yes. You can place as many as you need. Each one runs at its own position and sees the message as it exists at that point.

Why is my XPath value empty?

The most common reason is a namespace in the XML that the path does not account for. The second is that the step runs after a mapping that changed the structure. Check the trace to see the body at that point.

Conclusion

The content modifier is one of the smallest steps in SAP CPI, but it does a huge share of the daily work. Once you know that headers are for metadata, properties are for internal values and the body is the payload itself, most of the confusion goes away. Keep names clean, use expressions where they help, and always test with tracing on.

If you want to go further than a single step, a structured SAP CPI with BTP training course can help you practice real scenarios, from simple modifiers to complete end-to-end integrations. Hands-on practice with SAP CPI, along with proper BTP training, turns these small concepts into skills you can use on a live project.

About the author

This article has been written by the TechBrainz SAP CPI team. The team works with SAP Cloud Integration and SAP Integration Suite every day, building and supporting real integration scenarios and training learners who are new to SAP BTP. Their aim is to explain integration topics in plain language, with examples taken from actual project work.

What is the content modifier in SAP CPI and how do you set headers, properties and body values in an i Flow?