Entuity Integration

Versus connects to Entuity Network Analytics (ENA, from Park Place Technologies) — the network monitoring platform that already polls the switches, routers, firewalls, load balancers and hosts in many estates — so what Entuity knows becomes part of network automation. From the Integrations page, a workflow or the AutoPilot you can see which devices Entuity monitors and how, which incidents are open right now and on what, the event stream behind them, the Views the NOC works from and the port state of any monitored device, and you can reconcile Entuity's inventory with the Versus inventory and import what is missing.

The integration is read-first: every lookup is a plain API read. The write actions (close or annotate an incident, raise an event, import devices) are ordinary SDK calls you place behind an approval gate in a governed workflow.

---

How it connects

An Entuity source in Versus points at one ENA web server. Everything goes through the Entuity RESTful API under /api on that server:

Authentication is either an Entuity user over HTTP Basic (RFC 2617; Entuity caches the result for five minutes) or an access key sent in the ENA-Api-Key header (keys live in accessKeys.properties on the ENA server and map to an Entuity user). Either way the user's Entuity permissions scope what the API returns, so a read-only user is enough for everything except closing or annotating incidents and raising events. Use HTTPS — Basic credentials travel in clear text otherwise.

Secrets are write-only and encrypted at rest — they are never returned by the API, and editing a source lets you leave them blank to keep the stored values. See Security & Compliance.

Fields

Test reads the API version, counts servers, inventory devices and open incidents, and records them on the source.

---

What you can see

Open Integrations → Entuity → Explore on a source. Every tab shows whether the data is Live from ENA or, for a seeded demo source, Sample data.

• Overview — product and API version, the ENA servers behind the URL, monitored-device and View counts, open incidents by severity and the most severe open incidents.
• Inventory — every monitored device with management IP, Entuity device type, sysDescr, location, management level and SNMP version. Reconcile with Versus compares it with the Versus inventory by management IP, then by name or hostname, and lists what is only in Entuity (with the Versus vendor Versus would assign from the sysObjectID / sysDescr), what is matched, and what Versus manages that Entuity does not monitor. Tick devices and Import them: Versus creates plain device records with vendor, type, version and location filled in, ready for credentials. Devices Versus has no vendor for (UPS, wireless controllers, generic hosts) are listed, not created.
• Incidents — open, closed or all incidents, filtered by minimum severity or text: severity, incident, source object, impact, when it opened, contributing event count and annotation. Each row can be annotated or closed.
• Events — the event stream for the last hour to seven days, by state and minimum severity.
• Views — the View tree with the objects in the selected View; devices by default, every object type on request.
• Ports — the ports of any monitored device: admin / operational state (admin-up but operationally-down ports are highlighted), speed, IPs, VLANs, connected hosts and last change.

Severity follows Entuity's scale — info (2), minor (4), major (6), severe (8), critical (10).

---

Using it in workflows

The Python SDK exposes Entuity as versus.integrations.entuity() — the first enabled source, or versus.integrations.entuity('ENA Toronto') by name.

ena = versus.integrations.entuity()

# what is Entuity complaining about on this device?
for inc in ena.incidents_for('10.10.1.1'):                    # name, polled name or management IP
    versus.log(f"[{inc['severity_label']}] {inc['description']} — {inc['details']}")

# Entuity's record for the device, and its ports that are admin-up but operationally down
dev  = ena.find_device('tor-core-sw-01')
down = [p for p in ena.ports(dev['sw_id']) if p['admin_status'] == 'up' and p['oper_status'] == 'down']

# the estate
devices   = ena.inventory(q='tor-')
views     = ena.views()
perimeter = ena.view_objects('Perimeter')
critical  = ena.incidents(states='open', min_severity='severe')
recent    = ena.events(hours=6, min_severity='major')

# inventory drift between the two systems
gap = ena.reconcile()                 # {matched, only_entuity, only_versus, counts}

Actions — place these after a core.approval step in a governed workflow:

ena.close_incident(63, annotation='Port Gi1/0/24 replaced SFP — workflow run 1234')
ena.annotate_incident(61, 'ISP B case 00412 open')
ena.raise_event('Versus change window started', severity='info', source='Versus', reason='CHGT0042')
ena.import_devices(all_missing=True)  # or ids=['107', '116']

incidents_for() is the building block for a closed loop with the Diagnostics AutoPilot and the Desk: an Entuity incident names a device and port, Versus checks the device itself, applies the remediation behind an approval, and closes the Entuity incident with the ticket number in the annotation. The Generate with AI button in the Workflow Builder knows these methods, so "close the Entuity incident for this device after the port comes back up" produces a working workflow.

Device and incident shapes

find_device() and inventory() return:

incidents() and incidents_for() return {id, description, details, severity, severity_label, source, impact, opened, state, annotation, event_count, sw_id}; events() returns the same without state and with time instead of opened.

---

In the AutoPilot and Support Copilot

Two read-only expert tools are available to the Diagnostics AutoPilot and to agents that inherit its toolbox:

• entuity_incidents — open incidents for a device by IP or name (or the most severe open incidents overall), with an optional minimum severity.
• entuity_device — Entuity's inventory record for a device plus its admin-up / operationally-down ports.

A path-check that stalls at "the client cannot reach the VIP" can now continue with "Entuity has had Port Operationally Down open on tor-core-sw-01 Gi1/0/24 for 18 minutes, isolating tor-access-sw-04", which is usually the actual answer.

---

Demo source and sample data

Running manage.py seed_entuity_demo (or the full seed_demo) creates an Entuity (Demo) source flagged as a demo. It answers from a representative sample deployment — one ENA server, 24 monitored devices across Toronto and Montréal (the demo Check Point pair, ProxySG pair and Zscaler Private Service Edges plus the core and access switches, edge routers, WLC, firewall and UPS a monitoring platform would also know), eight Views, a day of events and eight open incidents including a critical unreachable switch, a severe BGP peer loss and a port down that isolates an access switch — so the surface is demonstrable before a real ENA server is connected. Reconcile shows real matches against the Versus demo inventory and real gaps. Actions on the demo source are simulated and say so.

Real sources never fall back to sample data: if ENA cannot be reached, the tab, the SDK call and the AutoPilot tool report the error.

---

Notes and limits

• The inventory list resource only carries id, name and polled name; Versus fetches per-device detail (type, sysDescr, management IP, sw_id) for the first 100 devices of a listing and for every device during a reconcile (up to 300). Large estates: scope with a Default View or search.
• Incident and event queries use Entuity's own filters — state, severity mask, View, opening time — and are sorted most severe first (incidents) or newest first (events). Entuity also offers updateId cursors for incremental polling; the SDK exposes the same update_id parameter.
• Closing or annotating an incident uses PUT incidents/{id} with state / annotation; raising an event uses POST events. Both need an Entuity user with the matching permissions.
• A multi-server ENA deployment is addressed through its central server; the API's serverId qualifier is reported on every record.
• Every API call goes out from the Versus server (or the site's collector when ENA is only reachable on-prem). Allow TCP 443 from that address to the ENA web server.

Related

• Diagnostics AutoPilot — where the entuity_incidents tool lives
• Workflow Builder — approval gates around the incident actions
• Cisco ISE Integration — who is behind the port Entuity says is down
• Pager / On-Call Integration — page the on-call from the same workflow