Technical blog

Aggregator component in SAP Cloud Integration - Correlation function

created by Sonnet 4.0

Jiri Fridrich

Sep 8, 2025

Integration

The Aggregator component is a very powerful and versatile component, which can be used for many different things. Today we will focus on the Correlation feature.

Working with data file interfaces, it is common that data arrives in a raw and flat format, often containing multiple records that belong logically together. In SAP Cloud Integration (CPI), the Aggregator step helps us collect and group these messages so that they can be processed as a single unit.

In this blog post, we will look at scenario where we receive General Ledger (GL) records that must be paired into Credit and Debit entries, based on a common GL ID. We’ll use the Correlation function of the Aggregator to achieve this grouping. The Aggregator may be overlooked as the first go-to option and we may be thinking about Groovy scripts or XSLT transformation, but Aggregator is the smoothest way to do this.

The Input Data

Our source system delivers data in a flat, delimited structure:

US01|01 01 180000039|US01|0011040120|0011040120||01012025|01012025|01012025|D|USD|100.00|USD|100.00|||||||||||||||||||||||||||||||||||
US01|01 01 180000039|US01|0011040100|0011040100||01012025|01012025|01012025|C|USD|100.00|USD|100.00|||||||||||||||||||||||||||||||||||
US01|02 01 180000080|US01|0011040120|0011040120||02012025|02012025|02012025|D|USD|150.00|USD|150.00|||||||||||||||||||||||||||||||||||
US01|02 01 180000080|US01|0011040100|0011040100||02012025|02012025|02012025|C|USD|150.00|USD|150.00

These are four GL records, which actually form two logical pairs:

Debit & Credit for GL ID 01 01 180000039
Debit & Credit for GL ID 02 01 180000080

The field at position 2 is the GL Id and field at position 10 indicates whether it is Debit (D) or Credit (C).

Converting Flat Data to XML

Since the Aggregator works with XML, our first task is to transform the flat file into XML. This is done using CSV to XML Converter component.

Here we have to provide:

XSD schema – to define the structure of the incoming message.

Path to target element - this is the path in xsd where the GL record is actually stored
Field separator - a pipe in our case

After the message passes this step, we get one XML with four records like this.

Now we have to split this single XML into separate messages using Splitter to be able to use the Aggregator component, as it works with individual XMLs and performs the aggregation / correlation on them. We are splitting again on the /root/item xpath.
You can see the sequence on the screenshot above: Converter -> Splitter -> Aggregator.

Grouping with the Aggregator

Now comes the interesting part: Aggregator with Correlation.
In the Aggregator step, we configure the Correlation Expression to use the GL_Id field.

This ensures that all records sharing the same GL_Id are collected into a single group. Once the group is complete (for example, after receiving both Debit and Credit), the Aggregator releases the combined message.

As a result, instead of four separate records, we get two XML documents grouped on GL_Id value. In the terms of SAP, we got a paired GL posting record with Debit and Credit side.

Mapping to S/4HANA

Of course, SAP S/4HANA expects different field names and a slightly different XML structure for posting GL documents.
Here we typically use an XSLT mapping or a Message Mapping step to transform the aggregator’s output into the required S/4HANA format.
These steps are highly dependent on the target API (e.g. Journal Entry API), but conceptually it’s just restructuring fields.

End-to-End Flow

Summarizing the integration steps:

Receive Flat File (pipe-delimited records).
Convert to XML using XSD + converter.
Split per individual records
Aggregate Records by GL_Id with Correlation.
Transform to S/4HANA Format via XSLT mapping.
Send to S/4HANA using the standard OData/HTTPS adapter.

The Correlation feature of the Aggregator in SAP CPI is very helpful. It allows us to logically group related records—even if they arrive as separate messages—so that downstream systems like S/4HANA receive them as consistent and balanced documents.