We’re experiencing severe performance issues with our change management workflow when processing ECOs that affect multi-level BOMs. Our custom PX script is designed to propagate changes through the entire BOM hierarchy, but it hangs indefinitely when the BOM has more than 4-5 levels.
The PX recursion handling walks through each BOM level to update affected components and their children. However, with deeper BOM structures (we have some 8-10 level assemblies), the script execution just stops responding. Here’s the core logic that’s causing problems:
public void processBOMLevel(IBOMItem item, int level) {
for (IBOMLine line : item.getBOMLines()) {
updateComponent(line);
processBOMLevel(line.getChild(), level + 1);
}
}
The workflow step optimization seems inadequate for complex assemblies. We’re seeing memory consumption spike and eventually the change order closure gets blocked completely. The PX script doesn’t throw errors - it just hangs, forcing us to restart the application server. Multi-level BOM processing shouldn’t be this problematic. Any suggestions on handling deep BOM recursion more efficiently?
Don’t forget about workflow step optimization. Your PX might be running synchronously during the workflow, blocking the entire change order closure. Consider making it asynchronous - queue the BOM update as a background task and let the workflow proceed. The change order can close while your PX processes the multi-level BOM in the background. This requires careful state management but dramatically improves user experience.
Classic recursion issue. Your script is likely hitting stack overflow or creating too many database queries. Each recursive call loads BOM lines from the database, and without caching, you’re making exponential queries. For an 8-level BOM with 10 components per level, that’s potentially 10^8 queries. You need to implement breadth-first traversal with batching instead of depth-first recursion.
Loading everything into memory upfront is actually the right approach, but you need to do it smartly. Use Agile’s BOM explosion API to get the flattened structure in a single query, then process it iteratively rather than recursively. This gives you O(n) complexity instead of O(n^depth). Also consider processing in chunks - update 100 components, commit, then continue. This prevents transaction timeout issues.
Add a maximum recursion depth limit to prevent runaway execution. Set a threshold at 10 levels and log a warning if exceeded. Also, implement a visited set to track already-processed items - you might have circular references in your BOM causing infinite loops. Check if your BOM structure has any components that reference parent assemblies.
We don’t have circular references - our BOM validation prevents that. But the exponential query issue makes sense. Each recursive call is indeed hitting the database separately. Would loading the entire BOM structure into memory first help, or would that just shift the problem to memory consumption?