Data Chopping and Aggregation Strategy in eZintegrations

Enterprise integrations often deal with hierarchical business data containing multiple levels of related information.

Examples include:

• Orders containing Shipments and Items
• Invoices containing Invoice Lines
• Claims containing Claim Entries
• Payments containing Transaction Records

A common implementation pattern is to start processing from the top-level business object and progressively break the data into smaller parts.

While this works functionally, it creates dependency on the parent hierarchy throughout the workflow.

In eZintegrations, the recommended strategy is to process data from the lowest meaningful transactional level and progressively build higher-level business summaries.

---

Current Processing Pattern

In many integrationintegrations, implementations,processing atypically commonfollows approachthis is:pattern:

Parent Business Object
   ↓
SingleBreak Lineinto to Multi Line
   ↓
ChildSub-Level Records
   ↓
DataBreak Aggregationinto Detailed Records
   ↓
Prepare Final Business Summary

Although multiplethe Singledata Lineis toeventually Multisplit Lineinto Operationsgranular arerecords, used,the thisworkflow is still adriven top-down processing model because processing begins fromby the parent hierarchy.

In

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

---

Order Management Example

Common IncorrectProcessing ApproachFlow

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)Shipments
   ↓
Single Line to Multi Line (Items)Items
   ↓
DataFinal AggregationOrder Summary

In this approach:model:

• Processing starts from Orders
• The hierarchyData is progressively broken progressively downward
• AggregationFinal happensbusiness summaries are prepared only afterat traversalthe end

EvenThis thoughcreates data chopping is performed, the architecture still dependsdependency on the parentcomplete structure.Order hierarchy during processing.

---

Recommended ApproachProcessing in eZintegrations

The recommended strategy is to process from the lowest-level transactional entities first.

Example:

Flow

Items
   ↓
Item-Level Processing
   ↓
DataBuild AggregationShipment Details
   ↓
Packages
   ↓
Shipments
   ↓Build Final Order Summary

Here:

• Items become the sourceprimary ofprocessing truthunit
• AggregationBusiness movescalculations upwardoriginate progressivelyfrom transactional records
• ParentHigher-level summaries are progressively derived from finalized childitem recordsdata

---

Functional Perspective

From a business perspective, the recommended approach focuses on processing smaller transactional units independently instead of depending on the complete parent business object throughout the workflow.

This creates a cleaner and more manageable processing model for hierarchical business transactions.

CorrectTechnical ArchitecturePerspective

Pattern

From a technical architecture perspective, the strategy follows a lowest-level-first processing model.

Data Aggregation Flow

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

ThisThe architectureparent ensures:

business

object
• Betterbecomes scalability
a
• Independentderived summary instead of the primary processing
• Parallel execution
• Better fault isolation
• Cleaner orchestration

---

controller.

Key Principle

Data Chopping Alone Is Not Enough

UsingBreaking multiplehierarchical Singlebusiness Linedata tointo Multismaller Linerecords Operationsis doesonly notone automaticallypart createof athe scalableprocessing architecture.strategy.

The more important factoraspect is:is how the business flow is designed after the data is split.

Where Aggregation Starts

If aggregation logicprocessing still depends heavily on the parent business hierarchy, the architectureworkflow remainsbecomes top-down.tightly coupled and difficult to manage as transaction volume increases.

The correctrecommended modelapproach is:is to:

Process Lowest-Levelthe Entitieslowest Firstmeaningful ↓transactional Aggregaterecords Upwardfirst
↓
Perform Buildbusiness Parentprocessing Summaries

at