Boomi Dynamic Process Properties: Real-World Examples

If you’ve been working with Boomi for any length of time, you’ve probably encountered scenarios where you need to store temporary values, track counters, or pass data between different parts of your integration process. That’s exactly where Dynamic Process Properties (DPPs) come into play.

In this comprehensive guide, I’ll walk you through what Dynamic Process Properties are, when to use them, and most importantly—real-world examples that you can implement in your own integrations today.

What Are Dynamic Process Properties?
DPPs vs Process Property Components
How to Create and Use Dynamic Process Properties
Real-World Use Cases
Working with DPPs in Groovy Scripts
Persistence: When and Why
Common Pitfalls and Best Practices
Advanced Patterns

What Are Dynamic Process Properties?

Dynamic Process Properties are name-value pairs that you can create on-the-fly within a Boomi process to store arbitrary information. Think of them as runtime variables that exist throughout the execution of your integration.

Unlike Process Property Components (which are pre-defined and reusable), DPPs are:

Created dynamically during process execution
Scoped to the process where they’re set
Stored as strings (requiring type conversion for numbers/dates)
Optionally persistent across executions

Key Characteristics:

Case-sensitive: API_TOKEN is different from api_token
String-based: All values are stored as characters
Unlimited quantity: You can set as many as you need
Process-level scope: Available throughout the entire process (unlike Document Properties which are document-scoped)

DPPs vs Process Property Components

Before we dive deeper, let’s clarify when to use each:

Feature	Dynamic Process Properties	Process Property Components
Setup	Created on-the-fly	Pre-defined in Process Library
Reusability	Single process	Multiple processes
Data Types	String only	Multiple types (String, Number, Date, etc.)
Maintenance	Must remember property names	Visible in component dialog
Best For	Runtime temporary values	Configuration settings
Persistence	Optional	Always available

Boomi’s Recommendation: If you’re starting a new project, use Process Property Components when possible—they’re more maintainable. However, DPPs are perfect for temporary runtime values that you don’t want cluttering your Process Library.

How to Create and Use Dynamic Process Properties

Creating a DPP Using Set Properties Shape

Here’s the basic workflow:

Step 1: Add a Set Properties Shape Drag the Set Properties shape onto your process canvas.

Step 2: Configure the Dynamic Process Property

Click the + button
Select Dynamic Process Property from the dropdown
Give it a descriptive name (use a naming convention like UPPER_CASE_WITH_UNDERSCORES)
Choose whether to persist the value

Step 3: Set the Value Configure the parameter source:

Static: Hard-coded value
Dynamic: From document data or another property
Connector Operation: From a connection response

Retrieving a DPP

You can retrieve DPPs in several places:

In a Map Function: Use the function getProcessProperty("PROPERTY_NAME")
In a Decision Shape: Reference it as {1:PROPERTY_NAME}
In a Groovy Script: Use ExecutionUtil.getDynamicProcessProperty("PROPERTY_NAME")
In Another Set Properties Shape: Select it from the property list

Real-World Use Cases

Let’s explore practical scenarios where DPPs shine.

Use Case 1: API Rate Limiting with Request Counter

Scenario: You’re calling an external API that allows only 100 requests per minute. You need to track how many calls you’ve made and pause if you exceed the limit.

Solution: Use a persisted DPP to maintain a counter.

Implementation:

Process Flow:
1. Retrieve persisted DPP: API_CALL_COUNT
2. Increment counter in Groovy script
3. Decision: If count > 100, wait 60 seconds and reset
4. Make API call
5. Persist updated counter

Groovy Script:

groovy

import com.boomi.execution.ExecutionUtil;

// Retrieve current count
String countStr = ExecutionUtil.getDynamicProcessProperty("API_CALL_COUNT");
int currentCount = (countStr != null && !countStr.isEmpty()) ? Integer.parseInt(countStr) : 0;

// Increment
currentCount++;

// Store back with persistence
ExecutionUtil.setDynamicProcessProperty("API_CALL_COUNT", String.valueOf(currentCount), true);

