iDNA Applications collects design data in order to surface insights and complexity about the various applications in your environment. To determine if there are issues with design collections either
From here, you will receive all messages about why iDNA had a failure collecting design information regarding a particular database. The issues could be wide and varied to actual issues with the application’s design structure (this is a Domino error, not an iDNA one). You get a hint about what is broken and you need to fix the design yourself: This could be permission issues, server down, etc.
Often failures are caused by the IBM / HCL DXL Exporter on which the Design Collection in iDNA Application depends. DXL Exporter is deemed unstable, however there is no other way to export the designs of Notes databases. panagenda works around the frequent crashes by having the DXL exporter running in its own Docker container and when freezes are detected from the outside, it is restarted automatically. For advanced commands, you could go to the iDNA application's console, issue a "'docker ps -a"-- and you can notice a frequently different uptime of the panagenda_dda Docker container compared to all the other ones. However, once the exporter crashed on one database, we can't automatically rescan it again due to technical constraints of DXL itself. This is how the list of failed databases builds.
The best practice is to simply rescan failed databases several times. Therefore:
