The documentation is getting better. Try the Atrium Core 7.6 Data Modelling Guide that is part of the Atrium 7.6 documentation.
Cheers Peter > No, thatâs not what Iâm trying to say. Sorry, I wasnât more clear. > Iâm just saying that thinking in terms of Parent/Child will probably end > up being confusing at some point. I think itâs better to think in terms > of Source and Destination. For example, if A depends on B, which is the > parent and which is the child? In the same vein, you can say that B > impacts A, because A depends on B, but when you look at the two > relationships in the CI viewer, youâre going to see two arrows pointing > in opposite directions. In that case, thinking in terms of parent/child > starts to break down. > > For servers and applications, OOB BMC discovery uses the > HostedSystemComponent relationship for this. The Server is the Source, > and the Application is the Destination in the relationship. If it makes > it easier here, you can think of the Source as the Parent and the > Destination as the Child. > > Iâm not sure about the documentation. It seemed to me that the > documentation was extremely lacking for most of ITSM (at least the 7.0 > stuff) as well as CMDB (at least up to 2.1). We ended up figuring a lot > of it out as we went along and by seeing how BMC did it with their > Configuration Discovery product (formerly Marimba). > > I hope this was a little clearer⦠> > Lyle > > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org] On Behalf Of Koyb P. Liabt > Sent: Thursday, December 03, 2009 11:04 AM > To: arslist@ARSLIST.ORG > Subject: Parent _ Child Relationship Server Appliction > > ** > > I have to define a role when importing the application data. In the case > we have a server, and an application, are you saying that an application > is the "Parent" role? In relationship to the server, I considered the > application the "child" and the server the parent. Without the Server, > the application would not operate. > > Is there any documentation on this. I have not been able to find it. > > ** > Iâm not sure it can be thought of in such a simple manner. The problem > is that what you consider the parent or the child does not necessarily > correspond to the direction of the relationship depending on what type of > relationship youâre talking about. For example, if Item A depends on > Item B, your relationship arrow goes from Item A to Item B, but can you > say that one is the parent or child in this relationship? In the case of > applications on servers in the CMDB, BMC uses a HostedSystemComponent > relationship. (I donâtânecessarily agree with this approach, but > thatâs the way it isâ¦) In that case, the arrow goes from the server > to the application. Conceptually, the application could probably be > thought of as the child, but the arrow goes the other way (you can also > debate which way the arrows ought to go to indicate which is the parent or > the child, further muddying the waters). > > I would say to not even try to think of things in terms of parent-child. > Rather, just figure out which way the arrows should go. In this case, > they go from the server to the application. What this means in concrete > terms is that, when you create a HostedSystemComponent for this, the > Source is the server, and the Destination is the application. > > Does that make sense at all? > > Lyle > > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org] On Behalf Of Koyb P. Liabt > Sent: Friday, November 20, 2009 10:35 AM > To: arslist@ARSLIST.ORG > Subject: Parent _ Child Relationship Server Appliction > > ** > Hi, > > We are having confusion in our organization. > > Relationships - If let's say Solaris Applications sit on the UNIX server. > Is the Solaris Application a child of the Unix server. Or is the Unix > server a child of the Solaris Application. > > We are just trying to understand what is the relationship of the > applications. > > > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ > > > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged information. Any > unauthorized review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply email > and destroy all copies of the original message. > > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
