The current VeloCloud SD-WAN Edge by HTTP template collect link metrics via aggregate API endpoint.

According to the Zabbix integration page, the Edge template uses the macros {$VELOCLOUD.ENTERPRISE.ID} and {$VELOCLOUD.EDGE.ID}, and the "Get link metric data" item has the key "`velocloud.edge.link.get.data" and the type "HTTP agent."

The problem is that the aggregate endpoint can return link metric only for the current Edge, but for multiple Edges or Enterprises. In the large MSP-environment this results in a single discovered Edge host receiving link records form other Edges/Enterprises. As a result, velocloud.link.discovery may create link items on a single Edge host for links that do not belong to the current Edge/Enterprise.

Steps to reproduce:

1. Configure VeloCloud SD-WAN by HTTP / VeloCloud SD-WAN Edge by HTTP templates.
2. Use an API token with access to multiple Enterprises.
3. Discover Edge hosts.
4. Check a discovered Edge host with valid:

{$VELOCLOUD.ENTERPRISE.ID}
{$VELOCLOUD.EDGE.ID}

1. Review raw value of velocloud.edge.link.get.data;
2. Check discovered link items/tags on that Edge host.

Result:

1. velocloud.edge.link.get.data returns link records from multiple Enterprise/Edges.
2. velocloud.link.discovery creates link items on one Edge host for links, that do not belong to the current Edge/Enterprise;
3. In the client case, the Edge Host has received about 42 000 items, and the tags showed various Enterprises that were not related to it. 

Expected:

1. For the Edge host, the link discovery rule must only receive and create links relating to the following:

{$VELOCLOUD.ENTERPRISE.ID}
{$VELOCLOUD.EDGE.ID}

Temporary workaround was applied:

Was tested temporary LLD filter on Zabbix side:

LLD macros:

{#EDGEID} ->  $.link.edgeId
{#ENTERPRISEID} -> $.link.enterpriseId

Filter:

{#EDGEID} matches ^{$VELOCLOUD.EDGE.ID}$
{#ENTERPRISEID} matches ^{$VELOCLOUD.ENTERPRISE.ID}${code}

Condition logic : AND

This workaround helped to reduce the creation of incorrect link items, but not reduce the payload requested from the Orchestrator, bacause he filtering takes place  after Zabbix has already received the aggregate response.