Note: If I specify the relations inside the Explorer Query I am able to see the relationships. I'd like to see the relations without specifying the relations in the query.
I'm thinking that the Atrium Explorer doesn't see the relations besides the ones in the BaseRelationship superclass. Is there a way to customize the explorer in a way that it sees other types of relationships too?
1 of 1 people found this helpful
Hi Paolo, you are correct. Expand Children will work in a default way, that is using BaseRelationship and any child class of it.
There was no planning for a different superclass. Can you try making your relationship class as a child of BaseRelationship?
What is the justification for using a totally different superclass?
We used a totally different superclass because the CIs that we are managing belong to a totally different class from the ones that we have in the BaseElement one, and because the software let us create a new superclass, so we thought this kind of modification would be allowed.
Is there any way to modify the behavior of the Atrium Explorer to make it work with classes that don't belong to BaseElement/BaseRelationship, if so, would you point us in the right direction?
Be aware I'm not asking for specific instructions, just which object/form/table we have to edit to make the feature work with our classes.
"Can you try making your relationship class as a child of BaseRelationship?"
I don't think we can, the CIs and classes are already in a Production environment, and we would have to delete the classes and create them again under BaseElement/Relationship right?
If there is a non-destructive way I can test in in our testing environment.
It is true it is allowed, but in this case it is highly not recommended. Best practices in the documentation mention that you should always try to fit your data into the existing CDM and changes made need to be highly thought through because the impact can be high.
Regarding the CMDB Explorer this definitely seems like a defect, and you should work with support to analyze that and file a defect if necessary.
Even if they are in production migrating to a Relationship class under/or part of BaseRelationship hierarchy should be easy. You can create a one-time migration job, for example using Atrium Integrator. Another option is simply to change the classID of the records, if the fields are the same and contain the same information then this can be achieved.
Do you know how we could modify the Atrium Explorer behavior to make it function as we need?
What do we need to edit to change its behavior, I didn't find anything in the related forms.
You only have until the end of this year before Adobe removes support from Flash, and we're all supposed to be on 20.2 p1 or whatever it is moves functionality to the Jetty console.
Have you looked at the Jetty Console to see if it will do what you want?
Agreed with Nick. Did you check the new console? CMDB Explorer.