Portal
Portal / Nodes / Universal Item Iteration / Samples

Universal Item Iteration: Sample Configurations

Real working examples for common scenarios.

← Back to Overview

Sample 1: Sequential Email Sending

Send personalized emails to customers one at a time. No parallelization, simple configuration.

Configuration: 
{
  "itemsIterationEnabled": true,
  "itemsIterationPropertyName": "customers",
  "recipients": "@{input:item|email}",
  "subject": "Hello @{input:item|name}",
  "body": "Order #@{input:item|order_id}"
}
Input (customers array): 
[
  {
    "email": "alice@example.com",
    "name": "Alice",
    "order_id": "ORD001"
  },
  {
    "email": "bob@example.com",
    "name": "Bob",
    "order_id": "ORD002"
  }
]
Timeline: Email 1 (1s) → Email 2 (1s) = 2 seconds total
When to use: Small lists, order matters, or low-volume operations

Sample 2: Parallel API Calls (100 concurrent)

Fetch user data from API for 100 user IDs in parallel batches of 10.

Configuration: 
{
  "itemsIterationEnabled": true,
  "itemsIterationPropertyName": "user_ids",
  "url": "https://api.example.com/users/@{input:item|id}",
  "method": "GET",
  "batchSize": 10,
  "parallelExecution": true,
  "batchWaitTimeMs": 0
}
Input (user_ids array): 
[
  { "id": 123 },
  { "id": 124 },
  { "id": 125 },
  ...
  { "id": 222 }
]
// Total: 100 items
Performance: 10 concurrent requests × 10 API calls each = 1 second per batch × 10 batches = ~10 seconds total (instead of 100 seconds sequential)
Speedup: 10× faster than sequential

Sample 3: Batch Database Insert with Rate Limiting

Insert 5000 records in batches of 500 with 100ms wait between batches.

Configuration: 
{
  "itemsIterationEnabled": true,
  "itemsIterationPropertyName": "records",
  "batchSize": 500,
  "parallelExecution": false,
  "batchWaitTimeMs": 100,
  "aggregateResults": true
}
Batch Breakdown: 
Batch 1: Items 1-500 (insert)
Wait: 100ms
Batch 2: Items 501-1000 (insert)
Wait: 100ms
Batch 3: Items 1001-1500 (insert)
...
Batch 10: Items 4501-5000 (insert)

Total time: ~5 seconds
(assuming 1s per batch insert)
Why rate limiting? Prevents database connection pool exhaustion and respects rate limits.
Aggregation: All results collected into single array for downstream processing

Sample 4: Error Handling and Retries

Retry failed items up to 3 times, then continue with next items.

Configuration: 
{
  "itemsIterationEnabled": true,
  "itemsIterationPropertyName": "api_calls",
  "url": "@{input:item|endpoint}",
  "method": "POST",
  "retryFailedItems": 3,
  "breakOnFirstError": false,
  "timeoutPerIteration": 5000
}
Execution Flow: 
Item 1: Success ✓
Item 2: Attempt 1 → Fail
        Attempt 2 → Fail
        Attempt 3 → Fail
        Attempt 4 (final) → Success ✓
Item 3: Success ✓
Item 4: Attempt 1 → Timeout
        Retry (max 3) → Success ✓
Retry backoff: Exponential backoff between retries (100ms, 200ms, 400ms)
Total attempts per item: 1 initial + 3 retries = 4 total attempts

Sample 5: Filtering and Sorting Before Iteration

Filter for high-priority items and sort by priority before processing.

Configuration: 
{
  "itemsIterationEnabled": true,
  "itemsIterationPropertyName": "tasks",
  "filterExpression": "@{input:item|priority} >= 7",
  "sortByExpression": "@{input:item|priority}",
  "reverseOrder": true,
  "recipients": "@{input:item|assignee}"
}
Input & Output: 
// Input (5 tasks)
[{priority: 5}, {priority: 9},
 {priority: 3}, {priority: 8},
 {priority: 10}]

// After filter (>= 7)
[{priority: 9}, {priority: 8},
 {priority: 10}]

// After sort + reverse
[{priority: 10}, {priority: 9},
 {priority: 8}]

// Process in this order
Filter impact: Only 3 of 5 items processed
Sort order: Highest priority first (descending)

Sample 6: Large Dataset with Limits

Process up to 10,000 items from a dataset of 50,000+ items.

Configuration: 
{
  "itemsIterationEnabled": true,
  "itemsIterationPropertyName": "items",
  "maxAllowedCount": 10000,
  "minAllowedCount": 100,
  "batchSize": 100,
  "parallelExecution": true
}
Safety Limits: 
Input: 50,000 items

maxAllowedCount: 10000
├─ Process first 10,000
└─ Skip remaining 40,000

minAllowedCount: 100
├─ If < 100 items: Error
└─ If >= 100 items: Proceed

Result:
10,000 iterations in batches
of 100 (100 batches total)
Why these limits? maxAllowedCount prevents runaway processing; minAllowedCount catches data quality issues
Use case: Scheduled jobs that might receive unexpected data volumes

Sample 7: Nested Property Access

Access deeply nested properties using pipe notation.

Configuration: 
{
  "itemsIterationEnabled": true,
  "itemsIterationPropertyName": "orders",
  "customer_email": "@{input:item|customer|contact|email}",
  "shipping_zip": "@{input:item|shipping|address|postal_code}",
  "first_item_sku": "@{input:item|items|0|sku}"
}
Input Structure: 
{
  "customer": {
    "contact": {
      "email": "alice@example.com"
    }
  },
  "shipping": {
    "address": {
      "postal_code": "94102"
    }
  },
  "items": [
    { "sku": "PROD001" },
    { "sku": "PROD002" }
  ]
}
Pipe syntax: Each pipe goes one level deeper
Array access: Use |0 for first element, |1 for second, etc.

Performance Comparison Summary

Scenario Configuration Time
100 emails (sequential) No batching 100 seconds
100 emails (batch 50) batchSize: 50, parallel: false 100 seconds
100 emails (parallel) batchSize: 50, parallel: true 2 seconds
5000 DB inserts batchSize: 500, parallel: false ~25 seconds
← Back to Overview | Getting Started →