I want to explain a bit how bill of material data works in Vault. It’s not very intuitive looking at the API. I’ll also attempt to answer the question, “Why did they do it that way?”
The Primary Workflow
Let me know over the “primary workflow,” which I’m defining as the workflow most responsible for the architecture. There are plenty of other valid workflows, but I’m not going to focus on them much here.
It’s best if I list out the sequence of events in the primary workflow:
- The CAD user adds a file to Vault.
- The CAD plug-in uploads a BOM object along with the file. I’ll refer to this object as the “file BOM”.
- The “file BOM” object gets stored in the database and mostly stays dormant.
- A Vault user selects the file and runs the “Assign Item” command.
- Internally, the “file BOM” gets read and becomes the template for creating or updating Vault Items. In other words, the “file BOM” fills out most the information in the Assign Item wizard.
- When the Assign Item wizard is complete, the Item objects are created and hooked together to form an “Item BOM”. The Item BOM is what user sees and interacts with in the Item Master.
- The “file BOM” is still around in the database, but it goes back to being dormant. It would only be used again if there is an update to the Item BOM or a need to re-create the Item BOM.
Impact
There are some interesting consequences as a result of this workflow.
- The item structure has nothing to do with the file assembly structure. The file BOM is the only factor.
- The file BOM is uploaded, even if the product is Vault Basic. The idea is that the product may get upgraded to Vault Professional in the future. If the upgrade never happens, the BOM data stays dormant forever.
- The file BOM is not static data. It may get altered by the server. For example, data gets “filled in” during an Assign Item operation. This way things are optimized if the Items ever need to be updated.
- Results from GetBOMByFileId are not guaranteed to be the same, even when called on the same file version. See previous bullet.
- GetBOMByFileId is not actually used anywhere in the process. It’s an API-only feature intended for testing and troubleshooting purposes. And yes, I’m well aware that many people are using this function beyond it’s intended scope.
File BOM vs. Item BOM
Here is a quick rundown of the two different BOM representations.
File BOM | Item BOM | |
Purpose | A template for the Item BOM | Represent an accurate Bill of Materials |
Visible to end user | No | Yes |
File scope | Attached to 1 and only 1 file. | Can be associated with 0 to many files. |
Can be directly edited | No | Yes |