Batches are great.
But once you start batching, you immediately meet two new questions:
- How do we ship the batch efficiently to a connector?
- How do we route different items (or batches) differently without writing custom code?
August’s work tackles both with two powerful building blocks:
- Batch Output Connector Processor
- Switch-Case Processor (multi-conditions)
This is where pipelines start feeling less like “ETL flows” and more like programmable integration systems – without becoming an unmaintainable codebase.
Batch Output Connector: shipping pallets, not single parcels
If QQS + Buffer Entry is the “warehouse staging area”, the Batch Output Connector is the “truck”.
Instead of calling a connector once per object, it can:
- take a list of objects
- package them into a connector request
- send them in one call
- handle a response that contains success/error per item
A typical config looks like:
{
"id": "batch_out",
"type": "Qilin.BatchOutputConnector",
"config": {
"outputConnectorId": "connector-guid",
"domainName": "Offer",
"objectTypePath": "$.FlowObjectContents.entry.objectType",
"objectIdsPath": "$.FlowObjectContents.entry.objectIds",
"objectBodiesPath": "$.FlowObjectContents.entry.objectData"
}
}
When paired with buffering, this gives you classic enterprise integration behavior:
- fewer HTTP calls
- better throughput control
- reduced connector overhead
- easier handling of platform quotas and rate limits
Switch-Case Processor: routing logic that scales
The next problem: not every object should go to the same place.
You might need to route by:
- marketplace
- storefront
- country
- product category
- pricing strategy
- stock availability
- compliance rules
In the old world, routing becomes a pile of nested if-statements.
In Qilin, the Switch-Case Processor gives you a structured approach:
- each outgoing connection can define a condition (Filter Predicate)
- Qilin activates the first matching case
- a default route can catch everything else
A simplified mental model:
- if case A matches → follow path A
- else if case B matches → follow path B
- else → follow default
This is the “switch statement” you already know – adapted to pipeline routing.
Why multi-conditions matter
Multi-conditions are the difference between:
- “we can build a demo”
- and “we can build policies”
Because real routing often looks like:
- If it’s a hazardous material AND destination is EU → route to compliance enrichment
- If it’s a luxury brand AND price is missing → stop and alert
- If it’s marketplace X AND stock < 5 → route to low-stock strategy
Switch-case lets you express this cleanly, reuse it, and review it.
For developers
- batching reduces connector chatter and failure surfaces
- switch-case reduces custom code and makes routing auditable
- both are pipeline-native, meaning you get tracking, logs, and consistent error behavior
For merchants, agencies, and investors
- Merchants: faster, more stable syncs—especially for high-volume catalog/offer updates
- Agencies: cleaner architectures and reusable routing templates across clients
- Investors: this is platform maturity that increases addressable use cases and lowers delivery cost
What’s next
In September, we’ll shift from routing and batching into a different kind of control:
time.
Scheduling is a core part of integration work, and Qilin is adding pipeline primitives for time-based triggering and notifications.
Commerce runs on decisions (and decisions run on data)
Batches make shipping efficient.
Switch-case makes shipping intelligent.
Qilin.Cloud is building both—so your integrations can grow in volume and complexity without growing in chaos.
0 Comments