// Log for monitoring
logger.info("API call count: " + currentCount);

Why DPP Instead of Database?

Faster access (in-memory)
No external dependencies
Simpler implementation
Perfect for short-term tracking

Use Case 2: Session Token Management

Scenario: Your integration needs to authenticate with an API once, get a session token, and reuse it for subsequent calls within the same execution.

Solution: Store the token in a DPP and reference it across multiple connector operations.

Implementation:

Process Flow:
1. Call Authentication API
2. Extract token from response
3. Store in DPP: SESSION_TOKEN
4. Branch to multiple API calls
5. Each branch retrieves SESSION_TOKEN from DPP
6. Use token in Authorization header

Set Properties Configuration:

Property Name: SESSION_TOKEN
Parameter Type: Dynamic
Source: From authentication response profile
XPath: /response/auth_token
Persist: NO (only needed during this execution)

Using in HTTP Connector: In the HTTP Client connector’s Operation Options:

Header: Authorization
Value: Bearer {1:SESSION_TOKEN}

Benefits:

Avoid redundant authentication calls
Maintain security (token not hard-coded)
Clean separation of concerns
Easy to debug and monitor

Use Case 3: Incremental Data Load with Last Run Timestamp

Scenario: You need to pull only new/updated records from a database since the last successful run.

Solution: Persist a timestamp DPP that tracks the last successful execution.

Implementation:

Process Flow:
1. Retrieve LAST_RUN_TIMESTAMP (persisted DPP)
2. If empty, set to 30 days ago (first run)
3. Query database: WHERE modified_date > LAST_RUN_TIMESTAMP
4. Process records
5. On success: Update LAST_RUN_TIMESTAMP to current time
6. Persist the new timestamp

Groovy Script for Timestamp:

groovy

import com.boomi.execution.ExecutionUtil;
import java.text.SimpleDateFormat;
import java.util.Date;

// Retrieve last run timestamp
String lastRun = ExecutionUtil.getDynamicProcessProperty("LAST_RUN_TIMESTAMP");

// If null or empty, default to 30 days ago
if (lastRun == null || lastRun.isEmpty()) {
    long thirtyDaysAgo = System.currentTimeMillis() - (30L * 24 * 60 * 60 * 1000);
    lastRun = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date(thirtyDaysAgo));
    logger.info("First run detected, using default: " + lastRun);
}

// Store for use in database query
ExecutionUtil.setDynamicProcessProperty("QUERY_START_DATE", lastRun, false);

// After successful processing, update last run timestamp
String currentTimestamp = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
ExecutionUtil.setDynamicProcessProperty("LAST_RUN_TIMESTAMP", currentTimestamp, true);
logger.info("Updated LAST_RUN_TIMESTAMP to: " + currentTimestamp);

Database Connector Query:

sql

SELECT * FROM customers 
WHERE modified_date > '{1:QUERY_START_DATE}' 
ORDER BY modified_date ASC

Critical Consideration: Only persist the timestamp AFTER successful processing. If the process fails, you want to retry from the same point.

Use Case 4: Dynamic Routing Based on Cumulative Values

Scenario: You’re processing order records and need to route high-value batches to a priority queue, but only when cumulative order value exceeds $10,000.

Solution: Track cumulative value in a DPP and make routing decisions dynamically.

Implementation:

Process Flow:
1. Start with order batch
2. For each order:
   a. Retrieve CUMULATIVE_VALUE DPP
   b. Add current order value
   c. Update CUMULATIVE_VALUE
3. Decision Shape: If CUMULATIVE_VALUE > 10000
   - Route to Priority Queue
4. Else: Route to Standard Queue
5. At end: Reset CUMULATIVE_VALUE to 0

Groovy Script in Data Process Shape:

groovy

import com.boomi.execution.ExecutionUtil;
import java.io.InputStream;
import java.util.Properties;

