Service Desk Practitioners Forum

attributes on relations

Geert Van Riet
Regular Contributor.

attributes on relations


We are setting up HPSD for our CMDB. In designing our solution we have some major problems due to the restrictions on relations in SD. The fact that you cannot store any attributes on a relation forces us to do some 'dirty' workarounds to solve this.

Some example:
- We store some backup related data in CMDB.
We will base our backups of systems on data gathered from CMDB. What we need there is some specific attributes for instance between an application and an Filesystem.
Application X is on filesystem Y and has some specific backup attributes for the XY combination. Application X can also be partly on filesystem Z and then has some specific backup attributes for the XZ combination.
So logically, we would put these attributes on the relation between app and filesystem (X-Y, X-Z) but we cannot do this in SD so we have to create some 'combined CI's' for this and link them with our application.

Doing this, we end up with unnecessary duplication of CI records and unnecessary complexity for users who have to maintain these backup attributes.

But it's not only the backup attributes, we have other stuff we would like to store on relations too (active or passive status of a relation for instance).

Does anyone else have problems not having attributes on relations ?? If yes, how do you solve these issues without messing up your CMDB? And does anyone have an idea if this is something that is on the future roadmap of SD??

Thanks for any reactions.

Robert S. Falko
Acclaimed Contributor.

Re: attributes on relations


I think the lack of relations attributes is a problem if the same attributes ought to available on different types of relations. If not, you can simply create additional relations to cover your requirements.

For example, we have various relations between MQ Series objects. Some of these relations should, intuitively, have a boolean attribute. So we just create two different relations, according to the value of that attribute. Our MQ Series administrator is happy with that solution.

In the example you give, the relation between Application X and filesystem Y, would not be the same as the relation between Application Y and filesystem Z. By clever naming of the relations, you should be able to work around the clumsiness of this approach.