Here is what I see from the API docs:
void getMultilevelBomCompare(java.lang.Object part1,
ConfigSpec spec1,
java.lang.Object part2,
ConfigSpec spec2,
int maxDepth,
MultilevelBomCompareVisitor aVisitor)
throws WTException,
org.xml.sax.SAXException
Deprecated.
Recursively compares parts used by part1 and part2 using configSpec1 and configSpec2 to select the part versions. The comparison will only go maxDepth levels deep. The result is a string of XML showing the differences and any product structure needed to show where the differences occurred. This method delegates much of its responsibility. For customization this method uses a MultilevelBomCompareVisitor.
Supported API: true
Parameters:
part1 - The first part being compared. It will be compared to part2 using spec1 to navigate its part structure.
spec1 - The config spec being used to navigate the part structure of part1.
part2 - The second part being compared. It will be compared to part1 using spec2 to navigate its part structure.
spec2 - The config spec being used to navigate the part structure of part2.
maxDepth - The maximum number of levels down in the part structure to navigate as the comparison is done.
aVisitor - The visitor used to navigate the two product structures that are being compared. Customization of the data available for the report can be done by passing different visitors. MultilevelBomCompareVisitor is the reference implementation supplied out-of-the-box.
Note that in 11.1 M020, this was already deprecated and strangely, this method returns nothing (void). There isn't anyway I see to return this. The last value is a visitor which controls how it walks the tree. Honestly, this is a rather complex tasks given the config spec and a number of variables. I did do something similar to compare BOMs on a Change Notice report but that was single level, far easier task that just requires a two lists of WTPartUsageLinks. Did you absolutely need Multilevel?
