A limit to how many BOMs can be listed on a BOM?
Is there a limit to how many BOMs can be listed on one BOM?
For example I have part 1234 and it lists 6 BOMs
Now on 3 of those BOMs they have more BOMs.
BOM 1 has 56 BOMs
BOM 2 has 24
BOM 3 has 11
making for 91 BOMs listed on the third level of part 1234.
The problem I have is that when I try to release part 1234 on an ECO it takes 15 – 20 minutes to get the Released pop up screen or it times out.
Is there a limit? I read another question asking if there is a limit to the number of items you can put on a BOM. It stated that it might slow down your system as you’re trying to release. I have a few BOMs with 100 or so child items with only a handful of those parts being BOMs so I haven’t had an issue with releasing those. The set up described above is giving me trouble though.
I was under the impression what slowed the release down was the number of affected items and the size of the first level BOM on those affected items. I did not think the depth mattered.
It does seem to. In my Q environment I removed all items from part 1234 and got the pop up to release screen in less than 30 seconds. I added each back one by one and still got the next pop in under 30 seconds. Once I added BOM 1 with the 56 BOMs it took 2 minutes for the pop screen, then when I added BOM 2 with 24 BOMs it took 8 minutes for the pop up screen and then 15 minutes to actually release. Finally added BOM 3 and it took the same amount of time 8 and 15 to release. No in production I’m adding another BOM and it’s timing out at 20 min just to get to the pop up.
This is why I’m wondering what is the limit or if there even is one.
Change order transactions are on number of affected items and redline information.
Breakpoint Testing Results in capacity planning guide will give insight on release of change orders processing time.
Object in memory for process is driven by number of parameters.
Like Java Heap memory, cluster size, number of threads running, Number of users concurrently logged.
What is the version of agile being used?
Such problems better addressed in batches, if organizations do not want to have normal course of change release management process.
Generally for mass change release management scenarios like mass update with automation is utilized and executed in batches.
As Steve Jones stated, I have only ever seen the number of affected items affect the speed of how fast an ECO can be released, and never the depth of the BOM. Note that you are not releasing the entire BOM tree of an assembly, but only it’s direct BOM. And this is true for each affected item. How big the direct BOM is can certainly be a factor, but unless sub-assemblies are also included as affected items, BOM in the next level down will not affect the processing of the ECO. I would never put more the 500 affected items on an ECO, and only then if the client has a rather robust Agile environment. I always recommend less than 200. I still remember a client that had a single ECO for a data load that had 7500+ affected items on it. And of course, users just *had* to go look at it every once in a while. And the system would grind to a halt.
As Paritosh pointed out, environment resources also play a factor. If your environment does not have a very large heap size, you can quickly swamp it when you have a lot of affected items in an ECO, as it has to pull things in, then push something else out to process the next affected item. It doesn’t take a lot of time, but it does take time.
Showing a screen shot of the exploded BOM tree for 1243 (with numbers appropriately blurred) would be good. Even better would be a screen shot of the performance metrics of your Agile server when you are releasing the ECO. After that, you might have to dig rather deeper into what is going on. Are there a number of required fields that must be checked on?? That can slow things down a bit (even more with large BOMs, because each component must also be checked). But that only applies to the direct BOM.