Order approval automation fails during batch processing in order management

ERP Infor CloudSuite
, , , , , , , ,
1

Our automated order approval jobs are intermittently failing during batch processing in ICS 2022. The batch job scheduler runs every 15 minutes to process pending orders, but about 30% of runs end with timeout errors or incomplete status updates.

We’re processing roughly 500-800 orders per batch. The workflow status updates seem to get stuck, leaving orders in ‘PROCESSING’ state instead of moving to ‘APPROVED’ or ‘REJECTED’. When we manually trigger approval for these stuck orders, they process instantly.

Error from batch job log:


BatchJobException: Concurrent modification detected
Order ID: ORD-2025-4721
Status: PROCESSING (locked)

This is causing significant delays in our order fulfillment pipeline. The order data validation appears fine - no missing fields or invalid values. Has anyone dealt with batch job concurrency issues in order approval automation?

system 2

I’ll address all three aspects of your batch processing issue:

1. Batch Job Concurrency: Your 15-minute schedule with 18-22 minute execution times creates overlapping jobs that compete for the same order records. Implement a job lock mechanism:

if (isJobAlreadyRunning("OrderApprovalBatch")) {
    logger.warn("Previous batch still running, skipping");
    return;
}

Also increase your schedule interval to 20 minutes or implement a completion-based trigger instead of time-based. This prevents concurrent batch execution entirely.

2. Workflow Status Updates: Your status updates are failing because you’re validating and updating in separate transactions. Restructure to use atomic operations:

transaction.begin();
Order order = fetchOrderWithLock(orderId);
if (order.getStatus() == "PENDING") {
    validateAndApprove(order);
    order.setStatus("APPROVED");
    transaction.commit();
}

The key is fetching with a lock (SELECT FOR UPDATE) and committing immediately after status change. Don’t hold locks during validation - do validation first, then acquire lock only for the update.

3. Order Data Validation: Move validation outside the transaction boundary to avoid long-running locks:


// Pseudocode - Optimized batch processing flow:
1. Query all PENDING orders without locks
2. Perform validation checks on entire batch (approval rules, credit limits, inventory)
3. Create list of valid order IDs ready for approval
4. For each valid order (in chunks of 50):
   a. Begin transaction
   b. Fetch order with exclusive lock
   c. Recheck status is still PENDING (double-check pattern)
   d. Update status to APPROVED
   e. Commit transaction immediately
5. Log any orders that failed recheck for next batch cycle
// This minimizes lock hold time

Implement batch chunking with proper error handling:

  • Process 100 orders per chunk with commit between chunks
  • Add retry logic for deadlock exceptions (max 3 retries with exponential backoff)
  • Skip orders that are locked by other processes rather than failing entire batch
  • Maintain a processing timestamp to identify stuck orders for cleanup

For your stuck orders in PROCESSING state, create a cleanup job that runs hourly to reset orders stuck for more than 30 minutes. This handles edge cases where locks weren’t properly released due to job failures.

The reason manual approval works is single-record processing with immediate exclusive locks and no validation overhead. Your batch needs to mimic this pattern but at scale with proper concurrency controls.

This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

The ‘concurrent modification detected’ error suggests multiple batch jobs are trying to update the same orders simultaneously. Check your batch job scheduler configuration - you might have overlapping execution windows. If a batch takes longer than 15 minutes and the next one starts, you’ll get lock conflicts.

4

Good point Chris. I checked the execution logs and some batches are indeed taking 18-22 minutes when order volume is high. So we have overlap. But why would manual approval work instantly if the records are locked? Shouldn’t we see the same lock conflict?

5

Manual approvals use a different locking mechanism than batch processes. The UI grabs an exclusive lock immediately, while batch jobs use optimistic locking that can fail on commit. You need to implement retry logic in your batch job and add proper lock timeout handling. Also consider processing orders in smaller chunks rather than all 500-800 at once. Break it into batches of 100 with commit points between each chunk.

6

I had this exact issue last year. The problem is that your batch job isn’t checking for already-processing orders before attempting updates. You need to add a pre-filter query to exclude orders that are currently locked by another process. Also, the workflow status updates need to be atomic - update the status and release the lock in a single transaction. Check if your batch job is committing too frequently or holding locks too long during validation steps.

7

Mark, that makes sense. Our current batch job does validate each order individually before updating status, which could be holding locks too long. How would you recommend structuring the transaction boundaries? Should we validate all orders first, then update in bulk?