for (int i = 0; i < dataContext.getDataCount(); i++) {
    InputStream is = dataContext.getStream(i);
    Properties props = dataContext.getProperties(i);
    
    // Get order value from document
    String orderValueStr = props.getProperty("document.dynamic.userdefined.ORDER_VALUE");
    double orderValue = Double.parseDouble(orderValueStr);
    
    // Retrieve cumulative value
    String cumulativeStr = ExecutionUtil.getDynamicProcessProperty("CUMULATIVE_VALUE");
    double cumulative = (cumulativeStr != null) ? Double.parseDouble(cumulativeStr) : 0.0;
    
    // Add current order
    cumulative += orderValue;
    
    // Update DPP
    ExecutionUtil.setDynamicProcessProperty("CUMULATIVE_VALUE", String.valueOf(cumulative), false);
    
    // Set document property for routing decision
    props.setProperty("document.dynamic.userdefined.BATCH_TOTAL", String.valueOf(cumulative));
    
    dataContext.storeStream(is, props);
}

Decision Shape Configuration:

If: {1:CUMULATIVE_VALUE} > 10000
Then: Priority_Queue_Branch
Else: Standard_Queue_Branch

Use Case 5: Error Tracking and Alert Threshold

Scenario: You want to send an alert only if more than 5 errors occur in a single execution.

Solution: Track error count in a DPP and trigger alert conditionally.

Implementation:

Process Flow:
1. Try-Catch around main processing
2. In Catch path:
   a. Retrieve ERROR_COUNT DPP
   b. Increment by 1
   c. Store updated count
   d. Check if ERROR_COUNT >= 5
   e. If yes: Send alert email
3. Continue with next record

Groovy Script in Catch Branch:

groovy

import com.boomi.execution.ExecutionUtil;

// Get current error count
String errorCountStr = ExecutionUtil.getDynamicProcessProperty("ERROR_COUNT");
int errorCount = (errorCountStr != null) ? Integer.parseInt(errorCountStr) : 0;

// Increment
errorCount++;

// Store
ExecutionUtil.setDynamicProcessProperty("ERROR_COUNT", String.valueOf(errorCount), false);

// Set flag if threshold exceeded
if (errorCount >= 5) {
    ExecutionUtil.setDynamicProcessProperty("ALERT_REQUIRED", "true", false);
}

logger.warning("Error count: " + errorCount);

Decision Before Email Notification:

If: {1:ALERT_REQUIRED} = true
Then: Send_Alert_Email
Else: Skip

Use Case 6: Pagination for Large API Responses

Scenario: An API returns paginated results (100 records per page). You need to loop through all pages.

Solution: Track current page number in a DPP and loop until no more pages.

Implementation:

Process Flow:
1. Initialize: PAGE_NUMBER = 1, HAS_MORE_PAGES = true
2. Loop Start
3. Call API with page parameter: ?page={1:PAGE_NUMBER}
4. Process response records
5. Check response for "has_next_page" field
6. If true:
   - Increment PAGE_NUMBER
   - Loop back to step 2
7. If false: Exit loop

Groovy Script to Manage Pagination:

groovy

import com.boomi.execution.ExecutionUtil;
import java.io.InputStream;
import java.util.Properties;
import groovy.json.JsonSlurper;

for (int i = 0; i < dataContext.getDataCount(); i++) {
    InputStream is = dataContext.getStream(i);
    Properties props = dataContext.getProperties(i);
    
    // Parse JSON response
    def jsonSlurper = new JsonSlurper();
    def response = jsonSlurper.parse(is);
    
    // Check if there are more pages
    boolean hasMorePages = response.pagination?.has_next_page ?: false;
    
    if (hasMorePages) {
        // Get current page and increment
        String pageNumStr = ExecutionUtil.getDynamicProcessProperty("PAGE_NUMBER");
        int pageNum = (pageNumStr != null) ? Integer.parseInt(pageNumStr) : 1;
        pageNum++;
        
        // Store incremented page number
        ExecutionUtil.setDynamicProcessProperty("PAGE_NUMBER", String.valueOf(pageNum), false);
        ExecutionUtil.setDynamicProcessProperty("HAS_MORE_PAGES", "true", false);
        
        logger.info("More pages available. Next page: " + pageNum);
    } else {
        ExecutionUtil.setDynamicProcessProperty("HAS_MORE_PAGES", "false", false);
        logger.info("Last page reached.");
    }
    
    dataContext.storeStream(is, props);
}

