We’re automating shift changes where we need to assign 20-30 operators to different machines simultaneously. Debating between using the batch assignment endpoint versus looping through single assignments. The batch endpoint seems more efficient but I’m concerned about error handling - if one assignment in the batch fails, what happens to the rest? With single assignments in a loop, we have granular control and can implement retry logic per assignment. Also wondering about API rate limits and whether the batch endpoint counts as one request or multiple. What are the trade-offs for transaction rollback behavior in each approach?
Batch endpoint is definitely the way to go. It’s transactional - either all assignments succeed or all fail, which is exactly what you want for shift changes. You don’t want half your operators assigned and half not. The API counts it as one request against rate limits, so you can do more assignments per minute.
Transaction rollback is important for data consistency. With single assignments, if assignment #15 fails and you’ve already committed 14 assignments, you’re in an inconsistent state. The batch endpoint handles this properly with database transactions. However, make sure your batch size isn’t too large - we found that batches over 50 assignments can timeout. Split into multiple batches if needed.
Check the batch endpoint documentation for your version. In 2021.1, the batch endpoint has a ‘partial success’ mode where you can set rollbackOnError=false. This gives you the best of both worlds - efficiency of batch processing with granular error handling. The response includes success/failure status for each assignment in the batch.
Having implemented both approaches in production environments, I can provide detailed analysis of the trade-offs for shift automation scenarios.
Batch Endpoint Efficiency
The batch assignment endpoint offers significant advantages:
-
Network Overhead: One HTTP request instead of 30 reduces network latency by ~90%. Each HTTP request has overhead (TCP handshake, TLS negotiation, headers), which multiplies in a loop.
-
Database Transactions: The batch endpoint wraps all assignments in a single database transaction, ensuring atomicity. This is critical for shift changes where you want all-or-nothing semantics.
-
API Rate Limits: Counts as ONE request against rate limits. For 30 operators:
- Batch: 1 request (1% of 100/min limit)
- Loop: 30 requests (30% of limit)
If you’re managing multiple plants or running frequent shift changes, this difference matters significantly.
-
Server-Side Optimization: The batch endpoint can optimize database queries (bulk inserts, batch updates) rather than executing 30 separate transactions.
Error Handling Strategies
The concern about error handling is valid, but the batch endpoint in Apriso 2021 provides flexible options:
Option 1: All-or-Nothing (Default)
POST /api/v1/resources/batch-assign
{
"rollbackOnError": true,
"assignments": [...]
}
If ANY assignment fails, ALL are rolled back. Use this when shift consistency is critical.
Option 2: Partial Success
POST /api/v1/resources/batch-assign
{
"rollbackOnError": false,
"continueOnError": true,
"assignments": [...]
}
Each assignment is attempted independently. Response includes per-assignment status:
{
"totalRequested": 30,
"successful": 27,
"failed": 3,
"results": [
{"index": 0, "status": "success", "resourceId": "M-1001"},
{"index": 14, "status": "failed", "error": "Operator not qualified"},
...
]
}
This gives you granular visibility into failures while maintaining efficiency.
Transaction Rollback Behavior
Understanding rollback is critical:
Batch Endpoint (rollbackOnError=true):
- All assignments execute within single database transaction
- If any fails, entire transaction rolls back
- Database state remains exactly as before the API call
- No partial assignments exist in the system
Single Assignments in Loop:
- Each assignment is a separate transaction
- If assignment #15 fails, assignments 1-14 are already committed
- Requires manual cleanup/rollback logic in your code
- Risk of inconsistent state if your cleanup fails
Recommended Hybrid Approach
For production shift automation, I recommend:
-
Pre-validation: Before calling the API, validate all assignments:
- Verify operators exist and are available
- Check machine states
- Confirm operator qualifications
- Validate shift is active
-
Use batch endpoint with partial success mode: Set
rollbackOnError=falseto handle edge cases gracefully -
Implement retry logic for failed assignments: Extract failed assignments from the batch response and retry individually with exponential backoff
-
Monitor and alert: Track success rates and alert supervisors when failure rate exceeds threshold
Performance Comparison
Real-world measurements from our deployment:
Single Assignments (30 operators):
- Total time: 12-15 seconds
- Network overhead: ~8 seconds
- Processing time: ~4-7 seconds
- Rate limit impact: 30%
Batch Endpoint (30 operators):
- Total time: 2-3 seconds
- Network overhead: ~0.3 seconds
- Processing time: ~2-3 seconds
- Rate limit impact: 1%
5x performance improvement with batch endpoint.
API Rate Limits Deep Dive
Apriso 2021 default limits:
- 100 requests/minute per API user
- 1000 requests/hour per API user
For multi-plant operations with 4 plants, 3 shifts/day:
- Loop approach: 30 × 4 × 3 = 360 requests/day for shift changes alone
- Batch approach: 1 × 4 × 3 = 12 requests/day
The batch endpoint provides much better scalability headroom.
Edge Cases to Handle
-
Batch Size Limits: Maximum 100 assignments per batch in Apriso 2021. For larger shifts, split into multiple batches.
-
Timeout Handling: Batches with 50+ assignments may timeout if server is under load. Implement timeout detection and retry logic.
-
Concurrent Batch Requests: If multiple processes submit batches simultaneously, use idempotency keys to prevent duplicate assignments.
-
Partial Failures: With partial success mode, implement workflow to handle the failed assignments - either manual intervention or automated retry.
Final Recommendation
Use the batch endpoint with these settings:
rollbackOnError=falsefor production flexibilitycontinueOnError=trueto process all valid assignments- Pre-validation to catch issues early
- Retry logic for failed individual assignments
- Comprehensive logging for troubleshooting
This approach provides the efficiency benefits of batch processing while maintaining the granular control you need for reliable shift automation.
We use single assignments in a loop because we need partial success handling. During shift changes, some assignments might fail due to operator qualifications or machine availability, but we still want to process the valid ones. With the batch endpoint, one failure means redoing everything. Our approach: loop through assignments, collect failures, retry failed ones with exponential backoff, then alert supervisors about any that still fail.