I attached my BOM-file.
The Gerber file of my PCB uploads just fine - whenever I try to upload this BOM file, the popup “The system is now calculating the component cost.” remains displayed indefinitely (I tried waiting for a full hour - no luck).
Is something wrong with my BOM-file? My Gerber file? Would be great if someone could give some pointers so I can start figuring out why this is happening.
particle_BOM2.xlsx (10.1 KB)
Hi Lex,
Thanks for your message, did you get it to work? I’ve just tried uploading the BOM using Microsoft Edge and Chrome without problems, there is nothing wrong with the format. Could you try again? It could just be a poor internet connection.
No, I continue having this issue. Yesterday, it did go through and it required me to input purchase links for three components as they couldn’t find it.
However, besides that one time I continue to experience issues with uploading my BOM-file…it always remains stuck in that window for hours. It’s annoying as now I can’t make any adjustments or anything to my PCB, or spend hours trying it over and over.
That is very peculiar, I’ve just tried again and I’ve asked a few other colleagues to try and they didn’t have any issues. The IT team are also checking to see if they can find anything odd.
Could you let us know what browser you are using? Can you download the template and try uploading that?
A BOM file that contains a component with a “publisher” field with more than 255 character fails due to the constraints of the field. However, there is no feedback or way to know that the BOM upload failed other than figuring it out from the log file.
Current Behavior:
When uploading a broken BOM file (see bom-broken.xml in bom-broken.zip), no components will be loaded, and there is no way to see that the BOM processing failed outside the log file. See “Additional Details” section for the stacktrace.
Steps to Reproduce:
Create a BOM file with a component that has a publisher value of more than 255 characters
– Or use the bom-broken.xml in bom-broken.zip
Upload the BOM file to Dependency Track manually in a test project
Note that no errors are raised, and no components are loaded
To test that the issue is with the publisher field, simply truncate the field in the XML file and reupload it to Dependency Track. The component should appear correctly in the Components tab.
Expected Behavior:
I expect one of 2 behaviors:
The BOM processing should succeed and limits put on fields should be removed unless explicitly stated by the CycloneDX specification
There should be a way to see that the BOM processing failed in the frontend, especially when uploaded manually
I think option 1 is better than option 2. The restriction makes it a problem for using automation as there is no way to predict if a component will break Dependency Track. Since the specification does not contain restrictions on field lengths, Dependency Track should not enforce arbitrary ones.
Environment:
Dependency-Track Version: 4.4.2 and 4.5.0
Distribution: Docker
BOM Format & Version: XML 1.3
Database Server: PostgreSQL (but should apply to all)
Browser: Chrome 100.0.4896.127
Additional Details:
DT stacktrace
2022-05-27 16:37:25,861 [] ERROR [org.dependencytrack.tasks.BomUploadProcessingTask] Error while processing bom
javax.jdo.JDOFatalUserException: Attempt to store value “Frank Hommers and others (Burhan Irmikci (barhun), Zachary Sims(zsims), kgamecarter, Stafford Williams (staff0rd), briangweber, Viktor Svyatokha (ahydrax), Christopher Dresel (Dresel), Vytautas Kasparavičius (vytautask), Vincent Vrijburg, David Roth (davidroth).” in column “PUBLISHER” that has maximum length of 255. Please correct your data!
at org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:615)
at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:720)
at org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:740)
at alpine.persistence.AbstractAlpineQueryManager.persist(AbstractAlpineQueryManager.java:417)
at org.dependencytrack.persistence.ComponentQueryManager.createComponent(ComponentQueryManager.java:320)
at org.dependencytrack.persistence.QueryManager.createComponent(QueryManager.java:379)
at org.dependencytrack.tasks.BomUploadProcessingTask.processComponent(BomUploadProcessingTask.java:170)
at org.dependencytrack.tasks.BomUploadProcessingTask.inform(BomUploadProcessingTask.java:124)
at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:99)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.datanucleus.exceptions.NucleusUserException: Attempt to store value “Frank Hommers and others (Burhan Irmikci (barhun), Zachary Sims(zsims), kgamecarter, Stafford Williams (staff0rd), briangweber, Viktor Svyatokha (ahydrax), Christopher Dresel (Dresel), Vytautas Kasparavičius (vytautask), Vincent Vrijburg, David Roth (davidroth).” in column “PUBLISHER” that has maximum length of 255. Please correct your data!
at org.datanucleus.store.rdbms.mapping.column.CharColumnMapping.setString(CharColumnMapping.java:253)
at org.datanucleus.store.rdbms.mapping.java.SingleFieldMapping.setString(SingleFieldMapping.java:183)
at org.datanucleus.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:158)
at org.datanucleus.state.StateManagerImpl.providedStringField(StateManagerImpl.java:1853)
at org.dependencytrack.model.Component.dnProvideField(Component.java)
at org.dependencytrack.model.Component.dnProvideFields(Component.java)
at org.datanucleus.state.StateManagerImpl.provideFields(StateManagerImpl.java:2528)
at org.datanucleus.store.rdbms.request.InsertRequest.execute(InsertRequest.java:352)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.insertObjectInTable(RDBMSPersistenceHandler.java:162)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.insertObject(RDBMSPersistenceHandler.java:138)
at org.datanucleus.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:4569)
at org.datanucleus.state.StateManagerImpl.makePersistent(StateManagerImpl.java:4546)
at org.datanucleus.ExecutionContextImpl.persistObjectInternal(ExecutionContextImpl.java:2026)
at org.datanucleus.ExecutionContextImpl.persistObjectWork(ExecutionContextImpl.java:1869)
at org.datanucleus.ExecutionContextImpl.persistObject(ExecutionContextImpl.java:1724)
at org.datanucleus.ExecutionContextThreadedImpl.persistObject(ExecutionContextThreadedImpl.java:219)
at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:715)
… 10 common frames omitted
Regards,
Rachel Gomez