HTTP Connector Configuration:

URL: https://api.example.com/records?page={1:PAGE_NUMBER}&limit=100

Decision Shape to Control Loop:

If: {1:HAS_MORE_PAGES} = true
Then: Loop_Back_to_API_Call
Else: End_Process

Use Case 7: Conditional Processing Based on Environment

Scenario: You want different behavior in DEV vs PROD environments without changing the process.

Solution: Set an ENVIRONMENT DPP at process start and use it throughout.

Implementation:

Process Flow:
1. Set DPP: ENVIRONMENT = "DEV" or "PROD" (from Process Property Component)
2. Multiple decision points check ENVIRONMENT value
3. Route to appropriate endpoints/logic

Set Properties Configuration:

Property Name: ENVIRONMENT
Parameter Type: Process Property
Source: Environment_Config.CURRENT_ENV

Use in Decision Shapes:

Decision 1 - API Endpoint:
If: {1:ENVIRONMENT} = PROD
Then: Use https://api.prod.example.com
Else: Use https://api.dev.example.com

Decision 2 - Email Notifications:
If: {1:ENVIRONMENT} = PROD
Then: Send to real recipients
Else: Send to test@example.com

Decision 3 - Batch Size:
If: {1:ENVIRONMENT} = PROD
Then: Process 1000 records
Else: Process 10 records (for testing)

Working with DPPs in Groovy Scripts

Groovy scripts give you the most flexibility when working with DPPs. Here’s your complete reference:

Import Required Class

groovy

import com.boomi.execution.ExecutionUtil;

Set a Dynamic Process Property

groovy

// Without persistence
ExecutionUtil.setDynamicProcessProperty("PROPERTY_NAME", "value", false);

// With persistence (survives across executions)
ExecutionUtil.setDynamicProcessProperty("PROPERTY_NAME", "value", true);

Retrieve a Dynamic Process Property

groovy

String value = ExecutionUtil.getDynamicProcessProperty("PROPERTY_NAME");

// Always check for null
if (value != null && !value.isEmpty()) {
    // Use the value
} else {
    // Handle missing property
}

Type Conversion Examples

String to Integer:

groovy

String countStr = ExecutionUtil.getDynamicProcessProperty("RECORD_COUNT");
int count = (countStr != null) ? Integer.parseInt(countStr) : 0;

String to Double:

groovy

String amountStr = ExecutionUtil.getDynamicProcessProperty("TOTAL_AMOUNT");
double amount = (amountStr != null) ? Double.parseDouble(amountStr) : 0.0;

String to Date:

groovy

import java.text.SimpleDateFormat;
import java.util.Date;

String dateStr = ExecutionUtil.getDynamicProcessProperty("LAST_RUN_DATE");
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date lastRun = (dateStr != null) ? sdf.parse(dateStr) : new Date();

Date to String:

groovy

import java.text.SimpleDateFormat;
import java.util.Date;

String timestamp = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
ExecutionUtil.setDynamicProcessProperty("CURRENT_TIMESTAMP", timestamp, false);

Complete Example: Counter with Reset Logic

groovy

import com.boomi.execution.ExecutionUtil;
import java.util.logging.Logger;

Logger logger = Logger.getLogger("DPP_Counter");

// Retrieve current count
String countStr = ExecutionUtil.getDynamicProcessProperty("PROCESS_COUNTER");
int count = 0;

if (countStr != null && !countStr.isEmpty()) {
    try {
        count = Integer.parseInt(countStr);
    } catch (NumberFormatException e) {
        logger.warning("Invalid counter value, resetting to 0");
        count = 0;
    }
}

// Increment
count++;

// Check if reset threshold reached
if (count >= 1000) {
    logger.info("Counter reached 1000, resetting to 0");
    count = 0;
}

