1. OOB the relationship between the SQL DB instance and Server is
Database RUNS ON::RUNS Linux server
and the form view is like this:
But one of our infrastructure team person saying its the other way around, ie the relationship should be
Database RUNS::RUNS ON Linux server
and says the map should be like this where Linux server is the Upstream and Database is the Downstream because, when the upsteam CI (Linux) is down, then the Downstream CI (Database) will also be down.
For this happen, I need to create a new entry cmdb_rel_type table with RUNS::RUNS ON, and only then I can see the map as shown above.
Also if I did this way, the Upstream and Downstream also shows properly in the form view.
So its really making sense what that person is saying.
Then why ServiceNow has built it other way round? If you see the 2nd image, If I use oob relationships, linux server is showing under Downstream relationship.
Confused!!!
If you know.have clarity on this, pleasee share the details.
@Suggy I did a little bit of playing in a PDI and the question of whether something shows as upstream or down stream is entirely dependent on which one is the parent.
Example
As an example. I set up an *ANNIE-IBM Used by::Uses C:\ relationship. I selected this relationship since it has a matching "Used by::Uses" relationship type.
I then looked at all the views of the relationship and *ANNIE-IBM (as the parent) is the upstream CI.
*ANNIE-IBM
C:\
Dependency View
Inverse
I then switched the whole relationship around to be the inverse C:\ Uses::Used by *ANNIE-IBM relationship.
This resulted in C:\ (as the parent) being the upstream CI
*ANNIE-IBM
C:\
Dependency view
Conclusion
So, with all that, whether the CI is listed as Upstream or Downstream is dependent on whether the CI is the Parent, or it is the Child.
For use cases where there is an obvious inverse relationship (as in my example) this will allow you to get objects to appear in the logical place.
Unfortunately, for non-obvious inverse relationships (like your example), this is not an option.
