- 4 minutes to read

Applications

Organize your monitoring landscape by business system with Nodinite Applications. Group all Resources belonging to a specific business system—like a BizTalk Application, Windows Server, or Azure subscription—for simplified management, end-to-end monitoring, and business-aligned access control.

Why use Applications:

  • Business alignment - Group Resources by business system or integration workflow
  • End-to-end monitoring - See all components of a system in one Monitor View
  • Simplified troubleshooting - When one system fails, see all affected Resources instantly
  • Team-based access - Grant teams access to their Applications without exposing others
  • Automatic grouping - Applications are auto-populated from BizTalk, Windows Servers, and other sources

How Applications Organize Resources

graph TB subgraph "Monitoring Agents Discover Resources" MA1[fal:fa-monitor-waveform BizTalk Agent] MA2[fal:fa-monitor-waveform Azure Agent] MA3[fal:fa-monitor-waveform Windows Agent] end subgraph "Resources Auto-Grouped by Application" APP1[fal:fa-box-open Application:
OrderProcessing BizTalk App] APP2[fal:fa-box-open Application:
Azure Subscription: Production] APP3[fal:fa-box-open Application:
Server: WINSERV01] R1[fal:fa-lightbulb-on Send Port
Category: Send Ports] R2[fal:fa-lightbulb-on Receive Location
Category: Receive Locations] R3[fal:fa-lightbulb-on Orchestration
Category: Orchestrations] R4[fal:fa-lightbulb-on Service Bus Queue
Category: Queues] R5[fal:fa-lightbulb-on Windows Service
Category: Services] MA1 --> | Discovers | R1 & R2 & R3 MA2 --> | Discovers | R4 MA3 --> | Discovers | R5 R1 & R2 & R3 --> | Same BizTalk App | APP1 R4 --> | Same Subscription | APP2 R5 --> | Same Server | APP3 end subgraph "Monitor Views Filter by Application" MV1[fal:fa-display Monitor View:
OrderProcessing End-to-End] MV2[fal:fa-display Monitor View:
Production Azure Resources] APP1 --> | All Resources | MV1 APP2 --> | All Resources | MV2 end style APP1 fill:#e1f5ff style APP2 fill:#fff4e1 style APP3 fill:#e8f5e9 style MV1 fill:#f3e5f5 style MV2 fill:#f3e5f5

Diagram: Applications enable business-aligned organization—monitor complete systems end-to-end with all their Resources

The Nodinite Application concept, like the Category concept, groups related Resources. The Resources come from Monitoring Agents and you can use the Application grouping feature to decide what to include in Monitor Views.

For example, all Resources in a BizTalk Application, or from a named Windows Server share the same Application Name. In these cases, the name of the BizTalk Application is being used, and the display name of the Windows Server. This makes it easy for the Nodinite system Administrator to group Resources in Monitor Views by business system or integration workflow.

Origin of Application names

Application names are automatically populated from Resources during the sync operation of the Monitoring Service. The Resources come from the Monitoring Agents. The Monitoring Service knows about the whereabouts of the Monitoring Agents from the settings in Monitoring Agents.

Application names are read-only — they are derived from the source system and cannot be renamed manually. The name reflects the identity of the system as known by the Monitoring Agent:

Agent type Example Application name
BizTalk Agent OrderProcessing (the BizTalk Application name)
Windows Agent WINSERV01 (the server display name)
Azure Logic Apps Agent Production Subscription / Integration RG
Azure Service Bus Agent Production Subscription / Messaging RG
Generic / custom Any string returned by the Monitoring Agent

Application Name Path Convention

For cloud-based and hierarchical sources such as Azure, Application names frequently use / as a separator to reflect the natural hierarchy of the source platform:

Production Subscription / Integration RG
Production Subscription / Messaging RG
Staging Subscription / Integration RG

Each segment separated by / represents a level in the hierarchy — for example Subscription → Resource Group for Azure resources. The Resource Name itself (e.g. the Logic App name OrderProcessor) is not part of the Application path — it is stored separately as the Resource Name.

This convention has two practical benefits:

  • Filtering in Monitor Views — you can filter Resources by Application prefix to show all resources under a subscription across multiple resource groups
  • Mapify virtual groupingMapify parses the /-delimited path at visualization time and builds a navigable tree of virtual nodes, without requiring separate Application records per segment

Example — how Mapify renders Production Subscription / Integration RG:

Production Subscription          (virtual node – level 0)
  └── Integration RG             (virtual node – level 1)
        └── OrderProcessor       ← Resource Name (Category: Logic App)
        └── InvoiceProcessor     ← Resource Name (Category: Logic App)

The two virtual nodes (Production Subscription and Integration RG) are derived purely from the Application name string. No extra configuration is needed.

Applications vs Categories

Both Applications and Categories group Resources, but they answer different questions:

Application Category
Groups by Business system or platform hierarchy Technical resource type
Example Production Subscription / Integration RG Logic App
Set by Auto-populated from the Monitoring Agent Configured by administrator
Used for End-to-end system monitoring, Monitor View filters Filtering by type, Expected State rules
Mapify grouping Yes — path segments become virtual tree nodes Yes — leaf node type label

A single Resource always has exactly one Category and at most one Application. Together they give you two independent axes for navigating your integration landscape.


Next Step

Add or manage Application
Add or manage Categories
Add or manage Resource
Add or manage Monitoring Agent
Add or manage Monitor View

Applications Overview
Categories
Monitoring Agents
Monitor Views
Resources