// Store updated count with persistence
ExecutionUtil.setDynamicProcessProperty("PROCESS_COUNTER", String.valueOf(count), true);
ExecutionUtil.setDynamicProcessProperty("LAST_COUNT_UPDATE", 
    new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new java.util.Date()), 
    true);

logger.info("Process counter updated to: " + count);

Persistence: When and Why

Persistence allows a DPP’s value to be retained across separate process executions. This is powerful but must be used carefully.

When to Use Persistence

✅ Good Use Cases:

Tracking last successful run timestamp
Maintaining sequence numbers
Storing OAuth refresh tokens
Keeping long-running counters
Checkpoint markers for batch processing

❌ Avoid Persistence For:

Session-specific data
Values that change every execution
Temporary calculation results
Large data payloads (memory concerns)

How Persistence Works

When you enable persistence (checkbox in Set Properties or true in Groovy):

Value is immediately written to disk in the Atom’s execution folder
On next process execution, value is automatically loaded into memory
Value persists until explicitly changed or process is updated

File Location (for debugging):

<atom_installation_directory>/execution/<process_ID>.properties

Important Persistence Gotchas

1. Concurrent Executions: If your process allows simultaneous executions, the last-write-wins. This can cause race conditions.

❌ Problem:

Execution 1: Reads counter = 10, writes 11
Execution 2: Reads counter = 10, writes 11
Result: Counter is 11 instead of 12

✅ Solution: Disable concurrent executions for processes using persisted counters, or use external storage (database) for accuracy.

2. Persistence Happens Immediately: The value is persisted the moment the Set Properties shape executes—not at process completion.

❌ Problem:

1. Persist LAST_RUN_TIMESTAMP = current time
2. Process fails halfway through
3. Next run starts from new timestamp, missing failed records

✅ Solution: Persist critical values only AFTER confirming success.

Best Practice Pattern:

Process Flow:
1. Retrieve LAST_RUN_TIMESTAMP
2. Store in temporary DPP: CURRENT_RUN_TIMESTAMP
3. Query data using LAST_RUN_TIMESTAMP
4. Process all records
5. Try-Catch wrapping steps 1-4
6. In Success path: Persist CURRENT_RUN_TIMESTAMP as new LAST_RUN_TIMESTAMP
7. In Catch path: Log error, do NOT update timestamp

3. Parent-Child Process Scope: Persisted DPPs in a parent process are NOT automatically available to child processes.

✅ Solution: Explicitly pass the value using a Call Process shape’s process properties parameter, or re-set the DPP in the child process.

Common Pitfalls and Best Practices

Pitfall 1: Case Sensitivity Typos

❌ Problem:

Set Properties: API_TOKEN
Retrieval: api_token  // Returns null!

✅ Solution: Establish a naming convention and stick to it.

Recommended Convention:

UPPER_CASE_WITH_UNDERSCORES for all DPPs
Example: API_TOKEN, LAST_RUN_TIMESTAMP, ERROR_COUNT

Pitfall 2: Forgetting Type Conversion

❌ Problem:

groovy

String count = ExecutionUtil.getDynamicProcessProperty("RECORD_COUNT");
// count is "5" (String)
int newCount = count + 1;  // Results in "51" not 6!

✅ Solution: Always convert explicitly.

groovy

int count = Integer.parseInt(ExecutionUtil.getDynamicProcessProperty("RECORD_COUNT"));
int newCount = count + 1;  // Correctly results in 6

Pitfall 3: Not Checking for Null

❌ Problem:

groovy

String value = ExecutionUtil.getDynamicProcessProperty("SOME_VALUE");
int num = Integer.parseInt(value);  // NullPointerException if property doesn't exist!

✅ Solution: Always validate.

groovy

String value = ExecutionUtil.getDynamicProcessProperty("SOME_VALUE");
int num = (value != null && !value.isEmpty()) ? Integer.parseInt(value) : 0;

Pitfall 4: Using DPPs for Large Data

❌ Problem: Storing large XML/JSON payloads in DPPs.

Why It’s Bad:

Stored in memory (performance impact)
Stored as String (encoding issues)
Hard to debug (not visible in process logs)

