As we know, Agents belong to a specific Flow, and correlation strategies enable us to identify the messages and corresponding Agent Events that belong to the same Item in that Flow.

When the Flow takes a single unique path through the network or application from a single starting point to a single end point, VMX-Analysis can correlate Agent Events unambiguously, as we describe in the Correlating an item section of this document.



1:1 Flow (one Visibility Point at the starting point to one Visibility Point at the end point):

1:1 Flow (one Visibility Point at the starting point to one Visibility Point at the end point.)

However, in some scenarios, such as for publication or subscription services and active or active server topologies, an entity may broadcast a business object to multiple end points for purposes of redundancy or scalability. In this scenario, a Flow will contain multiple branches, each leading to a different end point. The business object, for example a price, flows down these multiple branches simultaneously.

In these Fan-out topologies, the same business object is seen at multiple Visibility Points on different branches.

A fan-out topology

Correlating Agent Events in Fan-out topologies

Beeks Analytics can build intervals between Visibility Points in branches as well as in 1:1 Flows and between Flows. However, for Fan-out topologies, VMX-Analysis can’t use Correlation ID to identify the Agent Events that belong to each individual branch in the Flow, because all Agent Events in a Flow share the same Correlation ID, even those on different branches. Instead we use a unique identifier for the branch if available, or we use Connectivity hints.

Using another unique identifier

If the business object already contains a unique identifier for each end point, then the Agent can be configured to inject it into a Capture Attribute and then pass it to VMX-Analysis where it is used to identify Agent Events from the same branch in a Flow. An example is where the business object for each end point contains a VLAN tag specific to the end point.

Connectivity hints

Connectivity hint

A piece of data injected into a business object by an Agent to indicate which branch the Agent Event is on.

Example
In the diagram below, VMX-Analysis is configured to build interval timings from:

  • Agent 1 to Agent 2

  • Agent 1 to Agent 3

  • Agent 2 to Agent 4

  • Agent 3 to Agent 4

Agents in a fan-out topology

Without Connectivity Hints, VMX-Analysis doesn’t know which Agent Event belongs to which path, and will compute unnecessary intervals such as:

  • Agent 2 to Agent 5

  • Agent 3 to Agent 4

This is solved by configuring Agent 2 and Agent 3 to inject the following Connectivity Hints to the business object.

  • Agent 2 injects branchA into the business object that goes to Agent 4, where A is an identifier for that branch.

  • Agent 3 injects branchB into the business object that goes to Agent 5, where B is an identifier for that branch.

Now VMX-Analysis can identify Agent Events containing branchA as belonging to one branch, and those with branchB into a separate branch, and measure the appropriate interval timings between Agent Events.

Note: Agent 1 wouldn’t usually be configured to inject connectivity hints unless the delivery time from Agent 1 to Agents 2 and 3 is materially different.

Where the Fan-out topology contains a tree of branches, the Agent is configured to use incoming and outgoing connectivity hints to identify the path.

Incoming connectivity hints are injected into the business object by the previous Agent and which indicate the branch ID, the previous Agent, and the current Agent. For example, 23branchA.

Outgoing connectivity hints are injected into the business object by the current Agent and which indicate the branch ID, the current Agent, and the next Agent. For example, 38branchA.

Connectivity hints