Skip to main content

Data Chopping and Aggregation Strategy in eZintegrations

In many integration implementations, a common approach is:


Parent Object
   ↓
Single Line to Multi Line
   ↓
Child Records
   ↓
Data Aggregation

Although multiple Single Line to Multi Line Operations are used, this is still a top-down processing model because processing begins from the parent hierarchy.

In eZintegrations, the recommended approach is to process from the lowest-level transactional entities and aggregate upward.

Order Management Example

Common Incorrect Approach

In an Order Management use case, integrations usually receive payloads containing:

  • Orders
  • Shipments
  • Packages
  • Items

A common implementation pattern is:


Orders
   ↓
Single Line to Multi Line (Shipments)
   ↓
Single Line to Multi Line (Items)
   ↓
Data Aggregation

In this approach:

  • Processing starts from Orders
  • The hierarchy is broken progressively downward
  • Aggregation happens only after traversal

Even though data chopping is performed, the architecture still depends on the parent structure.

Recommended Approach in eZintegrations

Example:


Items
   ↓
Item-Level Processing
   ↓
Data Aggregation
   ↓
Packages
   ↓
Shipments
   ↓
Final Order Summary

Here:

  • Items become the source of truth
  • Aggregation moves upward progressively
  • Parent summaries are derived from finalized child records

Correct Architecture Pattern


Lowest-Level Records
   ↓
Independent Processing
   ↓
Data Aggregation
   ↓
Derived Parent Objects

This architecture ensures:

  • Better scalability
  • Independent processing
  • Parallel execution
  • Better fault isolation
  • Cleaner orchestration

Key Principle

Chopping Alone Is Not Enough

Using multiple Single Line to Multi Line Operations does not automatically create a scalable architecture.

The important factor is:


Where Aggregation Starts

If aggregation logic still depends on the parent hierarchy, the architecture remains top-down.

The correct model is:


Process Lowest-Level Entities First
            ↓
Aggregate Upward
            ↓
Build Parent Summaries
Conclusion

In eZintegrations, hierarchical data processing should not begin from parent-driven traversal.

Instead, integrations should:


Process Lowest-Level Records
            ↓
Perform Data Aggregation
            ↓
Build Parent Summaries

This strategy provides:

  • Better scalability
  • Improved parallel processing
  • Better fault tolerance
  • Cleaner architecture
  • Easier maintenance

Data chopping combined with lowest-level-first aggregation should be treated as the standard integration architecture pattern in eZintegrations.

Back to top