✅ Solution: Use Document Properties or temporary file storage for large payloads.

Pitfall 5: Overusing DPPs Instead of Process Property Components

❌ Problem: Creating dozens of DPPs for configuration values.

✅ Solution: Use Process Property Components for anything that:

Is reused across processes
Represents configuration (not runtime data)
Needs to be easily changed without code
Should be visible to non-developers

Best Practices Checklist

✅ Naming:

Use descriptive, uppercase names with underscores
Include units in name if applicable (TIMEOUT_SECONDS, not just TIMEOUT)
Prefix by category if many DPPs (API_TOKEN, API_RETRY_COUNT, API_BASE_URL)

✅ Documentation:

Add comments in Groovy scripts explaining each DPP’s purpose
Document in process notes which DPPs are used
List persisted DPPs separately in documentation

✅ Error Handling:

groovy

try {
    String value = ExecutionUtil.getDynamicProcessProperty("COUNTER");
    int counter = Integer.parseInt(value);
    // Use counter
} catch (NumberFormatException e) {
    logger.warning("Invalid counter format, resetting to default");
    ExecutionUtil.setDynamicProcessProperty("COUNTER", "0", true);
}

✅ Logging:

groovy

logger.info("Setting DPP 'SESSION_TOKEN' for API authentication");
ExecutionUtil.setDynamicProcessProperty("SESSION_TOKEN", token, false);
logger.fine("SESSION_TOKEN set successfully: " + token.substring(0, 10) + "...");

✅ Cleanup: Reset DPPs that don’t need to persist beyond current execution:

groovy

// At end of process
ExecutionUtil.setDynamicProcessProperty("TEMP_CALCULATION", "", false);
ExecutionUtil.setDynamicProcessProperty("SESSION_TOKEN", "", false);

Advanced Patterns

Pattern 1: State Machine Using DPPs

Manage complex workflows with state tracking:

groovy

// State definitions
final String STATE_INIT = "INITIALIZED";
final String STATE_AUTHENTICATED = "AUTHENTICATED";
final String STATE_PROCESSING = "PROCESSING";
final String STATE_COMPLETE = "COMPLETE";
final String STATE_ERROR = "ERROR";

// Get current state
String currentState = ExecutionUtil.getDynamicProcessProperty("WORKFLOW_STATE");
if (currentState == null) {
    currentState = STATE_INIT;
}

// State transitions
switch (currentState) {
    case STATE_INIT:
        // Perform authentication
        // ...
        ExecutionUtil.setDynamicProcessProperty("WORKFLOW_STATE", STATE_AUTHENTICATED, false);
        break;
    
    case STATE_AUTHENTICATED:
        // Start processing
        // ...
        ExecutionUtil.setDynamicProcessProperty("WORKFLOW_STATE", STATE_PROCESSING, false);
        break;
    
    case STATE_PROCESSING:
        // Process records
        // ...
        ExecutionUtil.setDynamicProcessProperty("WORKFLOW_STATE", STATE_COMPLETE, false);
        break;
}

Pattern 2: Distributed Counter Across Branches

When processing documents across multiple branches and need a cumulative count:

groovy

import com.boomi.execution.ExecutionUtil;
import java.util.concurrent.atomic.AtomicInteger;

// This approach has limitations in parallel execution
// Use with caution or implement locking mechanism

synchronized (this.getClass()) {
    String countStr = ExecutionUtil.getDynamicProcessProperty("GLOBAL_COUNTER");
    int count = (countStr != null) ? Integer.parseInt(countStr) : 0;
    count++;
    ExecutionUtil.setDynamicProcessProperty("GLOBAL_COUNTER", String.valueOf(count), false);
}

Note: For truly parallel-safe counters, consider using external storage or the Boomi Cache.

Pattern 3: Multi-Value DPP Using Delimited Strings

Store multiple values in a single DPP:

groovy

// Adding to list
String currentList = ExecutionUtil.getDynamicProcessProperty("PROCESSED_IDS");
if (currentList == null) {
    currentList = "";
}

