SAP Splitter Pattern
The Splitter pattern is the opposite of the Aggregator. Where the Aggregator combines many messages into one, the Splitter divides one large message into many smaller messages and processes each one independently. This is essential when a source system sends bulk data that SAP must receive as individual documents.
Think of the Splitter like a delivery truck arriving at an apartment building. The truck carries a hundred packages. You cannot deliver a truckload to every apartment simultaneously — you take each package off the truck and deliver it to the correct unit individually. The Splitter does exactly this for message payloads: it takes the truckload message and creates individual packages for downstream processing.
When to Use the Splitter
- A file or API response contains multiple records that SAP must post as separate documents
- A nightly batch file contains 1,000 invoices that must each become a separate SAP FI document
- An e-commerce order contains multiple line items that must be distributed to different SAP plants
- Processing one record at a time allows individual retry of failed records without reprocessing the entire batch
- Different records in a bulk message have different error handling requirements
Splitter Types in CPI
General Splitter
Splits an XML document into multiple messages based on an XPath expression. Every element matching the XPath becomes a separate message.
INPUT MESSAGE: <Invoices> <Invoice><ID>INV-001</ID><Amount>500</Amount></Invoice> <Invoice><ID>INV-002</ID><Amount>750</Amount></Invoice> <Invoice><ID>INV-003</ID><Amount>1200</Amount></Invoice> </Invoices> SPLITTER XPath: /Invoices/Invoice OUTPUT: Three separate messages: Message 1: <Invoice><ID>INV-001</ID><Amount>500</Amount></Invoice> Message 2: <Invoice><ID>INV-002</ID><Amount>750</Amount></Invoice> Message 3: <Invoice><ID>INV-003</ID><Amount>1200</Amount></Invoice>
IDoc Splitter
Designed specifically for IDoc bulk messages. SAP systems sometimes send multiple IDocs in a single transmission (called a bulk IDoc). The IDoc Splitter separates them into individual IDocs for processing.
CSV Splitter
Splits CSV (comma-separated value) files line by line. Each row becomes an individual message. Configure the line separator, field separator, and whether the first row is a header.
INPUT CSV: OrderID,Customer,Amount PO-001,CUST-A,5000 PO-002,CUST-B,3000 PO-003,CUST-C,7500 CSV SPLITTER (skip header row = true): Message 1: PO-001,CUST-A,5000 Message 2: PO-002,CUST-B,3000 Message 3: PO-003,CUST-C,7500
Iterating Splitter
Processes each split message sequentially — one at a time, in order. The next message only starts processing after the previous one completes. Use this when the order of posting to SAP matters (for example, when later records depend on earlier ones being posted first).
Parallel Splitter
Processes all split messages simultaneously in parallel. Much faster for large batches but requires that each message is completely independent. Do not use parallel splitting when record order matters or when SAP cannot handle concurrent posts to the same business object.
Error Handling with Splitter
When one split message fails, what happens to the others? CPI provides two approaches:
Stop on First Error
Processing stops when any individual message fails. Remaining messages are not processed. Use this when messages are interdependent and proceeding without a failed message would create data inconsistency.
Skip and Continue (Recommended for Batch)
Failed messages are logged and skipped. Processing continues with the remaining messages. After the batch completes, a summary shows how many succeeded and how many failed. Use this for independent records like daily invoice uploads where a single bad invoice should not block 999 good ones.
SKIP-AND-CONTINUE PATTERN:
Splitter creates 1,000 individual messages
↓
[Process Message 1] → SUCCESS → post to SAP
[Process Message 2] → SUCCESS → post to SAP
[Process Message 3] → FAIL → write to error Data Store, continue
[Process Message 4] → SUCCESS → post to SAP
...continuing to 1,000...
↓
[Gather results]
↓
[Send summary: 997 success, 3 failed]
[Send error detail for 3 failed messages]
Carrying Header Data Through the Split
When you split a message, each sub-message contains only its own slice of the original payload. But the original message often has header data (file date, source system, batch ID) that every sub-message needs. Store header data as exchange properties before splitting — properties are copied to every sub-message automatically.
BEFORE SPLITTER:
Content Modifier:
Property: BatchDate = /Batch/@date (XPath from original)
Property: SourceFile = ${header.CamelFileName}
Property: BatchID = ${date:now:yyyyMMddHHmmss}
AFTER SPLITTER (in each sub-message):
${property.BatchDate} → still available
${property.SourceFile} → still available
${property.BatchID} → still available
Use these in the receiver step to tag each individual SAP posting
with the source batch information for traceability.
Tracking Split Progress
CPI automatically sets properties on each split message:
CamelSplitIndex– Zero-based index of this message in the split (0 = first, 1 = second, etc.)CamelSplitSize– Total number of messages the split producedCamelSplitComplete– True on the last message in the split
Use CamelSplitIndex and CamelSplitSize in log entries to track which record out of how many is currently processing. Use CamelSplitComplete to trigger a summary step that only runs after all split messages are done.
Splitter Performance Considerations
Splitting 10,000 records creates 10,000 messages in CPI's processing queue. Each message has its own MPL entry in the monitor. The monitor can show 10,000 entries from a single batch run. Consider:
- Use the Parallel Splitter to process faster, but set a reasonable parallelism limit to avoid overwhelming the SAP receiver
- Configure the SAP receiver adapter with a proper connection timeout — large parallel batches can tie up connection pools
- For very large batches (over 10,000 records), consider a staged approach: split into smaller chunks of 100 records, process each chunk, and aggregate results