icon
menu

Advanced References

This page documents the following advanced techniques for referencing resources in perspectives:

Multi-reference matching

Multi-reference matching is used to match multiple resources using a single reference. It is useful for cutting down on repetition in relation perspectives.

As explained in the previous section, references normally resolve to a single resource, even if multiple resources have the same identifier in the resource tree. For example, the following perspective code:

resources:
- name: Main Server
  icon: Networking/laptop.svg
    
- name: Switch A
  children: 
  - name: Port 1
  - name: Port 2
  - name: Port 3
    
- name: Switch B
  children: 
  - name: Port 1
  - name: Port 2
  - name: Port 3
    
- name: Switch C
  children: 
  - name: Port 1
  - name: Port 2
  - name: Port 3

perspectives:
- name: Connections
  relations:
    - from: Main Server
    - to: Port 1 # Matches only one instance of Port 1

will produce the following diagram:

An Ilograph diagram with one relation

As shown, only one instance of Port 1 appears connected to Main Server.

To have this relation instead go to all Port 1s, surround the resource ID in square brackets like so:

  relations:
    - from: Main Server
    - to: [Port 1] # Matches ALL instances of Port 1

This will produce the following diagram:

An Ilograph diagram with multiple relations

Note that square brackets can used when referencing parents, children, and descendants:

  relations:
    - from: Main Server
    - to: Data Center 1//[Port 1] # Will match ALL instances of Port 1 that are descendants of Data Center 1

Wildcards when matching multiple references

Wildcards (*s) can be used with multi-reference matching like so:

  relations:
    - from: Main Server
    - to: [Port *] # Matches ALL Ports

An Ilograph diagram with multiple relations

Wildcard matching can be combined with parent/children/descendant references:

  relations:
    - from: Main Server
    - to: Switch A/[Port *] # Matches ALL Ports that are direct descendants of Switch A

An Ilograph diagram with multiple relations

Wildcards can begin at the beginning, middle, and end of the query. Multiple wildcards in one query are allowed.

For examples of multi-reference matching, see the Physical Datacenter Architecture demo diagram.

Relative references

Relative references is another advanced method to reduce repetition in relational perspectives.

Consider a model of three identical systems (System 1, System 2, and System 3), each with a firewall, a load balancer, and two “instances” (Instance A and Instance B):

resources:
- name: System
  icon: Networking/computer-network.svg
  color: RoyalBlue
  abstract: true
  children: 
  - name: Firewall
    color: Firebrick
    icon: Networking/firewall.svg
    
  - name: Load Balancer
    color: DarkCyan
    icon: Networking/network-hub.svg
    
  - name: Instance A
    color: DeepPink
    icon: Networking/server.svg
    
  - name: Instance B
    color: DarkBlue
    icon: Networking/server.svg
    
- name: System 1
  instanceOf: System
    
- name: System 2
  instanceOf: System
    
- name: System 3
  instanceOf: System

Using this model, we can create a perspective showing that each firewall sends traffic to its corresponding load balancer:

...
perspectives: 
- name: Routing
  relations: 
  - from: System 1/Firewall
    to: System 1/Load Balancer
    
  - from: System 2/Firewall
    to: System 2/Load Balancer
    
  - from: System 3/Firewall
    to: System 3/Load Balancer

When rendered, the perspective looks like so:

An Ilograph diagram three relations

While this works, there is quite a bit of repetition here. This repetiton would continue as the number of Systems increase.

We could try to cut down on this repetion using multi-reference matching (see above), replacing three relations with just one:

...
perspectives: 
- name: Routing
  relations: 
  - from: [Firewall]
    to: [Load Balancer]
    label: Traffic

While this is cetainly shorter, it is not equivalent to what it replaced. Since [Firewall] matches all firewalls, and [Load Balancer] matches all load balancers, the result is every firewall sending traffic to every load balancer:

An Ilograph diagram with mixed up relations

This is clearly not what we intended. Instead, we want to specify that every firewall sends traffic to the load blancer in the same system. This is where relative references can be used:

...
perspectives: 
- name: Routing
  relations: 
  - from: [Firewall]
    to: ../Load Balancer
    label: Traffic

By prefacing the to reference with ../ we indicate that it is relative to the from reference(s) in the same relation. This is now equivalent to the first perspective, only without the repetition:

An Ilograph diagram three relations

Relative references can be combined with multi-reference-matching. Below, we add another relation specifying that every load balancer routes to every instance it shares a parent with:

...
perspectives: 
- name: Routing
  relations: 
  - from: [Firewall]
    to: ../Load Balancer
    label: Traffic

  - from: [Load Balancer]
    to: ../[Instance *]
    label: Routes to

With this addition, the perspective now looks like so:

An Ilograph diagram with multiple relations

Note: to reduce visual repetition, the diagram renderer may start stacking the Systems on top of each other if “Stack Similar Resources” is enabled. This can be disabled in the “more” menu (web version), or under the “View” menu (Ilograph Desktop).

Relative references are not limited to resources with shared parents. Multiple ../’s can be combined to go “up” multiple ancestors in the resource tree, like in this example:

...
    to: ../../../Resource

Note that relative references can also be combined with references to any descendant resource (using the double forward-slash):

...
    to: ../..//Resource

Relative references can be used in the from or to propery in a relation, but not both at once. As demonstrated in the above example, relative references are very useful when combined with resource inheritance and multi-reference-matching.

Clones

Cloning is a very advanced, and very rare, technique that allows the same resource to appear in more than one place in a perspective. It should not be confused with resource inheritance, which allows you to define similar or identical, but still distinct, resources.

Normally, a resource appears in only one place in a perspective. This is desireable because otherwise viewers might see the same resource in two places and conclude (wrongly) that they are distinct entities. There are some rare circumstances, however, where it is desireable to override this behavior. This is accomplished by resource cloning.

Resource clones are created when referencing resources in perspectives. To create a clone, simply reference a resource as normal (such as in the to field of a relation), and append a * and an identifier. Each unique identifier results in a unique clone. Below is a simple example of cloning in a perspective:

resources:
- name: Resource A
- name: Resource B
    
perspectives:
- name: Dependency
  relations: 
  - from: Resource A
    to: Resource B
  - from: Resource B
    to: Resource A *2

The resulting perspective looks like so:

An Ilograph diagram with clones

The identifier can be any string; it is not restricted to numbers.

Resource clones can be used anywhere regular resources are referenced, namely in relations, sequences, and slides. Cloned resources can also be referenced in aliases, and given new parents using parent overrides.