String newId = "12345";
if (!currentList.isEmpty()) {
    currentList += ",";
}
currentList += newId;

ExecutionUtil.setDynamicProcessProperty("PROCESSED_IDS", currentList, false);

// Later, checking if ID was already processed
String processedIds = ExecutionUtil.getDynamicProcessProperty("PROCESSED_IDS");
if (processedIds != null && processedIds.contains("12345")) {
    logger.info("ID already processed, skipping");
}

Pattern 4: JSON Storage in DPPs

For complex structured data:

groovy

import groovy.json.JsonBuilder;
import groovy.json.JsonSlurper;

// Storing JSON
def data = [
    timestamp: new Date().format("yyyy-MM-dd HH:mm:ss"),
    record_count: 150,
    status: "success"
]

String jsonData = new JsonBuilder(data).toString();
ExecutionUtil.setDynamicProcessProperty("EXECUTION_METADATA", jsonData, true);

// Retrieving JSON
String jsonStr = ExecutionUtil.getDynamicProcessProperty("EXECUTION_METADATA");
if (jsonStr != null) {
    def metadata = new JsonSlurper().parseText(jsonStr);
    logger.info("Last execution: " + metadata.timestamp);
    logger.info("Records processed: " + metadata.record_count);
}

Conclusion

Dynamic Process Properties are a versatile tool in your Boomi integration toolkit. They excel at:

Runtime state management
Temporary value storage
Cross-shape communication
Conditional logic implementation
Persistent tracking (when used carefully)

Remember the Golden Rules:

Use meaningful, consistent naming conventions
Always validate and convert types
Be cautious with persistence
Document your DPPs
Consider Process Property Components for configuration
Clean up temporary properties
Test thoroughly, especially with persistence

When to Reach for DPPs:

You need to track something during process execution
The value is temporary or changes frequently
You’re building dynamic, data-driven routing logic
You need a quick solution without creating reusable components

When NOT to Use DPPs:

Large data payloads
Cross-process communication (use sub-processes with parameters instead)
Configuration that rarely changes (use Process Property Components)
Strict concurrent execution scenarios (race conditions)

By mastering Dynamic Process Properties, you’ll write cleaner, more maintainable Boomi integrations that are easier to debug and more flexible to changing requirements.

Additional Resources

Have you used Dynamic Process Properties in creative ways? Share your use cases in the comments below!

Found this helpful? Subscribe to Integration Insider for more Boomi tips, tutorials, and best practices delivered to your inbox.

Table of Contents

What Are Dynamic Process Properties?

DPPs vs Process Property Components

How to Create and Use Dynamic Process Properties

Creating a DPP Using Set Properties Shape

Retrieving a DPP

Real-World Use Cases

Use Case 1: API Rate Limiting with Request Counter

Use Case 2: Session Token Management

Use Case 3: Incremental Data Load with Last Run Timestamp

Use Case 4: Dynamic Routing Based on Cumulative Values

Use Case 5: Error Tracking and Alert Threshold

Use Case 6: Pagination for Large API Responses

Use Case 7: Conditional Processing Based on Environment

Working with DPPs in Groovy Scripts

Import Required Class

Set a Dynamic Process Property

Retrieve a Dynamic Process Property

Type Conversion Examples

Complete Example: Counter with Reset Logic

Persistence: When and Why

When to Use Persistence

How Persistence Works

Important Persistence Gotchas

Common Pitfalls and Best Practices

Pitfall 1: Case Sensitivity Typos

Pitfall 2: Forgetting Type Conversion

Pitfall 3: Not Checking for Null

Pitfall 4: Using DPPs for Large Data

Pitfall 5: Overusing DPPs Instead of Process Property Components

Best Practices Checklist

Advanced Patterns

Pattern 1: State Machine Using DPPs

Pattern 2: Distributed Counter Across Branches

Pattern 3: Multi-Value DPP Using Delimited Strings

Pattern 4: JSON Storage in DPPs

Conclusion

Additional Resources

Leave a Reply Cancel reply