Multicasts: Your intuition may lead you astray

In the world of SAP Process Orchestration (PO), you sent the message to a receiver and you were done. In SAP Cloud Integration, you often can and should continue the integration process. If you aren't prepared for the platform's unique behavior—especially the quirks of multicasts—your integration might be doing things you never intended.

Sequential Multicast

If you want to make multiple calls where each successive call happens only if the previous one succeeded, use a sequential multicast. Any error, and the flow stops.

The sequential multicast works like a save point in a video game.

Who says work isn't fun

For example:

Simple Multicast

0.       Sequential Multicast saves a message at a point in time

1.       Branch 1: Does a request reply to system A

2.       The snap-back: The message body, headers, and properties revert to what they were when you initiated the multicast

3.       Branch 2: Reaches out to partner B using the original data

A more real life example

To see how this can bite you in real life, here is a more realistic interface:

A CRM calls CI to fetch data from two systems. The combined results is then sent as a quote to a customer. System 1 checks item availability. System 2 checks the price. The catch: if nothing's available, system 1 throws an error and there's no point going any further in the process.

So you build an iFlow that looks like this:

Mock Quote process

In this flow a property: availableQuantity = 0 is initialized. A sequential multicast is performed. Branch 1 calls the WMS, availableQuantity property is updated. Branch 2 calls S4 with the material, and gets pricing. The gather step occurs and a transformation happens. A quote is sent to the customer,

Deploy it. Done.

Right???

Wrong

After branch 1 completes, availableQuantity resets to 0. Why? The short answer is shallow copies. I think of it as… restored to the savepoint.

So how do you fix it? First, worth noting — if you're just sending data to 2 receivers with no need to carry data across branches, this isn't really a problem. It only gets messy when you're trying to persist data between branches or continue a process with a gather after the calls.

Dirty Solutions

There are a few workarounds, but none of them are pretty.

1. Variables or datastores — technically viable, but you're putting data into cold storage for what is effectively a live, in-flight process. It works, it just feels wrong.

2. Avoiding multicasts altogether — some people store and restore the message body via a property or header instead. It sidesteps the problem, but the resulting flow gets long fast, and the intent isn't obvious to anyone reading it later. A multicast, love it or hate it, at least tells you what it's trying to do.

A Cleaner Alternative

cleanliness is godliness

The gather step controls what gets persisted and what doesn't — which means your choice of gather algorithm matters more than you'd expect.

Someone in the SAP community mapped out the different algorithms and their behaviors in detail — if you're hitting this issue, this thread is worth a read. It's saved me a lot of hair-pulling (Read the comments).

The short version: Plain Text Combine preserves properties, so that's what I use. I also give each branch a distinct property name and merge the results after the gather, rather than trying to update the same property across branches. This keeps sequential processing intact and lets the flow continue cleanly.

Parallel Multicasting

Parallel Multicasts make more sense intuitively—everything happens at once (Think clones not savepoints).

If only I had them in real life

In theory, parallel multicasts should be a performance boost, and a failed branch should let the rest continue. In practice, the disappearing headers and properties behavior is identical to sequential — same problem, same gather-based fix.

That said, parallel multicasts have a few unique challenges worth calling out:

Joining and errors — To continue processing after a parallel multicast you need a Join followed by a Gather. However, if any branch fails, the entire iFlow is treated as errored and processing stops. One workaround: call a separate flow via Process Direct and override the header status — this bypasses the behavior. SOAP faults can trigger the same all-or-nothing failure, so plan your error handling accordingly and test it explicitly.

Consider isolating the logic — Many of these issues can be avoided by moving the multicast logic into its own local process or a separate flow entirely. This gives you better logging, cleaner error isolation, and avoids some hard-to-debug abend errors.

IDocs especially benefit from this — With IDocs, calling a separate flow lets you set distinct application_id values or custom headers tied to each IDoc number. If everything runs in the same flow, you risk overwriting the IDoc number across branches — which creates real supportability headaches down the line.

Conclusion

Multicasts are one of those features that reward the developers who take the time to understand them — and quietly punish those who don't. Get the gather algorithm right, isolate your logic where it makes sense, and they become a genuinely powerful tool. Get it wrong, and you're chasing phantom property values at 4pm on a Friday. Solid usage makes flows more readable, which greatly enhances supportability.

Speaking of things that bite you when you least expect it — next up, we'll talk about governance in SAP CI: why the decisions you make early about naming conventions, error handling standards, and flow design pay dividends (or debts) for the entire life of your integration landscape.